Milyonlarca modemin hacklenmesi ve kendi modem ihlalimin incelenmesi

 (samcurry.net)
2 puan yazan GN⁺ 2024-06-05 | 1 yorum | WhatsApp'ta paylaş
  • Ev ağındaki HTTP isteklerinin yaklaşık 10 saniye sonra DigitalOcean IP üzerinden birebir yeniden oynatıldığı görüldü; bu da Cox Panoramic Wifi ağ geçidinin arkasındaki birden çok cihazın trafiğinin dışarı sızmış olabileceğini ortaya koydu
  • VirusTotal ve URLscan incelemesine göre ilgili IP, geçmişte phishing domainleri ve kelime+6 rakam+TLD biçimindeki çok sayıda alan adıyla ilişkiliydi; bunun C&C amaçlı bir alan adı üretim algoritması olabileceği değerlendirildi
  • 2024’te Cox Business portalı analiz edilirken /api/cbma/ arkasındaki Spring tabanlı API ve Swagger dokümantasyonunun açıkta olduğu görüldü ve istekleri tekrar göndermekle yetki doğrulamasının atlanabildiği ortaya çıktı
  • Açıkta kalan API; müşteri arama, hesap PII görüntüleme, cihaz MAC adresi sorgulama ve WiFi ayarlarını değiştirmeye kadar izin veriyordu; ayrıca encryptedValue üretim mantığı da frontend JavaScript içinden çağrılabiliyordu
  • Cox, bildirimden sonraki 6 saat içinde açık API’yi kapattı; ancak bu hizmet 2023’te başlamıştı, bu yüzden 2021’deki ilk modem ihlalinin nedeni hâlâ ayrı bir mesele olarak kaldı

Ev ağında tespit edilen HTTP istek tekrarları

  • blind XXE zafiyetini test etmek için bir AWS instance’ında Python HTTP sunucusu çalıştırdıktan sonra evdeki bilgisayardan /test123 isteği gönderildi
    • Asıl istek ev IP’si 98.161.24.100 üzerinden ulaştı
    • Yaklaşık 10 saniye sonra bilinmeyen 159.65.76.209 IP’si aynı yolu tekrar isteyerek çağırdı
  • Aynı URL iPhone Safari’den istendiğinde de aynı IP isteği yeniden oynattı
    • Bunun yalnızca ev bilgisayarında değil, ev ağındaki diğer cihazlarda da tekrarlandığı görüldü
  • Yeni AWS instance’ı, Nginx ve bir GCP instance’ında da aynı IP istekleri yeniden oynattı; bu da sorunun AWS kaynaklı olma ihtimalini düşürdü
    • Geriye ISP, modem veya ağ yolunun ele geçirilmiş olması ihtimalleri kaldı
  • IP sahibi sorgusunda 159.65.76.209 adresinin ISP’ye değil DigitalOcean’a ait olduğu görüldü

DigitalOcean IP’sine bağlı geçmiş kötü amaçlı altyapı

  • VirusTotal sorgusunda, geçmişte bu IP’ye çözülmüş alan adları görüldü
    • Son 5 alan adının 3’ü phishing sitesi, 2’si ise posta sunucusu gibi görünüyordu
    • Örnek alan adları:
      • regional.adidas.com.py
      • isglatam.online
      • isglatam.tk
      • mx12.limit742921.tokyo
      • mx12.jingoism44769.xyz
  • isglatam.online ve isglatam.tk, Güney Amerika siber güvenlik şirketi isglatam.com’u hedef alan phishing siteleriydi
    • Gerçek ISG Latam sitesinde bunun Paraguay merkezli bir şirket olduğu ve Crowdstrike, AppGate, Acunetix, DarkTrace, ForcePoint ile iş ortaklığı bulunduğu görülüyordu
  • URLscan’de bu iki alan adının tipik bir BeEF phishing sitesi barındırdığına dair izler vardı
  • Aynı IP; Adidas ile ilgili bir alan adı, ISG Latam phishing’i ve modem trafiğinin yeniden oynatılması gibi görünen etkinliklerle birlikte ilişkilendirildi
    • IP’nin farklı sahipler arasında dönmüş olma ihtimali olsa da etkinlikler arasındaki boşluk uzun olduğundan, hemen başka bir kötü niyetli kullanıcıya yeniden atanmış olması pek olası görünmüyordu

Modemin değiştirilmesi ve 3 yıl sonra yeniden inceleme

  • Kullanılan cihaz Cox Panoramic Wifi gateway idi ve Cox mağazasında yeni bir modemle değiştirildi
    • Eski cihaz ISP’den kiralandığı için iade edilmesi gerekiyordu
    • Firmware dump ya da reverse engineering yapılamadı
  • Yeni modem kurulduktan sonra HTTP isteklerinin yeniden oynatılması tamamen durdu
    • Loglarda artık başka IP görünmüyordu
    • O dönemde eski modemin ele geçirilmiş olduğu sonucu dışında daha ileri inceleme yapmak zordu
  • 2024 başında, yaklaşık 3 yıl sonra güvenlik sektöründen tanıdıklarla yeniden bakılırken limit742921.tokyo, jingoism44769.xyz gibi alan adı biçimlerine dikkat çekildi
    • İlgili IP için reverse IP araması yapıldığında aynı desende 1.000’den fazla alan adı bulundu
  • Alan adı biçiminin tamamı kelime + 6 rakam + TLD yapısındaydı
    • Toplu kayıt ve algoritmik yapı nedeniyle, kötü niyetli operatörlerin C&C sunucu adreslerini gizlemek için kullandığı bir alan adı üretim algoritması gibi görünüyordu
    • Son gözlenen alan adı 17 Mart 2023’te kaydedilmişti ve sonrasında çözümlenen başka host görülmedi
  • Değiştirilen yeni modem de aynı modeldi, ancak Google aramasına göre bu model için kamuya açık bir zafiyet bulunamadı

ISP destek araçları ve TR-069’dan çıkan hipotez

  • Cox modem yeni bir konuma taşınırken, ISP destek temsilcisinin cihaz ayarlarını uzaktan değiştirebildiği görüldü
    • Destek temsilcisi cihaz ayarlarını güncelleyebiliyor, WiFi parolasını değiştirebiliyor ve bağlı cihazları görebiliyordu
  • Bu uzaktan yönetim, 2004’te hayata geçirilen TR-069 protokolü üzerinden yapılıyordu
    • ISP, kendi ağı içindeki cihazları 7547 portu üzerinden yönetiyordu
    • Bu protokol DEF CON sunumlarında da ele alınmıştı, ancak dışa açık bir yüzey değildi
  • İncelemenin odağı protokolün kendisinden çok, temsilcilerin kullandığı dahili cihaz yönetim web sitesi ve onun arkasındaki API’ye kaydı
    • Eğer bu API’ler müşteri cihazlarının ayarlarını okuyup değiştirebiliyor veya komut çalıştırabiliyorsa, modem ihlalinin yolu buradan geçmiş olabilirdi

Cox Business portalındaki API yapısı

  • Cox Business portalı; cihazların uzaktan yönetimi, firewall kuralı ayarlama ve ağ trafiği izleme özellikleri sunuyordu
  • Giriş sayfasındaki frontend JavaScript dosyası main.36624ed36fb0ff5b.js içinden route’lar çıkarıldı
    • /api/cbma/ tabanlı 100’den fazla API çağrısı tespit edildi
    • Örnekler:
      • /api/cbma/voicemail/services/voicemail/inbox/transcribeMessage/
      • /api/cbma/profile/services/profile/userroles/
      • /api/cbma/accountequipment/services/accountequipment/equipments/eligibleRebootDevice
  • /api/cbma/, normal frontend’den farklı yanıtlar verdiği için ayrı bir backend’e giden bir reverse proxy gibi görünüyordu
    • /api/anything_else/example isteği 301 redirect döndürüyordu
    • /api/cbma/example isteği 500 Internal Server Error döndürüyordu
  • Kayıtlı isteklerde kimlik doğrulamayla ilgili çeşitli header’lar bulunuyordu
    • Clientid: cbmauser
    • Apikey: 5d228662-aaa1-4a18-be1c-fb84db78cf13
    • Cb_session: unauthenticateduser
    • Authorization: Bearer undefined
  • HTTP method’u değiştirildiğinde Spring tarzı hata yanıtları döndü; böylece backend’in Spring tabanlı olduğu doğrulandı

Swagger dokümantasyonu ve statik kaynak bypass’ı

  • Spring actuator yolları bulunamadı, ancak Swagger UI yollarının bir kısmına erişilebildi
    • /api/cbma/userauthorization/swagger-ui/index.html yolu yanıt veriyordu
  • İlk yüklenen Swagger sayfası boştu
    • .png, .js, .css gibi statik kaynaklar API proxy’si yerine asıl host yoluna yönlendirildiği için sonsuz redirect oluşuyordu
  • Burp Intruder ile URL sonuna %00 ile %FF arası eklenerek test yapıldığında, URL-encode edilmiş / olan %2f değeri .js sonuna eklendiğinde 200 OK döndüğü görüldü
    • Örnek: /swagger-initializer.js%2f
  • Burp match-and-replace ile tüm statik kaynakların sonuna %2f eklendiğinde Swagger dokümanları düzgün yüklendi
  • Toplamda yaklaşık 700 API çağrısı görüldü
    • account: 115
    • voiceutilities: 73
    • user: 70
    • datainternetgateway: 57
    • accountequipment: 55
    • billing: 53
    • ticket: 52
    • ayrıca profile, voicecallmanagement, voicemail, userauthorization, csr vb.
  • Cihazlar ve müşteri hesaplarıyla doğrudan ilgili API’ler arasında accountequipment, datainternetgateway ve account en önemli olanlar gibi görünüyordu

Tekrarlanan isteklerle ortaya çıkan yetki doğrulama bypass’ı

  • Tüm GET endpoint’lerinde kimlik doğrulama olmadan erişim denenince bazıları auth hatası, bazıları ise 200 OK döndürdü
  • profilesearch endpoint’i ilk başta boş arama sonuçları içeren başarılı bir yanıt döndürüyordu
    • Aynı istek bazen Authorization Error-Invalid User Token döndürüyor, yeniden gönderildiğinde ise başarılı oluyordu
  • Aynı istek birkaç kez tekrar gönderildiğinde yetki hatası kayboluyor ve müşteri arama sonuçları dönüyordu
    • cox araması için 10000+ hits dönüyordu
    • fbi araması ise Cox Business müşterisi olan FBI saha ofislerinin fiziksel adreslerini içeren sonuçlar döndürüyordu
  • API isteklerini tekrarlamakla yetki atlatması mümkün oluyordu ve aynı sorunun 700’den fazla API genelinde etkili olduğu görülüyordu

Müşteri cihazlarına erişim ve hesap sorgulama

  • Cox Business API’sinin konut tipi ağ cihazlarına da erişip erişemediğini görmek için MAC adresi alan basit bir API test edildi
    • Endpoint: /api/cbma/accountequipment/services/accountequipment/ipAddress?macAddress=:mac
  • Kendi Cox hesabındaki MAC adresi alındıktan sonra istek tekrarlandığında, kendi modemin IPv4 adresi döndü
    • Bu API’nin gerçekten Cox cihazlarıyla iletişim kurabildiği doğrulandı
  • Hesap ID’si kullanan cihaz listesi API’si de çalışıyordu
    • Endpoint: /api/cbma/accountequipment/services/accountequipment/v1/equipments/{accountId}
    • Yanıt; internet cihazı, ses cihazı ve TV cihazı bilgilerini içeriyordu
    • Cihaz modeli, cihaz türü, MAC adresi, port listesi ve seri numarası dönüyordu
  • E-posta tabanlı kullanıcı sorgulama API’si de business hesap bilgilerini döndürüyordu
    • Örnek istek: /api/cbma/user/services/user/admin@cox.net
    • E-posta, ad, telefon numarası, durum, yetkiler, profil sahibi olup olmadığı ve alternatif e-posta gibi bilgiler yer alıyordu
  • Benzer bir POST hesap güncelleme isteği de çalıştı; böylece business hesaplarda okuma ve yazma yapılabildiği doğrulandı

encryptedValue ve cihaz ayarlarının değiştirilmesi

  • Donanım ayarı değiştiren isteklerde encryptedValue adlı bir parametre gerekiyordu
    • Örneğin: cihaz parolasını değiştirme, WiFi ayarlarını değiştirme
  • Frontend JavaScript’te encryptedValue üretme ve çözme mantığı izlendi
    • encryptWithSaltandPadding
    • decryptWithSaltandPadding
  • Hesap kaydı sırasında ayarlanan 4 haneli PIN de aynı fonksiyonla şifrelendiği için, tarayıcı debugger’ında ilgili çağrı noktasına breakpoint konup fonksiyon konsoldan doğrudan çağrılabildi
  • Gerçek hesap yanıtından alınan encryptedValue çözüldüğünde şu biçimde değerler görüldü
    • Cox hesap numarası
    • cihaz adı
    • cihaz ID’si
    • bilinmeyen bir değer
    • MAC adresi
    • etiket
  • Hesap numarası gibi alanların çoğu rastgele doldurulup yalnızca MAC adresi geçerli bırakılarak yeni bir encryptedValue üretildiğinde de istek başarılı oldu
    • Sunucu, hesap ID’si ile MAC adresinin eşleşip eşleşmediğini doğrulamıyordu

Rastgele modem ayarlarını değiştirme ihtimali

  • Kendi cihazı üzerinde WiFi SSID’sini Curry olarak değiştiren bir POST isteği gönderildi
    • Endpoint: /api/cbma/accountequipment/services/accountequipment/gatewaydevice/wifisettings
    • İstek gövdesinde wifiSettings, additionalProperties, encryptedValue bulunuyordu
  • Yanıt {"message": "Success"} oldu; ardından ağ kısa süreli kesildi ve yaklaşık 5 dakika sonra cihaz yeniden başladı
    • SSID gerçekten Curry olarak değişti
  • Bu davranış, API üzerinden yapılan cihaz yapılandırma değişikliğinin gerçek cihaza uygulandığını gösterdi
    • Saldırgan müşteri aramasıyla hesap UUID’sini alabilir
    • Bağlı cihazların MAC adreslerini sorgulayabilir
    • Ve MAC adresi tabanlı olarak cihaz ayarlarını okuyup değiştirebilirdi
  • Bu yetki, ISP destek ekibine benzer düzeyde bir erişimdi ve Cox’a ait milyonlarca cihazı etkileyebilecek bir yol sunuyordu

Etki alanı ve saldırı senaryosu

  • Zafiyet kombinasyonu, dışarıdaki bir saldırganın hiçbir ön koşul olmadan şunları yapabileceğini gösteriyordu
    • milyonlarca modemde komut çalıştırma ve yapılandırma değiştirme
    • Cox Business müşterilerinin PII verilerine erişim
    • ISP destek ekibine benzer yetkiler elde etme
  • Cox; ABD’nin en büyük özel broadband sağlayıcısı, üçüncü büyük kablolu TV sağlayıcısı, yedinci büyük telefon işletmecisi ve 10 eyalette en popüler ISP konumunda
  • Örnek saldırı akışı:
    • ad, telefon numarası, e-posta ve hesap numarasıyla Cox Business hedeflerini arama
    • dönen UUID ile hesap PII’si, cihaz MAC adresleri, e-posta, telefon ve adres sorgulama
    • donanım MAC adresiyle WiFi parolasını ve bağlı cihazları görüntüleme
    • rastgele komut çalıştırma, cihaz özelliklerini değiştirme ve kurban hesabını ele geçirme
  • Açıkta olan 700’den fazla API’nin önemli bir bölümü yönetici işlevleri sunuyordu ve tekrar gönderilen isteklerde aynı yetki sorunu yaşanıyordu

Cox’a bildirim ve düzeltme

  • Zafiyetler, Cox’un responsible disclosure program üzerinden bildirildi
  • Cox, bildirimden sonraki 6 saat içinde açık API çağrılarını kapattı ve yetki zafiyetini düzeltmeye başladı
    • Ertesi gün artık zafiyet yeniden üretilemedi
  • Açıklama zaman çizelgesi:
    • 2024-03-04: Zafiyet Cox’a bildirildi
    • 2024-03-05: Hotpatch uygulandı, zorunlu olmayan business endpoint’leri 403 döndürerek çalışmayı durdurdu
    • 2024-03-06: Zafiyetin artık yeniden üretilemediği Cox’a e-posta ile bildirildi
    • 2024-03-07: Cox, kapsamlı bir güvenlik incelemesi başlattığını bildirdi
    • 2024-04-10: Bildirimden 90 gün sonra açıklama yapılacağı Cox’a iletildi
    • 2024-04-29: Blog taslağı bağlantısı Cox ile paylaşıldı

Geriye kalan sorular

  • Cox, belirli zafiyet yolunun geçmişte kötüye kullanılıp kullanılmadığını inceledi ve kötüye kullanım izi bulunmadığını söyledi
    • İlgili hizmet 2023’te devreye alınmıştı
    • İlk modem ihlali 2021’de yaşandığından, açıkta olan Cox Business API zafiyeti o dönemdeki ihlalin nedeni değildi
  • Cox, DigitalOcean IP ile hiçbir ilişkisi olmadığını bildirdi
    • Cihaz gerçekten hacklenmişti, ancak açık API zafiyeti dışında başka bir yöntem kullanılmıştı
  • Modem dış erişime açık olacak şekilde yapılandırılmamıştı ve ev ağından cihaza giriş yapılmamıştı
    • Olası diğer yollar arasında local CSRF’den RCE’ye giden bir 0day benzeri yaklaşım anıldı
  • En büyük soru, saldırganın HTTP isteklerini neden yeniden oynattığı
    • Ağın içindeyse fark edilmeden erişebilirken, neden tüm HTTP isteklerini yeniden oynattığı açıklığa kavuşmadı

İlgili okumalar

1 yorum

 
GN⁺ 2024-06-05
Hacker News yorumları

  • Güzel bir yazıydı ve takip etmesi kolaydı. Özellikle Cox’un ihbarda bulunan kişiye saldırmaması ya da sorunu inkâr etmemesi, bu tür bir durumda beklenebilecek sorumlu güvenlik müdahalesi için örnek sayılabilecek şekilde davranması hoşuma gitti.
    Yetkisiz API erişimine aralıklı olarak izin veren hatanın ne olduğunu bir devam yazısında görmek isterim. Böyle hatalar yüzeysel testlerde kolayca kaçabilir ya da nedenine bağlı olarak test ortamında hiç yeniden üretilemeyebilir.

    • Cox’un sorumlu davrandığı doğru, ama ilk başta enfekte cihazla geldiklerinde bu fırsatı daha iyi değerlendirmelerini isterdim.
      Eskiden geleneksel bir telekom şirketinde ciddi bir güvenlik açığını tesadüfen bulmuştum; sadece genel müşteri destek kanallarıyla doğru kişiye ulaşmam neredeyse bir hafta sürdü ve destek organizasyonu hiç eskalasyon yapamadı. Cox’ta da bir bilgi güvenliği uzmanı enfekte cihazı bizzat getirmiş, ama destek organizasyonu bunu düzgün ele alamamış.
    • Yazı da kolay okunuyordu, Cox’un tepkisi de iyiydi. Keşif sürecini ve hatanın kendisini olumsuz ya da küçümseyici bir dille aktarmamış olmaları da hoşuma gitti.
    • Şirketler böyle şeyleri bulan kişiye “hackledi” diye dava açmak yerine ödül vermeli.
    • Yetkisiz API erişimine aralıklı olarak izin veren hatanın ne olduğunu ben de merak ediyorum. Belki de asla öğrenemeyiz; ama yetkilendirme kontrolü yapmayan bir test backend’inin yanlışlıkla load balancer yapılandırmasına dahil edilmiş olması mümkün.
    • Yazı iyiydi ama “super curious”, “super interesting”, “super interested” gibi super kelimesinin sürekli kullanılması biraz gözüme battı.

  • Bu tür durumlarda sinir bozucu olan şey, ISP’nin kendi modemini ya da router’ını kullanmaya zorlaması. Örneğin AT&T fiber, ağa erişimde sertifika tabanlı 802.1X kimlik doğrulaması kullanıyor; bu olmasa ONT’ye istediğiniz cihazı takabilirdiniz.
    Bypass yöntemleri var ya da vardı, ama internet kullanmak için böyle prosedürlerle uğraşmak istemediğimden AT&T router’ının tüm işlevlerini kapatıp arkasına güncel tuttuğum kendi router’ımı bağlıyorum. AT&T router’ı hacklense bile hizmeti olumsuz etkilemeye başlayana kadar fark etmeyebilirim. Neyse ki bugünlerde çoğu şey HTTPS kullanıyor.

    • ONT’nin modemden ayrı olduğu AT&T fiber’de 802.1X bypass etmek oldukça kolay. Modem ile ONT arasına yönetimsiz switch takıp modemin kimlik doğrulaması yapmasına izin verin, sonra modemi çıkarın.
      ONT yeniden başlatılırsa büyük olasılıkla bunu tekrar yapmanız gerekir, ama benim durumumda AT&T ONT için UPS verdiği için yeniden başlatma sıklığı düşük olur. Kişisel olarak, firewall kapalıyken ya da yeniden başlatılırken trafiğin AT&T modeminden geçtiği; açıkken ise firewall’umun trafiği alıp seçici olarak modem üzerinden ilettiği, bypass NIC tabanlı karmaşık bir kurulum yaptım. Ama aslında sadece yönetimsiz switch kullanmak da yeterli.
    • AT&T CPE router’ının hacklenme ihtimali, ağım ile AT&T ağı arasında kendi router’ım varsa büyük bir fark yaratmaz. AT&T CPE router’ını kaldırsanız bile sonuçta kontrol etmediğiniz bir kara kutuya bağlanıyorsunuz; o cihaz da hacklenmiş olabilir ya da trafiği çeşitli şekillerde inceleyebilir.
    • Neyse ki Cox böyle bir ISP değil. Abone olduğunuz hıza uygun, yeterince modern bir DOCSIS modem varsa kabul ediyor.
      Ama Cox’a övgüm burada bitiyor. İki yıldır aralıklı paket kaybı yaşıyorum; belirli bir node’un muhtemelen aşırı abone yoğunluğunda olduğuna dair veri toplamama rağmen bunu anlayacak birine ulaşacak destek eskalasyon yolu yok gibi görünüyor.
    • Bilgi olarak, xgspon’da bypass süreci artık otomatikleştirilmiş durumda. “SFP+ tak, web arayüzünden firmware yükle, cihaz seri numarasını gir” düzeyinde; kullandığınız SFP modülüne bağlı olarak ikinci adım da atlanabiliyor.
      Gerçekte 802.1X durumu sunucu tarafında doğrulanmıyor. Standart, 802.1X gerekiyorsa ve yapılmıyorsa modemin trafiği iletmemesi gerektiğini söyler; ama çoğu ya doğrudan geçiriyor ya da geçirir hale getirilebiliyor. AT&T tarafı doğrulama yapmıyor ve trafiği her zaman geçiriyor; içeride olan da bu.
    • AT&T gateway’i olmadan bağlanmanın yolları var ve çeşitli yöntemler https://pon.wiki/ adresinde derlenmiş.

  • Akıcı bir yazı ve araştırma da harika. Büyük bir şirketin güvenlik araştırmacısına nükleer bomba atmamasını görmek de güzel.
    Emin değilim ama bu Nokia router’ın yerel yönetici arayüzü isteklerinin düzgün kimlik doğrulamasından geçip geçmediğinden şüpheliyim. Yakın zamanda aynı cihazdan aldım; normal yönetici yetkisiyle değiştirilemeyen ayarlar vardı ve ISP süper yönetici hesabını vermedi. Ama sayfa denetleyicisiyle devre dışı bırakılmış alanları yeniden etkinleştirip değerleri değiştirince API bunları aynen kabul etti. Bu durumda iç ağ içinde bir uygulama çalıştırılabiliyorsa router’ı bu şekilde ele geçirmek çok zor olmazdı; yine de oldukça spesifik koşullar gibi görünüyor.

    • Cox’un ABD’nin en büyük özel geniş bant sağlayıcısı, üçüncü en büyük kablo TV sağlayıcısı, yedinci telefon operatörü ve 10 eyalette en popüler ISP olması, ISP’lerin bu kadar büyük olmaması gerektiğini düşündürüyor.
      Cox açıkça cazip bir saldırı hedefi ve makaledeki örnekte olduğu gibi tek bir güvenlik açığı FBI saha ofislerini bile riske atabilir. “Cox geçmişte kötüye kullanım olup olmadığını araştırdı ve kayıt bulamadı” demek yerine “araştırdığını iddia etti” diye yazmak daha doğru olurdu.

  • “Geçmişte kötüye kullanım geçmişi yoktu” sözüne güvenilebilir mi? Tüm ağ İsviçre peyniri gibi delik deşik görünüyor.

    • Bu yüzden tüm logları yalnızca yazma izni olan bir AWS hesabındaki S3 bucket’ına gönderirsiniz ve o bucket üzerinde başka işlem yapabilen hesaba girmek için üç kişinin onayı gerekir. Cox’un böyle yapıp yapmadığını bilmiyorum, ama “kötüye kullanım geçmişi yok” diyebilecek şekilde tasarlıyorsanız mimari böyle olur.
    • Konuşmayı başlatan tarafsanız sonuna kadar katılmadan kalamazsınız. Bir noktada “elimizdeki bilgi bu kadar ve eskisinden daha iyi durumdayız” demek zorundasınız.
    • “Yok” deniyorsa, zaten enfekte cihazların bulunduğu bir durumda Cox’un bilebileceği ya da bilemeyeceği başka saldırı yolları olduğu anlamına da gelebilir.

  • Birçok yönlendiricide firmware’i elle güncellemek gerekir. GL.iNet yönlendiricilerde son 6 ayda birden fazla uzaktan kod çalıştırma açığı vardı; bu yüzden kendi yönlendiricinizin hack’lenip hack’lenmediğini hızlıca kontrol etmek ve mümkünse firmware’i yükseltmek iyi olur.
    Sıradan kullanıcı açısından görülen belirtiler internet hızında düşüş, Wi-Fi sinyalinin kopması ve cihazların bağlanamaması, yönlendiricinin kendisi internete bağlıyken dahili yönetim sayfasının (192.168.8.1) yanıt vermemesiydi. Benim durumumda saldırgan IPRoyal’ın Pawns uygulamasını kurarak yönlendiriciyi bir proxy sunucusuna çevirmiş ve para kazanmıştı; kullanım süresi ile NAS’a bağlanılıp bağlanılmadığını içeren sistem günlüklerini de çalmıştı ve bir reverse shell’i de vardı. Çözüm için iyi sıra: firmware güncellemesi, yönlendiriciyi sıfırlayarak zararlı yazılımı temizleme, SSH’yi devre dışı bırakma, dinamik DNS gibi uzaktan erişimi kapatma. Uzaktan erişim gerekiyorsa Cloudflare Tunnel, Zero Trust, GoodCloud, ZeroTier, Tailscale gibi şeyler değerlendirilebilir; ama hangisinin uygun olduğundan pek emin değilim. GL.iNet en az ayrıcalık ilkesini izlemiyor, varsayılan olarak süreçleri root ile çalıştırıyor ve SSH de root erişimiyle varsayılan olarak etkin; bu yüzden uzak durmak daha iyi görünüyor.

  • “Kötüye kullanım geçmişi yoktu” denmesi, en başından yeterli günlük ya da denetim verisi olmamasından veya hack’ten sonra günlüklerin kalmamış olmasından kaynaklanıyor olabilir.

    • Yazıda gördüğüm kadarıyla, “yetkisiz isteği başarılı olana kadar yeniden deneme” şeklindeki belirli saldırı yolu günlüklerde çok kolay görünür. Yalnızca yol, IP ve durum kodu tutan temel bir günlük politikası bile yeterlidir; bu da çoğu web sunucusu ve framework’ün varsayılanına yakındır.
    • “Kanıt yokluğu, yokluğun kanıtı değildir” sözü buraya uyuyor.
    • Ya da yalan söylemiş olabilirler. Cox açısından düşününce, geçmişte kötüye kullanım olmuşsa bunu şirket dışından birine neden açıklasınlar? Aslında herhangi bir şeyi açıklamaları için bir neden yok.

  • Hangi kimlik doğrulama sistemi çağrıları bazen rastgele geçirir? Gerçekten beceriksizce görünüyor.

    • Bir vendor API’sinde böyle bir şey bulmuştum. Mevcut kullanıcı sağlayıcısını istek bazında değil singleton olarak kaydetmişlerdi; bu yüzden bazen kimliği doğrulanmış bir kullanıcının kuyruğuna takılıp geçmek mümkün oluyordu.
    • Benzer büyüklükte bir bug da görmüştüm. API tam olarak 10 dakika boyunca kimlik doğrulaması olmayan istekleri reddediyor, ardından tam olarak 1 dakika boyunca izin veriyor ve bu döngü sonsuza kadar tekrarlanıyordu. Backend’de neler döndüğünü gerçekten merak ediyorum.
    • Deneyimime göre bu tür şeyler load balancer yüzünden ortaya çıkabilir. Örneğin havuzdaki sunucuya düzgün yönlendirme yapılamaması ya da sunucular arasında yapılandırma veya yama seviyelerinin farklı olması gibi.
    • İsteklerin yönlendirildiği origin sunucuların bir kısmı yanlış yapılandırılmış olabilir.
    • API bir reverse proxy arkasındaysa cache sorunu da olabilir.

  • Para verdiler mi? Bu kişi Cox’u fiilen kurtarmış ve keşfetmesi de kolay olmayan bir güvenlik altyapısının tamamen ele geçirilmesini bildirmiş.
    “Doğru şeyi” yaptığı için hiçbir şey almamış gibi görünüyor; bu epey aşağılayıcı. Önemli bilgilerle ofise kadar gelen birini şirketin nasıl gördüğü ile kişinin kendi öz algısı muhtemelen çok farklıydı. Bu örnekler, 0day’lerin kesinlikle bildirilmemesi gerektiğini iyi gösteriyor.

    • Cox söz konusuysa, kendi hatalarını düzelten kişiyi dava etmemeleri bile şans sayılabilir.
    • Sam çok tanınmış bir güvenlik araştırmacısı; yılda 350 bin doların üzerinde kazanıyor olsa şaşırtıcı olmaz. Bu tür yazılar itibar artışı üzerinden ciddi para eder.
    • Cox bug bounty ödemiyor.

  • Hâlâ açık kalan soru, saldırganların onun HTTP trafiğini nasıl yakaladığı.
    Bazı CPE’lerde hata ayıklama için bulut Wireshark benzeri bir özellik bulunur. Cox’un üretim firmware imajında böyle bir özellik var mı bilmiyorum. Genelde üretim firmware’i ile test firmware’i ayrı olur; bu da üretim ortamı sorunlarını test etmeyi daha zorlaştırır. Cox sahada hangi firmware sürümlerinin olduğunu kontrol edebilir; ISP, belirli bir sürümle uyuşmayan firmware’i otomatik yükseltebilir ve bu bir Cox modemi olduğuna göre firmware’e de sahip olma ihtimalleri yüksek. Eğer debug firmware ise, nasıl yüklendiğini ve nasıl kalmaya devam ettiğini merak ediyorum.

    • Linux’ta PF_PACKET ile socket oluşturursanız tüm arayüzlerin trafiğini yakalayabilirsiniz. Bunu düşük seviyeli tcpdump gibi düşünebilirsiniz.
      80 numaralı porttaki tüm verileri yakalayıp HTTP header’larını parse ettikten sonra gerekeni yapmak kolaydır. Yine de birinin isteği neden yeniden oynattığını pek bilmiyorum.
    • HTTPS değil de HTTP ise, hat üzerindeki herhangi biri, herhangi bir cihaz isteği görebilir.
    • ISP’nin verdiği ekipmana güvenmemek ve kullanmamak için bir neden daha. ISP’nin uzaktan yönetimi mi? Kalsın.

  • Wi-Fi özelliği olan ISP tarafından sağlanan kablo modemleri sevinçle karşılamamamızın ve LAN içindeki endpoint ile servis güvenliğini iyi yapmamızın nedenlerinden biri de bu. En azından modem/ISP hattında TLS ve DNS over TLS gerekiyor.
    Ben sadece bridge moduna alıp Wi-Fi’yi kapatıyor, tüm ağ işlevlerini kendi ekipmanıma bırakıyorum. ISP’den kiraladığım son modeme ISP neredeyse 10 yıl firmware güncellemesi yapmamıştı; bu sayede gayet kararlıydı gerçi.

    • Buna karşı görüş de var. 1 milyondan fazla müşterisi olan ISP’ler, yatırım maliyetlerini düşürmek için ev gateway’lerini “sonsuza kadar” yükseltme motivasyonuna sahiptir.
      Çalıştığım Free, Fransa’da bir ISP ve Iliad olarak İtalya’da da ev gateway’i sağlıyor; 2011’de piyasaya çıkan cihazları bile hâlâ güncelliyoruz. En güncel Linux 6.4 çalışıyor; airtime QoS gibi modern özellikler, mobil uygulama güncellemeleri ve çeşitli yazılım özellikleri de sunuluyor.
    • Yönlendiriciler dünyada en çok istismar edilen IoT cihazları arasında ve son kullanıcılar yama yapmadığı için firmware açıkları çoğu zaman yıllarca kalıyor. ISP yönlendiricilere yamaları itebiliyor ve yamalanamayan cihazları geri toplayabiliyorsa, mülkiyetin ISP’de olması dahil siber güvenlik açısından net faydadır.
    • Ben de bridge moduna alıp Wi-Fi’yi kapatıyorum. Bir şekilde yönlendirici ve erişim noktası işlevi olmayan basit bir modem kurdurmuştum; böyle tek amaçlı cihazların hâlâ olduğunu bilmiyordum.
      Nispeten iyi bir yönlendirici alıp OpenWrt kurdum, ardından ISP ekipmanı üzerinden ağa bridge olarak bağladım ve iyi çalışıyor. Artık LAN içinde de HTTPS kullanıyorum.
    • Kendi yönlendiricimi kullanmama izin vermezlerse başka bir ISP’ye geçeceğimi söyledim.