Clickjacking es una técnica reciente que ha sido descrita por varios especialistas de seguridad que han podido tener acceso a los detalles de la vulnerabilidad como TERRORÃ?FICA. Según los datos que se han facilitado, la vulnerabilidad permitiría a un atacante preparar un sitio web malicioso mediante el cual podría realizar un “secuestro de clicks”, es decir, cada click que hagamos en el navegador podriamos estar clickando en otro sitio que no es el que pensamos, con el consiguiente riesgo de ejecución de malware y amenazas similares.

Los detalles de la vulnerabilidad, que afecta a practicamente todos los navegadores, iba a ser presentada en la OWASP AppSec de Nueva York pero parece ser que ha sido cancelada debido al riesgo de dar los detalles antes de que los fabricantes hayan podido desarrollar sus parches, hecho complicado puesto que según han confirmado ellos mismos no es una vulnerabilidad de fácil solución.

Hace ya unos cuantos meses introdujimos brevemente el concepto de entornos virtualizados, si recuerdan la entrada de nuestro compañero José Selvi. La cuestión es que cualquiera que haya tenido la oportunidad de “tocar” un entorno virtualizado ya sabe las ventajas que ofrece esta tecnología. Yo personalmente, aún recuerdo aquella época donde la llamada del operador 24 horas a las 2 de la mañana daba el inicio a una noche de nervios, crisis, backups y reinstalaciones hasta que el servidor volvía a la vida (si lo hacía).

Hoy en día, se pueden tener tranquilamente varios servidores “host” en un clúster albergando decenas de servidores virtuales. Estos servidores virtuales pueden migrarse de un host a otro en caliente, según se necesiten más o menos recursos; si hubiese un error crítico en uno de los hosts, automáticamente se balancearían todos los servidores virtuales de uno a otro. En resumen, llegas por la mañana, sacas un café y mientras lo saboreas te das cuenta que esa misma noche un “host” se ha apagado inesperadamente, pero que todos los servidores virtuales asociados siguen en marcha, esto es vida…

En relación con la vulnerabilidad del DNS que les comentábamos el otro día, les traemos un video de demostración de cómo aprovechar la vulnerabilidad del DNS descubierta recientemente para provocar una intrusión en un sistema, aprovechando los servicios de actualización automática:

Para los que se pierdan un poco, lo que Francisco Amato (Infobyte) hace primero es realizar un ataque Kaminsky para envenenar la cache del DNS utilizado por la víctima para que java.sun.com resuelva a la dirección de su equipo.

Una vez hecho esto, lanza el servicio evilgrade, que emula el servicio de actualización de la máquina virtual de Java, por lo que cuando desde el equipo víctima se pretende realizar la actualización, la solicita al servidor malicioso en lugar de hacerlo al original de Sun, con lo que evilgrade contesta con un paquete de actualización que es ejecutado por la máquina víctima, ejecutando un “Remote Shell” mediante el cual se consigue acceso al equipo.

Como prueba de la intrusión, Amato deja en el escritorio un fichero de texto con la palabra “Owned” para constatar que el equipo ha sufrido una intrusión.

Como curiosidad, y para remarcar la seriedad del problema, el propio creador de la Metasploit Framework ha sufrido un envenanamiento de la web www.google.com debido a que el DNS de su proveedor (AT&T) no estaba parcheado correctamente (como, podría añadir, seguramente todos los de los principales proveedores de Internet, nacionales e internacionales).

Nada más. Sigan temblando :P

Si nos siguen regularmente, sabrán que solemos dejar un par de días, como poco, entre entrada y entrada. Lunes, miércoles y viernes suele ser la periodicidad que personalmente más me gusta. Pero hay ocasiones, como esta, en las que las circunstancias imponen un cambio de planes. Ni que decir tiene que para aquellos que no la leyeron ayer, les recomiendo que le echen primero un vistazo a la entrada anterior, sumamente interesante y un fiel reflejo de la seguridad de las organizaciones y los riegos de carácter práctico que implica la movilidad y la portabilidad, tanto a nivel de datos de carácter personal como de cualquier otro tipo.

Pasemos ahora a eso que ha alterado el orden natural de publicación y hará que este viernes no vaya a haber ninguna entrada. Ya tienen bastante con lo que tienen, hasta la semana que viene.

Un ejemplo de la cantidad de ataques físicos que pueden hacerse contra los sistemas operativos cuando se tiene acceso físico al sistema:

En este caso, los chicos de Offensive-Security han grabado en video (y con música poco discreta) una pequeña demostración mediante la cual reinician un Windows Vista con una Live-CD y copiando el cmd.exe con otro nombres son capaces de lanzarlo sin realizar autenticación de usuario y hacerse con privilegios de SYSTEM (usuario de máximos privilegios del sistema).

Además, como podeis ver en el video de demostración, la prueba fue realizada en aproximadamente 2 minutos; si a eso le sumamos el tiempo de descargar e instalar algún software tipo backdoor, ponle 3 minutos. Con hacer una rápida visita al baño podriamos encontrarnos con nuestro portátil comprometido.

La solución a este problema pasa por el cifrado completo del equipo, bien sea mediante herramientas de pago, bien mediante algunas herramientas OpenSource que realizan esta función (TrueCrypt).

En un próximo post, alguna información sobre cifrado completo del sistema.

Hace poco estuve realizando un curso de Administración y Mantenimiento de Windows Server 2003 para mejorar mis conocimientos sobre este sistema operativo, ya que cuanto más conoces un sistema, más sencillo resulta auditar la seguridad del mismo, que es a lo que me dedico en mi actividad profesional.

Durante la realización de este curso hubo algo que me impactó un poco en relación con el soporte que ofrece Microsoft en sus sistemas para cifrar archivos y carpetas en sistemas de ficheros NTFS. No cabe duda de que en un primer momento puede suponer muy funcional por el hecho de que se cifra la información sin tener que recordar una contraseña adicional, que todo se realiza transparentemente al usuario.

Hace un par de días, leía en el blog de Enrique Dans que al parecer, Microsoft ha proporcionado a más de 2,000 policias en 15 paises un pequeño dispositivo USB llamado COFEE (Computer Online Forensic Evidence Extractor) que contiene unas 150 herramientas, y que conectado a un equipo Windows en funcionamiento permite obtener fácil y rápidamente datos para un análisis forense: datos de actividad en Internet, registros, y contraseñas y datos cifrados con BitLocker, el programa de cifrado de Windows Vista (entiendo que obtendrá datos y contraseñas residentes en memoria volátil sin cifrar, aunque Internautas afirme sin más que “permite a los investigadores acceder a todos los documentos, incluso aunque hayan sido cifrados”).

Esto ha levantado al parecer un pequeño revuelo en Internet, y aunque no es mi estilo, he de afirmar que la ignorancia es muy atrevida. Personalmente, no soy ni amigo íntimo ni enemigo acérrimo de Microsoft; tiene sus cosas buenas, y sus cosas malas, básicamente como cualquier gran empresa; aquello de Don´t be evil pasó a la historia. Pero esta me parece, al contrario de lo que muchos opinan, una buena noticia, por mucho que algunos se hayan llevado las manos a la cabeza y hayan puesto el grito en el cielo invocado las libertades civiles.

¿Se acuerdan de aquella entrada sobre los potenciales problemas de seguridad (y sus consecuencias) de los sistemas SCADA? Aquel texto fue reproducido en Kriptópolis y despertó varias suspicacias por su aparente nivel de alarma; algunas de las quejas apuntaban al típico “no seamos paranoicos”, al “estamos viendo fantasmas”. Por supuesto, crear alarma injustificadamente no era ese el propósito de aquella entrada ni de ninguna otra.

Al parecer, según informa Steve Bellovin en su blog, y de acuerdo a información de la CIA, grupos de hackers han sido los responsables de la pérdida de fluido eléctrico en varias ciudades extranjeras, como parte de una trama dedicada a la extorsión. Me atrevo a decir que Barcelona no es una de ellas; eso sería genial como excusa desde algún punto de vista político, aunque sin duda traería mucha más cola desde otros; una cosa es tener problemas de dimensionamiento, y otra saber que tu red eléctrica está completamente a merced de los delincuentes; a mí al menos esto último me asusta mucho más. Como apunta Bellovin, aunque es obvio que las redes de este tipo de servicios no deberían estar conectadas a Internet, esto no siempre es posible; a veces por requisitos funcionales, y a veces incluso por un exceso innecesario de innovación y/o publicidad. Esta es sólo otra noticia más en relación con sistemas SCADA y cómo los problemas de seguridad tienen consecuencias en la vida real (ver opinión de Bellovin al respecto).

Como ya comentamos en nuestro anterior artículo, vamos a finalizar esta serie de artículos aportando una serie de recomendaciones que pueden ayudarnos a reducir el riesgo de infección por un troyano/virus no documentado y, por lo tanto, no detectable por los sistemas antivirus (en su momento, ya introdujimos otras recomendaciones de carácter más general).

1) No ejecutar nada que “nos pasen”. La manera más fácil de conseguir infectar un equipo es pasarle un “.exe” a un usuario y pedir que lo ejecute. Se puede hacer con más o menos florituras pero el efecto final es el mismo. Pongámoselo difícil a los intrusos, concienciemos a los usuarios (y a muchos técnicos) para que no ejecuten absolutamente nada que no se les proporcione por medios confiables. Si “obligamos” al desarrollador de este tipo de troyanos a integrarlo con la explotación de algún tipo de vulnerabilidad para su propagación, aumentamos enormemente la posibilidad de que nuestros sistemas de detección reconozcan la explotación de dicha vulnerabilidad. Pero para ello es necesario que no puedan conseguir que lo ejecute nadie.

Hace ya algunos meses del primer y segundo artículo de “Bichos et al” en los que comentábamos la posibilidad de desarrollar sin demasiadas complicaciones software malicioso indetectable por los sistemas antivirus. Durante este tiempo, he intentado dedicar tiempo a realizar una pequeña prueba de concepto y a realizar diversas pruebas con diferentes sistemas antivirus para demostrar que es posible burlarlos siguiendo las pautas que se mencionaron en el apartado anterior.

Sin embargo, no llegué a terminar dicha prueba de concepto, puesto que en el proceso de documentación descubrí el troyano RaDa, desarrollado por Raúl Siles, David Pérez y Jorge Ortiz, que demuestra exactamente lo mismo que se pretendía en este artículo, y siguiendo una filosofía muy cercana a la aquí planteada.