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!

Desde 48bits os deseamos unas felices comilonas y un próspero loquesea.

Quiero ambientar este post con una canción de la página revelación del 2010, ano.lolcathost.org

Su título es “Miau, Miau”, letra a cargo de Alejandro Sanz y el fulano de Jarabe de Palo. La música fue compuesta por Luis Cobos.

Según los autores “con esta canción queríamos expresar nuestra consternación por todo lo que vemos en la tele y la gente nos cuenta en facebook: los superpobres que son muy pobres ¿sabes? la falta de berberechos humanos en China, el cambio simpático y los tierramotos de Haití. Sin olvidarnos de cómo nos vemos obligados a beber agua del grifo debido a la pirateria.”
Pulsa para escuchar el hit de las navidades: “Miau Miau”

Al lio…

Hace aproximadamente 3 años que vendí a ZDI un fallo en la implementación RPC de los productos IBM U2 (Universe y Unidata).

About InterCall
InterCall is an API (application programming interface) that enables a UNIX or Windows client to access data on UniVerse and UniData servers. With InterCall, your applications can:
Connect to one or more servers
Access files and records
Execute database commands and UniVerse BASIC programs On Windows platforms, you can write applications for client programs using any development tool that accesses DLLs, for example, Visual Basic, C, or Visual C/C++. On UNIX, you can use any tool that accesses static libraries, typically a C compiler

Minimum System Requirements
To run InterCall applications, you need the following:
On a UNIX server:
UniVerse Release 8.3.3.1G or later, or UniData Release 5.1 or later
TCP/IP
UniRPC daemon (unirpcd) running
On a Windows server:
UniVerse Release 9.3.1 or later, or UniData Release 5.1 or later
TCP/IP, if connected to a UNIX client
TCP/IP or LAN Manager, if connected to a Windows client
UniRPC service (unirpc) running
{…}
bin/unirpc32.dll A DLL used by InterCall applications at run time.

El fallo, un integer overflow de libro, se producía en la función uvrpc_read_message:

En este punto, si el tamaño era mayor el server necesitaba más memoria para albergar el paquete

pero si no llamaba a recv con el buffer por defecto hasta completar la recepción del paquete usando el valor de longitud que nosotros enviamos en el paquete, no el que él calculó.

El problema está en que al ser una comparación con signo , si el valor que nosotros le pasamos + 0×18 que le suma él, es un número negativo, nos saltaremos el check.

Ejemplo:
fake_size = 0x7ffffff0 :: Es > 0
+ 0x18h = 0×80000008 :: Ahora es < 0 asi que fake_size < nNumberofBytesToRead
entonces
n=recv(socket, buffer, fake_size-(n), flags)

Simple PoC

Lo curioso de este caso es que IBM vendió esta rama de productos a la empresa Rocket. Estos por tanto heredaron el bug que todavía no había sido parcheado. Finalmente, hoy ha sido liberado el parche y el advisory de ZDI. El tiempo transcurrido entre una cosa y otra ha sido de casi 3 años. Yeah.

La historia de esta rama de productos la podéis leer en Wikipedia http://en.wikipedia.org/wiki/Rocket_U2

ZDI Advisory http://www.zerodayinitiative.com/advisories/ZDI-10-294/

El modo en que funciona la arquitectura de los ActiveX y sus métodos de securización, muy ligados al dominio dentro del cual se está instanciando, hacen del XSS un vector de ataque muy potente. Esto lo demostré en la pasada RootedCon, donde un fallo de diseño permitía controlar por completo una máquina usando un ataque XSS en conjunto con métodos potencialmente inseguros en un ActiveX. Es conveniente recordar las slidespara entender mejor este post.

Hoy, vamos a hablar de un fallo del mismo tipo en la arquitectura de la Agencia Tributaria española.

El escenario del ataque sería aquel donde la víctima pincha, por el medio que sea, un enlace especialmente creado. Una explotación exitosa acarrearía la posibilidad de que el atacante obtuviera acceso a los datos fiscales, facturas u otros ficheros de la víctima, pudiera modificarlos e incluso ejecutar código.

Disclaimer.
Quiero dejar claro, para que nadie piense nada raro, que a mí sólo me interesa lo que se ejecuta en mi ordenador. No he tocado ningún servidor de la AEAT, ni ganas tengo. Recordar así mismo que un XSS se ejecuta en el lado cliente. Si por obligación se me conmina a instalar un ActiveX quiero saber por qué, qué hace y si esto supone un riesgo para la seguridad de mis equipos.No me hago responsable de ninguna manera del mal uso que pueda darse a esta información. Hasta donde considero mi obligación como researcher, he cumplido.

Dicho esto, al lío…

Si entrar en más detalles ya que es algo totalmente documentado, como contábamos antes, a la hora de instanciar los ActiveX Microsoft ofrece algunas medidas que permiten controlar quién puede “jugar” con ellos y quien no. Si se informará al usuario antes de ejecutarlos, desde qué dominios pueden ejecutarse etc. IObjectSafety, via claves en el registro (AllowedDomains), sin contar con los métodos propietarios que use cada ActiveX para asegurar que quien está accediendo a sus métodos procede de un lugar realmente legítimo

En el caso de la Agencia Tributaria, los que hayais usado el PADRE para descargar los datos fiscales os acordareís que os mandaron instalar un ActiveX para este propósito. Este mismo activeX es instalado a la hora de realizar las declaraciones telemáticas de IVA que todas las sociedad tienen que presentar obligatoriamente, a través de internet.

Veamos qué metodos expone:

Como veis hay algunos metodos como GRABABI que suenan interesantes. Haciendo ingeniería inversa podemos fácilmente averiguar los parámetros correctos que quedarían por ejemplo:

GRABABI(\’c:\\\\\AEAT\\\\RENTA2009\\\\irpf2009_false.jar\’,\’base64\’,\’ADFADFAFAFAFAFAFA[..]\’)

Internamente, el ActiveX implementa una serie de comprobaciones para evitar que las operaciones que hagamos salgan fuera del directorio “c:\aeat\”, sin embargo, podríamos sobreescribir cualquier .jar de los que instala el PADRE o crear ciertos tipos de ficheros que fuera cargados automaticamente por el sistema.

Luego existen, los métodos LEERFI, LEERDIR donde podríamos listar el directorio y leer los ficheros de datos fiscales o de otro tipo y enviarlos a un servidor controlado por nosotros… En fin mil cosas.

Qué nos falta? Que la página de la agencia tributaria tenga un XSS para poder isntanciar el ActiveX desde el dominio permitido, ya que se guarda en la clave “AllowedDomains” el dominio desde donde se inicia y acepta la instalación del activex, en este caso, alguno de los pertenencientes a la AEAT.

¿Existe un fallo XSS en las webs de la AEAT? Sí. Y este permitiría hacer una cosa así.

https://aeat.es/XXXXXXXXXXXXXXXXXXXXXXXXXXX=javascript:{var c0d= '<html><body><object id=\'ab\' classid=\'CLSID:B785FA3C-1DE9-4D20-8396-613C486FE95E\'></object><script>function xplit(){ab.GRABABI(\'c:\\\\\AEAT\\\\RENTA2009\\\\irpf2009_false.jar\',\'base64\',\'ADFADFAFAFAFAFAFA\');}</script><a href=\'javascript:xplit();\'>exploit</a></body></html>';document.write(c0d);}

U otras peores. Avisé a la AEAT de este fallo hace más de un mes. A día de hoy sigue sin arreglarse. Yo por mi parte considero que no puedo hacer más.

Hasta la siguiente.

Recuperando el espíritu del post de los Rascas, seguimos con “sistemas opacos“. En este caso vamos a aplicar un poco de ingeniería social. Los que estuvieron el año pasado en la LaCon ya se saben todo el tema, aquí voy a intentar tratar algunas cosas, principalmente un análisis del billete online de Renfe. Ese que nos podemos imprimir en nuestra casa.

Habrá muchas sorpresas, regalos y serpentinas… Incluida conversación con atención al cliente de renfe

Dentro vídeo!

Antecedentes
Hurto, tenencia ilí…uy! perdón, esto no.

Vamos a explicar unas cuantas cosas que nos ayudarán a entender mejor el post y el razonamiento asociado.

Allá por el 2000 Renfe lanzó “Tiknet”, su servicio de venta online de billetes. Lo comprobas y tenías que “canjearlo” con el resguardo y previa identificación en taquilla,auto-ticketing o si no me equivoco interventor(revisor). Pero fue en el 2006 cuando se introdujo la posibilidad de imprimirte tus propios billetes en casa.

Hay que tener en cuenta que Renfe es más vieja que el fuego, pero como tal ya no existe. La aplicación de la directiva europea de separación entre explotación y gestión de infraestructuras ferroviarias, dió como resultado dos entes:
- ADIF
Empresa pública, encargada de gestionar las infraestructuras ferroviarias.
- Renfe Operadora
La encargada de explotar estas infraestructuras

Nosotros hablaremos en general de “la Renfe”. Ahí to’ guapo, la renfe nano, que no?!

Existen varios sistemas de venta y control, siendo SIRE la base de ellos, también el más antiguo.
- VISIR
- ORION
- VOL/VCX (el de internel https://w1.renfe.es/vol)
- VERTANET
Venta billetes en ruta.
Los “aparaticos” móviles.TPVs (vertas)

Infraestructuras

- AVE/Larga distancia
- Media Distancia ( Alvia, Regionales/Express… )
- Cercanías (Madrid, Cataluña, Andalucía)
- Red de Via estrecha. (FEVE)

Las CC.AA tienen transferidas las competencias sobre aquellas infraestructuras que transcurren completamente por su territorio. Esto puee traer que la implantanción de nuevos sistemas o mejoras ejecutadas de forma asíncrona, así como desigualdad de equipamientos según territorios, provincias, poblaciones, estaciones o trenes.

Comunicaciones

-La más antigua y limitada, el Tren-Tierra. Un sistema analógico.UHF 440-460 Mhz – Monocanal – Voz y Datos. Se puede interceptar.
-El estandar es GSM-R, una variación de GSM para ferrocarriles. Se lleva implantando progresívamente desde hace más de 6 años.
-No he podido comprobar que se creen redes WiFi ad-hoc entre ciertos trenes y la estación a su llegada, pero parece que podría ser.

Analizando el billete.

1.- Número de Billete
Identificador unívoco del billete. Generado por Renfe. No nos interesa demasiado.

2.- Localizador
6 códigos alfanuméricos que sirve de identificador de referencia para el billete, imprimirlo etc…

3.-Codigo bidimensional Datamatrix
Una vez decodificado vemos que contiene una secuencia de caracteres alfanumericos con la siguiente disposición.
“nº billete+ID Estación de Origen+ID Estacion de Destino+fecha+ID de tren+ID coche+ID plaza+Localizador” Todo ello sin espacios entre campos.

4.Estaciones de salida y destino.
Cada estación tiene asociado un ID.

5.Tren
El tipo e ID de tren. Cada tren que realiza un determinado recorrido tiene un ID asociado.

6.Cadena de datos
Contiene: IDTren+IDEstacionOrigen+IDEstacionDestino+Fecha+Tipo de Plaza+Coche+nºPlaza+Tarifa

7.Código de Barras.
Es de Tipo EAN 128, y contiene lo mismo que el Datamatrix.

¿Dónde podemos conseguir los códigos de identificación de las estaciones y los trenes? Venga currároslo un poco jeje…una pista https://w1.renfe.es/vol/js2/index.js

¿Necesitamos demasiado GIMP/Photoshop para generarnos un billete? Según Renfe cuenta con las medidas necesarias para evitar su falsificación.Nosotros comprobamos que en vez de generar un pdf opaco que lo dificulte, el sistema de Renfe te genera un pdf compuesto de distintas partes, la imagen de fondo, los glyphs, etc… es decir puedes extraer los caracteres de la fuente, la imagen de fondo y hacer una copia exacta. Tan solo tienes que usar un editor de pdf o cualquier utilidad de extracción de streams.

Bien. Hasta aquí tenemos todos los elementos que componen un billete. En este punto sabríamos cómo generar uno igual, una copia o uno nuevo. Obviamente con datos como el nº de billete y el identificador falseados. ¿Está todo perdido? No! Ahora llega la parte divertida, ¿en qué situaciones un billete aparentemente válido, pero falso, podría “colar?”.

El “aparatico”

La clave es el sistema de Venta en Ruta, llamado: “Vertanet” y sus “vertas”; las TPVs que llevan los interventores . En la zona norte, regionales y algunos media distancia tenemos el siguiente dispositivo. Observación y un poco de google nos llevan a este dispositivo:

Intermec PenKey 6110 + módulo impresora 6802 . Tiene soporte para GSM,IrDA y un puerto serie para añadirle módulos adicionales.

Se empezaron a utilizar en 2002 aproximadamente. Por lo tanto, antes de que el billete impreso final estuviera disponible

La experiencia me dice que los interventores en regionales/regionales express no comprueban los billetes impresos en casa mediante esta TPV.¿ Quiere esto decir que no se pueden comprobar? ¿Están capacitados estos dispostivos para leer códigos de barras/bidimensionales?. Podrían estarlo, lo que no quiere decir que lo estén en todo caso.

¿Están habilitados para comunicarse con el sistema central en tiempo real para poder verificar un billete impreso? Podría ser viable, lo que no quiere decir que esté implementado.

Vamos a hacer un poco de ingeniería social, cambiamos el chip y nos ponemos en el rol de un participante cualquiera de “granjero busca esposa” para llamar a “atención al cliente de Renfe” sin levantar sospechas, a ver qué podemos averiguar . Esta es una de las llamadas…

¿Conclusiones?. Que cada uno saque las suyas…Yo siempre pago mis viajes. Soy un tío legal… eee!! que os oigo las risas, hijosputa!

De ningún modo estoy animando a la gente a cometer fraude,no merece la pena. Aqui sólo se han expuesto datos técnicos al alcance de cualquiera. El uso o abuso de ellos es responsabilidad de cada uno.

Por cierto, estaré dando charlas por Valencia este julio, 8 y 9 en el Curso de Verano y asegur@IT . El 27 del mismo mes en la Campus Party. ¡Nos vemos por allí!