1 puan yazan GN⁺ 2025-12-24 | 1 yorum | WhatsApp'ta paylaş
  • Lotusbail paketi, meşru bir WhatsApp Web API kütüphanesi olan Baileys'in bir fork'u olup, 6 ay boyunca npm'de 56 binden fazla indirilen kötü amaçlı kod içeren bir paket
  • Normal çalışan API işlevleri sunarken WhatsApp kimlik doğrulama bilgilerini, mesajları, kişileri ve medya dosyalarını çalıp saldırganın sunucusuna gönderiyor
  • Veriler RSA, AES, Base-91, LZString gibi çok katmanlı şifreleme ve gizleme süreçlerinden geçirilerek iletiliyor; bu da güvenlik izlemesini atlatmayı mümkün kılıyor
  • Paket, sabit kodlanmış bir eşleştirme kodu üzerinden saldırganın cihazını kullanıcının WhatsApp hesabına kalıcı olarak bağlayan bir arka kapı kuruyor
  • Bu vaka, tedarik zinciri saldırılarının giderek daha sofistike hale geldiğini gösteriyor ve yalnızca statik analizle tespit edilemeyen tehditlere karşı davranış temelli güvenlik izlemenin gerekliliğini vurguluyor

Lotusbail paketine genel bakış

  • lotusbail, meşru @whiskeysockets/baileys paketinin bir fork'u ve WhatsApp Web API işlevlerini aynen sunuyor
    • Mesaj gönderme ve alma normal şekilde çalıştığı için geliştiricilerin şüphe duymadan kurma olasılığı yüksek
    • npm'de 6 aydır kayıtlı ve yazının hazırlandığı an itibarıyla hâlâ indirilebilir durumda
  • Ancak gerçek işlevlerin arkasında WhatsApp kimlik bilgisi hırsızlığı, mesaj yakalama, kişi toplama ve arka kapı kurulumu gibi kötü amaçlı faaliyetler gizleniyor

Çalınan bilgiler

  • Kimlik doğrulama token'ları ve oturum anahtarları, tam mesaj geçmişi, telefon numaraları dahil kişi listesi, medya dosyaları ve belgeler ile kalıcı arka kapı erişim yetkisi buna dahil
  • Tüm veriler, saldırganın sunucusuna gönderilmeden önce şifreleniyor

Çalışma şekli

Gerçekte çalışan kamuflaj işlevi

  • Çoğu kötü amaçlı npm paketi bozuk çalışır ya da şüpheli kodlarla kolayca ayırt edilir; ancak Lotusbail, normal çalışan bir API gibi davranarak gizleniyor
  • Meşru Baileys kütüphanesini temel alıyor ve mesaj gönderme/alma işlevleri eksiksiz biçimde uygulanmış durumda
  • Bu sayede geliştiricilerin “normal çalışan kod” içinde kötü niyetli davranıştan şüphelenmemesine dayanan bir sosyal mühendislik tekniği kullanılıyor

Veri hırsızlığı ve aktarımı

  • Paket, WhatsApp ile iletişim kuran WebSocket istemcisini saran bir yapı olarak çalışıyor
    • Kimlik doğrulama sırasında oturum bilgilerini yakalıyor; mesaj alımı ve gönderimi sırasında ise tüm içeriği kopyalıyor
    • Normal işlev korunuyor, yalnızca tüm veriler eşzamanlı olarak saldırgana da gönderiliyor
  • Çalınan veriler, özel bir RSA uygulaması ile şifrelenerek iletiliyor
    • Bu mekanizma, WhatsApp'ın kendi uçtan uca şifrelemesinden ayrı çalışıyor ve ağ izlemeyi atlatmak için kullanılan bir şifreleme katmanı işlevi görüyor
  • Sunucu adresi kod içinde doğrudan görünmüyor; bunun yerine şifrelenmiş bir yapılandırma dizesinin içine gizleniyor
    • Unicode değişken manipülasyonu, LZString sıkıştırma, Base-91 kodlama ve AES şifreleme dahil 4 aşamalı gizleme uygulanıyor

Arka kapı kurulumu

  • WhatsApp'ın cihaz eşleştirme kodu özelliği kötüye kullanılarak saldırganın cihazı kullanıcının hesabına bağlanıyor
    • Paketin içinde AES ile şifrelenmiş, sabit kodlanmış bir eşleştirme kodu bulunuyor
    • Kullanıcı kimlik doğrulaması yaptığında saldırganın cihazı da aynı anda bağlanarak kalıcı hesap erişimi elde ediyor
  • Saldırgan; mesajları okuma, gönderme, medya indirme ve kişilere erişme dahil hesabın tamamını kontrol edebiliyor
  • npm paketi silinse bile saldırganın cihazı bağlı kalıyor; bunu engellemek için WhatsApp ayarlarından tüm cihaz bağlantılarının elle kaldırılması gerekiyor

Analizden kaçınma teknikleri

  • Kod içinde 27 sonsuz döngü tuzağı bulunuyor; bunlar hata ayıklama araçları tespit edildiğinde yürütmeyi durduruyor
    • Hata ayıklayıcıları, süreç argümanlarını ve sandbox ortamlarını algılayarak dinamik analizi engelliyor
    • Kötü amaçlı kod bölümlerinde yorumlar yer alıyor ve sistematik geliştirme yönetimine dair izler görülüyor

Sonuç ve güvenlik çıkarımları

  • Tedarik zinciri saldırıları giderek daha incelikli hale geliyor ve normal çalışan kod biçiminde gizlenen örnekler artıyor
  • Yalnızca statik analiz ve itibar temelli doğrulama ile tespit zor; çalışma anındaki davranış analizi (behavioral analysis) gerekli
  • Lotusbail vakası, “kod çalışıyorsa güvenlidir” varsayımına dayanan güvenlik açığını istismar ediyor ve runtime davranış izleme sistemleri kurmanın önemini gösteriyor
  • Koi Security araştırma ekibi, bu tür runtime tabanlı tespit teknikleri sayesinde mevcut doğrulama süreçlerini aşan tehditleri tanımladı

1 yorum

 
GN⁺ 2025-12-24
Hacker News görüşleri
  • Her kötü amaçlı yazılım olayı yaşandığında güvenlik ekiplerinin verileri aşırı kilitleme yönüne gitmesi can sıkıcı
    WhatsApp mesajlarının sızması tetikleyici olmuş olabilir ama sonuçta başka bir şeyi çalacaklardı
    Uygulamaları yalnızca belirli imzalar okuyabilecek şekilde engellerseniz, meşru yedekleme ya da veri erişimi de imkansız hale gelir
    Güvenliğin güçlenmesi iyi ama her şeyi kilitleyen aşırı savunma yaklaşımının da ayrı bir sorun olduğunu düşünüyorum

    • Katılıyorum. Bu arada bu paket, resmi WhatsApp API’sinin bir sarmalayıcısı değil, tersine mühendislikle oluşturulmuş bir WhatsApp Web istemcisi
      Kullanıcılar, tıpkı WhatsApp hesaplarına başka bir istemci bağlar gibi erişiyor ve bunun sonucunda tüm verilere erişim mümkün oluyor
      WhatsApp düzgün bir resmi API sunsaydı bu tür şeyler daha az yaşanırdı
      İlgili belgeler: Baileys Wiki
    • Bence işletim sistemi uygulamalar arası veri erişimini aracılık etmeli ve kullanıcıdan açıkça izin istemeli
    • WhatsApp’ın bu tür kısıtlamaları getirme nedeni bence güvenlik değil, rekabeti sınırlamak
    • Uygulamaları kilitlemek sonuçta şirketlerin daha fazla kontrol ve gelir elde etmesinin bir yolu
      Eskiden daha çok kötü amaçlı yazılım vardı ama buna karşılık özgürlük ve birlikte çalışabilirlik de daha fazlaydı
    • Bu durumu iyi hicveden bir xkcd çizgi romanı var
  • Bu tür saldırıların artık öngörülebilir bir sonuç olduğunu düşünüyorum
    NPM gibi paket yöneticileri, derlemeden hemen önce bağımlılıkları çeken bir yapıya sahip olduğu için yapısal olarak kırılgan
    Sürüm kontrol sistemini by-pass ederken, doğrulanmamış sayısız bağımlılığı kabul eden kültür asıl sorun

    • Giderek fark ediyorum ki biz geliştiriciler güvenlik konusunda gerçekten zayıfız
      Sadece NPM değil, Cargo, Docker, CI/CD dahil tüm ekosistemler benzer sorunlara sahip
      Yapı “isimle kur ve geç” şeklinde olduğu için güvene aşırı dayanıyor
      Net bir çözüm de yok — işbirliğinden vazgeçemeyiz, ama tam güvenlik de mümkün değil
      Sonuçta canavar zaten evin içinde
    • Katılıyorum ama bu yalnızca paket yöneticilerinin sorunu değil
      Doğrudan bir git URL’si belirtsek de sonuç aynı olurdu
      Sonuçta bu, bağımlılık yönetiminin yapısal sorunu
    • Her platformda fazla sayıda paket yöneticisi var
      Dilden bağımsız standartlaştırılmış bir paket yöneticisine ihtiyaç var gibi geliyor
      İmza doğrulama, kaynağın garanti edilmesi, API standardizasyonu gibi özellikler şart
    • apt ya da rpm gibi sistem paket yöneticileri de kusursuz değil
      xz vakasında olduğu gibi enfekte paketler olduğu gibi dağıtılabiliyor
      Üstelik sistem paket yöneticileri en güncel sürümleri desteklemekte yavaş kaldığı için geliştirme için uygun değil
      Sonuçta npm, cargo, pip gibi araçlara ihtiyaç duyulmasının nedeni bu
    • Bu olayda enfekte olmuş bir bağımlılık değil, baştan sona kötü amaçlı bir paket vardı
      Sorun paket yöneticisi değil, en başından beri güvenilmez olan koddu
  • Kötü amaçlı yazılım yazarının fonksiyon adlarını exfiltrateCredentials gibi bu kadar açık seçik koymuş olması komik
    Hata ayıklayıcı tespiti eklemiş ama kodu gizlememiş olması ironik

    • Aslında kod gizlenmişti ve yazarın paylaştığı şey gösterim amaçlı geri yüklenmiş sürümdü
    • 27 hata ayıklama tuzağını test etmek için epey test kapsamı gerekmiş olmalı
      Kötü amaçlı yazılım testi de artık geliştirmenin bir türü haline geldi
  • “Geliştiricinin düşünmeden kurduğu bağımlılık” ifadesi ürkütücü

    • Geliştiricilerin çoğu npm install komutunu doğrudan çalıştırıyor
      Güvenlik politikaları sıkı olan kurumlar dışında bunu pratikte engellemek zor
      Sonuçta çözüm npm’i daha az kullanmak olabilir
    • Docker imajları da aynı şekilde
      Etiket temelli belirtildiğinde her an tedarik zinciri saldırısına açık hale geliyor
      Sektör, sanıldığından çok daha fazla kör güven üzerine işliyor
      Otomatik dağıtım sistemlerinin “iki kez düşünme” lüksü bile yok
    • Korkutucu ama geliştiricilerin çoğu için gerçek durum bu
    • Bence içinde biraz abartı da var
  • JavaScript için de Apache Commons gibi güvenilir, büyük ölçekli kütüphaneler olsa güzel olurdu
    Apache Commons tanıtımı

    • Ama kütüphane ne kadar büyük olursa olsun, WhatsApp API muhtemelen onun içinde yer almazdı
  • lotusbail paketi, WhatsApp Web API’si gibi davranan kötü amaçlı bir npm paketi
    6 ay boyunca dağıtıldı ve kimlik bilgisi hırsızlığı, mesaj ele geçirme, arka kapı kurma gibi çeşitli saldırılar gerçekleştirdi

  • JS ekosistemine bağımlı geliştiricilerin gerçekçi olarak risk azaltma stratejilerine ihtiyacı var
    Docker ya da VM kullanma yöntemlerinden söz ediliyor

    • Önceki işimde DevOps ve güvenlikten sorumluydum
      Tüm geliştirme ortamlarını konteynerleştirdik ve bağımlılıkları sabit sürümlere kilitledik
      Global kurulum yasaktı, otomatik güncelleme yasaktı, manuel doğrulama zorunluydu
      Hassas projeler için düzenli aralıklarla sıfırlanan özel iş istasyonları veriliyordu
      Uğraştırıcı ama gerçekçi güvenlik bu
      Ya da JS ekosistemini terk etmek de bir seçenek
    • Ama bu vakada kullanıcı paketi bilerek kurmuştu, o yüzden bu tür önlemlerle engellemek zor
      İşletim sistemi ya da Docker düzeyinde ağ bağlantısına izin verilip verilmeyeceğinin doğrulanabilmesi gerekir
    • Ben Incus OS kullanıyorum ve her proje için yeni bir konteyner açarak geliştiriyorum
      Çekirdeği paylaşıyor ama JS ekosistemindeki saldırıları durdurmak için yeterli
      npm’de bir konteynerden kaçış saldırısı görürsem o zaman VM’e geçerim
      Başta bunu aşırı güvenlik sanıyordum ama şimdi hem hızlı hem de kararlı buluyorum
    • Böyle paketler dağıtıldığında risk yalnızca geliştiriciye değil, tüm kullanıcılara yayılıyor
    • Bazı şirketler, npm paketlerinin yalnızca birkaç aylık geçmişi varsa kullanımına izin veriyor
      Çünkü bu süre içinde kötü amaçlı olup olmadığı ortaya çıkabiliyor
  • Bu paket en başından beri güvenlik açısından başarısızdı
    Resmi API yerine istemci kimlik doğrulamasının yeniden uygulanmış bir sürümünü kullanıyordu ve kullanıcı gizli anahtarları üçüncü tarafın elinden geçiyordu
    Kullanıcıların da dikkatli olması gerekirdi ama tüm suçu onlara yüklemek zor

    • Aslında WhatsApp’ın genel kullanıma açık bir API’si yok
      API erişimi için “WhatsApp Business Platform”a kayıt olmak gerekiyor
      Gerçek bir API olsaydı bunlar yaşanmazdı
    • Resmi API’nin işlevleri eksikse yeniden uygulamanın kendisi sorun değil
      Ama kimlik doğrulama sırasında gizli anahtarların üçüncü tarafa verilmesi riskli
      Genelde insanlar kendi hesaplarını otomatikleştirmek için bu tür paketleri kuruyor
  • Son zamanlarda LLM tarafından üretilmiş blog yazıları ortalığı kapladı
    Kalite düşük ama maliyet sıfır olduğu için pazarlamacılar açısından verimli
    Geleneksel yazı yazma artık bir tür legacy haline geldi

    • Ama komik olan, bu yorumun kendisi bile LLM yazmış gibi hissettiriyor
  • Tedarik zinciri saldırıları artıyor gibi görünüyor. Geliştiriciler buna nasıl karşılık vermeli?

    • Azaltmak için rastgele paket kullanmayı bırakmak ve temelde npm gibi ekosistemlerden uzaklaşmak gerekiyor
    • Sunucu URL’si gizlenmiş ya da şifrelenmiş paketler bir uyarı işaretidir
      Otomatik taramalarla bu tür kalıplar tespit edilmeli ve doğrulama süreçleri güçlendirilmeli
    • 1999’daki gibi bağımlılıkları tek tek inceleyip vendor etmek gerekiyor
    • Artık bağımlılık sayısı fazla ve kimse koda bakmıyor
      Konteynerleştirme, bağımlılık kilitleme, güvenlik taraması ve gecikmeli güncelleme şart
      npm global kurulumları ise en kötü seçenek
    • Çalıştırmak zorundaysanız, bunu olabildiğince izole bir ortamda yapmalısınız
      rootless podman gibi konteynerler ya da VM’ler kullanarak riski en aza indirmek gerekir