Tüm dünyayı arkadaşına kötüye kullanım bildirimi göndermeye zorlayan IP spoofing saldırısı

 (delroth.net)
1 puan yazan GN⁺ 2024-10-30 | 1 yorum | WhatsApp'ta paylaş
  • Hetzner, 195.201.9.37 adresinden SSH port taraması yapıldığına dair bir kötüye kullanım bildirimi iletti, ancak sunucunun içinde kötü amaçlı süreçler, dosya değişiklikleri veya anormal trafik olduğuna dair kanıt bulunmadı
  • tcpdump ile görülen gerçek akışta, sunucu dışarıdaki 22/tcp adresine bağlanmıyor; bunun yerine birçok internet ana makinesi sunucuya TCP RST geri gönderiyordu; bu durum backscatter'a yakındı
  • Temel neden, BCP38 filtrelemesi yapmayan ağlar üzerinden istenen kaynak IP adresiyle paket gönderilebilmesi; TCP·QUIC·TLS gibi gidiş-dönüş yanıt gerektiren protokollerde saldırgan yanıtları doğrudan göremez
  • Aynı örüntü yazarın diğer iki Tor relay düğümünde de görüldü; tor-relays e-posta listesi ve Tor Project issue kayıtlarında da benzer olaylar günler öncesinden raporlanmıştı ve bazı düğümler geçici olarak devre dışı kalmıştı
  • Saldırgan, kurbanın IP’sini kaynak adres olarak sahteleyip birçok SSH hedefine bağlantı denemesi gönderebilir; bunun sonucunda otomatik kötüye kullanım bildirimleri, engelleme listeleri ve hosting sağlayıcısı aksiyonları tetiklenebilir

Hetzner kötüye kullanım bildirimi ve sunucu incelemesi

  • Hetzner, 195.201.9.37 IP’si için bir AbuseInfo e-postası gönderdi
    • Bildirimi yapan: abuse@watchdogcyberdefense.com
    • Kayıtlarda çeşitli 202.91.16x.x hedeflerinin 22/tcp portuna giden DENIED girdileri yer alıyordu
  • İlk bakışta sunucu internete SSH bağlantıları göndermeye başlamış gibi görünüyordu; bu da normalde zararlı yazılım bulaşması şüphesi doğuracak bir durumdu
  • 1-2 saatlik incelemede sunucu durumu normale çok yakındı
    • Anormal süreç yok
    • Dosya sisteminde değişiklik yok
    • Hypervisor açısından anormal ağ trafiği yok
  • Bu sunucuda birden fazla dağıtık ve federatif servis çalışıyordu
    • Syncthing relay
    • Mastodon instance
    • Tor relay
    • Matrix homeserver
  • Tor relay bazı 22/tcp relay düğümlerine bağlanıyordu, ancak bunlar bildirideki ağlarla eşleşmiyordu; Matrix ve Mastodon loglarında, ayrıca Mastodon Sidekiq kuyruğunda da rastgele IP veya port isteklerinin izi yoktu

tcpdumpun gösterdiği gerçek paket akışı

  • İlk olarak dst port 22 filtresiyle sunucudan dışarıya 22/tcp yönünde giden trafiği doğrulamaya çalıştı
  • Filtre not src host 195.201.9.37 olarak değiştirildiğinde, çeşitli dış IP’lerin 22/tcp portundan yazarın sunucusundaki geçici portlara gelen TCP RST paketleri görüldü
  • Yani gerçekte sunucu rastgele ana makinelerin 22/tcp portuna bağlantı göndermiyordu; bunun yerine rastgele internet ana makineleri sunucuya reset paketleri yolluyordu
  • Bu örüntü, kaynak IP sahteciliği nedeniyle yanıt paketlerinin sahte IP’ye dönmesiyle oluşan backscatter ile uyumluydu

Kaynak IP sahteciliği ve BCP38’deki boşluk

  • İnternette hedef IP’nin doğru olması gerekir, ancak kaynak IP’si sahte olan paketleri birçok hedefe göndermek mümkündür
  • BCP38, eş ağların yalnızca kendilerinden beklenen IP adreslerini kaynak olarak kullanmasına izin verilmesini öneren güncel en iyi uygulamadır
  • Bu filtreleme, etkili olabilmesi için paket yolunun erken aşamasında uygulanmalıdır
    • Büyük transit provider seviyesinde anlamlı filtreleme zordur; çünkü eş ağlar bu provider üzerinden tüm internet trafiğini taşımayı bekler
  • BCP38 uygulamayan tek bir transit provider bulmak bile istenen kaynak IP ile paket göndermeye yeterlidir
  • APNIC, 2023’te kaynak adres doğrulamanın neden hâlâ sorun olduğunu anlatan bir yazı yayımladı
  • TCP, QUIC ve TLS ailesi protokoller gidiş-dönüş iletişim gerektirdiği için, kaynak IP sahte olduğunda saldırgan yanıtları göremez
    • Bu yüzden normal port taraması sonuçlarını görmek için uygun değildir
    • Yine de yansıma DDoS gibi bilinen kötüye kullanım biçimleri vardır

Bu sahtecilik neden zarara yol açıyor?

  • En makul akış, birinin yazarın IP’sini kaynak adres olarak kullanıp birçok internet ana makinesinin 22/tcp portuna bağlantı denemeleri göndermesidir
  • Amaç sıradan açık port taraması olsaydı, sahteleyen taraf yanıtları göremeyeceği için bu mantıklı olmazdı
  • Geçmişte Idle Scanning adlı bir teknik vardı, ancak bu daha az meşgul sunuculara ve öngörülebilir ağ yığını sayaçlarına dayanıyordu; onlarca yıldır pratik değerini yitirmiş durumda
  • Trafik hacmi çok düşüktü ve süre çok uzundu; bu yüzden tarayıcı ayarında kaynak IP’nin yanlış girilmiş olması da ikna edici görünmüyor
  • Asıl zarar kötüye kullanım bildirimi otomasyonu üzerinden oluşuyor
    • Sahte bağlantı denemeleri honeypot veya izinsiz giriş tespit sistemi bulunan ağlara ulaşıyor
    • Bazı sistemler otomatik olarak kötüye kullanım bildirimi gönderiyor
    • Hosting sağlayıcıları, kurban sunucunun ele geçirilmiş veya kötü niyetli olduğunu sanabiliyor

Aynı örüntü diğer Tor relay düğümlerinde de tekrarlandı

  • Yazar, kendi sunucusunun bir Tor relay olarak çalıştığını yeniden doğruladı
  • Tor relay, Tor ağı içindeki bir düğümdür; exit node değilse genel internetle doğrudan iletişim kurmaz
    • Relay, Tor ağına katılan düğümler arasında şifreli anonim trafiği taşır
    • Bazı relay düğümleri Guard Node olarak çalışıp Tor ağına giriş noktası olabilir
  • Farklı ülkelerde ve farklı ISP’lerde bulunan iki ek relay üzerinde de tcpdump çalıştırdı
    • Ev internet hattındaki relay
    • Japonya’daki Linode VPS üzerindeki relay
  • Her iki relay’de de dış 22/tcp portlarından relay IP’sine yönelen aynı sahte TCP yanıtı örüntüsü görüldü
  • Yazar, tor-relays e-posta listesine yazdı; ayrıca Tor Project’te birkaç gün önceden aynı olayı inceleyen bir issue zaten vardı
  • Bu spoofing saldırısı, relay düğümlerinden önce başka tür düğümlerde başlamıştı ve daha büyük ölçekli sahte bağlantılar nedeniyle bazı düğümlerin geçici olarak devre dışı kaldığı örnekler olmuştu

Herkesin hedef olabileceği saldırı akışı

  • Olası saldırı akışı şöyle
    • Saldırgan BCP38 filtrelemesi olmayan bir ağa erişir
    • Birçok rastgele internet ana makinesinin 22/tcp portuna TCP bağlantı isteği gönderir
    • Kaynak IP olarak kurbanın IP’sini sahteleyerek kullanır
    • Hedef ana makineler veya güvenlik sistemleri, bağlantıyı kurbanın başlattığını sanıp kötüye kullanım bildirimi yollar
    • Ölçek yeterince büyürse kurbanın IP’si çeşitli engelleme listelerine girer ve hosting sağlayıcısı sunucuyu askıya alabilir
  • Bu saldırıda Tor’a özgü bir unsur yok
  • Tek bir motivasyon sahibi saldırgan için uygulanması özellikle zor görünen bir yöntem değil
  • Kurban, gerçek saldırgan değil; yalnızca sahte kaynak IP’nin sahibidir. Ancak otomatik kötüye kullanım bildirimleri ve hosting sağlayıcısının tepkisi nedeniyle operasyonel zarar görebilir

2024’te de süren internet işletim sorunu

  • Sahte kaynak IP kullanımının 2024’te hâlâ sorun olması, internet işletimi açısından neredeyse bir başarısızlık sayılabilir
  • Yalnızca BCP38 değil, RPKI de dağıtım açısından benzer sorunlar yaşadı; ancak büyük internet şirketleri doğrudan eş ağlara şart dayatmaya başlayınca yaygınlaşabildi
  • Bu saldırı için sonraki adımlar net değil
    • Zaten fiilen yaşanıyor
    • Yazar bunun daha önce belgelenmiş bir saldırı olup olmadığını bilmiyor
    • Sahte IP paketlerinin gerçek kaynağını sonradan izleyebilecek bir yöntem de bilmiyor
  • Benzer kötüye kullanım bildirimleri alan operatörlerin, sunucunun fail değil kurban olabileceğini doğrulaması ve hosting sağlayıcısına bunu açıklayacak kanıt toplaması gerekiyor

İlgili okumalar

1 yorum

 
GN⁺ 2024-10-30
Hacker News görüşleri

  • Bu tür sorunlarla uğraşmak gerçekten çok can sıkıcı. Kötüye kullanım bildirimine verilebilecek meşru yanıt olan “birisi benim IP’mi spoof etti, bunu ben yapmadım ve cihazlarım da ele geçirilmedi” sözü, kötü niyetli birinin öne süreceği bahaneyle tamamen aynı
    Sonuçta, yazıda anlatıldığı gibi aslında hiç ilgilenmeyen bir tarafa yokluğun kanıtını sunmanız gerekiyor; bu da pratikte neredeyse imkânsız

    • Hetzner e-postada yanıt gerekmediğini söylemişti
      Kolayca spoof edilebilen şeylere dair otomatik kötüye kullanım bildirimleri bildirimin kendisini meşru kılmaz, ama sunucumun normal çalıştığını ve ele geçirilmediğini hızlıca kontrol etmek için bir sebep olabilir
    • Meşru bir yanıt, güvenilir bir üçüncü tarafın gerçek dünyada kefil olduğu türden bir gerçek kanıt içermeli
      En azından kimlik ve yargı yetkisine dair dayanak, belki bir görüntülü arama bile gerekebilir. İnternette anonim şekilde “iyi biriyim” deyip buna inanılmasını istemek yeterli değil

  • Spoof edilmiş MAC adresleri, e-posta adresleri, ARP mesajları, Neighbor Discovery ve ortadaki adam TLS sertifikaları için de aynı durum geçerli
    Buna rağmen bir şeylerin hâlâ çalışıyor olması bile şaşırtıcı

    • İnternet bozuk değil; aksine muazzam bir kullanışlılık ve güvenilirliğe sahip
      Kusursuz biçimde tasarlanıp işletilecek şekilde yapılmış olsaydı, muhtemelen aksine oldukça sık büyük arızalar yaşardı. Bir miktar kusuru tolere edebilmesi, internetin sağlamlığına ve kullanışlılığına büyük katkı yaptı
      Bu, iyileştirme yapmayalım demek değil; daha çok mükemmeliyetçiliğin peşinden giderken her şeyi bozacak büyük hatalar yapmanın kolay olduğuna dair bir uyarı
    • Spoof edilebilir MAC adresleri, Wi‑Fi gizliliği için epey gerekli
    • Mobil şebekelerin SS7 sisteminde de benzer bir sorun var: https://youtu.be/wVyu7NB7W6Y
    • Çin’in internet protokolünü reforme etmeyi önermesinde bir mantık payı mı vardı diye düşünmeye başlıyorum
    • DNS hakkında sık sık şikâyet duyuyorum, ama aslında ne kadar güvenli olduğunu ve neden düzeltmeye yönelik çabanın az olduğunu merak ediyorum

  • Eskiden benzer bir yöntemle DrDoS yansıtma sunucularını tarardım. Hiçbir barındırma sağlayıcısı port tarama bildirimi almak istemez, bu yüzden taramanın kaynak adresini itibarlı ve masum bir bulut sağlayıcısının IP’si gibi gösterirseniz yansıtma sunucuları UDP yanıtlarını oraya gayet güzel gönderirdi
    Bulut sağlayıcısı doğal olarak bir sürü bildirim alırdı, ama benim sunucumdan tarama yapılmadığını söylediğinizde sağlayıcı bunu doğrular ve hizmeti kapatmazdı. Spoof edilmiş tarama paketlerini gönderen sunucu tespit edilemediğinden, olağan kötüye kullanım bildirimleri sorununa takılmadan tüm interneti tekrar tekrar taramak mümkün olurdu
    Bunun gerçekte ne kadar sık olduğunu bilmiyorum ama iletim sağlayıcılarıyla iş birliği yapıp atlamaları geriye doğru izlerseniz spoof edilmiş paketlerin kaynağını bulmak mümkün. Bir keresinde JPMorgan, Cogent ile birlikte çalışıp kendi IP adreslerine paket göndermemem gerektiğini bildirmişti. Bu arada Cogent, internetin Tier 1 sağlayıcıları arasında spoofing’e epey müsamahalı olanlardan biri
    Bu yöntemin özellikle Tor hedef alınarak kullanıldığını ilk kez duyuyorum ve bu biraz sezgilere aykırı. Çünkü spoof paketleri gönderen tarafın Tor destekçisi olmasını beklersiniz. Muhtemelen sadece bir trol ve neyse ki Tor barındıran sağlayıcılar bu tür şeyleri çok da umursamayacaktır

    • Cogent genel olarak da pek iyi görünmüyor
      Sadece bir trol olabilir ama Tor gözetim faaliyetlerine engel olduğu için, ona radyoaktif atık muamelesi yaptırmaya çalışan bir taraf da olabilir

  • Bu yeni bir şey değil. Yıllar önce çok basit bir güvenlik duvarı kuralı yazmıştım; hedef portu 22 olan ve SYN=1, ACK=0 taşıyan gelen TCP paketlerinde kaynak IP’yi bir günlüğüne engelliyordu
    Sonra bazı site ve hizmetlerin çalışmadığına dair şikâyetler geldi; meğer birkaç günde bir 8.8.8.8, 1.1.1.1, Steam, Roblox, Microsoft, Facebook, Instagram ve çeşitli sohbet hizmetleri gibi popüler sunucuların IP’lerinden bu tür paketler geliyormuş. Elbette bunların hepsi spoof paketleriydi ve sonunda güvenlik duvarı kuralına biraz daha doğrulama ekledim
    Bu yüzden bunun oldukça yaygın olduğundan eminim. Kişisel olarak birden fazla IP adresi işleten istisnai bir durumda olduğumu biliyorum, ama kaynak adreslerimden herhangi birini kullanarak herhangi bir ISP üzerinden paket gönderebilme esnekliğine ihtiyacım var. Bu benim için önemli; ISP kaynak adresine göre filtreleme yaparsa bunu sözleşmeyi sonlandırma sebebi sayar ve başka bir ISP’ye geçerim

    • Gerçekten kendi IP adreslerinize sahipseniz bu normal ve beklenen davranıştır. Ama ISP A’nın IP adreslerini ISP B üzerinden ya da tersini kullanabiliyorsanız, bu her zaman bir hataydı ve böyle kullanılmamalıydı
      İkincisi daha çok “spacebar ile ısıtmayı yeniden açmak” gibi bir kategoriye giriyor ve ISP’lerin bozuk ağlarını düzeltmesini umuyorum
    • Somut bir gerçek örnek vereyim
      Bir şirkette şubenin şirket içi ortamında bazı web varlıkları barındırılıyordu ve orada 1Gbps hat vardı. Merkezde ise birkaç 10G hat ve oldukça iyi bir veri merkezi olduğundan, web VM’lerini merkeze taşıdık ama atanmış IP adresini, yani ISP-A’nın herkese açık statik IP’sini koruduk. Merkeze VPN ile yönlendirme yaptık ve sunucu, varsayılan ağ geçidini kullanarak ISP-B’nin 10G hattı üzerinden ISP-A kaynak IP’li yanıtlar gönderdi
      Böylece gelen trafik 1G ile sınırlı olsa da giden trafikte 10G kullanılabildi. Zaten sadece GET istekleriydi. En iyi kurulum değildi ve sonunda IP’yi değiştirdik ama geçerli bir kullanım senaryosu gibi görünüyor
      İkinci olarak, iki farklı ISP hattımız, kendi ASN’imiz ve kendi /23 bloğumuz vardı. Bir miktar trafiği yük dengelemek için IP’lerin yarısını ISP-A’ya, geri kalanını ISP-B’ye verdik. Güzel çalıştı ama dengeyi biraz karıştırmaya çalışınca ilginç bir sorun ortaya çıktı. İlk /24’ü ISP-A’ya, ikinci /24’ü ISP-B’ye duyurmuştuk ama ISP-A tarafında RP filtering vardı. Bu yüzden tüm IP’leri oraya da duyurmak zorunda kaldık
      RP filtresinin çalışma biçimi yüzünden prepend gibi şeyler yapamazsınız ve tüm trafiğin onlar üzerinden gelmesi gerekir. İlgili prefix için daha iyi bir yol görürse filtreler. Aylarca bunu güvenlik gerekçesiyle düzeltmeyi reddettiler. Madem güvenlik için en iyi uygulama diyorlardı, ISP’nin adını da verebilirim: Virgin Media
      Bu arada rp_filter olan internet hattı aylık 20 dolarlık değil, aylık 5 bin doların üzerindeydi. O bölgede alternatif olmadığı için değiştiremedik ama olsaydı sözleşmeyi kimin kaybedeceği belliydi
    • Normalde her yerde rp_filter açan biri olarak, neden böyle bir esnekliğe ihtiyaç duyulduğunu gerçekten merak ediyorum
    • Teknik olarak böyle ISP’ler de ihlal durumunda olurdu. Kendi ASN’iniz gerekir

  • “Birileri Tor relay’lerinden nefret ediyor” hipotezi, harcanan çabaya kıyasla pek ikna edici görünmüyor
    Kötü niyetli relay’leri işleten taraf, meşru relay’leri etik dışı yollarla devre dışı bırakarak kendi kontrol ettikleri ağ oranını artırmaya çalışıyor olabilir

    • Neredeyse kesin olarak olan bu gibi görünüyor. Burada, çok da büyük olmayan bazı node’ların loglarına erişebilen bir saldırganın kişilerin hizmetlere erişim kalıplarını ne kadar kolay görebileceği konusunda epey gerçeklikten kaçış var
    • Tor ağından nefret ediyorsanız daha kolay yol, trafiği boca edip hizmeti yavaşlatmaktır
      Birkaç BitTorrent indirmesi çalıştırmak bile yeterli olabilir

  • Spoofing’in artık mümkün olmaması için, BCP38 uygulamayan tüm AS’lerin trafiğini yeterli sayıda ağ işletmecisinin reddetmesi için ne gerekir?

    • Tek başına Cloudflare bile muhtemelen yeterli olabilir
      Zaten yeterince fazla inbound trafiği kontrol ediyor, dolayısıyla “bağlantı güvenliği kontrol ediliyor” ifadesi gerçekten bir anlam taşıyabilir
    • Ağ işletmecilerinin bunu önemsemesini sağlayacak bir yol bulmak gerekiyor. Özellikle tier-1 taşıyıcılar ya da anormal derecede büyük ağlar önemli
      Yine de yansıma amplifikasyon katsayısını düşürmek çok daha kolay. Çünkü IPv4’te yansıma vektörleri taranabiliyor ve giren baytın 10 katı kadar yanıt verenlere itiraz edilebiliyor

  • Bu, swatting ile benzer bir sorun. Doğrulanmamış bir sorun ihbarına dayanarak yetkili bir tarafın güçlü önlemler almasına bel bağlıyor
    Farkı ise, yetkili kişiyle doğrudan iletişime geçmek yerine alakasız üçüncü tarafların ihbar göndermesini sağlaması gibi görünüyor

  • Tek paketlik ve gidiş-dönüşü bile olmayan isteklerde, hizmet reddi düzeyinde trafik söz konusu değilse sistem otomatik olarak kötüye kullanım bildirimi göndermemeli gibi görünüyor
    Özellikle SSH için, herhangi bir handshake gerçekleşmeden önce bunun geçerli bir bağlantı denemesi olduğunu söylemenin bir yolu yok

    • Eğer herkes kötüye kullanım bildirimi yapabiliyorsa, sunucu sağlayıcısı “2 gün içinde yanıt vermezseniz sunucu askıya alınır” gibi sözleşmesel yaptırımları devreye sokmadan önce bildirimi gerçekten doğrulamalı
      Benim ana sunucum da sahte bir kötüye kullanım bildirimi yüzünden kapatılmıştı. Benim IP’mden 1Gbps’yi aşan bir DoS saldırısı geldiğini iddia etmişlerdi, ama sunucu hattım 400Mbps ile sınırlıydı. Biri bildirimi sadece okusaydı bile bunun imkânsız olduğunu anlardı ve tatildeyken telefon desteğiyle iki gün kavga etmek zorunda kalmazdım
    • Ama port taraması gibi, gerçekten kötüye kullanım gibi görünen davranışların sadece o tek paketten ibaret olduğu durumlar da var

  • Bu, IP sürümü bir swatting, patent zorbalığı, masum birine suç atma ya da rakibi ortadan kaldırmak için kullanılan bir DMCA yayından kaldırma talebi gibi
    Özünde, kötüye kullanım önleme mekanizmalarını silaha çevirip hoşlanılmayan hedeflere saldırma yöntemi. Yetkili tarafın zayıf halka hâline gelmesi ve ahlaksız aktörlerin amaçlarına ulaşması için etkin biçimde kullanılabilmesi ilginç, ama tamamen yeni bir olgu değil

    • Akıllıysanız ve kendi relay’iniz de varsa, ne kadar çok başka relay’i devre dışı bırakırsanız kendi relay’inizin seçilme olasılığı da o kadar artar
      metrics.torproject.org’daki relay sayısı ve “advertised bandwidth” grafiğine bakınca büyük bir fark yaratmış gibi görünmüyor, ama yine de ilginç
      En kötü tarafı ise, “Watchdog Cyber Defense”, Spamhaus, Shadowserver veya UCEPROTECT gibi zorba taklidi yapan yerlerin otomatik olarak milyonlarca bildirim gönderebilmesi ve host’ların da IP aralıklarının engelleme listelerine girmesini istemiyorlarsa fiilen bu bildirimlere uymak zorunda kalmaları

  • Bu soruna yönelik in-band bir çözüm yok, ama out-of-band bir çözüm olabilir
    Örneğin (1) hedef ISP’ye ters yönlü trafik aldığı bildirilir, (2) o ISP paketlerin nereden geldiğini doğrular ve ilgili ISP’ye haber verir, (3) kaynak bulunana kadar 2. adım tekrarlanır, (4) ağın o kısmı düzgün çalışana kadar izole edilir
    Sonuçta internet insanlardan oluşuyor

    • İnternetin bir bütün olarak çalışmasının sebebinin, insanlığın bir kısmının dünyanın en abartılı boru oyununu yönetmeyi gerçekten sevmesi olduğu gerçeğine bazen şaşıranlar oluyor
      1. ve 3. adımlar, çok sayıda insanın başkalarının sorunlarını çözmek için ücretsiz çalışmasını gerektiriyor
    • Not: https://news.ycombinator.com/item?id=41985920