30 abril 2014

Abierto el cuarto reto Tuenti Challenge #TuentiChallenge4

Por cuarto año consecutivo, se está celebrando el Tuenti Challenge: una competición para demostrar nuestras habilidades técnicas en unos cuantos ámbitos. El propósito del challenge no es otro que permitir que la gente con inquietudes técnicas se lo pase bien a la vez que sirve tanto para dar visibilidad a Tuenti como como empresa fuertemente basada en la tecnología como para nosotros encontrar personas especialmente preparadas.



Tradicionalmente, digamos entre 2006 y 2010, Tuenti fue bastante opaca en cuanto a tecnología y lo integrada que estaba con las distintas comunidades técnicas. En aquel momento, pensábamos que había que proteger esos desarrollos al máximo (por ejemplo, cómo éramos capaces de escalar) y, sin embargo, hoy estas técnicas están muy bien documentadas en distintos sitios (que el 30% de la plantilla fueran guiris que no hablaban demasiado castellano tenía también mucho ver :P). Por ello, a partir de 2010 empezamos a querer integrarnos mucho más con la escena local y reforzamos nuestra visibilidad. Es fácil que un mes cualquiera estemos prestando nuestras oficinas para que grupos como PHPMad, Mongo Madrid o Madrid-Devops den sus charlas habituales. Y de la misma manera, aunque algo menos, en nuestras oficinas de Barcelona.



Volviendo al challenge: el primer año la totalidad de los retos eran de programación / algorítmicos, con alguna prueba igual más relacionada con la astucia. Con el tiempo, y debido también al interés de los que aquí estamos, hemos ido introduciendo más pruebas relacionadas con la seguridad y que podrían ser vistas más en CTFs (a los que de vez en cuando solemos jugar). 

Finalización del primer reto de Tuenti en 2011


Clausura del segundo reto de Tuenti en 2012

Ganadores del tercer challenge de Tuenti en 2013
Este año podríamos decir que la mezcla es un 50% programación y algorítmica, un 30% seguridad y un 20% astucia. Podríamos pensar que el Tuenti Challenge es una mezcla de Google Code Jam y un CTF clásico. Eso sí, con una diferencia: nos fijamos en el tiempo de ejecución de cada problema, la calidad del código, que no se hayan compartido soluciones, etc.

A los diez primeros en superar el reto de la web les invitamos a nuestras oficinas (bueno, en realidad empezamos con una barbacoa en toda regla), donde el reto continúa. Los premios de este año desde luego invitan a participar aunque lo mejor, desde nuestro punto de vista, es que te puedes ir de aquí con una buena oferta de trabajo (el 15% de nuestro equipo técnico empezó participando en un Challenge ;) )

Premios para los ganadores del cuarto reto de Tuenti
start Hacking now!


Contribución gracias a Luis Peralta (@luisperalta)
CTO @ Tuenti
Leer más...

29 abril 2014

Cómo filtrar ataques DDoS WebHive

Para el que no lo sepa, un WebHive es una herramienta para coordinar ataques de tipo DDoS a través de la web. Su funcionamiento es realmente sencillo, simplemente cargas el código HTML en un sitio web, defines el objetivo a atacar, y haces que la gente navegue hacia el WebHive.

Una vez en la página, los visitantes comenzarán a lanzar un desproporcionado número de visitas hacia el sitio objeto del ataque. Cuanta más gente navegue a la web donde esté alojado el WebHive, más fuerte será el ataque DDoS.

Un WebHive tiene este aspecto:


El problema a la hora de gestionar este tipo de ataques es que, dada su naturaleza distribuida, es casi imposible filtrar por IP, además tampoco sería una buena estrategia ya que habría que poner numerosas reglas en el Firewall (una por cada IP atacante) que terminaría por dañar su desempeño.

La estrategia correcta es tratar de fijar un punto único común a todas las peticiones para aplicar un filtrado global. En este caso, sí que se puede identificar algo que nos sirva para ejecutar acciones de filtrado.

Lo primero que hay que hacer es activar el modo extendido de logs en nuestro servidor Apache, eso nos va a permitir obtener mucha más información de las conexiones. Para ello, en el fichero de configuración de Apache hemos de definir los logs así

CustomLog logs/access_log combined

que se corresponde a este tipo de logs:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

Vemos que de esa forma hacemos que en nuestro fichero access_log aparezca más información, entre otras cosas el Referer, que es lo que nos va a permitir filtrar

Una vez activado el log extendido, podemos ver la fisonomía de las peticiones de un ataque mediante WebHive con más detalle:


37.0.123.xx - - [28/Apr/2014:01:06:43 +0200] "OPTIONS / HTTP/1.1" 200 11692 "http://pruebahive.net76.net/hive.html" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36"
37.0.123.xx - - [28/Apr/2014:01:06:43 +0200] "OPTIONS / HTTP/1.1" 200 11692 "http://pruebahive.net76.net/hive.html" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36"
37.0.123.xx - - [28/Apr/2014:01:06:43 +0200] "OPTIONS / HTTP/1.1" 200 11692 "http://pruebahive.net76.net/hive.html" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36"
37.0.123.xx - - [28/Apr/2014:01:06:43 +0200] "OPTIONS / HTTP/1.1" 200 11692 "http://pruebahive.net76.net/hive.html" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36"


Como se puede observar, todas llevan como referer 'http://pruebahive.net76.net/hive.html' con lo que ya tenemos un patrón para ejecutar el filtrado.

Para poder filtrar esas peticiones vamos a hacer uso de las capacidades extendidas de Iptables que permite, entre otras muchas cosas, filtrar por 'strings' con lo que, definiendo el puerto destino (80) y el patrón del referer, podemos quitarnos de golpe todas las peticiones que provengan de ese WebHive.

Para filtrar ejecutamos (como root):

# iptables -A INPUT -p tcp --dport 80 -m string --string "pruebahive.net76.net" --algo kmp -j LOG --log-ip-options --log-tcp-options --log-prefix "WebHive"


# iptables -A INPUT -p tcp --dport 80 -m string --string "pruebahive.net76.net" --algo kmp -j DROP


De esa forma, todas las peticiones que vengan de ese WebHive no impactarán en nuestro servidor web con lo que, ni consumirán 'sockets', ni recursos a nuestro servidor Apache (otra cosa es el impacto a nivel red del tráfico puro)

Si le damos un vistazo a nuestro /var/log/messages nos encontramos:


Apr 28 01:09:49 revproxy kernel: WebHiveIN=eth0 OUT= MAC=00:0c:29:9d:1a:19:8a:c9:5e:36:70:10:08:00 SRC=37.0.123.196 DST=192.168.21.11 LEN=500 TOS=0x00 PREC=0x00 TTL=46 ID=32019 DF PROTO=TCP SPT=45815 DPT=80 WINDOW=107 RES=0x00 ACK PSH URGP=0 OPT (0101080AF32986A0D2820C51) 


Apr 28 01:09:50 revproxy kernel: WebHiveIN=eth0 OUT= MAC=00:0c:29:9d:1a:19:8a:c9:5e:36:70:10:08:00 SRC=37.0.123.196 DST=192.168.21.11 LEN=486 TOS=0x00 PREC=0x00 TTL=46 ID=28012 DF PROTO=TCP SPT=45814 DPT=80 WINDOW=107 RES=0x00 ACK PSH URGP=0 OPT (0101080AF3298800D2820C41) 


Apr 28 01:09:50 revproxy kernel: WebHiveIN=eth0 OUT= MAC=00:0c:29:9d:1a:19:8a:c9:5e:36:70:10:08:00 SRC=37.0.123.196 DST=192.168.21.11 LEN=486 TOS=0x00 PREC=0x00 TTL=46 ID=11831 DF PROTO=TCP SPT=45816 DPT=80 WINDOW=107 RES=0x00 ACK PSH URGP=0 OPT (0101080AF3298940D2820C59) 

Podemos ver que, una vez hemos puesto las reglas de filtrado, es nuestro Iptables el que está tirando las conexiones y ya han dejado de aparecer en los logs de Apache.

Leer más...

28 abril 2014

Abierto el Call For Papers de No cON Name 2014




Como ya es habitual por estas fechas, se abre al público el CFP de la decimoprimera edición del Congreso de Seguridad Informática en España más veterano: La No cON Name o NcN

Las propuestas de ponencias relacionadas con descubrimientos o investigaciones técnicas, en cualquier campo de la seguridad informática y hacking, con el objetivo de transmitir conocimiento a los asistentes, podrán tener dos tipos de formatos:
  • Ponencias de 30 minutos: Exposición oral sobre investigaciones realizadas.
  • Talleres de 55 minutos: Clases magistrales sobre una investigación de forma práctica e interactiva.

El evento se celebrará en Barcelona, en la última semana de Octubre de 2.014

Según la nota de prensa enviada a Security By Default, NcN ofrecerá a sus asistentes otras posibilidades de participación, como:

  • Concurso Capture The Flag: después del éxito internacional del año anterior, el tirón mediático y el suculento premio de la empresa patrocinadora, se repite esta edición con algunas novedades (aún por anunciar).
  • Signing Party: Siendo conscientes de que PRISM y otros programas gubernamentales nos espían, se estimulará a que hackers usen e intercambien sus llaves GPG/PGP con el objetivo de hacer más seguras sus comunicaciones.  

Si tienes una charla en mente y quieres enviarla a NcN, deberás rellenar el formulario de la web https://www.noconname.org/propuesta antes del 15 de Julio de 2.014.
Leer más...

27 abril 2014

Enlaces de la SECmana - 224


Leer más...

25 abril 2014

Analizando el contenido de un fichero mediante patrones visuales

Antes de empezar este artículo me gustaría decir que no suelo escribir entradas que giren casi en exclusiva alrededor de software que he escrito yo mismo. El marketing se me da fatal. Sin embargo esta herramienta de la que voy a hablar ya tiene su tiempo, siempre me la llevo conmigo y ya han sido varias personas las que me han animado a publicarla (entre ellas NighterMan y más recientemente mi jefe en Tarlogic, Andrés Tarascó). Y como además voy a hablar de un tema que parece que no se ha tratado mucho, me dije, qué demonios, ¿por qué no?

El asunto es que a lo largo de estos últimos años yendo y viniendo de CTFs, teniendo que abrir archivos una y otra vez para saber qué se oculta en ellos, e incluso fuera del mundillo de la seguridad, en un ámbito más de "andar por casa" donde he tenido que navegar entre los escombros de un core o simplemente la mera curiosidad de saber qué se oculta en un archivo cuyo contenido desconozco me ha surgido la siguiente pregunta: ¿hay alguna forma de ir más allá? ¿existe alguna forma de optimizar ese primer vistazo que le damos a un archivo tan pronto lo abrimos con un editor hexadecimal?

La respuesta a todas estas preguntas es sí, gracias a cierto aspecto de los datos que solemos ignorar: los propios bits. Estamos muy acostumbrados a tragarnos grandes volcados en hexadecimal y eventualmente algún volcado ASCII a la derecha, del cual sólo podemos confiar en poder entender lo que dicen. Todo lo que no es ASCII se ve como un soplido de caracteres al azar, formando un extraño galimatías que solemos ignorar pensando en que "ya lo entenderá el ordenador".

Pero la verdad es que hay más. Mucho más. Para empezar, en los números 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40 y 0x80 se esconde una similitud que a simple vista pasa totalmente desapercibida. Lo mismo entre los números 0x55 y 0xaa para los que os haya tocado alguna vez un sector de arranque. E incluso en el código máquina de una arquitectura RISC. El problema es que esto, en hexadecimal, o se ve mal, o directamente ni se ve.


Estos nuevos detalles se pueden apreciar mejor gracias a una herramienta que escribí allá por 2011 después de mi primera RootedCON: biteye, y más recientemente vix. Y cómo no, ambas GPL y para GNU/Linux.



Biteye es un programa con un aspecto bastante extraño. Es un editor hexadecimal que para empezar, ni puede editar. Lo escribí cuando estaba aprendiendo a usar SDL y el resultado es una interfaz bastante sobria. Exactamente así:


Biteye, mostrando un ELF.


Biteye sólo responde a cuatro teclas: Arriba, Abajo, Av Pág y Re Pag. Lo único que podemos hacer es avanzar y retroceder a lo largo y ancho del archivo.



Parece algo muy elemental, sin embargo la verdadera utilidad reside en tres elementos: para empezar, el panel de la izquierda (que llamaré "panel de filas"), el de la parte inferior (que llamaré "panel de columnas") y el color del volcado hexadecimal en el centro. Empezaremos por este último, que será el más familiar para todos.


El volcado hexadecimal
Este volcado es como cualquier otro volcado hexadecimal, offset a la izquierda, bytes en el centro y ASCII a la derecha, mostrando 1024 bytes a partir de cierta posición del archivo. Lo particular de este es el color de los bytes:


El color no está elegido al azar por algún incomprensible sentido mío de la estética. La idea es calcada de algo que llevan haciendo herramientas como Hexplorer para Windows, y es que los bytes con un valor absoluto más pequeño se vean más oscuros que los bytes más grandes. Fijémonos en el 0x01, el 0x02 o el 0x10: tienen un tono mucho más oscuro que 0xd5, 0xec y 0xbb. Teniendo en cuenta que en los ejecutables y muchos otros archivos binarios la mayor parte del archivo está formado por ceros, tener estos colores que contrastan tanto en un mar de negrura nos ayudan a encontrar datos de una forma mucho más visual. Sin embargo, hay más: supongamos una tabla de offsets, o la propia .plt, donde cada entrada tiene un salto direccionado por una entrada correspondiente en la .got, las cuales suelen estar ordenadas y miden todas lo mismo. De este modo, las direcciones de la .got crecen de forma bastante lineal. ¿Cómo se ve esto?


Se ven como degradados. Y en parte es normal: no estamos haciendo más que variar linealmente el valor de los bytes y por tanto, su color. Esto puede ser de gran ayuda a la hora de identificar estructuras y la semántica de sus campos. En estos casos podríamos formular hipótesis sobre índices, claves foráneas o desplazamientos relativos de cualquier tipo.


Pero vamos un paso más allá: estas líneas se ven verticales porque los índices están alineados al ancho del volcado (16 bytes). Sin embargo, no todas las estructuras gozan de este alineamiento. Cuando hay un array de estructuras de este tipo, veremos grandes secuencias de diagonales como estas:





Esto no es algo que no se pueda ver con un editor hexadecimal con un ojo entrenado. De hecho, muchos lectores experimentados van a decir que esto no es nada nuevo, ciertamente no lo es. Sin embargo, lo importante aquí es ahorrarnos tiempo. Y los colorines, francamente, ayudan.



Existen muchas estructuras que se pueden dilucidar en este volcado, es cuestión de ir probando con archivos de distinto tipo e intentar razonar por qué vemos lo que vemos.



El panel de filas

Es aquí donde empezamos a alejarnos un poco de los editores hexadecimales tradicionales. Esta vista nos permite contemplar los bits del archivo distribuidos horizontalmente y es, en mi experiencia, la más útil de todas ellas. Cada secuencia de ocho píxeles horizontales representa un byte, pintándose de naranja los bits que están a uno y en negro los que están a cero. Además, dentro de los unos, se marca en un color más claro los bits más significativos y más oscuro los menos significativos. Esto nos permite saber dónde acaba cada byte. Sí, lo sé, esto es equivalente a un mapa de bits monocromo de ancho fijo:




Cada fila tiene un ancho de un píxel y representa 32 bytes, teniendo por tanto 32 bytes * 8 bits = 256 píxeles de ancho. En rojo se marcan los 1024 bytes que están siendo mostrados en el volcado hexadecimal. Esto nos permite mantener la perspectiva de la parte del fichero que estamos visualizando. 



Debo decir que esto tampoco es una revolución: este tipo de vista la he encontrado en algunos editores hexadecimales especializados en editar ROMs de videojuegos de Gameboy, con algunas opciones más sofisticadas como tomar los bits de dos en dos (o grupos potencia de dos más grandes) y asignar un valor de una escala de grises, pudiendo mostrar mapas de bits de distinta profundidad de color. Citaría la herramienta donde he visto esto, pero es que francamente, no me acuerdo (agradecería que alguien me la pudiese indicar, llevo años detrás de ella)



Un caso práctico: la cabecera ELF

Del mismo modo que para el volcado hexadecimal, las estructuras alineadas con los 32 bytes de ancho de la vista se verán como grupos verticales de píxeles, y aquellos que no lo están se verán como franjas diagonales. Sin embargo, en esta vista existe un conjunto de patrones que se suelen repetir muchísimo cuando analizamos ficheros binarios. Especialmente los ficheros ejecutables, que por la diversidad de sus estructuras internas son muy representativos y les dedicaré los siguientes apartados. Por ejemplo, el /bin/ls de mi sistema (Linux, x86_64) que acabo de utilizar en el ejemplo anterior. Examinemos sus primeros bytes:



De un vistazo podemos apreciar dos regiones diferenciadas, aunque realmente hay tres. Existe una primera línea que empieza con una línea (no más grande de un byte) de varios bits a 1. Esto es parte del número mágico de la cabecera de un ELF: "\x7fELF". Ese 0x7f inicial es en binario 01111111, de ahí todos esos bits con el mismo color. Así comienzan los primeros bits de la estructura de 64 bytes Elf64_Ehdr de este ejecutable. Como son 64 bytes, la cabecera ocupa apenas 2 píxeles de ancho.

Lo siguiente región se aprecia un poco mejor por ser considerablemente más grande. Estas cuatro columnas (que una simple división nos dice que deben medir 32 / 4 = 8 bytes de ancho) pertenecen a las entradas de la tabla de cabeceras de programa, o tabla de segmentos, que para este ejecutable tiene 9 entradas. Cada entrada de esta tabla, en 64 bits, tiene 56 bytes. Sin embargo, estos 56 bytes ni siquiera son múltiplo entero de los 32 bytes de ancho que tiene la vista de filas. ¿Cómo puede ser que lo veamos como columnas verticales y no como las diagonales propias de los arrays desalineados? Pues porque resulta que en este caso se ha dado una casualidad que realmente se va a dar en muchos otros ficheros, y tiene que ver con cómo se agrupan los campos en las entradas de esta tabla (cada una del tipo Elf64_Phdr):

           typedef struct {
               uint32_t   p_type;
               uint32_t   p_flags;


               Elf64_Off  p_offset;

               Elf64_Addr p_vaddr;
               Elf64_Addr p_paddr;
               uint64_t   p_filesz;
               uint64_t   p_memsz;
               uint64_t   p_align;
           } Elf64_Phdr;

Prácticamente todos los campos de esta estructura tienen 64 bits y por lo tanto ocho bytes de ancho. Los únicos dos campos que se escapan a la norma son p_type y p_flags que son de 32 bits y además están agrupados, por lo que podemos verlos como un único campo de 64 bits. Esto no es muy distinto a un array de 56 / 8 = 9 elementos de enteros de 64 bits. Además, como el valor absoluto de todos estos campos están por debajo de 0x100000000, sus 32 bits más altos (salvo para los dos primeros campos) van a ser nulos. Gracias a esta característica vamos a poder diferenciar cada campo del siguiente.


Otro detalle que merece la pena destacar es que teniendo en cuenta que la mayoría de sus valores son pequeños, la probabilidad de encontrar un bit menos significativo a 1 es mayor que la de encontrar uno más significativo igualmente a 1. En una arquitectura little endian va a provocar que los bits se agrupen a la izquierda, ya que los bytes menos significativos van a aparecer antes que los más significativos. Por contra, en arquitecturas big endian los bits se agruparán a la derecha ya que los bits más significativos están en posiciones de memoria más bajas que los menos significativos. Comparemos, pues, una cabecera del /bin/ls de SPARC64 (big endian):




Con la de mi x86_64 (little endian):



Evidentemente, la vista sigue dependiendo mucho del alineamiento, pero alineamientos a parte, podemos ver indicios de cierto gradiente de densidad de bits a 1 hacia un sentido o hacia el otro en función de la arquitectura. Cuando lidiamos, por ejemplo, con firmwares que no tienen ningún tipo de cabecera y por tanto desconocemos la CPU para la que han sido compilados, este tipo de vistas nos pueden ayudar a obtener información sobre la arquitectura subyacente.


Las siguientes líneas que aparecen sin ninguna estructura aparente son las secciones .interp (que tiene tamaño variable y contiene la ruta del intérprete del binario), .note, .gnu.hash, .note.ABI-tag y .note.gnu.build-id, que suelen tener tamaños dispares y normalmente suelen contener información del compilador usado y la ABI.


La tabla de símbolos dinámicos: .dynsym
La siguiente región que podemos encontrarnos tiene un patrón de ocho columnas, pero siendo todas ellas mucho más homogéneas que las ya vistas:



Este patrón pertenece a .dynsym, la sección del ejecutable que contiene la tabla de símbolos dinámicos. Cada entrada es del tipo Elf64_Sym:

           typedef struct {
               uint32_t      st_name;
               unsigned char st_info;
               unsigned char st_other;
               uint16_t      st_shndx;
               Elf64_Addr    st_value;
               uint64_t      st_size;
           } Elf64_Sym;

Tenemos de nuevo una situación similar a la de la tabla de cabeceras de programa: los campos se pueden agrupar de ocho en ocho, de ahí la regularidad. La columna "ancha" se debe al campo st_name: es un offset dentro de cierta sención (dynstr) con la cadena del nombre del símbolo descrito. Como la mayoría de campos son de tipo función y son globales (STT_FUNC = 2 y STB_GLOBAL = 1) se codifican en el campo st_info como (1 << 4) | 2, lo cual es 00010010 en binario y encaja con la columna de dos píxeles naranjas con dos píxeles de separación. Como el resto de campos están a cero, aparecen estas líneas negras entre cada dos líneas: todos estos símbolos hacen referencia a funciones importadas por el ejecutable desde otras bibliotecas.

Si nos fijamos, el patrón vuelve a cambiar hacia el final de esta sección. Esto es debido a que al final de todas las importaciones se describen símbolos que realmente han sido definidos dentro del ejecutable (como _edata, _end, __bss_start, etc), lo cual cambia algunos flags y hace que el contenido esté un poco más cargado de bits a 1.

Texto ASCII: cuando sólo teníamos 7 bits
La siguiente región es igualmente representativa de muchísimos otros ficheros binarios, y además tiene una característica importante compartida por absolutamente todos sus bytes:


Esto se corresponde con la sección .dynstr, y está formada exclusivamente por texto plano y algún que otro carácter nulo. Básicamente es una secuencia de todos los nombres de los símbolos definidos en .dynsym. Lo importante aquí es que todos los caracteres imprimibles de la tabla ASCII están siempre debajo de 128 (0x80 en hexadecimal), o sea que su bit más alto va a ser siempre cero. Esto provoca que se sucedan unas líneas verticales de ceros separando cada byte. El resto de los mismos parece bastante ruidoso (para las máquinas nuestra forma de escribir es un auténtico galimatías casi incomprensible), pero en fin, ¡qué podemos esperar del lenguaje natural! Suficiente tenemos con ese bit siempre a cero :)

Encontrar este patrón en un fichero con un formato desconocido suele ser buenas noticias, básicamente porque significa que es algo que nosotros podemos leer. No es nada que no pueda mostrar un strings, pero esta vista nos permite ver las cadenas en su contexto. Y si queremos leerlas siempre tenemos el editor hexadecimal a la derecha.

Torres binarias
A veces nos encontramos en un fichero binario largas sucesiones de números enteros que crecen en unidades que son múltiplos de potencia de dos y que además están alineadas. Cuando esto sucede, se forma un patrón en forma de media torre muy llamativo. Es llamativo porque es autosemejante a diversos niveles de escala: si nos fijamos, la mitad de esta torre es igual a toda la torre salvo una línea vertical.


Podemos hacer el experimento en una hoja de papel cuadriculado: si escribimos los números del 1 al 16 en binario uno justo debajo del otro, pintando los cuadrados en negro cuando se correspondan con un cero y dejándolos en blanco cuando es cero, veremos exactamente este mismo patrón.

Cuando vemos estas torres, debemos pensar automáticamente en el patrón en degradados que vimos en los colores del volcado hexadecimal, pues están directamente relacionados. Lo que en el volcado se ve como incrementos de brillo, aquí se ve esta forma particular. En la imagen, lo que estamos viendo son las entradas de la sección .plt de un /bin/ls de i386, las cuales tienen esta forma:

080494e0 <__ctype_toupper_loc@plt>:
 80494e0:       ff 25 00 20 06 08       jmp    *0x8062000
 80494e6:       68 00 00 00 00          push   $0x0
 80494eb:       e9 e0 ff ff ff          jmp    80494d0 <_init+0x30>

080494f0 <getpwnam@plt>:
 80494f0:       ff 25 04 20 06 08       jmp    *0x8062004
 80494f6:       68 08 00 00 00          push   $0x8
 80494fb:       e9 d0 ff ff ff          jmp    80494d0 <_init+0x30>

08049500 <raise@plt>:
 8049500:       ff 25 08 20 06 08       jmp    *0x8062008
 8049506:       68 10 00 00 00          push   $0x10
 804950b:       e9 c0 ff ff ff          jmp    80494d0 <_init+0x30>


Cada entrada en la .plt tiene exactamente 16 bytes, lo cual provocará que cada par de entradas esté alineado con nuestra vista de filas. Lo importante de cada entrada en la .plt es que hay tres instrucciones cuyos argumentos varían con una diferencia constante que es potencia de dos respecto del anterior: el primer salto lee las direcciones 0x8062000 el primero, 0x8062004 el segundo, 0x8062008. Lo mismo sucede con el push (0x4, 0x8, 0x10...) y con el siguiente jmp (que además crece de 16 en 16, también potencia de 2).

Debido a que hay dos filas por entrada, tenemos que ver 6 patrones en forma de torre binaria, que es exactamente lo que sucede.

Los poemas de las CPUs: del CISC romance al RISC oriental.
En general, no hace falta saber chino para diferenciar un texto chino de un texto en árabe, ruso, sánscrito o inglés. Básicamente porque los alfabetos son distintos y la forma de agrupar las palabras es igualmente diferente. Cuando pasamos código máquina de alguna arquitectura bajo los ojos de biteye, sucede exactamente lo mismo.

Hoy por hoy, las arquitecturas de CPU se dividen en dos grandes familias: las arquitecturas CISC y las arquitecturas RISC. En las arquitecturas RISC las instrucciones suelen tener el mismo tamaño en bytes y existen un número bastante limitado de ellas, aunque son suficientes para poder compilar un Linux y ejecutarlo correctamente. Ejemplos de arquitecturas RISC son ARM, PowerPC, SuperH o MIPS (esta última ni siquiera tiene una instrucción para meter un valor en un registro, en su lugar se hace sumando un cero con el valor que queremos inicializar dicho registro). En general, hablamos de un lenguaje máquina muy depurado donde incluso con un poco de práctica, se podría leer sin la necesidad de un desensamblador.

En el otro extremo tenemos a las CISC, entre las cuales las más conocidas son x86 y x86-64. Estas se caracterizan por tener un repertorio de instrucciones enorme, donde los operandos se pueden componer de muy diversas formas (haciendo además que las instrucciones puedan tener tamaños diversos) y con todo tipo de modificadores e instrucciones especializadas. Además, a diferencia de las arquitecturas RISC, donde el procesador nunca puede leer una instrucción "por la mitad" ya que deben estar obligatoriamente alineadas, en CISC esto no es así, y si utilizamos un desensamblador en una dirección incorrecta lo más probable es que obtengamos un falso desensamblado que incluso pueda llegar a ser ejecutando correctamente por la CPU (aunque evidentemente no hará lo que nosotros queramos).

Continuando con el símil del idioma, podríamos comparar las arquitecturas RISC con el coreano y las arquitecturas CISC con el francés: en el coreano todas las sílabas ocupan el mismo recuadro y están formadas por unos componentes muy simples. En el francés, sin embargo, las sílabas pueden tener todo tipo de longitudes que dependen de las letras involucradas, excepciones, acentos y el sonido que se quiera producir. Además, si empezamos a leer una sílaba "por la mitad" no podríamos saber a priori si la sílaba está cortada y obtendríamos una pronunciación que en absoluto tiene que ver con la de la sílaba completa.

Analicemos entonces cómo se ven las instrucciones de las arquitecturas RISC más famosas. Por ejemplo, ARM (little endian):


MIPS 32 (little endian):


MIPS 32 (big endian):


SPARC 32:


SPARC 64 (las instrucciones miden lo mismo que en SPARC de 32 bits y apenas se pueden notar las diferencias):



SuperH 4 (nótese que esta arquitectura tiene instrucciones de 16 bits, por tanto 2 bytes por instrucción y 32 / 2 = 16 instrucciones por fila):



Y PowerPC:



Debido al alineamiento obligatorio de las instrucciones RISC que convierten al código en algo equivalente a un array de enteros, siempre vamos a ver patrones verticales. 

Por otro lado, el código máquina generado para arquitecturas CISC suele carecer de alineamientos de ningún tipo, y a veces es difícil de distinguir de un chorro de bytes totalmente aleatorios.

Por ejemplo, un código de x86 en 16 bits sacado de FreeDOS:



Y de nuevo para x86, en 32 bits (lo que en el mundo de Linux se conoce popularmente como i386):


A medida que esta arquitectura fue evolucionado y el tamaño de sus registros se fue duplicando, el número de bits desperdiciados a la hora de representar números pequeños fue creciendo también (0x0004 -> 0x00000004 -> 0x0000000000000004). Aunque en general el código máquina de x86-64 maneja esto bastante bien, podemos ver trazas del desperdicio en la cantidad de bits a cero comparado con i386:


Sin embargo, estas tres no son las únicas arquitectura CISC que hubo en la historia. Por ejemplo, la también popular Z80 se ve así (esto lo he sacado tal cual de una ROM del Pokémon para la Gameboy Color y empieza a ser complicado ver algún tipo de patrón salvo por alguna que otra anomalía estadística en la cantidad de ceros):



Y para Motorola 68000 (donde una vez más, los ceros delatan la existencia de un código):



Otros estructuras
No todos los ficheros ejecutables que nos toque analizar son tan simples, y algunos de ellos ni siquiera están dentro de un formato conocido. Por ejemplo, en el mundo de los firmwares no es raro encontrarse datos comprimidos, donde la entropía es máxima (y que  por tanto no se pueden diferenciar a simple vista de datos cifrados cuando el algoritmo es robusto) y los unos y ceros se reparten de forma aparentemente aleatoria siguiendo una distribución uniforme:


También nos podemos encontrar algún que otro mapa de bits (esto es un Tux que me encontré en un kernel de Motorola 68000, supongo que es la imagen que aparece en la esquina superior izquierda del framebuffer cuando arranca el PC):



Existen además muchos sistemas (como por ejemplo, DOS) que almacenan fuentes tipo raster como mapas de bits monocromos, los cuales además suelen tener ocho píxeles de ancho. En casos como este, la vista de columnas se vuelve muy útil, ya que nos permiten visualizar la fuente tal cual se vería en pantalla, salvo quizá por el sentido horizontal en el que se almacenan. Por ejemplo, un fichero EGA.CPI de mi FreeDOS revelaba un contenido como este:


O volviendo a la dichosa ROM del Pokémon:


Y muchas otras cosas más que por brevedad dejaré al lector curioso que juegue con la herramienta para buscar "cosas raras" en el fichero que más rabia le dé, y saque sus propias conclusiones :P

Conclusiones
Hay mucho que ver más allá del hexadecimal.

La verdad es que si me salgo de los ejecutables podría extenderme con muchísimos patrones más, pero no creo que pudiese cubrir todas las áreas en las que alguien se podría especializar. Incluso se podría utilizar para evaluar la calidad de un generador de números pseudoaleatorios. Para poder usar correctamente esta herramienta es importante tener la mentalidad de intentar comprender el porqué de lo que se ve (comparar la vista de bits con el volcado es necesario, a pesar de todo), y gran parte de los descubrimientos que se hacen se deben a la experiencia con archivos conocidos y a unos ojos bien entrenados. 

Y por lo demás, sólo recordar que a veces es divertido visualizar un archivo sin la pretensión de encontrar nada.

Post Scriptum sobre la herramienta
Como mencioné antes, Biteye ha sido escrito originalmente como un pasatiempo, tenía curiosidad por cómo se veían los bits de un fichero y además de experimentar con SDL, y como tal el código apesta. Nunca esperé que llegase a ser una herramienta que fuese a liberar. En cualquier caso, el código original se pueden bajar de http://actinid.org/outcoming/biteye-0.1.tar.gz (Git web: http://actinid.org/git/?p=biteye.git;a=summary)

Cuando empecé a escuchar algunas opiniones favorables comencé a escribir Vix, una versión mucho mejor diseñada y también basada en SDL (Git web: http://actinid.org/git/?p=vix.git;a=summary, descarga lista para ser compilada: http://actinid.org/outcoming/vix-0.1.tar.gz) y que soporta una interfaz con ventanas que se pueden organizar para aprovechar mejor el espacio de trabajo, múltiples archivos abiertos a la vez, etcétera. El aspecto de Vix no se aleja mucho del de biteye:


El problema de Vix es que todavía está en pañales y es ligeramente más lento. Mi intención era añadirle algunas cosillas, como algunas combinaciones de teclas para saltar a un offset, desensamblar regiones (usando, por ejemplo, libbfd), cambiar el ancho de las vistas de bits, la profundidad de color, ¿integrarlo con radare? y quién sabe si soporte de edición. Como se puede apreciar, son muchas cosas en el TODO para lo que originalmente ha sido un juguete.

Desgraciadamente, no tengo tanto tiempo como me gustaría para implementar todas estas funcionalidades. Pero quién sabe, si al final esta herramienta acaba siendo de utilidad podría atreverme a priorizarlo un poquito :D

Artículo cortesía de Gonzalo J. Carracedo
Leer más...

24 abril 2014

Arrancan las Jornadas X1RedMasSegura 2014



Las Jornadas X1REDMASSEGURA nacieron en 2013 con el propósito de promover a través de un foro el uso de Internet de una manera confiable y segura. Su objetivo es hacer llegar a todos los públicos, independientemente de sus conocimientos técnicos en informática, el uso adecuado y responsable de los recursos disponibles en la red con el fin de evitar ser víctimas de abusos fraudulentos, estafas, acoso, grooming y tantos otros problemas que cualquier navegante puede sufrir en Internet si no cuenta con unos conocimientos adecuados.
Esta segunda edición del evento también se encuentra coordinada por el colectivo X1RedMasSegura, que desde su nacimiento en 2013 ha ofrecido sus ganas y todo su apoyo por hacer de estas jornadas algo grande, sin ningún ánimo de lucro.
Las Jornadas durarán dos semanas, del 8 al 17 de Mayo. Comenzarán por una serie de talleres GRATUITOS que se celebrarán del 8 al 14 de Mayo en las sedes de IPA Madrid, del Vivero de Empresas de Móstoles y de la UDIMA, para Padres, Niños, Ciberabuelos, Empresarios, Profesores e Internautas Base, en los que se enseñarán como protegerse de la red de redes sin necesidad de ser experto ni en Informática, ni en Seguridad de la Información. Entre los temas que se tratarán se encuentran porqué es necesario utilizar HTTPS, cómo crear una contraseña segura, seguridad en redes sociales, etc. Los talleres tienen un máximo de 20 plazas cada uno, y podréis apuntaros GRATUITAMENTE desde el siguiente formulario de inscripción:
Además, el día 10 de mayo tendrá lugar un taller dirigido a personas con discapacidad, gracias al Programa de Atención Integral a la Discapacidad del Ayuntamiento de Alcalá de Henares, que tendrá lugar en el Espacio Joven, situado en los bajos de la plaza de toros de Alcalá de Henares a las 18h
Los días 16 y 17 de Mayo se celebrará el evento principal en el auditorio de la Escuela Técnica Superior de Ingenieros de Telecomunicación (ETSIT) de la Universidad Politécnica de Madrid, localizada en la “Ciudad Universitaria”. Las jornadas comenzarán el viernes 16 a las 16:00 horas y finalizarán el sábado a las 14:30 horas. Al igual que los talleres, las jornadas van dirigidas a público no técnico y en ellas se tratarán problemas actuales como las estafas cibernéticas, malware (virus), nuestros derechos en la red, la nube, etc., explicado para ser entendido por todos los niveles.
A continuación os dejamos la dirección para llegar tanto a los talleres como al lugar donde se celebrarán las jornadas:
Esperamos que las jornadas sean un éxito, las disfrutéis y sobretodo que sirvan para lo que queremos, conseguir entre todos 1Red MasSegura.
Aprovechamos para recordaros que sigue abierto el concurso “Infografías Jóvenes x1RedMasSegura ’14″ hasta el próximo 4 de Mayo, con el objetivo de concienciar y educar a los más jóvenes en el uso seguro y responsable de Internet.
Desde Security By Default, queremos mostrar nuestro apoyo a este eventos como este, que se hacen por causa solidaria, sin otro fin que el de educar y enseñar a los colectivos que tienen un mayor riesgo en Internet: nos referimos personas mayores y niños. 
En Internet no debe haber prohibición ni censura, sino educación y concienciación; y aun así, nadie está exento totalmente de sufrir diversos ataques que puedan afectar a nuestra vida digital. Cuanto más preparados estemos, mejor seremos capaces de enfrentarnos y reaccionar ante estas amenazas.      
El hashtag del evento será #X1RedMasSegura. No os lo podéis perder!
Leer más...

23 abril 2014

Menuda sorpresa recibimos ayer, resulta que este humilde blog ha sido seleccionado finalista de los 'European Security Blogger Awards' unos prestigiosos premios que se celebran en el marco del evento 'INFOSECURITY EUROPE'

Cuando nos llegó el correo: 


Al principio se nos quedó cara de WTF ! y pensamos que se trataría del típico correo que luego no es lo que parece, nos cruzamos varios correos entre los editores hasta que confirmamos el correo: Efectivamente estamos nominados !

Viendo la lista de los otros nominados, la verdad es que impone bastante respeto:


Estamos hablando del blog de Brian Krebs, blog con decenas de miles de visitas diarias y miles de seguidores en twitter, el blog de Xavier Mertens e incluso el blog Countermeasures de todo un Trendmicro 

Y sobre todo, el matiz más importante es que, todos los blogs nominados están escritos en lengua Inglesa, con lo que el hándicap para SbD es aun mucho más grande.

El hecho de que nos hayan nominado para llegar a la parte de votación pura (la fase de nominación es mediante jurado), la verdad es que es bastante impresionante y supone un inmenso honor

Sabemos que es imposible: por tamaño, por lenguaje, por trayectoria ... pero ¿hay alguna posibilidad de ganar el premio?

De momento se han abierto las votaciones y si queréis podéis votar a SbD en este enlace

Si os hace ilusión que un blog de habla hispana esté ahí luchando entre los grandes, vota. Lleguemos hasta donde lleguemos, siempre os estaremos agradecidos, porque el hecho de haber llegado hasta aquí, es gracias a vosotros
Leer más...

22 abril 2014

Hackeos Memorables: El asesino en serie B.T.K


La historia del asesino en serie Dennis Rader, más conocido como B.T.K. (Bind, Torture, Kill),  es memorable y digna de un pequeño hueco en este blog debido a la importancia de la ciencia forense informática en su captura.

El primero de los asesinatos de BTK de los que se tiene constancia, fue en 1974, cuando mató a una pareja y a dos de sus hijos: entró en su casa, les cortó el teléfono, los ató a las sillas, y los fue asfixiando uno a uno con bolsas de plástico en la cabeza.

Ese mismo año asesino a otra joven e intento lo mismo con su hermano.

Durante ese año, tres personas confesaron los crímenes asegurando que eran B.T.K., lo que provocó que el Dennis Rader llamase a un periódico local para contarles que había colocado una carta en un libro de la biblioteca pública en la que desacreditaba a los falsos asesinos, y daba más datos para demostrar que el asesino era él. No sólo reconocía los crímenes sino que aseguraba que volvería a matar: 

The code word for me will be....Bind them, toture them, kill them, B.T.K., you see he at it again. They will be on the next victim.

Y efectivamente, así lo hizo: mató a 5 personas más entre el 77 y el 91.

En 1977 asesina a una chica y lo intenta con sus dos hijos, pero el sonido del teléfono lo asusta y huye del lugar del asesinato.  También en el 77 asfixia a otra chica de 25 años.

Sus actos cesan hasta el año 85, donde estrangula a otra mujer. Un año después otra joven es asesinada siguiendo el mismo patrón. Finalmente en el año 91, comete su décimo y último crimen al secuestrar y estrangular a otra mujer. 

Firma de BTK
A Dennis Rader le gustaba comunicarse con la policía mediante cartas y pretendía llamar la atención de los medios de comunicación.

Era 2004, habían pasado décadas y el asesino seguía libre, además enviaba sobres y notas con su firma a cadenas de televisión locales, también solía incluir documentos personales de sus víctimas, puzzles y acertijos.

Pero el 16 de Febrero de 2005 algo cambió. Un disquete que contenía un archivo con el nombre: "Test A.RTF" y algunos objetos más se entregaba en KSAS TV.

El fichero contenía el texto: This is a test. See 3 x 5 Card for details on Communication with me in the newspaper
Disquete con Test A.RTF
El disquete fue entregado a los forenses que no tardaron en observar en las propiedades del archivo el texto: "Dennis" y "Christ Lutheran Church". Lo que llevó al especialista a lanzar una consulta a Google. Allí encontró la página web de la iglesia, en la que figuraba un tal "Dennis Rader" como presidente de la Congregación. ¡Bingo!

El grupo encargado de su búsqueda rápidamente lo localizó y distintas pruebas de ADN hicieron el resto.

Debido a que Kansas re-instauró la pena de muerte en 1994 (3 años después de su último asesinato) fue condenado a 10 cadenas perpetuas consecutivas. Lo que garantiza que morirá en prisión.

Lo cierto es que la historia da para una buena telenovela, y así ha sido ya que hay unas cuantas películas sobre este asesino (ninguna demasiado buena, todo hay que decirlo): Feast of the Assumption: The Otero Family Murders, The Hunt for the BTK Killer, B.T.K. Killer y B.T.K.  También documentales y libros de todo tipo. 

Referencias:
Leer más...

21 abril 2014

Análisis de Acierta las preguntas (Parte II de II)

En la entrega anterior vimos algunas de las vulnerabilidades presentadas por la aplicación Acierta las preguntas, además de posibles soluciones que se podrían haber implementado para evitar su explotación.

Nos quedó por analizar el apartado multi-jugador, así que manos a la obra.

El modo online


El juego dispone también de un modo multi-jugador donde retar a otros usuarios. Cuando accedemos capturaremos la siguiente petición/respuesta:


Como en mi caso no tenía iniciada ninguna partida, el resultado es una estructura JSON vacía. Si ahora buscamos un reto a través del modo online capturaremos el siguiente tráfico:


Aquí podemos ver el ID asociado a nuestra partida, que cuando termine generará la siguiente petición:


Una vez más esta petición puede ser fácilmente alterada de modo que podemos indicar de manera libre nuestra puntuación.

Además al carecer de cualquier tipo de control de acceso nos permite enumerar las partidas de otros jugadores, esto se puede lograr si modificamos en la petición de recuperación de partidas la URL para indicar otro usuario:


De modo que si al final sumamos todas estas ausencias de comprobaciones, a través de la pantalla de ranking se podría obtener los nombre de los mejores jugadores, iniciarles un reto online sin su consentimiento y enviarles una puntuación de 0. Esto en el sistema de juego online supondría una bajada de nivel para su perfil.

Para protegernos ante estos problemas podríamos optar por soluciones que ya comentábamos en el artículo anterior:

  • Realizar una gestión correcta de la sesión. De este modo no haría falta intercambiar el usuario como un parámetro de la petición y evitaríamos la alteración de este dato.
  • Delegando la responsabilidad al servidor de determinar la puntuación. Si cada acierto/error se envía al servidor, cuando haya que calcular la puntuación no será necesario confiar en una petición que ha podido ser alterada por la parte cliente del juego.

 

Suplantación de identidad


Como ya hemos visto a lo largo de las peticiones capturadas se hace notar la falta de una gestión correcta de la sesión y prácticamente todo el sistema se basa en enviar el nombre del usuario como parámetro, ya sea en la URL porque es una petición de tipo GET o en el cuerpo de la petición porque es de tipo POST, pero, ¿de donde sale este nombre de usuario?

La respuesta está en el formulario de login que rellenamos en la primera ejecución. Este formulario intercambió la siguiente petición/respuesta:


A partir de este intercambio de información la aplicación ya da por supuesto que somos el usuario nodoraiz, que al ser un dato persistente nos induce a pensar que se encuentra en la base de datos. Lo comprobamos:


De este comportamiento podemos deducir que lo que ocurre es que:

  1. Rellenamos el formulario de inicio de sesión
  2. Se envía el nombre de usuario y el MD5(clave)
  3. Se recibe una respuesta que varía entre si es un alta, si es un inicio de sesión válido (es la captura que he puesto arriba de Respuesta) o si es un inicio de sesión inválido
  4. Si es un alta o inicio de sesión válido, se guarda en la base de datos y a partir de entonces se trabaja con ese valor en todas las peticiones

Una vez analizado el comportamiento, sólo queda hacer una explotación como prueba de concepto.
  • Desde el menú de Android nos vamos a Ajustes > Aplicaciones > Acierta las preguntas y borramos los datos. Esto lo hacemos para limpiar la base de datos del juego y así eliminar nuestro usuario.

  • Ponemos a interceptar el tráfico de nuestro dispositivo Android con un Web proxy
  • Iniciamos sesión en el juego con otro usuario inventándonos la clave:

  • Alteramos la respuesta y cambiamos el mensaje recibido de error:
    • {"resultado":[{"msg":"El usuario ya existe","code":2,"nivel":1}]}
  • Por el mensaje recibido cuando todo es correcto:
    • {"resultado":[{"msg":"Autentificaci\u00f3n correcta","code":1,"nivel":"1"}]}

A partir de este momento el juego enviará en todas las peticiones el nombre de usuario suplantado y el servidor se lo creerá ciegamente al no existir ningún otro mecanismo de validación.

Una vez más, para evitar este problema hubiera bastado con introducir un mecanismo de gestión de sesión y que cada vez que se abra la aplicación se envíen los credenciales al servidor para que este los valide. También y por pasarlo por alto, se debería evitar el uso de MD5 para realizar el hash de la clave y utilizar alguna función más robusta como SHA-2 con sal.


Conclusiones finales


Aunque sea a través del ejemplo de un juego, hemos visto como prácticamente toda la aplicación cae por tres motivos clave:

No olvidemos que aunque se trate de un juego se deben cuidar estos aspectos, de otro modo se favorece la aparición de cheaters y con ello se produce la caída de la experiencia jugable.

Artículo cortesía de Miguel Ángel García
Twitter: @nodoraiz
Leer más...