Hardware Hacking Notları #2: BLE Akıllı Saatlerde GATT Güvenliği

Saatin güvenliği ekrandan görünmez

Bir akıllı saat, telefona bildirim gösteren küçük bir ekran gibi görünebilir. Güvenlik açısından ise radyo, gerçek zamanlı işletim mantığı, sensörler, firmware ve mobil uygulama arasında çalışan bir IoT düğümüdür. Saatin Bluetooth üzerinden kabul ettiği tek bir yazma isteği; titreşim, alarm, zaman senkronizasyonu, firmware kontrolü veya cihazın yeniden başlatılması gibi sonuçlar doğurabilir.

MUCAHIC’in Dossier-02 çalışması, fason bir RW-32 akıllı saat üzerinde BLE protokolünü ve GATT servislerini inceleyen bir laboratuvar notu olarak yayınlandı. Çalışmanın ana bulgusu, güvenliğin yalnızca Bluetooth bağlantısının şifreli olup olmamasına indirgenemeyeceği. Cihaz bağlantıyı kabul ediyor, fakat hangi peer’ın hangi characteristic’e hangi koşullarda yazabileceğini yeterince doğrulamıyorsa saldırı yüzeyi bağlantı kurulduğu anda açılıyor.

Buradaki gözlemler tek bir cihaz örneğine aittir. Aynı model adını taşıyan farklı üretim partileri, firmware’ler veya mobil uygulamalar farklı davranabilir. Bu nedenle bulguları bütün BLE cihazlarına genellemek yerine, GATT yetki modeli için bir test deseni olarak okumak gerekir.

BLE yığını: Hangi katman neyi korur?

BLE güvenlik testinde en sık yapılan hata, tüm katmanları “Bluetooth” diye tek bir kutuya koymaktır. Oysa cihazın radyo tarafı ile uygulama verisi arasında farklı sorumlulukları olan katmanlar vardır.

Physical Layer / PHY
        ↓
Link Layer (LL)
        ↓
HCI — Controller ↔ Host sınırı
        ↓
L2CAP
        ↓
ATT + Security Manager (SM)
        ↓
GAP / GATT
        ↓
Mobil uygulama ve cihaz iş mantığı

Controller ve Link Layer

Controller tarafında radyo zamanlaması, kanal kullanımı, advertising ve bağlantı olaylarının zamanlaması yürütülür. Link Layer, bağlantı durum makinesini yönetir. Bir paketin zamanında gelmemesi, bağlantı aralığının bozulması veya bağlantının kopması gibi davranışlar burada ortaya çıkabilir.

HCI

Host ile Controller arasındaki Host Controller Interface, özellikle donanım araştırmalarında önemli bir sınırdır. Bir cihazın radyo yeteneği çalışırken üst yazılımın yanlış bir komut üretmesi veya HCI üzerinden kabul edilen bir olayın yeterince doğrulanmaması, uygulama seviyesine taşınan bir güvenlik sorunu doğurabilir. HCI trafiği, üreticiye ve kullanılan yığına göre farklı görünür; tek bir cihazdan alınan kayıtlar genel BLE protokolünün tamamı değildir.

L2CAP ve ATT

L2CAP, üst katman protokollerinin veri taşıma kanalını sağlar. Attribute Protocol (ATT) ise istemcinin bir attribute’u keşfetmesi, okuması, yazması veya değişiklik bildirimi alması için kullanılan istek–yanıt kurallarını tanımlar. Güvenlik testinde gördüğümüz “read”, “write”, “notify” ve “indicate” izinleri bu veri modelinin parçasıdır.

GAP

Generic Access Profile cihazın çevreye kendini nasıl tanıttığını, hangi rolde çalıştığını ve bağlantının nasıl kurulacağını belirler. Akıllı saat çoğunlukla GATT server/peripheral, telefon ise GATT client/central rolündedir. Fakat test aracı olarak bir ESP32 central rolünde çalıştırıldığında, telefon uygulaması olmadan saatle doğrudan konuşmak mümkün olabilir.

GATT

Generic Attribute Profile cihazın sunduğu servisleri, characteristic’leri ve descriptor’ları düzenler. Bluetooth SIG standart servisleri 16-bit UUID’lerle tanımlanabilir; üreticiye özel servisler çoğunlukla 128-bit UUID kullanır, ancak fason cihazlarda kısa veya standart dışı görünen UUID’lerle de karşılaşılabilir. Bluetooth SIG’nin BLE primer’ı, GATT keşfi, characteristic okuma/yazma ve notification prosedürlerinin ATT üzerine kurulduğunu açıklıyor. Bluetooth LE primer

Pairing, bonding ve authorization aynı şey değil

Bir cihazın “bağlantıyı kabul etmesi”, karşı tarafın her veriye yetkili olduğu anlamına gelmez. Bu üç kavramı ayırmak gerekir:

• Pairing: İki cihazın güvenlik anahtarlarını üretme ve kimlik doğrulama süreci.
• Bonding: Üretilen anahtarların sonraki bağlantılarda kullanılmak üzere saklanması.
• Authorization: Belirli bir işlemin veya characteristic erişiminin gerçekten izinli olup olmadığı.

GATT server bağlantıyı pairing istemeden kabul edebilir; bazı servisleri açık bırakıp hassas characteristic’leri yalnızca şifreli bağlantıda sunabilir. Güvenlik kusuru, açık bir servis ile yazılabilir bir kontrol kanalı arasında ayrım yapılmadığında ortaya çıkar.

Bluetooth Core Specification, LE Security Mode ve LE Secure Connections için farklı seviyeler tanımlar. LE Secure Connections, P-256 tabanlı anahtar anlaşması ve AES-CMAC gibi mekanizmalar kullanır; ancak bu mekanizmanın varlığı, uygulamanın her characteristic için doğru izin kontrolü yaptığı anlamına gelmez. Bluetooth Core Specification – Security Manager

NIST’in Bluetooth güvenlik rehberi de güvenliğin yalnızca radyo şifrelemesinden ibaret olmadığını; cihaz keşfi, eşleştirme, anahtar yönetimi ve uygulama konfigürasyonunun birlikte değerlendirilmesi gerektiğini vurgular. NIST SP 800-121 Rev. 2

Laboratuvar yaklaşımı

İnceleme, gerçek bir kullanıcının saatine veya yakındaki cihazlara müdahale etmek yerine, araştırmacının sahip olduğu cihaz üzerinde yürütülmelidir. Güvenli bir test planı şu sırayı izler:

1. Cihazın modelini, firmware bilgisini ve test tarihini kaydet.
2. Cihazı fabrika ayarlarına döndürerek eski bond kayıtlarını temizle.
3. ESP32 veya başka bir central ile yalnızca keşif ve bağlantı gözlemi yap.
4. GATT tablosunu çıkar; servis, characteristic, descriptor ve izinleri kaydet.
5. Önce salt-okunur characteristic’leri test et.
6. Yazma testlerini tek characteristic ve tek değer ile sınırla.
7. Her deneme arasında cihaz durumunu, yeniden başlatmayı ve bağlantı kaybını ölç.
8. Tekrarlı davranış üretmeden önce watchdog, güç kesme ve kurtarma planını hazırla.

Bu yaklaşımın amacı “ne yazarsam ne olur?” merakı değil; hangi izin modelinin hangi işlevi koruduğunu kanıtlamak. Üretim cihazlarında rastgele characteristic yazmak, veri kaybı veya kalıcı brick riski yaratabilir.

RW-32 üzerinde gözlenen erişim problemi

MUCAHIC notlarında, test cihazına central rolündeki ESP32 ile doğrudan bağlantı kurulabildiği ve Security Manager seviyesinde beklenen eşleştirme adımının tetiklenmediği aktarılıyor. Cihazın bağlantıyı kabul etmesi, araştırmacıya GATT tablosunu çıkarmak için bir pencere açmış.

Bu bulgu Broken Access Control sınıfına oturuyor: sistem bağlantı kurulmasını bir kimlik kanıtı gibi kullanıyor, fakat kritik attribute’ların erişimini ayrıca güvenceye almıyor. Burada dikkat edilmesi gereken nokta, BLE’nin “şifrelenmemiş” olduğu iddiasından daha dar ve daha teknik: cihazın hangi servisleri açık bıraktığı, hangi characteristic’leri yazılabilir yaptığı ve bu yazma işlemlerini hangi güvenlik seviyesine bağladığı.

GATT envanteri

Test sırasında standart servislerin yanında üreticiye özgü veya işlevi belirsiz servisler görüldü. Kaynak notlarda şu UUID’ler öne çıkıyor:

• 0x180D: Heart Rate Service olarak tanımlanan standart servis.
• 0x180F: Battery Service. Kaynak notta kısa yazılmış değer, Bluetooth SIG atamalarında Battery Service UUID’si olan 0x180F olarak okunmalı.
• 0x1802: Immediate Alert Service.
• 0x3802, 0xAA02 ve 0xFEE7: cihazın üreticiye özel kontrol kanalları olabileceği değerlendirilen servisler.

Bir UUID’nin standart olması onun otomatik olarak güvenli olduğu anlamına gelmez. Aynı şekilde 128-bit veya tanımsız görünen bir UUID de tek başına kötü niyet kanıtı değildir. Asıl inceleme, attribute permissions ve değer işleme kodundadır.

Bilgi sızıntısı: küçük değer, büyük bağlam

Kaynak çalışmada pil seviyesi okunabildi ve cihazın dahili yazılım kod adı olarak “leopard” benzeri bir değer gözlendi. Cihaz adı da GATT değerleri içinde RW-32 olarak görülebildi. Pil seviyesi tek başına yüksek etkili bir veri olmayabilir; fakat şu bilgiler bir araya geldiğinde cihaz parmak izi oluşturur:

• model veya ürün adı,
• firmware kod adı,
• pil seviyesi,
• servis ve characteristic haritası,
• kullanılan üretici UUID’leri,
• uygulamanın hangi servislerle konuştuğu.

Bu veriler, hedef cihazın aynı model olup olmadığını anlamayı ve sonraki testleri daraltmayı kolaylaştırır. Sağlık sensörü servisi listeleniyor diye nabız veya uyku verisinin gerçekten açıkta olduğu sonucuna varılmamalı; bunun için değer okuma, bildirim ve uygulama akışı ayrı ayrı doğrulanmalıdır.

Standart servis ile özel komut kanalı arasındaki fark

0x1802 Immediate Alert Service ve 0x2A06 Alert Level characteristic’i Bluetooth SIG tarafından tanımlanmış standart bir alarm modelidir. Kaynak çalışmada bu characteristic’e beklenen tek byte’lık bir değer gönderildiğinde saatin beklenen titreşim davranışının oluşmadığı, cihazın ise farklı bir üretici komutunu beklediği değerlendiriliyor. Bluetooth Assigned Numbers

Bu küçük sonuç önemli. Bir üretici standart servisi tabloya eklemiş olabilir; fakat gerçek uygulama mantığı başka bir proprietary characteristic üzerinden yürüyebilir. Güvenlik değerlendirmesi “standart servis var” noktasında bitmemeli. Mobil uygulamanın hangi UUID’ye hangi paket formatını gönderdiği, descriptor’ların ne söylediği ve cihazın yanlış biçimli değerlerde nasıl davrandığı incelenmeli.

Yazılabilir proprietary characteristic ve uzaktan DoS

Kaynak laboratuvar notlarında 0x3802 servisi altındaki 0x4A02 benzeri bir characteristic’in yazma izni açık bulunduğu, başka bir özel characteristic’e de yazılabildiği ve 0x01 değerinin gönderilmesinden sonra saatin tekrar tekrar yeniden başladığı aktarılıyor. Aynı değerin sürekli gönderilmesi cihazı kullanılmaz hâle getiren bir remote denial-of-service davranışı oluşturmuş.

Bu gözlemi doğru çerçevelemek gerekir:

• Bu, üretici firmware’inin belirli bir sürümünde, belirli bir yazma yolunda gözlenen bir laboratuvar davranışıdır.
• “Her RW-32 cihazı kesin savunmasız” veya “Bluetooth üzerinden kalıcı kontrol sağlandı” sonucu çıkarılamaz.
• Yeniden başlatma, kalıcı firmware bozulmasıyla aynı şey değildir; ancak kullanılabilirlik etkisi yine de güvenlik bulgusudur.
• Kimlik doğrulama, input validation, rate limiting veya güvenli hata yönetimi eksikliği bu davranışı mümkün kılmış olabilir; kök neden firmware incelemesiyle doğrulanmalıdır.

IoT cihazlarında DoS bazen bir “çökme”den fazlasıdır. Saat telefon bildirimlerini kaçırabilir, alarm veya sağlık ölçüm döngüsünü durdurabilir, pil tüketimini artırabilir veya tekrar bağlanma döngüsüne girebilir. Etki analizi cihazın kullanım bağlamına göre yapılmalıdır.

Fuzzing nasıl güvenli yapılır?

BLE fuzzing, rastgele byte’ları kontrolsüz biçimde her characteristic’e göndermek değildir. Daha güvenli bir yöntem:

• UUID ve izin envanterini çıkar;
• characteristic uzunluğu, descriptor ve uygulama paket formatını kaydet;
• geçerli bir mesajı tek alanı değiştirerek mutasyona uğrat;
• her testten sonra bağlantı, cevap, hata ve yeniden başlatma durumunu kaydet;
• cihaz cevap vermiyorsa test döngüsünü durdur;
• yeniden üretilebilir bir tek değer elde etmeden “zafiyet” sonucuna varma.

Özellikle write-without-response işlemleri, cihazın akış kontrolü yoksa hızlı şekilde yük oluşturabilir. Bu yüzden test hızı, bağlantı aralığı, MTU, supervision timeout ve cihazın kurtarma süresi ölçülmelidir.

Üretici tarafında düzeltme modeli

Bir BLE saat veya bileklik için minimum güvenlik tabanı:

1. Hassas servisler için LE Secure Connections ve uygun bonding politikası kullan.
2. Kritik characteristic’leri encryption, authentication veya authorization koşuluna bağla.
3. “Write” iznini yalnızca gerçekten gerekli olduğu yerde aç.
4. Write-without-response akışlarında uzunluk, aralık, sıra ve rate limit kontrolü uygula.
5. Hatalı paketleri yeniden başlatmak yerine güvenli hata koduyla reddet.
6. Watchdog kullan; fakat watchdog’u saldırganın sürekli reboot döngüsüne dönüştürme.
7. Firmware ve OTA güncellemelerini imzalı ve geri dönüş kontrollü tasarla.
8. Üretim imajında debug arayüzlerini, test UUID’lerini ve varsayılan anahtarları kapat.
9. Cihaz adı, firmware kod adı ve sensör durumunu gereksiz yere açık advertising veya GATT alanlarında yayınlama.
10. Mobil uygulamada yalnızca BLE bağlantısına güvenme; uygulama seviyesinde cihaz kimliği ve yetki doğrulaması ekle.

Bluetooth SIG’nin güvenlik ve gizlilik iyi uygulamaları, Secure Connections Only Mode ve yönetilen anahtar yaşam döngüsünü özellikle vurgular. Bluetooth Security and Privacy Best Practices

Savunma ve izleme

Bir kullanıcının telefonunda GATT denetimi yapmak zor olabilir; üretici veya kurumsal filo tarafında aşağıdaki telemetri değerli olur:

• beklenmeyen central adresleri ve yeni bond kayıtları,
• aynı characteristic’e olağandışı yazma sıklığı,
• kısa sürede tekrarlayan disconnect/reconnect olayları,
• watchdog reset ve boot reason kayıtları,
• firmware veya ayar değişikliği,
• cihazın advertising adında veya servis listesinde beklenmeyen değişiklik.

Ölçüm cihazı sınırlıysa, telefon uygulaması ve Bluetooth HCI log’ları birlikte incelenebilir. HCI kaydı gizli anahtarları veya sağlık verilerini gereksiz yere yaymamalı; test sonunda temizlenmeli.

ATT ve GATT’ı kablo üstündeki bir API gibi okumak

GATT tablosu, cihazın dışarı açtığı bir API sözleşmesi gibi ele alınabilir. Her attribute’un bir handle değeri, bir UUID’si, bir türü ve erişim koşulu vardır. İstemci önce servisleri ve characteristic’leri keşfeder; daha sonra belirli handle’lara okuma, yazma veya notification isteği gönderir.

Saldırı yüzeyini anlamak için PDU adlarını bilmek yeterli değildir; isteğin hangi güvenlik seviyesinde kabul edildiğini de kaydetmek gerekir. Yaygın ATT işlemleri şunlardır:

• Exchange MTU Request/Response: Bağlantıdaki taşıma boyutunu müzakere eder. MTU büyüdükçe tek mesajın parçalanma ve buffer sınırı testleri önem kazanır.
• Read By Group Type / Read By Type: Servis ve characteristic tablolarını keşfetmek için kullanılır.
• Read Request / Read Response: Bir attribute değerini okur.
• Write Request / Write Response: Sunucunun onayını bekleyen yazma işlemi.
• Write Command: Yanıt beklemeden gönderilen yazma işlemi; rate limit ve akış kontrolü zayıfsa test yükü hızlı büyüyebilir.
• Handle Value Notification / Indication: Sunucunun istemciye değer göndermesi. Indication onay ister, notification istemez.

Güvenlik incelemesinde şu kayıt formu kullanılabilir:

Handle | UUID | Service | Property | Security | Length | State effect
-------|------|---------|----------|----------|--------|-------------
0x002A | 0x2A06 | 0x1802 | Write | Open? | 1 byte | Alert path
0x00XX | vendor | 0x3802 | Write | Open? | variable | Unknown

Buradaki Open? alanı varsayım bırakmamak için özellikle soru işaretiyle tutulur. Telefon bağlantı kurdu diye “unauthenticated” sonucu yazılmaz; ATT error code, pairing state, link encryption ve GATT permission birlikte doğrulanır.

UUID’leri isimlendirmek neden yetmez?

Bluetooth SIG Assigned Numbers dokümanı 0x180F gibi standart servisleri ve 0x2A06 gibi characteristic’leri tanımlar. Ancak üretici bir UUID’yi tabloya ekleyip kendi protokolünü yazabilir. Aynı UUID farklı firmware nesillerinde farklı anlam taşıyabilir; kısa UUID’nin tanınmıyor olması da tek başına gizli veya tehlikeli olduğu anlamına gelmez.

GATT enumeration sonucunu üç gruba ayırmak daha doğru:

1. Standart ve pasif: Battery Service gibi yalnızca durum okuyan, etkisi sınırlı servisler.
2. Standart fakat kontrol etkili: Immediate Alert gibi yazma ile fiziksel davranış üretebilen servisler.
3. Proprietary ve belirsiz: Üretici UUID’si, firmware güncellemesi, zaman senkronizasyonu veya test komutu olabilecek kanallar.

Her grup için ayrı test politikası gerekir. Standart servis adına güvenip write iznini açık bırakmak, protokol uyumluluğu değil access-control hatasıdır.

Pairing association modelleri ve gerçek tehdit

BLE Security Manager’da association modeli, iki cihazın birbirini nasıl doğruladığını belirler. Laboratuvar testinde en az şu durumlar ayrı ayrı denenmelidir:

• Just Works: Kullanıcı onayı kolaydır; MITM koruması sınırlıdır.
• Passkey Entry: Bir tarafın gösterdiği veya kullanıcının girdiği kodla doğrulama yapılır.
• Numeric Comparison: İki ekranda gösterilen sayının kullanıcı tarafından eşleştirilmesi gerekir.
• Out-of-Band (OOB): Anahtar veya doğrulama bilgisi başka bir kanal üzerinden taşınır.

Bir saat ekranında sayısal karşılaştırma desteklenmiyorsa Just Works seçilmiş olabilir. Bu tek başına cihazın tüm GATT alanlarının açık olduğu anlamına gelmez; fakat hassas characteristic’lerin link-level encryption veya application-level authorization olmadan bırakılması riski artırır.

Test raporunda şu durumlar yazılmalı:

Connection: accepted / rejected
Pairing prompt: yes / no
Bond persisted: yes / no
Link encrypted: yes / no
MITM protection: yes / no / unknown
Sensitive read before pairing: allowed / denied
Sensitive write before pairing: allowed / denied

Bluetooth SIG’nin LE Secure Connections açıklaması, P-256 tabanlı anahtar anlaşmasının legacy pairing’e göre daha güçlü bir temel sunduğunu belirtir. Fakat bu yalnızca anahtar kurulum katmanıdır. Uygulama, yazılabilir characteristic’i hiç kontrol etmiyorsa güvenli link üzerinde yetkisiz kullanıcı yine meşru bir yazma isteği gönderebilir. LE Secure Connections

RW-32 bulgularını bulgu formatına çevirmek

Kaynak laboratuvar notlarında görülen davranışlar, tek bir “Bluetooth güvensiz” başlığında kaybolmamalı. Daha net bir bulgu ayrımı şöyle yapılabilir:

F-01 — Pairing olmadan GATT erişimi

Gözlem: Central rolündeki test cihazı, eşleştirme kodu veya görünür kullanıcı onayı olmadan bağlantı kurabildi.

Etkilenen sınır: GAP/SM → GATT access control.

Güvenlik etkisi: Yetkisiz cihaz servis ve characteristic envanterini çıkarabiliyor; açık izinli değerleri okuyabiliyor veya yazabiliyor.

Kanıt seviyesi: Test cihazı ve firmware sürümüyle doğrulanmış laboratuvar gözlemi. Aynı modelin başka üretim partileri için yeniden doğrulama gerekir.

F-02 — Metadata disclosure

Gözlem: Pil seviyesi, cihaz adı ve “leopard” olarak geçen dahili firmware kodu okunabildi.

Etkilenen sınır: GATT read permission → device fingerprinting.

Güvenlik etkisi: Model ve firmware profili çıkarılabiliyor; diğer saldırı testleri için hedef yüzeyi daralıyor.

Not: Sağlık verisinin de açıkta olduğu sonucu yalnızca servis UUID’sinden çıkarılamaz.

F-03 — Yazılabilir proprietary characteristic ile reboot/DoS

Gözlem: Özel characteristic’lere 0x01 değerinin gönderilmesi sonrası yeniden başlatma davranışı görüldü; tekrar eden yazmalar cihazı kullanılamaz hâle getirdi.

Etkilenen sınır: ATT write validation → firmware state machine/watchdog.

Güvenlik etkisi: Cihazın kullanılabilirliği kayboluyor; bildirim, alarm ve sensör akışı kesilebiliyor.

Kök neden hipotezi: Eksik input validation veya write handler içinde güvenli olmayan state geçişi. Firmware kaynak kodu olmadan kesinleştirilemez.

Bu ayrım, üreticinin hangi düzeltmeyi yapacağını belirler. Pairing’i açmak F-03’ü azaltır; ancak yazma handler’ı hatalıysa yetkili kullanıcı da cihazı çökertmeye devam edebilir.

Fuzzing için test matrisi

Rastgele mutasyon yerine input sınıfları belirlenmeli:

Test boyutu	Örnek değer	Ölçüm
Uzunluk	0, beklenen, maksimum üstü	ATT error, disconnect, reboot
Değer	0x00, 0x01, sınır, bilinmeyen	State değişimi
Sıklık	tek yazma, burst, yavaş tekrar	CPU, pil, bağlantı stabilitesi
Sıra	write-before-pair, write-after-pair	Permission sonucu
MTU	varsayılan, negotiated büyük değer	Fragmentation ve parser davranışı
Bağlantı	reconnect sırasında write	Race ve watchdog

Her hücre için test ID, firmware hash’i, GATT handle, PDU tipi, zaman, cevap kodu, RSSI, pil seviyesi ve reboot reason kaydedilmeli. Bir cihazın tekrar başlaması “fuzzing başarılı” değil, yeniden üretilebilir bir bulgunun başlangıcıdır.

Mobil uygulama güven sınırı

Saatin mobil uygulaması da araştırma kapsamına alınmalı. Uygulama, hangi UUID’leri keşfediyor? Hangi servisleri “known device” kabul ediyor? Cihaz adı veya MAC adresi tek başına güven ölçütü mü? Uygulama pairing state’i yerine bağlantı callback’ine bakarak komut gönderiyor mu?

İyi tasarımda uygulama şu kontrolleri yapar:

• beklenen service/characteristic UUID seti,
• cihazın kimlik anahtarı veya sertifikası,
• firmware ve protokol sürümü,
• komut öncesi link encryption/bond state,
• nonce veya sequence counter,
• gelen notification’ın uzunluk ve semantik doğrulaması.

Bu kontrollerin hiçbiri kullanıcı deneyimini bozmayacak şekilde tasarlanmazsa geliştirici “saat bağlanmıyor” sorununu çözmek için güvenlik kapısını tekrar açabilir. IoT’de güvenlik ve kullanılabilirlik gerilimi, ürün yaşam döngüsünün başında ele alınmalıdır.

OTA ve kurtarma güvenliği

Remote DoS sonrası cihazın güvenli şekilde geri dönmesi de tasarımın parçasıdır. Watchdog, cihazı sonsuz reboot döngüsüne sokmamalı; art arda boot başarısızlıklarında güvenli recovery mode’a geçmeli. OTA için:

1. Firmware imzası doğrulanmalı.
2. Anti-rollback sürüm politikası uygulanmalı.
3. Güncelleme sırasında güç kesilmesine karşı iki bölümlü veya atomic yazma kullanılmalı.
4. Başarısız güncellemede bilinen iyi imaja dönüş yapılmalı.
5. Recovery arayüzü BLE üzerinden kimlik doğrulamasız açılmamalı.

Pil, watch ve notification gibi düşük güç hedefleri bu kontrolleri zorlaştırabilir; fakat “enerji verimli” olmak, input validation veya imza kontrolünü kaldırmak için gerekçe değildir.

Tekrar üretilebilirlik ve responsible disclosure

Bu tip bir cihaz bulgusu yayımlanacaksa rapor şu bilgileri içermeli:

• ürün adı ve mümkünse üretim partisi,
• firmware sürümü veya hash’i,
• kullanılan central rolü ve ESP-IDF sürümü,
• pairing/bonding başlangıç durumu,
• hangi handle/UUID’nin test edildiği,
• tek yazmada mı, tekrar sonrası mı etki oluştuğu,
• cihazın kurtarma adımı,
• üreticiye bildirim tarihi ve alınan yanıt.

MAC adresleri, kişisel sağlık verileri ve gerçek kullanıcı kimlikleri rapordan çıkarılmalı. Üreticiye bildirim yapılmadan geniş çaplı cihaz taraması yapılmamalı.

Sonuç

RW-32 incelemesinin değeri, ucuz bir saatin “kötü” olmasından değil, BLE güvenlik modelinin nerede kırılabildiğini görünür kılmasından geliyor. GAP bağlantıyı kurar, GATT veriyi düzenler, ATT işlemi taşır, Security Manager anahtarları yönetir; fakat son karar yine firmware’in characteristic izinleri ve input validation mantığıdır.

Bir IoT cihazını değerlendirirken şu dört soruyu ayrı ayrı sormak gerekir:

• Kim bağlanabilir?
• Bağlanan peer hangi servisleri görebilir?
• Hangi characteristic’e hangi güvenlik koşuluyla yazabilir?
• Hatalı değer geldiğinde cihaz güvenli biçimde reddediyor mu, yoksa yeniden mi başlıyor?

BLE protokolü kendi başına bir güvenlik garantisi değildir. Güvenlik, cihazın seçtiği pairing modeli, GATT izinleri, uygulama doğrulaması, hata yönetimi ve güncelleme zincirinin birlikte sonucudur.

Sık sorulan sorular

GATT enumeration tek başına zafiyet midir?

Hayır. Servis ve characteristic keşfi GATT’ın normal işlevidir. Zafiyet, hassas işlevlerin kimlik doğrulamasız okunması veya yazılması gibi erişim kontrolü hatalarında ortaya çıkar.

Şifreli BLE bağlantısında yine DoS olabilir mi?

Şifreleme veri gizliliğini ve bütünlüğünü artırır; hatalı input handling veya cihazın bağlantı yönetimindeki bug’ları otomatik olarak ortadan kaldırmaz. Uygulama katmanı doğrulaması ayrıca test edilmelidir.

Fason cihazlarda yalnızca Bluetooth’u kapatmak yeterli mi?

Kullanım ihtiyacı yoksa kapatmak saldırı yüzeyini azaltır. Ancak cihaz kullanılacaksa güncel firmware, güvenli bonding, sınırlı izinler ve üretici desteği birlikte değerlendirilmelidir.

Kaynaklar

• MUCAHIC Dossier-02: Hardware Hacking Notları #2
• Bluetooth LE primer
• Bluetooth Core Specification – Security Manager
• Bluetooth Assigned Numbers
• NIST SP 800-121 Rev. 2 – Guide to Bluetooth Security
• Android Bluetooth Low Energy overview