Logo de Heartbleed.
Mientras las empresas se apresuraban en los últimos días para hacer frente al último gran agujero de seguridad cibernética conocido como Heartbleed, investigadores de la Universidad de Texas en Dallas (EE.UU.) encontraban una solución que corrige la vulnerabilidad, y también detecta y atrapa a los hackers que puedan estar utilizándola para robar datos confidenciales.
La sofisticada técnica, conocida como Red Herring (literalmente, arenque rojo; significa "pista falsa"), ha sido creada por un equipo dirigido por Kevin Hamlen, profesor asociado de ciencias de la computación en el la Escuela Eric Jonsson de la universidad. Automatiza el proceso de creación de servidores señuelo, haciendo a los hackers creer que han tenido acceso a información confidencial segura, cuando en realidad sus actos están siendo observados, analizados y transmitidos a la fuente.
"Nuestro cebo automatizado crea un servidor Web fijo que parece y actúa exactamente igual que el original, pero es una trampa", explica Hamlen en la nota de prensa de la universidad. "Los atacantes piensan que están ganando, pero no es así. De ese modo, podemos averiguar lo que están intentando hacer, en lugar de simplemente bloquearlos".
Heartbleed, dado a conocer la semana pasada, afecta a sitios web que utilizan la biblioteca de códigos de computación OpenSSL para cifrar conexiones supuestamente seguras que se utilizan para fines sensibles como banca y compras online, envío y recepción de correos electrónicos, y redes de trabajo remotas.
En 2012, una nueva característica denominada Heartbeat (Latido) se añadió al software principalmente para conexiones lentas a Internet. Heartbeat permite que las conexiones estén abiertas, incluso durante el tiempo de inactividad. Un fallo en la implementación permitió que información confidencial pasara a través de la conexión, de ahí el nombre Heartbleed (Corazón sangrante).
Aunque Heartbleed se encuentra ahora en proceso de arreglarse, las víctimas se enfrentan al reto de no saber quién puede estar ya aprovechándolo para robar información, y qué información pueden estar buscando.
Una solución común para este tipo de problema es crear una trampa, una trampa que atraiga y exponga a los atacantes. Normalmente, esto puede implicar la creación de otro servidor Web en otro lugar.
Soluciones
"Hay todo tipo de soluciones ad hoc en las que la gente trata de confundir al atacante mediante el despliegue de servidores falsos, pero nuestra solución construye la trampa en dentro del servidor real, de modo que los ataques contra el servidor real se pueden detectar y controlar", explica Hamlen. "Nuestra idea se puede desarrollar de forma realmente rápida y fiable a medida que se conozcan nuevas vulnerabilidades."
El algoritmo de Red Herring creado por Hamlen convierte automáticamente un parche - código ampliamente utilizado para arreglar vulnerabilidades como Heartbleed- en un cebo que puede a la vez atrapar al atacante.
"Cuando apareció Heartbleed, se convirtió en el test perfecto de nuestro prototipo", señala Hamlen.
Como el atacante piensa que está robando de datos, se puede rastrear el ataque para averiguar cuál es la información que busca el atacante, cómo funciona su código malicioso y quién está enviándolo.
"En su comunicado inicial, la firma de seguridad Codenomicon instó a los expertos a que empezaran a construir manualmente cebos para Heartbleed", recuerda Hamlen. "Puesto que ya habíamos creado algoritmos para automatizar este proceso, hemos tenido una solución en cuestión de horas."
Actuación inmediata
Cuando las noticias sobre Heartbleed se hicieron públicas el 8 de abril, el doctorando en ingeniería de software Frederico Araujo comenzó a investigar la vulnerabilidad, y ya la había puesto en práctica a las 2:30 de la madrugada del 9 de abril.
"Me sentí muy orgulloso de que [Araujo] tomara la iniciativa", reconoce Hamlen. "Normalmente , yo personalmente habría empezado a trabajar en ello antes, pero había estado poniendo notas toda la noche anterio".
Se estima que pasarán varias semanas hasta que algunas organizaciones puedan protegerse completamente contra Heartbleed. Hasta entonces, Hamlen recomienda no iniciar sesión en ningún servidor sensible a problemas de seguridad. "Evitar introducir su contraseña en los próximos días, y después cámbielas todas", recomienda Hamlen.
La sofisticada técnica, conocida como Red Herring (literalmente, arenque rojo; significa "pista falsa"), ha sido creada por un equipo dirigido por Kevin Hamlen, profesor asociado de ciencias de la computación en el la Escuela Eric Jonsson de la universidad. Automatiza el proceso de creación de servidores señuelo, haciendo a los hackers creer que han tenido acceso a información confidencial segura, cuando en realidad sus actos están siendo observados, analizados y transmitidos a la fuente.
"Nuestro cebo automatizado crea un servidor Web fijo que parece y actúa exactamente igual que el original, pero es una trampa", explica Hamlen en la nota de prensa de la universidad. "Los atacantes piensan que están ganando, pero no es así. De ese modo, podemos averiguar lo que están intentando hacer, en lugar de simplemente bloquearlos".
Heartbleed, dado a conocer la semana pasada, afecta a sitios web que utilizan la biblioteca de códigos de computación OpenSSL para cifrar conexiones supuestamente seguras que se utilizan para fines sensibles como banca y compras online, envío y recepción de correos electrónicos, y redes de trabajo remotas.
En 2012, una nueva característica denominada Heartbeat (Latido) se añadió al software principalmente para conexiones lentas a Internet. Heartbeat permite que las conexiones estén abiertas, incluso durante el tiempo de inactividad. Un fallo en la implementación permitió que información confidencial pasara a través de la conexión, de ahí el nombre Heartbleed (Corazón sangrante).
Aunque Heartbleed se encuentra ahora en proceso de arreglarse, las víctimas se enfrentan al reto de no saber quién puede estar ya aprovechándolo para robar información, y qué información pueden estar buscando.
Una solución común para este tipo de problema es crear una trampa, una trampa que atraiga y exponga a los atacantes. Normalmente, esto puede implicar la creación de otro servidor Web en otro lugar.
Soluciones
"Hay todo tipo de soluciones ad hoc en las que la gente trata de confundir al atacante mediante el despliegue de servidores falsos, pero nuestra solución construye la trampa en dentro del servidor real, de modo que los ataques contra el servidor real se pueden detectar y controlar", explica Hamlen. "Nuestra idea se puede desarrollar de forma realmente rápida y fiable a medida que se conozcan nuevas vulnerabilidades."
El algoritmo de Red Herring creado por Hamlen convierte automáticamente un parche - código ampliamente utilizado para arreglar vulnerabilidades como Heartbleed- en un cebo que puede a la vez atrapar al atacante.
"Cuando apareció Heartbleed, se convirtió en el test perfecto de nuestro prototipo", señala Hamlen.
Como el atacante piensa que está robando de datos, se puede rastrear el ataque para averiguar cuál es la información que busca el atacante, cómo funciona su código malicioso y quién está enviándolo.
"En su comunicado inicial, la firma de seguridad Codenomicon instó a los expertos a que empezaran a construir manualmente cebos para Heartbleed", recuerda Hamlen. "Puesto que ya habíamos creado algoritmos para automatizar este proceso, hemos tenido una solución en cuestión de horas."
Actuación inmediata
Cuando las noticias sobre Heartbleed se hicieron públicas el 8 de abril, el doctorando en ingeniería de software Frederico Araujo comenzó a investigar la vulnerabilidad, y ya la había puesto en práctica a las 2:30 de la madrugada del 9 de abril.
"Me sentí muy orgulloso de que [Araujo] tomara la iniciativa", reconoce Hamlen. "Normalmente , yo personalmente habría empezado a trabajar en ello antes, pero había estado poniendo notas toda la noche anterio".
Se estima que pasarán varias semanas hasta que algunas organizaciones puedan protegerse completamente contra Heartbleed. Hasta entonces, Hamlen recomienda no iniciar sesión en ningún servidor sensible a problemas de seguridad. "Evitar introducir su contraseña en los próximos días, y después cámbielas todas", recomienda Hamlen.
En España
El Instituto Nacional de Tecnologías de la Comunicación (Inteco) ha minimizado el impacto del problema en España. Según informa en su blog, los productos de la familia Microsoft no son vulnerables ya que utilizan sus propias implementaciones de SSL. "Y no sólo eso, si no que muchos sistemas utilizan versiones de la librería OpenSSL anteriores y, por tanto, no adolecen del fallo identificado".
Gracias a la colaboración con Red.es han obtenido los siguientes datos: de los dominios .es activos a fecha de 16 de Marzo sólo el 0,42% utilizaban librerías OpenSSL potencialmente vulnerables; y a nivel de direcciones Web (<dominio>.es, o www.<dominio>.es, y las redirecciones existentes de dominios .es) los porcentajes de servicios potencialmente vulnerables son el 0,52%.
Esta sería la información obtenida a partir de las versiones utilizadas en los servicios. Si bien, reconoce Inteco, es posible que alguna de estas webs utilice igualmente una versión de OpenSSL vulnerable aunque el banner del servicio no muestre directamente dicha información. Conscientes de esa limitación, el porcentaje real de webs afectadas sería del 1,38%.
Esta información se obtuvo el martes, 14 de abril (con los dominios .es actualizados a nivel de altas y bajas a fecha de 6 de abril), pero para cuantificar con más exactitud la magnitud de sitios impactados, habría que sumar a esta cifra los sitios web que se parchearon en los días previos desde que conoció la vulnerabilidad, explica el Instituto.
Estos datos se acercan a la dimensión apuntada por otras pruebas realizadas tomando como muestra las estadísticas de Alexa: el 8 de Abril solo el 0,63% de los 10.000 primeros sitios estarían afectados.
Exposición al agujero
El Inteco explica además que el grado de exposición y arco temporal en el cual la información privada protegida por OpenSSL ha estado expuesta "es difícil de determinar". El bug se introdujo en el código de OpenSSL en diciembre de 2011 y ha estado funcionando desde la salida de la actualización 1.0.1 el 14 de marzo de 2012. Esto quiere decir que el bug ha sido "potencialmente explotable" desde esa fecha aunque, al no ser conocido de forma pública, el impacto quedaría limitado a quien pudiera tener conocimiento del fallo y su posible forma de explotación.
El día 7 de Abril de 2014, el bug se hizo público, paralelamente a la publicación del parche que lo corrige. "Desde ese momento, y hasta la aplicación del parche correctivo es donde el riesgo de compromiso de datos ha sido alto", señalan. Por lo tanto, si por ejemplo hace 3 meses que no accedemos a una página web, esa contraseña no habrá estado al alcance de los ciberdelincuentes.
El post minimiza el efecto del agujero de seguridad, aunque reconoce sin embargo que existen muchos otros servicios afectados como móviles, routers domésticos, VPN, etc. para los que está por comprobar el grado de impacto.
Por último, recomienda cambiar las contraseñas cada cierto tiempo, y mantener actualizadas todas las aplicaciones y productos IT.
El Instituto Nacional de Tecnologías de la Comunicación (Inteco) ha minimizado el impacto del problema en España. Según informa en su blog, los productos de la familia Microsoft no son vulnerables ya que utilizan sus propias implementaciones de SSL. "Y no sólo eso, si no que muchos sistemas utilizan versiones de la librería OpenSSL anteriores y, por tanto, no adolecen del fallo identificado".
Gracias a la colaboración con Red.es han obtenido los siguientes datos: de los dominios .es activos a fecha de 16 de Marzo sólo el 0,42% utilizaban librerías OpenSSL potencialmente vulnerables; y a nivel de direcciones Web (<dominio>.es, o www.<dominio>.es, y las redirecciones existentes de dominios .es) los porcentajes de servicios potencialmente vulnerables son el 0,52%.
Esta sería la información obtenida a partir de las versiones utilizadas en los servicios. Si bien, reconoce Inteco, es posible que alguna de estas webs utilice igualmente una versión de OpenSSL vulnerable aunque el banner del servicio no muestre directamente dicha información. Conscientes de esa limitación, el porcentaje real de webs afectadas sería del 1,38%.
Esta información se obtuvo el martes, 14 de abril (con los dominios .es actualizados a nivel de altas y bajas a fecha de 6 de abril), pero para cuantificar con más exactitud la magnitud de sitios impactados, habría que sumar a esta cifra los sitios web que se parchearon en los días previos desde que conoció la vulnerabilidad, explica el Instituto.
Estos datos se acercan a la dimensión apuntada por otras pruebas realizadas tomando como muestra las estadísticas de Alexa: el 8 de Abril solo el 0,63% de los 10.000 primeros sitios estarían afectados.
Exposición al agujero
El Inteco explica además que el grado de exposición y arco temporal en el cual la información privada protegida por OpenSSL ha estado expuesta "es difícil de determinar". El bug se introdujo en el código de OpenSSL en diciembre de 2011 y ha estado funcionando desde la salida de la actualización 1.0.1 el 14 de marzo de 2012. Esto quiere decir que el bug ha sido "potencialmente explotable" desde esa fecha aunque, al no ser conocido de forma pública, el impacto quedaría limitado a quien pudiera tener conocimiento del fallo y su posible forma de explotación.
El día 7 de Abril de 2014, el bug se hizo público, paralelamente a la publicación del parche que lo corrige. "Desde ese momento, y hasta la aplicación del parche correctivo es donde el riesgo de compromiso de datos ha sido alto", señalan. Por lo tanto, si por ejemplo hace 3 meses que no accedemos a una página web, esa contraseña no habrá estado al alcance de los ciberdelincuentes.
El post minimiza el efecto del agujero de seguridad, aunque reconoce sin embargo que existen muchos otros servicios afectados como móviles, routers domésticos, VPN, etc. para los que está por comprobar el grado de impacto.
Por último, recomienda cambiar las contraseñas cada cierto tiempo, y mantener actualizadas todas las aplicaciones y productos IT.