- En el flujo de autenticación KCM/CASS de la TSA, si se comprometía el sistema de una aerolínea, se podía agregar a usuarios arbitrarios como si hubieran pasado la verificación de empleo, lo que podía llevar a evadir el control de seguridad e incluso acceder a la cabina
- FlyCASS ofrecía una interfaz web de CASS para aerolíneas pequeñas, y una inyección SQL en la página de inicio de sesión de Air Transport International permitía iniciar sesión como administrador
- La pantalla de administración podía otorgar permisos de KCM y CASS al agregar nuevos empleados sin verificación adicional, y un usuario de prueba aparecía como aprobado en ambos sistemas
- Después de la divulgación a ARINC, la FAA y DHS/CISA a finales de abril de 2024, DHS confirmó que FlyCASS fue separado de KCM/CASS, pero no respondió a las solicitudes de corrección sobre la explicación de la TSA
- La TSA afirmó que no era posible acceder al checkpoint porque hay una revisión antes de emitir un código de barras KCM, pero el proceso real aún permitía la entrada manual del ID de empleado, por lo que el impacto de la vulnerabilidad era mayor
Qué verifican KCM y CASS
- Known Crewmember (KCM) es un programa de la TSA que permite a pilotos y tripulantes evadir el control de seguridad incluso durante viajes personales dentro del país
- El empleado presenta un código de barras KCM en una fila exclusiva o le da a un agente de la TSA su número de empleado y su aerolínea
- La laptop del agente de la TSA consulta con la aerolínea el estado laboral y, si la verificación tiene éxito, ese empleado puede entrar a la zona segura sin una inspección adicional
- Cockpit Access Security System (CASS) es un sistema aparte que verifica la autorización para acceder a la cabina
- La mayoría de los aviones tienen un jumpseat dentro de la cabina, detrás de los pilotos
- Cuando un piloto se traslada o viaja y no puede usar fácilmente un asiento pagado, puede usar el jumpseat
- El personal de puerta usa CASS para verificar si quien usará el jumpseat es un piloto autorizado y puede informar a la tripulación que la autenticación CASS fue confirmada
- El punto clave de ambos procesos es la verificación del empleo actual en la aerolínea
- Si alguien no es empleado de la aerolínea, no está cubierto por la revisión de antecedentes, por lo que no debería permitírsele evadir seguridad ni acceder a la cabina
- También se devuelve una foto del tripulante para confirmar que la persona aprobada es la correcta
ARINC y los sistemas de autenticación de cada aerolínea
- ARINC es una subsidiaria de Collins Aerospace y parece encargarse de operar KCM por parte de la TSA
- ARINC opera componentes centrales como un sitio web donde pilotos y tripulantes consultan su estado en KCM, y una API que enruta solicitudes de autorización entre aerolíneas
- Cada aerolínea parece operar su propio sistema de autenticación para participar en KCM y CASS, y este sistema interactúa con el hub de ARINC
- La TSA y las aerolíneas pueden enviar solicitudes como
CockpitAccessRequestyCrewVerificationRequesta ARINC - ARINC enruta la solicitud al sistema de la aerolínea correspondiente y recibe la respuesta
- La TSA y las aerolíneas pueden enviar solicitudes como
- Actualmente 77 aerolíneas participan en KCM
- Es posible que las grandes aerolíneas hayan creado sus propios sistemas, pero la investigación se enfocó en cómo las aerolíneas pequeñas respondían a solicitudes de KCM o CASS
La inyección SQL descubierta en FlyCASS
- Los investigadores encontraron el sitio FlyCASS mientras buscaban al proveedor que realmente operaba los sistemas de autenticación
- FlyCASS ofrecía una interfaz web basada en navegador para CASS destinada a aerolíneas pequeñas
- Cada aerolínea tenía una página de inicio de sesión separada, y Air Transport International (8C) podía accederse en
/ati
- Al ingresar una comilla simple en el nombre de usuario, el sistema devolvía de inmediato un error de MySQL
- Eso sugería que el nombre de usuario se insertaba directamente en la consulta SQL de inicio de sesión
- Con sqlmap se confirmó el problema de inyección SQL
- Con la combinación de nombre de usuario
' or '1'='1y contraseña') OR MD5('1')=MD5('1se podía iniciar sesión en la cuenta de administrador de Air Transport International
Agregar usuarios aprobados para KCM/CASS con privilegios de administrador
- FlyCASS operaba tanto KCM como CASS para las aerolíneas participantes
- Tras obtener privilegios de administrador de Air Transport International, era posible gestionar la lista de pilotos y tripulantes vinculados a esa aerolínea
- Al agregar un nuevo empleado a la aerolínea, no había ninguna verificación o autenticación adicional
- Un administrador de la aerolínea podía agregar a cualquiera como usuario aprobado para KCM y CASS
- Como prueba, se creó un empleado llamado
Test TestOnly, se le asignó una foto de prueba seleccionada y se le otorgó acceso a KCM y CASS- Luego, al verificar con la función Query, el usuario de prueba aparecía como aprobado tanto en KCM como en CASS
- Bastaba conocimiento básico de inyección SQL para iniciar sesión en el sitio y agregar usuarios arbitrarios a KCM y CASS
- En consecuencia, esto podía permitir saltarse el control de seguridad e incluso acceder a la cabina de aviones comerciales de pasajeros
- El proceso de divulgación comenzó justo después de descubrir el primer problema, y además se encontraron varios otros fallos graves
Proceso de divulgación y respuesta de la TSA
- Incluso encontrar un contacto adecuado para la divulgación no fue sencillo
- Como FlyCASS parecía ser operado por una sola persona, no querían contactar directamente a FlyCASS desde el principio y tomarlo por sorpresa
- El 23 de abril de 2024 se divulgó el problema al Department of Homeland Security, y DHS confirmó que estaba al tanto y que lo estaba “tomando muy en serio”
- Después, FlyCASS fue desactivado de KCM/CASS y más tarde parece que el problema fue corregido
- Una vez corregido el problema, se intentó coordinar una divulgación segura, pero DHS dejó de responder
- La oficina de prensa de la TSA emitió una explicación negando el impacto de la vulnerabilidad
- La TSA dijo que no era posible acceder a un checkpoint KCM con esta vulnerabilidad porque el proceso de revisión comienza antes de emitir un nuevo código de barras KCM
- Sin embargo, el código de barras KCM no es obligatorio para usar un checkpoint KCM, ya que un TSO puede ingresar manualmente el ID del empleado y la aerolínea
- Después de que los investigadores informaran esto a la TSA, la TSA eliminó la sección de su sitio web que mencionaba el ingreso manual del ID de empleado y no respondió a la solicitud de corrección
- Se confirmó que la interfaz usada por los TSO aún permite ingresar manualmente el ID de empleado
Ataques adicionales posibles y cronología de la divulgación
- Como la vulnerabilidad permitía modificar miembros KCM existentes, también era posible cambiar la foto y el nombre de usuarios ya registrados
- Este método podía permitir eludir el proceso de revisión de nuevos miembros, incluso si dicho proceso existía
- Si se podía obtener un código de barras KCM no registrado, también era posible registrarlo directamente a un ID de empleado desde el sitio web de KCM
- Cronología de la divulgación:
- 2024-04-23: divulgación inicial a ARINC y la FAA
- 2024-04-24: divulgación adicional a DHS a través de CISA
- 2024-04-25: el CISO de DHS confirma que se estaba trabajando en la mitigación
- 2024-05-07: el CISO de DHS confirma que FlyCASS fue separado de KCM/CASS
- 2024-05-17: seguimiento con el CISO de DHS sobre la explicación de la TSA, sin respuesta
- 2024-06-04: nuevo seguimiento con el CISO de DHS sobre la explicación de la TSA, sin respuesta
1 comentarios
Opiniones de Hacker News
Aquí, la respuesta de la TSA es de un nivel infantil y vergonzoso, pero no sorprende si se piensa que es una organización con poco interés real en la seguridad.
Al principio, parece que el DHS manejó el reporte de forma rápida y profesional, pero es interesante que después no haya logrado mantener hasta el final la autoridad superior sobre el proceso de corrección y divulgación.
He visto cómo problemas graves, como claves expuestas, se tratan como algo menor, mientras que asuntos como bibliotecas JavaScript antiguas o la falta de soporte para IPv6 se escalan.
Está claro que la TSA y sus socios intentan minimizar la posible exposición, pero probablemente a muchos gerentes les cuesta entender el significado de las vulnerabilidades, y los desarrolladores también están reduciendo su propia responsabilidad y echando la culpa a otros.
En la práctica, parece que el objetivo es consolidar un sistema de vigilancia y construir una apariencia de fuerza.
No se limitaron a confirmar la inyección SQL: incluso crearon un registro de empleado falso, así que resulta impactante que Homeland Security no haya ido a arrestar a los involucrados.
Pensaba que Homeland Security sería el lugar con más probabilidades de confundir una divulgación responsable con hacking malicioso y llamarlo así.
Eso me impresiona más que la incompetencia de la vulnerabilidad en sí.
Si se hubieran agregado a Known Crewmember y de verdad hubieran evitado el control del aeropuerto, entonces sí habrían terminado en prisión.
Entonces los mejores talentos de otros países menos amistosos los revisarán en su lugar, y es poco probable que ellos divulguen de forma responsable.
https://bugcrowd.com/engagements/dhs-vdp
Como ya tienen una relación desde hace años, supongo que están algo familiarizados. La TSA en sí puede estar menos familiarizada, pero dado que el DHS opera una política de divulgación de vulnerabilidades (VDP) para todo el departamento y, a través de CISA, asesora a otros departamentos sobre cómo operar VDP, no creo que vayan a pedirle al DOJ que presente cargos.
Aunque quizá estoy siendo demasiado optimista.
Así se puede reducir el riesgo de ser procesado por una divulgación responsable.
Una forma más segura es enviar el informe de manera anónima y fijar un plazo claro para la divulgación o la divulgación completa, aunque en ese caso, por supuesto, es difícil recibir crédito como descubridor.
Es tan grave que, al momento de escribir esto, nadie está hablando de lo malo que es almacenar contraseñas con MD5.
En este caso también queda claro que ni siquiera usaban salt, y aun con salt MD5 sería insuficiente.
Pero si con solo una solicitud se puede manipular la consulta SQL como uno quiera, qué tan bien estén almacenadas las contraseñas deja de importar demasiado.
Probablemente menos del 20% usaba salt y además un hash criptográficamente seguro, y MD5 aparecía con muchísima frecuencia.
Considerando que antes de esa entrevista ya había un filtrado considerable, la línea base general era aún peor.
La explicación de que “no contactamos primero a FlyCASS porque parecía operado por una sola persona” es difícil de creer.
Da la sensación de que sabían que el desarrollador del sitio lo corregiría de inmediato y querían que su hallazgo tuviera más impacto.
No es algo que el responsable deba arreglar en silencio y ya; hay que volver a verificar a todas las personas en la base de datos.
Si el único desarrollador lo hubiera corregido de inmediato, habría sido difícil escalar el problema a los niveles superiores para que lo arreglaran de forma sistemática.
No sé si esa reforma integral realmente ocurrirá, pero si no se escala, las probabilidades de que ocurra son aún menores.
No sorprende que hayan negado la gravedad del problema, pero sí sorprende bastante que no hayan avisado al FBI ni intentado arrestarlos.
Quizá sea un avance pequeño.
Si lo hubiera reportado directamente a la TSA, bien podría haber terminado en amenazas legales y fanfarronería.
Apostaría 50 dólares a que Ian será acusado.
Es sorprendente que algún adolescente aburrido de 17 años con una identificación falsa todavía no haya subido a TikTok un video colándose en un avión.
Inyección SQL, nada menos.
Es gracioso, aunque no tan sorprendente, que una vieja inyección SQL pueda inutilizar todo un teatro de seguridad de miles de millones de dólares al año.
Es bastante sorprendente que las aerolíneas compren software tan sensible para la seguridad a una empresa de una sola persona.
Cuando llegas a cierto punto intentando vender SaaS a la mayoría de las empresas estadounidenses, como mínimo te piden un informe de auditoría SOC2.
SOC2, como estándar de auditoría, es bastante fácil de aprobar sin observaciones importantes, pero si la empresa la maneja una sola persona, hay varios criterios que deberían encender luces rojas en el informe.
Pensaba que, si el software se integra con sistemas de acceso de la TSA, los requisitos serían mucho más estrictos que SOC2.
Todo en el backend está apenas sostenido con más cinta adhesiva que en una pequeña empresa promedio.
Puedes comprar unos cuantos aviones de pasajeros viejos, convertirlos en cargueros y ya eres una “aerolínea”.
¿Es valioso que surjan nuevas aerolíneas? ¿Deberíamos hacerlas cerrar porque todavía no tienen sistemas que toman años o décadas construir? ¿Una empresa que opera una sola ruta entre la nada y la nada con dos aviones debería pagar una fortuna por sistemas a medida pensados para grandes aerolíneas de pasajeros?
Aquí los requisitos y las auditorías no son la respuesta. El problema fundamental de diseño es que la TSA combinó la certificación de “la aerolínea XXX dice que eres empleado” con un permiso extremadamente amplio de “puedes saltarte todos los controles de seguridad en cualquier aeropuerto del país”, y ni siquiera existía una verificación básica como “¿esa aerolínea siquiera opera en este aeropuerto?”.
También me sorprendió que algo así pudiera ser tan fácil, pero la explicación posterior sobre la respuesta de la TSA es realmente muy inquietante.
La gente que hizo esto probablemente reciba una visita de Homeland Security o del FBI.
No sé qué pensaban que podían ganar.
No creo que al gobierno le importe la seguridad, pero sí es vengativo.
El método posible aquí sería comprar un boleto de una aerolínea grande, llevar un artículo prohibido en el equipaje de mano y luego, mediante una inyección SQL en un sistema FlyCASS de un tercero, agregarse a la lista Known Crew Member de una aerolínea pequeña para saltarse el control de la TSA.
¿Entonces la vulnerabilidad consiste en poder subir a un avión grande con artículos prohibidos?
Hoy en día, la mayoría de las filas de control de la TSA ni siquiera piden pase de abordar, así que en teoría podrías llevar una bomba y saltarte todo este teatro de seguridad.