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

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.

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.

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.

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.

Hace unas semanas, un conocido tecnólogo-gurú 2.0 se quejaba de que una empresa seguía mandándole correos electrónicos de publicidad a pesar de los reiterados intentos de cancelar una presunta suscripción. Como respuesta a su comentario, algunas personas le sugirieron que esa publicidad era legítima debido a que su correo estaba publicado en su blog, y por tanto en una fuente de acceso público.

Con apelar al sentido común, se da uno cuenta de que si esto fuese efectivamente así, se estaria legitimando el 95% del envío de spam; al fin y al cabo, no hay más que navegar un poco para hacerse con una cantidad nada despreciable de correos electrónicos. Pero como no quiero que se fíen de mi palabra, les muestro lo que dice el punto j) del artículo 3, “Definiciones”, de la LOPD:

Antes de que se me adelanten, creo que considerar Internet en su conjunto un medio de comunicación es algo excesivo, así que en mi opinión queda claro, ¿no?

Nada más esta vez. Buen fin de semana a todos.

-

Actualización: Se me olvidó añadir que el reglamento añade “Las guías de servicios de comunicaciones electrónicas, en los términos previstos por su normativa específica”, aunque eso no modifique el razonamiento realizado.

Después de unos días de abandono personal del blog, por cuestiones de salud y de trabajo, vengo a comentarles hoy una cuestión sobre el nuevo Reglamento de Desarrollo de la LOPD, también conocido como RDLOPD, que me parece no sólo curiosa, sino incluso fascinante. Veamos como introducción la definición de fichero y de fichero no automatizado, según el punto k) y n), respectivamente, del artículo 5:

A causa de la gestión de un proyecto europeo de protección de la privacidad de las personas y de la seguridad de sus datos en una empresa multinacional, tarea a la que llevo dedicado los últimos siete años de mi vida profesional, he tenido que estudiar las diversas leyes y normativas acerca de la protección de datos. Aunque están todas ellas basadas en la Directiva Europea y por tanto con textos legales muy similares, no sólo hay pequeños detalles que las hacen totalmente diferentes, sino que además la manera de interpretar y aplicar dichas leyes por los ciudadanos de cada país, convierten la protección de datos personales en algo muy dispar en requerimientos, riesgos y consecuencias, afectando de manera importante al coste de adaptarse a cumplirlas o simplemente ignorar que existen (ya que de todo hay en esta Unión Europea).

Si empezamos por el ámbito de aplicación, en algunos países se especifica que afecta a las personas físicas, en otros también a personas jurídicas, en otros además a todas las organizaciones legalmente establecidas, y para colmo existe un problema común ya que no hay manera de establecer el límite entre persona identificable y no identificable de una forma clara.

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.