Sektöre ilk girdiğim yıllarda, 'testCompany' bünyesinde yürüttüğümüz bir projede akıllı termostatları test etmem gerekiyordu. O zamanlar heyecanlıyım, elimde yeni bir firmware var ve cihazın içine sızmak için sabırsızlanıyorum. Bir komut satırı hatası yüzünden, test ortamındaki tam 50 adet termostatı aynı anda 'brick' ettim, yani tamamen kullanılmaz hale getirdim. Ofis bir anda buz kesti; çünkü o cihazlar artık sadece duvarda asılı duran pahalı plastik parçalarıydı. O gün öğrendiğim en büyük ders şuydu: IoT dünyasında bir şeyi bozmak çok kolaydır, ama o deliği kapatmak bazen imkansıza yakındır.
IoT (Internet of Things) dünyası, biz Red Teamer'lar için aslında devasa bir oyun alanı. Neden mi? Çünkü üreticiler genellikle hıza odaklanıyor ve güvenlik, o parlak plastik kasaların içinde kendine yer bulamıyor. Akıllı bir tost makinesinden tutun da endüstriyel kontrol sistemlerine kadar her şey temelde aynı zafiyetlerle boğuşuyor. Gel, bu 'akıllı' ama bir o kadar da savunmasız dünyada neler dönüyor, beraber bakalım.
İlk Durak: Varsayılan Ayarların Laneti
Sahada gördüğümüz en temel hata, hala ve ısrarla değiştirilmeyen varsayılan kullanıcı adları ve şifreler. Bir cihazı ağa bağladığınızda, eğer admin:admin veya root:12345 gibi kombinasyonlarla erişilebiliyorsa, o cihaz artık sizin değil, internetteki herkesindir. Shodan gibi arama motorlarında basit bir filtreleme yaparak binlerce kameranın veya endüstriyel panelin açık olduğunu görmek mümkün.
Bir cihazın ağdaki ayak izini sürmek için genelde şu basit nmap komutuyla başlarız:
# IoT cihazındaki açık servisleri ve versiyonları tespit etmek
nmap -sV -p 22,23,80,443,1883,8080 127.0.0.1
Burada 1883 portuna dikkat. Bu port genellikle MQTT (Message Queuing Telemetry Transport) protokolü için kullanılır. IoT cihazlarının birbirleriyle ve bulutla konuştuğu dildir bu. Eğer şifreleme veya yetkilendirme yoksa, o ağdaki tüm trafiği dinleyebilirsiniz.
MQTT: Duvarların Dili Olsa da Konuşsa
Bir akıllı ev sisteminde lambaların yanıp sönmesi veya kapı kilidinin açılması genelde MQTT mesajlarıyla tetiklenir. Eğer saldırgan bu trafiğe sızarsa, 'Subscribe' yöntemiyle tüm veriyi toplar.
Zararsızlaştırılmış bir örnekle, ağdaki mesajları dinlemek için şöyle bir araç kullanabiliriz:
# MQTT trafiğini dinleyen basit bir pseudo-kod
import paho.mqtt.client as mqtt
def on_message(client, userdata, message):
print(f"Konu: {message.topic} , Mesaj: {message.payload.decode()}")
client = mqtt.Client("RedTeam_Listener")
client.connect("example.com", 1883) # Broker adresi
client.subscribe("home/smart_lock/#") # Kilit ile ilgili tüm alt başlıkları dinle
client.on_message = on_message
client.loop_forever()
Eğer bu sistemde düzgün bir TLS sertifikası veya güçlü bir kimlik doğrulama yoksa, saldırgan sadece dinlemekle kalmaz; sisteme kendi 'Publish' mesajlarını göndererek kapıyı bile açabilir. Düşünsenize, bir 'payload' gönderiyorsunuz ve fiziksel dünyada bir kapı 'tık' diye açılıyor. Bu, dijital güvenliğin fiziksel gerçeklikle en tehlikeli kesişim noktasıdır.
Web Arayüzleri ve Komut Enjeksiyonu
IoT cihazlarının çoğunun bir yönetim paneli vardır. Bu paneller genellikle hafif (lightweight) web sunucuları üzerinde çalışır ve çoğunlukla girdi denetimi (input validation) yapılmaz. Geçenlerde karşılaştığım bir senaryoda, cihazın 'ping testi' yapması için ayrılan bir form alanı vardı.
Eğer girdi şöyleyse:
8.8.8.8 -> Sistem ping 8.8.8.8 çalıştırıyor.
Ama biz araya bir noktalı virgül koyarsak:
8.8.8.8; cat /etc/shadow -> Sistem önce ping atıyor, sonra şifrelerin (hash'lenmiş de olsa) olduğu dosyayı bize kusuyor.
Bu tür bir 'Command Injection' zafiyetini önlemek için geliştiricilerin mutlaka 'whitelist' kullanması ve sistem komutlarını doğrudan çalıştırmaktan kaçınması gerekiyor.
Firmware Analizi: Cihazın Beynine İnmek
Cihaza ağ üzerinden sızamadınız mı? Sorun değil. Cihazın içindeki yazılımı (firmware) bir şekilde ele geçirmek (üreticinin sitesinden indirmek veya fiziksel olarak çipten okumak) her şeyi değiştirir. binwalk gibi araçlar kullanarak firmware'i parçalarına ayırabiliriz.
# Firmware içindeki dosya sistemini ayıklama
binwalk -e smart_bulb_firmware.bin
İçeri girdiğimizde genellikle bizi bir Linux türevi karşılar. Burada grep komutuyla 'password', 'key', 'secret' gibi kelimeleri aratarak hardcoded (yazılımın içine gömülmüş) API anahtarlarını veya SSH şifrelerini bulmak çocuk oyuncağıdır.
Peki, Ne Yapmalı? (Savunma Sanatı)
Cihazları üretiyor veya kullanıyor olmanız fark etmez; şu prensipler hayat kurtarır:
- Ağ Segmentasyonu (VLAN): IoT cihazlarınızı asla ama asla ana bilgisayarlarınızın olduğu ağda tutmayın. Onlar için ayrı, internet çıkışı kısıtlanmış bir 'misafir' ağı oluşturun. Akıllı ampulünüz hacklenirse, en azından şirket veritabanına giden yolda bir engel olsun.
- Gereksiz Servisleri Kapatın: Eğer cihazın bir web arayüzüne ihtiyacı yoksa, o servis kapatılmalı. Telnet gibi 90'lardan kalma şifresiz protokolleri zaten hayatınızdan çıkarın.
- Güncelleme Yönetimi (OTA): Cihazların güncellenebilir olduğundan ve bu güncellemelerin imzalı (signed) olduğundan emin olun. Sahte bir firmware güncellemesiyle tüm cihazları birer zombi bilgisayara (botnet) çevirmek çok kolaydır.
- Girdi Denetimi: Geliştiriciyseniz, kullanıcıdan gelen her verinin 'zehirli' olabileceğini varsayın. Asla
system()veyaexec()gibi fonksiyonlara doğrudan veri göndermeyin.
IoT dünyası, 'çalışsın da gerisi mühim değil' mantığıyla ilerlediği sürece biz Red Team ekiplerine daha çok iş düşecek. İşin özü şu: Bir cihaz ne kadar 'akıllı' görünüyorsa, o kadar çok potansiyel hata barındırıyordur. Cihazlarınıza birer küçük bilgisayar gözüyle bakın ve onları öyle koruyun.
Bir sonraki sızma testinde veya kendi evinizdeki o 'akıllı' cihazı kurarken bu anlattıklarımı bir düşünün. Belki o zaman termostatları brick etmezsiniz, ne dersiniz?