30 noviembre 2011

Whisper Systems & Twitter & Egipto

Ayer recibíamos con sorpresa la noticia de que la empresa de Moxie MarlinspikeWhisper Systems había sido adquirida por Twitter.

La sorpresa inicial viene dada por lo poco que, a priori, casan ambos conceptos, twitter una red social y Whisper Systems que principalmente se dedica a la seguridad en dispositivos Android.

Hasta aquí, simplemente una buena noticia por el hecho de que todo un Twitter se interese realmente por la seguridad fichando 'caviar'.

La sorpresa desagradable ha llegado en forma de artículo en 'The Register' donde señalan que uno de los programas / servicios ofrecidos por Whisper Systems, Redphone, había dejado de dar servicio de forma repentina, sin previo aviso.

¿Por qué esto tiene tanta trascendencia? Redphone es un programa que permite mantener conversaciones teléfono<-->teléfono empleando algoritmos fuertes de cifrado, y este programa era ampliamente utilizado en Egipto como forma de comunicación entre los disidentes.

Justo ahora que Egipto se encuentra en un oscuro proceso electoral, Redphone ha dejado 'tirados' a todos los usuarios, dejándolos bajo cierto desamparo, y sorprende aun más porque el propio Moxie decía tiempo atrás:


Por lo tanto, es bastante extraño que, ahora que Twitter ha comprado Whisper Systems, dejen de dar servicio precisamente en un momento crítico para Egipto.

Probablemente existan motivos de peso para esta decisión, aunque personalmente no soy capaz de entender en que puede afectar que el servicio esté online/offline para llevar a buen puerto la venta de la compañía.

Adicionalmente se crea un cierto problema de desconfianza debido a que Moxie es el impulsor de 'Convergence', el sistema (o anti-sistema) diseñado para rivalizar con el esquema tradicional PKI-SSL. 

Esperemos que se aclaren las cosas y lleguen las explicaciones
Leer más...

29 noviembre 2011

Anthony G. Basile, aka blueness, es una de las personas que está detrás de proyectos como PaX/Grsecurity, Gentoo Hardened o Tin Hat, un sistema operativo basado en Gentoo que tiene una razón de ser muy interesante.

Nos ha dejado hacerle algunas preguntas sobre su labor en algunos de éstos proyectos, y su forma de ver varios aspectos de la seguridad actualmente.

Personalmente he disfrutado mucho haciendo la entrevista y me gustaría agradecerle que haya compartido con nosotros un poquito de su tiempo. Os dejo con él.

1. Cuéntanos algo sobre tí, trabajo, hobbies, y qué haces cuando no tienes un ordenador entre manos.

Soy profesor en D'Youville College, en Buffalo, NY. Es una pequeña escuela con unos 3000 estudiantes. Soy el director del programa "Information Technology", que es cómo lo llamamos, pero es una licenciatura de ingeniería informática con énfasis en programación y diseño de sistemas. La mayoría de mi vida la paso enseñando, administrando servidores, y después llego a casa para escribir código para varias iniciativas en Gentoo.

Por otro lado, paso tiempo con mi perro Daniel. Vamos al parque todas las mañanas para hacer ejercicio.

2. ¿Por qué Gentoo Hardened? Y, ¿por qué basado en Gentoo y no Debian, Fedora u otro sabor de GNU/Linux?

Primero, ¿por qué Gentoo? Gentoo es una distribución "desde el código", no es como una distribución tradicional. Más o menos creas tu propia distribución cada vez que configuras una nueva máquina con Gentoo. Una vez que tienes los binarios básicos en tu disco duro, depende de tí el cómo vas a recompilar el sistema entero como tú quieres. Ni Debian ni Fedora te dan ésto. Por ejemplo, si quieres construir un sistema sin el módulo de soporte de autenticación PAM, como podría ser para un sistema embebido, ¡puedes! Pero en sistemas con binarios, ésa decisión ya está tomada por tí por parte de los los desarrolladores. Por lo que, si vas a construir una distribución derivada, y quieres construirla a tu manera, como Tin Hat (luego hablaremos de ello), la elección del "padre" en obvia.

La otra razón para elegir Gentoo como raiz de Tin Hat es que también soy desarrollador de Gentoo, trabajo en el kernel y en hardening, por lo que ya estoy familiarizado con las elecciones que he de tomar a nivel de código. Gentoo te da más opciones que Debian, ¡pero no es infinitamente abierto! Nosotros parcheamos código fuente y decidimos qué características añadir o quitar en éste nivel. Por ejemplo, yo sé y estoy involucrado en cómo construimos los binarios ELF, por lo que diseño el sistema en un nivel más bajo.

Finalmente, ¿por qué Hardened? Porque la idea principal detrás de Tin Hat era un sistema que tuviera cero fugas de información. Cuando está funcionando, no queremos que un atacante sea capaz de entrar y ver qué está pasando, y cuando se apaga, ¡no queremos si quiera que un atacante sepa que había un sistema operativo corriendo en la máquina! Por ésto, el hardening es crítico para nuestros propósitos.

3. ¿Podemos decir que Gentoo (Hardened) es una buena distribución para escritorio, o es mejor para otros entornos? ¿Por qué?

Gentoo, hardened u otro, puede ser usado igual para escritorio, servidor o embebido. No hay un entorno en el que es mejor. Pero la carga de construir el sistema está en el usuario. Por lo que, ¡mejor que sepas lo que estás haciendo! Para continuar con mi ejemplo de antes, ¡no debes desactivar PAM a la ligera!

Una vez que lo has diseñado como lo quieres, Gentoo funciona muy bien. Yo prefiero Gentoo en mis escritorios o servidores a Ubuntu (que suelen usar los estudiantes) porque los construyo de forma precisa con las cosas que yo quiero. Raramente sufro la frustración de que un paquete no se genere como yo quiero.

4. ¿Cuáles son las ventajas de portage contra, por ejemplo, APT?

Comparar portage y APT es como comparar manzanas y tomates --- ambos pueden ser rojos, ¡pero por dentro son muy diferentes!

Portage es una suite para compilar paquetes entre dependencias, desde el código, a un sistema funcional. Toda la información está ahí. Desde el código, a la manera en la que tiene que ser compilado para que termine en un sistema coherente.

APT es más restringido en alcance. Resuelve dependencias, descarga, instala los binarios precompilados, y configura los paquetes en el sistema. Portage hace éso también, pero tiene una dimensión extra, en el sentido de que compila el código según las decisiones del usuario. Puedes pensar en portage como en una capa que abstrae las decisiones de los desarrolladores sobre la manera de compilar un paquete para dárselas al usuario final --- nada que ver con APT.

5. ¿Cuales fueron las motivaciones para desarrollar Tin Hat?

Comenzó durante un experimento en una clase de Sistemas Operativos Modernos, dónde estábamos discutiendo la idea de "información cero". ¿Bajo qué condiciones se filtra la información y qué tipo de información es filtrada?

Queríamos un sistema que, al final, ¡ni siquiera filtrara el hecho de que hay un sistema operativo! ¡Información cero!

El usuario podría decir plausiblemente "éste ordenador no tiene nada en él", y que un atacante no fuera capaz de probar que éra incorrecto. Esto es un ideal extremo, pero fuímos en ésa dirección.

Al menos cuando cuando el ordenador se apaga, podemos asegurar que todo es limpiado. Por ello, sería muy difícil probar que el ordenador ha tenido alguna vez algo corriendo en él. Ponemos todo en RAM.

Cuando el ordenador está corriendo, queremos asegurar que el sistema es tan seguro como es posible para que un atacante no pueda entrar de forma remota. Por éso decidimos añadir la cantidad mayor de hardening posible sin hacer el sistema inutilizable.

Esperamos haber llegado a algo atractivo para el usuario paranóico de verdad :)

6. ¿Qué opinas acerca de las mitigaciones activadas en el kernel por defecto?

Ésto es absolutamente necesario a día de hoy, especialmente para exploits 0day.

Es imposible para los desarrolladores escribir código que garantice el 100% de seguridad. No hay humanos que tengan tanta perspicacia para saber cómo se puede abusar del código. Tarde o temprano, hasta el código mejor escrito tendrá alguna fisura que pueda ser aprovechada para un exploit. Por lo tanto, la seguridad se tiene que hacer a varios niveles: los desarrolladores deben escribir de forma tan segura como sea posible (ej: sanitizar la entrada del usuario), las herramientas deben de incluir medidas para prevenir exploits (ej: protección stack smashing) y el kernel debe hacer su parte (ej: prevenir de ejecutar memoria que también se puede escribir).

Núnca tendrás un sistema 100% seguro, pero según te frustras más y más con los vectores de ataque, las posibilidades de una explotación satisfactoria disminuyen.

Ok, puede que un desarrollador no se diera cuenta de que tiene un mapa de memoria en modo lectura/escritura/ejecución en uno de sus plugins, ¡pero PaX lo hace! En primer lugar, él no debería estar desarrollando de ésa forma, pero si ésto ocurre se cae en el siguiente nivel de seguridad.

La forma en la que se trabaja en Gentoo Hardened es que cuando detectamos paquetes que fallan avisamos a los desarrolladores. Cada capa ayuda a mejorar las otras capas y al sistema entero.

7. ¿Por qué grsec/PaX no está incluido por defecto de alguna manera?

Está incluido por defecto en Tin Hat. La máxima seguridad en las herramientas y el kernel está activada mientras el sistema siga siendo usable para escritorio. Una característica no activada por defecto es RBAC, unas reglas de acceso del sistema. Esto es más apropiado en servidores que hacen la misma tarea una y otra vez. Ahí, el sistema RBAC puede aprender la rutina y construir las reglas apropiadas, permitiendo sólo ésas tareas y nada más. En un escritorio, que es lo que Tin Hat pretende ser, RBAC es más difícil de implementar para que no interrumpa el uso normal.

En Gentoo, como parte de la filosofía, depende del usuario final añadir o no añadir el hardening que él quiera, por lo que no incluimos grsec/pax por defecto. No queremos limitar ésa elección. Hay algunos paquetes mal escritos que rompen con algunos aspectos del hardening.

Si el usuario final no quiere seguridad, ¿por qué forzarle?

8. ¿Qué opinas acerca de Qubes OS? ¿La disminución del rendimiento justifica la seguridad en éste caso?

No he mirado Qubes OS en profundidad, pero la seguridad es diferente a la que busca Tin Hat. Qubes OS pretende securizar mediante el aislamiento entre programas utilizando máquinas virtuales ligeras. ¡Ésto no llega a los extremos de ocultar los datos y el sistema operativo entero! El nivel de paranoia es diferente.

Imagina que vives en un régimen represivo dónde las autoridades pueden confiscar tu ordenador y obligarte a descifrar los discos duros. Con Tin Hat, cuando el sistema se apaga, no hay nada que pueda obtener el atacante. No hay nada que "entregar". A lo mejor el atacante puede obtener el sistema de arranque --- un pendrive bootable.

Para ser honestos, yo he tenido sistemas Tin Hat corriendo durante meses. Mientras no haya un fallo eléctrico, el sistema funciona y puede ser borrado en un segundo. Todos los datos que quieras guardar los puedes almacenar de forma remota mediante una conexión cifrada. Puedes bloggear acerca de las violaciones de los derechos humanos utilizando Tor para ocultar tus pasos y no necesitas guardar nada en local.

9. ¿Qué hay de las mitigaciones en los smartphones? Parece que Apple dió el primer paso implementando ASLR en sus dispositivos. ¿Son necesarias las mitigaciones para los últimos dispositivos móviles?

La diferencia entre los dispositivos móviles y los ordenadores está desapareciendo. De hecho, está pasando con todos nuestros dispositivos.

¡No me sorprenderá ver que un día nuestras neveras sean dispositivos con IP para que la compañía pueda loggear y hacer diagnósticos! (O ver qué comidas preferimos) ¿Imaginas virus en redes dónde todos los dispositivos tienen CPUs e IPs?

10. Estudiando las mitigaciones actualues podemos intentar imaginar cómo puede ser el futuro de la explotación. ¿Qué imaginas acerca de ésto?

Es difícil decir lo que puede conseguir el ingenio de alguien para eludir los esfuerzos actuales de las mitigaciones. Ciertamente si tú fueras un escritor de virus, querrías saber todas las técnicas para prevenir su propagación. Ésto incluye saber evadir la detección de los escáners. No sé mucho sobre ese aspecto de la seguridad por lo que no puedo predecir que la dirección de la explotación vaya a ser en esa dirección.

Pero una vez el ataque llega a la máquina, queremos prevenir cualquier tipo de corrupción o abuso de memoria tanto en espacio de usuario cómo de kernel. Éste progreso se está haciendo todos los días por el equipo de grsec y PaX.

Dado que las técnicas de explotación se están cerrando, lo que permanece son agujeros más exóticos que requieren técnicas más concretas. Por ello, no veo que la explotación se esté terminando, pero no vamos a volver a los tiempos del clásico "stack smashing" que afectaba a un alto tanto por ciento de binarios. El número de binarios afectados está disminuyendo y las técnicas se están volviendo más particulares y no tan fáciles de transferir a otras situaciones.

No creo que a estas alturas del juego nos estemos perdiendo una familia de técnicas grande, por lo que las técnicas futuras serán cada vez más limitadas en alcance.

11. ¿Lees blogs? ¿Cuál es tu manera de estar actualizado?

Sigo muchos feeds RSS y estoy en muchas listas de correo. Aquí hay algunas:

Cosas del kernel y seguridad:
- todos los feeds de http://seclists.org
- lkml y muchas listas de http://vger.kernel.org/vger-lists.html

Noticias geeks generales:

12. ¿Cinco herramientas que debes tener en tu ordenador?

um .... sólo necesito tres

busybox, kernel, un destornillador

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

Original en inglés:

1. Tell us something about you, works, hobbies, and what do you do when you don't have your hands on a computer.

I am a professor at D'Youville College in Buffalo, NY. It is a small school of about 3000 students. I am the director of the "Information Technology" program, which is what we call it, but it is more of a computer engineering degree with emphasis on programming and systems design. So most of my life is spent teaching, running servers, and then coming home and writing code for the various initiatives in Gentoo.

However, I do spend time with my dog Daniel. We go to the park every morning where we both get our exercise.

2. Why Gentoo Hardened? And why based on Gentoo and not Debian, Fedora, or other GNU/Linux flavor?

First why Gentoo? Gentoo is a "from source" distribution and so it is not like a traditional distro. You pretty much create your own distro every time you set up a new Gentoo box. Once you get the basic binaries on the hard drive, it is up to you how you will recompile the entire system into what you want. Neither Debian nor Fedora give you that. For example, if you want to build a system with no PAM authentication module support, like you might for an embedded system, you can! But with binary distros, that choice was already made for you by the developers. So, if you're going to build a derivative distro and you want to build it your way, like Tin Hat, the choice of parent is obvious.

The other reason for Gentoo as the parent of Tin Hat is that I am also a Gentoo developer, and work on kernel and tool chain hardening, so I already have familiarity with the choices that are made at the source level. Gentoo gives you more choices than Debian, but its not infinitely open! We patch source code and decide what features to add or remove at that level. So, for example, I know and have input into how we build our ELF binaries and can design the system down to that level.

Finally why hardened? Because the whole idea behind Tin Hat was a system that would leak zero information. When its running, we don't want an attacker to be able to get in and watch whats going on, and when its shut off we don't even want the attacker to know that there was an operating system on the box! So, hardening is critical for our purposes.

3. Can we say Gentoo (Hardened) is a good distribution for desktops, or it is better for other environments? Why?

Gentoo, hardened or otherwise, can be equally used for desktop, server or embedded. There's no environment where it is better. But, the burden is on the user to build the system she wants. So, you'd better know what you're doing! To continue my example above, you don't want to disable PAM lightly! Once built the way you want it, Gentoo works great. I much prefer my Gentoo desktops or servers to Ubuntu (which the students more typically use) because they're build precisely for the kinds of things I want. I seldom feel the frustration of some package not being built the way I wanted it.

4. What are the advantages of portage against, for example, APT?

Comparing portage and apt is like comparing apples and tomatoes --- they may both be red, but their insides are very different! Portage is a suite for building inter dependent packages from source into a functional system. All the information is there for what code is needed and how to build it into a coherent system. Apt is more restricted in scope. It resolves dependencies, downloads, installs the prebuilt binaries, and configures packages on the system. Portage does that too, but has that extra dimension of building the source according to user choices. You can think of portage as an abstraction layer which abstracts the developers' choices about how to build packages and exports that to the end user --- there's nothing like that in apt.

5. What were the motivations to develop Tin Hat?

It began during a thought experiment in a Modern Operating system class in which we were discussing the ideal of "zero information". Under what conditions is information leaked and what kind of information gets leaked? So we wanted a system that, in the end, would not even leak out the fact that it has an Operating System on it! Zero information! The user could plausibly say "this computer has nothing on it", and the attacker would not be able to prove them wrong. This is an extreme ideal but we pushed in that direction. At least when the computer is shut off, we can make sure everything gets wiped. Then it would be very difficult to prove that the computer had ever had anything running on it. So we put everything into RAM. When the computer is running, we want to make sure that the OS is as secure as possible so the attacker can't make headway into it remotely. So we decide to add the most amount of hardening without making the system unusable.

We hope we've come up with something appealing to the truly paranoid user :)

6. What do you think about the mitigations activated in the kernel by default?

This is absolutely necessary today, especially with zero day exploits. It is impossible for developers to write code which guarantees 100% security. No human has that much insight into how code could be abused. Sooner or later, even the best written code will show some crack that can be escalated into an exploit. So security has to be done at multiple levels: the developer must write as securely as possible (eg. sanity checks on user input), the toolchain must include guards to prevent exploits (eg. stack smashing protection) and the kernel must do its part (eg. prevent executing memory which is also writable). You'll never get a 100% secure system, but as you frustrate more and more vectors of attack, the chances of an exploit succeeding will decrease. Okay, maybe the developer didn't catch that he's got a read/write/executable memory mapping in one of his plugins, but PaX did! He shouldn't be coding that way in the first place, but if it happens then you fall back on the next level of security. The way it usual plays out in hardened Gentoo is we see the packages fail and then alert the developers. So each layer helps to improve the other layers and tighten up the system.

7. Why grsec/PaX isn't included by default in some way?

It is included by default in Tin Hat. The maximum toolchain and kernel hardening is turned on while still leaving the system usable as a desktop. One feature not enabled by default is RBAC, a system of mandatory access rules. This is more appropriate on servers which do the same task over and over again. There the RBAC system can learn the routine, construct the appropriate rules, thus allowing only those tasks and nothing more. On a desktop, which is what Tin Hat aims to be, RBAC is harder to implement in such a way that it doesn't restrict normal usage.

In Gentoo, as part of the philosophy, its up to the end user to add or not add as much hardening as she wants, so we don't include grsec/pax by default. We don't want to limit that choice. There are some poorly coded packages which break under some aspects of hardening. If the end user doesn't need the security, why force them!

8. What do you think about Qubes OS? The performance kill justify the security in that case?

I haven't looked at qubes-os in any depth, but security there is different from the security Tin Hat is looking for. Qubes-os aims to secure by isolating programs from one another in light weight vms. It does not aim at the extremes of hiding the data and the entire OS! The level of paranoia is different. Imagine you're living in a repressive regime where the authorities can confiscate your computer and demand that you decrypt the drives. With Tin Hat, once the system is down, there's nothing there for the attacker to get. There is nothing to "hand over". Maybe the attacker can get the boot medium --- a bootable pen drive. But to be honest, I've had Tin Hat systems running for months. As long as there is no power failure, the system runs and can be wiped at a given second. Any data you might want to store you can store remotely and upload/download via some encrypted connection. Or more likely you can blog about human rights abuses using tor to hide your tracks in which case you don't even need to store anything locally.

9. What about mitigations in smartphones? It seems Apple has done the first step implementing ASLR in their devices. Are mitigations necessary for last mobile devices?

The difference between mobile devices and networked computers is disappearing. In fact, this is becoming true of all our devices. I will not be surprising if one day our refrigerators become IP devices so the company can log in and do diagnostics! (Or see what foods we prefer!) Can you imagine viruses wild in network where every appliance in the world has a CPU and an IP address!

10. Studying actual mitigations we can try to imagine how could be future of exploitations. What do you imagine about that?

Its hard to say what cleverness someone might come up with to circumvent current mitigation efforts. Certainly if you were writing viruses, you'd want to know all the techniques in place today to prevent their propagation. This includes such things as evading detection by scanners. I don't know much about that aspect of security so I can't predict what the evolution of exploitation will be in this direction.

But once the attack lands on the box, we really want to prevent any kind of memory corruptions or abuse in either kernelland or userland. There progress is being made every day by the grsec and PaX teams --- like the recent work to constify all kernel pointers which can be made constant. As entire families of exploit techniques get closed off, what remains are more exotic holes requiring more ad hoc techniques. So I don't see exploitation every going away, but we're not going back to the days of classic "stack smashing" that affected some large percentage of binaries. The effected binaries are becoming fewer in number and the techniques are becoming more particular and not as easy to transfer to other situations. I don't think at this stage of the game we're missing any really big family of exploit techniques, so future techniques will be increasingly limited in scope.

11. Do you read blogs? What is you way to be updated?

I follow lots of RSS feeds and I'm on lots of email lists. Here's just a few:

Kernel stuff, security stuff
- http://kernel.org/kdist/rss.xml
- http://feeds.feedburner.com/grsecurity
- http://freshmeat.net/index.atom
- all the feeds from http://seclists.org
- lkml and many of the lists at http://vger.kernel.org/vger-lists.html

General geek news
- http://www.theregister.co.uk/headlines.atom
- http://rss.golem.de/node/feed?category=
- http://slashdot.org/slashdot.rss
- http://digg.com/rss/index.xml

12. Five must-have tools for your computer?

um .... I only need three

busybox, kernel, screw driver
Leer más...

28 noviembre 2011

Usando la GPU para crackear la contraseña de WPA/WPA2-PSK con oclHashcat

Pyrit es una herramienta que permite utilizar la potencia de la GPU para crackear contraseñas de puntos de acceso wireless con WPA/WPA2-PSK. En la entrada de hoy, vamos a mostrar una alternativa: oclhashcat plus.

Lo primero es descargar e instalar la última versión de aircrack-ng, disponibles en: http://nightly.aircrack-ng.org/aircrack-ng/trunk/. Esto es importante ya que las últimas versiones incluyen dos opciones que no están disponibles en los paquetes que distribuyen algunos sistemas.

cd /tmp
wget -q hxxp://nightly.aircrack-ng.org/aircrack-ng/trunk/aircrack-ng-trunk-2011-11-19-r1997.tar.gz
tar -zxf aircrack-ng-trunk-2011-11-19-r1997.tar.gz
cd aircrack-ng-trunk-2011-11-19-r1997/
make && make install 

Tal y como en el siguiente ejemplo:


Lo siguiente es cambiar la tarjeta a modo monitor. En el caso de la Intel  Centrino Ultimate-N 6300 que viene con mi portátil, no hace falta parchear ningún driver ni nada adicional.

ifconfig wlan0 down
iwconfig wlan0 mode monitor
airmon-ng start wlan0


Lanzamos la aplicación airodump-ng para capturar la autenticación de un cliente, filtrando por el canal en el que transmite y el BSSID del punto de acceso. Utilizando el dispositivo mon0 creado después de ejecutar el airmon-ng start y almacenando los resultados en el fichero "dump".

airodump-ng -c 2 mon0 --bssid F4:EC:38:9F:D0:2D -w dump.pcap



Hasta aquí es más o menos lo que se lleva haciendo toda la vida para sacar la contraseña. Ahora para hacer fuerza bruta usando la GPU con oclhashcat plus, hay que seguir estos tres últimos pasos.

Para limpiar la captura y exportarla en otro formato para que pueda leerla la herramienta oclhashcat plus es necesaria la versión actualizada de aircrack-ng.

Ojo con la aplicación wpaclean, que tiene invertido el orden en el que se aceptan los ficheros. Primero el destino y después el origen. Con el primer comando se crea el archivo wpaclean.cap y con el segundo, partiendo de wpaclean.cap se genera el fichero final dump2.hccp

wpaclean wpaclean.cap dump.pcap-01.cap
aircrack-ng wpaclean.cap -J dump2

Otra opción para crear el archivo hccp es subir el cap a la página web: http://hashcat.net/cap2hccap/

Por último, se usa la última versión de oclhashcat+ indicando que es WPA (-m 2500) y que se use el diccionario de rockyou.

cudaHashcat-plus64.bin -m 2500 dump2.hccap rockyou.txt



En este ejemplo se observa una velocidad de 3900 intentos por segundo con la Nvidia Quadro 1000M del portatil,  a diferencia de la cpu i7 del mismo equipo, que con aircrack consigue 1020 keys por segundo o los 3300 intentos que obtiene pyrit usando la gpu también.

Si no hay suerte con los diccionarios más típicos, con la utilidad maskprocessor hay que generar mascaras para intentar sacarla con fuerza bruta tradicional. En este ejemplo se intentará con caracteres en minúsculas, mayúsculas, números y caracteres especiales con una longitud de 5:

mp64.bin -1=?l?u?d?s ?1?1?1?1?1 | ./clhashcat-plus64.bin -m 2500 dump2.hccap
Leer más...

27 noviembre 2011

Enlaces de la SECmana - 99

Leer más...

26 noviembre 2011

I Jornada de Seguridad - Asociación Geiser


De la mano de Isaac Castro, fiel lector de SbD, nos llega la noticia de la convocatoria de la I Jornada de Seguridad en Santiago de Compostela, organizada por la Asociación Geiser y patrocinada por la Escuela Técnica de la Universidad de Santiago.
Este evento, se celebrará en tierras gallegas el 15 de Diciembre y contará con importantes profesionales del sector.

El cartel de conferencias es de lo más prometedor: 
  • Nuestro querido amigo Pedro Sánchez, del conocido blog Conexión Inversa, que traerá una charla de temática forense, de las que no te deja indiferente, porque la historia estará basada en un hecho real. En este caso, analizará los patrones que se siguen en una extorsión.
  • Nuestros también admirados, profesionales de la seguridad, de "The Flu Project", impatirán un taller sobre cómo controlar remotamente un ordenador desde Windows y Android, a través de su troyano Flu.
  • Javier Berciano (moderador la mesa redonda en la 5ª edición de ENISE en la que participó nuestro compañero Yago) y José Valentín Gutierrez, ambos integrantes de INTECO-CERT, explicarán cómo funciona un CERT, y qué proceso se sigue a la hora de gestionar una incidencia de seguridad, de forma profesional y a nivel nacional e internacional.   
La asistencia a las charlas del Congreso es gratuita, aunque el taller de Flu cuesta 20 euros por persona y está el aforo limitado a 32 personas.

Web oficial: http://asociaciongeiser.org/
Leer más...

25 noviembre 2011

Hackeos memorables: The IT Crowd



No, no es que hoy queramos hablar de un hackeo memorable protagonizado por los entrañables Moss y Roy, actores de la serie inglesa The IT Crowd, sino por los protagonizados por personajes de la vida real que, habiendo sido despedidos de malas formas, se han tomado la justicia por su mano y han ejecutado su peculiar Vendeeeetta!

Vía correo del CEO de la empresa para la que trabajo, os cuento cinco casos bastante curiosos, en los que un "IT guy" ha generado más de un hackeo memorable. Por cierto que el subject del correo del CEO era: "You guys are all doing a FABULOUS job and I love you all!" (Chicos, ¡estáis haciendo todos un trabajo FABULOSO y os quiero a todos!),… vamos, por si acaso :) 


"/etc/init.d/".$_ stop foreach (@coches);
Sea una concesionario de coches de alquiler. Dichos vehículos están provistos por la empresa de un sistema que permite selectivamente apagar el motor de los coches si los compradores/o personas que los alquilan, no pagan a fin de mes las cuotas correspondientes. Un empleado de TI despedido decide que como medida de protesta, accede a los sistemas se la empresa (del cuál se sabe la contraseña) que permiten habilitar el mecanismo de corte de corriente de arranque de todos los coches de la flota.

Lógicamente, y para evitar accidentes, el sistema no funciona si el coche está en movimiento, imagina que estás adelantando en una carretera de doble sentido y te apagan el motor. Así pues, en la primera parada que los conductores hicieron, no fueron capaces de volver a arrancar los vehículos. A la empresa le llovieron montones de quejas de usuarios que pagaban sus cuotas religiosamente y su vehículo había quedado inutilizado durante varios días. Para haceros la historia corta, traceando la IP origen, la policía logró identificar al individuo y procesarle.


Amenizando una presentación importante,… con porno!
Básicamente, un tipo despedido de una compañía, se las ingenia para instalar algún tipo de herramienta que captura credenciales en diversos PCs, entre ellas las de su jefe (el brazo ejecutor de su despido). Desconozco si fue un keylogger, o alguna herramienta de análisis de tráfico de red con capacidades Man in the Middle del tipo de Ettercap o Cain & Abel.

Durante un mes, el atacante se conectó más de 100 veces a la red de la empresa, y se dedicó a "liarla parda" sembrando cizaña y confusión, reenviando correos con la cuenta de otro empleado o su jefe. Como tenía acceso al correo de su jefe, se enteró que éste iba a llevar a cabo una importante presentación, junto el Consejo Directivo de la compañía, ante importantes personalidades de la ciudad. En medio de la presentación, el atacante se conectó remotamente, cambió una de las transparencias de la presentación original por una con contenido pornográfico.

Desconozco si el protagonista del ataque seguía en Twitter a @artepresentar, pero la idea debió amenizar bastante el "aburrido powerpoint"… y de paso sacar unos cuantos colores al "ex-jefe", aunque fue identificado y multado por ello.


El Silencio de las Contraseñas
Otro individuo que conocía las contraseñas de acceso a cualquier red de las redes municipales de la Ciudad de San Francisco. Básicamente, conocía dichas contraseñas, puesto que él había diseñado desde el principio dichas redes. Este tipo se entera que va a ser despedido proximamente. Por ello, decide que como él diseñó y creó dichas redes, le pertenecen. Después, modifica los permisos de acceso de otros usuarios a las mismas, quedando sólo su usuario con permisos de administrador.

Sus jefes se dan cuenta de ello y le exigen las contraseñas necesarias para poder crear más administradores y volver a tener el control de acceso a la red. El tipo se niega a decirlas. por lo que es arrestado y aislado en una celda de una comisaría. Después de 12 días de arresto, decide que revelará la contraseña de administrador, siempre y cuando sea el propio Alcalde de la ciudad quien vaya a hablar con él y se la pida. Finalmente, el Alcalde accedió a entrevistarse en la celda del ex-empleado para conocer la contraseña maestra.



Nuevo McMenu; ahora con WIFI (y celda) gratis
Otra compañía que despide a un individuo vengativo de malas maneras. El individuo decide atacar a su ex-compañía, intentando acceder mediante ataques de fuerza bruta o diccionario, a través de sistemas de conexión remota a las redes de la misma.

Le cuesta tiempo y esfuerzo, pero finalmente logra acceder con un usuario válido. El tipo conoce perfectamente la infraestructura de la compañía y decide borrar del mapa 15 virtual hosts con información crítica de la compañía. Para realizar la fechoría utiliza una red wireless gratuita ofrecida por un McDonalds. De esta manera, el individuo pensó que sus acciones permanecerían en el mayor de los anonimatos. Quizá habría sido más fácil si hubiera pagado su McMenú con dinero en efectivo en vez de con su tarjeta de crédito, 5 minutos antes de llevar a cabo el ataque. Otro caso documentado de accesos ilícitos a sistemas remotos mediante pares usuario/contraseña, es el de un ex-empleado que no cobró su última nómina. Decidió acceder remotamente a la red de su ex-compañía y cepillarse la base de datos de nóminas,.. "Si yo no cobro, los demás tampoco!". Éste no se tomó tantas molestias y decidió hacer el ataque desde su propia casa…. Ambos fueron juzgados y condenados.

#./dominar_el_mundo.pl
Un empleado con solera, de los que llegó a ser la estrella de la compañía en su día, años atrás, harto de su actual situación en la que la sangre nueva lo ha ido apartando, piensa que próximamente va a ser despedido y decide planificar una venganza "le-gen-daria".

Durante el suficiente tiempo, el fulano en cuestión se va llevando a casa TODOS los backups realizados en cinta, y metódicamente va eliminando su contenido. Según se van haciendo backups nuevos, él los borra y vuelve a dejar las cintas en su sitio. Así, espera a que el momento del despido llegue… y éste, no tarda en llegar. Cuando esto pasa, antes de irse deja una bomba lógica (en 6 líneas) lista para activarse en determinada fecha y.... Fin de la historia. Efectivamente, se cepilló toda la información de valor de la compañía, y no hay backup. Por lo visto, fue el fin de aquella compañía... y bueno, también el del protagonista vengador de esta historia que se pegó tres años a la sombra y se le exigió el pago de una multa de - atención - "2 millones de dólares".

Conclusiones:
  • Empleados de IT despedidos: La IP origen os delata, ojo a TOR o herramientas como Proxyfire. Los pagos con tarjeta, las posiciones GPS, la actividad de un móvil, todo es traceable…. Y aún así, no podréis estar seguros de que todo ha sido tenido en cuenta. No quiero incitar a nadie a cometer actos delictivos. La mejor forma de dormir tranquilo es tener siempre presente que "quien nada hace, nada teme".
  • Empresas: Cuando se despide un empleado, se toman medidas para evitar accesos remotos desde su usuario: 
    • Se bloquean las cuentas de usuarios inexistentes, se aconseja modificar las contraseñas a otros usuarios con acceso remoto (por si alguna vez el despedido tuvo conocimiento de la contraseña de un compañer@) y se advierte al resto del personal que esa persona ya no trabaja en la compañía, para evitar que sean víctimas de un ataque de ingeniería social. La utilización de tecnologías de autenticación fuerte, también son útiles para evitar estos problemas.
    • Por supuesto, es una muy mala práctica la utilización de contraseñas de uso compartido. Una de las mejores costumbres es aplicar convenientemente la granularidad de permisos y, aplicar la Ley de Mínimo Privilegio y del Necesidad de Conocimiento
    • Suele ser útil que los logs generados por ataques de fuerza bruta ante servicios críticos o de autenticación remota,  levanten algún tipo de alerta que alguien pueda comprobar. 
    • Las estrategias de Recuperación ante Desastres y los Planes de Continuidad de Negocio recomiendan que los backups, además de existir y hacerse de forma periódica suficiente, se almacenen en una localización apartada del site principal.
  • Empleador: Cuidado con cómo despides a tus chicos de IT, que al final, como dice el dicho: "Más vale un mal arreglo que un buen pleito"
Leer más...

24 noviembre 2011

Joomla, Wordpress o Drupal, ¿Cual es más seguro?

La pregunta que pone título a esta entrada parece sencilla, pero realmente no lo es tanto. Hace dos años intenté hacer este mismo ejercicio con algunos resultados. Ahora voy a enfocarlo con otros objetivos y por lo tanto, de distinta forma.

Tal vez evaluar la seguridad de un CMS sin sus plugins nos dé una visión de la calidad de este en su estado más puro, pero surgen varias preguntas: ¿Es realista tener uno de estos gestores sin plugins?  ¿No deberían de encargarse los propios productos de proporcionar los mecanismos de seguridad adecuados para que hasta el menos afortunado en conocimientos pueda desarrollar sin poner en riesgo todo un sistema? Con estas premisas, ¿cuál es el más seguro?

La forma más rápida de obtener referencias de las vulnerabilidades publicadas para cada uno de ellos es verificando los CVE y observando cuál de ellos presenta más boletines. Este método sería perfecto salvo por que hay algunas referencias que incluyen más de una nota de seguridad, como por ejemplo el CVE-2011-0700  de Wordpress que son 5 XSS distintos, aun así, en estos casos se catalogan en base a la que tiene la criticidad más alta, por lo que la aproximación puede ser válida.

Wordpress tiene un total de 160 vulnerabilidades, además este año no ha tenido mucha suerte, con 3 vulnerabilidades críticas (CVSS de 9 ó 10)



Drupal acumula 217 referencias CVE y este año presenta tan solo 2 vulnerabilidades medias, con criticidades inferiores a 8.



Joomla sigue siendo el patito feo por su fatídico 2008, actualmente acumula 260 y tiene 14 fallos para el 2011, aunque faltan por añadir 2 fallos con criticidad alta que fueron reportados la semana pasada.



Estos mismos datos, son utilizados para realizar el ranking, que queda de peor a mejor: Joomla, Drupal y Wordpress.


En todos ellos, entre el 2007 y 2008 sufrieron un gran pico, y es que en esto de la seguridad está demostrado que ¡la letra con sangre entra!
Leer más...

23 noviembre 2011

Vuestros "ETHERNET EXPOSED" - VII

Nueva edición de nuestra sección Vuestros ETHERNET EXPOSED, posts en el que pretendemos recopilar aquellas imágenes que realizáis a tomas ethernet que se encuentren expuestas en lugares curiosos y que posteriormente nos enviáis a nuestra dirección de contacto.

Para este conjunto número 7, vamos a publicar dos nuevas contribuciones, que pasamos a describir a continuación.

La primera de ellas nos la envió Busindre, e incluye una mini-investigación acerca del aparato conectado a la toma en cuestión y sus posibilidades:


"Aquí les traigo un "Ethernet exposed" de traca en un establecimiento "Galeria Kaufhof" de Würzburg, los cuales están muy extendidos por Alemania, el aparatito que está conectado a la otra toma es un terminal de control de acceso físico IF4735, no hace falta decir mucho más al respecto."

Pues efectivamente, poco más que decir al respecto, habría que aprovechar las toallas que se ven en las estanterías para taparse mientras se trastea con el ETHERNET EXPOSED, o dejarlo para un día de rebajas, pero si que está bastante expuesta.

A continuación, os presentamos unas tomas recogidas por nuestro compañero Lorenzo, mientras su espera en un aeropuerto. Son varias, y una de ellas podría abrir una nueva sección llamada RJ-11 EXPOSED, ahora veréis por qué:

"En este caso en el aeropuerto de Lisboa, donde tuve que hacer una larga espera hoy, encontré un teléfono que dice que está a mi disposición... qué considerados. Una lástima no tener el portátil en el que aún tenía módem, porque nada puede haber más entretenido en una espera de un avión que no llega, que probar alguna herramientita de dialing."



"Al darme la vuelta y buscar un verdadero Ethernet Exposed, y de paso mirar si mi vuelo salía o no en hora, vi que el panel, nutre su colorido texto, utilizando una maravillosa toma de red RJ-45. Tengo claro que no iba a ponerme a desenchufarlo para ver qué pasaba, pero, justo al buscar la dificultad de acceso del conector, veo que hay otro RJ-45 de libre acceso. 




"Había bastante gente en ese sector, como para sacar un cable de red y ponerme a jugar (y reconozco que lo llevaba) pero no tenía ganas de ponerme a escribir un post de Ethernet Exposed desde una fría sala de la policía del aeropuerto de Lisboa :) ."

Parece como si hubiese habido algún panel ahí al lado con anterioridad, o directamente, se trata de una toma "backup". ¿Tendrá enlace? Quién sabe...

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!

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

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

22 noviembre 2011

Bypassing Captchas, más facil de lo que parece

El otro día me preguntaron si recomendaba algún proyecto decente para evitar las validaciones mediante captcha y leyendo al respecto me pareció curioso la cantidad de opciones a las que se puede acudir cuando muchas veces las formas de saltarse esos sistemas no tienen nada que ver con la complejidad de las imágenes que generan (que muchas veces ni nosotros somos capaces de acertarlas a la primera) sino de la implementación que se hace de los mismos.

Hace un año se publicó en este mismo blog una contribución anónima acerca de las vulnerabilidades existentes en la Lista Robinson y pudimos comprobar como la forma de saltarse el sistema de captcha no consistía en nada más que acceder al código de la página y buscar un campo oculto con nombre 'captchacode_01' y obtener de ahí el valor de la imagen mostrada.

Otro caso curioso lo protagonizó la SGAE y su formulario de contacto (aunque la vulnerabilidad es del plugin CForms para Wordpress) que permitía asignar a nuestra sesión un captcha cuyas propiedades de generación podíamos modificar, obteniendo finalmente un captcha que siempre valía '0'.

Como hemos visto, hay formas de saltarse los sistemas de captcha sin tener que utilizar técnicas complejas de reconocimiento de texto en imágenes, simplemente basta con manipular el sistema como tal. Esos ejemplos ya habían sido comentados por aquí pero ¿hay más? En este caso voy a comentar uno que afecta a más sistemas de los que esperaba (inluyendo algunos controles de Google, Twitter, etc).

¿En qué consiste? Pues simplemente en obtener el token y el valor correcto del captcha y replicarlo en cada una de las peticiones que hagamos. De esta forma siempre estaremos enviando la respuesta correcta. La verdad es que parece mentira que esta técnica funcione con lo fácil que sería eliminar el par token-valor una vez ha sido validado (valiéndonos solo para una petición).

Más interesante, veamoslo en un ejemplo... el sistema de control de búsquedas automatizadas de Google.

Cuando realizamos muchas búsquedas en Google al final acaba pidiéndonos que rellenemos un captcha. El sistema en cuestión es:

http://www.google.es/sorry/Captcha?continue=URL

Si nos fijamos vemos que el sistema asigna a nuestra sesión una imagen a la que podemos acceder mediante su identificador:

http://www.google.es/sorry/image?id=ID

Quedando la petición de validación del captcha:

http://www.google.es/sorry/Captcha?continue=URL&id=ID&captcha=VALOR&submit=Enviar

Por lo tanto, bastará con repetir esta petición cada vez que Google intente validar nuestra búsqueda automatizada (colocando la url de la búsqueda en el parámetro 'continue') para saltarnos el control (es necesario enviar la cookie GDSESS).

Como véis, con una técnica de lo más simple es posible saltarse la restricción de búsquedas de Google (aunque hay otros servicios sin reCaptcha que tampoco se ven afectados como el de iniciar sesión), el formulario de creación de una cuenta en Twitter Mobile, y otras muchas páginas.

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

Contribución por Luis Delgado
Leer más...

21 noviembre 2011

Fortificación de lighttpd

Lighttpd es otro servidor web libre y gratuito que está desarrollado con el objetivo de ser ligero y altamente eficaz.

Al igual que la semana pasada con nginx, vamos a repasar algunas directivas que pueden impactar en la seguridad y que se han de tener en cuenta en una instalación o auditoría.

Lo primero y más básico es arrancar el servicio con un usuario no privilegiado, por lo que el fichero de configuración ha de incluir dos lineas como las siguientes:

server.username = "lighttpd" 
server.groupname = "lighttpd"

Para evitar que se generen listas del contenido de un directorio en caso de no existir un archivo index.html, es necesario deshabilitar el parámetro dir-listing tal de la siguiente forma:

dir-listing.activate = "disabled" 

Para modificar la cabecera Server y no mostrar la versión y producto del servidor web se especifica la cadena en server.tag:

server.tag ="HTTPD"

Si se desea restringir el acceso a determinadas extensiones de ficheros, que pueden existir residualmente o ser de configuración, puede hacerse como en este ejemplo:

url.access-deny = ( "~", ".inc", ".bak" )

Si el servidor no va a recibir ficheros, también se puede limitar el tamaño de una petición a 1kb, 

server.max-request-size  = 1

TRACE y TRACK, no están soportados en lighttpd, pero para deshabilitar todos los métodos menos los esencialmente necesarios como son GET, HEAD y POST:

$HTTP["request-method"] !~ "^(GET|HEAD|POST)" {
url.access-deny = ( "" )
}

Si queremos molestar a los auditores y denegar el acceso a algunas herramientas automáticas en base a su user-agent, se puede hacer con una expresión regular. ¡Ojo!, que esto es fácilmente evadible y sirva más de ejemplo para evitar bots o ataques concretos.

$HTTP["useragent"] =~ "(acunetix|nikto)" {
url.access-deny = ( "" )
}

Para evitar que las imágenes del servidor sean enlazadas desde otro sitio (hotlinking), tan solo hay que añadir las siguientes líneas:

$HTTP["referer"] !~ "^(hxxp://sbd\.com|hxxp://www\.sbd\.com)" {
url.access-deny = ( ".jpg", ".jpeg", ".png", ".gif" )
}

El status es un módulo que muestra información sobre el servidor, en ocasiones estos datos pueden incluir datos confidenciales y debería estar restringido a direcciones IP. Si no se utiliza, es aconsejable eliminarlo, borrando la línea que contenga "status.status-url" y verificando que no está cargado en "server.modules"

status.status-url = "/server-status"
server.modules = ( ..., "mod_status", ... )

Por último, si se hace uso de SSL, es recomendable deshabilitar la v2 y algunos ciphers. Una configuración robusta (a falta de parche para BEAST) podría ser esta:

ssl.use-sslv2 = "disable"
ssl.cipher-list = "TLSv1+HIGH !SSLv2 RC4+MEDIUM !aNULL !eNULL !3DES @STRENGTH"

Para restringir un recurso a varias direcciones IP, rangos o localhost, lighthttpd permite este tipo de sintaxis:

$HTTP["remoteip"] !~ "192.168.1.3|10.0.5.*|127.0.0.1" { 
   $HTTP["url"] =~ "^/Admin/" { url.access-deny = ( "" ) }
}

En caso de querer proteger un directorio con usuario y contraseña, del RFC 2617 se ha de usar digest y nunca basic, con una sintaxis del módulo mod_auth, similar a la siguiente

auth.backend = "htdigest"
auth.backend.htdigest.userfile = "lighttpd-htdigest.user" 
auth.debug = 2

auth.require = ( "/protected/" =>
    (
    "method"  => "digest",
    "realm"   => "Nombre de mi directorio con Password",
    "require" => "valid-user"
    ),
)
Para crear el fichero lighttpd-htdigest.user:
# htdigest -c lighttpd-htdigest.user 'Nombre de mi directorio con Password' aramosf
Leer más...

20 noviembre 2011

Enlaces de la SECmana - 98


Leer más...

19 noviembre 2011

A la caza del proxy abierto

Hacía pocos días que notaba que el led de la unidad ONT HG 850G, que me conecta a Internet a través de fibra óptica, parpadeaba más de lo normal.

Por las horas a las que suelo acostarme, puede darse el caso que el servidor de casa esté buscando actualizaciones, haciendo backups, etc, etc,… En otro momento de mi vida quizá diría que el Emule está echando humo y me iría a la cama contento. Al día siguiente tendría muchos capítulos de series descargadas. Sin embargo, actualmente, que cuando necesito algo, lo descargo bajo demanda, me pareció que algo no iba bien.

Cierto es también que, al disponer de una conexión de fibra óptica, la velocidad de descarga de cualquier cosa es tan rápida, que no te das cuenta que hay "algo" comiéndose la línea.

Así pues, me dispuse a investigar qué es lo que estaba pasando en la máquina y esto que os cuento es lo que encontré:
  • Mediante un "tcpdump -n -i ppp0", pude ver que casi toda la actividad de red estaba encaminada al puerto 8088. Las direcciones IP origen procedían de diferentes partes del Mundo, aunque sobre todo, desde China.
  • Mediante un "netstat -tanp|grep -i 8088" ví que se trataba del proceso Apache público.


ProxyRequests On
ServerName miserver.com 

Order deny,allow
Allow from all
ProxyPass /to_be_proxified http://IP_tomcat:Puerto_tomcat/gps
ProxyPassReverse /to_be_proxified http://IP_tomcat:Puerto_tomcat/gps
CustomLog logs/micustomlog combined

Según lo ví… dije WTF!!! casi 4 años trabajando con proxies inversos, y voy y configuro el que es para mi propio uso sin cuidado alguno.

¿Qué estaba sucediendo?


  • Apache está escuchando en la IP Pública  en el puerto 8088 y, la intención es reenviar ciertas peticiones (las que lleguen a /to_be_proxified), a otro servidor web, actuando como un proxy.
  • Sin embargo, la configuración está muy mal hecha… Por culpa de las prisas fundamentalmente, tomé como referencia un bloque Virtualhost de otro servidor web interno que sí que utilizo como proxy saliente.
  • Esta configuración, y sobre todo la línea "ProxyRequests On" lo que permite es que, cualquier máquina que utilice como proxy HTTP la IP pública y el puerto 8088, podrá utilizar mi conexión como "proxy anonimizador".
  • Este Virtualhost además tiene definido que almacene logs de las peticiones en el fichero logs/micustomlog. Mirando dicho fichero (que por cierto ya iba en dos días por los 4 GB), veía peticiones de lo más variopintas.
  • Si apagaba el servicio Apache, el ancho de banda dejaba de consumirse en los términos anteriores. Estaba claro, este era el problema.
¿Y desde cuándo llevaré yo siendo el objeto de la navegación de vaya usted a saber quién?

Analizando los logs de "micustomlog" ví que afortunadamente esto sólo estaba pasando desde hace un par de días. Fue sencillo puesto que las entradas en dicho fichero son siempre del mismo tipo:

"GET /to_be_proxified/Data?imei=123456789012345&rmc=$GPRMC,blah,V,bleh,N,bloh,W,0.00,xyz,12345,,*00,123.4,AUTO HTTP/1.1" 200 2 "-" "-"

En el momento en que empieza a haber cosas que se salgan de ese patrón, es que alguien ha hecho hit.
Así pues, llega un punto de log se ve lo siguiente:

222.215.230.175 - - [09/Nov/2011:06:36:06 +0100] "GET http://www.graduateszone.com/proxyheader.php HTTP/1.0" 200 5 58 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
222.208.183.218 - - [09/Nov/2011:06:36:32 +0100] "GET http://proxyjudge2.proxyfire.net/fastenv HTTP/1.1" 200 401 " -" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

Después, 5 minutos de tranquilidad. A partir de ahí una fiesta de logs con peticiones desde múltiples direcciones IP con destinos de lo más variopintos.

Siguiendo con el análisis, como se puede ver en el extracto del fichero, la segunda entrada del log es http://proxyjudge2.proxyfire.net/fastenv.

Proxyfire, es una herramienta que se define como Cazador de Proxies.

He descargado la herramienta y examinado un poco el contenido. Os aseguro que no tiene desperdicio. Páginas con proxies abiertos, rangos de direcciones IP a escanear, un fichero especialmente interesante llamado "avoid_ip_ranges.txt" que, como podéis imaginar, es un bonito listado de IPs de organizaciones gubernamentales como la NASA, Agencias de Defensa, servidores controlados por el FBI… vamos un sueño recopilado en un único fichero! La primera línea de dicho archivo ya dice explícitamente: "IP Ranges you should not scan".

Durante su ejecución, aparte de permitirte navegar por sitios de dudosa catadura y echar la culpa a otro, Proxyfire dedica una parte de su tiempo a buscar diferentes máquinas mal configuradas por Internet, con proxies abiertos al Mundo. Cuando encuentra una, "llama a casa" y la añade a una lista global, que es descargada periódicamente los usuarios.

Disponen de una versión libre (con sus limitaciones) y una "Profesional". Dios me libre de saber qué tipo de "profesional" necesita pagar por esta herramienta.

En fin, que una vez solucionado el problema de configuración, aún de vez en cuando veo en el log diferentes intentos de peticiones a otros lugares.


Mis dudas y conclusiones
  • Aunque los usuarios de este tipo de herramienta, efectivamente anonimizan la IP de sus accesos, al no ser precisamente yo un "proxy anónimo", sino que tengo loggeados los 2 días que tuve las "piernas abiertas", podría darse el caso que si quisiese registrar de una forma más detallada las peticiones que pasan a través de mí, lograría ser un honeypot interesante.
  • He leído diversas fuentes que ponen en tela de juicio la seguridad y anonimato que ofrece la conocida red TOR. Sin embargo, en este caso, tu máquina no forma parte de ninguna red ni obtiene un certificado TLS. Con esta herramienta, tú utilizas directamente un proxy abierto de los de la lista, que se supone que no guarda logs, para visitar todo el contenido que desees, haciendo culpable a otro de tus fechorías.
  • Señor Juez: si mi dirección IP hubiese roto algo en esos días, mientras servía de pasarela a un montón de chinos que intentan bypassear el Gran Cortafuegos Chino, según las direcciones IP que he extraido de los logs ¿de quién es la culpa?
  • Nunca, nunca, nunca publiquéis, con prisas o haciendo muchas cosas a la vez, un servicio a Internet. Ojo con los Copy-Paste, aunque sean de algo que habéis hecho previamente. En mi caso, por reutilizar la configuración de un servicio interno sin demasiado cuidado, abrí una puerta a Internet para que los chinos naveguen sin censura, desde mi IP, utilizando Proxyfire.
    Leer más...

    18 noviembre 2011

    Buscando el país de origen de un malware

    Cuando aparece un nuevo malware muchas veces leemos en documentos técnicos de compañías antivirus en qué país se ha creado, pero ¿cómo lo saben?, con esta entrada pretendo explicar de dónde sale esta información. Para entender el ejercicio, se va a utilizar una muestra del malware Noppuca.

    Lo primero y más importante es saber que existen varias formas de detectarlo, la más sencilla es buscar cadenas de texto y del idioma sacar la procedencia. Estos datos pueden ser falsos, pero ayudan a tener una  aproximación.

    Otra opción inmediata es ver si con el propio explorador de ficheros muestra los detalles en la pestaña Versión.

    Propiedades del binario
    Estos datos realmente son obtenidos de uno de los recursos del ejecutable. Si recordamos la estructura de un binario PE, estos contienen una sección denominada recursos (.rsrc) donde  en forma de árbol se almacenan algunos elementos como bitmaps, iconos o diálogos. Cada uno de estos elementos tiene que estar identificado por un nombre, el tipo y su lenguaje.

    Estructura de .rsrc
    Muchos ejemplares de malware no disponen del recurso Version y cuando se muestran sus propiedades, todos los campos están vacíos (Vista/7) o ni si quiera hay pestaña Versión (XP):

    Propiedades de malware sin recurso Version
    Volviendo al bicho original, si se abre el malware con alguna aplicación para analizar archivos PE , como  CFF Explorer  y se recorre los recursos desde "Resource Editor", bajo la estructura de "Version Info", se encuentra la información mostrada por Explorer en su pestaña Versión.

    CFF Explorer 
    En la imagen superior se observa que tras la cadena Translation, hay cuatro bytes 0904 (0409) y 04b0, que en decimal equivale a 1033 y 1200. Estos números son el código de lenguaje y el código de página. Si se consulta la referencia de MSDN, se encontrará de donde sale el English/United States que se mostró inicialmente.

    Tabla de Locales ID
    Hasta aquí todo perfecto pero esta información se puede editar y si se compara el lenguaje con el que se identifica (1033) con el que este y otros recursos han sido creados, estos no concuerdan. 

    Comparando el Lenguaje de Version (1033) con el de un Recurso (2052)
    Ya que tal y como se ha explicado anteriormente todos los recursos se forman por un nombre, un tipo y un lenguaje y esta información es añadida por el compilador que genera el binario utilizando la configuración local del equipo. Usando la misma tabla anterior, se observa que 2052 corresponde con lenguaje chino. Esto mismo se puede consultar en las propiedades del recurso desde el propio CFF, que ya lo identificará como tal.

    Propiedades de recurso
    Como prueba final, el binario es subido a una sandbox online como la de ThreadExpert, que lo identifica con el mismo origen: China.


    Por supuesto, estos datos también podrían haber sido modificados o incluso algo mucho más común, que no dispusiera de ningún recurso o el lenguaje fuera "0" que significa que se utilice el lenguaje local.


    Leer más...