Archive for October, 2009

El día que ICMP salvó la red, un tributo a su creador

Wednesday, October 28th, 2009

A consecuencia de las múltiples formas de aprovechar la funcionalidad del protocolo ICMP para el proceso de hacking, muchos administradores de TI y de red han optado por radicalizar su bloqueo hasta extenderlo a los mismos sistemas end-point (servidores Windows, Unix, etc).

A pesar de esa práctica, los especialistas en internetworking saben que eso es un problema que no debe ser combatido, sino mas bien asimilado (aceptado). De hecho, los riesgos con ICMP no sólo se dan con su funcionalidad, sino, también, con su implementación perse (lo que lo hace doblemente más antipático). “buenos catalizadores para detestarlo, a simple vista”, pero mejor veamos la historia de:

El día que ICMP salvó la red

“icmp_redirect_packet” es un paquete creado por un sistema para advertir a su destinatario que la ruta principal ha variado en la red. Saber que eso es posible, ha provocado la preocupación de una brecha facilitadora para un posible ataque de MiTM (man in the middle) en la LAN (el único lugar donde tiene efecto). De hecho, si busca en la Google, hallará que casi todos los sistemas operativos modernos aceptan cambiar su tabla de rutas al recibir ese paquete ICMP. Igualmente, verá que desactivar esa opción tampoco es gran reto, y parece ser la práctica de algunos administradores de sistemas (de hecho fue la mía hace 10 años atrás).

Sin embargo, el presente año (2009) mientras nos encontrábamos atendiendo un probable incidente de seguridad con uno de nuestros servicios de respuesta a emergencias, descubrimos algo fascinante. La red bajo análisis reportaba una alta latencia en las comunicaciones LAN, y un gran defecto en la apertura de las aplicaciones y su operación con consultas de base de datos. Luego de descartar la supuesta presencia de un gusano (de esos que agotan los equipos), observamos decenas de paquetes ICMP_REDIRECT actuando cuál si fueran abejas, para reconstruir las rutas de cientos de hosts, a los que el host aceptante (un servidor central Windows) no podía llegar porque tenía la ruta equivocada.

De no haber sido porque ese servidor central de S.O. Windows aceptaba (por defecto) ICMP_REDIRECTs, los hosts que se conectaban a él no habrían jamás podido llegar a establecer comunicación alguna, y la red habría tomado más tiempo en repararse.

Nuestro análisis y fabuloso hallazgo se dio durante una intensa situación en dicha LAN, en una semana en que la misma se encontraba migrando a nueva y más veloz tecnología de interneworking LAN. Durante esa migración apareció una nueva ruta, que provocaría la dislexia al servidor Windows, de no ser por un router bondados que emanaba gentilmente ICMP_REDIRECTs, que él aceptaba con igual gentileza. Aunque este es sólo un pequeño ejemplo del poder de ICMP, en nuestra trayectoria hemos visto muchas otras veces en que ICMP ha demostrado ser útil, por sobre la agenda de seguridad.

Ahora que le presentamos el potencial que tiene el invento de Jon Postel, saltará al tapete la crítica aguda respeto varias oposiciones a ICMP, como el bloqueo de paquetes ICMP_TIME_EXCEEDED en la Internet de algunos proveedores. Esa práctica impide supuestamente que un atacante pueda mapear la red, aunque también lo hace con sus usuarios convencionales (Hasta aquí, si quiere saber qué bloquear o no bloquear en ICMP, le sugerimos visitar a nuestros amigos de TEAM CYMRU)

Recuerde esto, la seguridad es, a veces, como contrapeso. Mucho contrapeso, puede hundir al barco. Si no es flexible con el trabajo de ICMP, sin duda se sentirá más seguro, pero un buen día podría lamentar no tener a este salvavidas de la red.

Quién creó ICMP

ICMP fue creado principalmente por Jon Postel, también considerado por los noventa, como el “dios de la red“. Jon postel también creó parte de la operación del famoso protocolo DNS. A pesar de lo que se diga de los defectos en la lógica de seguridad, la comprensión de Jon acerca de la red ha sido de mucho provecho para la operación tan transparente de la que gozamos hoy. Sin trabajos tan silenciosos como el suyo, es previsible que la tecnología de Internet y los negocios montados en ella tendrían varios años de retraso a comparación de la actual. Si sólo se comprendiera mejor su famoso “principio de robustez” los sistemas y la seguridad de la información podrían ser una mejor propuesta a la que hoy conocemos.

“Be liberal in what you accept, and conservative in what you send” (Jon Postel)

La buena seguridad implica equilibrio, y el equilibrio implica conocimiento profundo. Aventurarse a coger lo primero que le ofrece el medio corriente, podría ser un futuro error a lamentar.

JaCkSecurity
Conocimiento, Conciencia y Consultoría

La codicia genera codicia

Monday, October 19th, 2009

Lo prometido es deuda, aquí el post que le sigue al de la semana anterior.

La teoría dice que el valor de confidencialidad de la información debe reducirse con el pasar el tiempo. Ello implicaría pasar un documento o data de super secreta -a- pública o sin valor sensible, en cosa de años. Sin embargo, un caso curioso nos haría pensar lo contrario. [Luego de leer el enlace señalado, continué abajo.]

A pesar de que el sentido común nos dice que los custodios de esa información tuvieron parte de responsabilidad en no proteger los datos divulgados (notas estudiantiles), un análisis más calmado nos podría dejar una lección aún más valiosa.

Si observamos con mayor paciencia el citado caso, notará que la información filtrada no habría tomado la misma cognotación de destape mediático de no haber sido por la misma regla que la forzaría a protegerse, vale decir, la promoción de una valla profesional (ley tercio superior) por parte de alguien con una valla reprensible en su pasado estudiantil.

Esto significaría que información con décadas de devaluación puede reactivarse a un valor más alto de sensibilidad por causa del mismo dueño de la información. La causa de ello, sin embargo no es una previsible falla en la gestión o clasificación de datos (del owner), sino mas bien una más intrínseca a los seres humanos, la codicia. Una codicia generada por mantener una reputación intachable (no del divulgante, sino del mismo dueño de la información).

En suma, la codicia de un information-owner genera codicia, y expone a la información a un riesgo innecesario o mayor. Este es el consejo que le damos:

Si tienes un control de seguridad, haz lo que escribes (procedimientos), y escribe lo que haces (en la práctica). Si hay algo que no haces, no lo pongas, esa codicia te estropeará la reputación, quizás, la moneda más importante del mercado laboral y empresarial.

Javier Romero
JaCkSecurity, CTO
Conocimiento, Conciencia y Consultoría

Mientras más grande, menos se ve

Monday, October 12th, 2009

Si googlea un poco hallará la respuesta del acertijo señalado en el título de este post. [Luego de ello, continúe leyendo.]

Si la verdad envuelta en el acertijo está en lo correcto, piense de esta forma: mientras más complejo y enmarañado se pueda convertir a un sistema, más díficil será que alguien lo pueda comprender, y así los secretos (buenos o malos) estarán mejor guardados.

A partir de aquí nos preguntamos ¿existirán sistemas así?

Garabato

Probablemente sí, se dice que a la SEC le hubiera tomado unos 10 años en detectar el fraude de Enron (a través de las auditorías convencionales), y no precisamente porque la segunda no le proporcionara suficiente información, sino, más bien, por que el volumen de ese tipo información ha sido tan extensa, que se ha convertido en lo suficiente enmarañada para procesarla en tiempo real.

Entonces, es posible que la seguridad de cierta información confidencial no sólo se pueda proteger ocultándola, sino también, exacervándola. Por el contrario, el levantar muchas vallas de protección alrededor de la información podría incrementar la codicia por revelarla (ver próximo post).

Como lo señalamos en nuestra exposición “Seguridad en Tiempos de Crisis”, en el II Simposio Internacional de Redes y Comunicaciones de Datos”, la tendencia mundial de la transparencia está creciendo. Si tiene proyectos de cifrado en curso, estos podrían terminar siendo un absurdo y hasta una peligrosa maniobra para su reputación como gestor, si no comprende del todo los beneficios de mostrar vs. ocultar.

Javier Romero
JaCkSecurity, CTO
Conocimiento, Conciencia y Consultoría