SOC Toolkit v3.0 : BugHunter’dan Incident Response Tavsiyeleri
Selamlar, değerli meslektaşlarım ve ileride meslektaşım olacak kardeşlerim. Bu makalemde sektöre ilk adım attığım Bug Hunter ünvanım ile son yıllarımda kariyerimi şekillendiren Blue Team Member olarak Web Incident’larını nasıl ele alabileceğimize değineceğim. Öncesinde belki göz attığınız Web olaylarını ele alan MindMap’imi incelemenizi tavsiye ederim;
Bu Mindmap’imi açıklayarak Sizlerle Web alanındaki bilgilerimi paylaşıyor olacağım. Bu Mindmap’imin geliştirilmesinde bana değerli feedback’lerini katan Okan Hazırcı, Emrah Savaş, Ömer Sefa Umay, Caner Ertem, Taylan Barışık, Caner Hamze Canbaz, Hilal Ateş, Halis Baş, Esra Nur Soylu, Burak Özdörtdivanlı, Semra Durna, Onur Can’a sonsuz teşekkürlerimi sunarım. Adımlarımızı şimdi sıralıyor olalım;
- SIEM’de Query’i kontrol etme
Ilk adımda Siem’de varsayın Cloumn’lara yansıyan ve anlam veremediğiniz yada Query’de Note kısmına yansıyan değişkeni decode etmeniz gerekmekte, bu değer genelde hedeflenen ana saldırı vektörünü içerebilir. Bunu decode edip ilerleyen aşamalarda araştırmanıza dahil etmelisiniz.
2. Hedeflenen Path’in Analizi
Bu adımda önemli olan incelenen Query’de hedeflenen birimin bir değişken (parametre) “?alican” veya bir dizin mi olduğu “..\alican\…” olduğu kanısına varılmasıdır. Bu adımda hedeflenin bir parametre olması bizi XSS, SQLi veya parametre bazlı hedeflenen bir web atağına götürebileceğidir. Path bazlı denemelerde alarm ya hedef dışı yada path bazlı alarm kaynaklı olacaktır.
3. Result Code Kontrolü
Hedeflenen Request’in Sunucu taraflı dönen responce’u incelenip dönen yanıt ele alınmalıdır. Bu yanıtlardan;
- 2xx
- 3xx
Türevleri bizim için saldırı adımlarının devam niteleği taşıdığı ve incident incelemesinin devam ettiği anlamına gelmektedir.
4. HTTP Request Type Check
Ilerleyen adımlarda hedeflenen ilk request’in ardından süre gelen HTTP Request tiplerinin incelemesi sağlanmalı ve Post, Options, Delete ve benzeri sorun teşkil edebilecek request’lerin takibi sağlanmalıdır.
Ve yine aynı şekilde GET metodu ile aktarım olsada hassas bilgi vea unique hash bilgisi paylaşımları kontrol edilip, olası hash değer paylasımları yazılım ekibine bildirilmelidir.
Örneğin: “ …./?auth=123123321…”
5. Decode edilen ifade Analizi
ilgili URL’de geçen ifadeleri decode ettiğinizde < , > ,” , “ , (, ), gibi ifadeler ve JS’in temel komut ifadeleri script, onload benzeri ifadeler veya yarım ifadeciklere “ ononloadload” benzeri ifadelere rastlıyorsanız yüzleştiğiniz saldırının XSS olma ihtimali oldukça yüksektir. Burda özellikle Stored ce Reflected olmak üzere XSS türevlerine odaklanmalısınız. Ilgili hedeflenen bölge “ ?search=…” gibi parametrelerse Reflected XSS olma olasılığı fazla olduğu gibi “?form=..” benzeri ifadelerle form doldurma niteliği taşıyan stored nitelik oluşturabilecek yapıda ise Stored XSS’i göz ardı etmemelisiniz.
Query’de SELECT, ONION, veya çeşitli eşitlik niteliği taşıyabilecek tanımlamalar “ ‘1=1’=1'’ “ gibi ifadeler içeriyorsa SQLi olma ihtimali kuvvetlenecektir. Komplike SQLi ve XSS veya Command Injection ifadeleri içeren Query’lere rastlıyorsanız SQLMap benzeri tool tarafından komplike bir saldırı denemesi olduğunu varsayabilirsiniz.
Atak vektörunde “ ../../../ “ benzeri dizin tabirleri yer alıyorsa Path Traversal yada LFI erişimi denemesi olduğunu varsayabilirsiniz. Bu durumda Query ve path’den yola çıkarak kendinizde Web browser’ınızdan deneme yaparak teyit edebilirsiniz.
6. Temel SQLi’de hedef yönetim ve giriş panelleridir, gelişmiş attack vektörlerinde hedeflenen search yeteneğine sahip parametrelerdir. “ ?as=123..” bu parametrelere yapılan denemelerde SQL sorgulamada sanatizasyon yapılmadıysa backend’de etki bulacak ve bypass edecektir. Burda önemli olan Result Code’un önemsiz oluşudur. 500 veya 400 serisinde dönüşler Blind SQLi’de ve Error Based SQL’de kullanılabilecek Responce’lar olduğundan göz ardı edilmemelidir. Ve yine aynı şekilde Time Based, Error Based SQLi denemeleride göz ardı edilmemelidir.
