Nota: Esta es una historia real basada en hechos ficticios

Estaba un día trabajando en casa de mi primo y necesitaba acceso a la internet, por lo que obviamente le pedí la clave de la WiFi y de muy buena gana me la proporcionó, a lo cuál le agradecí su tan generoso gesto.

Para proseguir con mi actividad productiva necesitaba redirigir un puerto hacia mi máquina así que, dado que las cualidades técnicas de mi primo no van mas allá del facebook, decidí hacerlo sin preguntar y aquí comienza realmente la historia.

Me conecté al Router y comencé a probar las N combinaciones de cuentas de administrador que me conocía y alguna más que busqué por la web:

Sin resultado satisfactorio, me dirigí a mi primo con la oreja gacha herido en el orgullo hacker para preguntarle el usuario y contraseña, a lo cual me respondió con un “no se de que me hablas”. Perfecto, estaba apunto de arruinar un día entero de trabajo…

El siguiente paso fue intentar escalar privilegios desde una cuenta de usuario para consultar, por suerte éste router tenía la contraseña por defecto user/user habilitada, pero obviamente no permitía cambiar ningún parámetro, primero los pasos básicos para obtener shell de alguna manera:

Vaya por dios, parece que se han tomado en serio la seguridad los que han hecho esta versión de firmware! Pensemos durante unos segundos qué más podríamos probar:

Bingo! Parece que tenemos una manera de ejecutar comandos, sigamos jugando un poco más:

Perfecto, ya tenemos la clave de admin que era lo que necesitábamos; después de preguntar a nuestro amigo John pude redirigir el puerto que necesitaba. Pero ya quee no parece tener la shell disponible facilmente seguí un vistazo a ver qué podemos sacar desde la cuenta de admin.
Como se puede ver a continuación, tiene mucho más comandos, en concreto me llama la atención el comando echo:

Con el comando echo podemos ver la salida completa de los comandos ejecutados! Exploremos a ver que tiene este dispositivo:

Wow, hay un nc por ahí! Podremos usarlo para copiar ficheros dentro y fuera del mismo? Además tenemos un md5sum que nos viene perfecto para ver si la copia ha sido satisfactoria. Probemos con el binario /bin/httpd:

Comprobando en mi PC:

Funciona perfectamente! Probemos a enviar un fichero…

Y en el router:

Ya que tenemos el nc y que andar ejecutando comando a golpe de echo es un poco coñazo, una reverse shell nos vendría de lujo! Let’s try it, primero ponemos a escuchar el nc en el router:

Y después nos conectamos desde el PC:

Yeah! Pues nada, ahí tenemos control total de manera remota y ya podemos seguir jugando más comodamente, aunque eso será para otra entrada en el blog!

No me sigas por la calle! Sígueme por el twitter http://www.twitter.com/gabrielgonzalez

En este post os voy a hablar un poco de como he escrito un motor de análisis de código para x86 y x86_64, de los problemas que me he encontrado y de como he intentado solucionarlos (los que he arreglado, vamos…).

Hace ya algún tiempo que comencé con un proyecto llamado Pyew (similar al todo poderoso radare) el cual está pensado, principalmente, para análisis de baterías de malware. Se podría utilizar el IDA para ello pero, en ocasiones, esta herramienta es un poco pesada y, además, requiere una licencia (no muy barata, por cierto) que no todo el mundo tiene.

Comienzo

Al lío. Para hacer un reemplazo ligero del IDA para analizar malware se necesitan como mínimo 3 cosas:

1. Un cargador de formatos de ficheros: Para PE, ELF, Mach-O o lo que sea que te interese. En mi caso he utilizado Python PEFile para PEs y VTrace para ELFs.
2. Un desensamblador para el procesador: En mi caso, elegí Distorm64 (la versión 2) ya que tiene buen soporte para Python y soporta código x86 de 16, 32 y 64 bits.
3. Un motor de análisis de código: Esta es la pieza clave que no pude ‘coger de por ahí’ fácilmente, sino que me la tendría que escribir desde “0″ (bueno, la verdad es que se podría utilizar radare, pero preferí escribirlo por mi cuenta y aprender algo de paso).

Análisis de código

En este caso, la función que estamos analizando, comienza en la instrucción TEST, en 0xa950 y el bloque básico acaba en el primer salto condicional, en la instrucción JZ (en 0xa957). Ahora tenemos 2 posibles caminos que tomar: en caso de que la condición se cumpla (saltando a 0xa9c3) y el caso contrario, en el cual continuaría con la siguiente instrucción. ¿Cuándo terminaríamos de analizar esta función? Cuando llegamos a la instrucción RET, en 0xa9c4, que es donde acaba el último basic block y ya la función (porque no hay más caminos posibles que seguir).

Grafo de la sencilla función comentada

Mientras vamos siguiendo el flujo del programa descubriendo nuevas rutas de código, guardamos las llamadas a función, las ponemos en una lista y, al acabar con la función actual, se continúa con las funciones (direcciones) que se hayan encontrado. Hasta aquí todo muy bien y muy fácil. ¿Y con esto se descubren todas las funciones y todos los bloques básicos de una función? Ni mucho menos.

Bloques básicos

Antes había dicho que un bloque básico de una función es un conjunto de instrucciones seguidas hasta un salto condicional, no? Bueno, pues no exactamente. Pongamos un ejemplo fácil:

En este caso, en el primer bloque básico llegamos a un salto incondicional (JMP) y, siguiendo ese salto, encontramos después un salto condicional (JLE) a la dirección 0x3d3.  Las instrucciones desde 0x3c5 hasta 0x3d1 y 0x3ef a 0x3f3 no forman un único bloque básico, por una razón: un bloque básico solo puede tener un único punto de entrada. Así pues, lo que inicialmente creíamos que es un bloque básico hay que separarlo en piezas más pequeñas, de modo que cada bloque tenga solo un único punto de entrada (no así de salida). El grafo de flujo para esta función quedaría como sigue:

Grafo de la función con bloques básicos que no cumplen la lóǵica explicada inicialmente.

Ahora ya sabemos como tiene que ser un bloque básico correctamente y, teniendo en cuenta esto, ¿Tendríamos ya un motor de análisis de código funcional? Ni mucho menos.

Punteros a función

Los punteros a función son un quebradero de cabeza a la hora de analizar código estáticamente para encontrar funciones. ¿Porqué? Pongamos un ejemplo con el siguiente código en C:

Si compilamos este código (con GCC en mi caso) se generará el siguiente código ensamblador:

Realmente, no tenemos ninguna ruta de código a esa función así que, siguiendo la lógica actual de nuestro motor, no encontraremos la función “func”. ¿Soluciones? Varias, una de ellas, la más compleja, es trackear los argumentos y sus valores (haciendo una especie de mini-emulación). Si una dirección es pasada como argumento a una función y después se ejecuta esa dirección, pues sabemos que es un puntero a función, así que esa dirección la metemos en la cola de direcciones a analizar y listo.

Sin embargo, esta solución tampoco es 100% correcta. ¿Porqué? Imaginemos que la función que se encarga de ejecutar el puntero que le pasamos está en una librería, no en el binario que estamos ejecutando: como no tenemos el código de la librería (no se encuentra en el binario que estamos analizando) no sabemos que hará con esa dirección que se le pasa. Mi solución para esto es la siguiente: cada  vez que se referencia una dirección a un segmento ejecutable, esta dirección la pongo en la cola para posterior análisis. De este modo, muchas funciones de este tipo se podrían descubrir.

Aún así, tenemos otro problema más: ¿Y si el puntero se calcula en ejecución? Pues estamos jodidos, básicamente. Podemos intentar otras soluciones, como la siguiente.

Prólogos de función

El modo más típico de búsqueda de funciones es la búsqueda de prólogos de función. Por ejemplo, para x86 (32 bits) el siguiente es un prólogo típico:

Podríamos, simplemente, buscar los opcodes de este prólogo de función en los segmentos con permisos de ejecución (no necesariamente, ya que para malware, puede ser que se encuentre código en segmentos que no tienen permisos de ejecución y que luego se copien a una zona de memoria donde sí se tengan privilegios)  y, si esa dirección no corresponde con ninguna función ya analizada, poner dichas direcciones en la cola de análisis. Así se pueden encontrar muchas funciones que de otro modo, probablemente, no encontraríamos.

Pero, como siempre con el análisis de código, esta técnica tiene la oxtia de problemas: ¿Y si los opcodes que he encontrado corresponden a ese prólogo pero realmente no es una función? Este problema no es tan fácil de solucionar, la verdad. Mi solución es seguir desensamblando, buscando si el código tiene sentido (encuentro rutas de código que no se van a casa krixto, encuentro bloques básicos bien formados, etc…). Aún así, esta solución es solo parcial: ¿Qué ocurre si, por casualidad, resulta que encuentro una zona que parece código correcto y no lo es? La posible solución (que en Pyew no la he puesto aún) es asegurarse que el epílogo de función coincida. Esto es, si el prólogo de función típico de x86 es PUSH EBP & MOV EBP, ESP; habrá que buscar su epílogo correspondiente en los bloques básicos de salida, que es LEAVE & RET. Aún así, esto tampoco sería correcto, un ejemplo:

Esto podría ser un código perfectamente válido. La función recibe un argumento y salta inconicionalmente (que no llama) a la dirección pasada más un offset (una VTable, por ejemplo). La función a la que salta es la que, realmente, se encarga de arreglar la pila antes de retornar, es decir, es en esa zona de memoria donde se encuentra el epílogo de función.

De todos modos, vamos a suponer que ‘mágicamente’ tenemos solucionado también este problema. ¿Se podría decir que el motor está finalizado? Ni mucho menos: la búsqueda de prólogos de función es un coñazo porque hay múltiples prólogos de función. Por ejemplo, si desensamblamos ejecutables de Microsoft (librerías de Windows, el notepad, lo que sea) nos encontraremos que los prólogos a función no son como había puesto antes, sino así:

Así que nuestro motor de análisis de código no estaría encontrando el principio de la función, si no que estaríamos saltándonos una instrucción. La solución es buscar más prólogos: en vez de buscar solo PUSH EBP & MOV EBP, ESP, buscamos también con MOV EDI, EDI antes. Pero aún así, no vamos a encontrar todas las funciones del binario. ¿Porqué? Por la convención de llamadas de cada función, entre otras n-mil cosas.

Convenciones de llamada

Cada compilador, arquitectura, etc… tiene una serie de convenciones de llamadas, siendo las más típicas (x86) CDECL y STDCALL. La diferencia principal entre estas 2 convenciones de llamadas es la siguiente: en CDECL es el que llama a la función el que se encarga de restaurar la pila, mientras que en STDCALL es la función llamada la que tiene que restaurar la pila. En ambos casos, el prólogo de función cambiará, así que estamos jodidos.

Por si esto fuera poco, estas 2 no son las únicas convenciones de llamadas existentes. Tenemos otras más, como por ejemplo FASTCALL (la cual, por cierto, es implementada por cada fabricante como se le pone de los huevos), PASCAL, THISCALL o incluso podemos tener convenciones de llamada no estándar que el compilador ha decidido meter “así” porque resultaban más eficientes o usaban menos espacio.

Pero este no es el final de los problemas, aún tenemos otros todavía más gordos…

El coño de la Bernarda (también llamado contrucciones “switch”)

Un switch es una sentencia condicional que en función del valor comprobado tomará una ruta u otra o, incluso, varias. ¿Cómo se imlementa un switch en ensamblador? Cada compilador lo hace como se le pone de ahí. El modo más típico es el siguiente: tener una tabla de offsets a función y llamar a un registro (donde está la dirección de esa tabla) “+” un offset, que sería el índice dentro de la tabla. Este es el modo más típico para un switch medio/grande. Veamos un ejemplo con el siguiente grafo visto en IDA:

Ejemplo de switch sencillo (GCC, 32bits)

Si miramos el bloque básico que tiene varias salidas nos encontraremos con el siguiente código ensamblador:

IDA ha encontrado que la dirección 0×8048670 es una tabla de offsets (direcciones) a los bloques básicos que ha unido después. Es decir, ha encontrado un switch. ¿Cómo lo ha hecho IDA? Analizando el código que se encuentra en ese offset que ha encontrado que luego se accede al mismo por índice (0x0804842E) y que después hay un salto incondicional al valor que haya obtenido. Así que, si nosotros hacemos lo mismo en nuestro motor ¿Ya tendríamos soporte para sentencias switch? Ni de lejos… Cada compilador y cada arquitectura tiene varios tipos diferentes de dialecto de switch. Unos crean tablas como la que aquí se muestra. Otros, lo hacen accediendo a zonas de memoria relativa obteniendo la posición en ejecución. Un ejemplo (escrito a mano, que ahora mismo no encuentro ningún binario):

En este ejemplo, el compilador ha decidido que era mejor (por algún motivo) coger la dirección relativa de la tabla de funciones obteniendo la dirección de la función actual (de ahí el CALL +5 & POP EAX, para saber la dirección de la instrucción que se está ejecutando en ese momento).

Otra cosa que estoy obviando: estoy suponiendo que la tabla donde se apunta a las direcciones de los bloques básicos son contiguas y que son completas, osea, que estará del modo siguiente:

Sin embargo, esto no tiene porque ser así. En muchos casos me he encontrado que lo que realmente hay son direcciones relativas. Es decir, en vez de la dirección virtual completa nos encontramos simplemente el último WORD de la dirección. Por ejemplo, en vez de encontrarte una dirección como 0×08048436, te encontrarías con la dirección 0×8436, a la cual luego se le sumaría la base 0×08040000. O, aún peor, que lo que hay son las diferencias entre direcciones, es decir, el resultado de restar la dirección anterior de la actual. Y así podría seguir hasta aburriros y no acabaría en la puta vida.

Bueno, creo que el post ya es bastante largo así que lo dejo aquí. Espero que os haya gustado!

Hoy, a menos que La Noria lleve a Ortega Cano para que explique cómo matar a alguien y estar en la calle, la pandereta estará sobrevolando “el debate” en breves minutos.

Hace unos meses surgió una nueva polémica política respecto al control de RTVE, si bien ésta era un poco más curiosa. En todas las noticias al respecto veíamos que se mencionaba explícitamente un sistema de generación de noticias para medios de comunicación, que es el estandar de facto de la industria, el iNews.

Me voy a morder la lengua por no hacer lo propio con la yugular de alguno, así que vamos a lo que vamos.

Primero establezcamos el contexto con estos artículos

http://www.rtve.es/television/20110923/comunicacion-sobre-decision-del-consejo-administracion-crtve-programa-inews/463593.shtml
http://www.vayatele.com/profesionales/que-es-inews-y-que-tiene-que-ver-con-el-consejo-de-rtve

Parece que todo el mundo confía en la integridad del acceso al iNews. Asi que me puse a investigar un poco cómo funcionan las “teles” por dentro, en este caso TVE.

Lo primero que hice fue llamar a RTVE e intentar sobornar con donetes a algunos empleados para que me pasaran información. La cosa, incomprensiblemente, no funcionó así que hubo que pasar al plan B: Open Source Intelligence. Es decir, lo de siempre: Webs,comunicados, notas de prensa, pliegos, videos, foros, ir a tomar cafe al mismo bar que suelen ir los trabajadores a poner la oreja o a dejar un pendrive con el logo de TVE olvidado en la barra, etc etc…

He hecho una selección de las fuentes que proporcionan más información:

En esta web http://www.cobdc.net/12JCD/actes/ nos encontramos con 3 documentos interesantes, las presentaciones y papers de “El Gestor de archivo, nuevo perfil profesional en la redacción única de TVE” y “El uso de imágenes procedentes de Internet en los informativos de TVE”

Encontramos informaciones técnicas y operativas interesantes, que nos permiten ir formándonos una imagen del escenario.

http://www.cobdc.org/jornades/12JCD/materials/comunicacions/pres/MEANA_gestor_archivo_nuevo_perfil_tve.pdf

http://www.cobdc.org/jornades/12JCD/materials/comunicacions/MEANA_gestor_archivo_nuevo_perfil_tve.pdf

http://www.cobdc.org/jornades/12JCD/materials/comunicacions/AGUILAR_uso_imagenes_internet_tve.pdf

Los dos últimos ficheros son fundamentales para entender el artículo, así que recomiendo su lectura. Explican la manera de funcionar de las redacciones de TVE, desde el punto de vista técnico y funcional.

Ejemplos de la información extraida

MEANA_gestor_archivo_nuevo_perfil_tve.pdf
“En los SSII de TVE todos los periodistas tienen la posibilidad de trabajar con texto, audio y vídeo en alta resolución. Todos trabajan sobre estas plataformas y elaboran su noticia desde su puesto de trabajo, es decir, escriben texto y después sobre el mismo equipo abren su software de edición que apunta a servidores de vídeo o unidades de almacenamiento compartido donde pueden encontrar las imágenes que necesitan.”

“Sin embargo, en la actual redacción digital de TVE, todo el material que
llega en cualquier formato, se digitaliza, y se introduce en el
almacenamiento compartido junto con los metadatos que lo identifican. Este
proceso de digitalización se llama “ingesta”.”

“El sistema se compone de un gran almacenamiento compartido llamado
ISIS/Interplay (Avid) que contiene todos los materiales con los que se puede
trabajar en un día. Este gran almacén tiene una capacidad cercana a 4.000
horas de vídeo y audio. Desde cualquier puesto de trabajo se puede tener
acceso a este almacén, añadiendo nuevos materiales, ingestando o
descargando contenidos que servirán para elaborar nuevos productos
informativos”

“La Ingesta Central es donde se llevan a cabo las grabaciones de líneas. En
la redacción digital de TVE existe un departamento que graba las señales
externas en ISIS. Utiliza 24 equipos llamados Airspeed (Avid), que se
pueden programar si se trata de envíos periódicos”

“Una vez que el material ha pasado desde los Airspeed a ISIS, el redactor o
el realizador dispone del mismo y pueden editar su noticia o pieza con
cualquier sistema de edición no lineal.
Para el montaje de una noticia, el redactor trabaja con dos aplicaciones
principales:
Instinct e Inews (ambos de Avid) que trabajan en paralelo”

AGUILAR_uso_imagenes_internet_tve.pdf
En el caso de los Informativos de TVE, las tareas estrictamente de ingesta
están a cargo de dos secciones distintas:
- Ingesta Central, encargada de la recepción de señales. Cuenta
para ello con 25 AirSpeed (servidor de ingesta directa de la
empresa Avid).
- Ingesta Local, responsable del resto de formatos que se capturan:
ENG, cintas del Archivo histórico, DVD, CD, Web y memorias tipo
flash. Cuenta con 6 NewsCutter Adrenalin

Esquema 1
Atendiendo a este esquema donde aparece Odetics para el archivo antiguo, deberían tener algo parecido a esto, mola.
http://www.youtube.com/watch?v=9fTJkVgRvpw

Esquema 2

Las imágenes y el texto recopiladas nos llevan a realizar otras búsquedas y averiguar que software, hardware y qué empresas están detrás.

Esta web de la revista de temática audiovisual nos ofrece un artículo con bastante información
http://www.tmbroadcast.es/index.php/tve-hasta-el-infinito-y-mas-alla/
Separándola convenientemente entre Producción, Emisión y Archivo.

Producción
“En la redacción se han instalado un total de 300 clientes concurrentes. La herramienta básica de trabajo para el redactor es Avid iNews Instinct”

Bien, esto cuadra con todo el revuelo organizado en base al control de iNews. Veamos un poco más del iNews en este video (3:05) de La 2 Noticias; Mara Torres invita a David Trueba a dirigir el informativo y donde hablan brevemente sobre este software.

El Famoso iNews

Podemos deducir un poco más de como tienen estructurada la arquitectura, se ve que usan switchs KVM

Emisión
“Como sistema de emisión se ha instalado el sistema ADC-100 de Harris con cliente, Production Client”

Fijaos en la pantalla resaltada, bastante parecida a ésta, perteneciente al BroadcastSupervisor del ADC-100, lo que también cuadra.

La arquitectura vendría a ser así

Podemos observar varios de los elementos que vemos en la foto de La 2.

A más alto nivel

Recapitulando, tenemos que están usando básicamente:

Avid NewsCutter XP
Avid NewsCutter Adrenaline
Avid iNews/Instinct
Avid Media Composer
Avid Interplay
Servers Avid MediaStream
Server Avid Unity ISIS
25 servers AirSpeed
Sistema Harris ADC-100 con el hardware/software asociado

Echemos un ojo al uso de puertos, y por lo tanto funcionalidades, por parte del Software/hardware de Avid http://cdn.pinnaclesys.com/SupportFiles/FAQ_Avid/243397/Port_Usage_Guide_UPDATED_24SEP2009.xls

Es un CTF en toda regla. Cuanto más lejos llegues, más pollas ascii podrás poner en el mapa del tiempo durante el telediario.

¿Cómo de seguro es el iNews?

Con tanto revuelo, que si se puede acceder o no al iNews y ver qué está escribiendo cada periodista, quise echar un ojo a la autentificación al menos.

En principio debido a las características del Software de Avid y los tipos de clientes, es bastante restringido. Aunque haciendo un poco el retard-ninja he conseguido algunos, entre ellos el famoso iNews.

Como hemos visto iNews es un software cliente, y desgraciadamente no tenemos acceso al servidor. Sin embargo, sólo para escarbar la superficie de lo que puede ser, quise comprobar si al menos cifraba las credenciales antes de enviarlas al servidor. Efectivamente no.

Si no tenemos un servidor pues no los inventamos, mejor dicho lo moldeamos. La técnica es útil en estos casos: crear un server dummy, dejar que el cliente iNews -ANWS.exe- hable con nosotros y ver qué peticiones espera. Vamos analizando el parser de paquetes y construimos el servidor según esto, finalmente podemos completar la secuencia y llegar a la autentificación

Básicamente el cliente se comunica con el server, le envía un ‘ping’ y este le dice que acción realizar, sí está disponible o no, seguidamente se comprueban que las versiones de ambos son compatibles y se realiza la petición de autentificación.

Mediante ingeniería inversa vamos analizando las peticiones que espera recibir el cliente y cómo parsea los datos, moldeandonos el server según lo que vemos, que quedaría así.

Fake iNews Server – Testing plain authentication
Britney spears is connected
Receiving PING
‘\x17\n’
OK- Sending LOGIN Request
Receiving CLIENT version
‘#(@) 3.2.5.9 DOS\x00′
Sending SERVER Version
Initiating AUTH request
‘\xfc\x03\x00\x00\xfc\x03\x00\x00′
Completing AUTH request
receiving plaintext user/password…
‘\x05\x81\x81\x00\xfe\x01\x02\x00′
‘\x00\x04\x81\x81\x00\x01\x02\t\x00\xbd\x04\x81\x00\x04\x14\x02a\x00a\x00a\x00a\x00a\x00a\x00a\x00a\x00a\x00a\x00….

Curiosamente tras 3 intentos fallidos de autentificación, el programa muestra un Message Box diciéndote que has agotado los intentos, que te pires y se cierra. Pero teniendo en cuenta que nosotros somos el server y no le hemos dicho nada, la cuenta de los logins fallidos está en el lado cliente.

Lo que no puedo asegurar es si sólo está en ese lado, ya que no tengo un server. Si sólo se mantiene en el client-side además podríamos construir un programa para bruteforcear logins facilmente. La forma de interceptar las credenciales ya dependería de la arquitectura de red.

Los periodistas pueden estar “tranquilos”, a nivel de la aplicación sus credenciales están viajando en texto claro. Vamos que si no oficialmente, ‘extraoficialmente’ en principio no parece muy complicado monitorizarlo.

Bueno, pues ya sabemos algo más de cómo funciona TVE por dentro. Ahora a ‘disfrutar’ del debate, a ver si pasa algo raro…

Si alguno tiene más información o correcciones, escribid un comentario!

Hasta la próxima gorrillas del ciberespacio.

Estamos de acuerdo en que internet es para gatos y ya cada vez menos para ver cosas que son pecado, pero navegando por ahí te puedes encontrar situaciones interesantes.

Lo bonito de eso es que sabes donde empiezas pero nunca donde acabas…Una de estas veces terminé en un sistema “experimental” de una central de cogeneración rumana. Esta de aquí, más concrétamente.

El caso es que un día como otro cualquier me puse a ver que cosas de SCADA había por ahí y acabé en ese sistema, el cual corría un software SCADA cliente/servidor de la empresa http://www.inductiveautomation.com/ .

Tras echarle un ojo, aquello era un coladero por lo que entrar al sistema no era muy dificil. Con todos estos datos avisé al ICS-CERT para, por un lado poner en aviso a los operadores de la central y por otro advertir de las vulnerabilidades al vendor.

De esta manera, los encargados de la central chaparon los sistemas accesibles y la compañia de software arregló un importante fallo que permitía acceder a toda la información del sistema, incluyendo los passwords. Todo el mundo contento, y así yo puedo seguir paseando por Cohlada.

El advisory del ICS-CERT lo podéis consultar aquí http://www.us-cert.gov/control_systems/pdf/ICSA-11-231-01.pdf

Hasta la siguiente.

Hola anonymous y anonymaus,

En la época estival 48bits retorna.

[Música épica] Cuando nadie lo esperaba, cuando todos nos daban por muertos, detenidos o ambas cosas. En esos momentos, vamos y publicamos.

Vamos a ver cómo buscar vulnerabilidades en embebidos, sin necesidad de disponer del dispositivo. En este caso vamos a dar un poco de caña al sistema out-of-band management de DELL. Al lío..

A la hora de enfrentarse a un software/hardware, lo primero de todo es buscar toda la documentación posible sobre el sistema. A partir de la wikipedia podemos acceder a las más importantes, sencillas búsquedas por google arrojan un monton de resultados adicionales:

http://www.dell.com/content/topics/global.aspx/power/en/ps2q02_bell?c=us&l=en
http://en.wikipedia.org/wiki/Dell_DRAC

Hay que tener en cuenta la siguiente cuestión, si bien el código fuente de ciertos componentes del firmware de DELL DRAC están disponibles, DELL admite que no provee ni el entorno para crear un firmware funcional, ni el código de la versión final. Por lo tanto no tenemos acceso al código fuente de las partes más interesantes.

Llegado este punto es indispensable pasar a analizar el firmware y ver hasta donde podemos llegar. Podemos descargar la última versión desde la página de soporte de Dell
http://support.us.dell.com/support/downloads/format.aspx?releaseid=R299265&c=us&l=en&cs=&s=gen

Un zip autoejecutable que nos descomprime dos ficheros, uno de ellos es el firmware “firmimg.d6“, que ocupa 54 megas.

Lo común es utilizar binwalk para ver que contiene. No podemos confiar ciegamente en este programa, basado en firmas, porque en ocasiones da falsos positivos y/o resultados con poco sentido. En cualquier caso es un buen punto de partida.

DECIMAL   |	HEX     |  	DESCRIPTION
--------------------------------------------------------------

512       	0x200     	uImage header, created: Sat Mar 12 21:17:47 2011, image size: 4479904 bytes, Data Address: 0x8000, Entry Point: 0x8000, CRC: 0x1BB8BE08, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: none, image name: arm-linux
12424     	0x3088    	romfs filesystem, version 1 1892957376 bytes, named \240\324<\300hsqs\324\324<\300\177\023.
12436     	0x3094    	Linux Compressed ROM filesystem data, little endian size 3225212064 CRC 0xc03cd538, edition 3225212264, 3225738208 blocks,            3225738220 files
12444     	0x309C    	Squashfs filesystem, little endian, version 54632.49212, 4991 bytes, -1069755180 inodes, blocksize: 56288 bytes, created: Fri Aug 11 04:51:44 2006
103296    	0x19380   	gzip compressed data, from Unix, last modified: Sat Mar 12 21:10:25 2011, max compression

Esto es algunos de los resultados que muestra, de los cuales el único válido es el primero, en el offset 0×200. Primero nos encontramos con una cabecera propia del firmware. Es bastante común encontrarse con una imagen del bootloaderu-Boot (tanto en standalone como imagen de kernel, sobre todo esta última). No nos interesa especialmente en este caso, aunque podríamos debuggearlo a través de qemu-arm-system compilado con soporte para gdb. También podríamos seguir paso a paso la ejecución desde IDA que soporta este modo de debugging.

Con una fichero de firmware de 54 Megas, además de un kernel debemos tener mucha más chicha asi que vamos a buscarlo. Un análisis de entropía del fichero, por ejemplo usando uno de los últimos commits de radare (thx pancake!) “rahash2 -b 512 -a entropy firmimg.d6″ o de forma visual veremos como en torno al offset 0x45b000 empezamos a observar zonas de muy alta entropía lo que suele significar datos comprimidos o cifrados..Buscando en la zona anterior nos encontramos con

Si os fijais podemos identificar el magic de un CramFS “45 3D CD 28″ seguido por “Compressed ROMFS” y nombres relativos a directorios,ficheros… por lo tanto blanco y en botella: previo a la zona de alta entropia tenemos un cabecera de un CramFS legítimo. Por lo tanto, lo que tenemos que hacer es dumpear desde el magic hasta el final y montarlo.

dd if=firmimg.d6 bs=1 skip=4480512 of=tirori.fs
mount -o loop -t cramfs tirori.fs /mnt/drac

Y listo, de esta manera tenemos montado el sistema de ficheros que usa el dispositivo, por lo tanto tenemos acceso a todos los ficheros de configuración, certificados, shadow, demonios… aquí podéis ver el listado http://pastebin.com/Wn10iFf3

Pero podemos ir más allá y emular los ejecutables para poder así buscar vulnerabilidades en los servicios. QEMU soporta dos modos, emulación completa o sólo de user-mode. En este caso lo que nos interesa es emular en la capa de usuario por lo que seguiremos los siguientes pasos.

1. Instalarnos una suite de cross-compiling/debugging ARM como por ejemplo (http://www.codesourcery.com/sgpp/lite/arm/portal/subscription?@template=lite)
2. Cross-Compile QEMU user-mode en éstatico con el target arm
$ ./configure –enable-user –static –target-list=arm-linux-user –enable-debug
3. Activar el soporte en el kernel para otros formatos ejecutables
$ apt-get install binfmt-support
Descargar y ejecutar http://compbio.cs.toronto.edu/repos/snowflock/xen-3.0.3/tools/ioemu/qemu-binfmt-conf.sh
4. Crear /usr/gnemul/qemu-arm y copiar las librerias de /mnt/drac/lib a este directorio.
5. Copiar el qemu-arm estático a /mnt/drac/usr/local/bin
6. Chrootear en /mnt/drac y listo
7. Mapear /proc y /dev en el chroot para poder usar comandos como “ps” y sobre todo permitir a los binarios arm usar /dev/(u)random en el entorno chrooted.
mount -bind /dev /mnt/drac/dev
mount -t proc proc /mnt/drac/proc

De esta manera estamos podemos ejecutar, mediante la emulación que QEMU hace de la capa de usuario, los ficheros del firmware. Esto supone también la posibilidad de debuggearlos mediante gdb en remoto, ya que ptrace no está implementado en la capa de emulación.

(Entorno Chrooted)$ qemu-arm -g 1337 binario
Desde el entorno no chrooted usamos el cross-compiled gdb para arm de la siguiente manera
(gdb) target remote localhost:1337

Por ejemplo, vamos a depurar el servidor web que usan (appweb)

(chrooted) # qemu-arm -g 1337 /usr/local/bin/appweb -r /usr/local/lib/appweb -d /usr/local/www -a 0.0.0.0:8150

(fuera) $ arm-none-eabi-gdb
(gdb) target remote localhost:1337

Tras algo de “stress” los SIGSEGV comienza a aparecer…

Por último, vamos a hacer de esto algo participativo. DRAC permite una serie de métodos de acceso, por ejemplo ssh. Atendiendo a la configuración de PAM
/etc/pam.d
diags
kvm
login other
racadm
sol

sshd
#%PAM-1.0
auth sufficient pam_ldap_manager.so
auth sufficient pam_local_manager.so use_first_pass
auth required pam_auth_status.so
account sufficient pam_ldap_manager.so privilege=0×01
account sufficient pam_local_manager.so privilege=0×01
account required pam_auth_status.so
session required pam_auth_status.so
session required pam_session_manager.so sessiontype=SSH maxsessions=2

telnetd
vm
vmcli
webgui
wsman

Tenemos el /etc/shadow mapeao a memoria flash, pero el shadow por defecto, y que es copiado a la flash por un script en al inicio, está en /etc/default/shadow

root:$1$fY6DG6Hu$OpwCBE01ILIS1H/Lxq/7d0:13502:0:99999:7:::
user1:$1$nVOr80rB$HDAd6FRlG24k/WN4ZuYPC0:0:0:99999:7:::
racuser:!:0:0:99999:7:::
sshd:*:11880:0:99999:7:-1:-1:0

Aunque la documentación avisa que se debe cambiar el password de root, en ningún sitio se menciona el usuario “user1″. Por lo tanto estaríamos ante un usuario backdoor o una cuenta de testing de los developers, el problema es que es altamente improbable que ningún administrador haya cambiado el password o deshabilitado el usuario ya que no pueden tener conocimiento de ella.

A parte de otras vulnerabilidades que podamos encontrar vamos a hacer de esto algo participativo.

Para los ninjas del cracking de passwords (@aramosf puta dale cera) vamos a ver si entre todos petamos los passwords. El premio es acceso al sistema (no hombre, que es ilegal), ¿cómo encontrarlos? Bueno, hay miles en Shodan http://www.shodanhq.com/?q=appweb

Si los sacais, avisad! Hasta la próxima!