Web Application Security

Docker Exploit = داکر 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

ابزارهای حرفه‌ای برای باگ هانتینگ! در info-disclosure.ir، با ابزارهای پیشرفته واچر، به راحتی آسیب‌پذیری‌ها را شناسایی و پیگیری کنید. برای شفاف‌سازی باگ‌ها به ما بپیوندید! ‏info-disclosure.ir – جایی که باگ‌ها شفاف می‌شوند. Professional tools for bug hunting! At info-disclosure.ir, easily track and identify vulnerabilities with our advanced Watchers. Join us for bug disclosure! info-disclosure.ir – Where bugs get disclosed. site : https://info-disclosure.ir

خوش‌حال میشم با اشتراک گذاری از کانال حمایت کنین😁❤️🙏

2️⃣ استفاده از DNS Rebinding برای بایپس SOP : طبق فلوی مرحله قبل میتونیم 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 حساسش چیه. 2. باید دامنه هکر رو دقیقا به همون آیپی که روی آن web application نصب شده resolve کنیم. 3. اگه وب اپلیکیشن داخلی روی پورت خاصی هست، ماهم باید به اون پورت درخواست ارسال کنیم.

⁉️چه زمانی DNS rebinding نمیتونه SOP رو bypass کنه؟

1. وقتی authentication نیاز باشه. 2. وقتی روی 192.168.1.20 SSL/TLS وجود داشته باشه.(بخاطر مچ نشدن certificate جلوی حمله گرفته میشه)

#DNS_Rebinding

آسیب پذیری 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 تعریف کنیم. 2. اول روی ورودی کاربر DNS resolution انجام بدیم و روی آیپی آن blacklist check رو انجام بدیم. برای مثال هکر یه دامنه بالا میاره به اسم dns.attacker.com که به آیپی 127.0.0.1 اشاره میکنه. با این روش جلوش گرفته میشه.

اگه تا این حد امن شده باشه، هکر میتونه از HTTP redirect ها استفاده کنه و داخل سورس کدش به 127.0.0.1 redirect بشه. اما این روش در صورتی جواب میده که follow redirect انجام بشه و قبل از ارسال درخواست توسط فانکشن آسیب پذیر به SSRF، ری دایرکت به 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

امنیت اپلیکیشن قسمت سوم = نمونه کد زیر رو در نظر بگیرین:

<?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 های سامانه افشا بشه؟ بله. به غیر از آسیب پذیری هایی مثل RCE و Command injection، آسیب پذیری دیگه ای هم وجود داره که میتونه منجر به افشای environment variable های سامانه بشه که در آینده بهش اشاره میکنیم. اما احتمال وجود این آسیب پذیری از stack trace error و افشای source code خیلی کمتره پس این روش امنیت بیشتری از روش سنتی داره. #application_security

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) Cross-Origin Resource Sharing (CORS) Dependency Confusion / Abuse JSON Web Token (JWT) Misconfiguration Missing Security Headers

Client-Side Codebase Testing

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 Misconfiguration Security Assertion Markup Language (SAML) Misconfiguration Google Firebase IAM Misconfiguration Keycloak IAM Misconfiguration

Application Logic Testing

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

https://blog.devsecopsguides.com/ #resource

تفریح جدید جدیدا همچین مواردی رو چندبار دیدم که یه شخص حرفه ای خودشو به عنوان یه نیروی 0 کیلومتر معرفی میکنه که بقیه راهنماییش کنن واسه شروع و بعد کلی وقت گذاشتن که پیش خودت فکر میکنی داری به یه تازه کار کمک میکنی، میبینی اون شخص اصلا تازه کار نیست و همش سرکار بودی. اینکار باعث میشه اگه یکی هم واقعا تازه بخواد شروع کنه بخاطر این موارد راهنماییش نکنن. #منهای_امنیت

🚨 WatchTower Bug Bounty: Your Ultimate Hunting Radar! 🎯 Always on the lookout for the latest in the bug bounty world? You’ve found your spot! At WatchTower, we keep you updated with the freshest and hottest intel: 💻 New Bug Bounty Programs 🌐 Fresh and actionable assets 📊 Real-time updates on program statuses 📂 JS file monitoring to uncover hidden vulnerabilities ✍️ The best and latest writeups from top hunters ✨ Join a community of passionate and professional bug hunters striving for growth and success. 👣 Step up your game and hunt like a pro! 📌 Join us now: @infodisclosure WatchTower: Your companion in the never-ending hunt! ----------------------------------------------------------- 🚨 واچ‌تاور باگ بانتی: برج دیده‌بانی شکارچی‌ها! 🎯 اگر همیشه به‌دنبال جدیدترین‌ها در دنیای باگ بانتی هستید، اینجا جای شماست! در کانال WatchTower، شما رو با تازه‌ترین و داغ‌ترین اطلاعات به‌روز نگه می‌داریم: 💻 جدیدترین برنامه‌های باگ بانتی 🌐 فرش‌ترین asset‌های قابل‌استفاده 📊 آپدیت‌های لحظه‌ای از وضعیت برنامه‌ها 📂 مانیتورینگ فایل‌های JS برای کشف باگ‌های مخفی ✍️ اشتراک بهترین و جدیدترین Writeupها ✨ کانال ما، همراه شکارچی‌های حرفه‌ای و مشتاق برای رشد و موفقیت در دنیای باگ بانتی. 👣 قدم بردارید و حرفه‌ای‌تر شکار کنید! 📌 لینک عضویت: @infodisclosure

جالبه وقتی گفتم از چنل حمایت کنین بیشتر از الان که گفتم لفت بدین چنل ریزش داشت😂😂

⚠ ادامه فعالیت چنل متوقف میشه و 👆 پست آخر چنل هست، میتونین لفت بدین‌. اما چنل پاک نمیشه.

تکنیک Reverse MX lookup = یکی از تکنیک هایی که برای 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

https://ibb.co/1b1CKb9 جاوااسکریپت در یک نگاه #Javascript

https://beaglesecurity.com/blog/tag/vulnerability/ یک منبع خوب برای آشنایی با حملات مختلف(خلاصه میگه و به هر کدوم که علاقه مند بودین باید بیشتر دربارش بخونین) #resource

اما این آموزش‌ها رو برای وقتی گذاشتم که به 800 نفر برسیم 😉 پس با حمایت‌تون می‌تونیم سریع‌تر به 800 نفر برسیم و آموزش‌ها رو شروع کنیم❤️

چون آموزش CRLF Injection خیلی مورد استقبال قرار نگرفت، آموزش بقیه موارد هم فعلاً متوقف می‌شه.