Topera es una herramienta que realiza ataques IPv6 que no son detectados por Snort o sistemas basados en Snort.
¿Qué hace diferente a TOPERA?
En muchos foros, blogs, reddit e, incluso, la propia lista de correo de Sourcefire (empresa fundada por el creador de Snort) se ha cuestionado los ataques que lleva a cabo TOPERA y como estos podrían detectarse ajustando las reglas de detección de Snort.
TOPERA aprovecha un fallo de diseño de Snort en el tratamiento de ciertos paquetes de IPv6. Esto significa que no importa lo buenas que sean las reglas que se tengan configuradas, Snort no será capaz de detectar los ataques que se aprovechen de este fallo de diseño.
TOPERA no ha reinventado la rueda, en lo que ataques se refiere, pero les ha otorgado la capacidad de ser indetectables por Snort.
TOPERA fue la primera en incorporar este ataque bajo IPv6 (que días más tarde fue añadido al proyecto slowloris) y, además, dotarlo invisibilidad ante Snort:
¿Qué consecuencias tiene TOPERA?
Si eres administrador de sistemas, probablemente ya te habrás echado a templar leyendo el nuevo ataque. Si no eres sysadmin o todavía no le ves el peligro real (más allá del propio ataque) esto tal vez te haga hacerte una idea:
Usando TOPERA puede inutilizar (durante todo el tiempo que se esté ejecutando el ataque) un servidor web vulnerable a slow HTTP attaks, como Apache. Al no ser detectado por el IDS (basado en Snort) no podrás tomar contramedidas para poder protegerte o tratar de mitigar el ataque. Por lo tanto: el sistema de seguridad en que delegas para proteger tu infraestructura será inútil y no podrás hacer nada, ya que todavía no hay forma de solucionarlo.
No está mal, ¿verdad? Creo que ahora ya todo el mundo entiende el porqué los sysadmin se echaron a templar
Uso y disfrute
Usar TOPERA es muy sencillo. Está hecho en python y es multiplataforma (aunque en Windows os irá muy lento si usáis el intérprete oficial de python: CPython).
Tenéis toda la documentación y ejemplos del estilo “copy&paste” (lo que más nos gustan, ¿verdad? ) en la web del proyecto que tenemos publicada en github: http://toperaproject.github.io/topera/
Por si sois algo perezosos, no tenéis ningún sistema con IPv6 a mano o, sencillamente, no os apetece bajar la herramienta para verla en acción, aquí os dejamos el video oficial que hicimos de demo:
Y, como pone un poco más arriba, a usarlo y disfrutarlo. Eso si! Con moderación y no la lieis demasiado
El firmware de algunas series de discos Seagate (especialmente la serie Barracuda 7200.11 y algunas series de Momentus para portátiles) vienen con un defecto que provoca que el disco se congele y deje de ser detectado por el PC. Para hacer frente a este problema hay diversas guías publicadas en la red, pero generalmente carecen de precisión en algunos conceptos y, en general, les falta claridad, así que he decidido redactar esta guía explicando el proceso de forma más fácil e inteligible.
El problema
Realmente, existen diversos casos distintos en los que el disco deja de funcionar. Entre ellos, los más comunes son:
Error LBA 0: En este caso la BIOS detecta el disco pero indica que su capacidad es de 0 bytes.
Error BSY: La BIOS no detecta el disco duro en absoluto, porque éste indica que está “ocupado” (BuSY)
Bloqueo del motor u otras averías físicas. En estos casos la solución no resolverá el problema, pero el proceso siguiente servirá para diagnosticarlo.
La causa
Un disco duro, además del espacio reservado a datos del usuario, contiene una partición especial dedicada a información de autodiagnóstico (SMART) que en situaciones normales se utiliza para marcar los sectores defectuosos y otros problemas encontrados. Esto sirve para evitar en lo posible fallos catastróficos, siendo el propio disco duro lo suficientemente inteligente como para evitar perder datos y/o avisar cuando está a punto de sufrir un problema grave. Pues bien, el firmware que viene con estos modelos de disco tiene un error que provoca que la partición de SMART se corrompa, dejando el disco inutilizable. Seagate publicó en su momento una actualización del firmware para estos discos que evitaba el error. La mala noticia es que esta actualización evita que el problema aparezca, pero una vez que el problema aparece es imposible actualizar el firmware. Por tanto, a no ser que seas un poco paranoico o que ya conocieras el problema con anterioridad, es muy poco probable que hayas actualizado el firmware sin encontrarte antes tu disco duro convertido en un bonito pisapapeles. Por supuesto, cuando el problema aparece los datos no se han perdido, ni muchísimo menos.
La solución
Dado que el origen del problema está en los datos de la partición SMART, la forma de solucionar el fallo una vez ha aparecido va a consistir en devolver esta partición a su estado de fábrica. Como el disco no es accesible, dado que la BIOS no lo reconoce, vamos a utilizar un puerto serie que incorporan estos modelos, que está ahí precisamente para tareas de diagnóstico y reparación de este tipo. Las conexiones del disco duro tienen más o menos esta apariencia:
Material necesario
Para realizar esta operación necesitaremos:
Un puerto USB libre en un PC
Un conversor de USB a UART, como éste:
También nos sirve un módulo Arduino, del que usaremos los pines GND, TX y RX con el mismo cometido
Tres cables de cobre, con terminales que nos permitan conectar el UART al disco. En nuestro caso hemos usado puntas de prueba (test hooks) como estas:
Destornillador torx T3 de precisión. Sólo es necesario para los discos de 3,5″.
Una fuente de alimentación con un cable libre de alimentación SATA. También nos sirve una caja de disco externa del tipo adecuado y un cable de alimentación SATA.
Procedimiento
1. (Sólo si el disco es de 3,5″) Desatornillamos la placa PCB del disco para desconectarla por completo de éste. Si nos saltamos este paso y el disco tiene el error de BSY, no podremos acceder a la consola de diagnóstico en el paso 7.
2. Conectamos el adaptador UART al puerto serie del disco.Puedes basarte en el código de colores de las imágenes:
PC-TX ==> HDD-RX
PC-RX ==> HDD-TX
PC-GND ==> HDD-GND
NO es necesario conectar el pin de VCC.
3. Conectamos el adaptador UART al puerto USB.
4. Conectamos la alimentación SATA al puerto SATA-Power del disco duro.
5. Abrimos putty (también puedes usar hyperterminal u otro programa de terminal, siempre que uses los parámetros adecuados) y nos conectamos al puerto serie correspondiente al adaptador UART, usando la siguiente configuración:
Velocidad(Speed): 38400 baudios
Bits de datos (Data bits): 8
Bits de parada (Stop bits): 1
Bits de Paridad (Parity): Ninguno/None
Control de flujo (Flow control): Ninguno/None
6. Accedemos a la consola de diagnóstico del disco duro, pulsando Control + Z (en putty). Aparecerá un prompt en la consola: F3 T>
7. Accedemos al nivel de operación 2, escribiendo /2↵. El prompt cambiará. F3 T> /2 F3 2>
8. Esperamos unos segundos, y detenemos el motor del disco (o le hacemos saber a la PCB que está detenido, si la tenemos desconectada del disco), enviándole la orden Z↵. F3 2> Z
Aquí el disco tardará un momento y devolverá un resultado. Si devuelve un error, es posible que hayamos ido demasiado deprisa. Vuelve a emprezar y espera más tiempo antes de enviar la orden de parada del motor.
9. (Sólo si hemos desconectado la PCB en el paso 1) Con cuidado de que no se desconecte ningún cable, volvemos a conectar la placa PCB al disco duro. Para ello, la colocamos en su sitio y la atornillamos al mismo, apretando bien todos los tornillos.
10. Esperamos unos segundos, y arrancamos el motor del disco, enviándole la orden U↵. F3 2> U
Aquí el disco tardará un momento y devolverá un resultado. El motor del disco debería girar (debería notarse vibración). Si devuelve un error, es posible que la PCB no esté bien conectada al disco (revisa los tornillos), o que el motor del disco esté bloqueado y no pueda girar. Esto son malas noticias (ver más abajo).
11. Accedemos al nivel de operación 1, escribiendo /1↵. El prompt cambiará de nuevo.
F3 2> /1 F3 1>
12. Reiniciamos los datos de SMART, enviando la orden N1↵ F3 1> N1 El disco tardará un momento y devolverá un resultado.
13. Volver al modo de operación T, mediante T↵ F3 1> /T F3 T>
14. Reiniciar la lista de defectos detectados en el disco, usando el comando i4,1,22↵. Este paso no siempre es necesario. F3 T> i4,1,22
Aquí el disco tardará un momento y devolverá un resultado.
15. Detenemos el motor del disco (para apagarlo con seguridad) y lo apagamos. Para ello:
Accedemos al nivel de operación 2, escribiendo /2↵
Detenemos el motor del disco, enviándole la orden Z↵.
Cuando el motor se haya detenido, desconectamos el cable de alimentación SATA.
16. Esperamos unos 10 segundos.
17. Volvemos a conectar la alimentación SATA
18. Volvemos a acceder a la consola de diagnóstico del disco duro, pulsando Control + Z F3 T>
19. Regeneramos la partición de SMART, con el comando m0,2,2,,,,,22↵ F3 T> m0,2,2,,,,,22
Aquí el disco tardará un buen rato antes de darnos un resultado. Esperamos a comprobar que el resultado es correcto.
20. Detenemos el motor del disco (para apagarlo con seguridad) y lo apagamos. Para ello:
Accedemos al nivel de operación 2, escribiendo /2↵
Detenemos el motor del disco, enviándole la orden Z↵.
Cuando el motor se haya detenido, desconectamos el cable de alimentación SATA.
Y después…
En este punto, ya hemos terminado de reiniciar los datos problemáticos. Si todo ha ido bien, el disco ya será detectado normalmente por la BIOS y podrá usarse sin problemas. Lo único que queda pendiente, a modo preventivo, es actualizar el firmware del disco duro para que el problema no vuelva a aparecer.
Qué hacer si el motor no gira
Si el motor de nuestro disco no gira (siempre responde con un error a la orden U en el punto 10 del procedimiento anterior), una de las causas más probables es que se encuentre bloqueado. Esto ocurre generalmente debido a un golpe o shock, o, con menos frecuencia, debido a un apagado brusco de la corriente. Llegados a este punto, si los datos contenidos en el disco son importantes, deberíamos enviar el disco al servicio técnico o a una empresa especializada de recuperación de datos. Sólo si esto no es posible y si los datos no son realmente importantes podríamos aventurarnos a desbloquear el motor nosotros mismos. Abrir un disco duro en un área no preparada específicamente para ello (debería hacerse siempre en una cámara de vacío) supone la muerte del mismo, por lo que, si estamos decididos a ello, debemos actuar rápido y con decisión y tener en cuenta que, una vez lo hayamos abierto, contaremos con poco tiempo para recuperar los datos antes de que éstos empiecen a degradarse. El bloqueo en este caso es físico, por lo que la operación consistiría en:
Equiparnos adecuadamente (mascarilla, gorro o redecilla para el pelo, guantes de latex o “finger cots”) para evitar dejar partículas de cualquier tipo en la superficie de los platos del disco.
Abrir el disco con los destornilladores torx apropiados.
Mover el brazo (34) a su posición de inicio (50), de forma que las cabezas de lectura/escritura (32) queden fuera de la superficie de los platos (10)
Obligar al rotor del disco (20) a girar, asegurándonos de que gira libremente y de que no tocamos ningún otro punto del disco.
A la hora de afrontar un análisis forense de dispositivos Android, una de las dificultades a las que nos enfrentamos es a que dicho dispositivo se encuentre bloqueado. En el siguiente artículo repasaremos las estratégias más utilizadas para evadir dicho bloqueo, incluyendo los tipos de elevación de privilegios, necesarios en muchas ocasiones.
Para comenzar, habría que repasar los 4 tipos de bloqueo del dispositivo que Android nos proporciona:
Slide (none). Es el modo más básico, simplemente realizando el gesto del desplazamiento el dispositivo quedará desbloqueado.
Pattern lock. En este modo se proporciona un patrón sobre los puntos marcados que debe seguirse para conseguir el desbloqueo del dispositivo. El único requisito sobre dicho patrón es que contenga al menos el paso por 4 puntos.
PIN. En este modo el usuario debe introducir un código numérico para desbloquear el dispositivo. El único requisito sobre el PIN es que conste de al menos 4 digitos.
Password. En este modo el usuario debe introducir con código alfanumérico para desbloquear el dispositivo. El único requisito sobre la contraseña es que conste de al menos 4 caracteres.
Los modos de bloqueo pueden configurarse desde las opciones generales, en el apartado de seguridad, en la opción “Screen lock”, como podemos ver a continuación:
Una vez clasificados los tipos, vamos a enumerar las diferentes aproximaciones para evadir estas protecciones: Smudge Attacks. En esencia se trata de ver las marcas físicas sobre la pantalla del dispositivo. Aunque a priori parezca un tanto cojido con los pelos, el hecho de tomar una fotografía de la pantalla y jugar con los cambios de colores, brillos, ponerla en negativo y demás pueden tener resultados muy satisfactorios. En el siguiente papper detallan esta aproximación desde una manera formal: http://static.usenix.org/event/woot10/tech/full_papers/Aviv.pdfPattern Lock Crack Evadir esta protección es muy sencilla solo si se tiene acceso al modo debug del dispositivo rooteado. En patrón se almacena en el dispositivo en forma de hash en el fichero /data/system/gesture.key, como podemos ver a continuación:
Si tenemos acceso ADB de root, podemos eliminar el fichero y crear uno nuevo vacío:
rm gesture.key touch gesture.key
A partir de ese momento, cualquier gesto desbloqueará el dispositivo. Si no tenemos acceso al modo debug, es posible a través de la interfaz JTAG, el proceso está descrito en el siguiente enlace: http://forensics.spreitzenbarth.de/2012/02/28/cracking-the-pattern-lock-on-android/Password Crack && PIN Crack Evadir estas protecciones es muy sencillo solo si se tiene acceso al modo debug del dispositivo rooteado. La contraseña y/o PIN se almacena en el dispositivo en forma de hash en el fichero /data/system/password.key, como podemos ver a continuación:
Si tenemos acceso ADB de root, podemos eliminar el fichero y crear uno nuevo vacío:
rm password.key touch password.key
A partir de ese momento, cualquier contraseña y/o PIN desbloqueará el dispositivo. La gracia visto lo visto es tener el dispositivo rooteado, pero rootear un dispositivo en el transcurso de un análisis forense entraña dificultades en el proceso, ya que el principio fundamental es que las modificaciones de la envidencia tiendan a cero. Vamos a repasar el proceso. Lo primero al acceder a un dispositivo es saber si somos root en el mismo, tal vez el usuario lo tiene rooteado. ¿Cómo saberlo manipulando lo menos posible el dispositivo? Lo más sencillo es conectar al mismo mediante ADB y ejecutar la siguiente sentencia:
adb shell su
Si como respuesta entramos a la shell, somos root, si obtenemos un “Permision denied” nos lo tenemos que ganar. Antes que nada, no pensemos que ser o no root es algo abosluto, en entornos Android tenemos diferentes tipos de rooteo, y no todos tienen las mismas implicaciones desde el punto de vista forense, por lo que debemos evaluar en cada caso cuál necesitamos y actuar en consecuencia.
Root permanente. Es el más habitual. Entramos al dispositivo y somos root, ¿porqué? Normalmente es así porque se ha habilitado alguna ROM personalizada o se le han proporcionado al dispositivo binarios ARM para comandos como “su“. La referencia es XDA Developers.
Root temporal. Se elevan privilegios solo hasta el renicio, normalmente tras aprovechar una vulnerabilidad en ejecución. Esta forma es ideal desde el punto de vista práctico, si bien entraña riesgos porque se va a modificar en dinámico, puede causar inestabilidad y aprovechar vulnerabilidades para elevar privilegios puede ser muy discutido desde el punto de vista del proceso.
A continuación indico un par de aplicaciones para conseguir este objetivo:
Root recovery. En este modo se habilita una particion de recuperación en el dispositivo que permite el acceso privilegiado solo cuando se carga dicha partición. Este tipo de rooteo es el más indicado para procedimientos forenses. La problemática es que cada fabricante maneja las particiones de recuperación de una manera diferente y en algunos casos no será trivial. A continuación dejo, por cortesía de @hidark, a modo de ejemplo el proceso para el modelo ASUS Transformer TF101: Arrancamos el dispositivo presionando los botones “power” y “subir volumen“, no ves nada en la pantalla, pero si la tienes conectada al PC puedes apreciar con un “dmesg” desde el PC que el dispositivo entró en modo APX:
As a forensic and malware analyst, I have always been a big fan of Volatility, the Python coded memory analysis tool that keeps growing day by day. Thus, since I readed the Michael Ligh’sarticle on his blog about the extraction of the ZeuS’ encryption keys, I was willing to try out the same thing with another malware family as well.
I’ve chosen Citadel in this case, that is one of the most widely used ZeuS’s variants since its source code leakage. Specifically the version 1.3.4.5 that, while not the last one, will be the basis for subsequent versions (although it is rumored that 1.3.5.1 could be the last we see) or other families.
When using Volatillity and Yara together, the power available for automatic malware processing increases. “zeusscan2“, one of the plugins resulting from the article mentioned above, is based on both things. It makes use of Yara rules against an infected machine’s memory to detect and access those memory regions that likely contains the information we want to extract from the binary file. This requires a thorough analysis on the family prior to “automate”, which in this case, being a variant of the well known and documented Zeus family, the work is limited to detecting differences within it.
As a start point, we know that ZeuS 2.X contains the following information embedded in the binary:
Initial config file download URL
RC4 key used to decipher the config file
Info about the location of the binary and his config on the infected machine
The first two can be found within the binary in a XOR encoded area with the bytes at the beginning of the last PE section, while the latter is an encrypted area using the RC4 key and with a fixed structure (For now on we will refer to it as the “magic object” to follow the convention used in the Volatility’s ZeuS plugin).
Note: In ZeuS’ case there’s a second RC4 encryption key contained in the last commented structure, but since Citadel lacks of it, is not relevant to the purpose of the article.
Thereby, the processing and extraction flow we are searching for should be something like:
Embedded config finding.
XORing with the bytes at the beginning of the last PE section to decode it.
RC4 key and initial config file download URL extraction.
Searching and decoding of the “magic object”
Rest of data extraction
Now that we know the base which supports Citadel, we can study the differences to adapt the plugin to the new family. The similarities (at binary level at least) are bigger than the differences, so once we understand it, the changes are not complicated.
The main difference comes from the cipher algorithm used to encrypt the downloaded config files (AES instead of RC4), but the “magic object” keeps RC4. The AES key, it’s not within the binary as so, but it’s calculated on runtime in the following way:
RC4(md5(BO_LOGIN_KEY))
The BO_LOGIN_KEY or binary key, is a 16 hexadecimal bytes key that can be found inside the binary and, in addition to compute the AES key, it’s used in the control panel communication, so to the localization of the embedded config and the “magic object”, we must add the hardcoded key.
To the workflow above, it should be added:
BO_LOGIN_KEY finding
AES key computing
With all of this, we can choose the following disassembled code to generate the new Yara rules that help us to find the commented variables in memory:
8BEC MOV EBP,ESP
83EC 0C SUB ESP,0C
8A82 00010000 MOV AL,BYTE PTR DS:[EDX+100]
8845 FE MOV BYTE PTR SS:[EBP-2],AL
8A82 01010000 MOV AL,BYTE PTR DS:[EDX+101]
8845 FD MOV BYTE PTR SS:[EBP-3],AL
8A82 02010000 MOV AL,BYTE PTR DS:[EDX+102]
B9 801A1300 MOV ECX,131A80 ; BO_LOGIN_KEY
8845 FF MOV BYTE PTR SS:[EBP-1],AL
E8 BEF2FFFF CALL 0015BC16
———————————————————————————
56 PUSH ESI
BA 54050000 MOV EDX,554 ; Embedded configuration length
I hope this example helps to understand a little better all the capabilities Yara and Volatility offers when automating and analyzing malware.
The plugin for the 1.3.4.5 version can be found here. Michael Ligh has also merged it with the previous versions of the ZeuS 1 & 2.X plugins, so from now on it will be shipped with Volatility too, though it won’t be enabled by default; Use the –plugins parameter to access them like this:
Regarding 1.3.5.1 version, the process to follow should be similar to the one described, except for a new hardcoded key and the size and structure of the “magic object”, that changes from sample to sample.
Los pasados días 30 de noviembre y 1 de diciembre se celebró en Albacete (España) la II edición de las conferencias de seguridad Navaja Negra con Buguroo como unos de los patrocinadores.
Estas conferencias de seguridad surgen como una iniciativa particular de profesionales de seguridad informática que desean intercambiar experiencias y conocimientos de forma libre e independiente.
Las jornadas fueron gratuitas y tuvieron un altísimo nivel con expertos en distintas áreas de la seguridad informática como exploiting, fraude, tecnologías móviles, reversing o seguridad en redes, entre otros.
Los contenidos tuvieron su componente teórico pero, sobre todo, un enfoque práctico con demostraciones en tiempo real realmente interesantes. Veamos un resumen de lo más destacable que se pudo vivir en esos dos días.
Puedes leer lo qué pasó el primer día aquí: Iniqua. Veamos un resumen de lo más destacable del segundo día.
Segundo día.
A brief introduction to reversing code with OllyDbg and other tools
Longinos (@L0ngin0s) nos introdujo en el apasionante mundo del reversing de una forma muy sencilla y para todos los públicos. De 0 a 100 en reversing en 50 fascinantes minutos.
Utilizando OllyDbg nos enseñó cómo hacernos nuestro propio crackme “Navaja Negra” de una pequeña aplicación hecha para la occasion. Sencillamente incredible.
From mail to jail: Exploit your ex-girlfriend
Geolocalización, Metasploit, Phishing… todas son palabras que conocemos de sobra, pero que siempre resulta entretenido e ilustrativo ver cómo alguien consigue, en 50 minutos, reunirlas todas y correlarlas para mostrar cómo ejecutar ataques orientados… a tu ex novia por ejemplo.
Joaquín Molina (@kinomakino) lo hizo, y de forma amena y simpática.
(in)Security in Mobile Communications
Charla de altísimo nivel técnico, difícil de seguir por aquél que no esté familiarizado con las tecnologías móviles y el 3GPP.
Ricardo Monsalve (@cenobita8bits) y Alfonso Moratalla (@alfonso_ng) comenzaron con una breve introducción teórica de algunos conceptos de GSM, para pasar pronto a la parte práctica y al espectáculo.
Con poco más que un móvil Motorola de pocos euros de valor, consiguieron algo que hizo que a todos nos recorriese un ligero escalofrío por el cuerpo… Interceptaron un SMS y una llamada en tiempo real…
IPv6 vs. IDS, se aceptan apuestas…
Daniel García a.k.a. cr0hn (@ggdaniel) y Rafael Sánchez (@r_a_ff_a_e_ll_o), se adentraron en el mundo del protocolo del Internet del futuro, es decir, de IPv6.
Esta vez le han buscado las cosquillas a los IDS encontrando una vulnerabilidad en las capacidades de detección del motor de Snort. Dos demostraciones prácticas se encargaron de mostrar las vergüenzas del mismo.
Se despidieron presentando de forma oficial el exploit “Topera”, capaz de realizar escaneos TCP que pasan inadvertidos por Snort, e invitando a todos a probarlo.
Los pasados días 30 de noviembre y 1 de diciembre se celebró en Albacete (España) la II edición de las conferencias de seguridad Navaja Negra con Buguroo como unos de los patrocinadores.
