Piyasada herkes 'Nessus çalıştırdım, IoT cihazı tertemiz çıktı' diye geziyor ya, işte o an benim devreler yanıyor. Abicim, o cihazın içindeki ARM mimarili işlemcide koşan 10 yıllık yamalanmamış BusyBox sürümünü senin o genel geçer, kurumsal ağlar için tasarlanmış tarayıcın rüyasında bile göremez. IoT güvenliği, web uygulama güvenliğine benzemez; burada 'input validation'dan önce 'donanıma fiziksel erişim' ve 'binary analizi' konuşuruz. Prod ortamında 'otomatize araçlarla IoT güvenliği yapıyoruz' demek, sadece kendinizi kandırmaktır; o cihazın kalbine inmeden, firmware'ini deşmeden 'güvenli' diyemezsiniz.
Nesnelerin İnterneti mi, Nesnelerin Rezaleti mi?
Selam millet. Bugün biraz can sıkacağız ama sonunda hepimiz daha bilinçli ayrılacağız. Ofiste, evde, fabrikada her yerimiz 'akıllı' cihazlarla doldu. Akıllı ampuller, IP kameralar, endüstriyel gateway'ler... Hepsi aslında küçük birer Linux bilgisayar. Ama sorun şu: Bu cihazları üreten şirketlerin çoğu donanımcı, yazılımcı değil. Güvenlik ise genellikle 'pazara yetişme' telaşının kurbanı olan en son madde.
Bir Red Teamer olarak testCompany ağında bir IoT cihazı gördüğümde, açıkçası iştahım kabarıyor. Neden mi? Çünkü biliyorum ki o cihazın üzerinde büyük ihtimalle unutulmuş bir debug portu var ya da firmware'in içinde hardcoded bir root parolası bizi bekliyor.
Fiziksel Katman: Kapıyı Kırmak Değil, Zaten Açık Olduğunu Görmek
IoT dünyasında her şey fiziksel erişimle başlar. Bir saldırganın cihazı eline geçirdiğini düşünün. Çoğu cihazın içini açtığınızda karşınıza çıkan o küçük pinler (UART, JTAG) aslında size cihazın ruhunu teslim eder. UART (Universal Asynchronous Receiver-Transmitter) portuna bir USB-to-TTL dönüştürücü ile bağlandığınızda, cihazın boot sürecini izleyebilir, hatta şanslıysanız doğrudan bir root shell'e düşebilirsiniz.
İşte bu yüzden, donanım tasarımı aşamasında bu portların fiziksel olarak devre dışı bırakılması veya şifrelenmesi kritik. Eğer o port orada duruyorsa, şifreleme katmanlarınızın hiçbir önemi kalmaz.
Firmware Analizi: Samanlıkta İğne Aramak (Ama İğne Orada!)
Cihazın firmware'ine (yazılımına) ulaşmak genellikle işin en eğlenceli kısmıdır. Ya üreticinin sitesinden bir .bin dosyası indirirsiniz ya da doğrudan cihazın flash belleğinden (SPI dump) veriyi çekersiniz.
Firmware elimize geçtiğinde ilk durağımız her zaman binwalk olur.
# Firmware içindeki dosya sistemini ayıklama (Temsili/Defanged)
binwalk -e device_firmware_v1.0.bin
Dosya sistemini (genellikle SquashFS) açtığınızda, o meşhur /etc/shadow veya /etc/passwd dosyalarına ulaşırsınız. Buradaki en büyük skandal, birçok üreticinin tüm dünyadaki aynı model cihazlar için tek bir 'root' parolası belirlemiş olmasıdır.
Bir defanged örnek üzerinden gidelim. Diyelim ki /etc/init.d/rcS gibi bir startup script'ini inceliyoruz ve şöyle bir şey gördük:
# MOCK CODE - Zararsızlaştırılmış örnek
# Arka kapı (backdoor) mantığını anlamak için
if [ "$1" == "testCompany_secret_debug_mode" ]; then
/usr/sbin/telnetd -l /bin/sh -p 9999
fi
Bu tarz 'magic string'ler veya debug modları, üretim ortamında unutulduğunda facia yaratıyor. Saldırgan ağ üzerinden basit bir paketle bu modu tetikleyip telnet üzerinden içeri sızabiliyor.
Protokol Seviyesinde Güvenlik: MQTT ve CoAP Gerçekleri
IoT cihazları genellikle HTTP yerine daha hafif olan MQTT veya CoAP gibi protokolleri kullanır. MQTT harika bir protokol ama 'Publish/Subscribe' mantığı düzgün kurgulanmazsa, yetkisiz bir kullanıcı tüm ağ trafiğini dinleyebilir.
Örneğin, ACL (Access Control List) tanımlanmamış bir MQTT broker'ınız varsa, saldırgan # (wildcard) kullanarak her şeyi abone olabilir (subscribe):
# MOCK PYTHON CODE - Sadece mantığı anlatmak için
# Zararsızlaştırılmış MQTT dinleme scripti
import mock_mqtt_library as mqtt
def on_message(client, userdata, msg):
print(f"Topic: {msg.topic} | Veri: {msg.payload.decode()}")
client = mqtt.Client()
client.connect("127.0.0.1", 1883) # Yerel test IP'si
client.subscribe("#") # Tüm kanallara sızma teşebbüsü (Wildcard)
client.loop_forever()
Savunma tarafında ne yapmalı? TLS kullanmak zorunluluktur. Ama sadece TLS yetmez; cihaz bazlı sertifikalar ve her cihazın sadece kendi topic'ine yazabildiği sıkı ACL kuralları şart.
Yazılımcılar İçin Savunma Reçetesi (Hardening)
Eğer bir IoT cihazı için kod geliştiriyorsanız, şu altın kuralları aklınızdan çıkarmayın:
- Gereksiz Servisleri Kapatın: Eğer cihazın web arayüzüne ihtiyacı yoksa, HTTP server çalıştırmayın. Telnet'i unutun, illa uzaktan erişim gerekiyorsa sadece SSH (anahtar tabanlı) kullanın.
- Hardcoded Credentials Yasak: Her cihaz kurulumda benzersiz bir parola oluşturmalı veya kullanıcıyı parola değiştirmeye zorlamalıdır.
admin:admindevri 20 yıl önce bitti. - Güvenli Boot (Secure Boot): Cihazın sadece sizin tarafınızdan imzalanmış firmware'i çalıştırmasını sağlayın. Donanım seviyesinde doğrulama yapın.
- Firmware Şifreleme: Firmware'iniz internetten indirilebilir durumdaysa, içindeki hassas verilerin okunmasını zorlaştırmak için dosya sistemini şifreleyin.
- Güncelleme Mekanizması (OTA): Cihazlarınızı uzaktan ve güvenli bir şekilde güncelleyebilmeniz lazım. Ama dikkat! Güncelleme sunucusu da bir hedeftir. İmzasız güncellemeleri asla kabul etmeyin.
Sonuç Niyetine Değil, Süreç Niyetine
IoT güvenliği 'yaptım oldu' diyebileceğiniz bir şey değil. Bu bir döngü. Bugün güvenli dediğiniz kütüphanede yarın bir RCE (Remote Code Execution) çıkabilir. testCompany bünyesinde yaptığımız testlerde de görüyoruz ki; en zayıf halka genellikle 'aman bu cihazdan ne olur ki' denilen o küçük sensor veya akıllı priz oluyor.
Donanımı hafife almayın, firmware'i kurcalamaktan korkmayın ve asla ama asla varsayılan ayarlara güvenmeyin. Siber dünyada paronaya bir hastalık değil, hayatta kalma becerisidir.
Bir sonraki yazıda belki biraz daha derinlere, radyo frekanslarına (RF/SDR) ineriz, ne dersiniz? O zamana kadar, cihazlarınıza iyi bakın, açık port bırakmayın!