SQL enjeksiyonu yoluyla havaalanı güvenliğini atlatma

 (ian.sh)
1 puan yazan GN⁺ 2024-08-30 | 1 yorum | WhatsApp'ta paylaş
  • TSA'nın KCM/CASS kimlik doğrulama akışında, havayolu tarafındaki sistem ele geçirilirse, istihdam durumu doğrulamayı geçmiş gibi rastgele kullanıcılar eklenebiliyor; bu da güvenlik kontrolünü atlamaya veya hatta kokpite erişime kadar gidebiliyordu
  • FlyCASS, küçük havayolları için CASS web arayüzü sağlıyordu ve Air Transport International giriş sayfasındaki SQL enjeksiyonu ile yönetici girişi yapılabiliyordu
  • Yönetici ekranı, yeni çalışan eklerken ek doğrulama olmadan KCM ve CASS yetkisi verebiliyordu; test kullanıcısının her iki sistemde de onaylı durumda olduğu doğrulandı
  • Nisan 2024 sonunda ARINC, FAA ve DHS/CISA'ya bildirildikten sonra DHS, FlyCASS'ın KCM/CASS'tan ayrıldığını doğruladı ancak TSA açıklamasının düzeltilmesi talebine yanıt vermedi
  • TSA, KCM barkodu verilmeden önce yapılan inceleme nedeniyle kontrol noktasına erişimin mümkün olmadığını söyledi; ancak gerçek prosedürde çalışan kimliğinin manuel girildiği bir yol kaldığı için açığın etkisi daha büyüktü

KCM ve CASS'ın yaptığı doğrulama

  • Known Crewmember (KCM), TSA programıdır ve pilotların ile kabin ekiplerinin yurt içi kişisel seyahatlerde bile güvenlik kontrolünü atlamasına izin verir
    • Çalışan, özel hattan KCM barkodunu gösterir ya da TSA görevlisine çalışan numarasını ve havayolunu verir
    • TSA görevlisinin dizüstü bilgisayarı havayoluna istihdam durumunu sorar; başarılı olursa ilgili çalışan ek tarama olmadan güvenli alana girebilir
  • Cockpit Access Security System (CASS), kokpite erişim yetkisini doğrulayan ayrı bir sistemdir
    • Uçakların çoğunda kokpit içinde, uçuş ekibinin arkasında bir jumpseat bulunur
    • Pilotlar işe gidip gelirken veya yer değiştirirken ücretli koltuk bulmak zor olursa jumpseat'i kullanabilir
    • Kapı görevlisi, CASS ile jumpseat kullanıcısının onaylı bir pilot olup olmadığını doğrular ve ekibe CASS doğrulamasının yapıldığını bildirebilir
  • Her iki sürecin de özü güncel havayolu istihdam durumunun doğrulanmasıdır
    • Kişi havayolu çalışanı değilse arka plan incelemesinden geçmiş sayılmayacağı için güvenlik kontrolünü atlamasına veya kokpite erişmesine izin verilmemelidir
    • Onay alan kişinin doğru kişi olduğunu doğrulamak için mürettebat fotoğrafı da döndürülür

ARINC ve havayoluna özel doğrulama sistemleri

  • ARINC, Collins Aerospace'in bir iştirakidir ve görünüşe göre TSA adına KCM işletimini yürütmektedir
  • ARINC, pilotlar ile kabin ekiplerinin KCM durumunu kontrol ettiği çevrimiçi bir web sitesi ve havayolları arasındaki onay taleplerini yönlendiren API benzeri merkezi bileşenleri işletir
  • Her havayolu, KCM ve CASS'a katılmak için kendi doğrulama sistemini çalıştırıyor gibi görünmektedir; bu sistem ARINC'in hub'ı ile etkileşir
    • TSA ve havayolları, CockpitAccessRequest, CrewVerificationRequest gibi istekleri ARINC'e gönderebilir
    • ARINC, isteği ilgili havayolu sistemine yönlendirir ve yanıtı geri alır
  • KCM'de şu anda 77 havayolu yer almaktadır
    • Büyük havayolları kendi sistemlerini kurmuş olabilir, ancak küçük havayollarının KCM veya CASS isteklerine nasıl yanıt verdiği araştırmanın konusu oldu

FlyCASS'ta bulunan SQL enjeksiyonu

  • Araştırmacılar, doğrulama sistemini gerçekten işleten tedarikçileri ararken FlyCASS adlı siteyi buldu
    • FlyCASS, küçük havayollarına CASS için web tabanlı bir arayüz sağlıyordu
    • Her havayolunun ayrı bir giriş sayfası vardı ve Air Transport International'a (8C) /ati üzerinden erişilebiliyordu
  • Giriş sayfasında kullanıcı adına tek tırnak eklenince anında MySQL hatası döndü
    • Kullanıcı adının giriş SQL sorgusuna doğrudan eklendiği anlaşılıyordu
    • sqlmap ile SQL enjeksiyonu sorunu doğrulandı
  • Kullanıcı adı ' or '1'='1 ve parola ') OR MD5('1')=MD5('1 birleşimiyle Air Transport International'ın yönetici hesabına giriş yapılabildi

Yönetici yetkisiyle KCM/CASS onaylı kullanıcı ekleme

  • FlyCASS, katılımcı havayolları için hem KCM hem CASS işletiyordu
  • Air Transport International yönetici yetkisi elde edilince, bu havayoluna bağlı pilot ve kabin ekibi listesi yönetilebildi
  • Havayoluna yeni çalışan eklenirken ek kontrol veya kimlik doğrulama yoktu
    • Havayolu yöneticisi, istediği herhangi bir kişiyi KCM ve CASS onaylı kullanıcı olarak ekleyebiliyordu
  • Test için Test TestOnly adlı bir çalışan oluşturulup seçilen test fotoğrafı yüklendikten sonra KCM ve CASS erişim yetkisi verildi
    • Sonrasında Query işleviyle kontrol edildiğinde test kullanıcısının hem KCM hem CASS'ta onaylı durumda olduğu görüldü
  • Temel SQL enjeksiyonu bilgisiyle bile siteye giriş yapıp rastgele kullanıcıları KCM ve CASS'a eklemek mümkündü
    • Sonuç olarak güvenlik taraması atlanabilir ve ticari yolcu uçağının kokpitine erişim bile mümkün hale gelebilirdi
  • İlk sorun fark edilir edilmez bildirim süreci başlatıldı ve bunun dışında da birkaç ciddi sorun daha bulundu

Bildirim süreci ve TSA'nın tepkisi

  • Uygun bildirim iletişim noktasını bulmak bile kolay değildi
    • FlyCASS'ın tek bir kişi tarafından işletildiği görülüyordu, bu yüzden en başta doğrudan FlyCASS ile iletişime geçip paniğe yol açmak istenmedi
  • 23 Nisan 2024'te sorun Department of Homeland Security'ye bildirildi ve DHS, durumu öğrendiğini ve bunu “çok ciddiye aldığını” doğruladı
  • Daha sonra FlyCASS, KCM/CASS'tan devre dışı bırakıldı ve açığın da sonradan giderildiği anlaşıldı
  • Sorun düzeldikten sonra güvenli açıklama koordine edilmeye çalışıldı, ancak DHS yanıt vermeyi bıraktı
  • TSA basın ofisi, açığın etkisini reddeden bir açıklama yaptı
    • TSA, yeni KCM üyelerine barkod verilmeden önce inceleme süreci başladığı için bu açıkla KCM kontrol noktasına erişilemeyeceğini söyledi
    • Ancak KCM kontrol noktasını kullanmak için KCM barkodu zorunlu değildir; TSO havayolu çalışan kimliğini manuel olarak girebilir
    • Araştırmacılar bunu TSA'ya bildirdikten sonra TSA, çalışan kimliğinin manuel girilmesinden söz eden web sitesi bölümünü kaldırdı ve düzeltme talebine yanıt vermedi
    • TSO'nun kullandığı arayüzün hâlâ çalışan kimliğinin manuel girilmesine izin verdiği doğrulandı

Mümkün olan ek saldırılar ve açıklama zaman çizelgesi

  • Açık sayesinde mevcut KCM üyeleri değiştirilebildiği için, kayıtlı kullanıcıların fotoğraf ve isimlerini değiştirmek de mümkündü
    • Bu yöntem, yeni üye inceleme süreci olsa bile onu atlatma ihtimali taşıyordu
  • Kayıtlı olmayan bir KCM barkodu ele geçirilebilirse, KCM web sitesinde bu barkod doğrudan çalışan kimliğine bağlanabilirdi
  • Açıklama zaman çizelgesi:
    • 2024-04-23: ARINC ve FAA'ya ilk bildirim
    • 2024-04-24: CISA üzerinden DHS'ye ek bildirim
    • 2024-04-25: DHS CISO çözüm üzerinde çalışıldığını doğruladı
    • 2024-05-07: DHS CISO, FlyCASS'ın KCM/CASS'tan ayrıldığını doğruladı
    • 2024-05-17: TSA açıklamasıyla ilgili DHS CISO'ya tekrar ulaşıldı ancak yanıt alınmadı
    • 2024-06-04: TSA açıklamasıyla ilgili DHS CISO'ya yeniden ulaşıldı ancak yine yanıt alınmadı

İlgili okumalar

1 yorum

 
GN⁺ 2024-08-30
Hacker News yorumları

  • Burada TSA’nin tepkisi çocukça ve utanç verici düzeyde, ama gerçek güvenlikle pek ilgilenmeyen bir kurum olduğunu düşününce şaşırtıcı da değil.
    DHS başta ihbarı hızlı ve profesyonelce ele almış gibi görünüyor; ancak sonrasında düzeltme ve kamuya açıklama süreci üzerinde üst düzey yetkiyi sonuna kadar koruyamamış olması ilginç.

    • Yönetimin, hatta IT yöneticilerinin bile bu tür bir konunun ne anlama geldiğini tamamen anlaması çok zor.
      Açığa çıkmış anahtarlar gibi büyük sorunların önemsiz görülürken, eski JavaScript kütüphaneleri ya da IPv6 desteği olmaması gibi konuların eskale edildiğini gördüm.
      TSA ve yüklenicilerinin olası ifşayı küçümsemeye çalıştığı açık; ama birçok yöneticinin bir zafiyetin ne anlama geldiğini anlamakta zorlanması, geliştiricilerin de kendi sorumluluğunu küçültüp suçu başkalarına atıyor olması çok muhtemel.
    • TSA bir güvenlik tiyatrosu; güvenlik sağlamaktan çok, güvenlik varmış yanılsaması yaratmak için var.
      Gerçekte amaç, gözetim sistemini pekiştirmek ve güçlü görünen bir dış görüntü yaratmak gibi duruyor.
    • Sanırım bir DHS orta kademe yöneticisi bir TSA orta kademe yöneticisine bağırdı; bu da TSA üst kademelerine iletildi ve sonra her zamanki politika olan inkâr etme·kaçınma·yok sayma devreye girdi.
    • Asıl şaşırtıcı olan, pentester’ın evine şafak baskını yapıp, terörle mücadele yasası maddelerini öne sürerek avukatsız şekilde gözaltına almamış olmaları.

  • SQL injection’ı doğrulamakla kalmayıp sahte bir çalışan kaydı da oluşturmuşlar; Homeland Security’nin ilgili kişileri tutuklamaya gelmemiş olması şaşırtıcı.
    Sorumlu açıklamayı kötü niyetli hackleme sanıp buna öyle deme olasılığı en yüksek yerin Homeland Security olduğunu düşünürdüm.
    Bu, gerçek zafiyetteki beceriksizlikten daha etkileyici.

    • Haksız sayılmazsın; ama fotoğraf yerine parlak pembe bir görsel koyup adı “Test TestOnly” yapmakla CFAA ihlali suçundan, jüri üyesi olarak mahkûmiyet vermem zor olurdu.
      Eğer kendilerini Known Crewmember’a ekleyip gerçekten havaalanı taramasını atlatmış olsalardı, o zaman hapse girerlerdi.
    • Sorumlu açıklama yapsan bile yargılanabileceğin kaygısını yaratan bir ortam oluşursa, bu sistemlere bakacak ülke içindeki en iyi yetenekler korkup geri çekilir.
      O zaman daha az dostane başka ülkelerin en iyi yetenekleri bakar ve onların sorumlu biçimde açıklama yapma olasılığı düşüktür.
    • DHS resmen Bugcrowd kullanıyor.
      https://bugcrowd.com/engagements/dhs-vdp
      Birkaç yıldır ilişkileri var, dolayısıyla bir ölçüde alışık olduklarını düşünüyorum. TSA’nın kendisi daha az alışık olabilir; ama DHS bakanlık genelinde zafiyet açıklama politikası (VDP) yürütürken ve CISA üzerinden diğer bakanlıklara da VDP işletme konusunda danışmanlık verirken, DOJ’den dava açmasını isteyeceklerini sanmıyorum.
      Yine de fazla iyimser düşünüyor olabilirim.
    • Almanya gibi bunun yaygın olduğu ülkelerde genelde sorun bir gazeteciye ya da CCC gibi kâr amacı gütmeyen bir kuruluşa bildirilir; onlar da devlet kurumuna veya şirkete ihbar eder.
      Böylece sorumlu açıklama yüzünden yargılanma riski azaltılabilir.
      Daha güvenli yöntem, raporu anonim göndermek ve kamuya açıklama ya da tam açıklama için net bir son tarih koymaktır; tabii bu durumda keşfeden kişi olarak tanınmak zorlaşır.
    • Zamanaşımı süresi uzun ve HSI çoğu zaman soruşturma neredeyse tamamlanana kadar dava açmayı erteler.

  • O kadar ciddi ki, bu yazıldığı sırada kimse parolaların MD5 ile saklanmasının ne kadar kötü olduğundan bile bahsetmiyor.
    Bu durumda salt bile kullanılmadığı da ortaya çıkıyor; gerçi MD5’te salt kullanmak da yetersiz olurdu.
    Ama yalnızca istek göndererek SQL sorgusunun kendisini istediğin gibi kurcalayabiliyorsan, parolaları ne kadar iyi sakladığının pek anlamı yok.

    • Bu, eskiden Triplebyte mülakatlarında neredeyse aynen çıkan bir soruydu ve oldukça iyi mühendislerin bile inanılmaz büyük bir kısmı yanlış yapıyordu.
      Salt kullanıp kriptografik olarak güvenli hash kullananların oranı muhtemelen %20’nin altındaydı; MD5 ise gerçekten çok sık çıkıyordu.
      Bu mülakattan önce de epey eleme yapıldığını düşünürsek genel taban çizgisi bundan da kötü.
    • SQL injection’daki md5 kısmı pentester tarafından eklenmiş gibi görünüyor; muhtemelen injection parametresi içinde parantezle biten bir çağrıya ihtiyaç duyulduğu içindi.

  • “FlyCASS tek kişi tarafından işletiliyor gibi göründüğü için önce onlarla iletişime geçmedik” açıklamasına inanmak zor.
    Site geliştiricisinin hemen düzelteceğini biliyorlardı ve bulgularını daha büyük patlatmak istiyorlarmış gibi geliyor.

    • Bu tür bir hata tam da büyük patlatılması gereken bir hata.
      Sorumlu kişinin sessizce düzeltip kapatacağı bir şey değil; veritabanındaki herkesin yeniden doğrulanması gerekiyor.
    • Motivasyon ne olursa olsun, bu kadar yaygın bir hatanın içeri girmesine izin veren mühendislik süreci bozuk.
      Tek geliştirici hemen düzeltseydi, sorunu üst kademelere taşıyıp sistematik olarak düzelttirmek zor olurdu.
      Böyle kapsamlı bir yenilenme gerçekten olur mu bilmiyorum; ama eskale edilmezse olma ihtimali daha da düşer.
    • Açıklamadan önce ihlalin kapsamını tamamen anlamak istediklerine katılıyorum.
    • Böyle bir açığı olan siteyle önce iletişime geçmeyip doğrudan Homeland Security’ye gitmek hiç uygun değildi.

  • Sorunun ciddiyetini inkâr etmeleri şaşırtıcı değil; ama FBI’a haber vermemeleri ya da tutuklamaya kalkmamaları epey şaşırtıcı.
    Küçük de olsa bir ilerleme olabilir.

    • Yazarın doğrudan TSA’ya bildirmek yerine FAA ve CISA üzerinden, yani DHS kanalıyla ilerlemesi doğru tercihti.
      Doğrudan TSA’ya bildirseydi bunun hukuki tehditlere ve blöflere dönüşmesi gayet olasıydı.
    • Bu tür süreçler çok yavaş işler.
      Ian’ın yargılanacağına 50 dolar bahse girerim.
    • Bu haber değeri taşıyor.
      Sahte kimlikli sıkılmış bir 17 yaşındaki gencin TikTok’a hâlâ uçağa gizlice biniş videosu koymamış olması şaşırtıcı.
      SQL injection ha.

  • Eski usul bir SQL injection’ın yılda onlarca milyar dolarlık güvenlik tiyatrosunun tamamını etkisiz kılması komik, ama çok da şaşırtıcı değil.

    • Bruce Schneier ve onun sahte biniş kartını hatırlayan var mı? Eskiden TSA’nin karalamaları tüm sistemin zayıf noktasıydı.

  • Havayollarının güvenlik açısından bu kadar hassas yazılımları tek kişilik bir şirketten satın alması epey şaşırtıcı
    ABD’deki çoğu şirkete SaaS satmak için belli bir aşamaya geldiğinizde, en azından bir SOC2 denetim raporu isterler
    SOC2, denetim standardı olarak bakıldığında büyük bir bulgu olmadan geçmesi oldukça kolay sayılır; ancak şirket tek kişi tarafından işletiliyorsa raporda kırmızı bayrak yakması gereken birden fazla kriter var
    TSA erişim sistemiyle entegre olan bir yazılım için gereksinimlerin SOC2’den çok daha sıkı olacağını düşünürdüm

    • FlyCASS gibi şeyleri kullanan “havayolları” zaten daha küçük işletmeler ve çoğu zaman kâr marjları aşırı düşük ya da doğrudan zarar edip, bir gün para ortaya çıkar da iş modeli işler diye umuyorlar
      Arka uçtaki her şey, ortalama bir küçük işletmeden bile daha fazla koli bandıyla zar zor bir arada tutuluyor
      Birkaç eski yolcu uçağı satın alıp kargo uçağına dönüştürürseniz “havayolu” olabilirsiniz
      Yeni bir havayolunun ortaya çıkması değerli bir şey mi? Yıllar, hatta on yıllar süren sistemleri henüz kurmadılar diye onları kapatmalı mıyız? Hiçbir yerle hiçbir yer arasında 2 uçakla 1 rota işleten bir şirket, büyük yolcu havayollarına yönelik özel sistemlere büyük paralar ödemek zorunda mı?
      Burada gereksinimler ve denetimler cevap değil. Temel tasarım sorunu, TSA’nın “XXX havayolu sizin çalışan olduğunuzu söylüyor” şeklindeki doğrulamayı “ülkedeki herhangi bir havalimanında tüm güvenlik kontrollerini atlayabilirsiniz” gibi çok geniş bir yetkiyle birleştirmesi ve “bu havayolu bu havalimanında gerçekten faaliyet gösteriyor mu?” gibi temel bir kontrolün bile olmaması

  • Böyle bir şeyin bu kadar kolay olabilmesi de şaşırtıcıydı, ama sondaki TSA yanıtı açıklaması gerçekten ciddi biçimde tedirgin edici

  • Bunu yapan kişiler muhtemelen Homeland Security ya da FBI tarafından ziyaret edilecek
    Ne elde edebileceklerini düşündüler, bilmiyorum
    Devletin güvenliği umursadığını sanmıyorum, ama misillemeci olduğu kesin

    • Homeland Security ya da FBI, bu “kişilerin” hava yolculuğunu daha güvenli hâle getirmek için sorumlu açıklama yapmaya çalışan, tanınmış ve yetkin iki güvenlik araştırmacısı olduğu sonucuna vardıktan sonra ne elde edebilir?

  • Burada mümkün olan yöntem şu: Büyük bir havayolundan bilet satın almak, yasaklı eşyaları kabin bagajına koymak ve üçüncü taraf FlyCASS sistemindeki SQL enjeksiyonu ile kendini küçük bir havayolunun Known Crew Member listesine ekleyip TSA kontrolünü atlamak
    Ardından yasaklı eşyalarla büyük bir yolcu uçağına binmeye yarayan bir açık mı bu?

    • Genel olarak evet
      Günümüzde çoğu TSA güvenlik kuyruğu biniş kartı bile istemiyor; yani teoride bir bombayla gidip tüm bu güvenlik tiyatrosunu atlayabilirsiniz
    • Kokpite de oturabilir hâle geliyormuşsunuz gibi geliyor?