Ses arabiriminde SSH varsayılan olarak etkin

 (hhh.hn)
1 puan yazan GN⁺ 5 일 전 | 1 yorum | WhatsApp'ta paylaş
  • Firmware dosyası açıldığında cihazın iç yapısı kolayca incelenebiliyordu ve Rodecaster Duo'da SSH varsayılan durumda açıktı
  • Güncelleme paketi gzipped tarball biçimindeydi; cihazda, hasar durumunda diğer tarafa önyükleme yapan iki bölüm ve güncelleme için kabuk betikleri bulunuyordu
  • Gelen firmware için imza doğrulaması yoktu; gerçek SSH erişimi Ethernet bağlantısı üzerinden doğrulandı ve yalnızca pubkey kimlik doğrulamasına izin veriliyordu
  • Windows'ta USB güncelleme akışı yakalanarak güncelleme moduna girişin ve flashlama işleminin M ve U adlı tek ASCII komutları ile yapıldığı görüldü; archive.tar.gz ve archive.md5 kopyalandıktan sonra yeniden başlatmayla yeni firmware yükleniyordu
  • macOS'ta özel firmware ile SSH parola kimlik doğrulaması etkinleştirildi ve açık anahtar eklendi; böylece gerçek bağlantı da mümkün oldu, ancak SSH'nin varsayılan etkin gelmesinin ve varsayılan anahtarların neden eklendiğinin nedeni sonuna kadar açıklığa kavuşmadı

Firmware güncellemesi ve SSH'nin varsayılan etkin olması

  • Rodecaster Duo, firmware güncelleme sürecinde cihaza aktarılan dosyaların kolayca incelenmesine izin veriyordu ve varsayılan durumda SSH etkin geliyordu
    • macOS'ta disk etkinliği izlenerek firmware'in saklandığı konum bulundu; firmware basit bir gzipped tarball biçimindeydi
    • Güncelleme denenirken cihazda USB disk yazma işlevi devre dışı olduğundan bu güncelleme başarısız oldu
  • Cihazın içinde çalıştırılabilir ikililer ve güncelleme için kabuk betikleri vardı; diskte iki bölüm bulunuyordu, böylece biri bozulursa diğeriyle önyükleme yapılabiliyordu
    • Gelen firmware için imza doğrulaması yok
    • Ethernet kablosu bağlanarak yapılan kontrolde SSH'nin gerçekten açık olduğu ve yalnızca pubkey kimlik doğrulamasına izin verdiği görüldü
  • Varsayılan olarak eklenmiş iki SSH anahtarı tespit edildi
    • ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCX/bCFTDgViuPvdFL/VMMVRrw9b5S8HcDQk17qoCEYwmI+IIG8rEAsLiaeCOwyhf9IN+8/LRaN0Z5ZfU3WMbmsKEg8zd1Yvqq74nFbhO47vbtzmCi9S4ucIKkBEVOyvyN5lt9hWf5t5nZSmlfldZK3Pem5y8wHM5A+K/gSnzp4gwQ1QYfFb068uQ+ciIdOhb8SkUs8CwzotglIbp19I6ZmXmsNj/TmpbUf5rMfUAf1gysZ5j1UdRWrvWVh5daqvZRsBBPbXEeJfDU3Nr3HR14XYt9mgexrz/5oyKSj/lQYLmh9cDfsxvkGNIQ8fF9l+n2L1KZM4lLgiGk4KFBjQHaIBZx9OebCiiZCO4NTJUBDk9a+SZpiDiipADV07s7vTInYyFA6GrmKtnq3M6upT4WJBvVuL/BMnK5yY1RZtoqox2/pcCg2rH5S1GIy0v0HFJisl7kWInlaG2mdsaCx19wAjCFe/qT9LyxjQ6+0rArI55/JJFDkNeMjrewRQwNdASjCox8vqXCBfjvsR9qv70/ywcymgsnLAnq2LuYg5FYwMMDYOvVnhACC+BYTdNDTn5oeMIjQCUenY/DPCHpJkf4YOf3YCMUTEU9tExhtwW/X+m21hS3+STLtTfqbUeg9CeuPQZgfl9vc65n3tMxAdlEGEDoTaNMAgr2TzJv92Ka9iQ==
    • ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDaNyzPfIcEeQsfzyQs/wyX6mX52kiS+4eNHfCaxFlgj

Güncelleme akışı ve özel firmware

  • Windows'ta Wireshark ve USBPcap ile güncelleme trafiği yakalanarak RODECaster App'in cihaza gönderdiği kontrol akışı incelendi
    • Cihazı güncelleme moduna alan 'M' komutu ve güncellemeyi çalıştıran 'U' komutu vardı
    • Her iki komut da HID report 1 üzerinden gönderilen tek bir ASCII karakteriydi
  • Gerçek güncelleme yapısı basitti
    • M komutu gönderildikten sonra yeni görünen diske archive.tar.gz ve archive.md5 kopyalanıyordu
    • archive.md5, arşivin md5sum değeriydi
    • Ardından disk unmount edilip U komutu gönderildiğinde flashlama başlıyor, sonrasında cihaz yeniden başlatılarak yeni firmware ile açılıyordu
  • macOS'ta konteyner kullanılarak SSH parola kimlik doğrulamasını açan ve kendi açık anahtarını authorized keys içine ekleyen bir özel firmware oluşturuldu
    • Flashlama için gereken en küçük işlev örneği burada görülebilir
    • Betik çalıştırılıp flashlandıktan sonra cihaza SSH ile bağlanmak mümkün oldu
  • Bu cihazda firmware'i flashlamak son derece kolaydı; SSH'nin varsayılan etkin olması ve varsayılan anahtarların dahil edilmesinin nedeni ise doğrulanmadan kaldı
    • Bu sorun RODE'a bir ticket ile iletildi ancak yanıt alınmadı
    • Sonraki firmware güncellemelerinde bir değişiklik olup olmadığı izlenmeye devam edilecek

İlgili okumalar

1 yorum

 
GN⁺ 5 일 전
Hacker News yorumları
  • Bu tür konularda beni hep en çok sıkan şey, signed firmware ile open firmware'in aslında birbirinin zıttı olmaması.
    Varsayılan olarak doğrulamayı açık tutmak sorun değil, ama donanımı satın alan kişinin kendi anahtarını kaydedebilmesi, bir jumper değiştirebilmesi ya da açılışta bir düğmeye basabilmesi gibi yollarla sahip denetimini alabilmesi gerekir.
    Bunu gerçekten yapan yerler birkaç Chromebook ve ağ cihazıyla sınırlı olduğu için, firmware güvenliği gündeme gelince iş hep "tam kilitleyelim" ile "tamamen açık bırakalım" kavgasına dönüyor ve parayı veren kullanıcının karar verdiği yapı ortadan kayboluyor.
    Rode'un bunu tarball + hash ile dağıtması çok iyi; ileride daha sıkı hale getirse bile, umarım elimdeki cihaza istediğim şeyi yükleyebileceğim bir yol bırakır.
  • Firmware imajının sadece tarball + hash olması gerçekten çok hoşuma gidiyor.
    Keşke bu kadar açık daha fazla cihaz olsa ve umarım Rode bunu görüp firmware yükseltmelerini kilitlemez.
    • Eğer bunu Rode tarafından biri görüyorsa, sırf bu yüzden cihazı satın alasım geliyor.
      Lütfen bunu değiştirmeyin.
    • Birkaç yıl önce bir HP yazıcı firmware'i yüklemem gerekmişti ve yöntem şaşırtıcı derecede basit olduğu için çok beğenmiştim.
      Yazıcı yaklaşık 2009 modeldi ve RAM'i 256MB'a çıkarmak için firmware güncellemesi gerekiyordu; ağ üzerinden yazıcıya tarball'ı FTP ile göndermek yeterliydi.
      FileZilla ile attım, birkaç dakika çalıştı ve güncelleme hemen bitti; o günden sonra firmware güncellemesinin neden bundan daha karmaşık olması gerektiğini sorgulamaya başladım.
      Güvenlik için en fazla checksum kontrolü yapılsa bile, tek bir blob'u FTP, SCP ya da SFTP ile yükleyip işin bitmesine izin verseler keşke.
    • Yine de güncelleme komutunun yalnızca fiziksel bir düğme gibi bir girişle etkinleştirilmesi gerektiğini düşünüyorum.
      Bir tür DFU mode'a geçmeden olmamalı; yoksa USB'ye erişebilen herhangi bir şey yanlış firmware'i itip cihazı kullanılmaz hale getirebilir.
    • Kişisel olarak ses arayüzümün SSH çalıştırmasını ve birilerinin oraya rastgele authorized key ekleyebilmesini istemem.
  • Başlık Ses arayüzüm 64 bitlik bir Linux bilgisayarı olsaydı daha ilgi çekici olurdu.
    10-20 yıl önce olsaydı bu tür işlevler muhtemelen küçük bir 16 bit ya da 32 bit SoC üzerinde VxWorks gibi bir RTOS ile uygulanırdı.
    Üzerinde çok sayıda fiziksel kontrol de olduğuna göre, bir sonraki adımın onu oyun konsoluna çevirmek olması doğal görünüyor.
    • Benim ses arayüzüm de aslında bir Linux computer ve içinde gerçekten field-programmed edilen bir FPGA var.
      Üstelik iki tane 1GbE portu bulunuyor ve her biri makinenin farklı bir parçasıyla haberleşiyor.
      Ama bu tür kurulumlar profesyonel ses dünyasında o kadar da sıra dışı değil; ev masasının üstünde kullanınca etkileyici duruyor, fakat sektör içinde oldukça sıradan sayılır.
      Sonradan root shell alınınca ya da cihaz tuğlaya dönünce hikâye daha da ilginç olabilir.
    • Senin video dongle'ın da bir Unix bilgisayarı olabilir: https://www.macrumors.com/2025/02/04/doom-apple-lightning-hdmi-adapter/
    • Şu anda RAM/storage baskısı olsa da çipler o kadar ucuz ki,
      maliyet ve uyumluluk açısından Linux'u geçmek de kolay değil.
  • Cihaza düzgün bir DSP girmeye başladığında bu tür yapı çok yaygın oluyor.
    Genelde altta bir ARM SoC üzerinde çalışan minimal bir Linux bulunuyor ve vendor BSP bazen yanlışlıkla sshd açık şekilde gönderiliyor.
    Bu daha çok kötü niyetten ziyade, ses tarafında rootfs'den gerçekten sorumlu birinin olmamasına benziyor.
    Asıl mesele bunun yalnızca USB tarafındaki ağda mı açık olduğu, yoksa gerçek LAN üzerinde de mi dinlediği.
    İlki can sıkıcı seviyede, ikincisi ise gerçekten endişe verici.
    • Ne yazık ki Linux varsayılanları bu tür cihazları seri üretmek için pek uygun değil.
      Buna karşılık Android'de eng / userdebug / user gibi varsayılan imaj türleri ayrılmış durumda; bu yüzden önceden yapılandırılmış doğru varsayılanı seçmek bile bu tip hataları önlemeyi kolaylaştırıyor.
    • Bu gerçekten LAN üzerinde de dinliyor.
      Yalnızca belirli bir işlev kullanılırken Wi‑Fi'ye bağlandığı için, o arayüzde de açık olup olmadığını kontrol edemedim.
  • Artık herkesin cebinde bir AI-hacker taşıyor gibi olması hâlâ şaşırtıcı geliyor.
    Bir ajana veriyorsun, birkaç dakika içinde firmware'e bakıp cihazı modifiye etmek için bir yaklaşım çıkarıyor.
    Geçen yıla kadar bunlar ya en az Hotz seviyesinde bir hacker'ın ya da çok uzun süre inatla kurcalayacak birinin yapacağı işlerdi.
    • Bu hiç doğru değil.
      LLM'lerin analiz, debug ve bypass işlerini çok daha kolaylaştırdığı doğru, ama bu cihazın koruma seviyesi o kadar düşüktü ki orta seviye becerisi olan biri bile yeterli motivasyon ve zamanla bunu rahatça yapabilirdi.
      Ne şifrelenmiş firmware vardı, ne imza kontrolü, ne de gömülü SSH access eksikti.
      Buna karşılık George Hotz'un kırdığı PS3 hypervisor, saldırgan açısından çok daha sağlam tasarlanmıştı ve gerçek exploit için FPGA ile voltage glitching bile gerekmişti.
      O tür saldırılarda LLM yardımcı olabilir ama tam bir geri bildirim döngüsü olmadığı için hâlâ ciddi insan emeği gerekiyor.
      https://rdist.root.org/2010/01/27/how-the-ps3-hypervisor-was-hacked/
    • Yazıdan anlaşıldığı kadarıyla Claude Code aslında büyük ölçüde Wireshark ve Google yerine USB HID trafiğini yorumlamak ve protokol dokümanı bulmak için kullanılmış.
      Wireshark kurulu değilse biraz zaman kazandırabilir ama bir miktar halüsinasyon riski de var.
      Bunun dışında Docker içinde firmware tarball'ındaki ~root/.ssh/authorized_keys ve /etc/shadow dosyalarını değiştirmek, ilgili HID mesajlarını yollamak ve modifiye edilmiş tarball'ı cihazın USB sürücüsü gibi sunduğu volume'a kopyalamak için basit bir Python betiği kullanılmış.
      Yani bu iş çılgın seviyede bir hacker gerektirmiyor; Linux sysadmin temelleri ve USB HID kütüphanesi kullanarak ufak bir program yazabilecek düzey yeterli.
      Yalnız Ubuntu container'a neden whois paketini kurduklarını bir an merak etmiştim; Debian türevlerinde mkpasswd tarihsel nedenlerle onun içinde olduğu için anlam kazandı.
      Ayrıca cihazın sshd_config dosyası varsayılan hâliyle duruyorsa, PermitRootLogin yüzünden root parola girişi zaten baştan mümkün olmamış olabilir.
      https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=116260
    • Ben de AI kullanarak elimdeki bir Phase One digital back üzerinde SSH açtım; diğerinde ise firmware'i tersine mühendislikle inceleyip farklı bir model olarak tanınacak şekilde patch'ledim.
      Credo 50'yi IQ250 gibi gösterdim; içleri zaten fiilen aynı.
    • Eskiden paket yakalamaları ve türlü veriyi saatlerce didiklemek gerekirdi; şimdi o zamanı harcamamak güzel.
      Derine inmenin eğlencesi ayrı ama yaş ilerledikçe rastgele firmware blob'larıyla 16 saat geçirmek zorlaşıyor.
    • Çoğu durumda LLM'ler o seviyede işler çıkaramıyor.
      Ayrıca SSH açık bir cihazla uğraşmak için özel bir beceri de gerekmiyor.
  • Bende de aynı sorun olduğu için, yazarın bunu nasıl çözdüğünü gerçekten merak etmiştim.
    Özellikle aynı odada oyun oynayıp Discord kullanırken benim ve kız arkadaşımın kendi bilgisayarlarımıza mikrofon bağlayıp eko olmadan kullanmak istememiz kısmı buna çok benziyor.
    • Rodecaster iki bilgisayara bağlanabiliyor.
      İkisi de aynı Discord görüşmesine katılır; iki mikrofonu tek bir bilgisayar girişinde birleştirip gönderirsin, diğer kişi ise mikrofonunu mute edip istemcide sadece sesi alır.
      Mix yerelde yapıldığı için eko oluşmaz.
      Daha fazla ayrıntı istersen e-posta at demek isteyecek kadar basit.
    • Geçenlerde Rust ile kabaca vibe coding yaparak bir jack mixer yazdım; LAN üzerinden sesi alıp tekrar dışarı verebiliyor.
      Gecikme yaklaşık 40ms, Wi‑Fi üzerinden ise 50-60ms civarında.
      Bir PC'de mikseri çalıştırıp yerel mikrofonu bir giriş kanalı olarak alırsın; diğer PC ise kendi mikrofonunu yayınlayıp mikserde kanal 2'ye gönderir, böylece benzer şekilde çözülebilir.
      Yerel PC'de müzik de çalınabilir ve mixer ya da broadcaster yerel bir sink oluşturabilir.
      En sonda her şey mixer'de birleşir; ana çıkış Discord'a gider, monitör hattı da Discord sesini çıkarıp diğer PC'ye tekrar relay ederek gerçek zamanlı dinleme için kullanılabilir.
    • Yönlü boom mikrofona sahip bir headset ile çözülebilecek bir problem değil mi diye düşündüm.
      Tabii durumu yanlış anlamış da olabilirim.
  • Yazı da güzel, domain de harika.
    Zola'yı pek bilmiyorum ama bunun yaygın bir tema mı yoksa özel bir şey mi olduğunu anlamasam da çok hoş görünüyor.
  • Birçok vendor, security'yi fiilen kopya önleme ile eş anlamlı görüyor gibi.
    Sanırım signed image zorlamalarının nedeni de bu.
  • Hedefin neden disclosure olduğunu merak etmiştim.
    Böyle bir arayüz için insan tam tersine açık kalmasını ister gibi geliyor.
    • Bu ille de hedef değildi; ben de RODE'un bunu açık bırakmasını umuyorum.
  • Avustralya tarafındaki Rode insanları nispeten iletişime açık oluyor; raporlanacak bir şey varsa doğrudan aramak bile işe yarayabilir.
    Sonuçta burada neredeyse İngilizce benzeri bir şey de konuşuyoruz, yani bir şekilde anlaşılır herhâlde.