@SkullZ güzel güzel nasıl hekledim ettim diye yazılar yazmış yıllar sonra canımı çektirdi bende eskiden yaptığım işlerde kullandığım birkaç teknikten bahsedeyim istedim.
öncelikle her bulduğunuz açığın sizi direk sistemin içine sokmayacağını bilmeniz lazım. o yüzden bir açık bulup tamam oldu bittiye getirmeden iyice sağını solunu analiz edin. bulduğunuz açık xsstir, sitenin başka bir yerinde sql yatıyordur xss ile boşa vakit kaybedersiniz.
örneğin şuan aktif olmayan fakat zamanında trde herkesin bildiği bir forumun moderatörlerinden biriyle dalaşmıştık. sinirlenip domain firmasına zorlamaya başladım.
firmada sql injection vardı fakat user tablosuna hiçbir şekilde erişemiyordunuz. daha doğrusu 3-4 farklı db vardı userlar hangi tabloda hem bilinmiyor hem de tabloya ait dataları çekemiyordunuz.
admin paneli belliydi ama sadece veritabanında kayıtlı ip adreslerinden erişim sağlanabiliyordu. totalde 11 adet ip adresi kayıtlamışlar ve bunların 7 si çin 2 si amazon aws ip'siydi hatırladığım kadarıyla. yani admin hesabını bile okusanız o iplerden dalmanız gerekiyordu.
ve stack query açık olmadığı için herhangi bir şekilde update de atılmıyordu. dolayısıyla işlevsel olarak hiçbir şekilde kullanılmıyordu.
normal şartlarda buradaki açık bi sike yaramaz diyip kestirip atar başka açıklara bakılır. ama ben tabloların hepsini didik didik ettim belki bir yerden ekmek çıkar diye. burada hedef domaine sızmak için firmanın domain transfer kodlarının tutulduğu tabloyu gözüme kestirdim. çünkü herhangi bir şekilde userlara ait ne şifre sıfırlama kodlarının olduğu yeri okuyabiliyordum ne de üye bilgilerini. ama domain transfer kodlarının olduğu tabloyu okuyabiliyordum. eskiden kalma bir ss'i koyayım hatta
normalde şifre sıfırlama urllerinin tutulduğu tabloyu okuyabilseydim direkt olarak urlyi çekip şifreyi sıfırlayacaktım. ama o da olmadığı için kullanıcı faktörünü devre dışı bırakıp domainle bağlantılı hangi veriyle ne yapabiliriz ona odaklanmamız gerekiyordu. domain transfer kodlarının olduğu tablonun okunabiliyor olması demek hala domaini transfer edebilmek için bir ihtimalin olması demek.
sitenin canlı desteğine bağlanıp domain transferi için talep oluşturmaya çalıştığımı fakat oluşmadığını söyledim. panelden kaynaklı bir hata sebebiyle oluşturamadığım için (sözde amk) onlardan oluşturmalarını rica ettim. basit bir iki şirin oyundan sonra domain transfer talebini oluşturdular. domain transfer kodlarının olduğu tablodaki son 10 kayıdı id'ye göre sıralayarak listeledim ve domain transfer kodunu kaftiledim. daha sonra kodu canlı desteğe verip transfer sürecinde yardımcı olmalarını istedim (kodu verdiğim için ek bir doğrulamaya ihtiyaç duymadılar, burda biraz sm konuşturun)
ve sonuç:
diğer bir firmada ise yine aynı forumdan bir admini hacklemek için kasmıştım. firma scripti kendi php ile yazmış ve template engine olarak smarty kullanmıştı. pathleri urlleri kurcalamam sonucu tüm template dosyalarını indirmiştim. ama .tpl dosyalarından çok kritik bir veri elde edemedim.
daha sonrasında açık aramak için açmış olduğum hesabın şifresini unuttum (dışarı çıkıp gelmiştim, notta etmedim bir yere amk) ve şifre sıfırlamak için mail adresine link yollattım.
normalde şifre sıfırlamada hesabınıza ait bir hash oluşturulur ve bütün işlemler o hash üzerinden yapılır. bu firma da aynı şekilde hashli bir link yolladı ve şifre sıfırlama ekranına yönlendirdi.
fakat bu firmada şöyle saçma bir mantık vardı. hash sadece sizi şifre sıfırlama ekranına yönlendirene kadar işinize yarıyordu. şifreyi sıfırlamak için yeni şifrenizi ve tekrarını girdiğinizde request attığı urlde hashi göndermiyor ve hashle alakalı hiçbir kontrol yapmıyordu.
tek kontrol post datadaki eposta adresi ile yine post datadaki id adresinin eşleşip eşleşmediğiydi. yani şifre sıfırlamada kullanıcıya ait id ve epostayı gönderiyor. eğer ikisi eşleşirse post datada gönderdiğin şifreyle o hesabı sıfırlıyordu.
hedef domaine whois attığımda eposta adresi açıktı, whois gizleme yoktu. kullanıcının mail adresini biliyordum fakat user id'sinin ne olduğu hakkında fikrim yoktu. burada da gece saati olmasını bekledim ve mail adresini alıp id değerine basit bir python scripti ile enumerate attım. ortalama 10 dakika sonra belirlediğim şifreyi hedef elemanın mail adresiyle denediğimde hesabına giriş yaptım.
onun sslerini koymayacam çünkü bildiğim kadarıyla hala takılıyor, ayıp olmasın. geçmiş olaylardan ötürü yeniden bi gerginliğe gerek yok.
son zafiyetin owasp'taki adı idor (yanılmıyorsam) araştırmak isteyen arkadaşlar tam teknik detayına araştırıp hakim olabilirler. ben kendi uyguladığım yöntemleri anlattım
ne uzun olmuş amk. sonuna kadar okuyana allah sabır versin, ben kaçtım
öncelikle her bulduğunuz açığın sizi direk sistemin içine sokmayacağını bilmeniz lazım. o yüzden bir açık bulup tamam oldu bittiye getirmeden iyice sağını solunu analiz edin. bulduğunuz açık xsstir, sitenin başka bir yerinde sql yatıyordur xss ile boşa vakit kaybedersiniz.
örneğin şuan aktif olmayan fakat zamanında trde herkesin bildiği bir forumun moderatörlerinden biriyle dalaşmıştık. sinirlenip domain firmasına zorlamaya başladım.
firmada sql injection vardı fakat user tablosuna hiçbir şekilde erişemiyordunuz. daha doğrusu 3-4 farklı db vardı userlar hangi tabloda hem bilinmiyor hem de tabloya ait dataları çekemiyordunuz.
admin paneli belliydi ama sadece veritabanında kayıtlı ip adreslerinden erişim sağlanabiliyordu. totalde 11 adet ip adresi kayıtlamışlar ve bunların 7 si çin 2 si amazon aws ip'siydi hatırladığım kadarıyla. yani admin hesabını bile okusanız o iplerden dalmanız gerekiyordu.
ve stack query açık olmadığı için herhangi bir şekilde update de atılmıyordu. dolayısıyla işlevsel olarak hiçbir şekilde kullanılmıyordu.
normal şartlarda buradaki açık bi sike yaramaz diyip kestirip atar başka açıklara bakılır. ama ben tabloların hepsini didik didik ettim belki bir yerden ekmek çıkar diye. burada hedef domaine sızmak için firmanın domain transfer kodlarının tutulduğu tabloyu gözüme kestirdim. çünkü herhangi bir şekilde userlara ait ne şifre sıfırlama kodlarının olduğu yeri okuyabiliyordum ne de üye bilgilerini. ama domain transfer kodlarının olduğu tabloyu okuyabiliyordum. eskiden kalma bir ss'i koyayım hatta
normalde şifre sıfırlama urllerinin tutulduğu tabloyu okuyabilseydim direkt olarak urlyi çekip şifreyi sıfırlayacaktım. ama o da olmadığı için kullanıcı faktörünü devre dışı bırakıp domainle bağlantılı hangi veriyle ne yapabiliriz ona odaklanmamız gerekiyordu. domain transfer kodlarının olduğu tablonun okunabiliyor olması demek hala domaini transfer edebilmek için bir ihtimalin olması demek.
sitenin canlı desteğine bağlanıp domain transferi için talep oluşturmaya çalıştığımı fakat oluşmadığını söyledim. panelden kaynaklı bir hata sebebiyle oluşturamadığım için (sözde amk) onlardan oluşturmalarını rica ettim. basit bir iki şirin oyundan sonra domain transfer talebini oluşturdular. domain transfer kodlarının olduğu tablodaki son 10 kayıdı id'ye göre sıralayarak listeledim ve domain transfer kodunu kaftiledim. daha sonra kodu canlı desteğe verip transfer sürecinde yardımcı olmalarını istedim (kodu verdiğim için ek bir doğrulamaya ihtiyaç duymadılar, burda biraz sm konuşturun)
ve sonuç:
diğer bir firmada ise yine aynı forumdan bir admini hacklemek için kasmıştım. firma scripti kendi php ile yazmış ve template engine olarak smarty kullanmıştı. pathleri urlleri kurcalamam sonucu tüm template dosyalarını indirmiştim. ama .tpl dosyalarından çok kritik bir veri elde edemedim.
daha sonrasında açık aramak için açmış olduğum hesabın şifresini unuttum (dışarı çıkıp gelmiştim, notta etmedim bir yere amk) ve şifre sıfırlamak için mail adresine link yollattım.
normalde şifre sıfırlamada hesabınıza ait bir hash oluşturulur ve bütün işlemler o hash üzerinden yapılır. bu firma da aynı şekilde hashli bir link yolladı ve şifre sıfırlama ekranına yönlendirdi.
fakat bu firmada şöyle saçma bir mantık vardı. hash sadece sizi şifre sıfırlama ekranına yönlendirene kadar işinize yarıyordu. şifreyi sıfırlamak için yeni şifrenizi ve tekrarını girdiğinizde request attığı urlde hashi göndermiyor ve hashle alakalı hiçbir kontrol yapmıyordu.
tek kontrol post datadaki eposta adresi ile yine post datadaki id adresinin eşleşip eşleşmediğiydi. yani şifre sıfırlamada kullanıcıya ait id ve epostayı gönderiyor. eğer ikisi eşleşirse post datada gönderdiğin şifreyle o hesabı sıfırlıyordu.
hedef domaine whois attığımda eposta adresi açıktı, whois gizleme yoktu. kullanıcının mail adresini biliyordum fakat user id'sinin ne olduğu hakkında fikrim yoktu. burada da gece saati olmasını bekledim ve mail adresini alıp id değerine basit bir python scripti ile enumerate attım. ortalama 10 dakika sonra belirlediğim şifreyi hedef elemanın mail adresiyle denediğimde hesabına giriş yaptım.
onun sslerini koymayacam çünkü bildiğim kadarıyla hala takılıyor, ayıp olmasın. geçmiş olaylardan ötürü yeniden bi gerginliğe gerek yok.
son zafiyetin owasp'taki adı idor (yanılmıyorsam) araştırmak isteyen arkadaşlar tam teknik detayına araştırıp hakim olabilirler. ben kendi uyguladığım yöntemleri anlattım
ne uzun olmuş amk. sonuna kadar okuyana allah sabır versin, ben kaçtım
