A Django site.
August 9, 2008

Nicolás Varcarcel
nxvl
Nikolas Valcarcel
» unthinkable paranoia

Internet is now proved to be unsecured even if DNS are patched and i reached and unthinkable level of paranoia. Given that launchpad ppa (which are awesome for QA) doesn’t use signed packages, so i can’t actually check the integrity of them i’ve changed all my sources.list from url’s to ip’s so i can’t (at least i hope) be vulnerable to cache poisoning \o/

P.S: Please launchpad team, make ppa use signed packages!

July 23, 2008

Gustavo Picón
tabo
tabo :: para todos y para nadie
» Vulnerabilidad: Servidores de DNS peruanos

(Update: y el bug ya se hizo público 2 semanas antes del plazo, y muchos servidores peruanos siguen vulnerables, excelente)

Update2: Ya hay plugin de metasploit para detectar el puerto de origen de los servidores DNS (lo que permite buscar todo un rango de IPs con facilidad). Esperen un exploit en unas horas.

ENJOY!

Pasen y tomen asiento. Trataré de ser breve y conciso, sin desviarme a temas "esotéricos" como IPv6, encriptación y jerga de seguridad informática (pero me pondré técnico y repartiré patadas al final, si sabes la diferencia entre un resolver y un name server, te puedes saltar la introducción). Aunque posiblemente no entiendan la mitad de lo que voy a decir, al menos crean en mis conclusiones. Deriven esto a los jefes/gerentes de sus áreas de sistemas y proveedores de Internet; y si la razón y un link a este post no funciona para convercerlos, apliquen el principio de ingeniería de Dilbert para convencer MBAs:


Esta tira de Dilbert que usé hace casi dos años en este mismo blog, tiene hoy una importancia especial: los servidores a los que se refiere son de los mas importantes que podemos tener en internet (aunque muchos ni sepan que existen): los servidores de DNS.

Qué es DNS?


(leer esta sección solo si hay un interés real en la introducción básica al problema, la pueden ignorar para ir directamente a los trolls)

DNS es un protocolo de Internet que permite entre muchas otras cosas transformar un nombre de dominio como www.google.com, que es algo que un ser humano maneja con relativa facilidad, a algo manejable por una computadora: un número bastante grande conocido como dirección IP (que muchos conocen en su versión amigable a humanos como los 4 numeritos separados por puntos). Otra de las funciones fundamentales de DNS es la de publicar qué servidor va a recibir los correos electrónicos que enviamos.

Esto hace que los servidores de DNS sean blanco frecuente de ataques; ya que quien logra traerse abajo un servidor de DNS, puede desaparecer de Internet a una empresa, o a todo internet para un grupo de usuarios. Por otro lado, quien logra manipular un servidor de DNS tiene carta abierta para ataques de phishing, robo de información, etc.

Ahora vamos a profundizar un poco mas en la arquitectura de DNS (que puede ser una de las mas complejas que hay asi que no nos complicaremos mucho). Existen básicamente dos tipos de servidores de DNS: los servidores de DNS per-se, que tienen autoridad sobre la información de algún dominio, y los resolvers, también conocidos como servidores de cache. Veamos un gráfico del documento que define el standard de como debe funcionar DNS.


Local Host | Foreign
|
+---------+ +----------+ | +--------+
| | user queries | |queries | | |
| User |-------------->| |---------|->|Foreign |
| Program | | Resolver | | | Name |
| |<--------------| |<--------|--| Server |
| | user responses| |responses| | |
+---------+ +----------+ | +--------+
| A |
cache additions | | references |
V | |
+----------+ |
| cache | |
+----------+ |



Cuando un cliente, como un navegador de internet, necesita resolver un nombre de dominio, se conecta a un Resolver Server, no directamente a un servidor de DNS. Esta distinción se ha perdido ya que la implementación de-facto de DNS, ISC BIND, permite manejar tanto el resolver como el name server con el mismo programa: el viejo y querido named. Esto quiere decir que cuando configuran los servidores de DNS para conectarse a Internet en sus computadoras de escritorio, lo que en verdad están configurando son los resolvers.

Uno de los puntos flojos en este esquema es el mecanismo en el que el Name Server envía la información al Resolver para que este la almacene en el cache (que es un almacenamiento temporal para evitar preguntarle la misma información al Name Server una y otra vez). Los ataques que aprovechan esta debilidad se conocen como Envenenamiento de cache de DNS. Cuando un atacante logra envenenar el cache de un resolver, logra tener el control de las peticiones de los usuarios a este resolver, sin necesidad de haber comprometido el servidor de nombres principal.

Cuál es la vulnerabilidad de DNS?


Hace 5 días, el 8 de julio, sucedió algo que no se había visto en la industria de la seguridad informática: publicación masiva de actualizaciones de seguridad para los principales servidores de DNS: ISC BIND, Microsoft Windows Domain Name System, Cisco, etc. En el VU de CERT se explica a grandes rasgos la vulnerabilidad y da una lista de sistemas afectados. NO HAY DETALLES PÚBLICOS SOBRE LA VULNERABILIDAD. Pero si sabemos que existe, y ha sido confirmada hasta por los mas escépticos. Esto es algo serio. MUY serio. Tan serio que estoy sentado a las 4:30am escribiendo esto luego de haber pasado 3 días en los que he dormido en total 5 horas (por otros temas, el punto es que debería dormir en vez de escribir este artículo). Los vectores de ataque son conocidos, los paliativos y soluciones también, desde hace muchos años. Ataques de cache de dns han existido con anterioridad, pero el elevado ratio de éxito de este nuevo ataque y sobre todo la portabilidad que tiene, hace que sea una de las amenazas mas serias que ha tenido Internet como un todo desde hace muchos años.

Afortunadamente, Dan Kaminski, el investigador de seguridad que descubrió el problema, ha dado un mes de plazo desde la fecha de publicación de los parches para esta vulnerabilidad (Julio 8), hasta la publicación de los detalles para realizar el ataque el 7 de Agosto en una conocida conferencia de seguridad. Asi que los hostmasters (los administradores de los servidores de DNS), tienen tiempo para actualizar sus servidores (asumiendo que en el transcurso de estos días nadie descubra la vulnerabilidad y publique un 0day).

Y los hostmasters responsables ya están actualizando los servidores.

Pero en Perú la cosa no va tan bien.

Qué pasa en Perú?


Habiendo pasado ya una semana de la publicación de los parches de la vulnerabilidad, decidí hacer algunas pruebas sobre los principales servidores de DNS peruanos. Los resultados son bastante preocupantes.



(ver tabla en formato original)

Como se puede ver, los servidores de DNS mas usados del país no han sido parchados luego de la primera de las cuatro semanas de plazo que hay para hacerlo. Es en este momento en que quiero hacer un comentario personal.

Si bien se ha dado un mes de plazo para parchar los servidores, hay un detalle: toda, TODA la comunidad de seguridad informática tiene los ojos puestos en esta vulnerabilidad, los buenos y los malos. Hay mucha gente dedicada en este momento a encontrar el problema para poder hacer una utilidad que lo aproveche. Posiblemente esta utilidad ya exista, pero no se hace pública aún. El riesgo en este momento es que los administradores se confíen en el mes de plazo y en este lapso de tiempo se publique una utilidad que explote la vulnerabilidad. Si esto sucede y los servidores siguen sin estar parchados, las consecuencias podrían ser CATASTRÓFICAS. Y quisiera decir que estoy hablando en sentido figurado, pero esto es SERIO, MUY SERIO.

Ahora, se que hay limitaciones técnicas para no actualizar: complejidad en la red de servidores DNS, dependencias, pérdida temporal de servicio para los clientes, y en el caso específico de este parche, modificaciones en los firewalls que están delante de los DNSs. Si bien estas limitaciones son técnicas y perfectamente entendibles, YA VA UNA SEMANA y el riesgo es demasiado alto como para dormirse.

Debido a que este problema es serio, voy a hacer todo lo posible por actualizar este cuadro diariamente hasta el día de la publicación detallada de la vulnerabilidad (agosto 7). Asi que espero que para ese día (idealmente mañana mismo!) todas las entradas esten en verde.

You are doing it wrong


Otro punto preocupante, es el desconocimiento básico de fundamentos de seguridad por parte de muchas instituciones que aparecen en la lista. Voy a decir algo muy sencillo que hasta un MCSE va a entender:

Si tienen un Name Server autoritativo, este NO DEBE FUNCIONAR COMO RESOLVER.Si usan BIND, limiten allow-recursion con un acl. Si usan servidores DNS windows formatéenlos, instalen un sistema operativo de verdad (nos gusta FreeBSD en el server room) y compren un libro de BIND (o entren en la mente de djb ). Pero por favor, nunca, nunca, NUNCA dejen que su servidor autoritativo permita recursion. Y si no me creen a mí, por favor, créanle a D.J. Bernstein.

TIP OF THE DAY (o como evitar los espantosos DNSs de speedy.com.pe): Si han leido este artículo en su totalidad, habrán notado algo en el párrafo anterior: pueden usar cualquier servidor que aparezca en la tabla con color rojo o verde como "servidor de DNS" en sus equipos, ya que estan funcionando como resolvers. Así que si no desean usar los lentísimos DNSs de speedy, o piensan como ya estoy empezando a pensar que el maravilloso OpenDNS es MALIGNO, pueden usar los DNSs de bancos o de diarios importantes, al menos hasta que sus administradores aprendan a configurar sus servidores ;).

CONCLUSION

El problema es MUY SERIO y nos afecta A TODOS. En este momento mi principal preocupación es que se publique una utilidad que explote esta vulnerabilidad antes que termine el periodo de gracia y coja a muchos servidores (y por ende a sus usuarios!) sin estar actualizados. Mi segunda preocupación es que lleguemos al final del periodo de gracia y debido a falta de información o capacidad técnica, hayan todavía servidores sin actualizar. Esto sería una total irresponsabilidad, por lo que iré actualizando esta tabla con la mayor frecuencia posible. Si desean que aumente algún otro servidor a la lista de análisis, mencionenlo en los comentarios.




Update: Dan Kaminski da una explicación sencillísima del problema con la ayuda de su asistente.












FAQ (actualizado 20080720)



Actualicé mi BIND al último parche, pero sigo vulnerable. Por qué?

El parche consiste en hacer que el puerto de origen de las respuestas del servidor sea aleatorio y con una entropía alta. En la mayoría de casos he visto que tienen la opción "query-source" activada, fijando el origen al puerto 53, efectivamente ANULANDO EL PARCHE. Otro problema es que si se reduce el uso de puertos disponibles para el origen, se reduce también la entropía, la opción que tienen que verificar para esto es "avoid-v4-udp-ports".

Otra opción es que sea su firewall el que este haciendo esto, verifiquen sus reglas.

Desde mi red la entropía de los puertos de origen es alta, pero por Internet es bajísima, qué pasa?

Posiblemente la salida de tus DNSs sea por un NAT en un firewall cisco/checkpoint/nokia/etc, que van incrementando secuencialmente los puertos de origan al hacer NAT (y asi venden seguridad... *sigh*). Reemplacen sus firewalls por equipos OpenBSD/FreeBSD con PF o en todo caso Linux con netfilter que si hacen esto (en BSD out of the box, en Linux con un poco de configuración). Otra opción es consultar con su vendor como habilitar la randomización de puertos de origen con entropía alta. Otra es darles IPs públicas a los DNSs para que no salgan por NAT. Si ninguna de estas es una opción válida, pues esperen a la andanada de script kiddies de agosto :)

Ojo: Checkpoint los protege si han pagado la suscripción de SmartDefense. Si _no_ la tienen, su equipo Checkpoint genera UDP source secuenciales (anulando los parches de sus servidores de DNS) Esta es una _excelente_ manera de Checkpoint para hacer que los clientes se suscriban :)

February 18, 2008

Nicolás Varcarcel
nxvl
Nikolas Valcarcel
» DNI electrónico

El viernes pasado y dado que mi DNI estaba por vencer, fui a hacer mi tramite de la renovación de este y viendo los videos que pasaban mientras esperaba me enteré de la nueva opción que estaban “desarrollando”, el DNI electrónico. Primero me pareció una gran noticia y un buen proyecto, pero instantáneamente esa sensación fue seguida de varias preguntas, conociendo sobretodo como funciona el estado peruano, algunas de las cuales fueron:

  • Que tipo de cifrado utilizarán para las firmas digitales
  • Utilizarán algún algoritmo de cifrado desarrollado y probado o cometerán sacrilegio al usar el suyo propio
  • El cifrado de documentos será mediante alguna aplicación propia de la reniec o una alternativa utilizada y libre
  • Que tan fácil de romper será el cifrado
  • Los “usuarios” generarán sus propias llaves privadas o simplemente les darán la llave ya generada en alguna computadora de dicha entidad con la opción que alguien pueda “sustraer” dicha llave privada
  • En caso la llave privada sea robada, habrá alguna opción de cambiarla
  • Si la anterior es Sí, que validez tendrán los archivos firmados anteriores
  • Si la llave privada esta contenida dentro del chip del DNI, como se asegurarán que al ser robado el documento no sea utilizado por un ladrón para suplantarnos
  • Si la llave privada esta contenida dentro del chip, como podré hacer uso de ella? Necesitaré una lectora de chips?
  • Estarán las llaves públicas en algún lugar accesible o solo será posible verlas/obtenerlas por ciertas entidades

Como buen geek interesado en la seguridad empecé a investigar, buscar en internet, leer sobre el documento y mi respuesta fue la esperada: no hay información de NADA de esto en internet, o por lo menos no la encontré, será que lo que me temo es cierto y nadie sabe como funciona (como suele pasar en Perú), será que están confiando la seguridad en un cifrado “desconocido” por el atacante, será tan fácil de romper como hacer un simple ataque de ingeniería inversa?

En resumen: el estado quiere darnos una nueva tecnología y una nueva forma de “identificarnos”, virtualmente, pero no hay información sobre como funcionará esta, que es lo que realmente nos están dando, a que peligros nos podríamos exponer y al buscar una respuesta a estas interrogantes solo se encuentran más preguntas y dudas, pero total, a la población no le interesa, si un pequeño porcentaje tiene acceso a una computadora, y de ese pequeño porcentaje somos incluso mucho menor la proporción de ciudadanos que conocemos del tema, entonces no nos preocupemos por informarles! Pero no podemos dejar que jueguen con la seguridad de nuestra identidad, la reniec debe poner bien en claro todos los aspectos de este nuevo cambio, los legales, los de uso y los técnicos.

February 13, 2008

Nicolás Varcarcel
nxvl
Nikolas Valcarcel
» Ubuntu Pentesting Team

Ubuntu Pentesting Team is team formed to continue check the security of the ubuntu resources (i.e: wiki.ubuntu.com, launchpad.net, qa.ubuntu.com, etc…) and as it will deal with the security holes on those resources it’s a restricted team. It has a really nice purpose, and sound like really exciting tasks so i try to join it, attend to the previous meeting only to sit and watch, but at this time i apply myself, and i was approved! so now i’m part of the Ubuntu Pentesting Team!! I’m really excited and hoping to start working soon, see you on the Pentest Day!!

December 24, 2007

Enrique Llanos
stereoskit
... y Asi habló Zarathustra
» Asterisk to ascii password.

It all started with me surfing through my old archives looking for a little executable file i used some years ago while trying to recover my old blogger account password… the reason for this search was: I needed to read an asterisk (yeah the glyph ‘*’) password to ascii from a DSL router from one of our worsts internet providers, i found several programs that helped me get the job done, yet im my research i found this[0] piece of code to be inserted in the address bar of the Firefox browser, if you read it, it is quite simple yet clever and fun, the surprising thing for me was that i didn’t know you can pass directly javascript code into a address bar and the browser would execute it, havent made much research about this last yet, but i don’t think of it as a bug but as a feature[1], of course back then (2 or 3 years ago) i didn’t know you can store your html forms logons directly in the Firefox browser.

[0]

function() {
var s,F,j,f,i;
s = "";
F = document.forms;
for(j=0; j<F.length; ++j)
{
f = F[j];
for (i=0; i<f.length; ++i)
{
if (f[i].type.toLowerCase() == “password”);
s += f[i].value + “\n”;
};
};
if (s) alert("Passwords in forms on this page:\n\n" + s);
else alert("There are no passwords in forms on this page.");
};

[1] to be researched.

Blogalaxia Tags:

April 4, 2007

Enrique Llanos
stereoskit
... y Asi habló Zarathustra
» security is not a product!

But is something most online stores, banks, etc sells us, here’s a clear case of it.

screenshot_ripley.jpg

and YES, using Ethereal you can see your password passing through

October 30, 2006

Gustavo Picón
tabo
Hacking for fun and profit
» XKCD on Cryptography, Alice, Bob and Eve the Eavesdropper

We already got a great UNIX, and programming jokes from XKCD, but the new one is about cryptography (funny because I’ve been reading a lot about Cryptography the last 2 weeks).

In case you don’t know, in Cryptography, Alice and Bob are commonly used instead of A and B, as in “Alice delivers a message to Bob”. There are other recurring characters like:

  • Eve, the eavesdropper of Alice and Bob’s communication.
  • Trent, a trusted third party.
  • Mallory, a malicious hacker that can not only intercept Alice and Bob’s communication, but also modify, substitute, delete or introduce new messages, impersonating both Alice and Bob. We know this as Man in the Middle Attack.

XKCD - Alice and Bob

By the way, there is also the Alice and Bob rap by “computer science gansta rapper” MC Plus+.

Alice and Bob

Alice is sending her message to Bob
Protecting that transmission is crypto’s job
Without the help of our good friend Trent
It’s hard to get that secret message sent

Work tries to deposit a check of your salary
But with no crypto it’ll be changed by Mallory
You think no one will see what it is you believe
But you should never forget there’s always an Eve

(Chorus)

‘Cause I’m encrypting sh*t like every single day
Sending data across the network in a safe way
Protecting messages to make my pay
If you hack me, you’re guilty under DMCA

DES is wrong if you listen to NIST
Double DES ain’t no better, man, that got dissed
Twofish for AES that was Schneier’s wish
Like a shot from the key, Rijndael made the swish

But Blowfish is still the fastest in the land
And Bruce used its fame to make a few grand
Use ECB and I’ll crack your cipher text
Try CFB mode to keep everyone perplexed

(Chorus)

Random numbers ain’t easy to produce
Do it wrong and your key I’ll deduce
RSA only public cipher in the game
Creating it helped give Rivest his fame

If we could factor large composites in poly time
We’d have enough money to not have to rhyme
Digesting messages with a hashing function
Using SHA-1 or else won’t cause dysfunction

(Chorus)

Nerds.