Tan solo un par de reflexiones en relación con el fallo general sufrido por las Blackberry de medio mundo la semana pasada.

Por un lado, y aunque informativamente creo que RIM ha reaccionado mejor que lo hizo SONY en el incidente de seguridad que tuvo hace unos meses —en el que el mutismo fue la actitud adoptada— deshaciéndose en disculpas hacia los usuarios y anunciando compensaciones, en mi modesta opinión, hablar de que “un fallo del conmutador de red” ha dejado fuera de juego durante cuatro días el correo electrónico de empresas y particulares de medio mundo es cuanto menos un poco difícil de creer.

Después de darle un pequeño repaso a VRRP, partimos del siguiente escenario. Nos encontramos en una LAN con un grupo VRRP formado por dos routers (A y B) con IP virtual 192.168.1.100. Como vemos en la salida el router A (configurado como Master) tiene una prioridad de 150 y una IP local de 192.168.1.5. En caso de caída, el router B tras un tiempo Master_Down_Timer, asumirá el rol de Maestro (Preemption enabled).

RouterA#show  vrrp
FastEthernet0 - Group 1
  State is Master
  Virtual IP address is 192.168.1.100
  Virtual MAC address is 0000.5e00.0101
  Advertisement interval is 1.000 sec
  Preemption enabled
  Priority is 150
  Master Router is 192.168.1.5 (local), priority is 150
  Master Advertisement interval is 1.000 sec
  Master Down interval is 3.414 sec      

RouterB#show  vrrp
FastEthernet0 - Group 1
  State is Backup
  Virtual IP address is 192.168.1.100
  Virtual MAC address is 0000.5e00.0101
  Advertisement interval is 1.000 sec
  Preemption enabled
  Priority is 100
  Master Router is 192.168.1.5, priority is 150
  Master Advertisement interval is 1.000 sec
  Master Down interval is 3.609 sec (expires in 3.533 sec)

A día de hoy sería extraño no encontrarse con configuraciones HSRP (Hot Standby Router Protocol), GLBP (Gateway Load Balancing Protocol) o VRRP (Virtual Router Redundancy Protocol) en organizaciones de pequeño/gran tamaño y más aún en entornos críticos donde prima la disponibilidad. El motivo es evidente: la mayor parte de los equipos son configurados con un Gateway estático generalmente obtenido por medio de DHCP. En caso de que dicho Gateway deje de funcionar implicaría la pérdida de paquetes hasta que el mismo se restableciera o bien hasta que otro Gateway fuera configurado en cada uno de los equipos. Aunque existen métodos para permitir una configuración dinámica del Gateway (proxy Arp, protocolos de routing RIP/OSPF, “ICMP router discovery protocol”, etc.) estos implican una configuración más “compleja” además de producir cierto overhead en la red. Por este motivo es por el que surgieron protocolos como HSRP, GLBP o VRRP, siendo este último la versión no propietaria de los protocolos desarrollados por Cisco.

1. Si mis datos no fallan, dentro de la Guardia Civil se instaura el Grupo de Delincuencia Informática hacia 1997, a cargo del Teniente Anselmo del Moral; desde 2000 hasta este mismo año el Grupo ha estado liderado por el Comandante Salom, y en estos momentos por ti. Ha llovido mucho estos años y, cambios de nomenclatura aparte, ¿cómo ha sido la evolución del Grupo durante este tiempo?

Si hace unos meses nos dejó Robert Morris, esta mañana nos enterábamos de la muerte el pasado domingo de Dennis Ritchie, dmr. Otro de los grandes que se va en este annus horribilis :(

Dudo que dmr necesite ningún tipo de presentación; jamás diseñó un iPhone o un iPad, pero entre sus pequeños aportes a la informática actual destacan el lenguaje de programación C (si alguien no se ha leído el K&R ahora es un buen momento para hacerlo y homenajear así a la R) o, junto a Ken Thompson, el sistema operativo Unix. Ahí es nada. Eso sin contar trabajos menos populares que Dennis Ritchie lideró o en los que participó de forma muy directa, como Plan9, Inferno o Limbo.

Estos trabajos le valieron a Dennis Ritchie todo tipo de premios y reconocimientos -entre ellos el Premio Turing de la ACM, quizás lo más parecido al Nobel en el campo de la informática- pero, sobre todo, la admiración de millones de personas que hemos devorado buena parte de lo que dmr escribía, usado y administrado sistemas operativos como Unix, programado en lenguajes como C y, en definitiva, tratado de aprender una milésima parte de lo que este genio ha aportado a la tecnología.

(N.d.E.: Vean antes la primera parte y la segunda parte)

Cuando la sesión se encuentra alojada en la cookie resulta mucho más difícil de explotar, debido a que cualquier navegador Web básico emplea la protección de mismo origen o “origin server”, donde un recurso web solo puede modificar atributos si ese recurso pertenece a su mismo dominio, puerto y protocolo, es decir, el servidor atacante no puede modificar la cookie del servidor víctima, y por tanto, no podrá fijar su sesión a la víctima.

Aún así existen distintas formas de intentar explotar una fijación de sesión almacenada en una cookie:

Tal como se describió en la anterior entrada, la fijación de sesión es una vulnerabilidad debida a un tratamiento incorrecto en la gestión de sesiones por parte de una aplicación Web. En concreto la vulnerabilidad radica en que cuando se concede una sesión a un usuario no autenticado, y éste se autentica en dicha aplicación, el valor de la sesión no cambia. Por tanto, el vector de ataque para explotar la vulnerabilidad consiste en intentar que la víctima se autentique en la aplicación usando una sesión previamente conocida por el atacante, de tal forma que una vez el usuario se autentique, el atacante pueda acceder a la aplicación con el mismo rol que la victima gracias a que conoce la sesión de ésta.

Para comprender de forma más sencilla el funcionamiento de la vulnerabilidad vamos a presentar una posible prueba de concepto, donde el recurso web “login.php” es vulnerable a la fijación de sesión en un escenario con un servidor web vulnerable, una víctima, un atacante y un servidor web del atacante. Veamos por paso el funcionamiento mediante un ejemplo:

El protocolo HTTP fue diseñado para cumplir unos requisitos muy limitados, sin tener en cuenta muchas de las necesidades de la actualidad; por ejemplo, el protocolo no es capaz inicialmente de proporcionar o restringir visibilidad sobre sus recursos dependiendo de qué usuario los solicite.

Cuando un usuario accede a un servidor web éste realiza el saludo a tres bandas, solicita un recurso al servidor mediante HTTP, el servidor le devuelve el recurso solicitado y se cierra la conexión, por lo que si pinchamos en un enlace de la web, el servidor lo vería como una petición nueva y desconocerá que somos el mismo usuario. Por ello fue necesaria la creación del concepto de sesión, de tal forma que el servidor web sepa que somos el mismo usuario y en función de la sesión, proporcione visibilidad sobre unos recursos y con un determinado formato.

Estimados lectores, espero que me permitan un post un tanto atípico y no especialmente relacionado con la seguridad pero si con las TIC. A estas alturas de la mañana todos ustedes estarán al tanto de lo sucedido; esta mañana fallecía Steve Jobs, fundador de Apple, con lo que el sector de las tecnologías de la información ha perdido uno de los grandes visionarios de la actualidad, hasta el punto de que en muchos lugares lo equiparan con Thomas Edison. Eso tan solo el tiempo lo dirá.

Por mi parte diré que no soy un consumidor de productos Apple (no por ninguna razón en especial) y no he seguido la carrera de Steve Jobs muy de cerca, así que en un primer momento pienso que Steve Jobs puede dar una imagen un tanto altiva y distante. Sin embargo ayer por casualidad vi un video en el que pronunciaba un discurso especialmente emotivo sobre su vida en la universidad de Stanford. En este discurso se veía a una persona cuya vida ha sido dirigida por una voluntad inquebrantable y una pasión irrefrenable por su trabajo, alguien que no solo ha transcendido a todos los problemas que ha encontrado a lo largo de su vida sino que ha sabido sacar partido de estas situaciones.

Como él mismo dijo en este discurso: en la vida se trata de conectar puntos…

Supongo que a muchos de ustedes les sonarán las reglas de Emerging Threats y sobretodo les sonarán el conjunto de reglas de la archiconocida “Russian Business Network” (RBN), sobretodo si disponen de sus sondas NIDS en un entorno mediano/grande, con gran cantidad de tráfico, donde por regla general suelen hacer acto de presencia. Estas reglas para el que no las conozcan alertan de conexiones realizadas o recibidas de direcciones de red que han sido clasificadas como maliciosas, sospechosas, peligrosas o similar. Este listado se actualizada de manera diaria, por lo menos en Emerging Threats, por lo que es bastante recomendable que nosotros también actualicemos este conjunto de reglas a la par que la fuente, ya que es un grupo bastante dinámico.

Estas reglas son muy útiles y no lo vamos a negar, ya que son un indicador que nos alerta de que existen conexiones sospechosas, desde orígenes o hacia destinos sospechosos; y lo que aportan merece la pena. Pero por otro lado, hemos podido comprobar que generan falsos positivos ciertos segmentos de red que están incluidos y que se han producido tras una simple navegación de un usuario.