Sektörde bir Shodan fetişizmi var, farkında mısınız? Herkes 'Bakın Shodan'da açık bir kamera buldum' veya 'Şu kadar IP açıkta' diye tweetler atıp duruyor. Açık konuşalım: Shodan başında sabahlayıp 'IoT güvenliği yapıyorum' demek, sadece vitrin bakmaktır. Prod ortamında, gerçek bir operasyonda Shodan'a güvenmek ise tam anlamıyla delilik. Shodan size sadece kapının önündeki paspası gösterir; kapının arkasındaki 20 yıllık zafiyetleri, berbat yazılmış firmware'leri veya şifrelenmemiş protokolleri değil. Bizim işimiz vitrinle değil, o cihazın kalbiyle.
IoT dünyası şu an siber güvenliğin 'Vahşi Batısı' gibi. Yazılımcıların 'Aman çalışsın da güvenliği sonra hallederiz' dediği, donanımcıların 'Maliyeti düşürelim, TLS kullanmasak da olur' diye düşündüğü bir ekosistemden bahsediyoruz. testCompany'de bu cihazları masaya yatırdığımızda gördüğümüz şey genellikle 1990'ların güvenlik standartları oluyor. Gelin, bu tozlu rafları biraz karıştıralım.
MQTT: Açık Unutulmuş Bir Arka Kapı
IoT cihazlarının birbiriyle konuşmak için en sevdiği protokol MQTT. Hafif, hızlı, tam bir 'set-and-forget' dostu. Ama gel gör ki, varsayılan kurulumlarda kimlik doğrulama (authentication) genelde 'opsiyonel' bırakılıyor. Kırmızı ekip operasyonlarında ağa sızdığımızda ilk baktığımız yerlerden biri bu.
Düşünsenize, fabrikanın tüm sensör verileri veya bir ofisin akıllı kilit sistemleri şifresiz bir şekilde ortalıkta uçuşuyor. Eğer saldırgan yerel ağdaysa (veya zeki bir arkadaşımız MQTT portunu 1883 üzerinden dünyaya açtıysa), tüm trafiği dinlemek çocuk oyuncağı.
Örneğin, basit bir mosquitto_sub komutuyla ağdaki tüm mesajları nasıl görebileceğinize bakalım (Lütfen bunu sadece kendi test ortamınızda deneyin):
# Zararsızlaştırılmış MQTT abone olma komutu
# 127.0.0.1 üzerinde koşan bir broker'daki tüm konuları (#) dinle
mosquitto_sub -h 127.0.0.1 -t "#" -v
Eğer çıktı şu şekilde geliyorsa, o 'akıllı' bina artık pek de akıllı değildir:
devices/office/lock/status unlocked
devices/office/temp/sensor 24.5
devices/admin/credentials {"user": "admin", "pass": "123456"}
Buradaki asıl facia, devices/admin/credentials gibi bir konunun (topic) var olması değil, bu verinin hiçbir şifreleme veya yetkilendirme olmadan 'broadcast' edilmesi. Savunma tarafında ne mi yapmalıyız? MQTTS (TLS üzerinden MQTT) kullanmak lüks değil, zorunluluktur. Ayrıca, her cihazın sadece kendi ilgilendiği 'topic'e erişebilmesi için ACL (Access Control List) tanımlanması şart.
Firmware Analizi: Samanlıkta İğne Aramak
Cihazın dışarıya bakan yüzü (web arayüzü, portları) sağlam görünebilir. Peki ya o cihazın içindeki 'beyin'? Firmware analizi, Red Team operasyonlarının en keyifli ve en 'geek' kısmıdır. Bir .bin dosyasını alıp içindeki dosya sistemini çıkarttığınızda, geliştiricinin orada unuttuğu 'unutulmuş' debug scriptlerini veya 'geçici' backdoorları bulmak çok olası.
Genelde binwalk bu işin kutsal kasesi sanılır. Ama binwalk sadece bir araçtır; asıl iş dosyaları ayıkladıktan sonra başlar.
# Firmware içindeki dosya sistemini ayıklama (Simüle edilmiş)
binwalk -e firmware_v1.0_example.bin
Ayıklanan klasörün içinde etc/shadow dosyasına ulaştığınızda ve orada root kullanıcısının şifre özetini (hash) gördüğünüzde, cihazın tüm kontrolü elinize geçebilir. Birçok IoT üreticisi hala tüm cihazlarda aynı 'hardcoded' root şifresini kullanıyor. Eğer bir cihazın şifresini kırarsanız, dünyadaki tüm aynı model cihazları kırmış oluyorsunuz.
Bu noktada savunma stratejisi net: Firmware imzalama (Firmware Signing). Cihaz, sadece üreticinin özel anahtarıyla imzalanmış güncellemeleri kabul etmeli. Ayrıca, her cihazın kendine has (unique) bir şifresi olmalı; etiketin üzerinde yazan o rastgele karakter dizileri boşuna değil.
Shadow IoT: Gölge Etme, Başka İhsan İstemem
Şirket ağlarında en büyük risklerden biri de 'Shadow IoT'. Çalışanın masasına getirdiği o masum akıllı su ısıtıcısı veya dekoratif Wi-Fi lamba, kurumsal ağın en zayıf halkası olabilir. Biz sızma testlerinde genelde en karmaşık firewall kurallarını geçmeye çalışmak yerine, bu tarz 'oyuncakların' zayıf güvenliğini kullanırız.
Bir akıllı lamba üzerinden ağa sızıp lateral movement (yanal hareket) ile domain controller'a kadar gitmek bir şehir efsanesi değil, acı bir gerçek. Cihazın üzerindeki bir stack overflow zafiyeti, bize ağın kalbine giden bir tünel açabilir.
Ne Yapmalı? (Defansif Bakış Açısı)
IoT güvenliğini sağlamak için 'paranoiak' olmak iyidir. İşte testCompany'de uyguladığımız ve tavsiye ettiğimiz birkaç altın kural:
- Ağ Segmentasyonu: IoT cihazlarını asla ana kurumsal ağa (VLAN) dahil etmeyin. Onlar için izole, internete çıkışı kısıtlanmış bir 'kum havuzu' oluşturun.
- Default Şifrelerin Ölümü: İlk kurulumda şifre değiştirmeyi zorunlu kılmayan hiçbir cihazı prod ortamına sokmayın.
- Gereksiz Servisleri Kapatın: Bir ampulün neden Telnet veya SSH portu açık olur? Port taraması yapın ve işe yaramayan her şeyi kapatın.
- Güncelleme Yönetimi: IoT cihazları genelde 'kur ve unut' mantığıyla çalışır. Ama unutmayın, her cihazın bir ömrü ve yama takvimi olmalı.
İş arkadaşım, dostum; IoT güvenliği sadece bir cihazı 'hacklemek' değil, o cihazın bulunduğu ekosistemi anlamaktır. Shodan'da IP aramak yerine, cihazın firmware'indeki o gizli logic erroru bulduğunda gerçek bir güvenlik uzmanı olursun.
Unutma, her akıllı cihaz aslında içinde Linux koşan küçük bir bilgisayardır ve her bilgisayar gibi o da hatalara gebedir. Önemli olan, o hatayı kötü niyetli birileri bulmadan önce senin keşfetmen ve yamaman.
Bir sonraki teknik derinlikte görüşmek üzere. O zamana kadar, MQTT trafiğinize mukayyet olun!