👻 La Newsletter de @weareDMNTRs 👻
Esta semana han hackeado Air Europa.
Y digo esta semana por decir algo, porque con los datos que tenemos no sabemos ni cuando se produjo el incidente ni cuanto tiempo duró.
Lo único claro es que la aerolínea está aconsejando a muchos de sus clientes cancelar sus tarjetas de crédito, ya que los datos de las mismas podrían haber sido comprometidos, por lo que podrían ser utilizados por "los malos" para "cositas". "Cositas" de esas que no nos suelen gustar.
Y entre estos datos se incluye el CVV de las tarjetas. Guárdate este dato. Que es importante.
Obviamente, cuando algo así sucede, el "universo twittero IT" se revoluciona. Comenzamos a hacer teorías, a cagarnos en todo lo cagable, a pensar en conspiraciones, en sobornos, otros se ponen a asustar viejas... ¡Cada uno a lo que se le da bien, básicamente!
Pero esta vez hubo algo que, para mí, fue curioso. Muy curioso. Y por ello, hoy, la intro de esta newsletter, se convierte en el "informe forense imaginario" más desenfadado de la historia.
Acompáñame para que juntos intentemos ver que ha pasado en Air Europa, como ha podido pasar y como podemos protegernos de algo así.
¿Te apuntas?
¡Comenzamos!
Air Europa es una compañía aérea española con sede en Mallorca, fundada en 1984. Desde sus inicios ha sido una empresa con un crecimiento brutal, de hecho, es la principal aerolínea con capital español actualmente.
En 2018 ya tuvo un incidente de seguridad, por el que incluso fue multada con 600.000€ por la Agencia Española de Protección de Datos. Exactamente, fueron 500.000 euros por la negligencia y 100.000 euros más por notificar el incidente a la AEPD con 41 días de retraso.
Desde entonces no se han conocido más incidentes reseñables de este tipo, lo que nos lleva pensar que en estos 5 años la empresa se puso las pilas.
Con esa idea en mente, Air Europa obtuvo en 2020 la certificación PCI-DSS, o "Payment Card Industry Data Security Standard". O sea la certificación "TOP" para empresas que procesan, guardan o transmiten datos de tarjetas de crédito o débito.
Y claro, en cuanto ese dato se puso sobre la mesa, llego la movida twittera: ¡COMO UNA EMPRESA CON EL PCI-DSS HA PODIDO SER VULNERADA! ¡ES QUE DAN LAS CERTIFICACIONES A CUALQUIERA! ¡TODO ESTÁ CORRUPTO! ¡VAMOS A MORIR TODOS! ¡QUE LLEGUE YA EL METEORITO!
Tengo la suerte de conocer a una persona que trabajaba en Air Europa y que estuvo presente en el proceso de la certificación de la empresa con PCI-DSS. Y me cuenta que la empresa cumplía todos los requisitos y procesos.
Además, me recordaba que cada año hay que pasar auditorías externas para asegurar que todas esas medidas se mantienen en el tiempo.
Si conoces un poco el tema de certificaciones de este tipo, ya sabrás que esto, normalmente, NO va de "me saco la certificación y al día siguiente hago lo que quiero".
Y solo meto lo de "normalmente" porque he visto algún cachondeo guapo con alguna ISO, pero al final costaba más el "simular" que se hacía bien a hacerlo bien.
Así que, si desde la barrera todo parece estar correcto, ¿cómo ha podido pasar esto? ¿Qué se nos escapa?
Vamos a plantear algunas hipótesis, pero antes veamos los datos de los que disponemos:
En primer lugar, si echas un vistazo a los requisitos genéricos de la PCI-DSS, verás que exige una alta exigencia en cuanto a seguridad, privacidad, mantenimiento del sistema, encriptación y demás.
Solo viendo el PDF de la norma se me ponen los pelos de punta de pensar el mogollón de documentación, testeo y acciones de corrección que habrá que aplicar a cualquier sistema para llegar a pasarla.
PCI-DSS aplica unos 300 controles de seguridad. La documentación oficial consta de más de 1800 páginas, de las que 360 son solo para entender qué formularios hay que utilizar para garantizar el cumplimiento.
¡Necesitarías más de 72 horas a buen ritmo de lectura solo para leer la normativa al completo! ¡Una puta locura!
POR TANTO, tiendo a pensar que, a pesar de que a muchos os gusten las teorías de la conspiración, Air Europa estaba al menos intentando hacer las cosas bien. No es posible ni rentable falsear una certificación como PCI-DSS.
Además, hay un dato básico en la norma PCI-DSS que nos va a permitir lanzar nuestra "teoría del incidente": los códigos CVV no se pueden almacenar. Ni cifrados ni no cifrados. ¡No puedes guardarlos de ninguna manera!
Operativamente, lo que se hace normalmente es trabajar con un procesador de pagos (Stripe, Adyen, Worldpay, FIS, etc) de manera que tu sistema solo ve los últimos dígitos de la tarjeta y recibe un token para referenciarla. ¡Tú no almacenas ningún dato de la tarjeta!
...
🤔-"¿Pero si tienen la PCI-DSS porque trabajan con un procesador de pagos y no lo hacen ellos directamente?
👻-"Pues porque hay una máxima de "zapatero a tus zapatos". El procesador de pagos tienen acuerdos con multitud de bancos y te permite, a un coste contenido, procesar los pagos de las tarjetas sin que tú tengas que desarrollar un departamento para ellos. ¡Es que no tendría sentido montarte tu el tema directamente!"
🤔-"¿Y entonces para qué quieren PCI-DSS?"
👻-"Pues porque cuando llegas a cierto nivel es "casi" obligatoria para que los procesadores de pagos te dejen trabajar con ellos. Mira por ejemplo, aquí STRIPE te lo explica: https://stripe.com/es/guides/pci-compliance ¡E incluso te ayuda con la certificación!"
...
¡Sigamos!
Echando un vistacito a la Política de Privacidad de la web de Air Europa, vemos a World Pay en la sección de colaboradores etiquetado como "Procesador de Pagos", por lo que deben de trabajar con ellos, lo que refuta nuestra teoría.
¡Y aquí ya podemos descartar muchas cosas!
Si, según creemos, los datos de tarjetas NO se almacenan en los sistemas propios de Air Europa, podemos descartar multitud de ataques, tipo ransomware, escalada de accesos a su base de datos, robo de backups o similares, ya que aunque hayan tenido acceso la base de datos, no tendrían acceso al CVV ni al número de tarjeta.
"Como mucho" con esos ataques podrían haber parado la operativa de la empresa, robado datos de carácter personal o información de vuelos de clientes o de empleados, pero nada de tarjetas. ¡Debe haber sido otra cosa!
De hecho, desde una web especializada apuntaban a una teoría sobre DNS-hijacking, pero la creo descartada, ya que los certificados SSL hubieran cantado por soleares... ¡A no ser que alguien hubiera tenido acceso para generar los SSL! Me parecería demasiado loco...
Así que si seguimos tirando de nuestra "cuerda imaginaria"... ¿Qué ha podido pasar? 🤔🤔🤔
A ver, MI TEORÍA, que surge después de darle muchas vueltas al proceso de reserva de vuelos en la web de Air Europa, parte de que el único momento donde metes los datos críticos (número de tarjeta, fecha de caducidad y CVV) es cuando vas a realizar el pago.
¡Ni antes ni después!
Y, obviamente, ese sería el lugar perfecto para robarlos... ¡Porque recuerda que esos datos no se almacenan! ¡Ya que una vez pasan al procesador de pagos tú solo almacenas un token!
Por tanto, el posible atacante, que habrá estudiado a Air Europa bastante más que yo, también tendría esto muy claro.
Así que vamos a plantear un posible escenario:
El malo consigue acceso a la red de Air Europa. Sea vía phising, ingeniería social, vía alguna política del firewall mal diseñada, una VPN perdida o por donde sea.
Una vez dentro, su objetivo será modificar la página web, ya que si consigue "colocarse en medio", modificando por ejemplo los javascripts que se lanzan en el momento donde se envían los datos al procesador de pagos, podrá recopilar toda la información confidencial que quiera.
Este tipo de ataque es conocido como Web skimming y, me inclino a pensar, que debe ser lo más parecido a lo que ha pasado en realidad.
Normalmente, los datos recopilados se guardarán en la misma red comprometida, para que no canté demasiado el tema.
...
🤔-"Pero Dementor tío, en cuanto envíes fuera de la red de Air Europa el primer dato, el sistema te va a detectar y todo saltará por los aires."
👻-"Cierto... Pero..."
...
Podrías enmascarar esa conexión externa, realizándola en el servidor comprometido y no en el javascript de la web...
O enviarlo junto con otros datos "tipicals" a un correo corporativo previamente comprometido para que el tema no cante demasiado...
O incluso recopilar todos los datos, almacenarlos en el servidor al que se ha ganado acceso, sin enviarlos a ningún lado, y lanzarlos fuera una vez el número de tarjetas supere cierto límite.
Obviamente, en ese momento, si la red está bien configurada, saltarían las alarmas, pero el atacante ya se habría llevado un gran número de tarjetas y su objetivo estaría conseguido.
¡Sea como fuere, la empresa, tendrá encima un marrón de enormes proporciones, que provocará hasta que cierto chalado les haga este "análisis forense imaginario"! 🤪🤪🤪
...
🤔-"¡Vaya tochaco te ha salido!"
👻-"¡Ya te digo! ¡Y esto un domingo por la mañana!"
...
La pregunta que muchos os estaréis haciendo es: ¿Y cómo podemos protegernos de algo así?
En primer lugar, lo de siempre: tu red, tu castillo. Para llegar a realizar el ataque han comprometido algo de nuestra red, así que debemos intentar tener una imagen clara de que está pasando en la misma, de arriba a abajo. Y eso implica gastar pasta en ciberseguridad. No nos vale tener un NGFW y ya está, hay que seguir avanzando.
En segundo lugar, no sería mala idea empezar a auditar automáticamente las zonas de código donde se tratan los datos de carácter crítico (suponiendo que el tema de cambiar cosas en los mismos y subir a producción ya lo tenemos controlado...), de manera que realicemos una comprobación rutinaria cada poco tiempo (minutos, horas) de los mismos. En algunos sitios usan MD5 Checksum o sistemas similares. Todo es poco.
Y lo tercero es lo que digo siempre: NO SE LIBRA NADIE, ASÍ QUE PROTÉGETE TÚ.
Por ejemplo, usa una tarjeta virtual recargable para tus compras on-line, que sí, que es un coñazo supino, pero si pasan cositas de este tipo, en empresas certificadas, auditadas y superprotegidas, imagínate en otros lugares...
Y nada, hasta aquí el "tocho" este que me ha salido, espero que te pueda ser útil.
¡Feliz Domingo!
📷 La imagen de la semana 📷
Esta semana estuve en el evento que anualmente organiza Fortinet con sus partners. A pesar de no ser un evento técnico, me quedo con varias conversaciones que pude mantener y algunas nuevas vías de servicio que estamos explorando para DMNTR Network Solutions y zeroset.
¡Seguimos!
🔗 Cajón desastre... 🔗
Vamos con los enlaces, que tengo muchas cosas que dejaros por aquí:
- Se acabó la gloria para Ubiquiti, pierde 10.000 millones en bolsa. Lo mismo la política errática de producto tiene algo que ver...
- Granada, ciberatacada por un grupo de hackers rusos tras la visita de Zelenski. Si pudiera contar cosas que no puedo contar...
- EE.UU tiene miedo de que China decida crear chips con la arquitectura RISC-V. ¿Y de qué no tiene miedo USA?
- Scarleteel 2.0 and the MITRE ATT&CK framework. Jodidamente interesante...
- OpenFlow y SDN. ¡Vaya ritmazo de contenido que nos está dando Eduardo Collado desde hace un tiempo! ¡Chapeau!
- Un CEO prueba ChatGPT y termina despidiendo a todo su equipo de atención al cliente. ¿Y a los comerciales? ¿A esos no los podemos despedir?
- La tecnología sin servidor lidera el gasto empresarial en computación cloud nativa. "Sin servidor". "Invisible". "Magia". "Humo".
- Homepages of major technology companies in 1995. Todavía no conocían el modo texto...
- Todavía estáis a tiempo de participar en el ESNOG: https://www.eventbrite.es/e/entradas-esnog-30-evento-hibrido-en-barcelona-los-dias-26-y-27-de-octubre-725984869287
- ‘HTTP/2 Rapid Reset’ Zero-Day Exploited to Launch Largest DDoS Attacks in History. Y lo que nos quedará por ver...
Y fin...
¡Creo que ha quedado la newsletter más larga hasta ahora! ¡Espero vuestro feedback!
Vamos a disfrutar de lo que nos queda de finde, que viene un achuchón gordo de trabajo estas próximas semanas.
Y nada, sigo a mis cosas. ¡Nos vemos en Twitter o en Telegram !
¿Como que forense? ¿Pero ahora es que analiza cadáveres o que hace este tío?
