Implementando ataques de fuerza bruta.

"En teoria, la práctica y la teoría son iguales. En la práctica, no lo son."

Bruce Schneier.

Y en efecto, en algunos casos, la teoría y la práctica, llegan a ser muy distintas. Especificamente, por ejemplo, muchos clientes de mis pruebas de penetración consideran que los ataques descritos en artículos anteriores son imprácticos pues: "cualquier firewall/IPS es capaz de bloquear tu dirección IP apenas se detecte el ataque de fuerza bruta". Sin embargo, esta medida de mitigación funciona sólo en teoría y sólo si tu atacante es un novicio.

En la práctica, la medida de bloquear la dirección IP de tu atacante no sería tan mala de no ser por la gran cantidad de proxies libres y pagos a la disposición de cualquiera que pueda ejecutar una busqueda en google. Si además agregamos la gran cantidad de servicios baratos en "las nubes" (ya sea de amazon, o las creadas por los criminales informáticos en lo que se conoce como "botnets"), nos damos cuenta que en realidad nuestro atacante dispone de una cantidad casi inagotable de direcciones IP desde donde puede lanzar su ataque! En la práctica, lo que sucederá al bloquear la dirección IP de nuestro atacante "no-novicio" es que simplemente se utilizará otra dirección IP casi instantaneamente. Antes de detener a tu atacante efectivamente mediante el bloqueo de su cada vez nueva dirección IP, será tu firewall/IPS quien muy probablemente tendrá serios problemas de desempeño al intentar bloquear tantas direcciones IP particulares. Esta consecuencia es muy bien conocida por los que nos hemos enfrentado a estos tipos de ataque de forma rutinaria y conocemos los intringulis de la bestia de forma práctica, no sólo teórica.

 
Pero ¿qué tan fácil es implementar un ataque de cambio de dirección IP automático luego que el administrador novicio intente bloquear nuestra dirección IP? la respuesta es: trivial. Por ejemplo, si estamos trabajando contra un sistema web, con nuestro propio script en perl y usando la libreria LWP::UserAgent, agregar la funcionalidad mencionada requiere una sola linea de código:

$ENV{HTTP_PROXY} = 'http://direccion.ip.del.proxy:puerto_del_proxy';

Y por supuesto, es necesario codificar el manejo de error cuando la conexión falle y cambiar la variable anterior. Este método tiene la ventaja que cualquier otro script que esté atento a la variable de entorno, continuará funcionando transparentemente luego de hacer este cambio en vivo. En caso que el proxy requiera autenticación, las modificaciones necesarias son igualmente triviales. El último ingrediente necesario es una lista de proxies que como hemos visto, es de muy fácil acceso hasta para el principiante.

DIGRESIÓN: Si no conocias la información anterior y estas pensando iniciar tu carrera criminal con las técnicas descritas aquí, te tengo malas noticias. Usar proxies de esta manera no provee la anonimidad que muchos probablemente piensan. Es muy fácil dejar pistas de tu identidad por muchos lados y si tu víctima tiene los recursos y tiempo para buscarte te van a atrapar. En mis trabajos de forénsica de redes hemos logrado atrapar a muchos atacantes novicios de forma muy rápida debido a errores muy tontos de su parte. Mi recomendación: olvida el mundo criminal y ejecuta este tipo de demostraciones de forma profesional, con permiso y ganando buen dinero por ello.

Esta digresión me lleva al siguiente punto equivocado que escucho con cierta frecuencia de mis clientes con un poco más de experiencia en estos temas.  El argumento es mas o menos el siguiente: "en la presencia de un ataque de fuerza bruta, nosotros no bloqueamos ninguna dirección IP, nosotros bloqueamos directamente al individuo que ejecuta el ataque, lo buscamos con ayuda de las autoridades y lo visitamos a su casa". Esta política es mucho más efectiva que la anterior pero sólo hasta cierto punto. Asumiendo que tu organización tiene los recursos y el tiempo para ejecutar tal respuesta en todos los casos, lo cual no es usual, y asumiendo también que tu atacante se encuentra en tu jurisdicción o una jurisdicción colaboradora, esta medida sólo será efectiva contra los atacantes menos sofisticados. Tu criminal informático "profesional", del tipo que va tras organizaciones con los recursos y tiempo que estamos considerando, muy probablemente también sepa contra-medidas para no ser encontrado. Hablamos no sólo de medidas técnicas, como encadenamiento de proxies, sino que incluso pueden tambien hacerle una visita mafiosa al investigador técnico a cargo de tu investigación. En otras palabras, tu atacante cuenta con exactamente las mismas posibilidades que tú, sólo que desde el punto de vista criminal y sin restricciones legales.

En cuanto a las técnicas avanzadas de anonimidad que usan estos "criminales informáticos avanzados", pienso que no tienen cabida en este tipo de artículos. Por un lado, porque para el pentester profesional tienen muy poca utilidad. En nuestras pruebas de penetracion nosotros no sólo tratamos de no cambiar IP. Por el contrario, intentamos ser lo más identificables posible. Esta situación es, por supuesto, con la idea de proveer a la organización que nos contrata de un método efectivo para diferenciar un ataque verdadero de las actividades de nuestro servicio. Por el otro lado, tampoco tienen cabida pues este blog trata de ser un punto de referencia para los profesionales de seguridad informática y no una enciclopedia de ayuda a los pichones de criminales informáticos.

La conclusión de este segundo error común con respecto a los ataques de fuerza bruta es: no siempre podrás identificar físicamente a tu atacante. En consecuencia, no puedes confiar enteramente en esta medida tampoco.

El tercer y último "error" que escucho, aunque no muy frecuentemente debido al detalle técnico que requiere, de mis clientes es el siguiente: "para una organización incluso tan pequeña como la mía, es relativamente barato hacer que el espacio de búsqueda de mi atacante sea lo suficientemente grande como para que su ataque requiera tanto tiempo que se genere un cambio de interés en sus objetivos". Este argumento es 100% correcto. Por supuesto, usualmente lo escucho de clientes con sistemas de nombres de usuario de 8 caracteres y un password de 4 dígitos. Obviamente, este espacio de búsqueda es realmente muy pequeño para los estándares de recursos actuales, pero no dejan de tener razón en la teoría.

El problema es el siguiente: ¿Cuándo es un espacio de busqueda lo suficientemente grande sin hacer que mis usuarios tengan que recordar credenciales inhumanamente grandes? En este tema intervienen demasiados factores como para dar una respuesta adecuada para todos los casos. En consecuencia, yo siempre recomiendo hacer lo que equivale a un "análisis de stress" a la aplicación. Simplemente se ejecuta un ataque de fuerza bruta controlado sobre los procesos importantes incluyendo el de "login" y se estudian los resultados. Al final de este trabajo no sólo se tiene un estimado de cúal es la capacidad de atención real del sistema, sino que también se tiene un estimado de la velocidad con que un atacante puede conseguir la información que necesita para continuar su ataque. Es con esta información que se deben tomar decisiones sobre controles de mitigación en lugar de abusar de los "estandares" y/o "buenas practicas" y/o ISO-XXXX como se quieran llamar. Siempre hay que recordar: los estandares no dejan de ser una recomendación meramente teorica y que se quedan, en la gran mayoría de casos, muy cortos en la práctica.

El tema es tán sutíl que hasta colegas pentesters con cierta trayectoria reportan una tasa muy pequeña de velocidad de revisión en los ataques de fuerza bruta ejecutados por sus scripts. Una de las formas en que pentesters (y criminales) profesionales hacen scripts de gran desempeño es mediante el uso de multi-threading. Hace un tiempo y para aprender algo de python decidí hacer un esqueleto de muti-threading para utilizarlo con mis scripts. Al ser mi primer programa en python está un poco áspero en los bordes, pero lleva a cabo el trabajo con efectividad:

class RequestThread(threading.Thread):
        def __init__(self, id, request_queue):
                threading.Thread.__init__(self, name ="ResquestThread-%d" %(id,))
                self.request_queue = request_queue
        def run(self):
                while 1:
                        pid = self.request_queue.get()
                        # trabajar con pid. Manejar errores de la transaccion web con cuidado.
                        # 3 posibles estados: exito->anotar exito y terminar, error->anotar error y terminar, else->reintentar.


class InputThread(threading.Thread):
        def __init__(self, id, salir, tope, startp, startt):
                threading.Thread.__init__(self, name ="InputThread-%d" %(id,))
                self.salir = salir
                self.tope = tope
                self.startp = startp
                self.startt = startt
        def run(self):
                while 1:
                        text = str(raw_input())
                        if text == "quit":
                                #salir
                                salir.put(1)
                                break
                        cur = tope.get()
                        print "pid: " + str(cur) + " Speed: " + str(abs(cur - self.startp)/abs(time.time() - self.startt)) + " thrs/sec",

if __name__ == "__main__":
        pid = 0 ### Inicio del ataque de fuerza bruta. Esto puede ser la secuencia de usernames/passwords/etc.

        N_compute_threads = 30 ## Numero de Threads concurrentes. 30 es un buen numero para iniciar las pruebas.
        request_queue = Queue.Queue(N_compute_threads)

        for i in range(N_compute_threads):
                RequestThread(i,request_queue).start()

        salir = Queue.Queue(1)
        tope = Queue.Queue(1)

        InputThread(1, salir, tope, pid, time.time()).start()

        while salir.full() == False:
                if request_queue.full() == False:
                        request_queue.put(pid)
                        try:
                                tope.get_nowait()
                        except:
                                pass
                        tope.put(pid)
                        pid = pid + 1

        for i in range(N_compute_threads):
                request_queue.put(None)
        print "Shuting down " + str(pid)
        while request_queue.empty() == False:
                print "!",
                time.sleep(1)





La clase InputThread se encarga de manejar la interacción con el usuario. Por el momento, escribir la palabra "quit" ocasiona la señal de parada para todos los threads y termina limpiamente. Cualquier otro input simplemente produce la impresión de estadisticas de velocidad, avance y status general del programa. Esta clase se podría mejorar para proveer otras acciones como aumento de threads, disminución de threads, etc. La clase RequestThread se encarga de hacer el trabajo bruto. En el loop "while 1" se ejecuta la tarea que se asigna en la cola request_queue y es necesario manejar todos los casos de respuesta. Para el caso de aplicaciones web, es necesario manejar una situación de éxito, una de fracaso y una de ninguna de las dos. En los comentarios del código hay un poco más de explicación.

Finalmente, a pesar de que este artículo está enfocado a aplicaciones web, no hay ninguna razón por la que estas ideas no se puedan aplicar a otro tipo de aplicaciones. Por supuesto, habrán detalles teóricos que hay que sortear. Pero eso nunca es problema en la práctica. Si estos detalles no los han descubiertos los expertos en seguridad informática, de seguro lo habrán hecho los criminales informáticos. En ambos casos, lo único que hay que hacer es aprender de éstos y adaptar nuestros sistemas.

Cuando tu atacante se ataca a sí mismo.

Los casos en donde atacantes de muy baja sofisticación cometen errores son tan viejos como la Internet misma y adicionalmente son siempre jocosos. Mi favorito es el caso de un individuo que lo convencen de atacar la dirección IP 127.0.0.1 haciendole creer que era la dirección IP de la persona con quien sostenía un altercado por chat IRC. La conversación original sucede en alemán, pero se puede leer una traducción aquí.

Ocasionalmente, mi trabajo en manejo de intrusiones y análisis forense no deja de producir anécdotas inolvidables. Lamentablemente, muchas no pueden ser compartidas por este medio por estar bajo acuerdos de confidencialidad y/o para proteger a los inocentes. Sin embargo, hace unos días recibí una alerta de mi sistema de detección de intrusiones, altamente entonado para hacer investigación de las amenzas del tráfico público de Internet. Esta alerta describía un paquete poco interesante pero de una fuente un poco inusual.

La razón de SNORT (¿Cuál otro IDS podría ser? SNORT rules!) para alertar sobre este evento es entendible. Se trata de un paquete ICMP con un payload de 0 bytes. Esta firma de paquetes es generalmente asociada al PING ICMP de nmap. Nmap es una herramienta muy popular en distintos estratos desde el profesional de la seguridad informática hasta el delincuente del crimen informático organizado, pasando por supuesto por los "script kiddies/junkies" que la abusan sin realmente entender muy bien lo que hacen.

Por lo tanto, usualmente este tipo de eventos es ignorado completamente en mi análisis rutinario. Éste hubiera sido también el caso para este evento de no haber sido por el detalle que la dirección IP de origen pertenece a la subred de servidores de infraestructura de mi proveedor de servicios de Internet (ISP). Uno de los paquetes transgresores se puede ver aquí:

Como es de esperarse de un paquete con un payload de 0 bytes, su tamaño es más pequeño de lo usual. El encabezado ICMP termina en la secuencia 0800 013f d4bf 2201. Si recordamos un poquito la decodificación del protocolo ICMP:

0800 -> Type 8, Code 0 -> ICMP Echo (solicitud de ping)
013f -> Checksum.
d4df -> Identificador del paquete ICMP.
2201 -> Numero de secuencia.

Esto ocupa los 8 bytes de payload del paquete IP creando en efecto un paquete ICMP de 0 bytes de payload. La pregunta inmediata es: ¿A que corresponden esos bytes despues de nuestro encabezado ICMP? Estos bytes estan ocupando la posición que normalmente ocuparia el payload de un ping normal. Un paquete ping normal se ve como sigue:

La diferencia que debe resaltar inmediatamente es la secuencia de simbolos y numeros crecientes del payload del paquete ICMP normal. Esta es una secuencia fija muy distinta a la secuencia con apariencia aleatoria del paquete anterior. En consecuencia decidí analizar el resto de paquete capturados por mi sensor de detección de intrusiones con la esperanza de hallar un patrón:

La falta de patrón no sólo es evidente sino que también la explicación es ahora muy sencilla de elaborar. Primeramente, la razón por la cual hay bytes extras en estos paquetes ICMP ECHO de 0 bytes se debe a que los frames ethernet son de mínimo 64 bytes. Como se puede ver, los paquetes IP fabricados por mi ISP son todos de una longitud de 28 bytes (0x001c), esto es 20 bytes de encabezado IP y 8 bytes de paquete ICMP sin payload. Si además sumamos los 14 bytes del encabezado ethernet y los 4 bytes del trailer ethernet, nos llega la cuenta a 46 bytes. Para llegar a 64 bytes hace falta que el sistema operativo rellene los 18 bytes faltantes. Estos 18 bytes de relleno son los que vemos en nuestros paquetes ICMP misteriosos.

Finalmente, al ver los strings parciales de algunos paquetes: "MENE", "feight", etc la hipótesis que cobra fuerza es una descrita aquí. En resumen, el sistema de mi ISP que esta creando paquetes ICMP con payload de 0 bytes puede estar ex-filtrando (presumimos que no intencionalmente) información al resto de Internet sobre su memoria interna. Esto sucede cuando los drivers de la tarjeta de red fallan en limpiar la memoria antes de rellenar los frames ethernet de tamaño inferior al mínimo permitido. Con suficiente recopilación de paquetes podriamos empezar a hacer profiling de su memoria, y poco a poco recuperar cadenas de caracteres con passwords, nombres de usuario, y todo tipo de información confidencial.

Una vez más el atacante no entrenado termina atacandose a sí mismo.

Los Poderes que nos acechan.

"Las computadoras son las armas y la trinchera no tiene limites"

James Adams, The Next World War. 1998

Muchos tienden a calificar el "Cyber Warfare" como simple prensa amarillista. Sin embargo, la última telenovela de cyber espionaje protagonizada por HBGary Federal y conducida por el grupo de hacktivistas "Anonymous" parece dejar asomar una macabra amenaza global.

Los acontecimientos preliminares comienzan con la negativa de los grandes mercantes de pago virtual, paypal, mastercard, etc de continuar prestando sus servicios a Wikileaks. Esta ruptura de relaciones surge a raíz de la publicación de los famosos cables diplomáticos Norteamericanos, y el anuncio de una futura publicación de documentos internos del Bank of America y otras entidades financieras por parte de Wikileaks. En estos documentos se revelarían supuestas irregularidades que se habrían convertido en la norma en lugar de la excepción para estas organizaciones mercantilistas.

Para el grupo de hacktivistas "Anonymous", este bloqueo económico fue razón suficiente para llamar a una "protesta virtual" en la forma de lo que se conoce técnicamente como un "ataque de denegacion de servicios distribuido". El ataque basicamente consistió en la modificación y distribución de un software cuyo único proposito es el de generar solicitudes a los sistemas de la entidad financiera sin la intención de llevar a cabo ninguna transacción verdadera. En muchas ocasiones, esta sobresaturación de los sistemas informáticos los hace fallar completamente o en el mejor de los casos, hace imposible prestar el servicio de los clientes legítimos. Es el análogo a llamar a muchísimas personas y pedirles hacer una cola en frente de la ventanilla del banco para simplemente al llegar a la ventanilla, no hacer ningún requerimiento, esperar hasta que el cajero nos pida retirarnos y retirarse a formar la cola de nuevo. El resultado es la denegación del servicio para el resto de usuarios en la cola.

Este tipo de ataques no es ni nuevo, ni sofisticado para el mundo virtual, aunque para el mundo real pueda sonar como toda una sensación. Sin embargo, debido al alto perfil de los objetivos (paypal, mastercard, etc), esta "protesta virtual" se convirtió rápidamente en el tema de la prensa alarmista y naturalmente en el sujeto de varias investigaciones del gobierno Norteamericano. Es aquí donde entra la empresa HBGary Federal a la trama de la telenovela.

La empresa HBGary Federal, siendo un jugador pequeño en el mercado de seguridad informática y encontrandose en serios problemas financieros, ve en el grupo de hacktivistas "Anonymous", la oportunidad perfecta para dirigir mayor atención hacia su empresa. Aaron Barr, ex CEO de la empresa se dio a la tarea de "penetrar" el grupo de hacktivistas e intentar revelar las identidades de sus integrantes de "alto rango". Despues de varias semanas de supuesto trabajo de investigación "en cubierto", Aaron Barr anuncia a la prensa hambrienta de sensacionalismo que habia tenido éxito en su incursión en el grupo y que daría a conocer sus resultados en varias importantes conferencias de seguridad informatica de audiencia global. La respuesta del grupo de hacktivistas no se hizo esperar. La respuesta incluyó el sabotaje de varios de los servidores web de HBGary Federal e incluso la usurpación de sus correos electronicos internos, no solo de HBGary Federal, sino tambien de la empresa hermana HBGary.

Pero, ¿Qué tiene que ver toda esta telenovela Norteamericana con nuestra región? Al final, nosotros aquí en latinoamerica estamos acostumbrados a esperar que Hollywood saque la versión de pelicula en pantalla gigante, para nuestra risa y entretenmiento. En este caso: mala idea. Resulta que los correos electronicos de HBGary Federal publicados en la actualidad por una gran cantidad de sitios web nos dejan echar un pequeño vistazo a esa fusión malsana entre las grandes corporaciones y ciertos sectores del gobierno norteamericano. Sería un grave error no aprender temprano de este caso y esperar a la versión de cotufas. La imagen develada no es bonita. Entre las revelaciones de estos emails se encuentran propuestas económicas por parte de HBGary para llevar a cabo todo tipo de servicios de muy dudosa legalidad entre los que se cuentan: desarrollo de virus y malware para espionaje de personas, creación y diseminación de información falsa para desprestigiar e intimidar a los simpatizantes de wikileaks, creación de identidades falsas en redes sociales (facebook, et al) para infiltrar grupos de uniones de trabajdores y un grandísimo etc. Todo esto lo podría llevar a cabo HBGary Federal con total impunidad, debido a que sus clientes serían ciertos sectores gubernamentales.

En particular, por ejemplo, en uno de los emails de HBGary Federal se encuentra un archivo de muy mal gusto. En este documento de la empresa "Endgame Systems, Inc." se hace un estudio de la posibilidad que Venezuela instale misiles nucleares provenientes de Iran con alcance a Estados Unidos. El documento finaliza con una lista de "activos digitales" en las redes Venezolanas, de varias entidades gubernamentales. Esta lista viene acompañada de comentarios sobre vulnerabilidades informáticas encontradas en los sistemas Venezolanos por medio del uso de lo que sería su herramienta de escaneo automatizado. En otras palabras, una suerte de informe de inteligencia con posibles objetivos digitales. Un informe de muy mediocre calidad, hay que reconocerlo, pero que sirve con cierta eficiencia su propósito. A continuación la lista de objetivos identificados por Endgame Systems, Inc:

La lección que considero tan importante como para no esperar a la versión de cinesunidos.com es la siguiente: Nótese como los objetivos examinados no se limitan a entidades de gobierno. En la lista se encuentra una importante organización educativa Venezolana. Verdaderamente la trinchera no tiene limites y cualquier sistema podría convertirse en el blanco en una "Cyber Guerra". Considérese lo siguiente: tradicionalmente en las guerras se destruyen los puentes para evitar el traslado de suministros de comida y municiones. En el mundo de hoy, si alguien quisiera causar desabastecimiento de alimentos a una nacion entera, por ejemplo, bastaría con violentar los sistemas informáticos de las grandes cadenas de mayoristas, distribuidores y hasta supermercados al detal. El desorden y retraso sostenido podría ocasionar no solo pérdidas cuantiosas al gobierno en forma de ayudas y rescates, sino que incluso podría agudizar situaciones de tensión y desestabilización. Adicionalmente, en anteriores artículos hemos visto que nuestros sistemas informáticos financieros tampoco cuentan con una protección adecuada, hasta el punto de permitir ataques de denegación de servicios triviales y fuga de información confidencial.

En terminos criollos, estamos blanditos y viene el lobo. Y ciertamente, contra los poderes que nos acechan, ya no sirven los fusiles ni los tanques. Es hora de despertar de la pelicula mala y adaptarnos a la nueva realidad. Mientras mas pronto, mejor.

Nuevos Cursos de Seguridad Informática

Si estas interesad@ en cursos de seguridad informática del SANS Institute en el formato de "Local Mentor", dictados en español y para la región de latinoamerica, revisa el siguiente link:

Cursos de Seguridad Informática del SANS Institute

La lista de cursos ha sido actualizada para incluir capacitación adicional. Si tienes alguna duda, no dejes de escribir tus comentarios a través del enlace de contacto.

Recuperando Archivos Borrados. Parte I.

 Nos ha pasado a todos. Borramos el archivo equivocado, en el momento menos apropiado. ¿Cómo recuperarlo? Existen muchos programas con interfaz gráfica para recuperar archivos eliminados para el sistema operativo Windows. Sin embargo, no existen tantos programas similares para el sistema operativo Linux. Esta situación, aunado a los últimos cambios en los sistemas de archivos de Linux puede hacer que el proceso de recuperación sea algunas veces hasta frustrante.

En realidad, la posibilidad de recuperar archivos eliminados en Windows es en cierta manera mayor que en Linux. La diferencia se debe a que la eliminación de metadatos es actualmente relativamente más frecuente en los sistemas de archivos de Linux que en NTFS de Windows por ejemplo. En consecuencia, el procedimiento en Linux se hace un poquito más involucrado pues no se cuenta con la estructura del nombre de archivo y en muchos casos tampoco con la estructura de los metadatos.

Supongamos el siguiente escenario: Escribimos el archivo con la respuesta a la vida, el universo y a todo:

$ cat > respuesta_absoluta.txt
La respuesta a la vida, el universo y a todo es: cuarenta-y-dos.
^D
$ ls respuesta_absoluta.txt
respuesta_absoluta.txt
$

Perfecto, ahi esta nuestro archivo con la respuesta a la pregunta sobre la vida, el universo y absolutamente todo. Definitivamente un archivo muy importante. Sin embargo:

$ rm resp*
$

Oh no! mi expresión regular ha eliminado todos los archivos que comienzan con "resp" incluendo la respuesta a la vida, el universo y a todo! ¿Qué podemos hacer?

Para comenzar a recuperar archivos en Linux, el primer requisito es el fabuloso paquete de utilidades "The Sleuth Kit". Existen diversos paquetes de instalación para distintas distribuciones de Linux. Por ejemplo:

En Fedora:

yum install sleuthkit

En Debian:

apt-get install sleuthkit

Etc.

Específicamente, estaremos usando principalmente las utilidades icat y ifind del sleuthkit y la utilidad strings de casi todas las distribuciones de linux.

El primer paso es localizar la unidad de datos que almacenaba nuestro archivo. Como ya no existe la estructura de nombre del archivo eliminado, es necesario buscar algo distintivo en el contenido de mi archivo. En ese caso ejecutamos el comando:

$ strings -a -n 13 -t d /dev/sda1 | grep 'cuarenta-y-dos'

En donde /dev/sda1 es la particion en donde se encontraba nuestro archivo y la cadena "cuarenta-y-dos" es el string que nos interesa.

Afortunadamente, la respuesta a la vida, el universo y a todo es muy particular, de lo contrario estariamos revisando cadenas de caracteres por 7.5 millones de años y los ratones se comerían nuestros datos. Este comando, sin embargo, puede demorarse un buen tiempo dependiendo del tamaño de nuestro disco duro. Pero en todo caso, mucho menos que 7.5 millones de años.
...
125829120 La respuesta a la vida, el universo y a todo es: cuarenta-y-dos.
^C
$

El numero que arroja el programa strings es la posicion en bytes en el disco en donde se encuentra nuestra cadena de caracteres. El siguiente paso es determinar la unidad de almacenamiento que corresponde a esa posición. Como usualmente el tamaño de los bloques/clusters es de 4KB,simplemente necesitamos dividir 125829120 entre 4096. Sin embargo, podemos el verificar el tamaño de los bloques con este comando:

$ fsstat /dev/sdb1 | grep -i block\ size
Block Size: 4096
$

Ahora, podemos usar una calculadora para hacer la división como han malacostumbrado a los niños de hoy en día, o podemos hacerlo usando la linea de comando como "la escuela vieja":

$ echo '125829120/4096' | bc
30720
$

Este número (30720) nos dice en qué bloque se encuentra la información que deseamos. En el peor de los casos con esta información podemos recuperar por lo menos parcialmente nuestra información:

$ blkcat /dev/sdb1 30720
La respuesta a la vida, el universo y a todo es: cuarenta-y-dos.
$

Esta solución puede no ser suficiente si el archivo que recuperamos es mayor a 4096 bytes y si existe mucha fragmentación en el disco. En esos casos, y si hay suerte, sólo nos hace falta encontrar el inodo al cual pertenece este bloque y asi conseguir toda nuestra información:

$ ifind -d 30720 /dev/sdb1
12
$

Eureka! Este es el número (12) que necesitabamos. Ahora simplemente, si nuestro disco tiene suficiente espacio en blanco, y el archivo que vamos a recuperar es lo suficientemente pequeño, podemos simplemente:

$ icat /dev/sdb1 12 > resucitada_respuesta_absoluta.txt
$ cat resucitada_respuesta_absoluta.txt
La respuesta a la vida, el universo y a todo es: cuarenta-y-dos.
$

EEl último comando desafía las "buenas práticas" pues estamos recuperando un archivo y escribiendo sobre el mismo dispositivo bajo análisis. Pero en el caso de la vida, el universo y todo se pueden romper alguna que otra regla. En las situaciones en donde el archivo sea muy grande o que no exista mucho espacio libre en el disco analizado es mas recomendable recuperar la información  en un disco alterno.

Lamentablemente, en casi cualquier distribución de Linux moderna, el penúltimo paso no será existoso porque la información del inodo será eliminada al borrar el archivo. En estos casos es necesario utilizar técnicas más avanzadas de forensica digital que serán el tema de futuros artículos.

Amenaza Inminente. Parte II.

En el artículo anterior de la serie Amenaza Inminente, obtuvimos muy fácilmente una lista de direcciones IP que nos atacaban inclementemente. Un paso casi inmediato en cualquier respuesta a incidentes de este tipo es tratar de ubicar la localización geográfica de nuestro atacante(s). Para lograr esto con verdadera precisión se requiere correlacionar información de diversas fuentes. Sin embargo, una primera fuente de información es justamente de la dirección IP que comete el ataque.

Existen gran cantidad de scripts que pueden convertir una dirección IP en coordenadas del globo terraqueo. Esta transformación se hace a partir de la información de registro del manejador del bloque de IPs a que correponde la dirección transgresora. Por lo tanto, no siempre se encuentrá actualizada o completa pero no deja de ser un buen punto de partida de todas maneras. A pesar de su gran disponibilidad, muchos de estos programas caen rapidamente en desactualización debido a los cambios constantes que hacen los proveedores de la información de localización para alcanzar mayor eficiencia en su servicio. Lejos de reinventar la rueda, tomamos un script público y lo arreglamos para que funcione con la tecnología actual.

$ ./ips2kml.rb hostile.unique.ips

Nuestro script toma como entrada un archivo con una lista de direcciones IP, y retorna un archivo de extensión kml, con el mismo nombre, para ser usado con los servicios de google-earth. Con este archivo es posible generar todo tipo de gráficas que permiten visualizar la "superficie de la amenaza".

Adicionalmente, se puede extraer facilmente las 10 localidades con mayor actividad hostíl, por ejemplo:

$ grep description hostile.unique.ips.kml | cut -d ">" -f 2 | cut -d "<" -f 1 | sort | uniq -c | sort -gr | head

   1874 Caracas, Distrito Federal, VE
    174 Cúcuta, Norte de Santander, CO
    102 Taipei, T'ai-pei, TW
    102 , , RU
     52 Moscow, Moscow City, RU
     43 Bogotá, Cundinamarca, CO
     33 Buenos Aires, Distrito Federal, AR
     30 São Paulo, Sao Paulo, BR
     27 Seoul, Seoul-t'ukpyolsi, KR
     22 Bucharest, Bucuresti, RO

Como es de esperarse de un ataque planificado, la mayor cantidad de infractores son de la localidad de Venezuela, en donde se recoletó esta información. En un ataque oportunista al azar, no esperamos ver esta distribución tan correlacionada. La idea de nuestros atacantes es usar las computadoras mas "cercanas" en terminos de latencia, para seguir vulnerando más y más equipos. El costo de llevar a cabo este ataque desde una localidad remota simplemente no es aceptable. Por esta razón los creadores de virus/gusanos/malware introducen algoritmos que hacen preferir las direcciones IPs de la misma subred antes de las direcciones más "remotas".

Con esta metodología es posible conseguir aún más estadísticas útiles para tomar decisiones sobre cómo reaccionar ante el incidente. La mayoría de veces estas decisiones giran alrededor de detener la amenaza y continuar con la operación normal. Sin embargo, algo que muchas veces no se puede dar el lujo la organización bajo ataque es investigar más profundamente la amenaza. Los objetivos de esta investigación pueden estar dirigidos a averiguar los métodos, intenciones u objetivos y finalmente hasta el responsable o responsables del ataque. Desarrollar un pequeño laboratorio virtual para abordar estos ambiociosos objetivos será el tema de proximos artículos.

Inseguridad Bancaria Online. Parte II.

En artículos anteriores hemos elaborado superficialmente sobre lo devastador que puede ser la vulnerabilidad de nombres de usuario predecibles. Especificamente señalamos que el alcance del objetivo de nuestro atacante se hace significativamente más sencillo cuando tiene disponible esta vulnerabilidad. Los objetivos pueden ser tan variados como ejecutar un ataque de denegacion de servicios total y muy dificil de detener, o simplemente obtener un par de credenciales que le permitan penetrar mas profundamente en el sistema de la entidad financiera.


Sin embargo, no sólo cuando el sistema obliga al usuario a usar nombres predecibles estamos a merced de nuestro atacante. Algunos sistemas de banca en linea, a pesar de reconocer la importancia de utilizar nombres de usuario arbitrarios, fallan en darse cuenta que también los mensajes de error pueden dejar completamente inefectivo su mecanismo anti-adivinacion de usernames.

Lo único que el atacante requiere para aprovechar esta vulnerabilidad, es que el sistema provea distintos mensajes de error cuando se introduce un usuario válido o inválido. Esta vulnerabilidad es fácil de detectar cuando los mensajes de error anuncian explícitamente que el nombre de usuario es inválido. La razón de este fallo es hasta entendible en cierta manera. Los sistemas de banca en linea tratan de ser lo más amigables posible dando al usuario legítimo la mayor cantidad de información para corregir su error. Esta conveniencia no viene sin su gran costo de riesgo para el sistema de forma global, pues se le otorga la misma información al atacante.

La naturaleza de esta vulnerabilidad es muchas veces tan sútil, que no es necesario que el sistema revele a nuestro atacante explícitamente que el nombre de usuario intentado es inválido. Muchas veces, nuestro atacante puede inferir esta información por la lógica de funcionamiento de la aplicación. Por ejemplo, supongamos que nuestro atacante comienza su ataque de adivinación de nombres de usuario y se encuentra con un sistema como el de la gráfica de la derecha. El mensaje de error del sistema es explícitamente ambiguo con la intención de imposibilitar el ataque.

Sin embargo, si el atacante ingresa un nombre de usuario válido, y cualquier contraseña (muy probablemente incorrecta), el mensaje de error que arroja el sistema es el que se ve en la gráfica de la izquierda. Ahora, por más truco Jedi que intente el sistema, nuestro atacante casi nunca es tan tonto. A pesar de que el error anterior asegure que el nombre de usuario o la contraseña pueda ser el incorrecto, nuestro atacante sabrá que el anterior error sólo se produce cuando se introduce un nombre de usuario incorrecto.

El tema es tan poco entendido entre los desarrolladores, que aún cuando evitan los casos anteriores con mucho trabajo, fallan al dejar distintos códigos de error dentro del código fuente de la página que no son renderizados por el navegador, por ejemplo. A pesar de que estas diferencias no son evidentes para el ojo no entrenado, el atacante avanzado, analizará sin descanso las respuesta de nuestros servidores en busca de estas diferencias casi imperceptibles. Una vez que nuestro atacante encuentre una diferencia confiable - podría ser incluso un distinto tiempo de respuesta del servidor web - entonces empleará todo su arsenal para llevar a cabo sus objetivos.

Por esta y muchas otras razones es tan importante llevar a cabo pruebas de penetración avanzadas que detecten este tipo de errores "no evidentes" antes que nuestros atacantes los encuentren y exploten con éxito.

Ver también:
Inseguridad Bancaria Online. Parte I
Inseguridad Bancaria Online. Parte III