Ossec es un conocido HIDS que además de controlar modificaciones de ficheros, analiza logs de las máquinas monitorizadas en busca de algún evento que pueda ser signo de un ataque. Reconoce y parsea gran cantidad de tipos de logs y tiene un motor de reglas con capacidad de correlación. Esta es su funcionalidad habitual, aunque también puede ser realmente útil como herramienta para la investigación de un incidente. Ossec tiene una herramienta que aunque originalmente sirve como diagnóstico del correcto funcionamiento de la aplicación, puede procesar un log recopilado offline de un equipo no monitorizado inicialmente, y procesarlo en el motor de ossec con el fin de encontrar evidencias de forma muy sencilla.

Pongamos como ejemplo, una máquina de la que se sospecha que ha podido verse comprometida. No tiene ningún HIDS instalado, ni su infraestructura dispone de un NIDS. Tan solo se tiene a salvo los logs del sistema, que se han almacenado en un servidor de syslog remoto, a salvo de alteraciones del presunto intruso.

El pobre incident handler se encuentra con que las únicas evidencias que le han facilitado para investigar son unos logs del sistema de varios cientos de MB. A pesar de que la forma más precisa de escarbar entre tanto log suele ser abrirlo con un editor, como highlighter, y comenzar a buscar cadenas, se puede automatizar la tarea procesando los logs con ossec, y tener una idea inicial de que ha ocurrido.

# cat auth.log | /var/ossec/ossec-logtest -a

Unos instantes más tarde nos muestra las alertas detectadas. Ossec clasifica alertas con un nivel por su grado de criticidad, de0 a16. Se puede echar un vistazo a los resultados y buscar alertas con level alto. En el caso del ejemplo encontramos esto:

** Alert 1359192816.27: mail  - syslog,attacks,
2013 Jan 26 10:33:36 hostVictima->stdin
Rule: 40112 (level 12) -> 'Multiple authentication failures followed by a success.'
Src IP: 172.16.1.99
User: root
Jan 26 05:28:28 hostVictima sshd[20423]: Accepted password for root from 172.16.1.99 port 60876 ssh2

Se puede ver claramente que han hecho un ataque de fuerza bruta contra el servicio ssh y que el ataque ha resultado efectivo.

Veamos otro ejemplo, esta vez con un log de apache:

# cat vhost1.access.log | /var/ossec/ossec-logtest -a

En este caso el resultado es un log bastante extenso, de bastantes KB, con alertas de mayor y menor criticidad, y encontrar algo interesante puede llevar algo de tiempo. En este caso se puede utilizar la herramienta ossec-reportd, que muestra un resumen estadístico de las reglas que ha procesado:

# cat vhost1.access.log | /var/ossec/ossec-logtest -a | /var/ossec/ossec-reportd

Top entries for 'Source ip':
------------------------------------------------
10.10.10.4		                           	|10  	|
172.16.1.99	                                	|6   	|

Top entries for 'Level':
------------------------------------------------
Severity 10                                 		|5 	|
Severity 6                        	          	|11  	|

Top entries for 'Rule':
------------------------------------------------
31151 - Multiple web server 400 error codes 	 	|11  	|
31502 - TimThumb vulnerability exploit attempt 		|4 	|
31510 - WordPress wp-login.php brute force attack	|1   	|

Se descubre por tanto que por los errores 400 probablemente haya habido un intento de descubrimiento de directorios, varios intentos de explotar una vulnerabilidad en el plugin TimThumb, y un ataque de fuerza bruta al login del wordpress.

Se pueden analizar muchos más tipos de logs. La versión actual de ossec incorpora 62 rulesets, por lo que abarca una gran variedad de aplicaciones y dispositivos.

(N.d.E. Hoy les traemos una presentación que nuestro compañero José Luis Chica, @bufferovercat, realizó hace unas semanas en la MurciaLanParty’12, en torno a las vulnerabilidades web. Esperamos que les guste.)

Kippo es un honeypot SSH de interacción media muy interesante. Permite emular un servicio SSH con credenciales inseguras y reproducir un sistema de ficheros y algunos comandos de sistema. Es muy entretenido echarle un ojo a los logs que genera, puesto que como recoge todas las pulsaciones del teclado, ves como interactúa el atacante y te das cuenta cuando es un script automático y cuando un atacante real, por eso de equivocarte de vez en cuando al escribir. Además, puede almacenar los datos recopilados a base de datos. Eso, unido a las múltiples herramientas que aprovechan esa info para pintarla, generar estadísticas, etc, hacen de kippo una tool muy interesante.

Una de las principales preocupaciones a la hora de desplegar un honeypot es identificar si es posible que un atacante sea capaz de reconocer que realmente está interactuando con un servicio falso. Y en el caso de kippo, es posible detectarlo. El problema está en el intercambio de claves cuando se inicia la conexión, debido a que no lo maneja correctamente y por culpa de eso, se delata.

De hecho, el módulo ssh_version de metasploit es capaz de reconocer si un servicio ssh está siendo emulado por un kippo, como se puede ver en la siguiente captura.

Por otro lado, hay reportada una vulnerabilidad [http://osvdb.org/show/osvdb/78099] indicando que los comandos “w” y “ps” tienen la salida hardcodeada por lo que es posible detectar el honeypot comparando las salidas de estos comandos.

Afortunadamente, estos dos problemas han sido resueltos. Ahora el comando “w” muestra la carga real y se ha arreglado el manejo de la conexión ssh. Para aprovechar estas mejoras, debéis descargar las fuentes directamente desde subversion, ya que el último paquete para descargar tiene casi dos años.

La siguiente captura muestra como metasploit ya no es capaz de detectar el honeypot en su última versión:

Aún así, sigue siendo posible a día de hoy identificar un honeypot kippo. El comando ifconfig devuelve siempre la misma salida. Además, es un poco sospechoso que el contador de bytes recibidos y enviados esté siempre fijo, no creen? ;)

En realidad, kippo no está pensado para emular de forma perfecta un entorno real. Su punto fuerte es la facilidad con la que despliegas un entorno potente, que te permite recopilar estadísticas, comandos usados, o rootkits descargados. Para proyectos más serios, es recomendable un honeypot de alta interacción o una honeynet.

En anteriores post ya hemos hablado sobre la tremenda utilidad que tiene la herramienta nmap. Se ha comentado funcionalidades, optimizaciones y demás investigaciones. Sin embargo, esta herramienta puede ser peligrosa si alguien malintencionado quisiera usarla contra nuestra red. Recordemos que nmap se usa principalmente para descubrir host activos en una red, mostrar sus servicios disponibles, versión de servicio, de sistema operativo, etc. En definitiva, información muy útil para alguien que pretenda hacer maldades.

Por tanto, continuando con la manía que tenemos los que nos preocupa la seguridad de nuestros equipos, vamos a conocer qué medidas se pueden aplicar para ponérselo un poco más difícil a los chicos malos.

1. Conócete a ti mismo

A pesar de ser una frase muy recurrente, tanto en la seguridad informática, filosofía griega o como frase típica de Sun Tzu, la mejor manera de despreocuparte de los escaneos de nmap es teniendo pleno conocimiento de lo que pueden averiguar de tu red, haciendo una serie de análisis de visibilidad externos e internos. Lanza escaneos, desde diferentes subredes, tanto fuera como dentro del perímetro. Comprobarás además si los firewalls están correctamente configurados o ha habido una regla olvidada que haya podido suponer un riesgo. Podrás descubrir servicios vulnerables, si usamos nmap además como herramienta de fingerprinting. Una vez hecha la valoración de la visibilidad, estaremos en condiciones de bloquear servicios, cerrar puertos, parchear vulnerabilidades, etcetc.

Esta práctica, convirtiéndola en periódica, convierte a nmap en una poderosa herramienta de servicios sospechosos. La utilidad Ndiff incluida en la suite de nmap, permite comparar resultados de escaneos, avisando de nuevos puertos descubiertos. Así se podría identificar posibles puertas traseras, o servicios que no deberían estar iniciados. Por ejemplo, si esta herramienta detecta que ha detectado el puerto 7777 como nuevo en un servidor de DMZ, es para preocuparse, ¿verdad?

2. Política por defecto DROP

Esta recomendación no se debería implantar únicamente para dificultar el escaneo al atacante, sino porque protege la red de forma más precisa. Básicamente, en una política por defecto ACCEPT DROP (gracias a ignaciopollo por darse cuenta de la errata) de un firewall, permites pasar tráfico hacia cualquier puerto excepto los definidos en una lista negra. En la política por defecto DROP, se filtra todo el tráfico excepto el definido por una lista blanca.

Explicaré esta consecuencia con un ejemplo: nmap lanza una sonda hacia un puerto concreto de una máquina al que se está auditando. Si hay un firewall en medio con política ACCEPT, dejará pasar esa sonda salvo que se haya configurado que ese puerto debe estar filtrado. Por tanto, el firewall dejará pasar todas las sondas que envíe nmap durante el escaneo, excepto las pocas sondas que se haya filtrado. Ocurre entonces que cuando llega un intento de conexión a un puerto cerrado de un equipo, éste responde de forma activa que el puerto está cerrado. Nmap recibe este dato y comprende que debe continuar su escaneo con el siguiente puerto.

Teniendo un firewall con política DROP, todas las sondas que envíe nmap quedarán filtradas, exceptuando las que estén definidas en la lista blanca. Por tanto, cada vez que se envíe una sonda hacia un puerto no alcanzable, el paquete se descartará. Entonces nmap esperará un tiempo hasta dar por perdida la sonda y la reenviará otra vez, hasta un número máximo de intentos para darse por vencido y pasar al siguiente puerto.

Haciendo números, el escaneo del primer ejemplo tardará únicamente el tiempo que se tarde en enviar las sondas hacia el objetivo, y recoger sus respuestas, obviando las retransmisiones por paquetes perdidos. En el segundo ejemplo, nmap se esperará un tiempo en recibir la respuesta hasta dar por perdido el paquete, multiplicado por el número de reintentos, y a su vez multiplicado por el número de puertos filtrados. En total, es una cantidad de tiempo considerable, desperdiciado en esperas y más esperas. Un escaneo con timings agresivos y bien optimizados, hacia los 64K puertos, puede variar de un par de minutos a cerca de una hora, dependiendo la configuración de los cortafuegos que hayan por medio.

3. Esconde servicios

Nmap tiene una lista de los puertos más usuales. Un escaneo por defecto, sin especificar qué rango de puertos se quiere auditar, tira de esa lista, escoge los 1000 puertos más utilizados para intentar encontrar alguno abierto. Esta lista usualmente está en /usr/share/nmap/nmap-services por si queréis consultarla. Es interesante en algunos casos cambiar el puerto a la escucha de un servicio por un puerto “oscuro” que no sea muy usual. A pesar del típico dicho de “seguridad por oscuridad” no es una buena opción, esta práctica puede ser útil, librándote de un escaneo rápido, y además, de bastante malware que busca servicios típicos para lanzarles ataques por fuerza bruta.

4. Confundir la detección de SSOO

Este “tweak” lo vi hace poco y me resultó curioso. Nmap tiene un fichero de 2MB con huellas de una gran cantidad de dispositivos. Cuando activamos la opción de OS fingerprinting, nmap hace más de 30 pruebas, determinando con bastante acierto el dispositivo y sistema operativo, en función de los resultados obtenidos. Una de esas pruebas es determinar el TTL por defecto. Dependendiendo del sistema operativo, el valor varía bastante. En el caso de Linux, es 64. No obstante, es un parámetro bastante sencillo de modificar. Veamos un ejemplo:

~# nmap -O 192.168.1.100
[...]
Device type: general purpose
Running: Linux 2.6.X
OS CPE: cpe:/o:linux:kernel:2.6
OS details: Linux 2.6.17  2.6.36

Observamos como en este ejemplo acierta bastante con el sistema operativo de la máquina auditada. Modificando el valor del TTL por defecto:

~# echo 83 > /proc/sys/net/ipv4/ip_default_ttl

por un valor inusual, obtendríamos ahora este resultado:

No exact OS matches for host (If you know what OS is running on it, see
http://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=5.61TEST2%E=4%D=4/18%OT=22%CT=1%CU=42601%PV=Y%DS=1%DC=D%G=Y%M=080
OS:027%TM=4F8EAFE6%P=x86_64¬unknown¬linux¬gnu)SEQ(SP=C8%GCD=1%ISR=C9%TI=Z%C
OS:I=Z%II=I%TS=8)OPS(O1=M5B4ST11NW5%O2=M5B4ST11NW5%O3=M5B4NNT11NW5%O4=M5B4S
OS:T11NW5%O5=M5B4ST11NW5%O6=M5B4ST11)WIN(W1=16A0%W2=16A0%W3=16A0%W4=16A0%W5
OS:=16A0%W6=16A0)ECN(R=Y%DF=Y%T=54%W=16D0%O=M5B4NNSNW5%CC=Y%Q=)T1(R=Y%DF=Y%
OS:T=54%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=Y%DF=Y%T=54%W=16A0%S=O%A=S+%F=AS%
OS:O=M5B4ST11NW5%RD=0%Q=)T4(R=Y%DF=Y%T=54%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y
OS:%DF=Y%T=54%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=54%W=0%S=A%A=Z%F=R
OS:%O=%RD=0%Q=)T7(R=Y%DF=Y%T=54%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T=
OS:54%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=54%CD=S
OS:)

Nos indica que no ha podido encontrar equivalencia con la huella obtenida. A pesar de que si que se puede leer “linux” entre los valores recogidos, no es capaz de afinar tanto como con el ejemplo anterior.

No obstante, en la práctica esto no suele ser tan bonito. Además de estos parámetros, nmap utiliza otros indicios para averiguar el tipo de sistema, como los banners de servicios. SSHd suele ser bastante chivato y por desgracia no hay ninguna opción para cambiar o silenciar este banner:

# nmap -sV -p22 192.168.1.100

PORT   	STATE 	SERVICE 	VERSION
22/tcp 	open  	ssh 		OpenSSH 5.9p1 Debian 5 (protocol 2.0)

Otro indicio es encontrar una aplicación que es específica de un sistema operativo concreto. Por ejemplo, un servidor web IIS, con bastante probabilidad estará ejecutándose en una máquina Windows, salvo que sea una honey, claro ;)

5. Otras “recomendaciones no recomendables”

Hay que tener mucho cuidado con la protección activa ante escaneos. En el caso de disponer de un IPS, debemos estar muy seguros de que la parametrización está bien afinada y que lo que se está detectando no hay falsos positivos. En determinados escenarios, es muy difícil hacer esto posible. Más peligroso todavía es añadir las IPs atacantes a cuarentena, o filtrado automático al firewall. Si un atacante detecta este comportamiento, podría lanzar un nmap con IPs spoofeadas, pudiendo forzar al sistema a filtrar IPs arbitrarias.

Otra medida más discutible es si añadir reglas al IDS para detectar escaneos. El hecho de que nuestra red está siendo escaneada probablemente no sea muy relevante como para preocuparse. Si nuestra red es grande, y el sistema de detección de intrusos está integrado con un SIEM, podrían llegar un gran número de alertas a lo largo del día, generando ruido innecesario. No obstante, si contamos con un sistema de correlación de alertas, que utilice este dato para contrastarlo con otros eventos, si que puede ser realmente útil recopilar esta información. Por ejemplo, un nmap desde una IP, por sí solo no es muy relevante, pero si hemos registrado un acceso por SSH un tiempo después de un escaneo desde esa misma IP, como hechos aislados no parece relevante, pero si se correla esta información, podríamos estar ante un potencial acceso no autorizado al sistema.

Nmap es una archiconocida herramienta de escaneo de red. Seguramente todos los que estéis leyendo esto la habréis utilizado alguna vez. Permite de forma muy sencilla hacer una enumeración de los equipos que hay conectados a una red, o descubrir los servicios disponibles en una máquina. Cuando hacemos esto de forma ocasional, y para un escaneo de una red pequeña, o para un solo equipo, no nos paramos a pensar en afinar la configuración, y escribimos la ristra de parámetros que nos sabemos de memoria. En mi caso suelo usar:

# nmap -T4 -A ip-host

Esta configuración hace un escaneo TCP de tipo SYN scan, que es el tipo por defecto si no le especificas de otro tipo. Utiliza una plantilla de tiempo bastante agresiva (-T4), y además ejecuta detección de sistema operativo, de versión de servicios, uso de scripts, y traceroute (-A) Todo esto, como ya hemos comentado, puede ser adecuado si el escaneo se lo realizamos a una única máquina. Pero cuando estamos hablando por ejemplo de hacer un escaneo a una clase B entera, se hace imprescindible optimizar el máximo posible la configuración del escaneo, ajustar al máximo los tiempos y lanzar únicamente las sondas que sean necesarias. Veamos como ajustar los rtt con valores personalizados.

[Read more…]

El objetivo que se fija un pentester a la hora de hacer un test de intrusión se resumiría básicamente en intentar saber hasta donde es capaz de llegar. Por regla general, si conseguimos vulnerar una máquina que se encuentre seguramente en una DMZ, estaremos en una posición ventajosa para acceder a recursos que no están accesibles directamente desde Internet. Todo depende claro está de cómo de restringida se encuentre dicha máquina.

Una técnica que se suele utilizar y que sorprendentemente da buenos resultados es conseguir las credenciales de administrador del equipo vulnerado y comprobar si el resto de máquinas accesibles comparten la misma contraseña. En el caso de sistemas Windows, el sistema operativo almacena las contraseñas cifradas en el fichero SAM con los algoritmos LM o NTLM. En sistemas anteriores a Windows Vista o Windows 2008, el algoritmo de cifrado por defecto es LM. Desgraciadamente (o por suerte para el pentester) este cifrado es muy débil por su diseño: soporta un tamaño máximo de contraseña de 14 caracteres, no distingue mayúsculas de minúsculas, almacena el hash en dos mitades de 7 caracteres, y no añade “sal” en el almacenamiento para añadirle aleatoriedad, haciéndolo muy vulnerable a ataques por fuerza bruta o por tablas precomputadas.

Vamos a plantear una situación, en la que el pentester ha conseguido vulnerar una máquina Windows, utilizando algún exploit con el framework Metasploit, y obteniendo una sesión de meterpreter en el equipo víctima. Aprovechando las herramientas de post-explotación que dispone, conseguirá recuperar los hashes de las contraseñas para poder descifrarlas usando como ejemplo tanto herramientas de fuerza bruta como de tablas precomputadas.

Empezamos recuperando los hashes almacenados en la SAM:

Este paso ha sido fácil, pero en la jungla salvaje no suele ser tan sencillo. Sin profundizar mucho sobre el tema, a veces necesitaremos permisos de Administrador o SYSTEM y habrá que escalar privilegios. La shell de meterpreter tiene varios métodos, aunque el más sencillo son los comandos priv y getsystem. Si escalando privilegios tampoco tuviéramos permiso para recuperar la SAM, es posible que sea necesario migrar el proceso de meterpreter al uid de un proceso creado por SYSTEM. Normalmente lsass.exe suele reunir dichas características.

Salimos de la sesion de meterpreter con la orden

Una mejora importante que han incluido en la versión 4 de Metasploit es que han integrado la base de datos dentro del core, por lo que ahora por defecto toda información que vayamos recuperando se irá almacenando automáticamente en un workspace de la base de datos. Estos datos podrán ser entonces utilizados por otros plugins. Vamos a comprobar que efectivamente los hashes están almacenados:

Comenzaremos utilizando el módulo de John the Ripper, introducido en la versión 4 de Metasploit. Su uso es extremadamente sencillo. Solo hay que cargar el módulo y lanzarlo. Él ya se encargará de leer los hashes del workspace donde estemos y darles caña.

Después de unos pocos instantes (en este caso, todo depende de la potencia de proceso del equipo) JtR termina informando que ha descifrado de forma exitosa los hashes. Veamos ahora que hay en la base de datos:

Ha actualizado la tabla de credenciales con las contraseñas descubiertas para cada usuario. Como se puede observar, la contraseña de administrador es “password”. Obviamente es una contraseña muy sencilla, de diccionario y no excesivamente larga. Si pusiéramos una palabra con caracteres especiales el módulo de Metasploit ahora mismo no sería capaz de descifrarlas, puesto que la adaptación de JtR a Metasploit está en una fase muy temprana y no permite ahora mismo configurar las opciones. Además, al añadirle complejidad a la contraseña, el tiempo de computación sería bastante más alto y quizás no crackee los hashes en un tiempo razonable.

Para estos casos, utilizar rainbow tables o tablas precomputadas es la solución ideal. Usaremos como ejemplo la herramienta ophcrack. Se encuentra disponible en la mayoría de distribuciones y su interfaz gráfica es muy sencilla de usar. Hará falta descargar aparte las rainbow tables. En la misma web [http://ophcrack.sourceforge.net/download.php] se pueden conseguir algunas tablas de forma gratuita.

Podemos observar que en tan solo 10 segundos ha conseguido crackear una contraseña compleja, “Pal4br@Chung4”. Obtenida la contraseña de administrador en texto plano, podemos probar a autenticarnos con dicha credencial en los servicios que sean visibles desde la máquina vulnerada, y a cruzar los dedos!

Este ejemplo sencillo de intrusión, sin embargo, se podría haber evitado si se hubieran tomado las siguiente medidas:

• Nunca repetir contraseña en ningún servicio de ningún equipo. Si alguna de esas contraseñas sale a la luz, te evitas que el fallo de seguridad se propague a otros servicios.
• Deshabilitar el uso de LM a la hora de almacenar las contraseñas en la SAM. Forzar el uso de NTLM.
• Utilizar contraseñas fuertes. Si son de más de 14 caracteres también estás forzando a que se almacene solo con NTLM.
• Aislar en la mayor medida de lo posible las máquinas de la red DMZ del resto de equipos. Que tenga visibilidad de únicamente los servicios que le sean estrictamente necesarios.

Nada más por hoy. Pasen un buen fin de semana.

En relación con el post de ayer que hablaba sobre los peligros que supone compartir fotos a través de redes sociales, hoy vamos a entrar en materia con una aplicación que recopila forma sencilla información sobre la geolocalización que la mayoría de smartphones almacenan en las fotos. Cree.py es un script en python con una interfaz muy sencilla. Le indicas la cuenta de twitter a la que quieres recopilar información, y listo. Puedes bajarte el programa, para Windows o Linux, en su web.

La aplicación recoge la información de las fotos colgadas en twitter, y de los “check-in” que haces con la aplicación foursquare. Una vez que creepy acaba con la busqueda, utiliza la API de Google Maps para situar cada posición encontrada en el mapa en forma de hitos. De esta forma podemos ver con un simple vistazo por donde ha estado nuestra “víctima”.

Vamos a probar con algún contacto que sigo en mi twitter:

Podemos ver en la captura que creepy nos muestra que esta persona ha estado en los últimos días en Madrid y Valencia. Vamos a cerrar el zoom para ver una vista más global:

¡Vaya, nuestro amigo viaja mucho! Podemos deducir con las posiciones GPS y la fecha de la foto que esta persona ha estado en Colombia el día 17 de este mes y el 16 del mes pasado. Esta información, aparentemente inofensiva, puede ser peligrosa si cae en malas manos. Por ejemplo, le estamos diciendo a un ladrón: “Mi casa está vacía y yo estoy a miles de kilómetros”.

Si este verano tienes intención de viajar, piensa qué información proporcionas por tus redes sociales.