'CRYPTERS': practicando la técnica dsplit/Avfucker

Tal y como ya adelanté, en este artículo vamos a poner en práctica lo que hemos aprendido hasta el momento sobre la evasión de Antivirus, en adelante AVs. En el último post de esta serie sobre 'Crypters', vimos los fundamentos teóricos de la técnica 'dsplit/AVfucker'. En este post voy a tratar de ilustrar esta técnica con un ejemplo práctico, valiéndome de un caso muy sencillo de aplicación de esta técnica.

Herramientas

Existen diversas herramientas que permiten aplicar la técnica 'dsplit/AVfucker', concretamente voy a utilizar una que es bastante cómoda, tiene muchas funcionalidades y es bastante rápida, pero si buscáis encontraréis otras por los foros relacionados con el tema. En concreto voy a utilizar 'UdTools Offset Locator 2.0'. También necesitaremos un anotador, así que voy a utilizar 'Antrax-Labs Offset Anotator' (by The Swash). Adicionalmente, utilizaré un 'Hex Workshop 6.7' como editor hexadecimal y 'OllyDbg' como disassembler (desensamblador).

Crypter

Para 'modear' un 'stub' hay que disponder del 'crypter' (tanto el 'builder' como el 'stub'). Es importante conseguir uno que sea 'original', es decir, que no haya sido 'retocado'. Trabajar un ejecutable previamente 'modeado' es siempre más complicado. Para este ejemplo voy a utilizar 'Simple Crypter 2010' (by DuNeD@i).

AV

Voy a utilizar para este ejemplo una 'firma' bastante sencilla del AV de origen Checo Avast (avast!). Ese, con esa voz tan sexy que siempre nos recuerda: "La base de datos de virus, ha sido actualizada". Lo primero que haremos, será configurar adecuadamente el AV para el proceso de 'modding'. Para ello, desactivaremos todos los 'escudos' en tiempo real y desactivaremos la opción de envío de muestras (En el caso de Avast hay que desactivar la opción 'Participa en la comunidad avast!')

Entorno de trabajo

Lo primero de todo es mantener una buena organización del entorno de trabajo. Para ello, vamos a trabajar en una carpeta en la crearemos varias 'sub-carpetas'. Una se llamará 'original' y en ella guardaremos el 'Crypter Original'. En otra carpeta guardaremos nuestro 'Anotador' y por último las dos más importantes, a las que se llamaremos 'offsets1' y 'offsets2', que funcionarán como carpetas de resultados en las que se almacenarán los diferentes archivos generados meadiante la aplicación de la técnica 'dsplit' y 'AVfucker'. En breve veremos el propósito de cada una de estas carpetas. Para comenzar a 'modear' necesitamos aplicar el 'crypter' a nuestro ejecutable de prueba, el 'anotador'. Para ello abriremos el 'builder' (llamado crypterx.exe en este crypter), y seleccionaremos el 'anotador'. Pulsaremos el botón 'Crypt' y se abrirá una ventana del explorador de archivos para indicar el nombre y ubicación del ejecutable. En este ejemplo lo llamaré 'modme.exe'.

Hey Ho Let's Go!

Dsplit

Ya tenemos todo lo necesario para aplicar 'dsplit' así que vamos allá. Abrimos 'UDTools Offset Locator 2.0' y arrastramos (o seleccionamos) el ejecutable 'modme.exe' al primer campo del formulario 'Archivo & Directorio'. En el segundo campo, arrastraremos el directorio 'offsets1'. A continuación, en la sección 'Método' seleccionamos 'DSplit'. En la sección 'offsets' veremos que los valores que se aparecen corresponden a el offset inicial: 1.000 (comienzo del ejecutable sin la cabecera PE) y el offset final del archivo (último byte del ejecutable), en ese caso 45.062. En la sección 'bytes', aparece por defecto el valor 1.000, que es el bloque de 'bytes' que vamos a usar en la primera iteración del proceso 'dsplit'. Si por algún motivo, nuestro archivo a 'modear' fuese mucho mayor, podríamos comenzar por bloques de '10.000' bytes, pero lo habitual es comenzar por 1.000 para que el número de archivos a generar y sobre todo a 'escanear' por el AV sea manejable. En general suele ser una buena idea seleccionar la opción 'Borrar todos los archivos del directorio seleccionado', de este modo, en cada ejecución lo primero que se llevará a cabo es el borrado del directorio seleccionado, por ahora 'offsets1'. Bien, pues ya solo queda pulsar el botón 'Iniciar' y se generarán en el directorio 'offset1' los archivos de tamaño incremental (1.000 bytes adicionales cada uno) desde el offset 1.000 hasta el offset '46.000'. 

El nombre de cada archivo, se corresponde con el offset en el que número de bytes añadidos al archivo, y del tamaño del bloque utilizado. Así pues tendremos: 1000_1000.exe, 2000_1000.exe, ..., 46000_1000.exe. 

A continuación, 'escanearemos' con el AV Avast la carpeta 'offsets1'. Pulsaremos botón derecho sobre la carpeta y seleccionaremos 'Analizar offsets1'. A continuación, nos aparecerá una ventana emergente de resumen del scan que indicará 'AMENAZA DETECTADA' y pulsaremos sobre el botón 'MOSTRAR RESULTADOS'. Nos aparecerá el detalle del análisis para cada fichero del directorio 'offsets1'. La firma que detecta es la misma en todos los archivos, en concreto: 'Win32:Malware-gen'. Si nos fijamos, veremos que no aparece ninguna detección de la firma hasta un offset concreto, en este caso el offset 11.000. A partir de ahí todos los demás offsets son detectados. Por tanto, sabemos que en el entorno del offset 10.000 el AV reconoce código malicioso y salta la detección de la firma. 

Vamos a precisar el offset concreto. Para ello, continuaremos con el proceso 'dsplit' en el entorno del offset 10.000. Volvemos a la aplicación 'UDTools Offset Locator 2.0' e introducimos el offset inicial 9.000 y el el offset final 11.000. Esto lo hacemos para evitar problemas con las zonas frontera. A continuación seleccionamos el valor de 'bytes' a 100, reduciendo un orden de magnitud respecto del valor anterior que era 1.000. De este modo, vamos precisando en cada iteración un poco más. Pulsamos el botón 'Iniciar' y se generan los archivos en 'offsets1'. Todos los archivos del proceso anterior se habrán borrado si la opción 'Borrar todos los archivos del directorio seleccionado' estaba marcada. 

Repetiremos el proceso de 'escaneo' mediante la opción 'Analizar offsets1' que nos aparecerá al pulsar el botón derecho sobre la carpeta. Una vez 'escaneada' la carpeta y desplegado el cuadro de 'MOSTRAR RESULTADOS' veremos que el primer offset detectado es 10.600. Una vez más volveremos a la aplicación 'UDTools Offset Locator 2.0' y seleccionaremos el rango 1.500 a 1.700 como offsets incial y final y reduciremos los 'bytes' de incremento a 10. Volveremos a 'escanear' y esta vez veremos que el primer offset detectado es 10.560. 

Una última iteración entre 10.550 y 10.570 con un incremento de 1 byte, nos indicará que el offset exacto en el que se detecta código malicioso es 10.552. Es decir, hasta el byte anterior el AV no ha sido capaz de detectar la firma, sin embargo, a partir del byte 10.552 ya la detecta. Parece lógico pensar que los bytes que definen la firma han de estar exactamente en el entorno de 10.552 pero no es así. La técnica 'dsplit' nos indica que en ese 'pedazo' de archivo seleccionado de 10.552 bytes el AV es capaz de detectar la firma. Mediante la técnica 'AVfucker' vamos tratar de localizar los bytes que conforman la firma. Para poder aplicar la técnica 'AVfucker' lo primero que haremos es copiar el archivo 10552_1.exe de la carpeta 'offsets1' a la carpeta de trabajo.

AVfucker

En la campo 'archivo' del formulario de la aplicación 'UDTools Offset Locator 2.0' teníamos nuestro archivo 'modme.exe', que es con el que hemos estado trabajando hasta el momento. Ahora arrastraremos el archivo 10552_1.exe a dicho formulario, ya que es sobre este archivo sobre el que vamos a aplicar la técnica 'AVfucker'. En el formulario 'directorio' no vamos a hacer cambios y mantendremos la carpeta 'offsets1'. En la sección 'Método' seleccionaremos 'Av-Fuck'. Veremos que ahora el offset inicial es 1000 y el offset final 10552, mientras que el rango de 'bytes' vuelve a ser 1000. La diferencia fundamental entre 'dsplit' y 'AVfucker' es que con 'dsplit' solo recortamos el ejecutable en secciones, mientras que con 'AVfucker' lo que hacemos es 'tapar' o 'rellenar' secciones del ejecutable con un valor determinado. Por tanto, en la aplicación 'UDTools Offset Locator 2.0' debemos indicar con que valor queremos 'rellenar'. podemos escribir el valor hexadecimal que queramos, siendo los valores '00' ó '90' los más usados generalmente. También podemos usar el botón 'A' para rellenar el campo con un valor aleatorio. El valor a escoger puede depender de varios factores, en general, '90' (instrucción NOP en ensamblador) es un buen valor de 'relleno' para comenzar. Pulsamos 'Iniciar' y se generan en 'offsets1' 10 archivos con sus respectivas zonas de 1000 bytes rellenos del byte '90'.

Ahora vamos a escanear 'offsets1' mediante el AV. Nos indicará 'AMENAZA DETECTADA' y si pulsamos 'MOSTRAR RESULTADOS' veremos que hay 9 offsets detectados. Ahora, lo que haremos, a diferencia del método 'dsplit' es eliminar los archivos cuyos offsets han sido detectados. Podemos indicar 'Aplicar esta acción a todos: Eliminar' y pulsar 'Aplicar'. Esto dejará en el directorio los archivos cuyos offsets 'indetectan' la firma. En este caso, solo queda uno, el archivo con offset 10.000. A continuación, desde 'UDTools Offset Locator 2.0' pulsaremos el botón 'Mostrar Offsets' y se mostrarán los diferentes offsets 'indetectados'. Si hacemos doble-clic sobre un rango concreto éste se agregará a la herramienta, y automáticamente se reducirá el rango de bytes para la siguiente interacción. En este caso, hay un único rango de 'indetección' por el momento, offset inicial 10.000, offset final 11.000 y bytes se reduce a 100. Si pulsamos de nuevo iniciar, aparece un aviso de que el offset 11.000 es mayor que el tamaño del archivo, si pulsamos aceptar se rellenará como offset final el valor correcto (10.552) y nos permite continuar. Pulsamos de nuevo 'Iniciar' y se generan los archivos en 'offsets1' que pasamos a escanear. Curiosamente, no nos detecta amenaza en ninguno de los archivos. Esto es no es habitual, pero en ocasiones ocurre que hay un rango muy grande de offsets que 'indetectan' la firma. Lo que podemos hacer ahora, es elegir uno de los archivos, por el ejemplo el primero de los offsets 'indetectados' y continuar reduciendo el rango de bytes hasta llegar a 1 byte. En realidad podemos trabajar con todo el rango, pero al ser tan grande vamos a generar muchos ficheros, especialmente al llegar a valores de un byte. Es preferible hacerlo por bloques. Por tanto, rellenamos con el valor 10.000 el offset inicial y 10.100 el offset final y reducimos a 10 el rango de bytes. Analizamos con el AV el resultado y nos detecta los offsets iniciales, pero deja 'indetectados' desde el 10.040 al 10.100. Reducimos a un byte y repetimos. Escaneamos y observamos que los 60 offsets 'indetectan' la firma.

Si miramos la zona con detenimiento y la ayuda de un editor hexadecimal, Hex Workshop en este caso, parece que se corresponde con algunas cadenas de texto. Para asegurarnos, examinamos también la zona con OllyDbg. Podemos probar a ir cambiando algunos de estos valores a ver si encontramos algún offset que mantenga funcional el ejecutable. Hay que tener en cuenta que hemos trabajado con un archivo recortado obtenido del proceso 'dsplit', por tanto, no es posible hacer pruebas sobre dicho archivo. Tendremos que hacer las pruebas de dichas modificaciones sobre el archivo ejecutable original al que habíamos llamado 'modme.exe'. Si hacemos una copia del mismo podemos probar a alterar manualmente algunos de los offsets para ver si nos deja 'funcional' el archivo, aunque también podemos continuar con el proceso 'avfuck' para localizar algún archivo funcional. 

Si estuviésemos ante una zona de código con instrucciones, lo más práctico sería aplicar técnicas como RIT o XOR para alterar las instrucciones de forma que se partiese la firma pero no se viese alterado el resultado del ejecutable. En este caso, como se trata de cadenas de bytes, es más práctico buscar alguna alteración de las mismas que no dañe el ejecutable. 

Lo que vamos a hacer es aplicar la técnica 'avfucker' sobre el archivo 'modme.exe' en lugar de trabajar sobre el archivo obtenido mediante 'dsplit' (10552_1.exe) y dejar los archivos resultantes en la carpeta 'offsets2'. Para ello arrastraremos el archivo 'modme.exe' y la carpeta 'offsets2' a los correspondientes campos de la herramienta y seleccionaremos el rango de offsets previo: 10.040-10.100. Pondremos el rango de bytes a 1 y seleccionaremos el relleno con '90'. Una vez tengamos los archivos en la carpeta 'offsets2' deberíamos eliminar de la misma aquellos cuyos offsets no 'indetectan' la firma. Hasta ahora, este proceso de eliminación lo hemos hecho mediante el 'escaneo' con el AV, pero hay que tener en cuenta que si hubiese alguna segunda firma el el archivo, el AV la detectaría y nos eliminaría todos los ficheros. Por lo tanto, lo que tenemos que hacer es eliminar de 'offsets2' los archivos que previamente hemos eliminado mediante la detección del AV de la carpeta 'offsets1'. En este caso concreto, todos los archivos del rango comprendidos entre el offset 10.040 y 10.100 están 'indetectados', y por ende la comparación de 'offsets1' y 'offsets2' quedará igual y no se eliminará ningún archivo, pero por regla general, esté proceso eliminará archivos de 'offsets2'. La herramienta 'UDTools Offset Locator 2.0' dispone de un botón en el menú superior que permite hacer está eliminación. Como en este caso no hay eliminación, probaremos a ejecutar cada uno de los archivos que se han generado en la carpeta 'offsets2'. Si alguno de ellos es funcional habremos roto la firma.

En nuestro ejemplo hay numerosos offsets en dicho rango que al ser rellenados con el byte '90' dejan funcional el ejecutable y por tanto 'indetectan' la firma.

Además no existe una segunda firma del AV para este archivo, sin embargo, en muchos casos, al conseguir tapar la primera firma, hay que continuar con el proceso 'dsplit' para localizar un segundo bloque de detección y volver aplicar AVfucker para localizar los offsets de las firmas adicionales.

Aplicar modificación al stub

Hay que tener en cuenta que hemos trabajado con el archivo 'modme.exe' para poder verificar su funcionamiento, pero en realidad lo que necesitamos es aplicar los cambios realizados al 'stub'. Para ello podemos hacer un copia del 'strub.exe' original y repetir los cambios realizados sobre 'modme.exe' también sobre el 'stub', o bien podemos extraer el 'stub' del archivo 'modme.exe'. Mediante un editor hexadecimal podemos llevar a cabo fácilmente esta operación. Simplemente es necesario conocer el tamaño del 'stub' original y seleccionar desde el primer byte hasta el tamaño final del 'stub' y guardar los bytes seleccionados a un nuevo archivo.

Como ya comenté al inicio, éste es un caso básico de eliminación de una firma de AV que sirve para ilustrar la técnica 'dsplit/avfucker' de una manera sencilla. Evidentemente hay multitud de firmas muchísimo más complejas que ésta, pero este ejemplo confirma la debilidad de algunas de las firmas que establecen los AVs.

Artículo cortesía de Abraham Pasamar

Leer más...

Enlaces de la SECmana - 194

• Genial triple entrevista en Genbeta con Chema Alonso, Alfonso Muñoz y nuestro compañero Yago Jesús sobre seguridad en Internet y la NSA.
• Un fallo de seguridad de Gtalk desvía mensajes a contactos equivocados. El fallo también afectaría a Google Hangouts.
• Retirada de la Play Store la aplicación que emulaba tener el sistema de mensajería iMessage de iOS en Android, tras comprobar que la aplicación no tenía nada que ver con Apple y ni siquiera pasaba por sus servidores.
• Parecía una inocentada pero no: Tras el fracaso del DNI electrónico, llega el DNI 3.0. El Gobierno espera que éste sí lo utilicen los ciudadanos.
• En el blog Ni ceros ni unos de Jesús Pérez, enumeración de extensiones SIP en Bluebox-NG, aplicación que nos presentó en este post en Security By Default.
• En el blog de Alienvault, Eduardo de la Arada publica un análisis del malware OSX/Leverage.a
• La noticia de la semana, el CCC esperó a la comercialización de los nuevos iPhone con lectura de huellas dactilares TouchID para demostrar que su sistema de copia de huellas del 2004 sigue funcionando todavía.
• Arrestado un joven en Londres sospechoso del ataque a Spamhaus en Marzo considerado el mayor ciberataque a Internet.
• Google refuerza la seguridad SSL en su navegador Google Chrome, reforzando los requisitos mínimos de cifrado así como mayor revisión de sus certificados para eliminar cuanto antes aquellos que hayan sido comprometidos.
• John McAfee, del cual se puede hacer una serie de televisión con su vida y andanzas, anuncia que pronto lanzará su próximo negocio, Future Tense, cuyo objetivo es el de crear una red más segura y fuera de los ojos de la NSA. ¿Será verdad? La web no tiene desperdicio...

Leer más...

Portspoof, o cómo atacar al atacante

¿Cuántas veces, revisando los logs de nuestros servidores, vemos intentos de conexión SSH, escaneos completos de sistema o escaneos web? Dado lo que es la justicia en Internet, ¿cuántas veces hemos cogido una IP que nos está dando brasa y la hemos contra-escaneado "a ver qué tiene"? En mi caso, reconozco que muchas veces lo he hecho porque, como será un nodo zombie de una botnet, quiero saber de una forma rápida quién me está arreando, por qué, y cómo se lo han cepillado a él previamente. Si detecto que tiene el TCP/3389 abierto, por ejemplo, tengo claro lo que hay,… A nivel IP, intento ver a qué organización pertenece y, si se puede, notifico que tienen, al menos, una máquina comprometida, que está atacando indiscriminadamente por Internet. En casos que no he podido identificar de quién se trata, incluso he estado tentado de acceder a la máquina por Terminal Services (si un bot pudo, yo también) y dejar de fondo de pantalla un mensaje indicando que han tenido un compromiso previo. Menos mal que revisando el código penal, se me pasan las ganas,… pero la culpa es de ellos por atacar primero!

Así pues, de la mano de Mike, un lector amigo de Costa Rica, llegaba a mis manos la existencia de una herramienta llamada Portspoof, que actúa a modo de Honeypot pero con capacidades ofensivas. Por una parte, en un sistema UNIX podemos simular un puerto concreto o incluso varios que por una regla de NAT entrante, redirija el tráfico que iba al puerto original hacia el puerto en el que escucha portspoof, por defecto el 4444 (mira que me suena ese puerto). Por otro lado, permite incluso contraatacar a la IP que hace el escaneo. Y os preguntaréis, ¿cómo ante un simple NMAP puedo responder de forma que logre incluso una shell en el equipo atacante? Pues en el video que aparece en la web de portspoof, y que os incorporo bajo estas líneas, se ve que si, en el Nmap que os lanzan, se han tomado la molestia de ejecutar determinados scripts NSE, en algunos casos, es posible hacer que portspoof devuelva un payload malicioso que fuerza la ejecución de código remoto o el envío de una shell desde la máquina atacante, imagino que con los permisos con los que se ejecuta nmap. 

Aunque no he probado la herramienta en profundidad, y parece que sólo permite hacer un honeypot de un único servicio por cada instancia de portspoof, me ha venido a la cabeza, una idea que me comentó Yago hace un montón de años. Se trataba de hacer un programa que "bindeara" un socket en todos aquellos puertos menores al 1024, que no fuesen servicios de verdad. Es decir, que si un sistema necesita tener como servicios escuchando en la red el SSH, HTTP y FTP por ejemplo, este programa crearía un socket en todos los demás puertos (o en unos cuantos). Cuando se recibiese un escaneo NMap normal (TCP SYN), el sistema devolvería que TODOS los puertos hasta el 1024 están abiertos. En aquella época, quizá fuese suficiente. Ahora con los anchos de banda disponibles, los escaneos son mucho más elaborados e incorporan, como bien cuenta Paulino Calderón en su libro "NMap 6: Network Exploration and Security Auditing Cookbook", infinidad de opciones y ejecución de scripts que hacen que NMap haya dejado de ser una herramienta puramente de reconocimiento, para jugar un papel mucho más ofensivo. 

Por ello, creo que una herramienta que combinase ambas ideas, la de "bindear" sockets en diferentes puertos, así como generar servicios fake aleatorios escuchando en los mismos, para confundir al atacante, podría ser francamente interesante. Si alguno de nuestros lectores se anima a hacerla, estaremos encantados de probarla y comentarla en SbD.

Leer más...

Mecanismos de autenticación-identificación. Vulneración y cracking de contraseñas

Hace algunos meses que no escribo asiduamente en el blog y con el paso del tiempo me he dado cuenta que crear nuevo contenido es tan complicado como estar en forma: una vez te tomas un descanso, volver es muy duro.

Afortunadamente en SecurityByDefault contamos con las estupendas contribuciones de muchos lectores y por supuesto, con la marcha firme de Yago, Lorenzo y Guasch. ¡Os envidio!

Tampoco es que este parado. He participado y estoy en mil batallas, que imagino, poco a poco iré contando por aquí. La más reciente es mi participación en el Curso Online de Especialización en Seguridad Informática para la Ciberdefensa, donde imparto partes de algunos módulos. 

El primero de ellos es de un par de horas y ya ha finalizado. Trataba sobre la autenticación y los ataques a contraseñas, para el que preparé una presentación y algunas demos que he subido a Youtube e incrustado dentro del documento.

El contenido es similar al que expuse en la RootedCon del 2011, pero ampliado y detallado; explicando algunos conceptos básicos y profundizando en otras partes. También hay alguna revisión, ya que algunas herramientas y procesos este par de años han cambiado.

Ahora estoy con otro módulo de Metasploit del que también he creado nuevo material que colgaré por aquí junto a sus demos. Si os gusta este ¡¡estad atentos!!

Leer más...

VUESTROS "ETHERNET EXPOSED" - XX

Seguimos recibiendo más y más fotos con vuestros ETHERNET EXPOSED, imágenes que realizáis a tomas ethernet que se encuentren expuestas en lugares curiosos, transitados, accesibles... y que posteriormente nos enviáis a nuestra dirección de contacto.

En la esta vigésima edición contamos con las contribuciones de Ivan Pereiro desde Bilbao, David Asorey desde Madrid y Victor.

Comenzamos con la contribución de Ivan Pereiro, la cual nos hizo llegar por twitter en un primer momento:

Como me pedísteis en twitter, os mando descripción del sitio donde encontré las tomas que mando en la foto adjunta. Están en un bar llamado "La antigua cigarrería" debajo de una tele al final del bar. El bar está junto a la plaza del ensanche en Bilbao. Un saludo.

Bueno, con tal maraña de cables, no sería complicado dejar ahí medio escondido un dispositivo conectado a algunas de las tomas ethernet disponibles. Habría que ver realmente a que sistemas tendríamos acceso, seguramente que a los relacionados con temas multimedia...

Continuamos con la contribución de David Asorey, el cual nos comenta lo siguiente acerca de una toma encontrada en un cajero:

Hola, buenos días, ante todo, quisiera felicitaros por vuestro blog, me encanta. 

El otro día, en un cajero automático en Madrid me encontré otro "EE", está en la calle Gran Vía, sobre el número 30. Es el típico cajero en el que el terminal está en un vestíbulo de la oficina. Os adjunto un par de fotos. Un saludo.

Quizás sea conveniente hacer que el cajero esté un poco más próximo a la pared, quizás haya tenido algún mantenimiento hace poco y no se ha dejado colocado como debiera...

Y hemos dejado el bombazo para el final. Tras el éxito de "un rack en mi baño", ahora llega a nuestras pantallas "un servidor y monitor en mi baño". Victor nos comenta lo siguiente:

ya no la conexión rj45... si no todo un servidor hp en el wc!!!

Podría estar apagado, pero aún así, no creemos que sea un sitio muy recomendable, aunque sea un simple aseo. Hay maneras de navegar por Internet en el baño mucho más cómodas que directamente acceder con el servidor (una tablet por ejemplo). Lo peor es que el servidor ¡se está usando para apoyar un papel higiénico! Y el ratón y teclado están perfectamente colocados, accesibles desde la taza.

Como siempre os decimos, nuestra dirección de correo sigue abierta a todas aquellas contribuciones de ETHERNET EXPOSED que os encontréis, ¡muchas gracias a todos y hasta la próxima!

---------------

[+] ETHERNET EXPOSED: Encuentra tomas de red al descubierto

[+] Vuestros "ETHERNET EXPOSED" - I

[+] Vuestros "ETHERNET EXPOSED" - II

[+] Vuestros "ETHERNET EXPOSED" - III

[+] Vuestros "ETHERNET EXPOSED" - IV

[+] Vuestros "ETHERNET EXPOSED" - V

[+] Vuestros "ETHERNET EXPOSED" - VI

[+] Vuestros "ETHERNET EXPOSED" - VII

[+] Vuestros "ETHERNET EXPOSED" - VIII

[+] Vuestros "ETHERNET EXPOSED" - IX

[+] Vuestros "ETHERNET EXPOSED" - X

[+] Vuestros "ETHERNET EXPOSED" - XI

[+] Vuestros "ETHERNET EXPOSED" - XII

[+] Vuestros "ETHERNET EXPOSED" - XIII

[+] Vuestros "ETHERNET EXPOSED" - XIV (edición Las Vegas)
[+] Vuestros "ETHERNET EXPOSED" - XV
[+] Vuestros "ETHERNET EXPOSED" - XVI
[+] Vuestros "ETHERNET EXPOSED" - XVII
[+] Vuestros "ETHERNET EXPOSED" - XVIII

[+] Vuestros "ETHERNET EXPOSED" - XIX
[+] Vuestros "ETHERNET EXPOSED" - XX

Leer más...

Consejos prácticos a la hora de integrar criptografía

Me encuentro a diario con personas (principalmente gente que desarrolla o administradores de sistemas) que se encuentran en el proceso de mejorar la seguridad de sus productos / sistemas implementando criptografía como aliada.

Muchas veces se da el caso que existe más buena FE que conocimiento a la hora de abordar esa tarea, y se cometen errores muy inocentes que tiran por tierra el esfuerzo de adoptar una solución por haberla adoptado incorrectamente.

En este post me gustaría compartir 'tips' sobre cómo abordar estos procesos para que deriven en un mejor resultado.

Almacenamiento de contraseñas

Este es el punto en el que más fallos se cometen, en muchos casos debido a que existe mucha información 'legacy' muy bien posicionada en Google a la que llega la gente y la usa como referencia.

Veamos consejos a la hora de realizar esta tarea:

• Olvida y entierra la tentación de cifrar la base de datos con una única contraseña y almacenar dentro las contraseñas en claro. No, ese esquema no es seguro, delegas toda la seguridad en una única contraseña que resulta fácil de obtener (por ejemplo revisando el código del programa que cargue esa base de datos). Nunca utilices criptografía reversible para guardar contraseñas

• Fundamental: OBVIA EL ALGORITMO MD5, sí, es seguro que vas a ver muchos ejemplos en Google que hablan de MD5, de hecho se sigue usando en otras tareas, pero nunca es aconsejable su uso para esta tarea. En su lugar usa SHA-512, penaliza el rendimiento con respecto a MD5, pero es algo imperceptible

• Emplea técnicas de 'salting' a la hora de almacenar el hash de la contraseña. Usar salt significa que, si la contraseña es 123456, en vez de guardar la representación de 123456 en su forma 'hasheada' lo que haces es introducir otro elemento que impida a un atacante usar un listado de hashes de contraseñas ya precompilado. Es decir, lo que guardas es salt+123456 que obviamente genera un hash diferente a 123456 (y que un atacante podría tener ya hasheado con lo que se ahorra el proceso criptográfico). En un típico esquema de usuario / contraseña para una aplicación web, es ideal usar el correo electrónico como salt ya que es un dato conocido y accesible (normalmente se envían correos de confirmación de altas) de forma que, en el ejemplo antes descrito, al final el hash se haría contra fulano@mengano.com+123456

• De nota: Usa PBKDF2 sobre los hashes que guardes. PBKDF2 es un estándar RSA para derivación de claves. Sin entrar en las profundidades matemáticas, lo que hace PBKDF2 es hacer más costoso el tiempo de computación de un hash. Los algoritmos de la rama SHA son algoritmos que han sido diseñados para ser rápidos, es decir, para que el costo computacional no sea elevado, eso, visto desde nuestra perspectiva, significa que los hashes que vamos a almacenar si usamos únicamente SHA se pueden atacar por fuerza bruta a un costo muy pequeño. Si usamos PBKDF2 lo que vamos a hacer es que, generar el hash, 'cueste' bastante más. Como decía al principio esto es de nota y SÍ va a tener un impacto notable a la hora de procesar peticiones de login en tu aplicación. Para una aplicación pequeña y que requiera máxima seguridad, ideal. Para un Facebook, probablemente no. Existen implementaciones de PBKDF2 en todos los lenguajes típicos

Cifrar datos

Vamos a abordar el tema de cifrar datos, una práctica muy deseable a la hora de trabajar con documentos o con datos.

• Evita el uso de los algoritmos DES y RC4. En el caso de DES principalmente porque hay alternativas mucho mejores en cuanto a algoritmos de cifrado 'de bloque', el tiempo que inviertas en implementar uno mejor, va a ser idéntico a usar el desfasado DES. En el caso de RC4 la cosa cambia, es un algoritmo 'simpático', muy fácil de implementar al ser 'de flujo'. No requiere complicarse y por tanto resulta tentador usarlo (honestamente, para un desarrollo cuyo nivel de seguridad sea bajo puede ser una opción)

• Cuando uses un algoritmo 'de bloque', como AES, GOST o Blowfish, siempre usa el modo 'CBC' que impide que un mismo dato tenga el mismo aspecto en diferentes puntos de los datos cifrados. Si usas, por ejemplo, el modo ECB, significa que la representación cifrada de 'securitybydefault' siempre tendrá el mismo aspecto una vez cifrado, lo que puede facilitar el criptoanálisis. 

• Algoritmos deseados: AES, Blowfish y si te fías de los rusos, GOST

Desplegar SSL

Vamos con la forma más optima de desplegar un servicio bajo SSL

• Usa certificados de 2048 bits. Ahora es lo mínimo exigible, de hecho, muchas CAs no admiten peticiones por debajo de esa longitud.
• Mejor certificados EV que certificados convencionales. Eso sí, son más costosos en tiempo y dinero. Siempre puedes empezar con uno tradicional e ir preparando los requerimientos de un certificado EV.
• Deshabilita SSL v2. Hoy día no existen razones reales de compatibilidad que hagan necesario el uso de esa versión del protocolo
• Obvia algoritmos de baja calidad, en concreto RC4, aunque lo deseable es configurar tu servidor para que solo use algoritmos de alta seguridad
• Habilita en tu servidor el uso de 'HTTP Strict Transport Security' esto instruye al navegador para que, una vez visitado un sitio bajo SSL, se niegue a hacerlo bajo HTTP lo que protege a tus usuarios de ataques 'sslstrip'

Leer más...

Y tú, ¿Ya has recibido una llamada de la NSA para troyanizar tu software?

El 'affaire' de la NSA rebelado por Snowden me recuerda al caso del vecino 'rarito' de la escalera, un día se descubre que tiene 10 cadáveres embalsamados en su trastero y a raíz de eso, todos los vecinos tienen una historia que contar.

Después del caso linux y su sistema de entropía, han saltado a la palestra más historias oscuras.

TheRegister ha publicado un artículo en el que pone sobre la mesa nombres y apellidos de gente que han sido 'tocados' de forma directa o indirecta para sugerirles lo ideal que sería colocar algún tipo de 'puerta B'. Obviamente hablamos de gente que está vinculada con el mundo de la criptografía de una forma directa o indirecta.

La mecha prende a raíz de un vídeo en el que a Linus se le pregunta si ha recibido 'presiones' para insertar un backdoor en Linux, de una forma muy cómica, Linus dice que no, pero asiente con la cabeza.

Quien sí admite abiertamente haber recibido 'un toque' por parte del gobierno de EEUU es Peter Biddle ex-desarrollador de Microsoft que tuvo un papel muy activo en el desarrollo de Bitlocker, el mecanismo que ofrecen los sistemas Microsoft para cifrar el disco duro. 

Por lo visto abordaron a Peter y le dijeron que sería genial poder disponer de un método de acceso a los datos en casos de pornografía infantil.

Otro que también admite haber recibido 'el toque' es Nico Sell, a la postre el desarrollador de Wickr una herramienta para compartir información que se publicita con un explicito 'Leave no trace'

Sería genial que alguien en España se decidiese a dar el paso y contar si aquí también dan 'el toque' 

Leer más...

Enlaces de la SECmana - 193

• Entrevista "Un minuto sin 010101 con Jose Antonio Guasch" en el blog Estación Informática realizada a un servidor.
• Un contrato hecho público muestra como la NSA compró el año pasado una suscripción al servicio de 0days proporcionado por la firma francesa VUPEN. ¿Sorprendidos?
• Noticia resumen en ComputerWorld acerca del Congreso Internacional de Seguridad en Pereira 2013 en el que participó nuestro compañero Lorenzo.
• Un soldado destinado en las Islas Canarias ha descubierto un importante fallo de seguridad que permite burlar la pantalla de bloqueo mediante código de iOS 7.
• FireEye, la empresa de seguridad especialista en prevención de APT y malware avanzado, sale a bolsa siendo su debut uno de los mayores récords, con más de 16$ por acción.
• El lanzamiento del juego para consolas y PC de Grand Theft Auto 5, además de suponer un gran beneficio para su empresa Rockstar, trae consigo una oleada en forma de campaña de malware escondida tras los generadores de serials y otros fraudes.
• Clientes de LinkedIn denuncian que sus cuentas de correo podrían haber sido comprometidas por dicha red social, para obtener información de contactos y propagar sus campañas de malware.
• Apple ha publicado una actualización de seguridad para su navegador Safari (versión 5.1.10) que solventa dos vulnerabilidades que podrían ser aprovechadas por un atacante remoto para lograr el compromiso de los sistemas afectados.
• Segunda parte de la serie de posts sobre todas las herramientas de hackers que un CISO necesitaría entender y conocer. La primera parte la podréis encontrar en este otro post.
• Aumenta el nivel de alarma de seguridad en Internet debido a un posible exploit in-the-wild circulando contra la vulnerabilidad de ejecución remota en Internet Explorer

Leer más...

Defiende tu sistema Windows ante ataques de fuerza bruta con RdpGuard

Uno de los ataques que más problemas está creando en el 'Mundo Microsoft' son los ataques por fuerza bruta al servicio RPD (terminal server)

En muchas de las infecciones por Ransomware el origen es un ataque de fuerza bruta que ha conseguido comprometer una cuenta de administrador y luego de eso, vía libre para hacer y deshacer en el sistema.

En el 'Mundo Linux' hemos disfrutado desde hace mucho tiempo de una aplicación tan potente como Fail2Ban que monitoriza los intentos de fuerza bruta y permite aplicar acciones sobre ellos.

Buscando una alternativa para servidores Windows, llegué hasta 'RdpGuard' una herramienta que permite monitorizar ataques de fuerza bruta a RDP y no solo eso, también a ftp y a SQL Server.

La aplicación se instala de forma fácil a golpe de ratón

Pulsamos 'Next'

Aceptamos la licencia

Seleccionamos donde queremos instalar la aplicación

Elegimos qué usuarios van a ver la interface de administración

Y ya está, ya tenemos listo RdpGuard

Una vez que se detecte algún intento de fuerza bruta, podemos consultar desde la interface gráfica la IP que nos ha atacado y el tiempo de bloqueo

El tiempo de bloqueo es configurable según lo que estimemos necesario

Para más información podéis ir a la página web del proyecto

Leer más...

Navega a través de TOR desde tu dispositivo iOS

A principios del 2011 en el post "Instalando TOR en iPhone: Privacidad con WiFi y GPRS/3G" indicábamos cómo poder navegar anónimamente desde nuestro dispositivo iOS (iPhone, iPad...) a través de la red TOR, tanto estando conectados vía wifi como mediante conexión de datos. Para esto último, requeríamos utilizar un servicio de VPN gratuito sobre el que viajarían nuestras conexiones tras habernos conectado a la red TOR. Además de la complejidad, la única manera de disponer de Tor era teniendo el dispositivo con Jailbreak.

Con la aplicación de la que os hablaremos en este post, ya no será necesario el llevar a cabo varios pasos, siendo posible obtener una conexión anónima a través de Tor.

Onion Browser consiste en un pequeño navegador web (para nada se asemeja a la versión móvil de Safari, ya que sus funcionalidades son restringidas) que permite tunelizar las peticiones realizadas a través de la red Tor.

Si bien no ha sido desarrollada por el propio equipo del Tor Project, obviamente está basada en la herramienta del proyecto, y además el desarrollador, Michael Tigas, ¡pone a nuestra disposición el código fuente de la aplicación! 

Las grandes ventajas de esta aplicación, frente a soluciones alternativas son:

- No es necesario un dispositivo con jailbreak instalado.

- Funciona tanto para conexiones mediante wifi como GPRS/3G, ya que se trata de un navegador normal.

- Permite el cambio de user-agent directamente desde las opciones del navegador.

Pero como todo, también tiene algunos inconvenientes...

- No es gratis, aunque su precio no pase de un euro.

- No ofrece privacidad máxima y absoluta, debido a, por ejemplo, ciertas limitaciones con el SDK de iOS. 

Una vez instalada la aplicación, ejecutamos haciendo clic en el icono, y el navegador restringido comenzará a negociar la conexión a través de la red Tor.

Tras finalizar el establecimiento de red, podremos hacer uso de los enlaces presentados para conocer la nueva dirección IP que se nos ha establecido, y mediante la cual navegaremos.

Recordad que para conectarnos a través de Tor en dispositivos Android, podéis acudir al siguiente post sobre la aplicación Orbot, disponible en la Play Store, o incluso recurriendo a Orweb, siendo este también un navegador que incluye la conexión establecida.

La aplicación Onion Browser está disponible por 0,89€ y está programada tanto para iPhone como para iPad, requiriendo una versión de iOS 5.1 o superior.

[+] Página principal de la aplicación OnionBrowser | Enlace a AppStore

Leer más...

¿Nos fiamos de los rusos?

Hubo un tiempo, durante la guerra fría, que todo lo 'Occidental' tenía su réplica en la URSS, o tal vez, a ojos de un Ruso, todo lo Ruso tenía su réplica en Occidente.

En el caso de la criptografía sucedió exactamente lo mismo, mientras el bloque occidental implementó los algoritmos que actualmente sustentan toda la seguridad en Internet a nivel global, los genios matemáticos Rusos hicieron su propia aproximación al problema de cifrar los datos en un mundo moderno.

El resultado de sus investigaciones fueron los algoritmos GOST, tanto a nivel cifrado como a nivel hash.

Adicionalmente existen implementaciones de GOST para clave pública y clave privada más actuales (2001) basadas en curvas elípticas.

Estos algoritmos han sido literalmente ignorados -a propósito o no- a la hora de diseñar la seguridad de Internet.

No verás los algoritmos rusos a la hora de pedir una página bajo SSL, tampoco los verás cuando uses un certificado digital. Los algoritmos que verás son aquellos que han sido apadrinados por occidente.

Y ahora la pregunta del millón: ¿Pero los algoritmos GOST son seguros? Como todo en criptografía es un 'depende'. Se han hecho avances significativos en el criptoanálisis de GOST -obvio- pero igual que se han realizado avances en prácticamente cualquier algoritmo.

Si consultamos a los expertos, a Bruce Schneier parece que le convence: "Against diferential and linear cryptanalysis, GOST is probably stronger than DES" (cita del libro Applied cryptography)

Se pueden consultar informes técnicos sobre la viabilidad de GOST como este.

¿Y por qué no se han incluido estos algoritmos en SSL/TLS? Esta pregunta se la lancé a Ivan Ristic, y me facilitó un enlace a un olvidado draft de un RFC que proponía su inclusión. No parece que se hayan promovido más iniciativas al respecto.

En este sentido cabe destacar las muchas fuentes que apuntan a que SSL ya está roto por parte de la NSA

Afortunadamente, GOST sí se encuentra bastante bien implementado en muchas librerías, OpenSSL tiene soporte para GOST.

También hay librerías en Perl o Python, con lo que cualquier persona puede usar esos algoritmos en sus proyectos.

Lamentablemente este algoritmo no se encuentra disponible, por ejemplo, en TrueCrypt, ni tampoco en Luks (cifrado de discos para Linux) o la CryptoAPI de Windows

¿Es hora de plantearnos el uso de algoritmos no 'tutelados' por EEUU/NSA?

Leer más...

RadioGraPhy 2.0

Hace algún tiempo presenté en sociedad RadioGraPhy, una herramienta que llevaba un tiempo usando de forma privada para hacer investigaciones forenses.

Esta herramienta es útil a la hora de 'radiografiar' un sistema Windows y extraer la máxima información posible.

En esta ocasión presento la versión V 2.0 que trae como novedad la posibilidad de extraer una copia de todos los binarios en ejecución y un backup del visor de eventos.

La idea es ejecutarla en un sistema sospechoso y llevarte la información para analizarla en el lab.

Se le ha añadido a la versión 'cli' el flag -c (no tiene mucho sentido añadir esta funcionalidad el frontend gráfico) que ejecuta la tarea de capturar esas evidencias.

Esto generará una carpeta llamada 'Evidences' y dentro de ella 'Eventlog' y 'Processes' 

Dentro de 'Eventlog' estará el backup del visor de eventos y dentro de 'Processes' una copia de los binarios que se estaban ejecutando en el sistema (de momento no los asociados a servicios)

Tampoco está de más recordar la lista de funcionalidades de la versión 1.0

RadioGraPhy obtiene los siguientes datos:

• Las claves del registro asociadas al auto-arranque de procesos

• Las claves del registro asociadas a la configuración de IE

• Las cuentas de usuario del sistema

• Los ficheros en directorios 'startup'

• Los servicios del sistema

• El contenido del fichero 'hosts'

• Los 'task' del scheduler de windows

• Los drivers o módulos cargados en el Kernel de Windows

• Carpetas compartidas por NetBios

• Ventanas ocultas (cmd y IE)

• La lista de procesos activos en el sistema y el path del ejecutable

• Información relacionada con la red (puertos abiertos, conexiones, etc)

La herramienta la he liberado totalmente 'Open Source' y se puede descargar desde aquí

Leer más...

Enlaces de la SECmana - 192

• En el blog de Trendmicro, Peter Pi investiga la seguridad de Firefox OS
• En Bitelia nos comentan cómo integrar el servicio eGarante con el software Evernote, muy buenos aliados que facilitan la tarea de tu tercero de confianza. 
• Robert David Graham, más conocido como ErrataBob, nos comenta cómo ha escaneado todo el direccionamiento público de Internet para obtener información sobre los servidores SSH disponibles a través del puerto 22. Para ello, ha utlizado un programa similar en velocidad a Zmap o ScanRand llamado MasScan, cuyo código está disponible en Github.
• Publicados más videos de Rooted CON 2013, esta vez toca el turno de los proyectos presentados en RootedForge, como son el correspondiente con la metodología OWISAM por parte de Andrés Tarasco, la preparación de GSICKMINDS 2013 y el plugin de Firefox PopUp Logout a cargo de Francisco J. Gómez. 
• El FBI admite que controló servidores de Tor a través de un ataque masivo con malware... ¿Sorprendidos?
• Michael Horowitz en Computer World nos recuerda cómo Google, mediante su copia de segurida de Android en la nube, podría almacenar las contraseñas de las redes inalámbricas almacenadas en texto plano, además de otros datos del teléfono.
• Campaña masiva de phishing en Alemania contra millones de clientes de Vodafone a los cuales fue posible obtener sus datos personales.
• Actualización importante en Wordpress en su actualización 3.6.1 que corrige, entre otras vulnerabilidades, una crítica de ejecución remota de código en PHP por no evitar la serialización.
• Chema Alonso, en El Lado del mal, entrevista a LUN4T1C0, un ex-defacer
• Pedro Sánchez en Conexión Inversa nos recopila una lista de herramientas para realizar análisis forenses.

Leer más...

III Edición del Congreso Navaja Negra

Los días 3, 4 y 5 de Octubre, tendrá lugar en Albacete la tercera edición del Congreso de seguridad Informática "Navaja Negra".

Este congreso, que ha acrecentado su relevancia a pasos agigantados, es además uno de los más esperados por el sector de la seguridad española. 

Con un cartel de ponentes genial, con cracks de la seguridad como David Barroso, Jaime Peñalba, Dani Kachakil, Alejandro Nolla, Jose Selvi, Sergi Alvarez "pancake", Manu Quintans, Juan Garrido, Jose Luis Verdeguer, Marc Rivero, Daniel Martínez, Pedro Candel, Daniel García, etc,... el evento tiene que ser sobresaliente!!!

De hecho, tal y como os comenté hace unos días, y como no me pierdo ni uno, será un placer asistir por primera vez al Navaja Negra Conference como ponente junto a esta pila de enormes colegas.

Aparte de las más de 20 charlas, el final del evento culminará con una mesa redonda entre Cuerpos y Fuerzas de Seguridad del Estado (David Pérez de la Brigada de Información Tecnológica de la Policía Nacional y César Lorenzana del Grupo de Delitos Telemáticos de la Guardia Civil), Pablo F. Burgueño como abogado "del diablo" y varios invitados 'sorpresa'... donde se generará un debate donde "casi todo" estará permitido, por lo que pediremos que entren con armas de fuego en el recinto (a los contendientes de ambos bandos...). Para cerrar el congreso, hay prevista una comida típica manchega.

Podéis ver el itinerario completo del congreso en http://navajanegra.com/itinerario.aspx

Como he dicho en más de una ocasión, para mí un evento no es sólo la riqueza aprendida en las diferentes charlas, sino el ambiente que se respira. Tanto en los eventos en los que participo en Latinoamérica, como en España, la experiencia de compartir buenos momentos con cracks de uno y otro lado del charco, para mí, es algo que hay que vivir!   

La organización ofrece descuentos para aquellos que se desplacen vía Renfe y ha negociado descuentos con diversos hoteles para el alojamiento. Toda la información, así como la forma de apuntarse (a partir de las 11) en la página web de Navaja Negra

Leer más...