Cómo verificar una violación de datos | TechCrunch

A través de los años, TechCrunch ha cubierto ampliamente las violaciones de datos. De hecho, algunas de nuestras historias más leídas provienen de informes sobre grandes violaciones de datos, como revelar prácticas de seguridad de mala calidad en nuevas empresas que contienen información genética confidencial o refutar afirmaciones de privacidad de una aplicación de mensajería popular.

No es sólo nuestra información sensible la que puede difundirse en línea. Algunas filtraciones de datos pueden contener información que puede tener un interés público significativo o que sea de gran utilidad para los investigadores. El año pasado, un hacker descontento filtró los registros de chat internos de la prolífica banda de ransomware Conti, exponiendo las entrañas de la operación, y una enorme filtración de mil millones de registros de residentes extraídos de una base de datos de la policía de Shanghai reveló algunas de las prácticas de vigilancia en expansión de China.

Pero uno de los mayores desafíos al informar sobre violaciones de datos es verificar que los datos sean auténticos y no que alguien intente reunir datos falsos de lugares dispares para venderlos a compradores que no se dan cuenta.

Verificar una filtración de datos ayuda tanto a las empresas como a las víctimas a tomar medidas, especialmente en los casos en los que ninguno de los dos tiene conocimiento del incidente. Cuanto antes sepan las víctimas de una violación de datos, más medidas podrán tomar para protegerse.

El autor Micah Lee escribió un libro sobre su trabajo como periodista autenticando y verificando grandes conjuntos de datos. Lee publicó recientemente un extracto de su libro sobre cómo periodistas, investigadores y activistas pueden verificar conjuntos de datos pirateados y filtrados, y cómo analizar e interpretar los hallazgos.

Cada violación de datos es diferente y requiere un enfoque único para determinar la validez de los datos. Verificar que una filtración de datos es auténtica requerirá el uso de diferentes herramientas y técnicas, y la búsqueda de pistas que puedan ayudar a identificar de dónde provienen los datos.

Siguiendo el espíritu del trabajo de Lee, también queríamos profundizar en algunos ejemplos de violaciones de datos que hemos verificado en el pasado y cómo las abordamos.

Cómo descubrimos a StockX ocultando su violación de datos que afecta a millones

Era agosto de 2019 y los usuarios del mercado de venta de zapatillas StockX recibieron un correo electrónico masivo en el que se les decía que debían cambiar sus contraseñas debido a “actualizaciones del sistema” no especificadas. Pero eso no era cierto. Días después, TechCrunch informó que StockX había sido pirateado y que alguien había robado millones de registros de clientes. StockX se vio obligada a admitir la verdad.

La forma en que confirmamos el truco fue en parte suerte, pero también requirió mucho trabajo.

Poco después de que publicáramos una historia en la que se señalaba que era extraño que StockX obligara potencialmente a millones de sus clientes a cambiar sus contraseñas sin previo aviso ni explicación, alguien se puso en contacto con TechCrunch afirmando haber robado una base de datos que contenía registros de 6,8 millones de clientes de StockX.

La persona dijo que estaba vendiendo los supuestos datos en un foro sobre delitos cibernéticos por 300 dólares y acordó proporcionar a TechCrunch una muestra de los datos para que pudiéramos verificar su afirmación. (En realidad, todavía nos enfrentaríamos a la misma situación si hubiéramos visto la publicación en línea del hacker).

La persona compartió 1.000 registros de usuarios de StockX robados como un archivo separado por comas, esencialmente una hoja de cálculo de registros de clientes en cada nueva línea. Esos datos parecían contener información personal de los clientes de StockX, como su nombre, dirección de correo electrónico y una copia de la contraseña codificada del cliente, junto con otra información que se cree exclusiva de StockX, como la talla de zapato del usuario, qué dispositivo estaba usando y en qué moneda estaba operando el cliente.

En este caso, teníamos una idea de dónde procedían originalmente los datos y trabajamos bajo esa suposición (a menos que nuestras comprobaciones posteriores sugirieran lo contrario). En teoría, las únicas personas que saben si estos datos son precisos son los usuarios que confiaron sus datos a StockX. Cuanto mayor sea el número de personas que confirmen que su información era válida, mayores serán las posibilidades de que los datos sean auténticos.

Dado que no podemos verificar legalmente si una cuenta StockX era válida iniciando sesión con la contraseña de una persona sin su permiso (incluso si la contraseña no estaba codificada y era inutilizable), TechCrunch tuvo que contactar a los usuarios para preguntarles directamente.

Por lo general, buscamos personas que sabemos que podemos contactar rápidamente y responder al instante, por ejemplo, a través de una aplicación de mensajería. Aunque la filtración de datos de StockX contenía sólo direcciones de correo electrónico de clientes, estos datos seguían siendo útiles ya que algunas aplicaciones de mensajería, como iMessage de Apple, permiten direcciones de correo electrónico en lugar de un número de teléfono. (Si tuviéramos números de teléfono, podríamos haber intentado contactar a las víctimas potenciales enviando un mensaje de texto). Como tal, utilizamos una cuenta de iMessage configurada con un @techcrunch.com dirección de correo electrónico para que las personas con las que nos comunicábamos supieran que la solicitud realmente provenía de nosotros.

Dado que esta es la primera vez que los clientes de StockX con los que contactamos se enteraron de esta infracción, la comunicación tenía que ser clara, transparente y explicativa y debía requerir poco esfuerzo para que los destinatarios respondieran.

Enviamos mensajes a docenas de personas cuyas direcciones de correo electrónico utilizadas para registrar una cuenta StockX eran @icloud.com o @me.com, que comúnmente están asociados con cuentas de Apple iMessage. Al usar iMessage, también pudimos ver que los mensajes que enviamos fueron «entregados» y, en algunos casos, dependiendo de la configuración de la persona, decía si el mensaje fue leído.

Los mensajes que enviamos a las víctimas de StockX incluían quiénes éramos («Soy un reportero en TechCrunch») y el motivo por el que nos comunicábamos («Encontramos su información en una violación de datos aún no reportada y necesitamos su ayuda». verificar su autenticidad para que podamos notificar a la empresa y a otras víctimas”). En el mismo mensaje, presentamos información que solo ellos podían conocer, como su nombre de usuario y talla de zapato, que estaba asociada con la misma dirección de correo electrónico a la que enviamos el mensaje. (“¿Es usted un usuario de StockX con [username] y [shoe size]?”). Elegimos información que fuera fácilmente confirmable pero nada demasiado sensible que pudiera exponer aún más los datos privados de la persona si los leyera otra persona.

Al escribir mensajes de esta manera, estamos generando credibilidad ante una persona que puede no tener idea de quiénes somos o que puede ignorar nuestro mensaje sospechando que se trata de algún tipo de estafa.

Enviamos mensajes personalizados similares a docenas de personas y recibimos respuesta de una parte de aquellos con quienes contactamos y con quienes hicimos un seguimiento. Por lo general, un tamaño de muestra seleccionado de alrededor de diez o una docena de cuentas confirmadas sugeriría datos válidos y auténticos. Cada persona que nos respondió confirmó que su información era precisa. TechCrunch presentó los hallazgos a StockX, lo que llevó a la compañía a intentar adelantarse a la historia revelando la violación masiva de datos en un comunicado en su sitio web.

Cómo descubrimos que los datos de usuario filtrados de 23andMe eran genuinos

Al igual que StockX, el reciente incidente de seguridad de 23andMe provocó un restablecimiento masivo de la contraseña en octubre de 2023. A 23andMe le tomó otros dos meses confirmar que los piratas informáticos habían extraído datos confidenciales del perfil de 6,9 ​​millones de clientes de 23andMe directamente de sus servidores: datos de aproximadamente la mitad de todos los clientes de 23andMe. .

TechCrunch descubrió con bastante rapidez que los datos extraídos de 23andMe probablemente eran genuinos y, al hacerlo, se enteró de que los piratas informáticos habían publicado partes de los datos de 23andMe dos meses antes, en agosto de 2023. Lo que resultó más tarde fue que el raspado comenzó meses antes, en abril de 2023, pero 23andMe no se dio cuenta hasta que partes de los datos extraídos comenzaron a circular en un subreddit popular.

Los primeros signos de una infracción en 23andMe comenzaron cuando un pirata informático publicó en un conocido foro de ciberdelincuencia una muestra de 1 millón de registros de cuentas de judíos asquenazíes y 100.000 usuarios de ascendencia china que utilizan 23andMe. El hacker afirmó tener a la venta el perfil de 23andMe, registros de ascendencia y datos genéticos sin procesar.

Pero no estaba claro cómo se extrajeron los datos o incluso si eran genuinos. Incluso 23andMe dijo en ese momento que estaba trabajando para verificar si los datos eran auténticos, un esfuerzo que a la compañía le llevaría varias semanas más confirmar.

La muestra de 1 millón de registros también fue formateada en una hoja de cálculo de datos separados por comas, revelando una gran cantidad de registros formateados de manera similar y ordenada, cada línea contiene un supuesto perfil de usuario de 23andMe y algunos de sus datos genéticos. No había información de contacto del usuario, solo nombres, sexo y años de nacimiento. Pero esta no fue información suficiente para que TechCrunch se comunicara con ellos para verificar si su información era precisa.

El formato preciso de los datos filtrados de 23andMe sugirió que cada registro había sido extraído metódicamente de los servidores de 23andMe, uno por uno, pero probablemente a alta velocidad y en un volumen considerable, y organizado en un solo archivo. Si el pirata informático hubiera irrumpido en la red de 23andMe y hubiera «desechado» una copia de la base de datos de usuarios de 23andMe directamente desde sus servidores, los datos probablemente se presentarían en un formato diferente y contendrían información adicional sobre el servidor en el que estaban almacenados.

Una cosa se destacó inmediatamente de los datos: cada registro de usuario contenía una cadena aparentemente aleatoria de 16 caracteres de letras y números, conocida como hash. Descubrimos que el hash sirve como un identificador único para cada cuenta de usuario de 23andMe, pero también sirve como parte de la dirección web del perfil del usuario de 23andMe cuando inicia sesión. Lo comprobamos nosotros mismos creando una nueva cuenta de usuario de 23andMe y buscando nuestro hash de 16 caracteres en la barra de direcciones de nuestro navegador.

También descubrimos que muchas personas en las redes sociales tenían tweets históricos y publicaciones que compartían enlaces a sus páginas de perfil de 23andMe, cada uno con el identificador hash único del usuario. Cuando intentamos acceder a los enlaces, fuimos bloqueados por un muro de inicio de sesión de 23andMe, presumiblemente porque 23andMe había solucionado cualquier falla que había sido explotada para supuestamente exfiltrar grandes cantidades de datos de cuentas y borrado todos los enlaces públicos para compartir en el proceso. En este punto, creíamos que los hashes de usuario podrían ser útiles si pudiéramos comparar cada hash con otros datos en Internet.

Cuando ingresamos un puñado de hash de cuentas de usuario de 23andMe en los motores de búsqueda, los resultados arrojaron páginas web que contenían una gran cantidad de datos de ascendencia coincidentes publicados años antes en sitios web administrados por aficionados a la genealogía y la ascendencia que documentan sus propias historias familiares.

En otras palabras, algunos de los datos filtrados ya se habían publicado parcialmente en línea. ¿Podrían ser datos antiguos procedentes de violaciones de datos anteriores?

Uno por uno, los hashes que verificamos a partir de los datos filtrados coincidían perfectamente con los datos publicados en las páginas de genealogía. La clave aquí es que los dos conjuntos de datos tenían un formato algo diferente, pero contenían suficiente información única del usuario (incluidos los hashes de la cuenta del usuario y los datos genéticos coincidentes) para sugerir que los datos que verificamos eran datos auténticos del usuario de 23andMe.

En este punto, estaba claro que 23andMe había experimentado una gran filtración de datos de clientes, pero no pudimos determinar con seguridad qué tan recientes o nuevos eran estos datos filtrados.

Un aficionado a la genealogía a cuyo sitio web hicimos referencia para buscar los datos filtrados le dijo a TechCrunch que tenían alrededor de 5,000 parientes descubiertos a través de 23andMe documentados meticulosamente en su sitio web, de ahí que algunos de los registros filtrados coincidieran con los datos del aficionado.

Las filtraciones no cesaron. Otro conjunto de datos, supuestamente sobre 4 millones de usuarios británicos de 23andMe, se publicó en línea en los días siguientes, y repetimos nuestro proceso de verificación. El nuevo conjunto de datos publicados contenía numerosas coincidencias con los mismos datos publicados anteriormente. Estos también parecían ser datos auténticos de usuarios de 23andMe.

Y eso es lo que informamos. En diciembre, 23andMe admitió que había experimentado una gran filtración de datos atribuida a una extracción masiva de datos.

La compañía dijo que los piratas informáticos utilizaron su acceso a alrededor de 14.000 cuentas de 23andMe secuestradas para extraer grandes cantidades de cuentas y datos genéticos de otros usuarios de 23andMe que optaron por una función diseñada para relacionar a familiares con ADN similar.

Si bien 23andMe intentó culpar de la violación a las víctimas cuyas cuentas fueron secuestradas, la compañía no explicó cómo ese acceso permitió la descarga masiva de datos de millones de cuentas que no fueron pirateadas. 23andMe ahora enfrenta docenas de demandas colectivas relacionadas con sus prácticas de seguridad antes de la violación.

Cómo confirmamos que EE.UU. . Los correos electrónicos militares se difundían en línea desde una nube del gobierno.

A veces, la fuente de una filtración de datos (incluso una divulgación involuntaria de información personal) no es un archivo compartible repleto de datos de usuario. A veces, el origen de una infracción está en la nube.

La nube es un término elegante para referirse a “la computadora de otra persona”, a la que se puede acceder en línea desde cualquier parte del mundo. Eso significa que las empresas, organizaciones y gobiernos almacenarán sus archivos, correos electrónicos y otros documentos del lugar de trabajo en vastos servidores de almacenamiento en línea a menudo administrados por un puñado de gigantes de las grandes tecnologías, como Amazon, Google, Microsoft y Oracle. Y, para sus clientes altamente sensibles, como gobiernos y militares, las empresas de nube ofrecen nubes separadas, segmentadas y altamente fortificadas para una protección adicional contra los espías y piratas informáticos más dedicados y con más recursos.

En realidad, una filtración de datos en la nube puede ser tan simple como dejar un servidor en la nube conectado a Internet sin contraseña, permitiendo que cualquier persona en Internet acceda a cualquier contenido almacenado en su interior.

Sucede, y más de lo que piensas. ¡La gente realmente los encuentra! Y algunas personas son realmente buenas en eso.

Anurag Sen es un investigador de seguridad de buena fe conocido por descubrir datos confidenciales publicados por error en Internet. Ha encontrado numerosos derrames de datos a lo largo de los años al buscar en la web nubes con fugas con el objetivo de repararlas. Es algo bueno y se lo agradecemos.

Durante el fin de semana feriado federal del Día de los Presidentes en febrero de 2023, Sen se comunicó con TechCrunch, alarmado. Encontró lo que parecían contenidos confidenciales de correos electrónicos militares estadounidenses difundidos en línea desde la nube dedicada de Microsoft para el ejército estadounidense, que debería estar altamente segura y bloqueada. Los datos que se derraman desde una nube gubernamental no es algo que se vea con mucha frecuencia, como una ráfaga de agua que sale disparada de un agujero en una presa.

Pero en realidad, alguien, en algún lugar (y de alguna manera) eliminó una contraseña de un servidor en esta nube supuestamente altamente fortificada, abriendo efectivamente un enorme agujero en las defensas de este servidor en la nube y permitiendo que cualquier persona en la Internet abierta se sumerja digitalmente y examine los datos que contiene. Fue un error humano, no un ataque malicioso.

Si Sen tenía razón y estos correos electrónicos resultaban ser correos electrónicos militares estadounidenses genuinos, teníamos que actuar rápidamente para asegurarnos de que la filtración se tapara lo antes posible, por temor a que alguien nefasto encontrara pronto los datos.

Sen compartió la dirección IP del servidor, una cadena de números asignados a su ubicación digital en Internet. Al utilizar un servicio en línea como Shodan, que cataloga automáticamente las bases de datos y los servidores que se encuentran expuestos a Internet, fue fácil identificar rápidamente algunas cosas sobre el servidor expuesto.

Primero, la lista de Shodan para la dirección IP confirmó que el servidor estaba alojado en la nube Azure de Microsoft específicamente para clientes militares de EE. UU. (también conocido como «usdodeast“). En segundo lugar, Shodan reveló específicamente qué aplicación en el servidor se estaba filtrando: un motor Elasticsearch, a menudo utilizado para ingerir, organizar, analizar y visualizar grandes cantidades de datos.

Aunque las bandejas de entrada del ejército estadounidense eran seguras, parecía que la base de datos de Elasticsearch encargada de analizar estas bandejas de entrada era insegura y, sin darse cuenta, filtraba datos de la nube. La lista de Shodan mostró que la base de datos de Elasticsearch contenía alrededor de 2,6 terabytes de datos, el equivalente a docenas de discos duros repletos de correos electrónicos. Para aumentar la sensación de urgencia de proteger la base de datos, se puede acceder a los datos dentro de la base de datos de Elasticsearch a través del navegador web simplemente escribiendo la dirección IP del servidor. En definitiva, estos correos electrónicos militares fueron increíblemente fáciles de encontrar y acceder a cualquier persona en Internet.

En este punto, nos aseguramos de que era casi seguro que se trataba de datos reales de correo electrónico militar estadounidense que se derramaban desde una nube del gobierno. Pero el ejército estadounidense es enorme y revelar esto iba a ser complicado, especialmente durante un fin de semana festivo federal. Dada la posible sensibilidad de los datos, tuvimos que descubrir rápidamente a quién contactar y hacer de esto su prioridad, y no dejar correos electrónicos con información potencialmente confidencial en una bandeja de entrada sin rostro y sin garantía de obtener una respuesta.

Sen también proporcionó capturas de pantalla (¡un recordatorio para documentar sus hallazgos!) que muestran correos electrónicos expuestos enviados desde varios dominios de correo electrónico militares de EE. UU.

Dado que se puede acceder a los datos de Elasticsearch a través del navegador web, los datos que contienen se pueden consultar y visualizar de varias maneras. Esto puede ayudar a contextualizar los datos con los que está tratando y proporcionar pistas sobre su posible propiedad.

Por ejemplo, muchas de las capturas de pantalla que Sen compartió contenían correos electrónicos relacionados con @socom.milo Comando de Operaciones Especiales de EE. UU., que lleva a cabo operaciones militares especiales en el extranjero.

Queríamos ver cuántos correos electrónicos había en la base de datos sin mirar su contenido potencialmente confidencial y utilizamos las capturas de pantalla como punto de referencia.

Al enviar consultas a la base de datos dentro de nuestro navegador web, utilizamos el parámetro de “recuento” incorporado de Elasticsearch para recuperar la cantidad de veces que una palabra clave específica (en este caso, un dominio de correo electrónico) se comparó con la base de datos. Utilizando esta técnica de conteo, determinamos que el dominio de correo electrónico «socom.mil”fue mencionado en más de 10 millones de entradas de bases de datos. Según esa lógica, dado que SOCOM se vio significativamente afectado por esta filtración, debería asumir cierta responsabilidad en la reparación de la base de datos expuesta.

Y ese es con quien contactamos. La base de datos expuesta fue asegurada al día siguiente y nuestra historia se publicó poco después.

Al ejército estadounidense le llevó un año revelar la filtración, notificando a unos 20.000 militares y otras personas afectadas sobre la filtración de datos. No está claro exactamente cómo se hizo pública la base de datos. El Departamento de Defensa dijo que el proveedor (Microsoft, en este caso) “resolvió los problemas que resultaron en la exposición”, sugiriendo que el derrame era responsabilidad de Microsoft. Por su parte, Microsoft aún no ha reconocido el incidente.

Para contactar a este reportero, o compartir datos violados o filtrados, puede ponerse en contacto en Signal y WhatsApp al +1 646-755-8849, o por correo electrónico. También puede enviar archivos y documentos a través de SecureDrop.