İçeriğe geç
Sedat Özdemir
Yazılar

embedded-security

Sokaktaki Lambadan Sunucu Odasına: IoT Güvenliğinde 'S' Harfinin Gizemi

Akıllı cihazlar dünyayı ele geçiriyor ama güvenlikleri hala 90'ların sonunda kalmış durumda. Firmware analizinden network protokollerine, IoT cihazların zayıf noktalarına teknik bir bakış atıyoruz.

Sedat Özdemir
· 4 dk okuma
curl -X POST -d "wifi_ssid=Guest&wifi_pass=$(cat /etc/passwd | base64)" http://127.0.0.1/api/network_config

Yukarıdaki satırı bir web arayüzü isteğinde veya bir UART konsolunda gördüğünde geçmiş olsun, cihazın kontrolü artık sende değil. IoT dünyasında "S" harfi güvenliği (Security) temsil eder derler ama hepimiz biliyoruz ki IoT kelimesinde "S" harfi yok. Sahada, testCompany bünyesinde yaptığımız çalışmalarda gördüğümüz en büyük yanılgı, bu cihazların sadece "basit birer sensör" olarak görülmesi. O basit sensör, senin iç ağındaki güvenli bölgeye (DMZ) sıçrama tahtası olduğunda iş işten geçmiş oluyor.

Donanım Kapıyı Açar: UART ve JTAG Gerçeği

IoT güvenliği yazılımdan önce donanımla başlar. Bir cihazı eline aldığında ilk yapacağın şey cihazın içini açıp o meşhur pinleri aramak olmalı. Çoğu üretici, geliştirme aşamasında hata ayıklama (debugging) için UART (Universal Asynchronous Receiver-Transmitter) pinlerini anakart üzerinde bırakır. TX, RX, VCC ve GND pinlerini bulup bir USB-to-TTL dönüştürücü ile bağlandığında, karşına çoğu zaman şifresiz bir root shell çıkar.

Eğer cihaz biraz daha kurumsalsa, üretici UART'ı kapatmış olabilir. İşte burada devreye JTAG girer. JTAG üzerinden işlemcinin register'larına kadar inebilir, çalışma anında (runtime) belleği dump edebilirsin. Bu, kilitli bir kapının anahtarını aramak yerine duvarı komple yıkıp içeri girmek gibidir. Donanım seviyesinde fiziksel erişim varsa, o cihaz artık senin cihazın değildir.

Firmware Analizi: Çöpün İçindeki Elmaslar

Cihazın fiziksel kartına ulaşamıyorsak, üreticinin web sitesinden indirdiğimiz veya bir şekilde ele geçirdiğimiz firmware dosyasını (genellikle .bin, .img) didik didik etmemiz gerekir. binwalk bu noktada bizim en iyi dostumuz.

binwalk -e firmware_dump.bin

Bu komutla dosya sistemini (SquashFS, CramFS vb.) dışarı aktardığımızda, genellikle karşımıza standart bir Linux dizin yapısı çıkar. /etc/shadow dosyasına bakmak ilk refleksimiz olmalı. Eğer burada hash'lenmiş bir root parolası varsa, John the Ripper veya Hashcat ile bunu kırmak çoğu zaman çocuk oyuncağıdır; çünkü IoT üreticileri genellikle "123456", "admin", "password" gibi trajikomik parolalar kullanmayı çok sever.

Ancak asıl hazine /home veya /root dizinindeki konfigürasyon dosyalarında, API anahtarlarında ve sertifikalardadır. testCompany ortamında yaptığımız bir simülasyonda, bir akıllı kameranın firmware'i içinden üreticinin tüm bulut altyapısına erişim sağlayan hardcoded bir AWS Access Key bulmuştuk. Düşünsene, milyonlarca cihazın verisi tek bir konfigürasyon hatası yüzünden ortada.

Protokollerin Karanlık Yüzü: MQTT ve CoAP

IoT cihazları genellikle HTTP kullanmaz. Daha hafif olan MQTT (Message Queuing Telemetry Transport) veya CoAP (Constrained Application Protocol) tercih edilir. MQTT, bir "Broker" üzerinden mesajlaşma mantığıyla çalışır. Eğer broker üzerinde kimlik doğrulama (authentication) yoksa veya zayıfsa, tüm trafiği dinleyebilirsin.

# Tüm konuları (topics) dinlemek için (Wildcard kullanımı)
mosquitto_sub -h 127.0.0.1 -t "#" -v

Yukarıdaki komutu çalıştırdığında, ağdaki tüm cihazların birbirine gönderdiği veriler ekranına düşmeye başlar. Bir akıllı prizin durum bilgisinden, bir fabrikanın üretim hattındaki kritik sensör verilerine kadar her şey... Daha da kötüsü, mosquitto_pub ile bu cihazlara sahte komutlar gönderebilirsin. Bir cihazın "kapıyı aç" komutunu beklediği topic'i biliyorsan, o kapı artık senin için ardına kadar açıktır.

Web Arayüzleri ve Command Injection

IoT cihazlarının web arayüzleri genellikle C veya PHP ile yazılmış, güvenlikten bihaber eski CGI script'lerinden oluşur. Kullanıcıdan alınan input'u direkt olarak sistem komutuna sokan o meşhur system() veya exec() fonksiyonları burada cirit atar.

Örnek bir zafiyetli kod parçası (Pseudo-C):

char cmd[256];
sprintf(cmd, "ping -c 4 %s", user_input_ip);
system(cmd);

Burada user_input_ip kısmına 127.0.0.1; rm -rf / yazdığında ne olacağını hepimiz biliyoruz. Bu tarz açıklar, IoT dünyasında hala "zero-day" olarak değil, standart bir özellikmiş gibi karşımıza çıkıyor. Saldırgan için bu, ağda yanal ilerleme (lateral movement) için altın değerinde bir fırsattır.

Defansif Yaklaşım: Ne Yapmalı?

Eleştirmek kolay, peki bu cihazları nasıl koruyacağız?

  1. Ağ Segmentasyonu: IoT cihazlarını asla ana üretim ağında veya kullanıcı ağında tutma. Onlar için izole edilmiş bir VLAN oluştur ve sadece gerekli portların (mümkünse sadece outbound) dışarı çıkmasına izin ver.
  2. Gereksiz Servisleri Kapat: UPnP (Universal Plug and Play), Telnet ve şifresiz HTTP gibi servisleri cihaz üzerinden devre dışı bırak. Eğer cihaz bunu yapmana izin vermiyorsa, firewall seviyesinde engelle.
  3. Firmware Güncelleme Politikası: Cihazların firmware güncelleme mekanizmasının güvenli olduğundan emin ol. İmzalanmamış firmware kabul eden cihazlar, saldırganın cihazı kalıcı olarak ele geçirmesine (persistence) olanak tanır.
  4. Credential Yönetimi: Default şifreleri asla kullanma. Cihaz ilk açıldığında şifre değişimini zorunlu kılan mekanizmalar kur. Eğer toplu bir dağıtım yapıyorsan, her cihazın kendine has (unique) bir parolası veya sertifikası olmalı.

Sonuçta, IoT güvenliği bir ürün değil, bir süreçtir. Masa lambanın senin domain controller'ına sızmak için bir köprü olarak kullanılmasını istemiyorsan, bu cihazlara birer "bilgisayar" muamelesi yapmaya başlamalısın. Sahada görüşmek üzere.

İlgili yazılar