¿Se deben usar passwords complejas en la web?

Hace un tiempo escribí un artículo titulado "Hay que acabar con las passwords complejas en los servicios online" en el que venía a explicar por qué creo que el recomendar masivamente a los usuarios que pongan contraseñas complejas en cualquier página web que se registra no tiene sentido. 

Figura 1: Gestión de contraseñas complejas

En aquel artículo recogí mis pensamientos sobre tres ideas principales.

1) Las passwords complejas no defienden de la mayoría de los ataques.
2) El usuario no puede ser el responsable de toda la medida de seguridad/inseguridad. Es decir, no podemos dejar que el usuario sea el determinante de la seguridad como dije en "Mea Culpa, Penny".
3) La mayoría de las medidas de seguridad deben caer de manos del servidor.

En aquel momento no había leído aún algunos trabajos académicos, pero con el tiempo fui descubriendo que a esta conclusión que yo había llegado por mi propia experiencia, hace tiempo que había sido estudiada y documentada en varios artículos que hoy os paso a dejar por aquí.

[1] ¿Sirven para algo las passwords complejas en la web?

Este primer documento recoge la primera de las tres ideas que use como argumento. La mayoría de los ataques que se utilizan en el robo de identidad no se ven afectados para nada si la contraseña es o no compleja. Que sea una password compleja o que no lo sea da exactamente igual.

Figura 2: ¿Sirven para algo las passwords fuertes en la web?

[2] El esfuerzo finito en la gestión de contraseñas que se le puede pedir a un usuario

Este segundo trabajo está centrado en la premisa de que si la seguridad de tu sistema depende de que el usuario haya elegido passwords complejas ese es un escenario poco realista, ya que el esfuerzo de los usuarios es finito y hay, por tanto, que identificar qué grupos de cuentas son en las que se puede exigir una password compleja y en cuál hay que asumir que no. Interesante.

Figura 3: El esfuerzo finito de los usuarios en su seguridad

[3] Las medidas deseguridad del sitio para no hacer necesarias las passwords complejas

En el artículo que yo escribí, decía que debía ser el sitio web el que ofreciera suficientes medidas de seguridad para hacer que las passwords no tuvieran que ser complejas, ya que las identidades estarían protegidas. La lista de medidas que yo enumeré fueron:

a.- Usar un segundo factor de autenticación.
b.- Evitar ataques de fuerza bruta a la password
c.- Evitar ataques de fuerza bruta al usuario
d.- Almacenamiento robusto de contraseñas
e.- Cifrado robusto end-to-end

En el último trabajo de Microsoft que os cito, se vuelve a hablar del poco sentido que tienen las passwords complejas en la mayoría de los escenarios, y lo acaban resumiendo con este cuadro en el que en cada situación, al final, da igual que la password sea compleja o no.

Figura 4: ¿Dónde ayuda algo una password compleja?

Solo en el caso del Offline Guessing Attack cuando el fichero ha sido obtenido por el atacante y el administrador del sitio no lo ha detectado es cuando una contraseña compleja gana algo de tiempo, pero no mucho más.

Al final, si gestionas una larga base de datos de usuarios online, poner un segundo factor de autenticación y una contraseña - como Latch, Verificación en 2 Pasos vía SMS o Google Authenticator - sencilla ayudará al usuario a estar más seguro, a no olvidarse la contraseña y generar problemas de soporte, y beneficiará tanto a la usabilidad como al negocio en general.

Saludos Malignos!

Un misterio criptográfico en la Universidad

Siempre estamos expuestos a cantidades ingentes de información, la mayoría de las veces visual, y sobre todo escrita, aunque habitualmente paseamos por el mundo sin prestarle demasiada atención. Pero, si nos tomamos cuidado para intentar fijarnos en los detalles, a veces nos podemos llevar más de una sorpresa. La siguiente historia es un claro ejemplo de esto, ya que por prestar atención al entorno, acabé involucrado en un misterio de criptografía.

Figura 1: Un misterio criptográfico en la universidad 

Un encuentro fortuito en la Universidad

A principios de este año, caminando por los pasillos de una facultad de una universidad pública conocida tuve la “suerte” de encontrar esto tirado en el suelo, documento que me he tomado la libertad de borrar –de forma muy amateur – algunos segmentos de la hoja para no implicar a las personas de la lista.

A primera vista es una página que podría pasar desapercibida por ser una hoja con los resultados y calificaciones de algún trabajo o examen de la universidad, sobre todo por la estructura y más aún al encontrarse debajo de uno de los tablones que se usan a tal fin. La sorpresa viene cuando te paras a intentar leer detenidamente algo de lo que está escrito en ella, ya que aquello es totalmente ilegible a simple vista.

Figura 2: El extraño documento tirado en la Universidad

Cualquier otro en mi lugar hubiera dejado el papel donde estaba o, al recogerlo y verlo, lo habría tirado a la basura. Pero a mí me picó la curiosidad, así que me lo guardé para “analizarlo” más tarde en casa. El papel me recordó a los problemas y retos a los que jugaba con mi abuelo cuando era más pequeño. Al fin y al cabo, detrás del texto estaba la atracción inherente de todo reto.

Ya que había decidido que iba a jugar con esto, antes de abandonar el lugar de los hechos tuve la precaución de revisar sin éxito el suelo y otros tablones adyacentes para ver si encontraba más especímenes de este tipo, pero no hubo ninguna suerte. Este ejemplar era único en esa zona. Habría que intentar sacar todo lo necesario de allí.

Primeras impresiones sobre el misterio

Una vez en casa, confirmé mi idea de que se trataba de algún tipo de lista de clase: arriba podemos ver el encabezado con los datos de la asignatura y el curso en cuestión, así como el escudo de la Universidad (bueno, lo podríais ver si no lo hubiera eliminado de la imagen). Más abajo encontramos tres columnas, con lo que, a priori, parecen ser nombres y apellidos, DNIs y notas numéricas. El hecho de que el listado central estuviera ordenado alfabéticamente (aunque sin ningún sentido en castellano) reforzaba esta idea. Pero por qué estaba codificado era el misterio.

Como no era el primer documento cifrado con el que me topaba, decidí intentar descifrarlo. No estaba seguro de si un escáner OCR, incluso aplicado al documento original, funcionaría correctamente para pasar los caracteres al equipo y lanzarle baterías de análisis automático, así que primero decidí tratarlo analógicamente, al estilo de mi abuelo con sus acertijos.

Lo primero que se me ocurrió fue someterlo a un análisis de frecuencia para ver qué letras o grupo de letras tenían mayor número de apariciones, pero deseché la idea por dos motivos: primero, que eso solo me serviría con los caracteres alfabéticos, no tendría utilidad ni para números ni para el resto de caracteres como puntos o comas. Y segundo y más importante, me parecía un esfuerzo importante como para hacerlo a mano.

Así que le saqué una foto a la página y la compartí con un grupo de amigos a los que les gustan estas cosas y que a veces tienen muy buenas ideas. Introduje el tema preguntando de qué tenía pinta la hoja, y todos coincidieron en decir que se trataba de un listado de notas de la Universidad (les adelanté que no creía que se tratase de las notas de una asignatura de criptografía, aunque como idea no estaba mal). Algunos sugirieron la posibilidad de que estuviese escrito en otro idioma, aunque seguro que no era así, pues los caracteres pertenecen al alfabeto latino. Les pedí ayuda para resolver el primer reto: decodificar la hoja. Si lo conseguíamos estaríamos un paso más cerca de conocer el resto de detalles al respecto.

Figura 3: Ideas sobre la decodificación del listado

Tras un ratito de debate (en el que surgió la útil pero aburrida idea de usar Haskell para descifrarlo), llegamos a la conclusión de que estaba codificado usando una variación del clásico Cifrado César, en la que en lugar de desplazar cada carácter (ojo, no solo las letras) tres posiciones a la derecha el desplazamiento era de una sola posición. El hecho de que se mantuviese el orden alfabético era una pista importante para ello.

Figura 4: El debate en WhatsApp fue dando ideas

Una vez comprobado que se trataba de ese cifrado (traduciendo algunos segmentos y viendo que en efecto se corresponden con términos en castellano: González, Gómez… Y en efecto la cadena EOJ coincide con las siglas DNI) el siguiente paso era averiguar cómo y por qué. Es decir, la criminalística y la criminología del hecho.

Es un detalle curioso el hecho de que también tanto los números (como se puede comprobar en el encabezado de la hoja, donde se lee Dvstp!Bdbel n jdp!3124.25 – Curso académico 2013,14) como los signos de puntuación estuviesen desplazados sugiere que el cambio se ha hecho sobre una tabla de caracteres, bien en un driver o bien en una tipografía diseñada ad hoc.

Investigación de campo en la Universidad

Para ello el primer paso era analizar en profundidad el contenido de la lista. En efecto se trata de una lista de clase, con los alumnos matriculados en una determinada asignatura ordenados según sus apellidos alfabéticamente. En la primera columna aparecen los DNIs correspondientes, mientras que la última no refleja ni las calificaciones ni los nombres de los trabajos. En su lugar lo que aparece son los usuarios virtuales de cada alumno de la universidad.

Esta información, aunque es fácil de conseguir (pues el algoritmo que se usa para generarlos es unir las tres primeras letras del nombre y ambos apellidos; en caso de conflicto con otro usuario ya existente se añade un contador numérico al final al usuario virtual), se supone privada, de forma que solo tienen acceso a ella el propio usuario y los servicios informáticos y de administración de la universidad (según me contestaron cuando pregunté, hay veces en que ni siquiera los propios profesores tienen acceso a esa información). Por tanto y teóricamente no es algo accesible a todo el mundo (lo que supone, por tanto, una violación – aunque cifrada – de la intimidad de la gente, en especial que la persona responsable dejase el papel tirado en medio del pasillo).

Bien, dicho esto, ese hecho despertó mucho (más) mi curiosidad: si se trata de una información ya de por sí restringida o clasificada, ¿qué sentido tiene codificarla de nuevo? ¿Quién esconde una sala dentro de una base ya secreta? ¿Y a qué fin? Además, para más INRI, usando un cifrado técnicamente tan débil (visiblemente puede que asuste). Por más que buscaba, no le veía sentido.

Cabían dos opciones:

- Que fuese algo involuntario: que se hubiese producido un error en la impresión.
- Que fuese algo intencionado: bien como reto de alguien o para ocultar información.

Investigación de campo en Internet

Investigué por Internet acerca de fallos que ocasionasen el cambio de caracteres en la impresión, pero no encontré nada al respecto. Y la verdad es que me parecía algo bastante extraño como para que no hubiese bibliografía al respecto. También podía tratarse de un virus informático o que la universidad usase un sistema de cifrado digital que deja mucho que desear. En el segundo caso, había tres enigmas que resolver: quién, cómo y por qué.

Dado que, tras mi infructuosa búsqueda por la red, me pareció más probable (e interesante por supuesto) la segunda opción, decidí diseñar hipótesis para la misma.

En cuanto al quién, la cosa era bastante evidente: alguien con acceso a esa información (me parecía muy improbable que alguien hubiese diseñado un ataque dirigido para conseguir tal información, máxime teniendo en cuenta que las contraseña no aparecen – por suerte – en la página). Esto reduce bastante la lista a profesores y miembros de administración (suponiendo que ningún alumno haya hecho un listado de este tipo). Y hace aún más difíciles las respuestas al por qué. ¿Para qué iba a querer un miembro del personal de la universidad codificar una hoja así?

Con respecto al cómo, la opción de hacerlo manualmente siempre está ahí, pero la descarté la primera por tratarse de un trabajo de chinos, como se dice, y muy probablemente nadie se iba a tomar ese esfuerzo para nada. También existía la posibilidad de que alguien hubiese creado una fuente tipográfica con estas características, que se hubiese usado un script para cifrarlo, un programa de cifrado para dummies…

Sin embargo, era el por qué lo que más intrigado me tenía. Un amigo mío, que conoce de mi afición por la criptografía y los juegos de ingenio de este tipo, me sugirió que había encontrado a mi alma gemela en esa facultad: alguien a quien le gustaba resolver enigmas como a mí y que lo había colocado allí a ver si alguien era capaz de resolverlo (lo cual era una idea rebuscada pero que a mí me gustaba bastante). Ese mismo amigo me incitaba a que escribiese un mensaje usando el mismo cifrado diciendo que había resuelto el misterio y lo dejase colgado donde encontré el primero (lo cual era bastante difícil, pues no recordaba dónde había sido). Además, ¿qué mensaje secreto podía haber oculto en una lista de clase?

Una resolución fortuita del misterio

Mi teoría se estaba asemejando peligrosamente a los relatos de misterio de Poe. Incluso llegué a pensar que podía tratarse de algún apasionante reto del estilo del recientemente resuelto Cicada 3301. Finalmente y por motivos de falta de tiempo, deseché esa última opción, aunque me hubiese gustado continuar mis pesquisas por ahí. Así que dejé apartado el asunto durante un tiempo. Hasta que unos meses más tarde, ordenando papeles, encontré con algo que me ayudó a esclarecer el asunto. Di con lo siguiente:

Figura 5: Mi piedra rosetta para este misterio 

En la comparación de ambas páginas se puede comprobar cómo el número de letras, las líneas y la estructura del documento coinciden tanto en la versión codificada como en la que está en cristiano. Este se trataba (el de la izquierda) de un documento que mi padre me imprimió hace unos años, pero que “por error” quedó impreso así, por lo que luego tuvo que hacer una copia nueva (a la derecha). Y mira por dónde, a este documento le sucedía exactamente lo mismo que a la página misteriosa.

Ya me había topado con eso antes, pero nunca le había prestado atención. Hasta ahora. Esta evidencia viene a confirmar la teoría de que se trata de un bug en algún driver de la impresora, ya que el suceso ocurrió en dos sistemas completamente distintos.

Tras reportar el fallo de seguridad al organismo correspondiente de la universidad (el sistema de gestión informática), sin obtener hasta el momento respuesta suya, contacté con Chema Alonso para contarle acerca del misterioso caso; le pareció interesante y me ofreció la oportunidad de publicarlo en un artículo en El lado del mal, por lo que le estoy muy agradecido. ¿Y vosotros habéis tenido alguna experiencia similar? ¿Se os han desordenado las letras al imprimir algún documento?

Un saludo,

Autor: Nacho

Cinco charlas en cinco días en cinco sitios distintos

Esta semana que viene, al final, se me ha complicado un poco más de la cuenta, y terminaré haciendo un número de cosas superior a lo normal. No obstante, como siempre me dices "avísame cuando vengas", pues que no sea por eso.

Figura 1: Lista de actividades para esta semana que entra

[1] Barcelona: Clinic SEO

El lunes 29 de estaré en el Espai Jove La Fontana www.lafontana.org, en la Gran de Gracia 190-192 08012, Barcelona, dando una charla sobre el mundo del Hacking y el SEO. Miguel Pascual dará una charla de Black SEO así que yo hablaré de algunas curiosidades y maldades sobre cómo funcionan los buscadores. Para ir al evento, puedes registrarte en la web del evento: Clinic SEO.

[2] Radio: La Mañana con Javi Nieves

Esto, como todos los martes, será en La Mañana con Javi Nieves, esta vez será el 30 de Septiembre entre las 10:00 y las 10:30. Ya sabes que son solo unos minutos, y que los podcasts luego los suben a la red. 

[3] Radio+Streaming Internet: Yu, No te pierdas nada

El martes por la tarde, también iré al programa de radio de Los 40 Principales de Dani Mateo y compañía, llamado Yu, no te pierdas nada.

Figura 2: Yu, no te pierdas nada en Los 40 Principales

Ese programa además, se puede seguir en directo por streaming de vídeo y con interacción en Twitter. Más información en su web: Yu, no te pierdas nada.

[4] Villaviciosa de Odón (Madrid): Máster Class en la UEM

El primer día de Octubre daré una Máster Class en la Universidad Europea de Madrid sobre riesgos de seguridad por atacantes internos, a la que está todo el mundo invitado. Será a última hora del día para que pueda venir la gente después del trabajo. Eso sí, creo que el aforo es limitado y no había mucho ya. Si quieres venir, tienes más información en la web: Máster Class: Seguridad Empresarial frente a insiders.

[5] Albacete: Navajas Negras

Terminaré la semana el viernes 3 de Octubre en Navajas Negras dando una charla por la tarde titulada "No me indexes que me cacheo" o "No me cachees que me indexo", que tanto monta, tanto, aunque veremos que no es tan así. No la he dado nunca, y ni tan siquiera me ha dado tiempo a terminar el artículo que iba a hacer de este tema para El lado del mal, pero espero que esta tarde me de tiempo a dejarlo todo listo para no desmerecer con tan buen ponente que hay ese día.

Figura 3: El viernes 2 de Octubre en Navajas Negras

Estarán por allí los libros de 0xWord, que podréis comprar en el congreso. Por último, aprovecho para pediros disculpas por anticipado a todos, pues después de mi charla seguramente deba regresar a Madrid, por lo que no tendré mucho tiempo para estar por allí con vosotros. 

Y eso es todo lo que tengo "público" para la semana que viene - además de los artículos que saldrán por El lado del mal -, así que si que si quieres apuntarte a algo, ya sabes dónde puedes localizarme.

Saludos Malignos!

ShellShock puede afectar a tu web, tu Linux, tu Mac OS X, tu router, tu punto de acceso WiFi o tu switch

A mediados de esta semana se ha hecho público un fallo de seguridad, al que se ha llamado ShellShock, en la popular interfaz de comandos Bash que afecta a todas las versiones lanzadas desde Bash 1.14.0 hasta Bash 4.3, o lo que es lo mismo, a todas las versiones desde el año 1994 hasta el reciente parche que se ha publicado dentro de las últimas 48 horas. El bug, que realmente son dos, tienen los CVE-2014-6271 y CVE-2014-7169 y afectan a sistemas UNIX, Linux y OS X que tienen instalada esta herramienta en sus plataformas.

Figura 1: ShellShock bug en Bash 1.14 hasta Bash 4.3

Comprobar la versión de tu sistema es fácil, solo necesitas usar el comando help y te dirá la versión de la bash que estás usando. En el caso de los usuarios OS X la versión que se distribuye con la última versión es la 3.5.2, así que todas las versiones de sistemas operativos de Mac OS X desde su concepción están afectados por ShellSock.

La forma de comprobar con una prueba real si tu sistema es vulnerable es bastante sencilla, solo debes irte a tu interfaz de comandos Bash y probar a declarar una función como una variable de entorno, pero añadiendo después de la definición un comando a ejecutar. En este ejemplo un comando para que muestre el mensaje de Owned. Luego se invoca bash para que cargue las variables de entorno y la ejecute el comando.

Figura 2: Test de ShellShock en Bash de OS X

Explotar este bug tiene muchas posibilidades, pero es especialmente peligroso en los servidores web que utilizando el motor CGI (Common Gateway Interface) se apoyan en el sistema operativo para dar sus servicios web. Es decir, a diferencia de las aplicaciones .NET, JSP o PHP que se basan en la interpretación por parte de un motor de scripting de las programas que forman la web, las aplicaciones CGI se tiran directamente con ejecuciones desde el sistema operativo, lo que permite interactuar con el interfaz de comandos, sea SH, KSH o Bash.

Recordaréis que hace unos años hubo un bug casi igual de serio con PHP corriendo en modo CGI, donde se podían inyectar comandos en la llamada de PHP, y eso podría permitir ejecutar una Shell en el sistema para controlar todo desde una WebShell. Esto mismo se puede hacer ahora, aprovechando la definición de variables que se haga en la aplicación CGI ya sea llegando a ella por cualquiera de los parámetros que se envíen por GET o por POST, o por cualquiera de los datos de entrada, como por ejemplo el USER-AGENT o las Cookies.

Figura 3: Test de variables de entorno en webs CGI

El valor de USER-AGENT es un campo de entrada que habitualmente se usa en las aplicaciones CGI para definir variables, tal y como te puedes encontrar en muchos test.cgi por Internet. Manipulando el valor del USER-AGENT es posible meter una webshell con el bug ShellSock, tal y como se ha publicado en el blog de Eleven Paths para explicar la peligrosidad del sitio.

Figura 4: Subida de una WebShell a un servidor web vulnerable a ShellShock

En nuestro sistema de pentesting persistente Faast, metimos un plugin de detección de ShellShock - al igual que tiene el de PHP en modo CGI, HeartBleed y cientos más - a las horas de que se hiciera público el bug, para avisar a nuestros clientes que están siendo monitorizados de en qué servidores se encuentra. Tuvimos que afinar bastante para poder resolver el Error 500 del que tanto se habla por ahí, pero conseguimos un plugin de detección de lo más estable.

Figura 5: Plugin de ShellShock en Faast ejecutnado shell

a que este bug te lo puedes encontrar en el sitio menos inesperado de tu infraestructura, como por ejemplo el panel de administración de un router, un switch o un punto de acceso WiFi que, tan comúnmente, cuentan con este tipo de paneles de administración web.

Figura 6: Búsqueda de paneles web CGI en Shodan

En ellos, con el objeto de reducir al máximo el software a instalar, la mayoría de los paneles están corriendo en CGI. Basta con darse un paseo por Shodan y con las consultas adecuadas localizar paneles de administración web expuestos a Internet, corriendo con una Bash vulnerable que da soporte a webs funcionando en modo CGI suficientes como para que la NSA y su programa de hacking de routers, switches y electrónica de red se ponga las botas, pero que si no tienes cuidado puede poner en riesgo también tu red WiFi a visitantes no deseados. No te olvides de ellos.

Saludos Malignos!

Retromalware: Detecta y Controla NetBus con Metasploit

En el año 1998 el mundo de la informática conoció el troyano NetBus. Esta pequeña aplicación fue lanzada como una herramienta de administración remota de máquinas, aunque existían algunas versiones más oscuras que eran utilizadas por atacantes para troyanizar máquinas. Yo dediqué tiempo a jugar con NetBus cuando iba al instituto, allá por el año 2001, pero eso es otra historia. En verano me dio por trastear y sacar del baúl de los recuerdos a software que hoy en día tienen poca aplicación, ya que son desbordados por otras herramientas con mucho más poder, pero apareció de nuevo el NetBus.

Figura 1: NetBus 1.70

Decidí echarle un ojo, y ver cómo los creadores de malware de la época hacían para transmitir la información y las órdenes desde un cliente a un servidor. Hay que recordar que el malware de aquella época seguía una arquitectura cliente-servidor clásica. Cuando mandaban el fichero patch.exe (servidor de NetBus) a una víctima ésta disponía de una dirección IP, la cual era una dirección pública. Esto hacía que cualquier usuario pudiera tener conectividad directa con dicha máquina. Después aparecieron los routers y la idea tuvo que cambiarse y ser el “bicho.exe” el que haga la conexión reversa a la máquina del atacante.

Fase 1: Detectando un NetBus

Echando un ojo con un Wireshark a la interacción entre el cliente y servidor en una red me llamó la atención la facilidad con la que NetBus se identificaba.

Figura 2: Tráfico de conexión a un servidor NetBus

En la imagen se ve como el cliente, en este caso una versión 1.60, realiza la conexión con el servidor (three-way handshake) y el servidor “escupe” un segmento con datos. Parece que el servidor muestra el banner, como si de otro servicio normal se tratase. Con Wireshark podemos ver que nos dice la versión a la que nos hemos conectado.

Figura 3: Versión de NetBus en el paquete de datos de conexión

Al ver esto, y viendo que el verano por el norte no ha sido muy productivo a lo que horas de sol se refiere, me puse a trastear con Ruby. Muchos saben que desde el libro de Metasploit para pentesters un servidor anda con ganas de ir haciendo más y más cosas para el framework, aunque no todo lo que me gustaría debido al poco tiempo libre. Para pasar el rato decidí codificar un script en Ruby para, dándole una dirección IP, detectar un NetBus y su versión.

Figura 4: Código en Ruby para detectar versión de NetBus

En el código, muy sencillo, se puede ver como se abre un socket contra una Dirección IP y un Puerto que, en la versión 1.60 de NetBus es el 6000, es por el que se gestiona. Tras abrir el socket esperamos a recibir un “\r” que es el delimitador que utiliza NetBus, algo que también se puede obtener del mensaje mostrado con Wireshark anteriormente. En él se puede ver que cada comando o información enviada acaba con un “\r”, en hexadecimal 0d.

Fase 2: Implementando el comando GetInfo de NetBus

Si lo que recibimos por el socket encaja con la expresión regular definida para localizar un banner de NetBus se imprime por pantalla la versión. Como se puede imaginar esto es algo bastante rápido de montar, y el sol seguía sin salir por el norte así que decidí ir un poco más allá.

El cliente de NetBus tiene diversos botones que permitían al atacante hacer maldades sobre sus víctimas. Pero, como ya hemos visto antes, la comunicación era trivial, el texto plano es la clave. Al probar el botón de Get Info, el cliente obtiene algo de información de la máquina remota, por ejemplo el Usuario con el que se está conectado en el sistema operativo, la ruta dónde se encuentra el patch.exe o el número de clientes conectados. Si observamos la trama en Wireshark veremos que el comando no puede ser más sencillo “Get Info”, escrito a través del socket, eso sí, que no se nos olvidé el 0d al final, o lo que es lo mismo “\r”.

Figura 5: Trama de red del comando "Get Info" en NetBus

Tras ver esto quise interactuar con el bicho a través del script, era como meterle mano al juguete que tenía de pequeño. El código al final era algo así:

Figura 6: Código para lanzar un Get Info desde Ruby

Es sencillo, si el socket está abierto se manda por él el texto GetInfo con el delimitador 0d al final y esperamos a que patch.exe nos proporcione la información. Una vez recibida, la damos un poco de format sustituyendo los ";" y "|" por saltos de línea y después se muestra.

Fase 3: Controlando NetBus con un módulo de Metasploit

Seguí investigando y jugando un poco con el troyano e implementé también la posibilidad de enviar texto a la víctima, recopilar información sobre el disco duro, por ejemplo listar todos los archivos y carpetas, y la posibilidad de ejecutar un message box en remoto, así que me cree un menú con las opciones de control del troyano que quería implementar y empecé con este proyecto personal de verano para crear un programa en Ruby para controlar NetBus que podéis descargar desde aquí, aunque como salió el sol por el norte y decidí que las vacaciones eran para coger algo de color y lo dejé para el siguiente día.

Figura 7: Panel de control para NetBus

¿Segundo día y también llueve? En efecto, llover y mucho llover por el norte en mis días por allí, por lo que decidí llevar mi pequeño script al mundo Metasploit. Mi idea era hacer un módulo auxiliary, mi prueba de concepto, más didáctico que efectivo en una auditoría, aunque módulos en Metasploit que detectan malware o que detectan paneles de gestión existen. Si visualizamos la ruta modules/auxiliary/scanner/misc podemos encontrar los módulos en Ruby que comentaba. Apoyándome en un módulo scanner el cual ya nos proporciona la posibilidad de escanear rangos de direcciones IP quise implementar la funcionalidad que tenía en mi script anterior.

Figura 8: Módulo NetBus Detector para Metasploit

Es importante observar los mixins que se incluyen con Tcp, scanner y report. Un mixin es una llamada a un método que es proporcionado por otra clase y que simplifica las tareas que realizamos. Por ejemplo, en el caso de Tcp se nos proporciona connect() y disconnect(). Con la primera se crea un socket contra el puerto y dirección IP que toque, recordemos que un módulo scanner coge rangos de direcciones IP y mediante un bucle se van recorriendo estas direcciones IP. El mixin disconnect() nos permite cerrar el socket. Más adelante en este artículo se muestra una zona de código dónde se pueden visualizar tanto el connect() como el disconnect(). La función initialize que todo módulo debe incluir permite inicializar el módulo cuando éste es cargado en el framework. Podemos ver que existen ciertos atributos que se configuran a modo informativo sobre el nombre del módulo, autor, tipo de licencia, etcétera. Esta información puede ser visualizada en msfconsole a través del comando info.

Figura 9: NetBus Detector cómo módulo MetasPloit

Por último, la función initialize tiene una llamada importante que es register_options. Con este método podemos incluir o sobreescribir nuevos atributos o parámetros del módulo. En este caso se indica que el parámetro RPORT por defecto tiene el valor 6000, que como hemos podido ver es un puerto en el que NetBus trabaja. Si decides implementar tus módulos utilizarás esta llamada en algún momento.

Al final la otra función que debe tener un módulo de Metasploit de tipo auxiliary es la de run_host. En esta función se le pasa el target_host, que simplemente será la dirección IP que toque ser escaneada. En otras palabras, como es un módulo auxiliary y de tipo scanner, de forma trasparente al programador el framework le proporciona un bucle que va ejecutando esta función, siendo en cada iteración un target_host distinto. También otra opción viable es la utilización de un número mayor de THREADS, ya que por defecto es 1. Esto también es trasparente al programador gracias al framework, por lo que podemos lanzar distintos hilos que el programador no tendrá que realizar la gestión ni de esto, ni de la llamada a run_host con distintos valores.

Figura 10: Código del módulo auxiliary de NetBus Detector

Como se puede ver en la definición de la función run_host se abre un socket a través del mixin connect. Una vez abierto el socket se espera que patch.exe, el bicho de NetBus nos envíe su versión. Tras esto se imprime la por pantalla que se ha encontrado en una dirección IP una versión de NetBus. En este punto se podría utilizar una expresión regular para asegurarnos que lo encontrado es lo que buscábamos. En el momento que se encuentra una dirección IP infectada se muestra un menú al usuario para que interactúe con él. A modo de prueba de concepto se han implementado algunas funcionalidades para manejar el troyano.

Figura 11: El panel de opciones de NetBus Detector para controlar NetBus desde Metasploit

A continuación podemos ver cómo se puede lanzar un message box sobre la máquina infectada. Realmente se ha implementado un mini cliente de NetBus en esta prueba de concepto. Posteriormente se muestra la captura dónde se recibe lo que ha pulsado el usuario víctima.

Figura 12: Un mensaje enviado con NetBus Detector desde Metasploit

Por último, quiero mostraros una función interesante como es el listado de ficheros que se encuentran en el disco de la víctima. Tras analizar con Wireshark cómo realiza esta operación paso a comentarla. El cliente legítimo manda un “GetFiles” a través del socket abierto en el puerto 6000, el servidor nos contesta con “DiskDone” y nos indica un tamaño en bytes de lo que ocupa toda la información (textual) que recibiremos. Después de esto, el cliente legítimo abre un segundo socket al puerto 12346 y es dónde tras abrir la conexión se recibe toda la información del disco duro.

Figura 13: Datos de DiskDone

Tenéis disponible el código en mi github NetBus Detector para poder trastear con ello un rato y poder evolucionarlo. Si quieres aprender más sobre Metasploit y un poco del desarrollo en el framework os invito a leer "mi libro" de Metasploit para pentesters.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor del libro "Metasploit para Pentesters"

Un fallo de CSRF en Twitter para robarte la cuenta

Los ataques de CSRF (Cross-Site Request Forgery) son conocidos hace bastante tiempo. La idea de ellos es bastante sencilla, y el objetivo es conseguir que una víctima, que tiene una sesión con su cuenta en un sitio web, haga acciones involuntarias en esa sesión al abrir un enlace o cargar un contenido externo.

Figura 1: Un bug de CSRF para robare la cuenta de Twitter

A día de hoy es una de las técnicas de hacking más utilizadas, y en el proyecto OWASP TOP TEN, que recoge los diez ataques más utilizadas en ataques a aplicaciones web y donde siguen reinando las técnicas de SQL Injection y el resto de inyecciones de código, ocupa el octavo lugar. 

Una explicación sencilla de CSRF

Para que sea fácil de entender en que consiste el ataque, vamos a suponer una aplicación web para controlar las nóminas de los empleados de una empresa. A esa aplicación web solo puede entrar el administrador y es tan absurdamente sencilla como que hay una lista con los nombres de los empleados junto con dos enlaces a su lado. Uno es un enlace que poner "Subir Sueldo" y otro es un enlace que pone "Bajar Sueldo". Esa aplicación web es tan absurdamente sencilla, que si miramos el código de los enlaces son algo como:

- http://www.server.test/subir_sueldo.php?trabajador=chema
- http://www.server.text/bajar_sueldo.php?trabajador=chema

Cuando se llaman a esos enlaces, lo que sucede es que automáticamente se incrementa o decrementa el sueldo de ese trabajador, en este caso chema, en la base de datos del sistema. Por supuesto, por protección, para que nadie pueda hacer uso de esos procedimientos de incremento y decremento, las aplicaciones subir_sueldo.php y bajar_sueldo.php comprueban que la persona que está enviando esa petición está autenticado como administrador, para lo que es necesario tener una sesión abierta.

El ataque CSRF se aprovecha de esa construcción insegura de enlaces dentro de la aplicación de administración. Es cierto que solo el administrador puede invocarlos, pero si el administrador tiene abierta esa aplicación en una pestaña de su navegador, y en otra tiene abierto  su correo electrónico, bastará con enviar un enlace a http://www.server.test/subir_sueldo.php?trabajador=chema para que haga clic en él para que se ejecute la acción. Si el administrador lo pulsa dentro del correo electrónico, entonces se ejecutará la orden de subir el sueldo a chema.

Esa es una forma muy "burda" de conseguir explotar el ataque, pero lo cierto es que si trasladamos esto a enlaces enviados por Twitter o Facebook o simples mensajes de correo electrónico escritos en HTML que cargan la imagen haciendo uso de img src="http://www.server.test/subir_sueldo.php?trabajador=chema". 

Figura 2: En el año 2007, el propio Gmail fue víctima de un ataque CSRF que generó un gusano

O mucho peor, imaginad que yo sé que tenéis abierto el Twitter en otra pestaña mientras veis este artículo de El lado del mal y cargo un fichero JavaScript malicioso que, usando vuestra sesión de Twitter, empieza a obligaros a publicar cosas, hacer seguimiento a personas o peor, os cambia la contraseña. Esto no podría ser. Sería un desastre.

Protecciones Anti CSRF

Para solucionar esto, se crean las protecciones Anti-CSRF, que consisten en un control del servidor a la hora de controlar desde donde viene hecho el clic. Es decir, en cada enlace que se muestra en una web, o en cada formulario que se carga en una página para que el usuario puede pulsar se genera un token, que se asocia a ese, y solo ese enlace, de tal manera que cuando el usuario hace clic en él debe ser enviado a al servidor junto con el enlace. 

Figura 3: Ejemplo de protección anti-CSRF propuesta en OWASP

En el ejemplo de subir el sueldo, se debería poner algo como http://www.server.test/subir_sueldo.php?trabajador=chema&csrfToken=14123423234234. Esto ayudaría a que si el atacante envía un enlace malicioso deba conocer cuál es el valor del token CSRF válido para la ejecución de la aplicación subir_sueldo.php. Si no lo averigua, el servidor no ejecutará el comando. Por supuesto, la recomendación es no usar esos tokens CSRF en peticiones GET, ya que los tokens quedarán en historiales de navegación, servidores Proxy, Firewalls, sistemas de registro de eventos, etcétera, por lo que lo mejor es hacerlo cambiando el enlace por un formulario.

El bug de Twitter

Esto es algo que hacen casi todos los sitios webs, y entre ellos se encuentra Twitter. Pero... nada de esto vale, si en el servidor no se valida correctamente el token CSRF. Si se envíe el token que se envíe da lo mismo, entonces volvemos a tener ese problema de que cualquiera pueda hacer lo que le de la gana con tu cuenta si la tienes abierta en otra pestaña.

Figura 4: Token Anti-CSRF en el formulario de añadir número de teléfono a cuenta de Twitter

Este es el caso del formulario que permite añadir un número de teléfono a tu cuenta de Twitter como protección, que tal y como podéis ver en el código fuente, cuenta con un token de protección anti-CSRF llamado authentiticity_token, pero... que se olvidó de validar.  Este bug fue descubierto por el investigador colombiano Juan David Castro Dylan Irzi, y lo presentó en la pasada DragonJar Security Conference 2014, con una conferencia que puedes ver online sobre ataques CSRF en general. 

Figura 5: Conferencia de Juan David Castro sobre ataques CSRF

En el caso concreto del ataque de Twitter, para robar la cuenta, lo que hay que hacer es enviar un enlace a la víctima. Cuando ella lo abra, se ejecutará el envío del formulario para añadir un número de teléfono a la cuenta de la víctima, tal y como se puede ver en el exploit que publicó. En él, authenticity_token está a null, porque Twitter no lo estaba validando.

Figura 6: Exploit para añadir el número de teléfono sin token CSRF

A partir de ese momento, la cuenta de la víctima estará asociada al número de teléfono del atacante, que podrá robar vía formulario de recuperación de contraseña. Para ello, basta con que el atacante solicite que se le envíe un código de recuperación de cuenta por SMS al número que está asociado a la identidad - que acaba de poner con el exploit de CSRF -. El vídeo completo de la prueba de concepto de cómo se puede robar una cuenta de Twitter por medio de un bug CSRF está disponible en el siguiente vídeo.

Figura 7: Prueba de Concepto de cómo explotar CSRF en Twitter y robar la cuenta

Por supuesto, Juan David Castro lo reportó a Twitter, que lo solucionó y puso en el Hall of Fame por ayudar a que los usuarios no estuvieran expuestos con este bug que en malas manos podría haber hecho mucho daño. Un hacker que encuentra un bug y lo reporta para que los usuarios no estén expuestos sin esperar nada a cambio. Buen trabajo Juan David, tienes mis respetos.

Saludos Malignos!

Crear una JavaScript Botnet con dispositivos Android

El día 1 de Septiembre se hizo noticia la vulnerabilidad publicada por el investigador Rafay Baloch detectada en dispositivos Android previos a la versión 4.4, que había sido identificada con el CVE-2014-6041. En ésta se reporta que el componente WebView de versiones anteriores al framework 4.4 permiten la evasión de su mecanismo de seguridad SOP (Same Origin Policy o Política del Mismo Origen), que es un control que deben implementar los clientes web para limitar que sólo ante determinadas circunstancias un documento web pueda cargar o modificar código en otro si estos están ubicados en orígenes diferentes.

Figura 1: Dispositivos Android vulnerables a bug del XSS Universal

El alcance de esta vulnerabilidad es notable ya que se estima que actualmente en torno al 75% de los dispositivos Android se encuentran en versiones anteriores a la 4.4, y en estos dispositivos suele estar instalado de serie el cliente Web Android Open Source Browser, el cual implementa este componente WebView vulnerable, y además el bug no se reduce únicamente a este componente, ya que como se ha hecho público en otros estudios realizados existen más clientes web vulnerables como Maxthon Browser o CM Browser.

Figura 2: Cuota de mercado de versiones de Android

En cuanto a la vulnerabilidad reportada, cabe destacar lo simple que es realizar una explotación como Prueba de Concepto ya que lo único que hace falta para evadir el SOP en este componente es incluir un byte nulo en un manejador con el código que queremos ejecutar en el contexto del origen de destino:

Figura 3: Inserción del null byte \u0000 para lograr el salto de SOP

Si accedemos a la página con el código anterior desde un navegador que contenga este componente vulnerable veremos cómo somos capaces de ejecutar el script insertado en el manejador onclick.

Figura 4: Código ejecutado saltándose la política SOP

Este método podría ser usado tanto para extraer información como el contenido HTML de una página web desde la sesión de un usuario, el envío de formularios sin el consentimiento del usuario, o  ataques de session hijacking, entre otros.

Figura 5: Explotación del bug desde Metasploit sobre una distribución Kali Linux

Sea como sea la historia de esta vulnerabilidad no acabó en su publicación y desde el día 7 de Septiembre disponemos de un módulo para Metasploit que en su configuración por defecto extraerá la cookie y el contenido HTML que el usuario ve al acceder a la página web.

Figura 6: Extracciíon de la cookie de sesión con el módulo de Metasploit

Es interesante destacar las opciones adicionales que incluye el módulo, ya que nos permitirán jugar con certificados, ejecutar nuestro propio código script si lo definimos en la opción del módulo CUSTOM_JS. Es en este punto donde los más juguetones están aprovechando para mediante una campaña, por ejemplo de spam enviado a usuarios de versiones Android vulnerables, cargar otros scripts tan interesantes como BeEF para hacerse una JavaScript Botnet de dispositivos Android, además de ofrecer otros mecanismos menos sutiles para hacer por ejemplo evasión de las cabeceras X-Frame-Options.

Figura 7: Inyección de scripts personalizados de control

Si a este grave fallo de seguridad le sumamos la fragmentación de la plataforma Android y el abandono por parte de proveedores de dispositivos y adaptaciones del sistema operativo, nos damos cuenta de que estamos ante una situación muy complicada ya que aunque se han publicado parches para corregir este fallo (aquí y aquí) un alto porcentaje de dispositivos no serán actualizados y mantendrán esta vulnerabilidad.

Autor: Miguel Ángel García (@nodoraiz)
Developer en Eleven Paths

Innovation Meets Security: ¡Reserva hoy tu plaza hoy!

En el evento del año pasado, desde Eleven Paths y Telefónica presentamos la oferta de nuevos productos y servicios de seguridad, donde desvelamos por primera vez Latch en Diciembre de 2013. Ahora, el próximo 16 de Octubre de 2014 es es el día que hemos elegido para el evento global de Innovación y Seguridad que organizamos este años desde Eleven Paths en conjunción con Telefónica.

Figura 1: 16 de Octubre - Madrid: Innovation Meets Security

Este evento es muy especial para nosotros, ya que dentro del ADN de Eleven Paths está la innovación constante, así que para este día os contaremos en qué hemos estado trabajando para mejorar todos nuestros productos y servicios, además de contaros cómo vemos las amenazas y la seguridad en el futuro.

Como os podéis imaginar, para este día hemos guardado muchas sorpresas, y os contaremos en un evento de tarde todas ellas - o al menos todas las que ya os podamos contar -. A día de hoy no os puedo avanzar demasiado ya que queremos que sea allí el día del evento cuando se cuenten, pero sí que os confirmo que habrá un proyecto completamente nuevo en el que hemos estado trabajando a lo largo del último año, llamado Path 5, y que lo hemos guardado como colofón del evento. Hemos hecho una agenda, lo suficientemente genérica para que sepas más o menos de que vamos a hablar, pero no hemos querido desvelar aún los detalles.

Figura 2: Agenda descriptiva del evento Innovation Meets Security

El evento está dirigido a responsables de seguridad,  profesionales de seguridad de la información, CISOs, CSOs y Administradores de IT. Hemos reservado el Auditorio principal de Telefónica en el Edificio Central del Distrito C de Las Tablas, pero el año pasado tuvimos más peticiones de asistencia que plazas, así que si quieres venir Reserva ahora mismo tu plaza en la web del evento: Innovation Meets Security. Te confirmaremos lo antes posible para garantizar que no tienes problemas para asistir.

Saludos Malignos!