¿Pero qué me metes en la DMZ?

23 de junio de 2009 Por

Uno de los ejemplos de cosas chocantes pero muy comunes que nos encontramos en diferentes redes cuando realizamos tests de intrusión es la variopinta cantidad de servicios presentes en las redes DMZ. En su definición más sencilla, una DMZ es una red que se encuentra expuesta a las conexiones entrantes de Internet, y por ello queda recluida en un segmento de red cuyo tráfico saliente se encuentra lo más restringido posible.

Sin embargo, basándose en esta definición, los administradores de sistemas y de redes colocan en la DMZ todo tipo de sistemas sin pensar en el flujo de las comunicaciones y en los posibles ataques, lo cual tiene como consecuencia que desde ella sea posible realizar ataques muy peligrosos. Un ejemplo claro y muy extendido es la colocación de los terminadores de túneles VPN en la DMZ. Cuando un terminador de túneles se situa en la DMZ, la conexión tanto de usuarios como de otras delegaciones sigue un esquema como el siguiente:

03_arpspoofing

Como se puede observar, la información viaja cifrada a través de Internet hasta el terminador del túnel, donde se descifra y se vuelve a enviar a la red corporativa atravesando la DMZ, esta vez sin cifrar, hasta los servicios internos de la organización. Sin embargo, como muchos podéis intuir ya, esta configuración presenta algunos problemas si alguno de los sistemas de la DMZ se ve comprometido. El primero es la posibilidad de realizar un Man-in-the-Middle mediante la técnica de ARP-Spoofing y situar el equipo comprometido en medio de la comunicación entre el cortafuegos y el concentrador VPN, como se puede ver en la siguiente imagen:

03_arpspoofing

Realizando este tipo de ataque, seremos incapaces de descifrar las comunicaciones que vayan desde Internet hacia el concentrador VPN, pero podremos capturar dicha información descifrada en el trayecto desde el concentrador VPN y la red interna, ya que este trayecto lo realiza sin cifrar. De esta manera, seremos capaces de realizar capturas de contraseñas y demás técnicas propias de los ataques típicos en redes LAN. Existen numerosas herramientas gratuitas que realizan este tipo de ataques, como por ejemplo Ettercap en Linux y Cain en Windows, que realizan su propio análisis del tráfico capturado, proporcionando directamente las contraseñas o hashes enviados sin tener que buscarlos manualmente dentro de la captura de red.

Además de realizar estos ataques para capturar la información de conexiones activas, podemos realizar de nuevo un ataque de ARP-Spoofing (que ya no se muestra en la imagen, por claridad) y utilizar direcciones IP del rango de la VPN para intentar encontrar IPs con acceso a servicios de la red interna que no son directamente accesibles desde las direcciones de la DMZ.

02_ruleabuse

Bien es sabido que el filtrado por dirección IP es algo muy poco eficaz en redes LAN, por lo que en este caso el cortafuegos no va a ser capaz de diferenciar si la conexión proviene de direcciones IP de VPN, o si es un equipo de la DMZ que ha suplantado dichas direcciones.

Como solución a este tipo de problemas podemos emplear una segunda DMZ (¿quien dijo que DMZ no hay más que una?) o terminar los túneles en el propio cortafuegos, aunque ello lo expone a la explotación de vulnerabilidades del servicio que podría comprometer toda la red, por lo que se recomienda la primera opción. En general, se recomienda pensar siempre por donde viaje el flujo de tráfico, por donde viajarán las contraseñas y de qué manera lo harán. También es recomendable intentar establecer reglas de filtrado por interfaz del cortafuegos en lugar de por IP, o en caso de realizarse por IP que las diferencias de privilegios de acceso no sean abismales. Si esto no fuera posible, intentar utilizar dos subredes diferentes.

V OWASP Spain Meeting

3 de junio de 2009 Por

owaspEl pasado 15 de Mayo dos miembros del equipo de seguridad lógica de S2 Grupo nos desplazamos a Barcelona para asistir al V OWASP Spain Meeting, donde como siempre pudimos asistir a conferencias de gran interés con ponentes de muy alta calidad:

1. Sintonizar la función de seguridad con el negocio (PDF). Alberto Partida, miembro del Advisory Board de SANS Institute y poseedor de un impresionante curriculum de certificaciones GIAC (entidad de certificación del SANS Institute), nos explicó la manera de compatibilizar los requisitos de seguridad con las necesidades del negocio, y nos explicó algunos trucos para aprender a mostrar la información a los directivos no tecnólogos de tal manera que entiendan a que riesgos se exponen, y nada mejor que ejemplificarlo con ejemplos de incidentes “sonados”. Una charla muy útil para cualquiera que se encuentre en una empresa no tecnológica o que ofrezcan servicios a empresas no tecnológicas.

2. LDAP Injection & Blind LDAP Injection (PDF). Chema Alonso, Consultor de Seguridad en la empresa Informatica64, MVP Seguridad de Microsoft y autor del conocido blog “Un Informático en el Lado del Mal“, nos habló de las particularidades que tiene LDAP Injection con respecto a SQL Injection, que son básicamente el juego de caracteres especiales que se pueden utilizar y el lenguaje, pero que se basa en los mismos principios. Una pena que no pudieramos ver las demostraciones en directo, ya que una caida de su equipo dejó el disco duro inservible.

3. Gestión de Incidentes de Seguridad Web en la Brigada de Investigación Tecnológica (PDF). En esta charla, una de las que la gente mostró más interés con sus preguntas, Jorge Martín, Inspector Jefe del Grupo de Seguridad Lógica del Cuerpo Nacional de Policía, nos explicó como trabajan y a que se dedican en su departamento, una charla muy interesante que despertó la curiosidad de muchos de los asistentes.

4. Extensión de módulos de pruebas de seguridad de la herramienta Webgoat de OWASP (PDF). Daniel Cabezas, de la empresa Ernst & Young, nos mostró diversos módulos que han desarrollado como ampliación de la genial aplicación WebGoat de OWASP para entrenamiento sobre seguridad web, una herramienta imprescindible para cualquier persona que quiera realizar formación en seguridad o que quiera incorporarse al mundo de la seguridad en su vertiente web. Uno de los módulos que creó un poco de confusión consistía en practicar la realización de Buffers Overflow, algo que dada la naturaleza Java de WebGoat despertó las suspicacias de parte del auditorio. No obstante (y eso es una nota para los asistentes al curso que también sean lectores de este blog), cuando Java realiza llamadas a binarios externos para cualquier motivo sí es posible realizar un Buffer Overflow, ya que al realizar la llamada a la función esto sale de máquina virtual java y por tanto de sus restricciones de seguridad, por lo que es posible (y de hecho existen casos documentados) de explotación de vulnerabilidades de Buffer Overflow A TRAVÉS (mejor que “en”) de aplicaciones Java.

En conclusión, los OWASP Spain Meeting son una cita muy recomendable, convirtiéndose en un imprescindible en las conferencias de seguridad en España, algo esperable del excepcional Proyecto OWASP. ¿Nos vemos en la próxima edición? ;-)

Yo, Bicho.

24 de marzo de 2009 Por

Algunos me llaman Kido, otros Disken, aunque puede que el nombre que me haya hecho más popular sea Conficker. En realidad no importa, sólo son nombres que me dan aquellos que me buscan para destruirme. Mi auténtico nombre es algo que, como mi creador, permanece oculto.

Soy un bicho, y esta es mi historia.

Nací hace algunos meses en un garaje de algún lugar del mundo, tras bastantes horas de esfuerzo. Allí mi creador me explicó lo que sería mi misión, y me transmitió el secreto que me permitiría avanzar entre los enemigos. “Busca el 445” me dijo, ese era el camino.

Una vez en la red, me apresuré a buscar ese 445 que me iba a permitir explorar este mundo que se abría ante mi. Desgraciadamente hoy en día los 445 no se exhiben así como así, sino que se encuentran bien guardaditos, al menos de puertas hacia fuera. Tenía que haber otra manera de pasar esas malditas puertas. Tras un par de vueltas a la cabeza y un par de copas en el bar de Blaster (sí, ese que montó tras retirarse) conocí a un bicho que aseguraba conocer el secreto para que Internet Explorer le abriera las puertas. No tenía nada que perder, así que decidí colaborar con él. Nos metimos en un disfraz de JPG y me dijo que me estuviera quieto y callado, y nos apresuramos a reenviarnos a tantos buzones de correo como pudieramos, con la esperanza de que alguno de ellos no se percatara de la trampa hasta que fuera demasiado tarde.

Pasadas unas cuantas horas y visitar algunos usuarios domésticos, alguien nos descarga desde su buzón de GMail, y al abrir la imagen… mi compañero cumple su palabra, me saca del disfraz y me libera para que prosiga con mi misión.

Miro a mi alrededor y efectivamente he pasado una de las puertas, estoy en un equipo edición profesional, y me pregunto como es posible que en estas empresas permitan que los usuarios consulten el correo de GMail o cualquier otro webmail público sin ningún tipo de restricción. Mejor para mí, ya estoy dentro…

Desde aquí puedo ver un montón de 445’s de equipos que tampoco tienen activados los cortafuegos personales. Me pregunto si tiene alguna utilidad que entre equipos de usuario este puerto sea accesible, además de servirme a mi para mis planes, o si la palabra “segmentación” y “filtrado” le dice algo a esta gente. Intento avanzar de equipo a equipo, consiguiéndolo en la mayor parte de ellos; a los usuarios (y a algunos administradores) no les gusta eso de aplicar parches de seguridad, de lo contrario ni siquiera hubiera podido pasar del Internet Explorer. El caso es que tengo un montón de equipos en los que andar a mis anchas.

En muchos de ellos están también aquellos que buscan destruirme, pero no me conocen, no saben cómo soy, y somos demasiados procesos como para que se den cuenta del tipo de acciones que estoy realizando.
Me copio en disco, bien escondido, y también en tantos dispositivos USB como encuentro, así si soy destruido mientras prosigo con mi misión, otro ocupará mi lugar.

Parece que finalmente he sido descubierto. Tanto andar a mis anchas de un lado para otro hace que todo vaya más lento; quizá la próxima vez debería ser más sigiloso. Han venido unos tipos y han capturado a varios de los nuestros, me preocupa que puedan interrogarlos y conseguir averiguar todo lo que saben sobre la misión. Mis peores temores se han hecho realidad, estos tipos de antes han debido avisar a aquellos que quieren destruirnos, porque ahora de repente nos reconocen, y saben cómo y dónde nos escondemos. Intentamos huir pero el 445 ya no me muestra el camino, no tengo escapatoria. Poco a poco, todos los compañeros caen, tras varios días de intensa batalla.

Parece que mi corta vida ha llegado a su fin, pero esto no va a quedar así. Volveré… Y estaré siempre un paso por delante de ti.

Ya no te puedes fiar de nadie…

14 de enero de 2009 Por

El año 2008 fue el año de la “vulnerabilidad crítica que pone en compromiso toda la seguridad de Internet”. Hemos visto varios casos de estos, primero la vulnerabilidad del DNS, luego algunas otras vulnerabilidades en los protocolos de enrutamiento, y alguna otra cosa de menor importancia.

En todos ellos, al final, la solución siempre ha sido la misma: apoyarnos en el uso de certificados digitales (clave pública y privada) para garantizar que estamos conectando donde realmente queremos conectar, y que toda la comunicación entre ambos extremos va a permanecer cifrada, no legible e inalterable por agentes externos a nuestra comunicación.

El gran problema del cifrado de comunicaciones mediante certificados es la distribución de las claves públicas, debemos encontrar alguna manera de poder obtener las claves públicas de nuestros sites web preferidos de tal manera que estos no puedan ser alterados, puesto que en ese caso no existiría ningún impedimento para que un intruso creara un certificado falso y nos lo hiciera llegar al realizar contra nosotros un ataque de Man-in-the-Middle.

Para solucionar este problema entraron en juego las CA (Certification Authority). Las autoridades de certificación son entidades a priori confiables por todo el mundo cuya misión es FIRMAR estos certificados digitales. Podriamos decir que son el equivalente a los Notarios en el “mundo real” (que me perdonen los notarios por la comparación), son entidades confiables que se encargan de “dar Fe” de que la persona que ha firmado un documento es quien dice ser. Las CA funcionan igual, disponen de su propia clave pública y su clave privada, y firman con su clave privada los certificados de las entidades que se lo solicitan.

Por poner un ejemplo para que quede la cosa más clara, pongamos que soy el administrador de www.mibanco.es y que he configurado el acceso por HTTPS con mis claves pública y privada para garantizar la seguridad de mis usuarios. Si no acudo a una CA para que firme mi certificado, los usuarios al conectar a mi web recibirán el mensaje de “este certificado no está firmado por una CA de confianza”, exactamente el mismo mensaje que les daría si un intruso realizara un ataque de Man-in-the-Middle (nos dará un certificado firmado por si mismo). Como no queremos que peligre la seguridad de nuestros usuarios, acudimos a una de las CAs reconocidas, la cual verifica nuestra identidad como administrador del host www.mibanco.es y firma con su clave privada nuestro certificado.

Al poner nuestro nuevo certificado firmado en nuestra web, a partir de ahora nuestros usuarios ya dispondrán de la diferencia entre conectar a la web auténtica (certificado firmado por la CA) y conecter a una web que intenta suplantar a la auténtica (certificado firmado por alguien que no es de confianza).

Como podeis imaginar, de esta manera, el problema de distribución de claves públicas de las webs se reduce al problema de distribución de claves públicas de las CAs, pero este es mucho menos debido a que, evidentemente, hay muchas menos CAs reconocidas que sitios webs en Internet. La solución es, sencillamente, incluir las claves públicas de las CAs más relevantes en el propio navegador web.

Después de todas esta no-breve introducción a las CAs, volvemos al problema que nos ocupa: ¿Nos fiamos de nuestras CAs?

El pasado 30 de Diciembre, en el 25th Chaos Communication Congress (25C3) en Berlín, un grupo internacional de investigadores (principalmente Estadounidenses, Holandeses y Suizos) anunciaron que habían conseguido explotar la conocida debilidad ante colisiones del algoritmo de Hash MD5 para realizar un ataque real contra la infraestructura de PKIs.

Como ya es sabido desde hace algún tiempo, el algoritmo MD5 es susceptible de presentar colisiones, es decir, es posible encontrar dos textos de entrada diferentes que sin embargo produzcan el mismo Hash resultado. Esto supone un verdadero problema para los algurirmos o sistemas que se apoyen en Hash MD5, puesto que para toda operación que se realice con este Hash, las dos entradas serán completamente indistinguibles.

Es el caso de las CAs, existen algunas CAs que a día de hoy siguen utilizando MD5 como Hash cuando firman certificados, ya que no firman el certificado entero por una cuestión de eficiencia, sino que calculan el MD5 de los parámetros más significativos del certificado y luego firman dicho Hash.

Como podeis imaginar, ahí es donde está el problema, ya que debido a la vulnerabilidad del algoritmo MD5, es posible encontrar 2 certificados diferentes cuyo Hash sea idéntico, y por lo tanto, el Hash firmado por la CA será igualmente idéntico. Este problema puede ser usado para usurpar la identidad de un host y realizar ataques Man-in-the-Middle, puesto que nuestro navegador reconocerá el certificado malicioso como firmado por una CA de confianza.

Volviendo al ejemplo de www.mibanco.es ,supongamos que un intruso quiere usurpar la identidad del sitio web, solo tiene que descargar el certificado con la clave pública del host (que se puede descargar desde el propio host) y calcular un certificado (con su clave pública y privada) cuyo contenido tenga como resultado el mismo Hash MD5 que el certificado original. Una vez conseguido esto (algo nada sencillo, los investigadores han tenido que usar un cluster compuesto por 200 Playstation 3 durante 3 días) lo único que hay que hacer es aplicar el Hash firmado original al certificado malicioso, que efectivamente será perfectamente válido, por lo que cuando el usuario acceda al sitio malicioso este aceptará el certificado ya que lo reconocerá como firmado por una CA reconocida.

En realidad, el ataque mostrado por los investigadores es un poco más complicado, ellos lo que hacen es conseguir que una CA reconocida firme el certificado de otra CA propia, una rogueCA, a partir de lo cual cualquier cosa que firmen con esa CA (que es de la propiedad de los atacantes) será automáticamente aceptado por todos los navegadores, lo cual es aún más terrorifico si cabe. Podeis acudir a la web original de los investigadores para más detalles.

Las CAs afectadas por esta vulnerabilidad ya han anunciado que están corrigiendo este problema, pero por el momento, la única medida efectiva con la que nos podemos quedar tranquilos es eliminar los certificados públicos de las CAs que aún utilizan MD5 de nuestro navegador/sistema operativo, ya que si no confiamos en la CA, no vamos a “tragarnos” la suplantación basada en la firma de esa CA.

Para no tener que comprobar uno a uno los certificados, podemos usar esta herramienta aunque sólo funciona en entornos Windows, según se lee en la propia web.

Si es que al final no podremos confiar en nadie…

ClickJacking

29 de septiembre de 2008 Por

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.

Por los datos que se han podido obtener, exploradores “lynx-like” no son vulnerables a este tipo de ataques. Otro de los datos que se ha publicado es que no tiene nada que ver con Javascript, por lo que usar complementos tipo NoScript no será 100% efectivo (aunque por lo que se ha podido averiguar sí que protegerá de algunos vectores de ataque).

A partir de estos datos que se han ido filtrando, varios especialistas en seguridad han “teorizado” sobre la posible vulnerabilidad, localizandola en un problema sobreponiendo un iframe transparente sobre otro que contenga otra web, de tal manera que al clickar en la web que consideramos inofensiva estamos clickando al mismo tiempo en enlaces de la web maliciosa. Hay sitios en los que incluso han creado una pequeña prueba de concepto.

Efectivamente, la solución teorizada parece tener sentido a partir de la información que ha sido facilitada de forma pública, pero no existe ninguna seguridad de que este sea el único vector de ataque.

Por ello, realizamos las siguientes recomendaciones a seguir hasta que se conozcan más detalles sobre la vulnerabilidad:

  • No clickar en enlaces que provengan de correo, MSN, etc, podrían llevarnos a una web maliciosa que parezca una web legítima.
  • Utilizar RUNAS (en Windows ó “su” en Linux) para lanzar un navegador con un usuario con mínimos privilegios en la máquina cuando queramos navegar libremente por páginas no conocidas, y NUNCA confiar en una web legítima que aparezca en este navegador.
  • Accede a las webs relevantes para tí desde los marcadores de tu navegador.
  • Esperar ansiosamente que en fabricante publique el parche que solucione la vulnerabilidad.

Demo de ataque DNS y troyanización

31 de julio de 2008 Por

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:

http://www.infobyte.com.ar/demo/evilgrade.htm

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

Vulnerabilidad en TrueCrypt

21 de julio de 2008 Por

El pasado viernes, Bruce Schneier publicó en su blog un análisis sobre una vulnerabilidad encontrada en la versión 5.1a de Truecrypt, la última en el momento de realizar este análisis (la última es ya la 6).

Según se reflejó en el análisis, Schneier y su equipo de la Universidad de Washington encontraron diversos problemas de seguridad en el uso de sistemas de ficheros ocultos sobre plataformas Windows, que podrían permitir en algunos casos detectar la existencia de dicho sistema o de ficheros contenidos en éste, y en el peor de los casos la recuperación de información.

Según puede leerse en el paper, debido a la naturaleza de determinadas funcionalidades del propio Windows o de aplicaciones habituales en dichos sistemas, es posible producir esta fuga de información. Schneier diferencia 3 tipos de vectores de ataques:

1) A través del sistema operativo. Por ejemplo, la existencia del software Truecrypt deja rastro en el registro de Windows, así como la existencia de las unidades de red en las cuales ha sido montado. Esto pondría de manifiesto la existencia de sistemas de ficheros cifrados pero no aportaría ninguna información extra, salvo que se encontraran en el sistema de ficheros abierto accesos directos que apuntaran a la unidad de la que ya hemos averiguado que se trata de una unidad cifrada. De esta manera, sí que podriamos obtener algo más de información sobre los ficheros que hay el sistema de ficheros cifrado/oculto. Recordemos que el propio sistema operativo guarda estos accesos directos en sus menús de inicio como “últimos ficheros abiertos”, por lo que no es necesario que hayan sido creados de forma manual, sino que el propio sistema los crea con tan solo acceder a alguno.

2) A través de una aplicación primaria. Por ejemplo, el autosalvado de herramientas como Microsoft Word, programas muy habituales en todos los sistemas Windows. El autosalvado de Word hace, “por seguridad”, una copia temporal del fichero con el que estamos trabajando de forma periódica, con el fin de poder recuperar la información en caso de fallo del sistema. Sin embargo, dicha copia es guardada en un directorio temporal del sistema operativo (por ejemplo C:\Users\UserName\AppData\Roaming\Microsoft\Word\), que a no ser que estemos optando por un cifrado completo del disco, estará almacenada sin cifrar. Una vez finalizada la edición del documento, este se encarga de eliminar el temporal del documento, ya que la información ya ha sido almacenada en su ubicación original, pero evidentemente Word no realiza un borrado seguro de los datos contenidos en el documento temporal. Esto significa que realizando una recuperación de ficheros borrados de un disco duro podriamos llegar a recuperar el documento, aunque realmente dicho documento esté presente en un pendrive cifrado del que no disponemos. Como podemos ver, este vector de ataque es uno de los más graves que podemos encontrar, ya que recuperariamos el contenido entero de un fichero cifrado.

3) A través de una aplicación no primaria. Por ejemplo, Google Desktop y la funcionalidad que tiene para poder recuperar estados anteriores de los documentos. Evidentemente, si tenemos instalado Google Desktop en nuestro equipo, éste podría indexar y cachear el contenido de un sistema de ficheros cifrado que tuvieramos montado y sobre el que estuvieramos trabajando. De esta manera, al igual que ocurría con el anterior vector de ataque, podriamos recuperar información completa sobre el contenido cifrado con tan solo acceder a la cache de Google Desktop, sin ni tan siquiera necesidad de recuperar la información borrada.

Haciendo un análisis de los problemas de seguridad mostrados en el paper, algunos de ellos pueden tener solución por parte de los desarrolladores del software, pero dada la naturaleza de los fallos gran parte de ellos me parecen difícilmente corregibles por dichos desarrolladores. Pienso que es más una tarea del administrador del equipo en el que va a ser ejecutado TrueCrypt el realizar una configuración adecuada para que este tipo de problemas no se produzcan.

¿Y qué pasa si ejecutamos nuestro Pendrive cifrado en un equipo sobre el que no tenemos el control? Bueno, incluso si no existiera ninguna vulnerabilidad en el software nunca deberiamos escribir una contraseña en un ordenador no confiable, puesto que la vulneración del cifrado sería tan inmediata como instalar un KeyLogger en el equipo que capture nuestra contraseña de cifrado en el momento de teclearla.

¿Recomendaciones?

  • Si hablamos de un equipo que tiene cifrada una unidad: mi recomendación es un cifrado completo del disco, así se evitan problemas con ficheros temporales y cachés, puesto que ellas estarán a su vez cifradas por estar contenidas en el disco.
  • Si hablamos de un dispositivo tipo pendrive que se mueve de aquí para allá sin control del equipo en el que se ejecuta: intentar no tener toda la información en una sola “unidad”, sino separada por cliente, proveedores, proyectos o como mejor se adapte a cada uno, utilizando contraseñas diferentes para cada unidad. De esta manera si en un sitio se pincha para ver la información del cliente X y un intruso captura la contraseña o accede a los datos, será siempre a datos a los que realmente ya debería tener acceso, ya que por eso se ha tecleado la contraseña.
  • Solución super-paranoica: mi pendrive es por un lado un LiveCD con Linux y por otro lado tiene una unidad TrueCrypt. Si necesito acceder a la información y no me fio del entorno, puedo arrancar desde USB con el Pendrive, y de esta manera al montar la unidad cifrada tengo la seguridad de que estoy arrancando un sistema operativo confiable; a partir de ahí copio la información, bien al disco del equipo local, bien a otro equipo, por medio de comunicaciones cifradas.

Seguiremos informando cuando TrueCrypt de una respuesta a este paper.

Crítico: Vulnerabilidad en protocolo DNS

9 de julio de 2008 Por

Hace apenas algunas horas acaba de publicarse (http://www.kb.cert.org/vuls/id/800113) una vulnerabilidad en el diseño del protocolo DNS y en la implementación que de ella hacen muchos fabricantes que podría permitir a un atacante realizar envenenamiento de Cache DNS.

Según se puede leer en el reporte de la vulnerabilidad, el problema radica (entre otros no especificados) en el campo ID que sirve para identificar que la respuesta recibida es efectivamente una contestación a la petición DNS realizada. Dicho campo, según el protocolo, tiene 16 bits de longitud, lo cual se estima insuficiente para poder garantizar la seguridad. Además, la implementación que realizan la gran mayoría de desarrolladores no realiza una correcta “randomización” del puerto de origen de la petición, por lo que dado la facilidad de realizar ataques de Spoofing de tráfico UDP, la predictibilidad del puerto origen y el corto espacio de posibles IDs hace posible que un atacante remoto pudiera generar multiples paquetes para todos los posibles IDs con tan solo ser capaces de predecir el puerto de origen de la petición y de esta manera realizar un envenenamiento de la Caché del servidor DNS atacado.

Imagínense el impacto de algo así, bajo este ataque, no tenemos ninguna certeza de que ninguna de las webs que visitamos es la que dice ser, ni siquiera otros servicios tan críticos como actualizaciones de seguridad.

Por suerte todos utilizamos protocolos cifrados para nuestras comunicaciones y comprobamos los certificados SSL/fingerprint cuidadosamente para verificar que el sitio donde queremos acceder es realmente donde estamos accediendo, ¿verdad? :P

Según comenta el propio descubridor de la vulnerabilidad, Dan Kaminsky (http://www.doxpara.com/), que ha incorporado una herramienta en su web para que podamos verificar si somos vulnerables o no, el descubrimiento de la vulnerabilidad se ha mentenido en secreto por algún tiempo y ha sido coordinada con los principales desarrolladores de software de servicios DNS para que tuvieran preparadas las pertinentes actualizaciones de seguridad antes de dar a conocer al mundo la vulnerabilidad. Consecuencia de ello es que los principales fabricantes ya han publicado, casi simultáneamente con la publicación de la vulnerabilidad, los parches pertinentes. Entre ellos, podemos destacar el advisory de BIND (el servidor DNS más usado en Internet) y el de Microsoft (no por ser el segundo más usado, sino por relevancia de la marca).

Se recomienda a todos los lectores que verifiquen si su servidor DNS es vulnerable a este tipo de ataques (casi con toda seguridad lo será) y que apliquen los parches de seguridad a la mayor brevedad posible, ya que aunque se ha comentado que la ingeniería inversa de los parches publicados es realmente complicada, no es imposible, por lo que se espera la aparición en breve de herramientas automáticas que aprovechen estas vulnerabilidades, incluidas aquellas no documentadas en el advisory
oficial.

Se espera también que Dan Kaminsky de más detalles sobre las vulnerabilidades encontradas y los vectores de ataque en la próxima Black Hack USA que tendrá lugar este mes de agosto.

Saludos y a parchear.

Vista Hacked en 2 minutos

28 de mayo de 2008 Por

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

Vista Hack

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.

¿Cifrado = Privado?

23 de mayo de 2008 Por

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.

captura.jpgEl problema con las cosas “excesivamente funcionales y transparentes” es que en la mayor parte de los casos implican un decremento en su seguridad. Por poner un ejemplo, algunas de las preguntas que me surgieron al explicarme este método de cifrado:

¿Que pasa si el usuario olvida la clave y es necesario resetearsela? Se pierde la información cifrada sin posibilidad de recuperación. Al haber sido cifrada utilizando la contraseña de usuario.

En realidad no se perdería, lo cual aunque en principio puede parecer algo bueno, comprobareis que el mecanismo empleado vulnera en cierta medida la privacidad de los usuarios de este sistemas de cifrado integrado.

Cuando configuras un fichero o carpeta como cifrado con EFS, además del usuario que lo crea que evidentemente tiene acceso, puedes definir un listado de usuarios que también tendrán acceso a dicho fichero. Dichos usuarios son perfectamente gestionables por el usuario propietario del fichero. El problema radica en lo que podemos apreciar en esa misma ventana un poco más abajo. Existe un “rol” denominado “Agente de recuperación de datos” (que por defecto es el usuario Administrador y que el usuario no puede cambiar) que es capaz de acceder a cualquier información cifrada del sistema.

Como podeis imaginar, el hecho de que un usuario Administrador del sistema pueda acceder a toda esta información cifrada vulnera completamente la privacidad que se pretende alcanzar con el uso de herramientas criptográficas.

Todo esto me ha llevado a la conclusión que el sistema de cifrado EFS proporcionado por Microsoft en sus sistemas operativos no satisface los requisitos mínimos de seguridad, por lo que yo personalmente recomiendo utilizar software de terceros aunque ello implique tener que recordar una contraseña más o llevar con nosotros un token o certificado digital, nuestra privacidad vale esa molestia y mucho más.

Saludos.