Google Chrome también tiene “sus cosas”

Si no conocen Google Chrome, es que han estado metidos debajo de una piedra estos últimos días. Para que se den cuenta de la relevancia del asunto, hasta los telediarios dieron la noticia sin que en ella mediase ninguna alusión a los innumerables peligros de Internet (crimen organizado, pederastia, sectas peligrosas, adicción al MSN, etc.). También estarán al tanto, si son habituales de esta página, de nuestra particular paranoia en torno a todo lo que suene a Google. Admito que quizá en algunas ocasiones (pocas) seamos algo desconfiados, pero en cuestiones de privacidad, más vale que sobre que no que falte. Y para qué negarlo, Google no deja de darnos razones para no quitarle la cruz, y luego verán porqué lo digo.

Antes de nada, he de decir que he probado Chrome, y es un buen producto. Tiene sus cosas, lógicas dado el estado “primitivo” de la aplicación, pero lo cierto es que para ser una primera versión beta “a perpetuidad”, como todo lo que Google lanza, tiene cosas muy buenas. Muy buenas, de verdad, sin ironías. Entre otras cosas, es un navegador impresionantemente rápido, sencillo, y lo que más me ha gustado, que aisla las pestañas unas de otras a modo de procesos independientes, de modo que el “cuelgue” de una de ellas no repercute en el resto de pestañas; algo que no entiendo como no se le ocurrió a nadie antes. No, no tengo intención de analizar a fondo la aplicación, ni de entrar en la discusión —muy interesante, sin duda alguna— sobre qué busca Google con este producto a nivel de mercado o qué debería pensar Microsoft de todo esto; eso lo dejo para otros foros. En definitiva, he de admitir que, como casi todo lo que hace Google, es un buen producto con un potencial impresionante.

Desgraciadamente, como (¿casi?) todo lo que hace Google, es un producto que también tiene sus problemas ajenos a cuestiones técnicas. El primero, ya subsanado, fue un “error”, “descuido”, o como quieran llamarlo, en las condiciones de uso (EULA, End User License Agreement), por el que Google adquiría de manera no exclusiva los derechos de uso de cualquier contenido transmitido a través de su navegador; afortunadamente, este sinsentido fue subsanado horas más tarde.

Por otra parte, mucho más interesante, algo que no es un error y sin duda Google no tiene intención de modificar, tenemos los habituales problemas de privacidad, algo lógico dado que el negocio de Google está fuertemente basado en la gestión de la información que almacena de sus usuarios. Lógico pero no necesariamente admisible. En este caso, tal y como reportó CNET hace unos días, se ha sabido que la barra de direcciones del navegador envía a Google los caracteres que tecleas aún cuando no presiones Enter; dicha herramienta, denominada Omnibox, está pensada con la finalidad de proponer al usuario sugerencias procedentes del buscador a medida que éste va tecleando en la barra. Si todo quedase ahí, podríamos considerarlo un mal menor (aunque aún de manera anónima, seguiría siendo una funcionalidad intrusiva), pero lo peor es que el buscador tiene pensado almacenar un 2% de la información que recibe, junto con la IP de la que procede, según comunicó un portavoz de Google a CNET.

Por fortuna, Kriptópolis aporta varias formas de modificar este comportamiento, que empiezan por (a) modificar el buscador por defecto que “propone” las sugerencias o (b) eliminar esta funcionalidad, pasando por (c) utilizar el modo “incógnito” del Google Chrome, y acabando en la elección más radical que es utilizar otro navegador. El problema en este caso es que, aunque exista la posibilidad de desactivar dicha funcionalidad, ésta viene activada por defecto, y la mayor parte de los usuarios no son conscientes de ella ni Google se ha preocupado de decir las cosas lo suficientemente claras. Acabaré diciendo que Google Chrome es un buen producto, incluso un muy buen producto, pero que como casi todo lo que lanza Google últimamente, vuelve a traicionar, esta vez por poco, sí, aquel ya obsoleto lema del buscador que decía “Don’t be evil”.

(Matt Cutts da algunos detalles de cuándo Chrome habla con Google y cuándo no, por si desean echarle un vistazo).

a) Con el cursor sobre la barra de navegación, botón derecho, “Editar motores de búsqueda”, seleccionar uno que no sea Google y pinchar en “Establecer como predeterminado”.
b) Con el cursor sobre la barra de navegación, botón derecho, “Editar motores de búsqueda”, y desactivar la opción “Utiliza un servicio de sugerencias para completar…” que aparece al final del cuadro de diálogo.
c) Ctrl + Shift + N.

Adeona

Últimamente parece que estemos un poco obsesionados con la seguridad alrededor de los portátiles. Han habido varios posts al respecto. Hemos hablado del auge de su protagonismo como activos a proteger, por el aumento de la extensión de su uso, no sólo por parte de gerentes y ejecutivos —que transportan en ellos información muy confidencial de sus organizaciones— sino también por técnicos y comerciales. También hemos hablado de medidas de seguridad proactivas que se les pueden aplicar: cifrado del disco, protección de acceso, etc.

La cuestión es que es un hecho que los portátiles son activos muy “golosos” para los amigos de lo ajeno, ya sea por el valor económico del dispositivo como tal o por el valor de la información que en él reside (en la mayoría de los casos, infinitamente superior). Buceando por la red me he encontrado con otra medida de seguridad pensada para estos dispositivos (aunque puede ser aplicada de igual manera a ordenadores de sobremesa o servidores), en este caso de tipo reactivo. Quizás alguno de ustedes la conozcan. Se trata de Adeona, una solución open source desarrollada por miembros de la Universidad de Washington en colaboración con participantes de la Universidad de California San Diego y la Universidad de California Davis. Esta herramienta permite trazar la localización de un portátil perdido o robado con la simple instalación de un pequeño software cliente (e incluso fotografiar al ladrón, en ciertos casos), y sus autores están trabajando para llevar esta herramienta al iPhone, “teléfono” que no dudo que tiene su buena tasa de robos.

Entre otras, la herramienta tiene algunas características que la hacen interesante, como que no precisa de un servicio centralizado y propietario para la localización del dispositivo, y preserva la privacidad del propietario del portátil, pues sólo éste puede revisar las pistas de localización del portátil, que permanecen cifradas. Y es open source y gratuita, lo que asegura en gran medida que Adeona no hace cosas que “no debe”.

Desgraciadamente, hoy por hoy, la versión disponible de Adeona no es a prueba de balas. Es inútil si la persona que sustrae el dispositivo lo destruye o desensambla, si lo formatea, le impide conectarse a Internet, o incluso si desinstala el agente. Pero contra aquellos “sujetos” poco duchos en informática que lo roban con el único propósito de venderlo bajo mano, sin más complicaciones, o para aquellos que deciden “fisgonear” por el contenido del dispositivo una vez robado, puede ser altamente efectivo. Les recomiendo que le peguen un vistazo.

Estamos de vuelta…

Como pueden imaginar, se me han acabado las vacaciones, durante las que he intentado mantenerme lo más alejado posible de cualquier dispositivo electrónico, por aquello de desconectar. Podría decirse que lo he conseguido, si dejamos de lado el DVD y la televisión, lo que hará presumiblemente mi vuelta a la rutina laboral un poquito más dura. A pesar de ello, las evidencias me obligan a asumir mi condición profesional y admitir que incluso en vacaciones, la seguridad, la LOPD, los teclados, ratones y demás artilugios y conceptos demoníacos me persiguen, y está demostrado que me alcanzan.

Verán el porqué de lo que les decía. Andaba yo en la piscina de mi pueblo, en bañador, tirado a la bartola, haciendo el zángano de la mejor forma que sé (algo que he perfeccionado hasta límites inhumanos), cuando hablando de esto y aquello, un buen amigo mío me comenta que en su empresa han despedido a un compañero, llamémosle “X”, por fisgonear en los sistemas de la compañía. Como disclaimer previo, diré que únicamente conozco el tema a grandes rasgos (imagínense una conversación a las cuatro de la tarde al borde de la piscina) y ningún detalle, por lo que no esperen conclusiones o reflexiones de peso, ni tampoco tomen la historia en un 100% al pie de la letra.

Podemos empezar diciendo que la empresa de mi amigo tiene al parecer una política bastante restrictiva en el acceso a Internet, limitado a determinadas personas y en determinadas circunstancias. Sin embargo, era casi de dominio público que X disponía de acceso a Internet de estrangis, aunque todo quedaba ahí; incluso parece ser que el responsable de informática conocía este hecho, y era algo aceptado. Un buen día, X tiene un problema con su equipo, y se ve obligado a remitirselo al área de informática, quien constata que no sólo disponía de acceso no autorizado a Internet, sino que además, tenía una recopilación de información corporativa a la que en teoría no tenía acceso; datos de facturación, rentabilidad, ofertas, esto y lo otro. Posteriores indagaciones mostraron que X disponía de hace tiempo de la contraseña de administración de los sistemas, y que todo indica que se había dedicado a bucear por los equipos corporativos y de sus compañeros, copiando información que a priori parecía interesante. Obviamente, X fue despedido tras conocerse todo esto. Una típica historia de terror en toda regla, de esas que nunca pasan.

Como decía, no voy a hacer ningún tipo de reflexión sobre cómo había accedido a la contraseña de administración de los sistemas, sobre si existían o no políticas formales de uso de equipos corporativos o de clasificación de la información, ni sobre si se realizaba un registro de accesos a los sistemas críticos. No conozco los sistemas, ni las personas implicadas, ni el entorno, así que comprendan que me abstenga de emitir valoraciones. Lo que me sorprendió tanto a mí como a mi amigo fue la reacción de parte de sus compañeros de trabajo, que en una frase, puede definirse como “No es para tanto”. Entiendo que las circunstancias personales de X, cuando X es alguien con quien puedes haber tenido una amistad, pueden influir en tu objetividad, pero el caso, y estoy seguro de que estarán de acuerdo conmigo, es que sí es para tanto. Es incluso, y según los grandes rasgos que les he dado, un delito penal.

Por último, me llena de satisfacción y orgullo, que diría aquél, ver que Paloma Llaneza nos menta en su blog con ocasión del Blog Day ’08, el pasado 31 de agosto. A mi no me miren, que era domingo y además apuraba mis últimos minutos de libertad tirado en un sofá. Nada más de momento; seguimos calentando motores. Manténganse a la escucha.

¡Vacaciones!

Estimados lectores,

Como cualquier blog que se precie y como (casi) todo hijo de vecino, nosotros también nos largamos de vacaciones. Eso significa, entre otras cosas, que no habrá nada nuevo por estos lares hasta la primera semana de septiembre, cuando nos encontremos en plena depresión postvacacional, por lo que si nos siguen regularmente pueden ahorrarse la visita hasta entonces. El año pasado no cogimos vacaciones, pero este año toca; el sprint final de julio ha sido especialmente intenso (en realidad, para la mayoría de nosotros todavía no ha acabado), y septiembre promete mantener el mismo nivel. Más allá de que este blog sea colectivo y corporativo, lo admito: necesito unas vacaciones.

Puesto que sé que a todos ustedes les encanta seguir trabajando en vacaciones, y como Sandra Bullock en La Red, llevarse el portátil a la playa (hay pocas cosas menos sensatas, si uno se estima su portátil), les he traído un par de libros a raíz de una entrada en en el blog de Félix Haro. En estos momentos estoy leyendo uno de ellos y está resultando muy interesante; va en la línea de lo que ya hemos comentado alguna vez por aquí: ten cuidado con lo que dice Google de ti, o tú le dices, porque Google no olvida y no sabes quién puede llamar a su puerta dentro de unos años preguntando por ti.

Afortunadamente, no tendrán —si no quieren— que gastarse un euro, ya que está disponible en Internet gratis por la patilla, en la página personal de su autor Daniel J. Solove. El título es The future of reputation: gossip, rumor and privacy on the internet. Probablemente prefieran empezar por el anterior libro de este mismo autor, también disponible a través de su página web, The digital person. Technology and privacy in the information age, pero les dejo eso a su elección. Claro que ambos están en inglés, pero es inglés académico y eso no debería ser un problema.

Yo les recomendaría que se alejasen de cualquier dispositivo electrónico durante un tiempo, que es básicamente lo que tengo intención de hacer yo a partir de este viernes, pero allá ustedes. Al menos, para aquellos que no tienen vacaciones, espero que esos libros les ayuden a sobrevivir a este agosto.

Nada más. Como diría el bueno de Pedro Erquicia, les espero en septiembre, para contarles en profundidad las cosas que pasan a lectores como usted. Buenos días y felices vacaciones.

* * *

Me apunta José Selvi antes de colgar el cartel de “Cerrado por vacaciones” que dentro de un par de días tiene lugar la final del “Capture the Flag” de DEFCON, en la que participa el equipo español “Pandas with gambas” (su foto “de familia”), en la que que intentarán arrebatar el trofeo a los campeones de los dos últimos años, los veteranos 1@stPlace (su foto “de familia”, algo más seria).

Mucha suerte!

No tan anónimos

Les confieso que en un primer momento tuve ciertas reticencias y dudas de colgar lo que les cuento a continuación, por si alguien pudiera considerarlo “incitación al delito”. Por supuesto, ese no es en ningún caso el propósito de la entrada, sino el de mostrar qué es posible hacer con unos pocos datos de carácter personal hoy en día —de esos que cualquiera de nosotros proporciona alegremente a cualquiera—, por lo que tras un par de consultas previas he decidido publicarlo. Obviamente, falta decir que lo que se cuenta en esta historia es completamente ficticio, fruto de mi imaginación, y cualquier parecido con la realidad es pura coincidencia. Sirva esto como disclaimer previo, y pasemos a la entrada.

Hace cosa de un par de semanas, a las 05:51 de la mañana, sonó mi móvil, que como siempre, había dejado encendido —mala costumbre— en la mesita de noche; con el sobresalto habitual de una llamada en horas intempestivas, contesté al teléfono sin saber quién me llamaba (tenía el número pero no estaba en mi agenda) y, para mi sorpresa, parece ser que mi interlocutor se había equivocado y, sin decir nada, ni un mísero “lo siento”, decidió colgar. A mí estas faltas de educación siempre me han molestado, pero sobre todo, me resulta incomprensible que alguien te llame a esa hora, se equivoque, y no tenga el valor de pedir disculpas ni decir nada, simplemente se limite a colgar.

Si esto se hubiera producido hace unos años, cuando no había móviles y los fijos de la época no disponían de un bonito display electrónico donde aparece el número llamante, simplemente me habría fastidiado, lo habría olvidado en unos minutos, y poco más. Pero en estos días a mi interlocutor (por llamarle de alguna forma) se le olvidó un pequeño detalle: tenía su teléfono móvil, o al menos el teléfono desde el que me había llamado; así que me propuse saber quién sería esta persona.

¿Qué hacer cuando dispones únicamente de un número de teléfono móvil, sin más datos? Puedes poner un anuncio en coches estacionados en diferentes zonas de la ciudad, pegado al cristal, con un precio atractivo y ese número de teléfono. Pero eso no supone ningún reto; sí que puede ser un reto tratar de conseguir la información de esa persona; un poco de ingeniería social nunca viene mal, y por suerte o desgracia, en este país si oímos la palabra “GRATIS” damos hasta nuestra partida de nacimiento…

A partir del prefijo móvil se puede determinar con un alto nivel de probabilidad la operadora de comunicaciones a la que pertenece, con lo que una promoción de dicha operadora siempre es una buena excusa; si ha habido una migración, pues la promoción se convierte automáticamente en una oportunidad para antiguos clientes. El resumen podría ser:

— “Le llamamos de XXXX para ofrecerle, una vez cotejados sus datos, una promoción de llamadas a 0 céntimos, GRATIS, durante todo el mes de agosto, sin letra pequeña”.
— Ah, dígame.
— ¿Es usted don Luis López, de Salamanca?
— No, me parece que se ha equivocado.
— Vaya, lo siento, entonces no puede acceder a la promoción… en cualquier caso, es usted cliente de XXXX, ¿verdad?
— Sí, sí, dígame…
— ¿Dispone usted de correo electrónico?
— Claro.
— Si me lo facilita, le enviaremos un e-mail y, simplemente por responder al mismo y rellenar nuestro cuestionario, tendrá acceso exclusivo a esta promoción.
— Claro, mi correo es yyyy@hotmail.com.
— En breve recibirá el correo; una vez obtenida su respuesta, en el plazo de una semana nos pondremos en contacto con usted para confirmarle el acceso y tendrá llamadas gratis durante todo el mes de agosto.
— Ah, muchas gracias, muchas gracias…

A partir de aquí, no hay más que enviar un correo al individuo en cuestión desde una dirección que parezca creíble; aunque para el 99% del personal es creíble cualquier dirección de Hotmail, mucho más elaborado es utilizar algo del tipo “registro@XXXXX.dyndns.org”, donde XXXX es obviamente el nombre de la operadora. En ese correo, con logos oficiales y formalismos que le den credibilidad, le pedimos amablemente su nombre, código postal —por aquello de la estadística— y el número de teléfono que quiere asociar a la promoción (aunque ya lo sepamos, nunca está de más). Et voilà, tenemos enseguida cómo se llama la persona y dónde vive (a lo de pedir la dirección postal, aparte de que no nos aporta nada, la gente suele ser más reacia, pero el código postal lo facilitamos sin problemas).

Con estos datos —nombre y apellidos, e-mail, teléfono y código postal— hemos recorrido buena parte del camino; depende de lo que queramos hacer con la información, esto es más que suficiente: desde poner anuncios de compraventa en prensa gratuita de la zona —hablaremos un día de la seguridad y autenticación en estos casos—, hasta técnicas más elaboradas; he aquí unos ejemplos:

— “Promoción” para averiguar si tiene hijos entre 10 y 20 años, y si es así, cualquier tarde de octubre, cuando su hijo esté en el colegio, volvemos a contactar con él para comunicarle que su hijo está retenido en el centro comercial X —cercano al domicilio— por haber sido sorprendido en pleno hurto, y le rogamos que venga a recogerlo. Ni hace falta saber el nombre del niño.
— “Promoción” para averiguar si su coche tiene más de cinco años y ofrecerle, en un concesionario de la zona que se ha adscrito a la promoción, una ganga. Debe pasar esa misma semana por dicho concesionario.
— Invitación a un Madrid-Barça, o Sevilla-Bilbao —dependiendo del código postal—, para él y dos acompañantes en zona VIP, completamente gratis, presentando su DNI en taquilla.
— Cualquier otra cosa que, como hemos dicho, incluya la palabra “GRATIS”.

Se me ocurren muchas más, pero ya se pasan de ser simples bromas a entrar en temas personales delicados, y después de todo, sólo fue una llamada a una hora intempestiva, y un poco de mala educación. Sirva esta entrada como reflejo didáctico, y ténganla en cuenta cuando se equivoquen de número una noche a las tantas de la madrugada y por supuesto, cuando alguien tenga la bondad de ofrecerles algo gratis.

Demo de ataque DNS y troyanización

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

“Eso no va conmigo”

Siempre que abordarmos un proyecto de auditoría de ISO 27002 o la implantación de un SGSI nos sigue sorprendiendo la actitud de ciertos directivos, que presionados por la urgencia del día a día, y por el seguimiento de indicadores puramente productivos, digamos que no contemplan (por no decir que desestiman o dejan de lado, que queda más feo) los riesgos a los que sus procesos de negocio se encuentran expuestos desde el punto de vista de la seguridad. Para ser justos, también nos encontramos con gerencias que están preocupadas por estos aspectos, o que ven por ejemplo —como siempre recalcamos en este tipo de proyectos— la viabilidad de trasladar las medidas de seguridad que se implantan para tratar datos de carácter personal al resto de la información que tratan sus organizaciones, y que a fin de cuentas es la que de verdad es importante para ellos desde el punto de vista del negocio. Pero insisto, todavía son “los menos”.

Si me permiten la expresión, a veces “se me pone la carne de gallina” cuando detectamos las barbaridades que en algunos casos se cometen gestionando esta información, y estoy hablando de grandes organizaciones, no de PYMES: envíos de documentos confidenciales a través de cuentas de webmail (Hotmail, Yahoo!, Gmail, etc.) porque el servidor de correo corporativo tiene una limitación en los ficheros anexados, redes corporativas —con acceso por parte de proveedores externos— sin segmentar, inexistencia de acuerdos de confidencialidad firmados con terceros, etc.

Incluso en el ámbito de auditorías de seguridad lógica comprobamos que sí, efectivamente, la empresa dispone de un IDS, pero que simplemente está “dejado caer”, sin que se haya configurado adecuadamente, o sin que nadie esté dando aunque sea un vistazo a las alertas que se puedan estar generando. O que cuando lanzamos las auditorías automáticas de vulnerabilidades, nadie (ya sea el departamento de sistemas o la empresa externa que dice estar gestionando la seguridad de la red auditada) detecta el aluvión de escaneos de puertos. Y no voy a entrar en el apartado de las medidas de seguridad de los CPDs, en la ausencia de control en el acceso a la información en soporte papel en salas de archivo de uso compartido, o en el espeluznante capítulo de la información confidencial en equipos portátiles, que tan acertadamente describió nuestro compañero Alberto Rivas.

Parece ser que esos riesgos no van con ellos; aparentan creer (por los hechos los conocerás, que decía aquél) que la información de su negocio no le interesa a nadie. Por desgracia, las cosas no son exactamente así, y siempre hay gente interesada en tu información.

Y esta es una PYME.

Vulnerabilidad en DNS “disclosed”

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.

Empecemos con una pequeña introducción. Hace unas semanas, tal y como avisamos aquí mismo, Dan Kaminsky informaba de un peligroso problema de seguridad en el servicio de DNS; no creo que nadie necesite que le explique para qué sirve el DNS, ni de cuál es su criticidad en el marco de Internet. El problema era de una importancia tal que dió de plazo aproximadamente un mes para desvelar los detalles técnicos del problema, hasta el 6 de agosto, en la conferencia que daría en Black Hat, tiempo que los proveedores deberían aprovechar para parchear sus sistemas. Cosa que la mayoría de grandes proveedores no han hecho, todo sea dicho.

Hace un par de días, Halvar Flake se puso a especular sobre el problema. Y parece que se acercó bastante. Ese mismo día, la gente de Matasano publicó en su blog una interesante entrada en su blog, dando muchos detalles sobre la vulnerabilidad, y violando —al parecer— el acuerdo que habían alcanzado con Dan Kaminsky. Aunque eliminaron la entrada y pidieron disculpas, Internet no olvida, y su entrada se encuentra tanto en Google, como en otros blogs, en Slashdot, PC World ya ha hablado de ello y vayan ustedes a saber dónde o quién más. En otras palabras, el problema es casi oficialmente de carácter público y es probable (aunque no seguro) que Dan Kaminsky aclare finalmente los detalles.

La explicación que les voy a dar no pretende ser técnicamente profunda, pero espero que les sea suficiente; por supuesto, si detectan algún error, hagánmelo saber. Seguiré básicamente, pero no al pie de la letra, los pasos que Matasano describía en su entrada. Como conceptos básicos, deben conocer qué es un servidor DNS, y la estructura recursiva que el protocolo tiene. Si el servidor A no conoce la dirección IP para www.victim.com, preguntará a uno de mayor nivel, y así sucesivamente. Veamos ahora dos tipos de ataques clásicos sobre el DNS.

a) DNS Forgery. Este ataque se basa en hacer creer al servidor DNS que www.victim.com no tiene la IP 1.2.3.4, que es la legítima, sino que es 4.3.2.1, que en realidad apunta a www.evil.com. De este modo, cuando alguien le pregunte al servidor DNS por la IP de www.victim.com, éste devolverá la IP de www.evil.com. Imaginen ahora que www.victim.com es la web de un banco y www.evil.com reproduce fielmente su interfaz. Seguro que ven el problema.

La idea es la siguiente. Cuando Pepe pide la dirección de www.victim.com, si su servidor DNS Pepe_DNS no tiene su dirección IP, preguntará a Alguien_DNS por dicha IP, y así recursivamente. Esa solicitud lleva asociado un query id (QID), que sirve para autenticar la respuesta. La intención del ataque es devolverle a Pepe_DNS la IP de www.evil.com como si fuese la de www.victim.com, antes de que el servidor DNS legítimo lo haga, con la gracia de que además, Pepe_DNS guardará esa dirección IP en caché durante un tiempo, por lo que muchas de las siguientes consultas devolverán la IP de www.evil.com.

Claro que para hacer eso, necesito saber el QID de la petición, o la respuesta será descartada. Antes, cuando los QIDs eran consecutivos, algo así podía resultar sencillo. Ahora los QIDs se generan aleatoriamente (¡vaya!). Imaginen ahora que puedo hacer que Pepe_DNS pida no una, sino 1000 veces la IP de www.victim.com; hay 1000 veces más QIDs, y sólo tengo que adivinar uno de ellos. Imaginemos además que empiezo a preguntarle a Pepe_DNS como resolver direcciones que controlo; podré acceder a los QIDs y eventualmente, con suerte y algo de tiempo, quizá consiga predecir la semilla de generación de los QIDs.

La solución básica para eso es lo que hace DJBDNS, que es combinar el QID con el puerto de petición del cliente DNS, con lo que aumentamos la seguridad de 16 bits a 32 bits, haciendo la cuestión de adivinar sensiblemente más complicada.

b) DNS RRset poisoning. Este ataque está basado en la estructura de los paquetes de respuesta del DNS. La idea es que en la respuesta que recibo del servidor, además de la información solicitada, existe una parte del paquete que puede contener información adicional “de interés”. Por ejemplo, si yo pregunto por www.evil.com, Pepe_DNS puede contestarme con la IP de www.evil.com y en el campo de “información de interés” darme la IP de www.victim.com, que por supuesto no es la IP legítima.

Claro que alguien se preguntará porqué podría alguien pedir la IP de www.evil.com. Imaginen que acceden a un blog, que tiene una imagen alojada en www.evil.com. Con sólo eso, ya estamos intentando resolver www.evil.com, y el resto ya lo saben. La solución a esto es muy sencilla, al menos en el nivel teórico: no hagas caso del campo “informacion de interés”, excepto si contiene información sobre el dominio sobre el que he preguntado; es decir, que si pregunto por www.evil.com, puede interesarme mail.evil.com, pero no mail.victim.com.

c) Pasemos finalmente al ataque de Dan Kaminsky, que está basado en una combinación de los dos anteriores ataques. Imaginemos que preguntamos por aaaaa.victim.com. Seguramente el servidor legítimo, que es más rápido, le conteste diciéndo que no existe tal dominio (NXDOMAIN). Sigamos intentándolo con aaaab.victim.com, con aaaac.victim.com, de manera recursiva, hasta que llegado un determinado punto, seremos más rápidos y conseguiremos que Pepe_DNS crea que xgsdty.victim.com tiene la dirección 4.3.2.1.

Claro que xgsdty.victim.com es una dirección inexistente, y aunque en la práctica tenemos un DNS “poisoned” (envenenado), no parece servir de mucho ya que nadie va a preguntar por la IP de xgsdty.victim.com. Pero ahora, mediante la técnia del segundo ataque descrito, podemos decirle a Pepe_DNS cuál es la IP de www.victim.com, incluyendo su dirección en la “información de interés”, que sí que nos aceptará por pertenecer al dominio victim.com.

Dicho de otra forma, se trata de conseguir que Pepe_DNS acepte como respuesta legítima una respuesta ilegítima de nivel 3 (xgsdty.victim.com), que aunque no sirva de nada, incluya información sobre la IP de otros dominios de nivel 3 (www.victim.com) del mismo dominio de nivel 2 (victim.com). Tomando un ejemplo más real, si consiguimos que el servidor acepte como válido un paquete que le dice que tazxvb.google.com tiene como IP 1.2.3.4, éste aceptará como válida cualquier información adicional sobre google.com: www.google.com, mail.google.com, etc.

Les dejo a ustedes sacar las conclusiones sobre qué pasaría si el DNS que habitualmente utilizan piensa que www.google.com tiene la IP de www.evil.com. Bien. Pues les adelanto que la mayoría de DNS son (aún) tristemente vulnerables (pueden comprobarlo en el blog de Dan Kaminsky). Ah. Y no saben lo peor, o lo más divertido, depende de su gusto por la ironía; que su DNS no sea vulnerable no significa que estén a salvo, gracias a la estructura jerárquica del servicio de DNS de Internet.

¿No les parece fascinante, y a la vez, un problema “de cagarse”? Nada más. Buen fin de semana a todos.

¿Seguridad o portabilidad?

Hoy en día, los dispositivos móviles se han convertido en un medio tremendamente eficaz para acceder a la información desde cualquier lugar donde podamos necesitarla. Para sus usuarios, la facilidad de acceso independientemente del lugar donde nos encontremos, con el fin de aportar y utilizar la información en seminarios, reuniones, discusiones y negociaciones, para simplemente realizar trabajos durante tiempos muertos en viajes o durante periodos de ausencia de la oficina por otros motivos, así como la posibilidad de tener la oficina en casa, son simplemente herramientas imprescindibles cuando se realiza un trabajo que requiere permanente atención y disponibilidad personal.

Desde el punto de vista del empresario, la tecnología móvil es un medio de facilitar a sus empleados acceso a los datos de la compañía, tanto de negocio como de producto, que potencia de un modo notable las capacidades de negociación y decisión de aquellos. Sin embargo, es muy fácil ver las ventajas, pero resulta menos frecuente pensar en los inconvenientes y riesgos que tal tecnología aporta.

Consideren un Centro de Proceso de Datos. El empresario sabe cuán alto es el presupuesto que le dedica, y considera que es una inversión y un gasto cuyos retornos no siempre están claros o son fácilmente evaluables. No obstante, sí que suele ser consciente de que la seguridad de sus datos es algo como mínimo importante y que el acceso a esta información debe ser controlado y justificado: datos de negocio, de diseño de productos, de estrategias de mercado y desarrollo de la compañía son críticos para la supervivencia de ésta y por otra parte, cada día más, también la protección de los datos personales de sus empleados y colaboradores resulta ser importante, si no se quiere tener un incidente público y encontrarse frente a una fuerte multa y/o un problema de reputación.

Supongamos por tanto que la compañía en cuestión ha invertido un gran presupuesto en almacenamiento de datos, teniendo los sistemas protegidos con tecnologías RAID en los discos duros, haciendo “mirroring” sobre un sistema paralelo con procesador y copia de datos en línea, para dar continuidad a los procesos en caso de recuperación de desastres. Todo esto se encuentra en dos salas separadas y estancas, protegidas con medios de detección y extinción de incendios, protección contra invasión de aguas y gases, paredes y puertas resistentes al fuego, alarmas de intrusión lógica o física, control de accesos, etc. Además hay un sistema de cajas fuertes que guardan las copias de los datos realizadas diariamente. O sea, una fortuna cada mes.

Pues bien, toda esta tecnología y ese gasto mensual, además de la dedicación y el cuidado de un equipo de profesionales especializados en su explotación y control, se ven anulados de repente cuando un empleado hace una copia de datos a su sistema portátil —cuya necesidad no siempre está justificada—, sistema que muy frecuentemente carece de los medios adecuados de protección de la información copiada, creando así un nuevo riesgo en un ambiente externo a la seguridad de sistemas descrita. Esto tendrá como consecuencia la necesidad de un nuevo gasto en seguridad adicional que, por resultar engorrosa para el usuario no especializado, con mucha frecuencia acaba no utilizándose: contraseñas de arranque en BIOS, llaves con certificados digitales, controles biométricos, etc.

A lo largo de las auditorias se detectan de manera reiterada los mismos problemas en diferentes empresas, que aportan riesgos importantes e innecesarios a la información, y ponen en evidencia que la seguridad centralizada no es suficiente.

Por ejemplo. El ciclo de solicitud de un usuario para el acceso a la información suele incluir las firmas y autorizaciones necesarias para otorgar dicho acceso; no siempre se incluyen las funciones que un usuario puede ejecutar, pero al menos si suele incluirse a que bases de datos va a acceder. Una vez ganado el acceso, resulta fácil conseguir volcar una copia de los datos, bien por falta de impedimentos (controles técnicos u organizativos), bien por autorización “tácita” del administrador, que se dice a sí mismo que si tiene acceso autorizado, entonces es que debe poder —estar autorizado a— copiar los datos (tremendo error). En otros casos, el volcado está autorizado debidamente, pero una vez los datos están en los sistemas personales, copiar estos o “sincronizarlos” con una PDA o similar, que el administrador ni siquiera sabe que existe, es bastante más fácil. Con ello, alguien que trabaja con un acceso autorizado, acaba teniendo una copia propia de la información.

Estirando un poco del hilo, muy posiblemente la información acabará llegando a un dispositivo cuyo usuario no sabe que es eso del cifrado, ni le agrada la contraseña tan molesta para arrancar el sistema, ni tampoco es consciente de la cantidad de gente que trabaja vendiendo datos robados, o dicho de una forma más suave, procedentes “de fuentes desconocidas”. A todo esto, el responsable de los sistemas sin enterarse del problema y el empresario creyendo que tan alta factura mensual le asegura que sus datos están protegidos en casa.

Pues bien, aportando datos muy recientes se puede ver cuál es la realidad de esto que parece una exageración:

  • El Canal Historia (de pago) el domingo 20 de julio por la tarde, emite un documental sobre el espionaje. Sorprende saber que una compañía alemana de diseño de aerogeneradores, cuya eficiencia estaba muy por encima de sus competidores, fue denunciada por derechos de patentes cuando intentó comercializarlos en Estados Unidos. Había una empresa que tenía los mismos diseños y tecnología patentados allí. La investigación concluyó en que un grupo de expertos en espionaje industrial, ayudados por algunos empleados, habían copiado diseños y materiales y se habían adelantado en su fabricación y patente en USA. El resultado es que la compañía alemana tuvo que esperar diez años para entrar en el mercado americano y por supuesto hacer un expediente de regulación de empleo.
  • Última hora | EL PAIS | Internacional – 20-02-2008
    La policía brasileña investiga un posible espionaje industrial en Petrobras
    EFE
    «… en Río de Janeiro, Valdinho Jacinto Caetano, afirmó ayer en conferencia de prensa que los ladrones se apoderaron de uno de los cinco ordenadores portátiles que había en el contenedor y de las placas de memoria de otros dos.

    “En un robo común, la persona se lleva el ordenador entero para usarlo … lo que indica que sería espionaje industrial”, agregó. Pese a que ni la policía ni Petrobras han confirmado el contenido de las placas de memoria robadas, la prensa local afirmó que contenían datos geológicos de la cuenca marina de Santos, donde la petrolera descubrió un yacimiento de hidrocarburos …»

  • Última hora | EL PAIS | Internet – 18-07-2008
    Los portátiles robados son delatores
    EFE
    « Cientos de miles de ordenadores portátiles desaparecen cada año en EE UU, bien por robo o descuido. Sólo en los aeropuertos del país se pierden cada semana unos 10.000 aparatos, generalmente … en un estudio oficial.»
  • En uno de los periódicos de este fin de semana, las fuerzas aéreas americanas reconocen que en los últimos años les han robado algunos miles de PC’s (solo?).

Y así sucesivamente….. ¿Entonces, qué hacer? Las reglas no son difíciles de explicar pero son bastante difíciles de implementar:

  • Dar acceso a datos en lugar de dar copias de datos.
  • Minimizar accesos y copias.
  • Cuando las copias sean imprescindibles, resumir y seleccionar la información necesaria. Solicitar autorización para la copia y establecer un periodo tras el cual se destruya.
  • Si la información copiada es confidencial, cifrarla y proteger su acceso.
  • TODOS los dispositivos portátiles deberían tener una contraseña de arranque.
  • TODOS los programas de comunicación con otros dispositivos deberían estar protegidos con contraseñas.
  • La seguridad física de los dispositivos debería ser un motivo de incentivación, y la pérdida o robo por descuido un motivo de acción disciplinaria.
  • NUNCA un dispositivo portátil para uso profesional debe estar accesible a personas distintas del empleado (incluyendo la familia los amiguetes, etc).
  • Mantener un inventario de dispositivos autorizados y sus usuarios.
  • Hacer auditorías periódicas del contenido de los sistemas, en el momento que se conectan a la red.

Hay muchas mas reglas, pero la más básica es que la información solo debe almacenarse donde su seguridad esté garantizada. Y eso es todo por ahora. Seguiré dando el tostón.

Vulnerabilidad en TrueCrypt

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.