Broken Authentication

Broken Authentication Nedir?

Authentication, bir kullanıcının kimliğini doğrulama işlemidir. Kimlik doğrulama mekanizmalarındaki çoğu güvenlik açığı iki yoldan biriyle ortaya çıkar.

• Kimlik doğrulama mekanizmaları brute-force saldırılarına karşı yeterince koruma sağlayamadığı için zayıftır.

• Uygulamadaki mantık hataları veya kötü kodlama, kimlik doğrulama mekanizmalarının bir saldırgan tarafından tamamen atlanmasına izin verir.

Yöntemler

Hydra Brute-Force

# Post Auth
hydra -l admin -P /usr/share/wordlists/rockyou.txt example.com http-post-form "/login.php:username=^USER^&password=^PASS^:invalid credentials" -V -t 64

# Basic Auth
hydra -L /usr/share/seclists/Usernames/top-usernames-shortlist.txt  -P /usr/share/seclists/Passwords/2023-200_most_used_passwords.txt 94.237.62.111 http-get / -s 33607

Username Enumeration via Length

Eğer doğru ve yanlış kullanıcı adı girişlerinde farklı yanıtlar dönüyorsa kullanıcı adları listelenebilir. Bu bir zafiyettir.

Username Enumeration via Delay

Parolaya çok uzun bir değer girerek kullanıcı adlarını listelemeyi deneyebiliriz. Eğer bir yanıt diğerlerinden daha geç geliyorsa o kullanıcı adı var olabilir.

Username Enumeration via Lock

Eğer başarısız girişler sonucunda hesap kilitlendi yanıtı alıyorsak fakat var olmayan hesaplarda bu yanıtı almıyorsak bu yöntemle kullanıcıları listeleyebiliriz.

IP Tabanlı Brute-Force Protection

Eğer brute-force koruması IP üzerinden yapıyorsak aşağıdaki başlıklar ile bu koruma atlatılabilir.

X-Forwarded-For: 127.0.0.1
X-Originating-IP: 127.0.0.1
X-Remote-IP: 127.0.0.1
X-Remote-Addr: 127.0.0.1
X-Client-IP: 127.0.0.1

Doğru Giriş ile Brute-Force Protection Bypass

Eğer doğru giriş yaptığımızda brute-force sayacı sıfırlanıyorsa her brute-force denemesinin arasına doğru girişler koyabiliriz.

Çoklu Parola ile Brute-Force Protection Bypass

Eğer login isteğinde json veri gönderiliyorsa ve parolanın bir liste olarak gönderilmesine izin veriliyorsa tek bir istek ile brute-force yapabiliriz.

Client-Side 2FA

Eğer 2FA kontrolü client-side yapılıyorsa sadece yönlendirme ile bu koruma sağlanıyor olabilir. Kullanıcının profil sayfasını 2FA girmeden ziyaret etmeyi deneyebiliriz.

Brute-Force 2FA

Eğer 2FA kodunda brute-force koruması yok ise ve bu kod kısa ise brute-force deneyebiliriz.

Parametre Kontrolü

Parola sıfırlama isteğindeki parametreleri kontrol edebiliriz.

Header ile Poisoning

Eğer parola sıfırlama linki aşağıdaki header kullanılarak üretiliyorsa, kurban linke tıkladığında istek bizim sunucumuza gönderilebilir.

X-Forwarded-Host: <COLLABORATOR>

Parola Sıfırlama ile Brute-Force

Eğer parola sıfırlama isteğinde username parametresi varsa diğer kullanıcılar için brute-force denemesi yapabiliriz.

Brute-Force Cookie

Eğer kullanıcının session çerezi base64 gibi bir şifreleme kullanıyorsa bu çerez üzerinden brute-force denemeleri yapabiliriz. Login panelinde koruma olsa bile çerez için bir koruma yapılmamış olabilir.

Şifrelenmiş Bir Kanal Üzerinden Taşınan Kimlik Bilgilerinin Test Edilmesi

Aşağıdaki gibi hassas veriler içeren hiçbir isteğin HTTP tarifiği üzerinden gönderilmemesi gerekir.

• Parolalar veya şifreler

• Body kısmındaki Tokenler

• Çerezlerin içinde Hesap veya şifre sıfırlama kodları

Sunucu bir session tokeni için çerez bilgisi döndürürse, istemcinin çerezi daha sonra şifrelenmemiş kanallar üzerinden ifşa etmesini önlemek için çerez Secure flag de içermelidir.

Varsayılan Credential Testi

Eğer uygulama giriş paneli içeriyorsa varsayılan kullanıcı bilgileri ile giriş yapmayı deneyebiliriz. Ayrıca aşağıdaki gibi çok kullanılar bilgileri deneyebiliriz.

creds search mysql

+---------------------+-------------------+----------+
| Product             |      username     | password |
+---------------------+-------------------+----------+
| mysql               | [e-mail] |  admin   |
| mysql               |        root       | <blank>  |
| mysql (ssh)         |        root       |   root   |
| mysql               |      superdba     |  admin   |
| scrutinizer (mysql) |    scrutremote    |  admin   |
+---------------------+-------------------+----------+

Zayıf Parolalar

admin:password
admin:admin
root:root
root:password
admin:admin1
admin:password1
root:password1

Captcha Mekanizması

• Challange aritmetik veya tahmin edilebilir olmamalı.

• HTTP Response code ile kontrol yapılmamalı.

• Sunucu tarafı mantığı varsayılan olarak başarılı bir çözüme sahiptir.

• CAPTCHA meydan okuma sonucu hiçbir zaman sunucu tarafında doğrulanmaz.

• CAPTCHA giriş alanı veya parametresi manuel olarak işlenir ve yanlış bir şekilde doğrulanır veya kaçar.

• CAPTCHA'yı çözmeden istek göndermeyi deneyin.

• Yanlış Captcha ile göndermeyi deneyin.

• Captcha değeri client-side tutuluyor olabilir.

• Zaten kullanılmış bir kodu deneyin.

• Cookie olmadan isteği gönderin belki cookie olmadığında kontrol edilmiyordur.

• Çok adımlı captca varsa direkt son adımı göndermeyi deneyin.

• Belki başka endpointte captcha koruması yoktur. (Örneğin aynı isteğin mobil apisi)

Önlemler

• Giriş bilgileri her zaman https üzerinden gönderilmeli.

• Giriş bilgileri hiçbir zaman get parametreleri ile gönderilmemeli.

• Güçlü bir parola politikası uygulayın.

• Username enumeration zafiyetini engellemek için yanlış girişlerde her zaman aynı yanıtın döndüğüne emin olun.

• Brute-force saldırılarını engellemek için IP tabanlı rate-limit veya captcha koruması eklenmeli.

• Daha güçlü bir giriş için 2FA mekanizması ekleyin.

Kaynaklar

• https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/04-Authentication_Testing/
• https://portswigger.net/web-security/authentication