Personalmente, yo en primer lugar trato de evitar el tema y así la pregunta y la respuesta asociadas; una buena táctica suele ser el fútbol (puedo hablar durante horas de fútbol sin tener ni idea, recurriendo a lo de siempre: “este año vamos así así“, “no hay rival pequeño“…) o el clima (“ya empieza el calor“, “vaya día de frío“…), temas que casi nunca fallan. Pero si no logro distraer la atención con estas conversaciones y al final aparece la pregunta maldita suelo responder de forma muy escueta: o bien digo “informática” o bien digo “seguridad“, en función de cómo tenga el día y, sobre todo, de lo que crea que en cada momento va a dar menos juego a mi interlocutor para seguir con la conversación. Pero esto último no siempre lo consigo, y la cosa a veces se complica…

Si respondo “informática” ya sé que a continuación me van a comentar algo del ordenador que se acaban de comprar o, peor aún, de lo complicado que les resulta programar el DVD y de que si les podría echar una mano… En ese momento o bien les doy la razón asintiendo con la cabeza y cambio de tema o, si estoy en plan valiente, les explico que la informática es otra cosa y trato de convencerlos de que en cinco años de carrera no tuve ninguna asignatura de programación de DVD y que no me dedico a eso exactamente. A partir de aquí, si el interlocutor es avispado ya llega a su propia conclusión: “ah, entonces haces programas… Pues entonces podrías ayudarme, porque el programa de contabilidad nos va lento y queremos otro…“. Si es que ya se sabe: en informática o arreglas ordenadores o haces programas, no hay más…

Con paciencia explico que la informática es muy amplia y tiene muchas especialidades, y que a pesar de tener unas bases comunes no sabes de todas y cada una de esas especialidades… Eso no suele quedar muy claro y la gente insiste en el tema: “Pero si ni arreglas ordenadores ni haces programas, ¿cómo que eres informático? ¡Pues vaya informático, que no puede ni arreglar la batidora!” (digo batidora como ejemplo de cacharro con cable que, por supuesto, debe conocer a la perfección cualquier informático). En este momento ya suelo poner un ejemplo de un buen amigo que es muy descriptivo y todo el mundo entiende: ¿Verdad que cuando tienes paperas no vas al proctólogo, por muy médico que éste sea? Podría llegar al centro de tu dolencia, pero te aseguro que el camino sería más largo que el del especialista… Pues lo de la informática es igual: yo podría arreglar tu ordenador o diseñarte un programa, pero ya te adelanto que ni tú ni yo vamos a quedar satisfechos…

Si en lugar de informática digo que me dedico a seguridad la cosa suele ser casi peor… “¿Seguridad? ¿Pero no habías estudiado algo de informática? ¿Te lo has dejado? ¿Qué estás, de vigilante?” “No, a ver, seguridad de la información y todo eso, lo de los ordenadores, no me he dejado la informática…” “Ah, vale, lo de los antivirus…“. Sí, justo eso, lo de los antivirus… Aquí suele acabar la conversación por mi parte, pero siempre hay alguien -el avispado de antes, posiblemente- que tiene interés en tu vida: “¿pero qué haceis? ¿poneis programas para que no entren virus ni hackers, como en las películas? ¡Qué pasada!” Sí, tenemos unas pantallas enormes, tipo Matrix, con letras verdes que se mueven mucho… Además somos capaces de saber dónde está la casa de una persona simplemente mirando su IP -geolocalizamos de cabeza hasta llegar a la dirección física-, ampliamos cualquier imagen todo lo que nos da la gana sin que se pixele y entre nosotros hablamos hexadecimal. Si es que el cine ha hecho mucho daño… diez horas al día delante de una pantalla negra con letras blancas mirando payloads les daba yo a éstos…

Si tratas de hablar en serio con ellos y explicar lo que son los ataques remotos, las botnets, las infraestructuras críticas, el ciberdelito o la ciberguerra te metes en un lío del que luego es difícil salir. Un consejo: ni se os ocurra hablar de estas cosas; dejadlo, como sea, en los virus, en el vigilante o en Matrix, pero no expliqueis esto o vuestro interlocutor se hará una idea equivocada de vosotros… Una vez, alguien de más confianza -un familiar, para ser exactos-, incluso me preguntó si llevaba pistola… Claro, llevo un AK-47 en la mochila, por si se me complica el día… ¿Lo saco y pegamos unos tiros aquí en la calle, y luego llamamos a Torrente para hacernos unas cañas… o lo que surja?

En fin, que esto de intentar explicar a qué nos dedicamos los que trabajamos en este ámbito, que ya no sé cómo llamar, es complicado. Imagino que todos hemos vivido situaciones parecidas a las que he comentado, por eso a veces, cuando creo que responder correctamente no va a suponer más que un jardín del que luego no voy a poder salir de manera rápida, sencillamente digo “soy taxidermista, ¿y tú?” ;)

La amplia participación y el interés del alumnado fue muy alto, llegando a presentar resultados más de 50 estudiantes. Los criptogramas de Vigenère divididos en cuatro bloques de dificultad con cuatro retos cada uno propuestos por el profesorado de la ETSINF, fueron resueltos en menos de un día, demostrando el alto nivel de los participantes.

S2 Grupo, de la mano de nuestro director de seguridad Antonio Villalón y un servidor entregaron a los ganadores su bien merecido premio, un iPad para el primer clasificado, Salvador Arnal Julián y sendos iPods para el segundo clasificado, Rafael Boix Carpi y terceros, Vicent Selfa Oliver y Eduardo Pablo Novella Lorente.

Agradecer por último el interés mostrado por los participantes y el esfuerzo de la ETSINF en todas las actividades que están realizando para conmemorar el centenario de este Año Turing 2012. Para el año siguiente ya se está barajando la posibilidad de organizar un reto hacking que ponga a prueba las habilidades de los alumnos de esta escuela, por el momento enhorabuena a los premiados por su esfuerzo.

Nosotros, hoy en día, estamos vendiendo nuestra privacidad por un plato de funcionalidades que nos proporcionan cocineros como Google, Apple, Dropbox, Microsoft, Sony y muchos otros. Nos tientan con posibilidades de usar nuevas aplicaciones muy atractivas, absolutamente imprescindibles — ¿Cómo no voy a proclamar a los cuatro vientos dónde me encuentro en cada momento o lo que estoy haciendo? — y a cambio de algo que apenas tiene valor — ¿Para qué querrán saber quiénes son mis amigos o a qué contactos les envío emails? — ¿o sí lo tiene?

Hoy mismo he visto una noticia en CNN, según la cual, Jeanette Horan, CIO de IBM, ha prohibido a los empleados de la multinacional el uso de Siri en sus iPhones porque “La compañía está preocupada porque las peticiones dictadas a Siri podrían almacenarse en algún sitio”. Of course, Ms. Horan, las peticiones se redirigen para su procesamiento a un centro en North Carolina y no está nada claro qué ocurre con ellas allí, en las entrañas de la bestia.

Claro que, si leemos las condiciones del acuerdo de licencia de software “When you use Siri or Dictation, the things you say will be recorded and sent to Apple in order to convert what you say into text” nos quedamos mucho más tranquilos. Porque somos todos un poco inconscientes. Y no sigo leyendo el acuerdo porque, en primer lugar, me aburro y, en segundo, nadie iba a escucharme. Bien se dice por ahí que la mentira más grande de Internet es “He leído y acepto las condiciones de uso”. Hasta tiene página en Facebook.

Y entonces, ¿qué hacemos? ¿renunciamos a las funcionalidades que a tan bajo precio nos ofrecen estas empresas tan magnánimas? La verdad es que nos ayudan mucho en nuestro trabajo y en nuestro tiempo de ocio. Nos permiten comunicarnos con mucha más facilidad y compartir nuestra vida con nuestros compañeros, familia y amigos. No seré yo quien les recomiende no usar todas estas posibilidades. Entre otras cosas, porque tengo hijos y sé cuándo un consejo es inútil.

Eso sí, recuerden que la sabiduría popular dice que “nadie da duros a cuatro pesetas” (para los nacidos en pleno euro, “nadie da euros a 80 céntimos”) y, por tanto, está claro que estas empresas van a “monetizar” la información que tan despreocupadamente les cedemos. Que eso nos perjudique o no, depende del uso que hagan y, desgraciadamente, no estamos en absoluto protegidos ante sus abusos.

En conclusión, mi consejo es que sean conscientes de cuál es la situación y asuman los riesgos con conocimiento. Ni más, ni menos. Si no los entienden, pregunten. Y si no, despreocúpense… peor sería ser ganador de un Premio Darwin.

Después de estar un buen rato entre subir fotos, ordenarlas y redactar la descripción de la vivienda me di cuenta que me habían enviado un correo de la web en donde había dado de alta el inmueble. Era el típico correo de bienvenida donde se me indicaba entre otra información mi usuario y mi contraseña, en texto en claro por supuesto.

Entonces tuve una idea fugaz: si me han mandado la contraseña en texto en claro… ¿no será porque la están almacenando en texto en claro? Y que mejor forma que confirmarlo que emplear los métodos de recuperación de contraseña ante una pérdida de la misma, así que me da por recordar la contraseña donde se indica literalmente “enviadme mi contraseña!”. ¡Sorpresa! Me envían al correo mi contraseña en texto en claro.

Lanzado como soy yo, me pongo en contacto con la web mediante correo electrónico y amablemente les indico que por favor cifren las contraseñas en la base de datos, a lo que recibo una contestación donde se me agradece la información proporcionada y que lo tendrán en mente como mejora.

Un año después he vuelto hacer la prueba y como supondrán todo sigue exactamente igual:

Lo siguiente era consultar con el Departamento de Consultoria de nuestra empresa, para preguntarles si era obligatorio cifrar las contraseñas, ya que aunque yo desde el punto de vista técnico lo tenía clarísimo, desde el punto de vista de la LOPD no lo tenía tan claro. La contestación fue que ese tipo de aspectos estaban regulados por el siguiente artículo:

Mi pregunta ahora es para ustedes. En calidad de usuario preocupado por la seguridad de sus datos, ¿debería informar a la Agencia Española de Protección de Datos o les envío un segundo correo para que me vuelvan a indicar que lo introducirán en sus mejoras próximamente? De momento ya les he mandado un segundo correo haciendo alusión al artículo 93, al que estoy esperando respuesta.

Les tendré informados.

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.

Metasploit es una maravilla para hacer auditorias, pero también una locura (debido al elevado número de módulos) si no sigues unas pautas en cierto orden y dedicas gran tiempo a la fase de information gathering.

La idea de esta entrada es mostrar cómo es posible automatizar algunas de estas tareas ahorrándonos mucho tiempo y garantizando seguir siempre una misma metodología sin olvidar ningún paso.

Personalmente, cada vez que quiero auditar una nueva red dedico mucho esfuerzo a la fase de discovering, utilizando diversos escaneos con db_nmap (-sT, -P0, -sS, -P0, -sV, -sA, etc.) y utilizando multitud de módulos auxiliares. Un caso bastante típico es encontrarse máquinas con servicios SMB ejecutándose, así que generalmente utilizo los auxiliary modules en auxiliary/scanner/smb para intentar conseguir la versión del S.O (smb_version), usuarios locales (smb_lookupsid), recursos (smb_enumshares), vulnerabilidades (ms09_050_smb2_negotiate_func_index), etc. Lo mismo para el resto de servicios como smtp, snmp, http, etc.

Obviamente, la idea de todo esto es almacenar toda la información que vayamos consiguiendo en nuestro workspace y en sus tablas asociadas (hosts, services, creds y notes) para posteriormente pasar a la fase de explotación. La pregunta es: si siempre llevo a cabo este modus operandi, ¿por qué no automatizar todo este proceso? Esta es la idea de los resource scripts, disponibles desde la revisión 8876, los cuales son tratados como templates ERB al permitirnos ejecutar bloques de instrucciones en ruby desde los que podremos hacer uso de la API de Metasploit (REX). En mi caso, suelo utilizar muchos de los scripts ya disponibles en $install_dir/scripts/resource, la gran mayoría desarrollados por m-1-k-3 (excelente trabajo, por cierto). Estos scripts nos permiten llevar a cabo, entre otras, gran parte de las tareas comentadas anteriormente.

Comenzaremos con el script basic_discovery.rc, el cual sirve para conseguir máquinas y servicios disponibles utilizando nmap y una gran variedad de módulos auxiliares (smb, imap, pop, http, ftp, vnc, etc.)

Si abrimos el script podemos ver que admite algunos parámetros desde el datastore. Uno de estos parámetros (NMAPOTS) nos permitirá especificar el conjunto de flags con el que deseamos utilizar NMAP; en caso de no definirlo utilizará -PN -P0 -0 -sSV por defecto.

Si en lugar de utilizar NMAP, lo que queremos es utilizar el módulo auxiliar portscan con el conjunto de puertos que se definieron en la variable #{ports} (véase arriba), bastará con fijar la variable NMAP a 0 (o valor distinto de true).

Supongamos, por tanto, que nos encontramos en la red local 192.168.1.0/24 y queremos obtener máquinas activas así como los servicios corriendo en las mismas. Lo único que tendremos que hacer es fijar en el datastore la variable RHOSTS y los parámetros deseados. Posteriormente, para lanzar el script ejecutamos resource basic_discovery.rc:

Si miramos ahora la tabla services obtenemos lo siguiente:

msf > resource port_cleaner.rc
[*] Processing /opt/framework/msf3/scripts/resource/port_cleaner.rc for ERB directives.
[*] resource (/opt/framework/msf3/scripts/resource/port_cleaner.rc)> Ruby Code (627 bytes)
...
...

msf > services -c name,info 

Services
========

host           name      info
----           ----    	 ----
192.168.1.1    ftp       220 cfr110998 FTP version 1.0 ready at Fri May
   15 03:22:21 2000\x0d\x0a
192.168.1.1    telnet    Password:
192.168.1.1    ssh       SSH-2.0-OpenSSH_5.8p1 Debian-7ubuntu1
192.168.1.7    netbios   SAW-PC:<00>:U :WORKGROUP:<00>:G
   :SAW-PC:<20>:U :WORKGROUP:<1e>:G :00:01:aa:02:bb:03
192.168.1.34   ssh        SSH-2.0-OpenSSH_5.8p1 Debian-7ubuntu1
192.168.1.34   dns       BIND 9.7.3
192.168.1.34   domain  	 ISC BIND 9.7.3
192.168.1.100  netbios   SAW-4F3245E21E:<00>:U :WORKGROUP:<00>:G
   :SAW-4F3245E21E:<20>:U :WORKGROUP:<1e>:G :00:01:22:22:21:cc
192.168.1.100  ntp       Microsoft NTP
192.168.1.111  ntp     	 NTP v4 (unsynchronized)
192.168.1.111  snmp
192.168.1.124  dns       BIND 9.4.2
192.168.1.124  netbios   SAW-4F3245E22E:<00>:U :SAW-4F3245E22E:<03>:U
   :SAW-4F3245E22E:<20>:U :WORKGROUP:<00>:G :WORKGROUP:<1e>:G :01:aa:bb:bb:cc:aa
192.168.1.124  ntp       Microsoft NTP

Veamos otro resource script que puede resultarnos de gran ayuda. Supongamos que conseguimos algunas de las credenciales de acceso a algún servicio y queremos comprobar si las mismas son válidas para algún otro servicio de los disponibles en nuestro workspace. El script auto_cred_checker.rc reutilizará las credenciales disponibles en la tabla creds e intentará hacer logging contra alguno de los servicios previamente identificados.

…

Como se observa en el ejemplo, el script ha utilizando las credenciales añadidas a creds (user: saw, pass: saw) para intentar autenticarse contra el resto de servicios disponibles en la tabla services, encontrado así un acceso ssh a la máquina 192.168.1.34.

Durante la fase de post-explotación también podemos programar, mediante este tipo de scripts, el conjunto de acciones que queremos llevar a cabo en la equipo objetivo. Supongamos, por ejemplo, que hemos conseguido multitud de sesiones con meterpreter y queremos ejecutar las mismas órdenes en todas las sesiones. Generalmente lo que queremos conseguir son hashes, tokens, etc., así que lo único que tendríamos que hacer es modificar a nuestro gusto el script multi_post.rc y lanzarlo. Utilizando los arrays meterpreter_commands y modules_win podremos añadir y quitar las órdenes que queremos ejecutar desde meterpreter así como los módulos post en los que estamos interesados.

Lo que hará multi_post.rc es recorrer cada una de las sesiones (framework.sessions.each_key) y ejecutar las acciones definidas en ambos arrays:

Veamos un último caso. Imaginemos que necesitamos ejecutar un conjunto de acciones sobre la máquina comprometida una vez conseguimos una sesión de meterpreter. Este generalmente es el caso cuando llevamos a cabo client side attacks, al no saber cuándo vamos a recibir shell (por ej. usando el browser autopwn). En el siguiente ejemplo crearemos un resource script en el que se añadirá el modulo search_dwld con el que conseguiremos los ficheros pdf y doc de la víctima. Para conseguir que se ejecute automáticamente necesitamos fijar la variable AutoRunScript a multi_console_command -rc /root/steal_pdf.rc

El script multi_console_command permitirá ejecutar múltiples comandos bien separados por comas (-cl) o bien definidos en un fichero de texto (-rc). El resultado:

Como puede verse, los resource scripts pueden ahorrarnos multitud de tiempo. Además, son sencillos de escribir, por lo que podemos crear o modificar los script disponibles según nos convenga.

La automatización de tareas desde Metasploit no se reduce únicamente a este tipo de scripts. Utilizando plugins, módulos auxiliares, haciendo uso de la Remote API, etc., es posible también automatizar multitud de acciones en función de las necesidades y de la flexibilidad que necesitemos para ello. Os recomiendo el post de HDM titulado Six Ways to Automate Metasploit donde se explica resumidamente cada una de estas opciones.

Esta característica es realmente impresionante ya que te permite ver información que antes no era posible —o al menos no de forma tan directa—, facilitando la identificación de ataques. Al activar la opción log_uri, el preprocesador almacenará la URI para la sesión completa y, si la alerta está configurada con las opciones “flow:from_server, established”, cuando salte esta alerta proveniente de la respuesta de un servidor, aparecerá la petición del cliente que la ha provocado.

Es decir, podremos ver la petición, por poner un ejemplo, que ha originado un error 500 en un servidor Tomcat. Con un ejemplo se verá más claro:

Gracias al campo Full URI podemos ver cómo la respuesta 500 del servidor se debió a una petición un tanto ‘extraña’. Si vemos la URI, se trata de una conocida webshell que han subido al servidor a la que se le pueden enviar comandos a través de la variable comment. En este caso, pretendían descargar el fichero 9.txt desde un servidor a través del comando wget. Afortunadamente, al no poder ejecutar el comando, el servidor devuelve un error 500, lo que ha hecho saltar la alerta.

Gracias a poder ver la URI que ha provocado el error se ha podido detectar este incidente que de otra forma no habría sido posible, ya que sólo se trataría de un error 500 que podríamos achacar a un error puntual del servidor.

Esta es sólo una muestra de la información que podemos sacar de ese campo en determinadas situaciones, lo que facilita la gestión de incidentes de seguridad, al menos en su fase de identificación.

Hoy, con motivo de la celebración del día de Internet, promovido desde 2005 por la Asociación de usuarios en Internet a las que se han ido sumando diferentes asociaciones españolas, me gustaría reflexionar sobre las virtudes y facilidades que los Servicios de la Sociedad de la Información han traído a las vidas de muchos ciudadanos y empresas internautas y qué mejor forma de hacerlo en los tiempos que corren que reflejarlo en la búsqueda de empleo.

En España el 48% de la población utiliza Internet para buscar empleo, según la reciente encuesta realizada por la consultora Ipsos siendo la referida tasa superior a la de otros países, como Italia (36%), Alemania (30%) o Francia( 25%). Para más datos, según el último informe publicado por el Instituto Nacional de Estadística (INE) en fecha 5 de octubre de 2011, el índice de personas en situación de desempleo que usaron Internet en sus hogares asciende al 86,6 % y aunque desconocemos los usos de este porcentaje, qué duda cabe que Internet es una herramienta útil para la búsqueda de empleo.

Siendo múltiples y variadas las plataformas, portales de búsqueda de empleo, mi atención la voy a centrar en las redes sociales puesto que dentro de la disparidad que encontramos en las redes sociales (generalistas y profesionales) y sus funcionalidades, están destacando como una opción más para la oferta de empleo.

Las redes sociales como plataformas de comunicación en línea permiten crear redes de usuarios, posibilitando que los candidatos puedan relacionarse con otros candidatos e incluso interactuar con empresas que demanden empleo diseñando y ajustando su perfil profesional a las necesidades del mercado laboral. Actualmente, no solo se utilizan redes sociales profesionales, como podría ser LinkedIn, sino que todas valen para dicho fin. Prueba de ello, el estudio realizado por el equipo de jobandtalent que establece que los contactos de Facebook son más utiles en la búsqueda de empleo que los de LinkedIn.

Desde mi punto de vista, el uso adecuado de las redes sociales son una oportunidad para estar conectado y tener acceso a múltiples grupos, perfiles de usuarios, Curriculums y ofertas de empleo asumiendo en todo caso la pérdida de intimidad que ello supone y la ausencia de confidencialidad para el caso de que lo que se pretenda sea simplemente una mejora de empleo.

Por otro lado, no debemos olvidar la otra cara de estar presente en las redes sociales para ofrecerte como candidato; me estoy refiriendo desde el punto de vista del posible futuro empleador. Por razones obvias, desde hace tiempo las redes sociales se están convirtiendo en un instrumento frecuente en los procesos de selección de personal habida cuenta la información personal que se puede extraer del candidato, resultando en ocasiones tras la consulta del perfil del usuario la causa por la que se desechan las candidaturas.

La duda que planteo es ¿hasta qué punto sería legal esta práctica de acuerdo con el principio de calidad de los datos establecido en el artículo 4 de la LOPD? El problema en todo caso es probar que se ha producido este tipo de tratamientos de datos “casi invisibles” por parte del seleccionador o headhunter, teniendo en cuenta que suelen suceder previamente a la entrevista de trabajo.

Como concepto derivado de un BIS o Sistema Inmune Biológico, los trabajos han sido orientados al seguimiento básicamente de tres paradigmas:

• La Selección Negativa
• Clonación Selectiva
• La teoría de la señal de riesgo

1. La selección negativa

El paradigma de la selección negativa biológica es simulado usando un aprendizaje sobre el comportamiento normal de una red o un sistema y tratándolo como propio, de modo que todo elemento ajeno al sistema es considerado como una intrusión. Concepto ya conocido como la detección de intrusiones basada en anomalías. Pues bien, dentro de este paradigma encontramos diferentes aproximaciones según autores.

• Zhang et al (2005). La propuesta de Zang pasa por la utilización de agentes independientes que trabajan de forma coordinada para detectar intrusiones, implementada en Java con AgentMOM y JSDT para las comunicaciones.
• Okamoto and Ishida (2007). Okamoto implementa tres clases de agentes, los C, B y M. El primero gestiona los dos siguientes, marcando a los de clase B las rutas entre los hosts que debe seguir. Los de clase B recolectan información de los equipos monitorizando comportamientos sospechosos. Por último los de clase M son los encargados de reaccionar ante intrusiones detectadas. Este modelo permite repartir la carga computacional de detección entre diversos equipos.
• Zhongmin et al (2007). Introducen el modelo de la diversidad, donde cada host de la red genera diversos agentes y estos son compartidos con los sistemas vecinos. Su sistema basado en anomalías genera agentes específicos para cada usuario del equipo, donde cada agente es capaz de reconocer a su usuario, pasando posteriormente a autoclonarse y cambiando de perfil de usuario. Esta copia podrá sobrevivir solo si obtiene una puntuación adecuada en el periodo de entrenamiento del agente.
• Luther et al (2007). Luther incorpora el concepto de mutación de agentes, donde todos los elementos de detección del sistema desplegados de forma distribuida son tratados como un único IDS. Para la comunicación entre sus elementos utiliza un modelo P2P ayudando a mitigar los falsos positivos generados por la detección basada en anomalías. Por último destacar que el sistema está desarrollado en Java.
• Bye et al (2008). Como el anterior, Bye utiliza la detección colaborativa, basando su lógica en la recolección estadística de información de los sistemas. Para el intercambio de información entre sus agentes hace uso de una red P2P, donde cada elemento tiene asociada una métrica computada de la posibilidad de infección, la cual es compartida dentro del entorno P2P. A su vez comparten información sobre ataques o incluso falsos positivos. Para testar el sistema utilizan NeSSI, un simulador de tráfico de red. El único inconveniente es que no se realiza ninguna acción tras la detección de una intrusión.
• Boudec and Sarajanovic (2004). Estos autores describen un sistema basado en conjuntos de agentes Workers donde cada grupo es especialista en un tipo de detección de intrusión. Todos ellos son gestionados por un agente Master. Cada elemento de esta red intercambia información periódicamente.
• Byrski and Carvalho (2008). Este modelo se centra en la definición de un comportamiento lícito del activo generado por la monitorización de los procesos y las llamadas a sistema de los equipos. Cuando un proceso se inicia se comparan todas las llamadas a sistema realizadas con las identificadas en el proceso de aprendizaje, de modo que si difieren es posible que se esté produciendo una intrusión. Al margen de esto utilizan el concepto de agentes móviles, capaces de viajar de sistema en sistema examinando las llamadas generadas.

2. Clonación Selectiva

El paradigma de la clonación selectiva simula la replicación de anticuerpos para combatir agentes patógenos. En un ABAIS esto es implementado creando agentes específicos para detectar y defender al sistema ante determinadas intrusiones, de esta manera un elemento especialista de la red es capaz de responder ante un determinado ataque clonándose él mismo y desplazándose hasta el lugar de la intrusión. Dentro de este paradigma encontramos diferentes aproximaciones según autores:

• Machado et al (2005). La detección de la intrusión es realizada mediante el análisis de los logs del sistema utilizando la herramienta Logcheck y apoyándose en Syslog-ng. Cuando una intrusión es detectada el sistema genera un número de agentes móviles que se desplazan al origen del incidente para erradicarlo. Para llevar a cabo esta respuesta se definen 2 tipos de actuación: las pasivas (remitir un email al administrador) y las activas (desplazamiento y eliminación).
• Yang et al (2009). Estos autores introducen el concepto de vacuna, donde dentro de un sistema IDS distribuido, los segmentos de protección que no han recibido la intrusión son “vacunados”, para prevenir ataques exitosos.

3. La teoría de la señal de riesgo

El paradigma de la señal de riesgo o peligro en un sistema inmune hace referencia a la muerte de las células de un cuerpo, bien sea por necrosis o por muerte natural (vejez). En un ABAIS esto se consigue coordinando una serie de agentes detectores situados en puntos distantes de la red capaz de alertar a los miembros del entorno de protección de que se está produciendo cierta amenaza.

• Greensmith et al (2008). Greensmith define dos tipos de nodos capaces de detectar y decidir, en primer lugar, si una alerta debe ser notificada a la red y en segundo lugar de actualizar al resto de elementos con la información obtenida. Estos datos capturados por estos agentes son recopilados en un log centralizado, donde son utilizados para aprender y desarrollar nuevas estrategias de defensa.

Cisco Modular Policy Framework (MPF) es un conjunto de funcionalidades y reglas que nos proporciona Cisco para configurar de forma flexible sus firewalls, pudiendo realizar un filtrado más específico de las conexiones que atraviesan nuestra red.

Habitualmente, cuando configuramos un firewall, solemos centrarnos principalmente en las capas de red y transporte, filtrando únicamente por direcciones IP, puertos, o incluso flags, no obstante, no debemos olvidarnos de que esto no siempre es suficiente, por lo que debemos poder controlar también las capas superiores, pudiendo filtrar por parámetros concretos a nivel de aplicación.

Como ya vimos hace tiempo, Cisco ASA nos da la posibilidad de poder normalizar conexiones TCP, no obstante, es realmente MPF quien hace posible esta normalización, junto con otras funcionalidades avanzadas como comprobaciones a nivel de checksum de paquete, tcp windowing, filtrado de flags, gestión de ancho de banda, o incluso, la posibilidad de hacer un bypass del stateful inspection del sistema. No obstante, para este post usaremos el framework para llevar a cabo una inspeccionar tráfico a nivel de aplicación.

Recordando el post de Roberto sobre la identificación de accesos de logmein, podemos configurar nuestro ASA para filtrar determinados patrones de tráfico a nivel de aplicación; en nuestro caso y para mantener un ejemplo similar, bloquearemos las peticiones DNS a dominios de logmein.com, aunque también se podría inspeccionar el tráfico HTTP para evitar ciertas conexiones.

Para llevar a cabo la inspección DNS, realizaríamos los siguientes pasos (existen configuraciones alternativas):

1. Configuramos una expresión regular que nos permita detectar los patrones de tráfico interesante:

ciscoasa# regex DNSFilter ".\.logmein\.com"

Podemos comprobar si una url hace match con la expresión regular mediante el comando test:

ciscoasa# test regex www.logmein.com .\.logmein\.com
    INFO: Regular expression match succeeded.

2. Configuramos un class-map para identificar el tráfico que queremos inspeccionar:

ciscoasa(config)# class-map type regex match-any DNSFilterList
ciscoasa(config-cmap)# description Dominios Bloqueados
ciscoasa(config-cmap)# match regex DNSFilter

Creando un class-map, podríamos añadir más entradas a la comprobación de expresiones regulares.

3. Creamos un policy-map donde asociamos el anterior class-map para especificar las acciones a llevar a cabo al detectar la expresión regular sospechosa. En este caso, cortamos la conexión y registramos el acceso:

ciscoasa(config)# policy-map type inspect dns DNSInspection
ciscoasa(config-pmap)# parameters
ciscoasa(config-pmap-p)# match domain-name regex class DNSFilterList
ciscoasa(config-pmap-c)# drop log

4. Asociamos al policy-map existente la nueva inspección de tráfico DNS creada en el punto anterior.

ciscoasa(config)# policy-map global_policy
ciscoasa(config-pmap)# class inspection_default
ciscoasa(config-pmap-c)# inspect dns DNSInspection

Puesto que hemos modificado el policy-map creado por defecto, no sería necesario modificar o crear un nuevo service-policy.

Llegados a este momento, si intentamos realizar una consulta DNS (que no esté almacenada en nuestra caché local o en la caché de nuestro servidor DNS) por ejemplo a www.logmein.com, sería filtrada por el firewall, generando el siguiente log:

%ASA-4-410003: DNS Classification: Dropped DNS request (id 24326) from
     inside:10.10.10.20/64355 to outside:8.8.8.8/53; matched Class 23: match
     domain-name regex class DNSFilterList

Donde claramente podremos identificar la IP que lanza la consulta DNS, y también se reflejaría en el debug si esta activado en el firewall:

DNS: === request: Param flags 0x7, match flags 0x10
DNS: Match flags 0x100 rr 1, return 0
DNS: Match dn, list 0xd5711358 entries 1
DNS: Match dn regex, return 1
DNS: Match type 0x1, class 0x1, return 1
DNS: Action 20: matching class 24, DNS Classification: Dropped
DNS: Ques 0: DN: 

Como hemos podido ver, esta funcionalidad nos permite crear nuevos patrones de filtrado acorde a las necesidades de nuestra organización; Veremos otras interesantes utilidades de MPF en el próximo post.