30 septiembre 2013

'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...

29 septiembre 2013

Enlaces de la SECmana - 194

Leer más...

28 septiembre 2013

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...

27 septiembre 2013

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...

26 septiembre 2013

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!

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

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

Leer más...

25 septiembre 2013

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. 
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...

23 septiembre 2013

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...

22 septiembre 2013

Enlaces de la SECmana - 193


Leer más...

20 septiembre 2013

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...

19 septiembre 2013

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.
Leer más...

18 septiembre 2013

¿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...

16 septiembre 2013

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...

15 septiembre 2013

Enlaces de la SECmana - 192

Leer más...

13 septiembre 2013

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. 


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...

12 septiembre 2013

OWASP ZAP 2.2.0 is out !

OWASP ZAP, una de las herramientas absolutamente indispensable en el arsenal de cualquier pentester, acaba de liberar su versión 2.2.0

Esta fabulosa herramienta, que además es gratuita, no para de progresar y añadir nuevas funcionalidades. Un enorme ¡GRACIAS! a OWASP por hacer que el proyecto crezca y siga adelante.

Esta versión trae interesantes novedades como por ejemplo soporte para Mozilla Zest, un motor de scripting orientado a herramientas de seguridad en entornos web

Así mismo también han integrado soporte para 'Plug-n-Hack', un estándar promovido por Mozilla para definir una forma elegante y funcional de integrar herramientas de seguridad en el navegador.

Adicionalmente se han hecho -literalmente- un montón de correcciones de fallos y se han añadido nuevas funcionalidades, se puede consultar la lista entera aquí

Y luce tal que así


Podéis descargarlo desde aquí
Leer más...

10 septiembre 2013

Una entrevista diferente





A lo largo del tiempo que llevamos con Security By Default, son muchos los correos que nos llegan por parte de nuestros lectores, con inquietudes de diversa índole. Desde peticiones del tipo "Quiero hackear el Whatsapp de mi mujer,.. os pago lo que sea!", solicitudes de periodistas que piden nuestra opinión para algún artículo de actualidad, hasta correos con entrevistas completas que, aunque demoremos más de la cuenta, intentamos contestar a todos. 

Hace tiempo, me llamó especial atención las cosas que me preguntaba Conrado Toledo desde México y, como muchas veces coincide con lo que más lectores nos preguntáis, he creído conveniente compartirla con vosotros, por si puede aportaros algo.



Estimado Ing. Lorenzo Martínez.

Me llamo Conrado Toledo, estudiante de la carrera en Informática para la universidad UTEL en la ciudad de México. Le escribo para solicitar su valioso en la realización de una pequeña entrevista.

Tengo entendido que forma parte de una importante consultora en temas de sistemas informáticos, lo cual me resulta de gran interés por lo que me tome el atrevimiento de seleccionarlo solicitando un poco de su tiempo para atender una pequeña entrevista, a través de las siguientes preguntas:


Antes de que empiecen las preguntas, hago un inciso aquí. La "prestigiosa consultora" a la que te refieres es mi propia empresa, Securízame (www.securizame.com) y yo la definiría como una empresa humilde, con un equipo con mucho conocimiento técnico e ilusión por hacer las cosas bien. Es decir, que no estás hablando con una Big Four, con un edificio de 50 pisos de oficinas, en la que si necesitas comprar material por valor de $100.000, imprimes la orden de compra y ya está, sino que es una compañía con recursos humanos limitados, con un gran trabajo hecho en su primer año de vida, que actualmente se encuentra en plena carrera de despegue, y a punto de alcanzar la velocidad de rotación necesaria para abrirse a proyectos aún mayores.


a) ¿Cómo se construye una carrera exitosa?


Aquí lo único que puedo decirte Conrado, es que te hacen falta dos cosas: Esfuerzo y suerte. Y no sacas nada con tener una sin la otra. Tienes que tener suerte, estar en el momento adecuado en el sitio adecuado, pero si te duermes en los laureles y esperas que el trabajo te llegue a casa, mal. Hay que hacer mucho ruido y darte a conocer. Asistir a eventos, aunque no siempre como ponente, sino que muchas veces la humildad de saber aprender de las ideas y líneas de investigación de otras personas, es fundamental para llegar a ser un profesional bien formado. Por otra parte, esfuerzo. No sacas nada con tener toda la suerte del mundo, si no te esfuerzas. Si no te levantas cada día con la ilusión de afrontar nuevos proyectos, aprender nuevas tecnologías y pegarte con quien sea por defender lo que tú consideras un planteamiento correcto y justo.


b) ¿Qué habilidades y competencias profesionales fundamentales debe desarrollar un profesional en la rama de la informática para tener éxito?


Desde un punto de vista técnico, hay dos formas de afrontar las cosas, el generalismo y la especialización. El generalismo, implica que más o menos sepas de todo. Esto he comprobado que en informática hay tantísimas ramificaciones que habrá individuos contados con los dedos de las manos en todo el Mundo, que puedan decir que saben de todo. Yo, por supuesto, no soy uno de ellos. Me queda muchísimo por aprender y es un reto que tengo totalmente perdido. Es decir, sé que cada día se descubren más cosas, se publican más tecnologías, de las que mi cerebro es capaz de asimilar,... así que nos elegimos la otra vía: la especialización. En mi caso, como inicialmente intenté abarcar todo, hasta darme por vencido, he logrado aprender muchas cosas de diferentes ramas a lo largo de mi experiencia profesional. Así, las áreas en las que más he profundizado son seguridad perimetral, redes, auditoría y análisis forense. 

Desde un punto de vista personal, no pierdas de vista que por encima de todo somos seres humanos, responsabilidad y sinceridad. Esto lo creo aplicable a cualquier trabajo, por lo que no es nada nuevo. Responsabilidad por sacar el trabajo adelante, no dejarlo tirado aunque sea la hora de salir, si has adquirido un compromiso, ya sea con tu jefe o con un cliente. Si eres consciente que un proyecto no se puede terminar en el tiempo propuesto (muchas veces el tiempo que ha vendido un comercial que no conoce lo que hay que hacer por debajo), lo más importante es decirlo. Hacer ilusionarse a un jefe o un cliente con que un proyecto estará terminado en un plazo irreal, o con unas especificaciones que son ciencia ficción es lo peor que se puede hacer en el mundo profesional.


c) ¿Qué esperan los empleadores de un egresado de ésta disciplina?
Pues a día de hoy, en México donde creo que aún hay posibilidades laborales, supongo que sangre fresca con una base técnica mínima y a los que formar en una serie de tareas o proyectos que requieren un esfuerzo humano que es capaz de asumirlo. En España, lo tengo claro, un recurso barato al que explotar pagándole cuanto menos mejor. Y que no se queje porque en la puerta hay más gente esperando deseoso de cobrar una moneda de un euro al mes, por un trabajo. Es muy triste, pero es así. En Securízame he tenido casos de gente que me ha enviado correos diciéndome que estarían dispuestos a trabajar GRATIS, únicamente por ganar experiencia! Por supuesto me he negado a ello. Creo firmemente que el trabajo que hace una persona, si le pone toda su ilusión y esfuerzo, hay que recompensarlo con un sueldo que sea adecuado. Evidentemente, hay que adaptarse a las situaciones y el mercado, pero jamás le pagaría a una persona por la realización de una tarea menos dinero del que yo mismo aceptaría por hacerla.

d) Alguna recomendación, sobre las cualidades que debe tener una persona exitosa en esta disciplina.
Creo que te las he respondido en las anteriores preguntas

e) ¿Cuáles son los retos más complicados a los que se enfrenta un profesional de esta disciplina?


Supongo que aquí podría decirte que el reto más complicado es quedarte convencido que el cliente para el que haces un trabajo se queda satisfecho. Se queda contento sabiendo que la solución que le has implementado, vendido, desarrollado,... es lo que él necesita y que quien te lo ha servido, ha hecho un buen trabajo, ha aprovechado las posibilidades de la solución o ha sabido encontrar la solución al problema. Retos complicados se te presentan en una auditoría, cuando llegas al cliente con un informe en el que explicas lo que has hecho, pero no demuestras la existencia de ninguna vulnerabilidad grave; o cuando te entregan un material para peritar, para hacer un análisis forense, y te faltan datos vitales que te permitan evidenciar la implicación o inocencia de alguien... La sensación de tener que explicar a un cliente que no ha sido posible sacar lo que espera recibir, con plenas garantías, o no ir con su base de datos extraída mediante técnicas de hacking, te hace pensar que hay algo que no has hecho correctamente. El trabajo puede estar bien hecho. Simplemente que si el disco duro que te entregan está totalmente destrozado, o lo que tienes que auditar es una web estática y simple, el buen trabajo es explicar al cliente qué técnicas has utilizado y qué estándares has seguido, aunque el resultado haya sido infructuoso. Y ojo que en el caso de una auditoría en el que no encuentras nada grave, muchos clientes respiran aliviados al salir de la reunión de presentación de resultados. Sin embargo, uno como técnico espera poder haber dado con algo. El reto aquí es no venirse abajo y saber que has hecho lo que estaba en tu mano lo mejor que sabes.


Leer más...