Api fuzzing For bugbounty.🔍

@Dagen_security

revers shell Generator 🔥

link : https://powershellforhackers.com/tools/revshell/

@Dagen_security

فول هانت یکی از خفن‌ترین سرچ‌انجین‌هاست با اختلاف؛ تمرکزش روی پیدا کردن assetهای جدید و شناسایی CVEهای نسخه‌های آسیب‌پذیره. کافیه فقط اسم دامنه رو بهش بدی. حتماً توی ریکانت ازش استفاده کن 🔥

link : https://fullhunt.io

@Dagen_security

How to start hacking with the right mindset ⚡️

این ریپازیتوری گیت‌هاب تمام دامنه‌های موجود در HackerOne و حتی سورس‌کدهایی که به‌صورت وایت‌باکس باگ‌ باونتی دارن رو لیست می‌کنه. برای اتوماسیون میتونه خیلی مفید باشه و به‌صورت مداوم اپدیته 🔥

link : https://github.com/zricethezav/h1domains

@Dagen_security

Web Cache Deception methodology

برای شروع دو حساب کاربری ایجاد کنید.

وارد حساب اول بشید و Burp Suite را برای گرفتن ترافیک (intercept) روشن کنید.

در بخش HTTP history به مسیر Endpoint حساس حساب کاربری بروید:

GET /setting/view/profile

این درخواست یک پاسخ JSON برمی‌گرداند که حاوی داده‌های حساب شماست.

آدرس را به این شکل تغییر دهید:

GET /setting/view/profile;test.js

اگر در هدر پاسخ مقدار زیر را دیدید:

cf-cache-status: HIT

این یعنی پاسخ کش (Cache) شده و می‌تواند به کاربران دیگه هم نمایش داده شود.

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

دوباره به همان URL برگردید حالا پاسخ کش‌شده حاوی داده‌های قربانی است، شامل اطلاعات حساس مثل ایمیل، اطلاعات پرداخت، و تنظیمات حساب. :)

@Dagen_security

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

link : https://website.informer.com

@Dagen_security

این وبسایت با استفاده از APIهای سرویس Microsoft 365، بر اساس دامنه یا Tenant ID جستجو انجام میده .
کافیه اسم دامین رو بهش بدی، این ابزار توی دیتابیسش می‌گرده و تمام organization name مرتبط با همون Tenant ID را پیدا میکنه و نمایش میده.
ویژگی منحصر‌به‌فردش اینه organization name هایی که شناسایی می‌کنه، توی هیچ منبع عمومی یا لیک‌شده‌ای وجود نداره.😎

link : https://micahvandeusen.com/tools/tenant-domains/

@Dagen_security

وقتی برای 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