1 điểm bởi GN⁺ 2024-08-30 | 1 bình luận | Chia sẻ qua WhatsApp
  • Trong luồng xác thực KCM/CASS của TSA, nếu hệ thống phía hãng hàng không bị xâm nhập, kẻ tấn công có thể thêm người dùng tùy ý như thể họ đã vượt qua xác minh tình trạng việc làm, từ đó có thể dẫn tới việc bỏ qua kiểm tra an ninh hoặc thậm chí tiếp cận buồng lái
  • FlyCASS cung cấp giao diện web CASS cho các hãng hàng không nhỏ, và trang đăng nhập của Air Transport International có thể đăng nhập quản trị viên thông qua SQL injection
  • Màn hình quản trị có thể cấp quyền KCM và CASS khi thêm nhân viên mới mà không cần xác minh bổ sung, khiến người dùng thử nghiệm được xác nhận là ở trạng thái được phê duyệt trong cả hai hệ thống
  • Sau khi được tiết lộ cho ARINC, FAA, DHS/CISA vào cuối tháng 4 năm 2024, DHS xác nhận FlyCASS đã bị tách khỏi KCM/CASS, nhưng không phản hồi yêu cầu đính chính về giải thích của TSA
  • TSA nói rằng không thể tiếp cận checkpoint vì có quy trình xét duyệt trước khi cấp mã vạch KCM, nhưng trong quy trình thực tế vẫn còn đường nhập thủ công ID nhân viên, nên tác động của lỗ hổng lớn hơn

Vai trò xác minh của KCM và CASS

  • Known Crewmember(KCM) là một chương trình của TSA cho phép phi công và tiếp viên bỏ qua kiểm tra an ninh ngay cả khi đi lại cá nhân trong nước
    • Nhân viên trình mã vạch KCM ở làn riêng hoặc cung cấp mã số nhân viên và hãng hàng không cho nhân viên TSA
    • Máy tính xách tay của nhân viên TSA xác minh tình trạng làm việc với hãng hàng không, và nếu thành công, nhân viên đó có thể vào khu vực an ninh mà không cần kiểm tra riêng
  • Cockpit Access Security System(CASS) là một hệ thống riêng để xác nhận tư cách tiếp cận buồng lái
    • Hầu hết máy bay có ghế phụ jumpseat trong buồng lái, phía sau phi công đang điều khiển
    • Khi phi công đi làm hoặc di chuyển mà khó sử dụng ghế trả phí, họ có thể dùng jumpseat
    • Nhân viên cổng có thể dùng CASS để xác nhận người dùng jumpseat có phải là phi công được phê duyệt hay không, và thông báo cho tổ bay rằng người đó đã được xác thực qua CASS
  • Cốt lõi của cả hai quy trình là xác nhận tình trạng làm việc hiện tại tại hãng hàng không
    • Nếu không phải nhân viên hãng hàng không thì không ở trạng thái đã được điều tra lý lịch, nên không được phép bỏ qua kiểm tra an ninh hoặc tiếp cận buồng lái
    • Hệ thống cũng trả về ảnh của tổ bay để xác nhận đúng người được phê duyệt

ARINC và hệ thống xác thực theo từng hãng hàng không

  • ARINC là công ty con của Collins Aerospace và dường như được TSA giao vận hành KCM
  • ARINC vận hành các thành phần trung tâm như website trực tuyến để phi công và tiếp viên kiểm tra trạng thái KCM, cũng như API định tuyến các yêu cầu phê duyệt giữa các hãng hàng không
  • Mỗi hãng hàng không dường như vận hành hệ thống xác thực riêng để tham gia KCM và CASS, và hệ thống này tương tác với hub của ARINC
    • TSA và các hãng hàng không có thể gửi các yêu cầu như CockpitAccessRequest, CrewVerificationRequest tới ARINC
    • ARINC định tuyến yêu cầu tới hệ thống của hãng hàng không tương ứng và nhận phản hồi
  • Hiện có 77 hãng hàng không tham gia KCM
    • Các hãng lớn có thể đã xây dựng hệ thống riêng, nhưng đối tượng được điều tra là cách các hãng nhỏ phản hồi yêu cầu KCM hoặc CASS

SQL injection được phát hiện trong FlyCASS

  • Trong lúc tìm nhà cung cấp thực sự vận hành hệ thống xác thực, các nhà nghiên cứu phát hiện một trang có tên FlyCASS
    • FlyCASS cung cấp giao diện nền web cho CASS dành cho các hãng hàng không nhỏ
    • Mỗi hãng hàng không có một trang đăng nhập riêng, và Air Transport International(8C) có thể truy cập tại /ati
  • Khi nhập dấu nháy đơn vào tên người dùng trên trang đăng nhập, hệ thống lập tức trả về lỗi MySQL
    • Có vẻ tên người dùng được chèn trực tiếp vào truy vấn SQL đăng nhập
    • Vấn đề SQL injection được xác nhận bằng sqlmap
  • Với tổ hợp tên người dùng ' or '1'='1 và mật khẩu ') OR MD5('1')=MD5('1, có thể đăng nhập vào tài khoản quản trị viên của Air Transport International

Thêm người dùng được phê duyệt KCM/CASS bằng quyền quản trị

  • FlyCASS đang vận hành cả KCM lẫn CASS cho các hãng hàng không tham gia
  • Sau khi có quyền quản trị viên của Air Transport International, có thể quản lý danh sách phi công và tiếp viên gắn với hãng hàng không đó
  • Khi thêm nhân viên mới vào hãng hàng không, không có xác minh hay xác thực bổ sung nào
    • Quản trị viên hãng hàng không có thể thêm bất kỳ ai làm người dùng được phê duyệt KCM và CASS
  • Để thử nghiệm, họ tạo một nhân viên tên Test TestOnly, thêm ảnh thử nghiệm đã chọn rồi cấp quyền truy cập KCM và CASS
    • Sau đó, khi kiểm tra bằng tính năng Query, người dùng thử nghiệm ở trạng thái được phê duyệt trong cả KCM lẫn CASS
  • Chỉ cần kiến thức SQL injection cơ bản là có thể đăng nhập vào site và thêm người dùng tùy ý vào KCM và CASS
    • Kết quả là có thể bỏ qua kiểm tra an ninh và thậm chí tiếp cận buồng lái máy bay chở khách thương mại
  • Quy trình tiết lộ bắt đầu ngay sau khi phát hiện vấn đề đầu tiên, và sau đó còn phát hiện thêm nhiều vấn đề nghiêm trọng khác

Quy trình tiết lộ và phản ứng của TSA

  • Ngay cả quá trình tìm đầu mối liên hệ phù hợp để tiết lộ cũng không dễ
    • Vì FlyCASS dường như do một người vận hành, các nhà nghiên cứu không muốn liên hệ trực tiếp với FlyCASS ngay từ đầu và khiến họ hoảng hốt
  • Ngày 23/4/2024, vấn đề được tiết lộ cho Department of Homeland Security, và DHS xác nhận đã nắm được, đồng thời “xem xét việc này rất nghiêm túc”
  • Sau đó FlyCASS bị vô hiệu hóa khỏi KCM/CASS, và về sau vấn đề dường như đã được khắc phục
  • Sau khi vấn đề được sửa, các nhà nghiên cứu cố gắng phối hợp công bố an toàn, nhưng DHS ngừng phản hồi
  • Văn phòng báo chí TSA đưa ra giải thích phủ nhận tác động của lỗ hổng
    • TSA nói rằng quy trình xét duyệt bắt đầu trước khi cấp mã vạch cho thành viên KCM mới, nên không thể dùng lỗ hổng này để tiếp cận checkpoint KCM
    • Tuy nhiên, mã vạch KCM không bắt buộc để sử dụng checkpoint KCM, và TSO có thể nhập thủ công ID nhân viên hãng hàng không
    • Sau khi các nhà nghiên cứu thông báo điều này cho TSA, TSA đã xóa phần website đề cập đến việc nhập thủ công ID nhân viên và không phản hồi yêu cầu đính chính
    • Giao diện mà TSO sử dụng được xác nhận là vẫn cho phép nhập thủ công ID nhân viên

Các cuộc tấn công bổ sung có thể xảy ra và dòng thời gian tiết lộ

  • Vì lỗ hổng cho phép chỉnh sửa thành viên KCM hiện có, nên cũng có thể thay đổi ảnh và tên của người dùng đã đăng ký
    • Cách này có thể vượt qua quy trình xét duyệt thành viên mới ngay cả khi quy trình đó tồn tại
  • Nếu có thể lấy được mã vạch KCM chưa được đăng ký, cũng có thể đăng ký trực tiếp mã đó với ID nhân viên trên website KCM
  • Dòng thời gian tiết lộ:
    • 2024-04-23: Tiết lộ lần đầu cho ARINC và FAA
    • 2024-04-24: Tiết lộ bổ sung cho DHS thông qua CISA
    • 2024-04-25: DHS CISO xác nhận đang xử lý
    • 2024-05-07: DHS CISO xác nhận FlyCASS đã bị tách khỏi KCM/CASS
    • 2024-05-17: Liên hệ tiếp với DHS CISO về giải thích của TSA nhưng không có phản hồi
    • 2024-06-04: Tiếp tục liên hệ với DHS CISO về giải thích của TSA nhưng không có phản hồi

1 bình luận

 
GN⁺ 2024-08-30
Ý kiến trên Hacker News
  • Phản ứng của TSA ở đây đúng là trẻ con và đáng xấu hổ, nhưng nếu nghĩ đến việc đây là một tổ chức vốn không mấy quan tâm đến bảo mật thực sự thì cũng không có gì đáng ngạc nhiên
    Ban đầu DHS dường như đã xử lý báo cáo nhanh chóng và chuyên nghiệp, nhưng điều thú vị là sau đó họ không duy trì được quyền kiểm soát cấp cao đối với quy trình sửa lỗi và công bố cho đến cùng

    • Ban lãnh đạo, thậm chí cả quản trị viên IT, rất khó hiểu đầy đủ những vấn đề như thế này có ý nghĩa gì
      Tôi từng thấy những vấn đề lớn như khóa bị lộ lại bị xem nhẹ, trong khi những chuyện như thư viện JavaScript cũ hoặc không hỗ trợ IPv6 lại bị escalated
      Rõ ràng TSA và các nhà thầu đang cố giảm nhẹ mức độ phơi lộ tiềm tàng, nhưng rất có khả năng nhiều quản lý khó hiểu ý nghĩa của lỗ hổng, còn các lập trình viên thì cũng đang giảm nhẹ trách nhiệm của mình và đổ lỗi cho người khác
    • TSA là một màn kịch an ninh, tồn tại không phải để cung cấp an ninh mà để tạo ảo tưởng rằng có an ninh
      Thực tế trông như mục tiêu là củng cố hệ thống giám sát và tạo ra vẻ ngoài mạnh mẽ
    • Có vẻ một quản lý cấp trung của DHS đã quát một quản lý cấp trung của TSA, nội dung đó được báo lên cấp cao TSA, rồi chính sách thường lệ là phủ nhận·né tránh·phớt lờ được kích hoạt
    • Điều đáng ngạc nhiên hơn là họ đã không đột kích nhà pentester lúc rạng sáng, rồi viện các điều khoản luật chống khủng bố để giam giữ không cho gặp luật sư
  • Họ không chỉ dừng ở việc xác nhận SQL injection mà còn tạo cả bản ghi nhân viên giả, nên thật sốc khi Homeland Security không đến bắt những người liên quan
    Tôi từng nghĩ Homeland Security là nơi có khả năng cao nhất hiểu nhầm responsible disclosure thành tấn công ác ý và gọi nó như vậy
    Điểm này còn gây ấn tượng hơn cả mức độ kém cỏi của lỗ hổng thực tế

    • Nói vậy không sai, nhưng với tư cách bồi thẩm viên, tôi thấy khó mà kết tội vi phạm CFAA chỉ vì họ thay ảnh bằng một hình màu hồng sáng và đặt tên là “Test TestOnly”
      Nếu họ tự thêm mình vào Known Crewmember và thật sự qua mặt kiểm tra an ninh sân bay, khi đó chắc đã vào tù
    • Nếu tạo ra bầu không khí khiến người ta lo rằng ngay cả responsible disclosure cũng có thể bị truy tố, những nhân tài giỏi nhất trong nước có thể xem xét các hệ thống này sẽ sợ hãi và rút lui
      Khi đó những nhân tài giỏi nhất từ các quốc gia khác, kém thân thiện hơn, sẽ xem xét thay, và khả năng họ công bố có trách nhiệm là thấp
    • DHS chính thức sử dụng Bugcrowd
      https://bugcrowd.com/engagements/dhs-vdp
      Họ đã có quan hệ vài năm nên có lẽ cũng quen thuộc ở mức nào đó. Bản thân TSA có thể ít quen hơn, nhưng trong bối cảnh DHS vận hành chính sách công bố lỗ hổng (VDP) cho toàn bộ bộ và thông qua CISA tư vấn cho các bộ khác vận hành VDP, tôi không nghĩ họ sẽ đề nghị DOJ truy tố
      Dù vậy có thể tôi đang quá lạc quan
    • Ở những nước mà chuyện này phổ biến như Đức, người ta thường báo vấn đề cho nhà báo hoặc tổ chức phi lợi nhuận như CCC, rồi họ sẽ báo cho cơ quan chính phủ hoặc công ty
      Như vậy có thể giảm rủi ro bị truy tố vì responsible disclosure
      Cách an toàn hơn là gửi báo cáo ẩn danh và đặt thời hạn rõ ràng cho việc công bố hoặc full disclosure, tất nhiên khi đó khó được ghi nhận là người phát hiện
    • Thời hiệu truy tố dài, và HSI thường trì hoãn việc truy tố cho đến khi cuộc điều tra gần như hoàn tất
  • Vấn đề nghiêm trọng đến mức, ngay cả vào thời điểm bài này được viết, cũng chưa ai nói đến chuyện lưu mật khẩu bằng MD5 tệ đến mức nào
    Trong trường hợp này còn lộ ra rằng họ thậm chí không dùng salt; mà với MD5 thì có dùng salt cũng vẫn không đủ
    Nhưng nếu chỉ bằng request đã có thể tùy ý lục tung chính câu truy vấn SQL, thì việc mật khẩu được lưu tốt đến đâu cũng chẳng còn nhiều ý nghĩa

    • Đây gần như nguyên văn là câu hỏi từng xuất hiện trong phỏng vấn Triplebyte trước đây, và ngay cả khá nhiều kỹ sư rất giỏi cũng trả lời sai nghiêm trọng
      Tỷ lệ dùng salt và cả hash an toàn về mặt mật mã có lẽ dưới 20%, và MD5 xuất hiện cực kỳ thường xuyên
      Nếu nghĩ rằng trước vòng phỏng vấn này ứng viên đã được lọc khá nhiều, thì đường chuẩn tổng thể còn tệ hơn thế
    • Trong SQL injection, có vẻ phần md5 là do pentester thêm vào, có khả năng vì họ cần một lời gọi kết thúc bằng dấu ngoặc trong tham số bị chèn
  • Khó tin lời giải thích rằng “không liên hệ trước vì FlyCASS trông như do một người vận hành”
    Có cảm giác họ biết lập trình viên của site sẽ sửa ngay, và họ muốn phát hiện của mình nổ lớn hơn

    • Những lỗi như thế này chính là lỗi cần phải làm cho nổ lớn
      Không phải chuyện người phụ trách âm thầm sửa rồi xong; tất cả mọi người trong cơ sở dữ liệu phải được xác minh lại
    • Dù động cơ là gì, quy trình kỹ thuật đã cho phép một lỗi phổ biến như vậy lọt vào là đã hỏng
      Nếu nhà phát triển duy nhất sửa ngay lập tức, sẽ khó đưa vấn đề lên cấp trên để buộc sửa một cách có hệ thống
      Không rõ cuộc đại tu như vậy có thực sự xảy ra không, nhưng nếu không escalation thì khả năng xảy ra còn thấp hơn
    • Tôi đồng ý rằng họ muốn hiểu đầy đủ phạm vi bị xâm phạm trước khi công bố
    • Việc không liên hệ trước với site có lỗ hổng như vậy mà đi thẳng tới Homeland Security là hoàn toàn không phù hợp
  • Việc họ phủ nhận mức độ nghiêm trọng của vấn đề thì không ngạc nhiên, nhưng việc họ không báo FBI hay cố bắt người thì khá đáng ngạc nhiên
    Có thể là một bước tiến nhỏ

    • Tác giả đã lựa chọn đúng khi không báo trực tiếp cho TSA mà xử lý qua FAA và CISA, tức theo kênh DHS
      Nếu báo trực tiếp cho TSA, hoàn toàn có khả năng sẽ dẫn đến đe dọa pháp lý và phô trương hù dọa
    • Những quy trình kiểu này vận hành rất chậm
      Tôi có thể cược 50 đô rằng Ian sẽ bị truy tố
    • Đây là tin đáng lên báo
      Thật đáng ngạc nhiên là một đứa 17 tuổi buồn chán với giấy tờ giả vẫn chưa đăng video lẻn lên máy bay trên TikTok
      Lại còn SQL injection nữa chứ
  • Thật buồn cười khi một lỗi SQL injection kiểu cũ có thể vô hiệu hóa cả màn kịch an ninh trị giá hàng chục tỷ đô la mỗi năm, nhưng cũng không quá ngạc nhiên

    • Có ai còn nhớ Bruce Schneier và thẻ lên máy bay giả của ông ấy không? Ngày xưa những nét nguệch ngoạc của TSA từng là điểm yếu của toàn bộ hệ thống
  • Việc các hãng hàng không mua phần mềm nhạy cảm về bảo mật như thế này từ một công ty chỉ có một người là điều khá đáng ngạc nhiên
    Khi đã đi đến một giai đoạn nhất định để bán SaaS cho phần lớn doanh nghiệp Mỹ, tối thiểu họ sẽ yêu cầu báo cáo kiểm toán SOC2
    Xét theo tiêu chuẩn kiểm toán, SOC2 là thứ khá dễ vượt qua mà không có phát hiện lớn, nhưng nếu công ty được vận hành bởi một người duy nhất thì có nhiều tiêu chí đáng ra phải bật đèn đỏ trong báo cáo
    Tôi từng nghĩ nếu là phần mềm tích hợp với hệ thống truy cập của TSA thì yêu cầu sẽ nghiêm ngặt hơn SOC2 rất nhiều

    • Các “hãng hàng không” dùng thứ như FlyCASS bản thân thường là những doanh nghiệp nhỏ hơn, thường có biên lợi nhuận cực thấp hoặc thậm chí thua lỗ, với hy vọng một ngày nào đó tiền sẽ xuất hiện và mô hình kinh doanh sẽ thành hình
      Mọi thứ ở backend chỉ được chắp vá bằng băng keo nhiều hơn cả một doanh nghiệp nhỏ trung bình
      Mua vài chiếc máy bay chở khách cũ rồi cải tạo thành máy bay chở hàng là có thể trở thành một “hãng hàng không”
      Việc có thêm hãng hàng không mới có phải là điều có giá trị không? Có nên buộc họ đóng cửa chỉ vì họ chưa có những hệ thống mất nhiều năm đến hàng chục năm để xây dựng không? Một công ty vận hành 1 tuyến giữa hai nơi chẳng mấy tên tuổi bằng 2 máy bay có phải trả khoản tiền lớn cho hệ thống đặt riêng dành cho các hãng hàng không chở khách lớn không?
      Ở đây, yêu cầu và kiểm toán không phải là câu trả lời. Vấn đề thiết kế căn bản nằm ở chỗ TSA đã ghép việc xác thực “hãng hàng không XXX nói bạn là nhân viên của họ” với một quyền hạn rất rộng là “có thể bỏ qua mọi kiểm tra an ninh ở bất kỳ sân bay nào trên toàn quốc”, mà thậm chí còn không có kiểm tra cơ bản như “hãng đó có hoạt động tại sân bay này không?”
  • Việc chuyện này có thể dễ dàng đến vậy đã đáng ngạc nhiên, nhưng phần mô tả phản ứng của TSA ở phía sau thì thật sự gây bất an nghiêm trọng

  • Những người làm việc này có lẽ sẽ được Homeland Security hoặc FBI ghé thăm
    Không hiểu họ nghĩ mình có thể đạt được gì
    Tôi không cho rằng chính phủ quan tâm đến bảo mật, nhưng họ thì có tính trả đũa

    • Homeland Security hay FBI có thể đạt được gì sau khi kết luận rằng những “người” này là hai nhà nghiên cứu bảo mật có năng lực và được biết đến, đang cố gắng công bố có trách nhiệm để giúp việc đi lại bằng đường hàng không an toàn hơn?
  • Kịch bản khả thi ở đây là mua vé của một hãng hàng không lớn, cho vật phẩm bị cấm mang lên máy bay vào hành lý xách tay, rồi dùng SQL injection vào hệ thống FlyCASS của bên thứ ba để tự thêm mình vào danh sách Known Crew Member của một hãng hàng không nhỏ nhằm vượt qua kiểm tra TSA
    Sau đó đây có phải là lỗ hổng cho phép mang vật phẩm bị cấm lên một máy bay lớn không?

    • Đại thể là đúng
      Ngày nay hầu hết các hàng kiểm tra TSA thậm chí còn không yêu cầu thẻ lên máy bay, nên về lý thuyết có thể mang bom đi và vượt qua toàn bộ màn kịch an ninh này
    • Nghe như thể còn có thể ngồi vào buồng lái nữa?