PHP Web Stat: Disfruta de mis estadísticas ¡sin password!

Ya hace tiempo le dediqué unas entradas a los paneles de monitorización de servicios web y a los paneles de gestión de estadísticas. De ellos se puede sacar mucha información útil para realizar un ataque y por tanto deben ser controlados en cualquier instalación en producción. Hoy os quiero hablar de uno de esos paneles de estadísticas que me pasó un amigo - gracias rootkit - y que como todos los sistemas de estadísticas web puede llegar a muestra toda la estructura de ficheros de un sitio web con solo localizar un fichero de información del sistema en el servidor web.

Figura 1: PHP Web Stats - Disfruta de mis estadísticas ¡sin password!

El software de gestión de estadísticas desarrollado en Alemania se llama PHP Web Stat y se ofrece un completo y funcional panel para gestionar las estadísticas de un servidor web de forma muy sencilla, pero al mismo tiempo cuenta con otras opciones útiles, como la gestión de versiones de los ficheros o la monitorización de permisos de los mismos o el control del estado del servidor.

Un Directory Listing y Data Leakage by Design

Entre las opciones, como se puede ver en la imagen superior, existe un "feature by design" que permite ver las estadísticas de los ficheros del servidor a cualquier usuario sin tener que utilizar la "molesta password".

Figura 2: SysInfo permite acceso sin contraseña. Todo mucho más cómodo

A toda esta información se accede a través del fichero SysInfo.php, y basta con hacer un poco de hacking con buscadores para encontrarlo en Internet usando un pequeño dork. Con el se pueden localizar miles de servidores web con este software publicado e indexado en Google.

Figura 3: Dork para localizar estos paneles de estadísticas abiertos usado por rootkit

Nada más entrar en el archivo de SysInfo.php se puede acceder a muchos datos jugosos, siendo un "Data Leakage" perfecto ya que no solo muestra datos de estadísticas, sino que también hay listas de ficheros del servidor. En el panel de la izquierda hay información de las propias estadísticas y debajo datos del servidor en sí con las versiones de software que se ejecutan.

Figura 4: Fichero de estadísticas SysInfo.php de un servidor, accesible sin password

A la derecha se cuenta con una lista con las versiones de los archivos que hay en el directorio, siendo un perfecto Directory Listing del sitio, aunque no es completo.

Figura 5: Archivos de datos en formato .dta

En la parte de más abajo hay más información, relativa a las versiones y estado de permisos de cada uno de esos ficheros con acceso a todos los archivos de datos en formato .dta, con lo que para un atacante hay cosas más que suficientes para comenzar a jugar.

El panel de administración y la password de acceso

Para acceder al panel de gestión de estadísticas es necesario conocer la contraseña de administración o de usuario, tal y como se ve en la imagen siguiente. Si se introduce la password de administración, se podrán modificar archivos del sitio, si se introduce la de usuario solo se podrá ver la configuración del panel de control.

Figura 6: Acceso al panel de adminsitración

Estas contraseñas, así como el resto de parámetros relativos a la seguridad de este gestor de estadísticas, se configura en un fichero que se almacena en misma ubicación del servidor llamado config.php.

Figura 7: Mala copia de seguridad del archivo de configuración

En estos entornos, a veces se puede tener suerte y encontrar algún servidor en el que el administrador del sitio haya tenido la mala idea de hacer un "mal backup" de la configuración, permitiendo que la configuración sea descargable.

Figura 8: Acceso a la configuración de seguridad en el backup

Dentro del panel, se puede acceder a todas las opciones que ofrece el software, así como a toda la información que se pueda extraer de las estadísticas, como por ejemplo todas las URLs visitadas, los valores de Http-Referer, las direcciones IP de clientes, etcétera.

Figura 9: Acceso al panel de administración de un gestor de estadísticas 

Toda esta información siempre es jugosa en un proceso de auditoría de seguridad, y se debe mirar con detenimiento para ver cuáles podrían ser los siguientes pasos a realizar.

El backup de los datos en el panel

Entre las cosas que se pueden hacer está la posibilidad de hacer backup, que por defecto se hace en la carpeta backup con un nombre de fichero que es backup_YYYY-MM-DD.zip, tal y como se explica en el panel de control. Para un atacante localizar la lista completa de backups de los últimos 3 años no es tan complicado, basta con hacer unas 1.000 peticiones, lo que tan poco es que sea un protección muy alta de los datos.

Figura 10: Gestor de copias de seguridad de datos de un panel de estadísticas

En definitiva, es un pequeño software de estadísticas que si se localiza en una auditoría tal vez te facilite todas las tareas, y que si lo utilizas, tal vez debas ver la forma de fortificarlo un poco, que puede ser demasiado "verbose".

Saludos Malignos!

The Real Deal: De compras en un supermercado para el cibercrimen en la Deep Web

Ayer domingo a la tarde-noche aproveché un rato de tranquilidad para dar un paseo por algunos de los sitios que había visto de moda en varios sitios. Se trata de una tienda en la Deep Web para cibercriminales dedicados a vender todo tipo de herramientas, exploits, tutoriales, cuentas robadas o bases de datos de servidores owneados, al mejor postor llamada The Real Deal. Solo hay que pagar el dinero suficiente. La verdad es que no he visto muchos exploits de 0day anunciándose en este momento, pero sí que se venden exploits de 1Day y alguna cosa curiosa, así que decidí traeros aquí la información a modo de información de mercado, ya que podéis ver lo que cuesta cada cosa.

Figura 1: The Real Deal, De compras en un supermercado para el cibercrimen en la Deep Web

Entre las cosas que se venden allí, la primera que os traigo es una botnet controlada por IRC de entre 5.000 a 10.000 máquinas infectadas. El coste de esta botnet es de 7.6 BitCoins, lo que sería unos 1.740 € más o menos. A partir de ese momento la botnet sería tuya y lo que harían esos equipos tu decisión y tu responsabilidad.

Figura 2: Venta de una botnet de 5.000 a 10.000 bots

Por supuesto, los amigos del fraude online ya harán su ROI para ver si les sale a cuenta o no controlar una de esas redes por ese precio, pero seguramente ya habrán sido todos los equipos desplumados de usuarios, contraseñas y cuentas que mereciera la pena explotar. De hecho, en otra parte de la web puedes comprar las cuentas bancarias de diferentes bancos, para poder explotarlas.

Figura 3: Lista de cuentas de algunos bancos a la venta

Algunas, como las de SunTrust parece que son las más deseadas, e incluso hay que esperar a que consigan nuevas cuentas para poder acceder a comprar una de ellas con un determinado volumen de dinero en los balances. Como podéis ver, el coste son unos 550 € más o menos.

Figura 4: Cuentas con Balances de 40.000 a 80.000 USD

Entre la lista de cosas, por supuesto, bases de datos robadas de diferentes sitios para que los amantes de los datos puedan explotarlas. ¿Qué habrá en ellas? ¿Habrá cuentas de gente que se ha registrado con la cuenta de su empresa utilizando la misma contraseña y sin tener un segundo factor de autenticación? Seguro que muchos han comprado ya esos datos por ese precio. Solo unos 687 €.

Figura 5: Base de datos de 4 Millones de usuarios

Algunas, incluso, de las más conocidas. En este foro venden la base de datos de BitCoinTalk.org con todos los datos de todos los miembros por un precio nada desdeñable de 126.9 Bitcoins. Es decir, un total de unos 28.800 € por los datos que ahí se almacenaban. Sí, en Mayo se anunció que se había vuelto a hackear.

Figura 6: BBDD de BitCoinTalk.org a la venta

No solo datos y cuentas, también se venden RATs y exploits para realizar intrusiones. En este ejemplo se puede ver un 1Day Exploit de Internet Information Services publicado el 15 de Abril para el MS15-034 de MS IIS que permite ejecución remota de código por un total de 72.000 €, que no está nada mal.

Figura 7: Exploit para MS IIS de ejecución remota de código

Por último, para no haceros muy largo este artículo, el sitio vende muchos tutoriales y material de formación, entre otros he seleccionado esta guía para ganar dinero haciendo trampas al poker online en sitios de juego online, por 30 € - un poco más que los libros de 0xWord -. Si juegas al poker online, alguno de tus contrincantes puede estar bien enseñado.

Figura 8: Guía para hacer trampas al poker online

En la red TOR se han empezado a poner de moda este tipo de tiendas, y ya son bastantes las que se dedican a esta venta especializada en el mundo del cibercrimen, así que cada día veremos que el robo de datos, la venta de información, el hackeo de servidores, equipos, etcétera, se hará más profesional. 

Figura 9: Uno de los servidores SCADA con acceso que se venden

Estos días la noticia era la venta en otros markets del acceso a servidores SCADA, así que para alguien que quiera hacer alguna tontería puede ser tan fácil como invertir unos BitCoins en el foro adecuado. 

Saludos Malignos!

Señor Juez, Facebook guarda todos tus datos pero ninguno de tus acosadores

Entre el número de mensajes que me llegan diariamente solicitando servicios ilegales, el del robo de credenciales de cuentas de Facebook es muy habitual. Esto es así porque Facebook se ha convertido en el centro de la vida social de muchas personas. No el correo electrónico o las cuentas en otros servicios, sino la actividad que se tiene en Facebook. Es por eso que las pasiones humanas se hayan trasladado allí. Celos, miedos, venganzas y acosos han poblado la red social, haciendo que el número de denuncias en los juzgados en que entra de por medio alguna actividad en Facebook crece sin parar.

Figura 1: Señor Juez, Facebook guarda todos tus datos pero ninguno de tus acosadores

Hoy en día, cuando se quiere vilipendiar y acosar a una persona se hace también por Facebook. No es raro que aparezcan cuentas "stalker" que se dedican solo a espiar la actividad de una persona, cuentas "Cyberbullying" que se dedican a insultar y acosar aprovechándose de secretos personales conocidos por algún grado de cercanía, medias verdades que se apoyan en la rumorología o directamente mentiras jugosas que la gente estará dispuesta a deglutir sin necesidad de muchas pruebas.

Figura 2: Petición de hoy para robar la contraseña de Facebook de una ex

Dentro de las cuentas que se crean para acosar a las personas en Facebook existen algunas muy dañinas que son las cuentas de la venganza, donde alguna ex-pareja o ex-relación puntual aprovecha todo lo que puede para hacer daño. Casos de estos son las publicaciones de fotografías comprometedoras que se han hecho en la intimidad de la relación y que acaban publicadas en redes sociales como Facebook o Twitter e indexadas en Google. Hoy en día, las tres empresas han dicho que bloquearán este tipo de contenido para evitar que las personas sufran, como ya os conté en la reflexión que le dediqué a Google sobre este respecto.

Figura 3: Cuenta impersonandome en Facebook

El caso es que no basta con esto. No basta porque el acosador se va de rositas en muchas ocasiones. No hay forma de meterle mano legalmente y ya buscará otra forma de hacer daño a la misma persona. No es raro encontrarse con que el acosador, baneada su cuenta de las redes sociales por haber hecho algún acto similar a estos busca otra forma de conseguir el mismo efecto, enviando el contenido por grupos de WhatsApp o por la clásica lista de direcciones de correo electrónico que crea con las direcciones de las personas cercanas a la víctima.

La justicia en Europa contra el acoso en Facebook

Muchos ciudadanos en Europa está hartos de sufrir el destrozo de su vida pública porque se ha permitido este tipo de publicaciones en una red social, y que los estafadores del sexting están aprovechando para hacer un negocio de las pobres víctimas que capturan en los sitios como Chatroulette y a los que tienen extorsionados después. Tal y como informa Reuters en el caso de una joven de Holanda, este hecho convirtió su vida en un infierno, y en algunos casos hay jóvenes que extorsionadas con la posibilidad de caer en un escándalo similar acaban en esquemas de Grooming que les ha llevado al suicidio.

Figura 4: Amenaza de acoso vía Facebook en una sextorsión

Visto todo esto, en Holanda se ha requerido a Facebook que identifique quién estaba detrás de las acciones de acoso y publicación de los contenidos que han destrozado la vida de esta joven, algo que según dicen ellos es - a pesar de enfatizar con su dolor -: 

"The offending account was ultimately deleted before we received any request for user data, so all information about it was removed from our servers in accordance with our terms and applicable law"

Es decir, Facebook dice no poder cumplir con la regulación porque han borrado todos los datos, lo que convierte a la compañía que más datos guarda de los usuarios, es la que menos datos guarda de los que te acosan, por lo que no podría recuperar ninguna información. Por supuesto, esto al juez no le ha sentado muy bien que digamos y por eso en la sentencia se ha dejado claro que:

"If Facebook continues to maintain that all data that could lead to a person are definitively deleted from its servers and no longer traceable, that should be confirmed by an independent researcher"

Es decir, que ahora se deberá saber si existe alguna forma o no de sacar los datos de los servidores de Facebook o no. No olvidemos que la compañía guarda datos de todos los usuarios que tienen que ver incluso con su navegación - algo que le está costando a Facebook otra investigación de Europa por no respetar la privacidad de sus usuarios - y que el número de bases de datos en las que almacena datos relativos a los IDs de las cuentas es alto, así que más que probablemente existirá forma alguna de tracear los movimientos de esa cuenta entre toda la maraña de datos.

Figura 5: Esquema de captura de datos en Facebook

Recordemos que compañías como Apple se enfrentaron a escándalos como el de CarrierIQ por guardar hasta las pulsaciones que se hacen en el teclado del iPhone en cualquier sitio y que Facebook puede estar guardando hasta lo que se borra al escribir y que venía descubierto por el estudio académico que dos investigadores en Facebook realizaron sobre "la autocensura".

Figura 6: Estudio sobre la autocensura donde se explica
cómo se guardan las pulsaciones de teclas que se borran

Facebook no ha respondido aún y está claro que esto no ha acabado aún. Los anuncios de Google, Twitter y Facebook de luchar contra este tipo de contenidos no es más que una reacción a la exigencia que desde Europa se está haciendo para que cumplan con las legislaciones europeas que las empresas creadas a este lado del océano tienen que respetar y que afectan a la gestión de los datos, los derechos ciudadanos y la investigación de los cuerpos de seguridad del estado que, serán del gusto o no de las empresas citadas, pero son las que hay.

Cumplimiento legal y privacidad en Facebook (y otras)

Para evitar este tipo de cumplimientos legales, incluidos los del gobierno de USA que ha hecho calar en la opinión pública una situación de abuso con revelaciones como el programa PRISM y similares, las empresas están buscando la forma de justificar que ellos no pueden dar esos datos porque no los tienen. Para ello aplican sistemas de mensajería que no guardan los datos en sus servidores, como en el caso de iMessage - aunque eso no implica que no se pueda interceptar la comunicación de los mismos -, o WhatsApp que intenta no guardar esos datos para evitar problemas legales - aunque sigue saliendo mal en los análisis de privacidad -.

Figura 7: Facebook aparece en PRISM desde el año 2009

En el caso que nos ocupa, el de los acosadores en Facebook, si estos tomaron sus precauciones a la hora de crear las cuentas, no será del todo fácil localizarle. Hay que tener en cuenta que con tener una dirección de correo electrónico previa es posible tener una cuenta en Facebook y que esta se puede crear directamente desde la red TOR - incluso conectándose a los servidores de Facebook que la compañía ha puesto allí -.

Figura 8: Servidores de Facebook en la red TOR

Dicho todo esto, el debate está servido como siempre, con respecto a la privacidad. En asuntos como el de la pederastia, empresas como Google y Microsoft ya dieron un paso adelante denunciando a usuarios que guardaban en sus servidores de OneDrive o en el correo de Gmail contenido pedófilo.

¿Merece el acosador irse de rositas? ¿Deben las empresas como Facebook, Twitter o Google permitir que los acosadores vean que destrozar la vida de una persona es fácil gracias a ellos? ¿Deben ser los que pongan las plataformas para que estos individuos campen?

Saludos Malignos!

Aplicaciones .NET con campos ViewState sin firmar o cifrar

Las aplicaciones web escritas en ASP.NET utilizan desde su concepción hace ya muchos años un campo oculto llamado ViewState que controla el flujo de datos y estados de la aplicación en todo momento. Este campo se utiliza para garantizar la privacidad y la integridad de la información en cada uno de los intercambios de información que se producen entre el servidor web y el cliente web. Es decir, para garantizar que la información no ha sido manipulada y que además se ha transferido de forma correcta en todos sus campos.

Figura 1: Aplicaciones ASP.NET con campos ViewState sin firmar o cifrar

Para poder conseguir estos objetivos con garantías, ViewState debe ir firmado y cifrado, pero esto no siempre es así, sobre todo en aplicaciones más antiguas que puedan estar aún en los servidores de muchas organizaciones.

Firmado de ViewState

Desde ASP.NET v.1.0 los campos ViewState van firmados por con un código MAC (Machine Authentication Check), que no es más que un CheckSum de toda la información que se encuentra almacenada dentro de ViewState. La idea es tan sencilla como que una vez que se decide qué se tiene que transferir, se hace una codificación en BASE64, se hace el CheckSUM de la misma y se calcula el valor MAC.

Figura 2: Flujo de utilización de ViewState

De esta forma, cuando se carga la página que se debe renderizar o cuando se envía de vuelta al servidor se puede comprobar si esta ha sido modificada verificándola con el valor de ViewState. Si no coincide, el servidor dará un error de aplicación.

Figura 3: Error .NET de fallo de validación de MAC en el campo ViewState

Esto está configurado a TRUE por defecto en la propiedad EnableViewStateMac desde la versión ASP.NET 1.0, por lo que es raro encontrar aplicaciones que no manejen el campo ViewState firmado, pero si esto sucediera entonces las funciones de integridad de la web aportadas por ASP.NET no serían robustas. 

Cifrado de ViewState

En cuanto al cifrado del campo ViewState no se activó por defecto hasta la versión ASP.NET 2.0. donde para configurar que se cifre el contenido almacenado - y no vaya solo codificado en BASE64 y con un código MAC - hay que configurar los valores decryptionKey y decrypt de las propiedades de MachineKey, tal y como se explica en este artículo de la MSDN. 

Figura 4: Generación de claves de MachineKey

La claves para algunas versiones de ASP.NET, como se puede ver en la imagen superior, se pueden crear y renovar desde el servidor IIS 7, tal y como se explica en este blog de MSDN.

Decodificar campos ViewState sin cifrar

No es demasiado común encontrar aplicaciones ASP.NET que tengan el campo ViewState sin cifrar, pero aún así, en nuestro sistema de Pentesting Persistente Faast, uno de los plugins que se centra en la seguridad y vulnerabilidades de este tipo de tecnologías, sí que lo revisa. En el siguiente ejemplo se puede ver una web localizada en producción con el campo ViewState sin cifrar.

Figura 5: Detección de aplicación ASP.NET con ViewState sin cifrar

Cuando el campo está sin cifrar, lo único que sucede es que se pueden acceder a todos los datos en tránsito, y entre ellos pueden ir las cookies de sesión que se estén intercambiando, o cualquier otra información sensible de la web.

Figura 6: El campo ViewState localizado sin cifrar en un decodificador

El código para decodificar un campo ViewState sin cifrar es conocido - tenéis uno disponible en esta pregunta de StackOverflow -, y es fácil localizar decodificadores online que te muestran todo el contenido dentro del mismo, tal y como se puede ver en la imagen siguiente.

Figura 7: Contenido decodificado de un ViewState sin cifrar

La firma y el cifrado de ViewState ayudan a hacer mucho más robustas las aplicaciones ASP.NET y a protegerlas frente a ataques avanzados, por lo que es una recomendación de seguridad básica en estos entornos. Además, los campos ViewState ayudan también a gestionar la seguridad frente a ataques CSRF, pero eso exige otras configuraciones de las que ya os contaré en otro artículo.

Saludos Malignos!

SmartGrids protegidos con Latch: Concentradores de Telegestión de Contadores PLC de Telecon integran Latch

Ayer se publicó en el blog de Eleven Paths un caso de uso de la tecnología Latch que nos pareció más que interesante, ya que combina el uso de dispositivos hardware con nuestra tecnología Latch. El caso de uso es bastante sencillo de entender, es una protección de un dispositivo físico desplegado en instalaciones contra accesos no autorizados. En concreto le permite a la empresa instaladora controlar el acceso a los Concentradores de Telegestión que se encargan de gestionar los Contadores PLC y que fabrica TELECON.

Figura 1: SmartGrids protegidos con Latch: Concentradores de Telegestión
de Contadores PLC de Telecon integran Latch

TELECON es una compañía española de origen gallego centrada en la fabricación de dispositivos inteligentes que se puedan aplicar a escenarios de Control Industrial Inteligente, SmartCites, soluciones (IoT) Internet of Things, o sistemas de vigilancia. Uno de los grandes problemas que se han detectado en los dispositivos hardware que se despliegan es la ausencia de segundos factores de autenticación en los procesos de control de acceso, y mucho peor, la implantación de los mismos con contraseñas por defecto o comunes.

Figura 2: Empresa Telecon

Para hacer más fácil el control de acceso a los dispositivos, desde TELECON han lanzado una línea de dispositivos hardware, estos Concentradores de Telegestión de Contadores PLC utilizados en soluciones de eficiencia energética y SmartGrids, que vienen incluidos con Latch. Esto permite a la empresa instaladora controlar el acceso a los mismos desde un dispositivo centralizo que abra y cierre las cuentas a los técnicos que deben ir a hacer las revisiones de forma centralizada.

Figura 3: Nuevos Concentradores de Telegestión que incorporan Latch

Es decir, es un dispositivo de supervisión que no solo permite elegir cuándo se van a poder realizar los accesos al dispositivo, si no que además permite - con la posibilidad de recibir una alerta cuando se acceda con el Latch abierto - saber cuándo se está accediendo a cada uno de los mismos.

Figura 4: Control del acceso a los Concentradores con Latch

Este es un caso de uso de Latch como capa de protección a un escenario de seguridad industrial, ya que desde estos dispositivos se pueden hacer cosas como cortar la luz de la instalación a la que estén conectados y tener esta posibilidad de gestión remota y supervisión de accesos mejora la protección de toda la infraestructura. Si tienes algún otro caso de uso en el que hayas implementado Latch, cuéntamelo, que nos llena de alegría ver cómo se usan nuestras tecnologías.

Saludos Malignos!

CustomErrors en .NET: Cómo evitar fugas de información por los mensajes de error

Para terminar este ciclo que he dedicado a los errores, o más concretamente a los mensajes de error, en aplicaciones .NET, es obligatorio terminar hablando de la posibilidad que permite el framework de personalizar, a nivel de servidor en el fichero Machine.Config o a nivel de aplicación en Web.Config, los mensajes de error que se van a mostrar. Ya hemos visto que los mensajes de error en modo Debug pueden generar un problema de seguridad grande al mostrarse el código fuente de la aplicación, pero los mismos mensajes de error .NET, aún no estando activado dicho modo, pueden seguir dando muchos detalles de la plataforma a los posibles atacantes. Esto se puede solucionar con una personalización robusta de los mensajes de error.

Figura 1: CustomErrors en aplicaciones .NET

La configuración de los mensajes de error permite que se personalice el entorno con cuatro posibilidades distintas, que deben ser tomadas en cuenta para cada necesidad. Esto se hace dentro de la sección de Machine.Config o Web.Config dedicado a System.Web, tal y como se ve a continuación:

<system.web>

<customErrors mode="On|Off|RemoteOnly" defaultRedirect="~/Error/Index" />

</ system.web>

CustomErrors mode OFF

Si el framework tiene configurado el valor de CustomErrors a OFF, eso quiere decir que se deben mostrar los errores .NET detallados, con la información concreta de qué excepción no controlada lo ha generado.

Figura 2: Error detallado que se obtiene con CustomErrors OFF

Un atacante podrá saber en todo momento qué es lo que está fallando en la aplicación .NET y le servirá para preparar una estrategia de ataque mucho más fácilmente.

CustomErrors mode ON

En este caso, cuando se genere un mensaje de error se mostrará una información genérica. Estos mensajes son los famosos Runtime Error que tantas veces aparecen en aplicaciones .NET. Esto indica que hay una excepción no controlada, pero el código del mensaje no da detalles sobre qué lo ha generado.

CustomErrors mode RemoteOnly

En este caso, el mensaje de error será también el genérico "Runtime Error" cuando se esté conectado el cliente desde una ubicación remota, y detallado cuando se genere desde la máquina local. En el siguiente ejemplo se puede ver como el mensaje indica que es genérico, pero que sería detallado si la conexión fuera local.

Figura 3: Error genérico que se obtiene con CustomErrors ON o
con CustomErrors RemoteOnly en una conexión remota

CustomErrors mode ON | RemoteOnly con DefaultRedirect

En el caso de que se haya decidido poner un modo de CustomErrors configurado a ON o a RemoteOnly, se puede configurar una página de error genérica. Esto haría que se diera solo la información corporativa que se desease. En el siguiente ejemplo el DefaultRedirect de Microsoft.com con los errores .NET.

Figura 4: Excepción controlada con CustomErrors y DefaultRedirect

Otros Errores de IIS y/o de Request Filtering

Hay que tener presente que, en un servidor IIS con una aplicación .NET hay otros mensajes de error que también hay que configurar. Ya vimos hace poco que los mensajes de error del módulo de Request Filtering son totalmente distintos, o los que se obtienen por cualquier excepción en el propio servidor IIS.

Figura 5: Mensaje de error 405 en un servidor IIS

Pero también serán distintos los errores del propio servidor IIS que tengan que ver con aplicaciones que no sean .NET, como en el caso de aplicaciones ASP normales, tal y como puede verse en la siguiente imagen.

Figura 6: Mensaje Error 404 en un servidor IIS con una aplicación ASP

Es decir, configurar CustomErrors en .NET ayuda a tener los errores del framework .NET controlados, pero debes controlar los mensajes de error de todos los frameworks, que puedes tener las fugas de información en cualquier sitio.

Saludos Malignos!

La NSA espió a los presidentes de Francia según Wikileaks

En la web de Wikileaks se ha abierto un micro-site dedicado en exclusiva a documentos confidenciales de la NSA americana que dejarían a las claras, dando pelos y señales, acciones de espionaje continuado a ministros y presidentes de Francia, entre los que se encuentran el actual Francois Hollande y los anteriores Jacques Chirac y Nicolas Sarkozy. 

Figura 1: La NSA espió a los presidentes de Francia según Wikileaks

Entre los documentos se encuentran los "selectores" para interceptar sus llamadas telefónicas, algo que ya habíamos visto anteriormente en el espionaje de las llamadas de teléfono de Angela Merkel, pudiendo utilizar para ello la interceptación de las llamadas en la red, o directamente infectando los terminales como se hizo en reuniones del G8 y G20.

Figura 2: Los selectores de espionaje de los presidentes y ministros franceses

Entre los documentos, publicados y explicados uno a uno, se puede ver como la NSA podría haber estado siguiendo todas y cada una de las reuniones de los presidentes en Europa para tener información detallada de todos los movimientos.

Figura 3: Documentos de reporte de espionaje de conversaciones a presidentes de Francia

Los archivos, están fechados entre 2006 y 2012 y hacen referencia a todos los escenarios internacionales en los que Francia ha estado tomando parte, y que van desde la crisis de Grecia con la Eurozona o los conflictos en Palestina.

Figura 4: Documento filtrado de conversación espiada relativa al conflicto en Palestina

Los próximos días los analistas políticos deberán analizar el material que se ha publicado, pero desde luego está claro que el Patriot Act y la ley FISA concedido a la NSA, que autorizaba al espionaje de ciudadanos extranjeros, se ha llevado a extremos que para muchos son difícilmente entendibles por sus "aliados" europeos.

Saludos Malignos!

Google y la LOPD: ¿Por qué no la "cumple como todos"?

Las noticias de estos últimos días hablan de que por fin Google va a retirar de sus índices las fotos íntimas subidas como forma de venganza por algunas ex-parejas.  Es decir, eliminar las fotos de personas que, sin quererlo las protagonistas de las fotos, han acabado publicadas en Internet e Indexadas en Google. Tras leer esta noticia, la sensación que me da es que Google ha dicho algo así como:

"Bueno, vale... después del millón de quejas al respecto voy a quitarlas porque creo que puede estar haciendo daño a alguien". 

Esta aceptación de las órdenes judiciales dictadas para que Google hiciera esto es similar a lo que ha sucedido con la aplicación del Derecho al Olvido, donde Google ha tenido que aceptar quitar de sus índices los enlaces a documentos con información y datos de carácter personal sujetos a la ley del derecho al olvido. Algo que Google no ha hecho aún en Google.com, y que permite a cualquier persona cambiar de motor buscador para ver toda la información de un sujeto, por lo que Europa le está reclamando otra vez que implemente correctamente los controles para que se aplique esta Ley.

Figura 1: Google y la LOPD, ¿por qué no la "cumple como todos"?

Google se suele negar en rotundo a hacer esto que la empresa llama "manipulaciones de los resultados" y parece estar solo interesado en hacerlo cuando haya un motivo realmente importante, como promocionar sus servicios por encima de la competencia haciendo algo que podríamos llamar "G-SEO" - el equivalente a "el buscador es mío y me posiciono como quiero" -.  Vistas estas noticias, hoy quería poneros sobre la pantalla una reflexión sobre privacidad y legalidad que lleva dando mucho tiempo vueltas en mi cabeza, y que tiene que ver con la aplicación de la Ley Orgánica de Protección de Datos (LOPD) en España y  la empresa Google, en concreto, con el Índice de Google y los Servidores de Caché de Google.

Los ficheros de datos y la LOPD

Supongamos una persona de una empresa que, aprovechando que la gente es distraída y deja sus datos personales e información personal publicada en sus páginas web, se dedica a recolectarla y meterla en una base datos. Supongamos que esos datos también tienen información de carácter muy personal, como estudios, puestos de trabajo desempeñados, notas universitarias, direcciones de su casa, su trabajo, números de teléfono, etc...

Supongamos que esa empresa guarda todos los datos en un fichero Excel, o en una base de datos Access, o en un simple fichero de texto y que pone la información que ha sido capaz de encontrar disponible para todos los empleados de la empresa a través de una pagina web interna con un interfaz de consultas, para que, por ejemplo, los entrevistadores de la empresa, los comerciales de la compañía, o los visitadores a clientes - por citar algunos roles -, se dediquen a sacar partido de esos datos en la generación de negocio para la compañía.

Por ejemplo, una empresa como un banco podría dedicarse a recoger todos los datos de los DNI de los ciudadanos españoles que hubieran quedado publicados en Boletines Oficiales, listados de notas, publicados en Curricula al rededor de la red, o simplemente perdidos en las redes P2P y crear un sistema interno de Risk Scoring para decidir que personas son más propensas a sufrir una robo o suplantación de identidad y poner más controles en la creación de cuentas o la contratación de servicios. Por poner un ejemplo de utilidad de toda esa información que está por la Red perdida. 

Figura 2: Datos almacenados en los servidores de Google de cada dato encontrado en Internet

Pues bien, esa empresa en el momento que almacene alguno de esos datos, debería declarar ese fichero, informar a los dueños de los datos de la captura de los mismos, establecer un canal informado de cómo gestionar el acceso para la consulta, modificación y borrado de esa información además de, por supuesto, declarar el fichero en la Agencia Española de Protección de Datos, ya que se tiene un fichero de datos personales.

El índice de Google y la Caché de Google es un fichero

Ahora bien, vayamos con Google y sus servidores para gestionar el Índice de Google y la Caché de Google. He oído muchas veces a gente de Google en el top management de la compañía en España decir que ellos no tienen datos, que los datos están en Internet y que su buscador únicamente dicen dónde están. Eso no es cierto ni mucho menos. Google también guarda datos, de todo el mundo, datos personales muchas veces, obtenidos sin informar a los usuarios y dueños de los datos. Los guarda, en el Índice de Google y a veces también en los Servidores de Caché de Google. De hecho, tienen los ficheros registrados.

La explicación técnica ya la conocéis, pero os la resumo en corto. Google visita todas las webs que puede de Internet con sus GoogleBots, accede al contenido público, ya sea porque es 100% público, porque alguien malo pone esa información incumpliendo la legalidad - como las fotos intimas de las venganzas que ahora va a retirar - o simplemente por un error puntual en el funcionamiento de la la plataforma web que los almacena - como en los casos famosos de Google Hacking -. Una vez que Google accede a toda esa información, genera una mega-base de datos llamado Índice de Google donde se almacena la información que ha recolectado, donde se encuentran los datos personales anteriormente citados. Algunas veces, además son también copiados en los servidores de Caché de Google. 

Figura 3: Los datos que se ven en los resultados están guardados en los servidores de Google.
Son datos que Google tiene en el Big Data que soporta su Índice de Google

Si los datos desaparecen de su ubicación original, es decir, que ya no están los datos en ningún sitio de Internet porque han sido eliminados por mil razones. Estos seguirán estando en el Índice de Google y/o en los Servidores de Caché, y simplemente accediendo a ese "fichero de datos" vía el motor del buscador, será posible acceder a los datos de carácter personal que Google tenga de esa persona. Un claro ejemplo de esto os lo conté con el caso de las contraseñas y datos de una persona que por error configuró mal una página de información en Evernote, y los datos siguieron en el Índice de Google durante meses.

Figura 4: Extracción de datos almacenados en los servidores de Google con Google Index Retriever

Sí, como digo e insisto para que quede claro, los datos están en los servidores de Google y automatizar las búsquedas será posible extraer todos los datos que tiene almacenado ese mega-fichero de datos de carácter personal llamado Índice de Google, como hace Google Index Retriever que saca la información que está almacenada en él.

La aplicación de LOPD sobre los ficheros de datos

Ahora que ya hemos dejado claro que los datos, además de estar en su ubicación original - o no -, están en los servidores de Google, hay que ir a la Ley Organica de Protección de Datos (LOPD) donde se define que un fichero de datos de carácter personal es:

"todo conjunto organizado de datos de carácter personal, cualquiera que fuere la forma o modalidad de su creación, almacenamiento, organización y acceso."

Esto quiere decir que para la Agencia Española de Protección de Datos es indiferente el modo cómo Google haya obtenido los datos de carácter personal (incluso si este es un bot que se dedica a recogerlos por todo Internet aprovechando fallos de configuración, venganzas personales o ataques dirigidos a personas o instituciones), que le da igual si es un fichero Excel o Access (o un mega Big Data para dar soporte al Índice del mayor buscador del mundo) y que por supuesto le importa poco si se utiliza un lenguaje de consultas como SQL, filtros LDAP o consultas de búsquedas en Excel para acceder a los datos (y por supuesto, incluso un buscador que se encuentre publicado en Google.com).

De hecho, tiempo atrás estuvimos mirando cómo aplicaría la LOPD a los volcados de memoria que se producen en los sistemas operativos cuando se lanza una excepción, y tras consultar con la AEPD la conclusión es que esos dumps deberían ser contemplados como ficheros temporales que deberían ser tratados con los mismos mecanismos de seguridad. Dicho todo esto, mi pregunta es sencilla:

¿Por qué Google no declara en la LOPD de la Agencia de Protección de Datos todos los datos que tiene de ciudadanos Españoles, que son muchos y nos da a los ciudadanos los mismos derechos ante esta empresa que ante cualquier otra que recolecte nuestros datos?

Os recuerdo que por ejemplo, en su Índice de Google guarda todos los datos que ha capturado del BOE o los números de teléfono y direcciones de los ciudadanos que no se han dado de baja en Infobel, pero también los de sitios vulnerados, las notas de la universidad, etcétera. Por eso Google registra su fichero de datos. 

Robots.txt, No Index y las WebMaster Tools

Cuando llegamos a esta parte de la conversación, las explicaciones suelen referenciar a las herramientas de control de indexación de datos en Google para el cumplimiento de la LOPD, como por ejemplo, la configuración de ficheros robots.txt, el uso de las HTML Tags noindex o las herramientas que la compañía pone a disposición de los administradores de sitios web en las WebMaster Tools. Algo que hemos visto ya cómo funciona de regular hasta para sus propios servicios de Gmail.

Figura 5: Números de teléfono usados en Gmail que acabaron en el Índice de Google

En todos los casos, estamos hablando de herramientas que están dirigidas y creadas para sitios web que publican cosas en Internet, y que nada tienen que ver con el usuario del que se capturan los datos. Si una web publica los datos de una persona y Google los almacena en los servidores de su Índice, a la persona que se ve expuesta no se le puede transferir la responsabilidad y someter al chantaje de quitar antes todos los datos de todos los sitios de Internet para que luego desaparezcan del fichero del Índice de Google.

Así no funciona la LOPD. Google guarda ese fichero con datos de carácter personal y debe cumplir la LOPD sin escabullir su responsabilidad. Ha almacenado los datos para crear un servicio y debe dar a los ciudadanos todas las garantías que marca la ley para salvaguardar su privacidad. Por supuesto, es posible borrar los datos de los servidores del Índice y de la Caché de Google servidos por Google España comunicándose con ellos, pero no es igual si alguien accede a Google.com. En definitiva, tus datos siguen ahí.

Saludos Malignos!