SQL 인젝션을 통한 공항 보안 우회

• TSA의 KCM/CASS 인증 흐름에서 항공사 측 시스템이 뚫리면, 고용 상태 검증을 통과한 것처럼 임의 사용자를 추가해 보안검색 우회나 조종석 접근까지 이어질 수 있었음
• FlyCASS는 소형 항공사용 CASS 웹 인터페이스를 제공했고, Air Transport International 로그인 페이지의 SQL 인젝션으로 관리자 로그인이 가능했음
• 관리자 화면은 새 직원 추가 시 추가 검증 없이 KCM과 CASS 권한을 부여할 수 있어, 테스트 사용자가 두 시스템 모두에서 승인 상태로 확인됨
• 2024년 4월 말 ARINC, FAA, DHS/CISA에 공개된 뒤 DHS는 FlyCASS가 KCM/CASS에서 분리됐다고 확인했지만, TSA 설명에 대한 정정 요청에는 응답하지 않음
• TSA는 KCM 바코드 발급 전 심사 때문에 체크포인트 접근이 불가능하다고 했으나, 실제 절차에는 직원 ID 수동 입력 경로가 남아 있어 취약점 영향이 더 컸음

---

KCM과 CASS가 맡는 검증

• Known Crewmember(KCM) 는 TSA 프로그램으로, 조종사와 승무원이 국내 개인 여행 중에도 보안검색을 우회할 수 있게 함
  • 직원은 전용 라인에서 KCM 바코드를 제시하거나 TSA 직원에게 직원 번호와 항공사를 제공함
  • TSA 직원의 노트북이 항공사에 고용 상태를 확인하고, 성공하면 해당 직원은 별도 검색 없이 보안 구역에 들어갈 수 있음
• Cockpit Access Security System(CASS) 는 조종석 접근 자격을 확인하는 별도 시스템임
  • 대부분의 항공기에는 조종석 안, 비행 조종사 뒤쪽에 점프시트(jumpseat)가 있음
  • 조종사가 통근하거나 이동할 때 유상 좌석을 쓰기 어려우면 점프시트를 사용할 수 있음
  • 게이트 직원은 CASS로 점프시트 이용자가 승인된 조종사인지 확인하고, 승무원에게 CASS 인증 사실을 알릴 수 있음
• 두 절차의 핵심은 현재 항공사 고용 상태 확인임
  • 항공사 직원이 아니면 배경조사를 받은 상태가 아니므로 보안검색 우회나 조종석 접근이 허용되면 안 됨
  • 승인 대상자가 맞는지 확인하기 위해 승무원 사진도 반환함

ARINC와 항공사별 인증 시스템

• ARINC는 Collins Aerospace의 자회사이며, TSA로부터 KCM 운영을 맡은 것으로 보임
• ARINC는 조종사와 승무원이 KCM 상태를 확인하는 온라인 웹사이트와, 항공사 간 승인 요청을 라우팅하는 API 같은 중앙 구성요소를 운영함
• 각 항공사는 KCM과 CASS에 참여하기 위해 자체 인증 시스템을 운영하는 것으로 보이며, 이 시스템은 ARINC의 허브와 상호작용함
  • TSA와 항공사는 CockpitAccessRequest, CrewVerificationRequest 같은 요청을 ARINC에 보낼 수 있음
  • ARINC는 요청을 해당 항공사 시스템으로 라우팅하고 응답을 받음
• KCM에는 현재 77개 항공사가 참여 중임
  • 대형 항공사는 자체 시스템을 만들었을 가능성이 있지만, 소형 항공사가 KCM이나 CASS 요청에 어떻게 응답하는지가 조사 대상이 됨

FlyCASS에서 발견된 SQL 인젝션

• 연구자들은 인증 시스템을 실제 운영하는 벤더를 찾다가 FlyCASS라는 사이트를 발견함
  • FlyCASS는 소형 항공사에 CASS용 웹 기반 인터페이스를 제공함
  • 각 항공사는 별도 로그인 페이지를 가졌고, Air Transport International(8C)은 /ati에서 접근 가능했음
• 로그인 페이지에서 사용자명에 작은따옴표를 넣자 즉시 MySQL 오류가 반환됨
  • 사용자명이 로그인 SQL 쿼리에 직접 삽입되는 것으로 보였음
  • sqlmap으로 SQL 인젝션 문제가 확인됨
• 사용자명 ' or '1'='1과 비밀번호 ') OR MD5('1')=MD5('1 조합으로 Air Transport International의 관리자 계정에 로그인할 수 있었음

관리자 권한으로 KCM/CASS 승인 사용자 추가

• FlyCASS는 참여 항공사를 위해 KCM과 CASS 모두를 운영하고 있었음
• Air Transport International 관리자 권한을 얻자, 해당 항공사에 연결된 조종사와 승무원 목록을 관리할 수 있었음
• 새 직원을 항공사에 추가할 때 추가 확인이나 인증은 없었음
  • 항공사 관리자는 누구든 KCM과 CASS 승인 사용자로 추가할 수 있었음
• 테스트용으로 Test TestOnly라는 직원을 만들고 선택한 테스트 사진을 넣은 뒤 KCM과 CASS 접근 권한을 부여함
  • 이후 Query 기능으로 확인했을 때, 테스트 사용자는 KCM과 CASS 모두에서 승인 상태였음
• 기본적인 SQL 인젝션 지식만으로 사이트에 로그인해 임의 사용자를 KCM과 CASS에 추가할 수 있는 상태였음
  • 결과적으로 보안검색을 건너뛰고 상업용 여객기 조종석 접근까지 가능해질 수 있었음
• 첫 문제를 발견한 직후 공개 절차가 시작됐고, 그 외에도 심각한 문제가 여러 개 더 발견됨

공개 절차와 TSA의 반응

• 적절한 공개 연락처를 찾는 과정부터 쉽지 않았음
  • FlyCASS가 한 사람이 운영하는 것으로 보여, 처음부터 FlyCASS에 연락해 놀라게 하고 싶지 않았음
• 2024년 4월 23일 Department of Homeland Security에 문제가 공개됐고, DHS는 이를 인지했으며 “매우 심각하게 받아들이고 있다”고 확인함
• 이후 FlyCASS는 KCM/CASS에서 비활성화됐고, 나중에 문제가 수정된 것으로 보임
• 문제가 수정된 뒤 안전한 공개를 조율하려 했지만, DHS는 응답을 중단함
• TSA 공보실은 취약점 영향을 부인하는 설명을 냄
  • TSA는 새 KCM 회원에게 바코드를 발급하기 전에 심사 절차가 시작되므로 이 취약점으로 KCM 체크포인트에 접근할 수 없다고 했음
  • 그러나 KCM 체크포인트 이용에 KCM 바코드는 필수가 아니며, TSO가 항공사 직원 ID를 수동 입력할 수 있음
  • 연구자들이 이를 TSA에 알린 뒤, TSA는 직원 ID 수동 입력을 언급한 웹사이트 섹션을 삭제했고 정정 요청에는 응답하지 않음
  • TSO가 쓰는 인터페이스는 여전히 직원 ID 수동 입력을 허용하는 것으로 확인됨

가능했던 추가 공격과 공개 타임라인

• 취약점으로 기존 KCM 회원을 수정할 수 있었기 때문에, 기존 등록 사용자의 사진과 이름 변경도 가능했음
  • 이 방식은 신규 회원 심사 절차가 있더라도 이를 우회할 가능성이 있었음
• 등록되지 않은 KCM 바코드를 확보할 수 있다면, KCM 웹사이트에서 이를 직원 ID에 직접 등록할 수도 있었음
• 공개 타임라인:
  • 2024-04-23: ARINC와 FAA에 최초 공개
  • 2024-04-24: CISA를 통해 DHS에 추가 공개
  • 2024-04-25: DHS CISO가 해결 작업 중이라고 확인
  • 2024-05-07: DHS CISO가 FlyCASS가 KCM/CASS에서 분리됐다고 확인
  • 2024-05-17: TSA 설명에 대해 DHS CISO에 후속 연락했으나 응답 없음
  • 2024-06-04: TSA 설명에 대해 DHS CISO에 다시 후속 연락했으나 응답 없음

[GN⁺]

Hacker News 의견들

• 여기서 TSA의 대응은 유치하고 민망한 수준이지만, 실제 보안에 별 관심이 없는 조직이라는 점을 생각하면 놀랍지도 않음
  DHS는 처음에는 제보를 신속하고 전문적으로 처리한 듯한데, 이후 수정과 공개 절차에 대한 상위 권한을 끝까지 유지하지 못한 점이 흥미로움

  • 경영진, 심지어 IT 관리자도 이런 사안이 무엇을 의미하는지 완전히 이해하기는 매우 어려움
    노출된 키 같은 큰 문제가 사소하게 취급되는 반면, 오래된 JavaScript 라이브러리나 IPv6 미지원 같은 사안이 에스컬레이션되는 걸 봤음
    TSA와 협력사들이 잠재적 노출을 축소하려는 건 분명하지만, 많은 관리자들이 취약점의 의미를 이해하기 어렵고 개발자들도 자기 책임을 축소하며 남 탓을 하고 있을 가능성이 큼
  • TSA는 보안 연극이고, 보안을 제공한다기보다 보안이 있다는 환상을 주기 위해 존재함
    실제로는 감시 체계를 굳히고 강해 보이는 외형을 만드는 게 목표처럼 보임
  • DHS 중간관리자가 TSA 중간관리자에게 소리쳤고, 그 내용이 TSA 고위층에 올라간 뒤 평소 정책인 부인·회피·무시가 작동한 것 같음
  • 오히려 놀라운 건 펜테스터 집을 새벽에 급습하고, 대테러법 조항을 들이대 변호사 없이 구금하지 않았다는 점임

• 이들은 SQL 삽입을 확인하는 데서 그치지 않고 가짜 직원 레코드까지 만들었는데, Homeland Security가 관련자들을 체포하러 오지 않은 게 충격적임
  Homeland Security라면 책임 있는 공개를 악의적 해킹으로 오해하고 그렇게 부를 가능성이 가장 큰 곳이라고 봤음
  실제 취약점의 무능함보다 이 점이 더 인상적임

  • 틀린 말은 아니지만, 사진 대신 밝은 분홍색 이미지를 넣고 이름을 “Test TestOnly”로 만든 정도로 CFAA 위반 유죄를 배심원으로서 인정하기는 어려울 것 같음
    만약 본인들을 Known Crewmember에 추가하고 실제로 공항 검색을 우회했다면, 그때는 감옥에 갔을 것임
  • 책임 있는 공개에도 기소될 수 있다는 걱정이 생기는 분위기를 만들면, 이런 시스템을 들여다볼 국내 최고의 인재들이 겁먹고 물러나게 됨
    그러면 덜 우호적인 다른 나라의 최고 인재들이 대신 들여다볼 것이고, 그들이 책임 있게 공개할 가능성은 낮음
  • DHS는 공식적으로 Bugcrowd를 사용함
    https://bugcrowd.com/engagements/dhs-vdp
    몇 년째 관계가 있으니 어느 정도는 익숙할 것으로 봄. TSA 자체는 덜 익숙할 수 있지만, DHS가 부처 전체 취약점 공개 정책(VDP)을 운영하고 CISA를 통해 다른 부처에도 VDP 운영을 조언하는 상황에서 DOJ에 기소를 의뢰할 것 같지는 않음
    다만 내가 지나치게 낙관적인 것일 수도 있음
  • 독일처럼 이런 일이 흔한 나라에서는 보통 문제를 기자나 CCC 같은 비영리 단체에 알리고, 그들이 정부 기관이나 회사에 제보함
    그러면 책임 있는 공개 때문에 기소될 위험을 줄일 수 있음
    더 안전한 방법은 보고서를 익명으로 보내고 공개 또는 전체 공개의 명확한 마감일을 거는 것인데, 물론 이 경우 발견자로 인정받기는 어려움
  • 공소시효가 길고, HSI는 수사가 거의 마무리될 때까지 기소를 미루는 경우가 많음

• 너무 심각해서, 이 글을 쓰는 시점에도 아무도 MD5로 비밀번호를 저장한 문제가 얼마나 나쁜지 얘기하지 않을 정도임
  이 경우 솔트조차 쓰지 않았다는 점도 드러나는데, MD5에서는 솔트를 써도 불충분함
  하지만 요청만으로 SQL 쿼리 자체를 마음대로 헤집을 수 있다면, 비밀번호를 얼마나 잘 저장했는지는 별 의미가 없음

  • 이건 예전에 Triplebyte 면접에 거의 그대로 나오던 질문이었고, 꽤 훌륭한 엔지니어들조차 엄청나게 많이 틀렸음
    솔트를 쓰고 암호학적으로 안전한 해시까지 사용한 비율은 아마 20% 미만이었고, MD5가 정말 자주 나왔음
    이 면접 전에도 상당히 걸러낸 상태였다는 점을 생각하면 전체 기준선은 그보다 더 나쁨
  • SQL 삽입에서 md5 부분은 펜테스터가 추가한 것으로 보이며, 삽입 매개변수 안에서 괄호로 끝나는 호출이 필요했기 때문일 가능성이 큼

• “FlyCASS가 한 사람이 운영하는 것처럼 보여서 먼저 연락하지 않았다”는 설명은 믿기 어려움
  사이트 개발자가 바로 고쳐버릴 걸 알고 있었고, 자기들의 발견을 더 크게 터뜨리고 싶었던 것처럼 느껴짐

  • 이런 버그야말로 크게 터뜨려야 하는 버그임
    담당자가 조용히 고치고 끝낼 일이 아니라, 데이터베이스에 있는 모든 사람을 다시 검증해야 함
  • 동기가 무엇이든, 이렇게 흔한 버그가 들어가도록 만든 공학 프로세스가 망가져 있음
    유일한 개발자가 즉시 고쳤다면, 윗선까지 문제를 올려 체계적으로 고치게 만들기 어려웠을 것임
    그런 전면 개편이 실제로 일어날지는 모르겠지만, 에스컬레이션하지 않으면 일어날 가능성은 더 낮아짐
  • 공개 전에 침해 범위를 완전히 이해하고 싶었던 것이라는 데 동의함
  • 이런 구멍이 있는 사이트에 먼저 연락하지 않고 Homeland Security로 바로 간 건 전혀 적절하지 않았음

• 문제의 심각성을 부인한 건 놀랍지 않지만, FBI에 알리거나 체포하려 들지 않은 건 꽤 놀라움
  작지만 진전일지도 모름

  • 작성자는 TSA에 직접 제보하지 않고 FAA와 CISA를 통해, 즉 DHS 경로로 처리한 게 올바른 선택이었음
    TSA에 직접 신고했다면 법적 협박과 허세로 이어졌을 가능성도 충분함
  • 이런 절차는 매우 느리게 굴러감
    Ian이 기소될 것이라는 데 50달러 걸 수 있음
  • 이건 뉴스감임
    가짜 신분증을 가진 지루한 17세가 TikTok에 비행기 몰래 탑승 영상을 아직 안 올렸다는 게 놀라울 정도임
    SQL 삽입이라니

• 구식 SQL 삽입 하나가 연간 수십억 달러짜리 보안 연극 전체를 무력화한다는 게 웃기지만, 그리 놀랍지도 않음

  • Bruce Schneier와 그의 가짜 탑승권을 기억하는 사람이 있나? 예전에는 TSA의 낙서가 전체 시스템의 약점이었음

• 항공사들이 이렇게 보안에 민감한 소프트웨어를 한 사람짜리 업체에서 산다는 게 꽤 놀라움
  미국 기업 대부분에 SaaS를 팔려고 어느 정도 단계까지 가면, 최소한 SOC2 감사 보고서는 요구함
  SOC2는 감사 기준으로 보면 큰 지적 없이 통과하기 꽤 쉬운 편이지만, 회사가 한 사람으로 운영된다면 보고서에서 빨간불이 켜져야 할 기준이 여러 개 있음
  TSA 접근 시스템과 연동되는 소프트웨어라면 요구사항이 SOC2보다 훨씬 엄격할 것이라고 생각했음

  • FlyCASS 같은 것을 쓰는 “항공사”들은 자체가 더 작은 사업자이고, 보통 이익률이 극도로 낮거나 아예 적자를 내면서 언젠가 돈이 나타나 사업이 성립하길 바라는 경우가 많음
    백엔드의 모든 것이 평균적인 소기업보다 더 많은 덕트테이프로 겨우 붙어 있음
    오래된 여객기 몇 대를 사서 화물기로 개조하면 “항공사”가 될 수 있음
    새 항공사가 생기는 건 가치 있는 일인가? 수년에서 수십 년 걸리는 시스템을 아직 갖추지 못했다는 이유로 이들을 문 닫게 해야 하나? 아무 데도 아닌 곳과 아무 데도 아닌 곳 사이의 1개 노선을 2대의 항공기로 운항하는 회사가 대형 여객 항공사용 맞춤형 시스템에 큰돈을 내야 하나?
    여기서 요구사항과 감사가 답은 아님. 근본적인 설계 문제는 TSA가 “항공사 XXX가 당신을 직원이라고 말한다”는 인증을 “전국 어느 공항에서나 모든 보안 검색을 우회할 수 있다”는 매우 넓은 권한과 결합해버렸다는 점이며, “그 항공사가 이 공항에서 운항하기는 하는가?”라는 기본 확인조차 없었다는 데 있음

• 이런 일이 이렇게 쉬울 수 있다는 것도 놀라웠지만, 뒤쪽의 TSA 대응 설명은 정말 심각하게 불안함

• 이 일을 한 사람들은 아마 Homeland Security나 FBI의 방문을 받을 것 같음
  뭘 얻을 수 있다고 생각했는지 모르겠음
  정부가 보안에 신경 쓴다고 보지는 않지만, 보복적이긴 함

  • Homeland Security나 FBI가 이 “사람들”이 항공 여행을 더 안전하게 만들려고 책임 있는 공개를 시도한 잘 알려진 유능한 보안 연구자 두 명이라는 결론에 도달한 뒤 무엇을 얻을 수 있겠나?

• 여기서 가능한 수법은 대형 항공사 표를 사고, 반입 금지 물품을 기내 수하물에 넣은 뒤, 제3자 FlyCASS 시스템의 SQL 삽입으로 자신을 소형 항공사의 Known Crew Member 목록에 추가해 TSA 검색을 우회하는 것임
  그런 다음 금지 물품을 들고 대형 항공기에 탑승하는 취약점인가?

  • 대체로 맞음
    요즘 대부분의 TSA 검색 줄은 탑승권조차 요구하지 않으니, 이론상 폭탄을 들고 가서 이 모든 보안 연극을 우회할 수도 있음
  • 조종석에도 앉을 수 있게 되는 것처럼 들리는데?