☀ Bu soru tam da yeni bir hedef üzerinde araştırma yaptığım ve hata avladığım bir dönemde soruldu, yani oturup hatırlasaydım süreç boyunca öğrendiklerimi not ederdim.
Hata bulma 2 ana yönteme ayrılır:
- Manuel İnceleme / Denetim
- Fuzzing
Bu makalede artık fuzzing'den bahsetmeyeceğim çünkü bundan daha önce bahsetmiştim: libFuzzer — Geliştiriciler için ürün hatası test yöntemi ve Bilgi güvenliği - Öğrenmeye Başla
Bununla birlikte, sanırım fuzzing hakkında bilgi edinmeye ve daha derinlemesine araştırma yapmaya başlayabilirsiniz, çünkü artık zamanımın çoğunu fuzzing üzerinde çalışarak geçirmiyorum, bu yüzden fazla derine inmek istemiyorum.
Yıllarca yapıp gözlemledikten sonra en önemli şeyin tutku, pratik ve azim olduğuna inanıyorum. Bunlara sahip olduğunuzda sonuç almak an meselesidir.
Ve bu makale çok teknik olmayacak çünkü çevrimiçi olarak diğer hata avcıları tarafından paylaşılan birçok teknik makale var, her hedefin farklı bir süreci, ilkesi ve bulma yöntemi var. Kendi adıma diğer kanallarda da pek çok paylaşım yaptım: youtube ve ask.fm. Gelecekte daha fazla teknik makale konuşabilirim/yazabilirim (eğer tembelsem).
Lütfen sıkışıp kaldığınızda veya nereden başlayacağınızı bilmediğinizde bunu bir kılavuz olarak düşünün...
Bu uygulamanın/nesnenin temel işlevlerini öğrenin, herhangi bir özel işlevin olup olmadığını kontrol edin, not alın, kimlik doğrulamanın nasıl yapılacağını, hangi platformun/çerçevenin kullanılacağını (varsa) vb.
Kendinizi bir geliştiricinin yerine koyun, bir fonksiyonu kodlamak isteseydiniz ne yapacağınızı hayal edin. Bu nedenle güvenlik zihniyetine sahip geliştiricilerden gelen ve oldukça etkili çalışan birçok hata avcısının olduğunu görüyorum.
Hedef dilin hata türlerini ve püf noktalarını öğrenin (örneğin: php sıklıkla sql'den muzdariptir, $_GET bir dizi olarak iletilebilir, falan filan. Ruby için, regexp sida. Java için, java-seri durumdan çıkarma, vb.) Bu Bilgi toplamayı ve uzun bir süre boyunca öğrenmeyi gerektirir. Çünkü bazen geliştirici kodu hatasız olabilir ancak hata, bileşen dilinde ve onu çevreleyen hilelerde yatmaktadır.
Anlamadığınızı hissettiğinizde hata ayıklayın. Oldukça titrek ve anlaşılması zor bazı kodlar olacaktır. Mümkünse, önemli noktalarda hata ayıklayıcıyı ve kesme noktasını açın.
Nesneyi birçok yolla araştırın: onunla ilgili yazıları, raporları, analizleri, taahhütleri/yamaları, blog gönderilerini bulun. Ancak burada bu hataları gerçekten anlamanız, mümkünse yeniden üretmeniz (ortamı ayarlamak için eski sürümleri veya yamaları bulmanız) gerekir.
Çünkü bunu yaparken yavaş yavaş hedefin ve onu kodlayan kişinin zayıf yönlerini görselleştireceksiniz (örneğin, javascript motorları yan etkilere, geri dönüş tuzaklarına, JIT optimizasyonuna vb. karşı çok hassastır).
Tıpkı belgeyi okurken ve aynı anda denetlerken olduğu gibi, baktığınız kodun genel resmini görselleştirmenize izin vermek çok zaman kazandırabilir.
Aşama 2: Hata bulmaya alıştıktan sonra şunları yapmalısınız:
Daha uzağa bakmaya çalışın, bir hata raporu okumayın ve sonra sadece tamamen aynı olan başka bir tane bulmaya odaklanın, o zaman sadece alçakta asılı meyve alırsınız. Onu bulan kişi gibi düşünme pratiği yapmaya çalışın, onun düşünme sürecini simüle etmeye çalışın, belki de bu noktayı garip ve ilginç buluyorlar ve bu yüzden daha derine iniyorlar, sonra bu adımda bunu görüyorlar, falan falan.
Bu hatayı tamamen anlamalısınız, çünkü aynı hedefe sahip olmanız çok muhtemeldir, ancak başka bir varyasyon bulmak için farklı bir yol seçebilirsiniz. Para toplayan $$$. Benim pdfium böcek yığınım bunun kanıtıdır.
Önde olan ve "büyük beyinli" olanların düşünce akışını yakalamaya çalışın, uzaklaştırın, nasıl düşündüklerini, sorunları nasıl çözdüklerini görmeye çalışın, bunu neden yapıyorlar? Bunu neden bulabildiler?
Arkanıza yaslanın ve düşünün
İlk başta raporları kılavuz olarak kullanın. Bir noktada denetimin kapsamını genişletmeniz ve diğer alanlardaki kodlar hakkında bilgi edinmeniz gerekecektir.
Bir şeye çok uzun süre takılıp kalırsanız, kendinizi yenilemek için kısa bir süreliğine yapacak başka bir şey bulmalısınız.
Son vuruşşş — . ϟ
Bazen nereye gideceğini bilmediğiniz kodu araştırmak/denetlemek için zaman harcamanız gerekir, herhangi bir sonucu olacak mı?
Ama... kabul edelim, araştırma böyledir, eğer zor, yeni yolu seçmezseniz, kayda değer bir şey başarmak zor olacaktır.
Ancak süreçte, bu hedef etrafında bilgi edinecek ve yazılımın/protokollerin/vb.'nin çalışma prensipleri hakkında daha fazla bilgi edineceksiniz. Daha önce bilmediğim şeyler böyleydi, bunu bir hobi olarak düşünün, aynı zamanda birçok farklı beceriyi uygulayın, olumlu düşünün!
Yorum Gönder