E-Posta Onay Kodlarını Hack'lemek Bu Kadar Kolay Olmamalı!

Selam hackerlar. Bugünkü videoda eğlenceli bir CTF'i birlikte çözüyoruz.

Bu hacking senaryosu özellikle web uygulama güvenliğine yeni başlayanlar ve orta seviyedekiler için harika bir alıştırma olacak. Çünkü sıfırdan başlayıp adım adım NMA map ile açık servisleri keşfedeceğiz. Dizin taraması ve log analizleriyle bilgi toplayacağız. Bypass teknikleriyle login sistemini alt üst edeceğiz. Bunu yaparken de hiç yorulmayacağız. Yapay zeka kullanacağız. Son olarak JWT manipülasyonu ile admin haklarını alacağız. Yani bu videoda pasif bilgi toplamadan tut brut force mantığına, rate limit aşımından JWT key injection'a kadar birçok temel ve orta seviye tekniği uygulamalı olarak göstereceğim. Olabildiğince açık anlatmaya çalışacağım. Videonun sonunda da çok önemli bir soruya cevap vereceğim. O yüzden sonuna kadar izle. Ama yine de kafana yatmayan bir şey olursa yorumlarda buluşalım. Hazırsan not defterini kap; arkana yazsan, ben hedefi eklerken sen de keyfini çıkar.

Bu arada bu videodaki tüm içerik sadece ve sadece eğitim amaçlıdır. Burada gösterilen tekniklerin izinsiz kullanılması dünyanın birçok yerinde yasalara aykırı ve ciddi sonuçlar doğurabilir. Lütfen öğrendiklerinizi etik sınırlar içinde kullanın. Hiçbir kişi ve kurumu, en başta da kendinizi zor duruma düşürmeyin.

Hack'e başlamadan önce YouTube algoritmasını eklemeye yardımcı olmaya ne dersin? Dünyanın en kolay eki. Kanala abone oluyorsun ve like butonuna tıklıyorsun. Bir de bildirimleri açıyorsun. Easy peasy. Başlıyoruz.

Elimizde sadece IP adresi var. Başka hiçbir bilgi veya yönlendirme yok. Bu senaryodaki amacımız da Application'ın kimlik doğrulama mekanizmasını atlatmak ve uzaktan komut çalıştırmak, yani RCE almak. İp adresini tarayıcımıza yazıyoruz. Herhangi bir geri dönüş alamıyoruz. Demek ki port 80 kapalı. Bu videoda şimdi her adımı tek tek açıklayacağım. Pasif bilgi toplamadan başlayıp zafiyet analizi, bypass teknikleri ve son olarak ele geçirme kısmına kadar ilerleyeceğiz.

Nmap scanı ile başlıyoruz. Bu scende -T4 -Pn komutunu kullandım. Çünkü hedefle alakalı hiçbir bilgimiz yok. NMAP varsayılan olarak sadece en çok kullanılan 1000 civarı portu tanıyor. Eğer -T4 -Pn loadunu kullanırsanız bütün 65.535 portun hepsini tarayabilirsiniz. Tabii bu skan normalden çok daha yavaş olduğu için biraz hızlandırmak istiyorum. Onun için de -T4 komutunu kullanıyorum. Şimdi scenimizi başlattık. Sonuçlanmasını bekleyeceğiz. Okey. Taramamız tamamlandı. Biraz büyüteyim şöyle rahat görün diye. Bu portta bir SSH servisi çalışıyor arkadaşlar. Versiyon bilgisine göre bu sistem muhtemelen Ubuntu. Bu aşamada parola denemesi veya brute force girişimi yapmayacağız. Ama ileride bir kullanıcı bilgisini ele geçirirsek SSH üzerinden bağlantıyı kırmayı deneyebiliriz. İhtiyaç olursa tabii.

Şimdi burada dikkat çekici bir detay var. SSH host keys; NMAP bize hedef sistemin SSH servisinde kullanılan public key'lerin parmak izleri, yani kimlik doğrulama anahtarlarını verdi. Bunlar bizim terminal üzerinden SSH ile bağlanırken sunucunun gerçekten o IP'ye ait olup olmadığını doğrulamamıza yarıyor. Yani ilk bağlantı anında karşımıza bu sunucunun parmak izi şu, kabul ediyor musun gibi bir uyarı çıkar ya, işte o parmak izleri bunlar. Eğer bu parmak izi değişirse bu büyük ihtimalle bir man in the middle saldırısı olabilir. O yüzden buradaki veriler aslında güvenlik açısından çok kritik. Biz bir etik hacker, penetration tester olarak bu bilgiye çok ihtiyaç duymasak da hedef sistemin yapılandırmasını analiz ederken güzel bir detaydır. Geçiyoruz.

Port 1337. İşte burası bizim asıl odaklanacağımız servis. HTTP protokolü. 1337 numaralı özel bir portta çalışıyor. Apaachi 2.4.41 versiyonu. Bazı bilinen açıklar olabilir. Özellikle yanlış yapılandırmalar varsa. HTTP başlığına baktığım zaman login olarak görünüyor. Yani burada bir giriş ekranı var ve evet, burada bir güvenlik açığı ipucu var arkadaşlar. PHP oturum çerezi olan PHP session ID için HTTP only bayrağı set edilmemiş. Bu da potansiyel olarak XSS gibi saldırılarda çerezin çalınmasına açık olabilir. Bakacağız. Önce bir login sayfasını inceleyelim. Evet, sıradan bir login sayfası. Direkt default credentialı deneyebiliriz. Admin, admin gibi. Bakalım bize ne söyleyecek. Evet, email ya da password yanlış dedi. Bir de forgot password kısmını deneyelim. Burada da email istiyor bizden. Admin@admin.com. Girelim bakalım. Evet, bu email doğru değildir dedi.

Bu arada ben notlarımı almaya başlayayım. İlk önce açık portlardan başlayalım. Endpoint'leri kaydediyorum. Bir de sayfanın page source'una bakıyorum arkadaşlar. Login sayfasının source koduna baktığımızda bunun bir PHP sitesi olduğunu görüyoruz zaten. Ayrıca bir developer notu dikkatimizi çekiyor. Bize diyor ki tüm özel dizinler HMR alt çizgi ön ekiyle başlar. Bu çok kritik bir bilgi. Çünkü ben direktörü taramasıyla devam edecektim. Fakat gördüm ki dizin isimleri custom isimler. Yani benim genel listemdeki isimlerle eşleşmeyecek. O yüzden ne yapmam lazım? Benim buradaki kurala göre bir word list oluşturup tarama yapmam lazım. Şimdi tarama listemizi buna göre düzenleyeceğim. Bunu yapmak için ilk komutum şu komut arkadaşlar. Bu komut ne yapıyor? Burada benim kullanacağım wordlist dosyasını benim work direktörüme kopyalıyor. Sonra da her satırın başına HMR alt çizgi ekleyerek yeni bir wordlist oluşturacağım. Bunun içinde komutum şu şekilde. Şimdi taramamı başlatabilirim. Bu tarama için de Ferox Buster kullanıyorum. Feroxbuster dizinleri bulmaya başladı. Birazcık daha devam etsin. Reset password'ü biz bulmuştuk zaten. HMR CSS dizinini buldu. HMR images dizinini buldu. HMR images dizinini bir çekelim. Evet bir tane fotoğraf çıktı karşımıza. O da bir çekiç fotoğrafı. Bunu kaydedeceğim. Belki daha sonra ihtiyacım olabilir buna. Bakalım başka neler buldu. Feroxbuster HMR logs dizini ilgimi çekiyor. Çünkü log dosyaları bazen sistemin iç yüzünü gösterebilir. Şimdi oraya bir bakacağım. Error logs adında bir dosya var ve evet, Apachi log dosyaları burada. Log sistemde kimlerin hangi sayfalara erişmeye çalıştığını ve nelerin engellendiğini detaylı bir şekilde gösteriyor. Hemen burada ilk logumuzda ilginç bir hata görüyorum ben. Sunucu bir isteği kendi içinde 10 kez yönlendirmeye çalışmış. Bu genelde yanlış yapılandırılmış .htaccess dosyaları ya da sonsuz döngüye giren bir kimlik doğrulama mekanizmasından kaynaklanabilir. Belki buradan bir login bypass ihtimali çıkabilir. Bakın burada çok enteresan bir log daha var. tester@hammer. Adında bir kullanıcı yanlış parola denemiş. Bu bize iki önemli bilgi veriyor. Gerçek bir kullanıcı adı tester@hammer. Erişmeye çalıştığı dizin restricted area, yani bir kullanıcı adı yakaladık. tester@hammer. Hedef dizinler öğrendik. Restricted area gibi, admin login gibi, protected gibi, lockdown gibi. Açıkçası log dosyası adeta bize burada zafiyet var diye bağırıyor.

Şimdi bu kullanıcı adı ve dizin bilgilerini kullanarak giriş sistemini manipüle etmeye çalışacağız. Hedef kimlik doğrulama mekanizmasını atlatmak ve içeride komut çalıştırmak. Bilgi toplama yaptık, log analizi yaptık. Artık hedef sistemin bize nasıl tepki verdiğini görme zamanı. Özellikle hata mesajları sistemin iç işleyişi hakkında çok önemli ipuçları verebilir. Şimdi bu kullanıcı adını kullanarak yeniden giriş yapmaya çalışalım. Artık elimizde email adresi var. Bakalım bize bir şey verecek mi? tester@hammer. Password 123 dedim. Evet. Invalid email or password diyor. Bu klasik bir yanıt. Sistem hangi kısmın hatalı olduğunu bize göstermiyor. Bu iyi bir uygulama. Çünkü brute force saldırılarına karşı önlem. Bir de parola sayfasını ziyaret edelim. Reset password endpoint'i. Admin hesabını burada da bir deneyeyim. Invalid email address diyor. Demek ki bu sitede admin@hammer.com bir hesap olmadığını biz buradaki error kodundan anlayabiliyoruz. Bir de test@hammer.com deneyelim. Evet, karşımıza bir ekran çıktı. Burası bir 2FA, yani iki aşamalı doğrulama adımı. Şifre sıfırlamak için bize bir kurtarma kodu soruyor. Bu kod muhtemelen test@hammer.com adresine gidiyor. Bazen bir uygulama doğrudan zaaf vermese de küçük tutarsızlıklar ve hata mesajları üzerinden sistemi çözümleyebilir. Bu sayede artık elimizde kayıtlı bir kullanıcı, aktif bir 2FA süreci ve belki de atlatabileceğimiz bir güvenlik mekanizması var. Şimdi bu 2FA'ın nasıl çalıştığını anlamaya çalışacağım. Bunu da Firefox'un developer tool'uyla yapacağım. Önce ekranı büyüteyim birazcık daha rahat görebilmeniz için. Aslında bu işlem için ben Burp Suite de kullanabilirim ama ben genelde ilk araç olarak browser'ın developer tool'unu kullanıyorum. Hem daha hızlı oluyor ilk izlenim açısından hem de Burp'te yapabileceğim bazı şeyleri uğraşmadan burada da yapabiliyorum. Ve bence sizin de bu aracın kullanımını görmeniz önemli. Çünkü çok fazla kullanacaksınız. 180'den geriye sayan bir timer var ve benden 4 haneli bir kod istiyor. Evet, response'u çektiğimde burada rate limit pending 7 diye bir alan görüyorum. Muhtemelen bu her yanlış girdiğimizde değişecek. Bir tane deneyelim. 1903 diyelim. Gördüğünüz gibi rate limit pending 6'ya düştü arkadaşlar. Peki her yanlış girdiğimde cookie'yi değiştiriyor mu? Ona bakmak istedim. Benim PHP session ID'm burada. Bakalım değişecek mi? Yanlış bir şey girelim, 4 tane 0 girelim. PHP session ID'm değişmedi ve rate limitim de 5'e düştü. Burada yanlış bir 4 haneli kod girdiğimizde recovery code ve s parametresini görüyoruz arkadaşlar. Bu da önemli bizim için. Ben bundan şunu anlıyorum. Sistem maksimum olarak 8 denemeye izin veriyor. Ancak bu kısıtlama sadece zamana bağlı. Geri sayım 180 saniyeydi. Yani 180 saniyede 8 kez deneyebiliyorsunuz ve bu süre boyunca aynı PHP session ID'yi kullanıyor. Bu demek oluyor ki sistem 180 saniyelik süre boyunca sabit bir oturum ile çalışıyor. Yani her yanlış denemede oturum resetlenmediği için sunucu bizim toplam kaç defa deneme yaptığımızı sayabiliyor. Bu aynı zamanda şunu da gösteriyor. Kod doğrulama işlemi büyük ihtimalle işlemci tarafında değil, tamamen sunucu tarafında ve session ID'ye bağlı bir rate limit uygulanıyor. Ben şimdi bu kalan 5 hakkımı bir deneyeceğim. Ne olduğunu görmek istiyorum. Belki de tuttururuz. Belli olmaz. Sonuçta 10.000'de bir ihtimalimiz var. 4 haneli bir kodda iki hakkım daha var. Evet. Bütün haklarımızı girince rate limit exceeded diye bir notla karşılaştık. Yani rate limit tamamen doldu arkadaşlar. Bizden daha sonra denememizi istiyor. Tabii biz bunu cookie'yi silerek hemen aşabiliriz.

Şimdi aklımıza şu sorular gelmeli: Rate limit sistemini atlatabilir miyiz? Session ID'yi sıfırlarsak 8 deneme daha elde edebilir miyiz? Alternatif oturumlarla denemeyi sürdürebilir miyiz? Recovery kodu tahmin edilebilir mi? Bunları test ederek ya rate limiti aşarız ya da belki sistemde başka bir zayıf nokta buluruz. Yani demek istediğim sadece saldırmak değil, gözlemlemek de çok önemli. Bu sayede sistemin sınırlarını anlamaya başladık. Artık elimizde çok net bir hedef var. resetpassword.php PHP endpoint'i. Bu sayfaya recovery code ve s=180 parametreleri ile istek gönderiyoruz. Recovery code 4 haneli digit kodumuz. S parametresi de kaç saniye kaldığını gösteriyor.

Akıllardaki en önemli soru şu: Peki bu kodu brute force ile kırabilir miyiz? Cevap evet, ama zekice yapmamız lazım. Bu yüzden bir Python script yazacağız. Ne kullanacağız bu scriptte? Her denemede farklı bir X-Forwarded-For IP adresi kullanacağım; bu sistemin bizi engellemesini zorlaştıracak. Aynı anda 50 tane farklı istek göndereceğim. İşlemi paralel hale getireceğim. Yani daha hızlı tarama yapıp 180 saniye içinde 10.000 option'ı tamamlamaya çalışacağım. Her isteğin cevabını analiz edeceğim. Eğer invalid or expired recovery code mesajı yoksa ve new password gibi bir yanıt geldiyse doğru kodu bulmuş oluyorum. Ve en önemlisi doğru kodu bulur bulmaz tüm denemeleri durdurup yeni parolayı sistemli bir şekilde otomatik olarak göndereceğim. Şimdi benim bu script'i yazmam zamanımı alacak. Bunu da istemiyorum. O yüzden neden yapay zeka asistanım ChatGPT'yi kullanmayayım? Bakalım böyle bir script'i yazabilecek mi? Yazsa da işe yarayacak mı? Göreceğiz.

Evet arkadaşlar, şöyle bir prompt yazdım: Hedef IP'ye ve endpoint'e recovery code ve s=180 parametrelerini kullanarak bir POST request gönder. Bunu yaparken X-Forwarded-For başlığını random IP adresleriyle kullan ki rate limit'e takılmayalım. Aynı anda 50 istek birden gönder, daha hızlı olsun. Cevabı kontrol et: Invalid or expired recovery code olmasın. New password olsun. Eğer new password bulursan bütün işlemleri sonlandır, son bir POST request göndererek parolayı "thehacker talks" olarak değiştir dedim. O da bana şöyle bir Python script'i verdi. Şimdi bu Python script'imizi kopyalayalım. Hemen nano attack.py diye bir dosya başlatıyorum. Buraya yapıştırıyorum. Dosyamı save ediyorum ve çıkıyorum. Şimdi ben bu script'i çalıştıracağım ve çalışacak mı çalışmayacak mı göreceğiz arkadaşlar. Evet, scriptimiz çalışmayı bitirdi. Brute force atağı sonlandırdı. Recovery kodu buldu: 3141 olarak. Bulduktan sonra yeni bir parola gönderdi. Parolayı "The Hacker Talks" olarak değiştirdik. Yani şu anda tester@hammer.com user'ının parolası "The Hacker Talks" olması gerekiyor. Bu korkunç derecede kolay oldu. Bence bu kadar kolay olmaması gerekiyordu ama gerçekten işe yaradı mı görmenin sadece tek bir yolu var. Şimdi ben o parolayı deneyeceğim. Login ekranımıza geri dönüyorum. Parolamı da "The Hacker Talks" olarak giriyorum arkadaşlar ve boom, içerideyiz. Welcome Tor diye bir mesaj karşıladı bize.

Artık elimizde geçerli bir kullanıcı adı ve şifre var. Kısa süre geçmeden sistem beni otomatik olarak oturumdan attı. Muhtemelen cookie zamanlayıcılı. Bunu kontrol edelim, tekrar giriş yaparak bakalım ne bulacağız. Ben şurada hemen Stu açayım. Tekrar bir login alıyorum. Evet, burada cookie value'sunda persistent session no diyor, domainimiz, path'imiz ve burada expiration'ımız var. Aynı tarihe kopyalanmış. Bizim bunları değiştirmemiz gerekecek arkadaşlar. Hemen tekrar giriş yapıyorum çünkü bizi sistem dışarı atıp duruyor. Önce persistent'ı yes yapıyorum ve bu expiration date'i de 30 Haziran'a çekeyim. Şu anda beni sistemin atmaması gerekiyor. Persistent session yes yapıldı. Burada PHP session ID'mi görüyorum ve başka bir token görüyorum. Bu bir JWT token arkadaşlar. Yani buradaki değer no'ydu. Bu değer no olduğu için sistem belli aralıklarla kontrol yapıyor ve beni oturumdan çıkartıyor. Bunu yes yaptım ve expiration tarihini ileri bir zamana çektim. Ayrıca burada PHP session ID ve JWT token var. Bu sayede artık otomatik çıkışı engellemiş olduğumu düşünüyorum. Şimdi panelde komut çalıştırmayı deneyeceğim. Önce kendi komutlarımı bir deneyeyim. umi. umi komutu izinli değil. id, cat, etc, password izinli değil. ls. Evet arkadaşlar, sadece ls komutu izinli gibi görünüyor. Diğer komutların hepsi engellenmiş. ls çıktısında ise çok ilginç bir şey var. d key uzantılı bir dosya görüyorum. Bunu browser'da açmaya çalışabiliriz. Ya da başka bir yol isterseniz komutumuz şu şekilde: curl. Evet, bu bir anahtara benziyor. Bunu bir notlarımızın arasına alalım. Developer Tools'ta JWT tokenlarını görmüştük. Tokenlar genellikle kullanıcının kimliği, yetkileri ve oturum bilgilerini taşır. Şimdi kendi tokenımı incelemek için jwt.io aracını kullanacağım. JWT.io web sitesinde JWT tokenlarının ne anlama geldiğini görebilirsiniz arkadaşlar. Üç alandan oluşuyor: Header, Payload ve Signature alanlarından. Burada header'da görüyoruz ki bir kid alanı var. Bu key ID anlamına geliyor arkadaşlar. Yani token ID'yi bu dizinden çekiyor. Ayrıca payload'da da bizim user ID'miz var. Bir email'imiz var kullandığımız ve rolümüz belirliyor. Rolümüz user rolü, yani privilege sahibi bir rol değil. Burası da signature. Tabii ben şimdi ilk etapta buradaki user rolünü admin rolüne çevirmeyi deneyeceğim. Bakalım çalışacak mı? Encoder'a gidiyorum ve user'ı admin'e çeviriyorum. Admin'e çevirdiğim zaman buradaki token değişiyor arkadaşlar. Token'ı alıyorum. Geri döndüm. Bir istek daha göndereyim ls adında. Buradaki en son isteğe geri döndüm. ls isteğinin response'u görüyoruz. Burada bakın. Request ls, response bulduğumuz dosyalar. Buraya umi yazarsam eğer yeni bir POST request geldi. Requestim komutu, response bu komut geçerli değildir diyor. Şimdi ben bu komutu tekrar göndereceğim. Onu da şunu biraz büyüteyim, daha rahat görün. Sol tarafta yapacağım. Burada gördüğünüz gibi PHP session ID'miz var. Ayrıca Authorization: Bearer alanı var. Bu benim var olan JWT tokenımı gösteriyor. Ben bu tokenı şimdi yenisiyle değiştirdiğim zaman çalışacak mı diğer komutlar? Admin olabilecek miyim onu görmeye çalışacağım. Tekrar gönderdim ben bu isteği. Bana invalid token signature verification failed diye bir response verdi web sitesi. Yani bu tokenı kabul etmedi. O yüzden benim başka bir şeyler yapmam lazım bu token üzerinde. Hemen şunu hatırlıyorum. Ben sistemde bir d.key dosyası bulmuştum. Neden bu d.key dosyasını denemeyeyim? Evet, dizinimi değiştirdim ve key dosyasının adını buraya koydum. Rolümü admin olarak tutacağım. Buraya secret olarak da benim daha önce bu key dosyasının içinde bulduğum değeri gireceğim. Şimdi yeni bir token oluştu. Bakalım bu sefer kabul edecek mi? Tokenımı girdim. umi komutunu tekrar gönderiyorum ve aldım. Output'u aldım arkadaşlar. /var/www/html/data output'unu aldım. Evet, farklı komutları çalıştırabiliyoruz. Artık admin yetkisine sahibiz. Hemen cat /etc/passwd deneyelim. Evet, bütün kullanıcıları ve parola hash'lerini burada görebiliyorum.

Evet hackerlar, admin privilege aldık. Bir sistemi daha ekledik. Bu zafiyet türüne key injection ile JWT privilege escalation diyoruz. Sistem token'ın doğruluğunu kontrol ederken bizim belirttiğimiz key ID yolundaki dosyayı anahtar olarak kullandı ve biz bunu manipüle ettik. Bu tarz saldırılarda küçük detaylar çok önemli. Cookie değerleri, token yapıları, dosya yolları hepsi bir saldırı vektörüne dönüşebilir. Dikkatli bakarsan açıklar konuşur.

Eğlenceli ve öğretici bir senaryonun daha sonundayız. Ama şimdi bazılarınız diyor ki Hasan bu anlattıkların çok iyiydi ama gerçek dünyada işime yarar mı? Cevap net: Kesinlikle evet. Şimdi ekranda gördüğün tablo JWT zafiyetlerinin en bilinen ve back-end platformlarında en çok karşılaşılan türlerini özetliyor. Biz bu videoda özellikle 5 numaralı saldırı tipini, yani key ID header traversal tekniğini uygulamalı olarak gördük. Bu saldırı authentication bypass ve privilege escalation gibi iki büyük zafiyetin birleşimi. Gerçek hayatta böyle bir açıkla karşılaşırsanız ya da yakalarsanız bu çok kritik bir bulgu olur. Benden söylemesi. Burada öğrendiğin her adım: pasif bilgi toplama, dizin taraması, komut enjeksiyonu, JWT manipülasyonu; hepsi gerçek hayatta karşına çıkabilecek zafiyetlerin birebir simülasyonu. Bu bilgilerle bir sistemin açıklarını kötüye kullanmak yerine onları daha güvenli hale getirmeyi öğreniyorsun. İşte gerçek kıymet de tam burada başlıyor. Eğer bir şeyler öğrendiysen ki eminim öğrendin, kanala abone olmayı, bu videoyu beğenmeyi ve bildirimlerini aktif etmeyi unutma. Soruların varsa yorumlara yaz. Birlikte tartışalım. Senin önerilerinle bu içerikler daha da zenginleşiyor. Bir sonraki videoda yeni bir zafiyet ve yeni bir hedefle yine burada olacağız. O zamana kadar etik kalın, meraklı kalın ve unutmayın gerçek hackerlar sistemleri yıkmak için değil korumak için öğrenir. Stay safe, stay sharp. [Müzik]