📊 Watcher Summary Report

🔹 BUGCROWD: 10 new items
🔹 HACKERONE: 60 new items
🔹 INTIGRITI: 11 new items
🔹 YESWEHACK: 0 new item
🔹 FEDERACY: 0 new item

🔗 Details: Click here

#zerosec #bugbounty #watcher #summary_report


⭐️ @ZeroSec_team

بدون شرح ...
⭐️ @Zerosec_team

go to https://nexovir.ir -> read js files -> login-endpoint (with manipulate path) -> XSS from login page -> find admin email -> use webapp to send email to admin email (Becaus Admin just open Trusted Email) -> use HTML injection (Basic) for create phishing -> steal Cookie -> login admin panel to access /admin path (403 -> 200) -> FUZZ path -> FUZZ parameter -> RCE -> exfiltration  /etc/passwd (POC)

The challenge isn’t over yet go ahead, do this, and solve it.

⭐️ @Zerosec_team

Some tips I wanted to share for this challenge:

1 - Always read the JS files carefully and don’t skip, even if the JS files are obfuscated

2 - Always use your hacker mindset and don’t look for low-hanging fruit

3 - Recon is always your best Friend

4 - Don’t FUZZ blindly

5 - Most of the time, the answer is right in front of you, but you ignore it

6 - “Don’t overlook chaining vulnerabilities for maximum exploitation”🥇

7 - Pay attention to 500,403,… status codes too most hunters miss them

#BugBounty #RedTeam #XSS #RCE #Tip

⭐️ @Zerosec_team

حملهههههه

#Shodan #FreePlan

⭐️ @Zerosec_team

Challenge Time
سلام دوستان یه چالش اکانت تیک اور قشنگ آوردیم
هدف چالش اینه که یه لینک بفرستید به ادمین کلیک کنه و کوکی هاش فرستاده بشه به سایت اتکر
فاز نکنید کل چالش تو همین صفحه هستش

راه حل هاتونو پی وی بفرستید
@arlrouh

https://rouhbakhsh.xyz/index2.php

سطح چالش: سخت

طبق گزارش هایی که بهمون رسیده Bugcrowd شدیدا داره اسکم میکنه
به چالش تحریم Bugcrowd بپیوندید

#تحریم_باگکراد #باگ_بانتی #هکروان #هک #تحریم_باگکراد_مطالبه_ملی

⭐️ @ZeroSec_team

تهدید عجیب مدیرعامل ایرانسل: اگر اینترنت ۷۰ درصد گران نشود، روزی ۳ ساعت قطعی اینترنت خواهیم داشت.

همینطوری برق میره روزی سه ساعت بی اینترنتیم شما ها دیگه از کجا اومدید😡😡

⭐️ @ZeroSec_team

For Developers: How to Prevent Timing Attacks on Login

A common attack used by hackers is a timing attack or username enumeration:
By comparing server response times, they can figure out whether a username exists or not.

🔹 Why Response Time Differs

Invalid username → server responds quickly

Valid username but wrong password → server has to check the password → takes longer

🔹 Defense Strategies

1️⃣ Uniform Response Time

Even if the username doesn’t exist, perform a dummy password check so the response time is consistent.

2️⃣ Uniform Error Message

Always return: Invalid username or password

Don’t reveal whether it’s the username or password that’s wrong.

3️⃣ Rate Limiting / Brute-force Protection

After a few failed attempts, slow down requests (throttling) or block access.

Goal: prevent hackers from guessing passwords with thousands or millions of attempts.

💡 Important: To prevent attackers from bypassing limits (e.g., changing IP or spoofing X-Forwarded-For), developers should:

Apply rate limiting per username and per IP separately

Even if the attacker changes IP, the same username is still limited.

Use randomized throttling

Add a slight random delay on failed attempts so attackers can’t measure response time precisely.

Monitoring & Alerting

Log unusual attempts (many logins on one user or from multiple IPs) and send alerts.

✅ With these measures, even if a hacker tries brute-forcing, the server will block them effectively.

4️⃣ Use MFA

Even if username and password are leaked, the second factor (OTP/TOTP) prevents intrusion.

5️⃣ Monitoring & Alerting

Log suspicious activity and alert admins.

🔹 Example in code:

$stored_hash = get_password_hash_or_dummy($username); 
password_verify($password, $stored_hash);
return "Invalid username or password”;

💡 Even if the username doesn’t exist, the password is checked → response time remains uniform
____________________________

برای برنامه نویس ها :‌

چطور از حملات Timing Attack روی لاگین جلوگیری کنیم؟

حمله ‌ای که هکرها ازش استفاده می‌کنن، timing attack یا username enumeration هست:
یعنی با مقایسه زمان پاسخ سرور، تشخیص می‌دن یوزرنیم درست هست یا نه!

🔹 چرا زمان پاسخ فرق می‌کنه؟

یوزرنیم غلط → سرور سریع جواب می‌ده

یوزرنیم درست ولی پسورد غلط → سرور باید پسورد رو چک کنه → زمان بیشتری می ‌بره

🔹 راه‌ های دفاع:

1️⃣ زمان پاسخ یکنواخت

حتی اگه یوزرنیم وجود نداره، یک عملیات ساختگی روی پسورد انجام بده تا زمان پاسخ ثابت بمونه.

2️⃣ پیام خطای یکنواخت

همیشه بگو: Invalid username or password

نه «یوزرنیم اشتباهه» و نه «پسورد اشتباهه»

3️⃣ Rate limiting / Brute-force protection

بعد از چند تلاش ناموفق، سرور باید یا درخواست‌ها رو کند کنه (throttling) یا کل دسترسی رو بلاک کنه.

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

💡 اما توجه: برای اینکه هکر نتونه این محدودیت‌ها رو دور بزنه (مثلاً با تغییر IP یا اسپوف کردن X-Forwarded-For)، برنامه ‌نویس ‌ها باید:

Rate limit روی یوزرنیم و IP جداگانه اعمال کنن

حتی اگه هکر IP عوض کنه، بعد از چند تلاش روی همان یوزرنیم محدود می‌شه.

Throttling تصادفی

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

Monitoring و Alerting

تلاش‌های غی رمعمول (تعداد زیاد لاگین روی یک یوزر یا از چند IP مختلف) رو لاگ کن و هشدار بده.

✅ با این روش‌ها، حتی اگر هکر بخواد brute-force کنه، سرور جلوی اون رو می‌گیره و حمله بی‌اثر می‌شه.

4️⃣ استفاده از MFA

حتی اگه یوزرنیم و پسورد لو رفت، مرحله دوم (OTP یا TOTP) جلوی نفوذ رو می ‌گیره

5️⃣ Monitoring و Alerting

تلاش‌های مشکوک رو لاگ کن و هشدار بده

🔹 مثال عملی در کد:

$stored_hash = get_password_hash_or_dummy($username); 
password_verify($password, $stored_hash);
return "Invalid username or password”;

‍‍‍‍‍
💡 حتی اگه یوزرنیم وجود نداشته باشه، پسورد چک می‌شه → زمان پاسخ یکنواخت می‌ مونه

#DNS_Bruteforce #Authentication

⭐️ @ZeroSec_team

🔥 Common Mistakes Developers Make 🔥

1️⃣ Rate Limit Only on IP
Developers often limit only the IP, not the username.

💡 How to bypass: Change your IP (Tor) or use X-Forwarded-For spoofing to bypass the restriction.

2️⃣ Different Response Times
Wrong username → fast response
Correct username but wrong password → slower response

💡 How to use: Analyze response times to find valid usernames (timing attack).

3️⃣ Different Error Messages
For example: “Username not found” or “Wrong password”

💡 How to use: Perform username enumeration by observing error messages.

4️⃣ Fixed Throttling
Fixed delay after failed attempts

💡 How to bypass: Makes brute-force or timing attacks easier to calculate.

5️⃣ Rate Limit in Temporary Cache
After server restart, limits are reset

💡 How to use: Can attempt unlimited login tries without restriction.

6️⃣ No Monitoring
Suspicious login attempts are not logged

💡 How to use: Can brute-force or enumerate using multiple IPs or usernames without triggering alerts.

💡 Summary for Hackers:

Check response times

Analyze error messages

Bypass limits by changing IP or username

________________________________

🔥 اشتباهات رایج برنامه ‌نویس‌ها در پیاده سازی صفحه احراز هویت🔥

1️⃣ Rate Limit فقط روی IP

برنامه ‌نویس‌ها فقط IP رو محدود می‌کنن، نه username.

💡 چطور دور بزنیم: با تغییر (Tor) IP یا X-Forwarded-For spoofing، محدودیت رو دور میزنیم.

2️⃣ تایم پاسخ متفاوت

یوزرنیم غلط → سریع جواب

یوزرنیم درست ولی پسورد غلط → طولانی ‌تر

💡 چطور استفاده کنیم: از response time می‌تونیم valid username پیدا کنیم (timing attack).

3️⃣ پیام خطای متفاوت

مثلا میگه: “Username not found” یا “Wrong password”

💡 چطور استفاده کنیم: username enumeration با مشاهده پیام خطا.

4️⃣ Throttling ثابت

تاخیر ثابت بعد از تلاش ناموفق

💡 چطور دور بزنیم: حمله timing attack یا محاسبه سرعت brute-force راحت‌تر میشه.

5️⃣ Rate limit در کش موقت

بعد از ریستارت سرور محدودیت‌ها پاک میشن

💡 چطور استفاده کنیم: میشه بدون محدودیت تعداد زیادی تلاش کرد.

6️⃣ عدم مانیتورینگ

تلاش‌های مشکوک لاگ نمیشن

💡 چطور استفاده کنیم: میشه با چند IP یا چند یوزر، brute-force یا enumeration انجام داد بدون هشدار.

💡 جمع‌بندی برای هکرها:

به response time نگاه کنید

پیام خطاها رو تحلیل کنید

محدودیت‌ها رو با تغییر IP یا username دور بزنید

#Developer_Mistakes #IP #BruteForce #Bypass

⭐️ @ZeroSec_team

#exploit
#Fuzzing
#AppSec
A Fuzzy Escape - A tale of vulnerability research on hypervisors (CVE-2025-30712)
https://bughunters.google.com/blog/5800341475819520/a-fuzzy-escape-a-tale-of-vulnerability-research-on-hypervisors

// The research uncovered critical VM escape vulnerabilities in QEMU and VirtualBox through static analysis and fuzzing, including a buffer overflow and an integer overflow enabling arbitrary code execution

⭐️ @Zerosec_team

Cache Deception + CSPT: Turning Non Impactful Findings into Account Takeover

https://zere.es/posts/cache-deception-cspt-account-takeover/

⭐️ @Zerosec_team

New challenge coming soon… 🔥

🔥 How to Monitor URLs in Bug Bounty?🔥


اینجا یه متودولوژی قدم‌ به ‌قدم برای مانیتور کردن URL ها 👇

1. URL Discovery (if we have new Asset) :

New Asset -> Passive Crawler + Passive Crawler -> Vulnerability Discovery Cycle


2. Statu Code Diff :

Check All Urls -> Change Status Codes -> Vulnerability Discovery Cycle
-> Let’s Hunt

403 -> 200

3. Parameter Diff:

Send req to urls -> Check for New Parameters -> Vulnerability Discovery Cycle (Like : BlindXSS , XSS , SSRF , OPENR ,…)


4. Response Body / Length Diff (Recommanded for JS Files)

Body Hash -> Change -> Looking for New Endpoints , Dangerous Sinks and Sources and Magic Parameters -> Let’s Hunt


5. Header Monitoring

Hash Headers -> Check All Changes in Headers -> Looking for favorite Headers (some headers Like : Access-Control-Allow-Origin)


برای مانیتور کردن URL ها رویکرد های زیادی وجود داره ولی برای شروع اینا میتونه براتون خیلی خوب باشه

#BugBounty #JS #Monitoring #Watcher

⭐️ @Zerosec_team

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

برا خودم باور نکردنی بود از ارجاعی که برا استوری من تو این پست بی نظیر ذکر شد ۳ سال تقریبا میگذره
و جالبه بدونید هنوز دسترسی پرسیسته کاملا 😁❤️ دلی کار کنید تا با دل خوش دسترسی هاتون حفظ بشه

این مال خیلی وقت پیش
دامنه اصلی یکی از کمپانی ها بود که اسمشو اوردم تو دوتا نظر قبلیم
دوتا مس اساینمت رو کوکی‌زدم که
AudienceType-> Internal
ocAuthenticate -> 1
یک صفحه خاص تغییر رفتار داد یک پارامتر ولی براساس سشن خودم اضافه شد اسم پارامتر رو یادم نمیاد ولی فرض کن:
intId : 54321
قبل‌مس اساینمت صفحه ۴۰۱ میداد بعدش شد ۴۰۳
اومدم این ای دی رو از یک شروع کردم بالا بردن تا هرجا جا داشت تو عکس هست

سر یکیش ۲۰۰ گرفتم
و …

https://soltanali0.medium.com/jwt-bugs-and-the-dot-that-changed-everything-%EF%B8%8F-50a0bc31fd66

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

یه پیلود ساده Open Redirect (فکر کنم پابلیک هم باشه):🚨

https://example.com\@marketing.victim.com/test

وقتی میره سمت بک‌اند، با یه کتابخونه URL پارس میشه.
پارسر hostname رو marketing.victim.com درنظر می‌گیره و چون این هاست جز وایت لیست ها قرار داره، کل ورودی رو که پیلود ما هستش رو تو هدر Location میذاره و با استاتوس کدی مثل 302 ریدایرکت می‌کنه.

اما وقتی مرورگر جوابو می‌گیره، اون \ رو تبدیل به / می‌کنه یعنی url normalization انجام میده و در نهایت هاست واقعی رو example.com می‌بینه 🤯

اگر اکستنشن ++logger رو توی burp suite استفاده میکنید فیلترهای زیر رو اضافه کنید و رنگ هر فیلتر رو تغییر بدین

https://github.com/bnematzadeh/LoggerPlusPlus-API-Filters/

⭐️ @Zerosec_team

⁉️ چرا نباید صرفاً به OWASP Top 10 در #BugBounty تکیه کرد؟

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

برای یک #BugHunter حرفه‌ ای، دلایل اصلی ناکافی بودن تکیه صرف به OWASP عبارت ‌اند از:

1️⃣ دامنه محدود (Scope Limitation):

OWASP Top 10 تنها بخشی از طیف حملات را پوشش می‌دهد.
آسیب ‌پذیری ‌های جدی مثل Business Logic Flaws، Race Conditions، Subdomain Takeovers یا Cloud Misconfigurations خارج از این فهرست هستند.


2️⃣ به‌روز نبودن (Update Frequency):

لیست OWASP هر چند سال یکبار به‌روزرسانی می‌شود، اما دنیای آسیب ‌پذیری ‌ها به ‌صورت روزانه تغییر می‌کند. بسیاری از اکسپلویت ‌های مدرن (مانند حملات به microservices یا API‌ها) در بازه انتشار OWASP ظاهر نمی‌شوند.


3️⃣ ریسک یکسان ‌سازی (Common Knowledge Risk):

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


4️⃣ عدم پوشش معماری‌ های خاص (Architecture-Specific Gaps):

اپلیکیشن‌ های مدرن با تکنولوژی‌ هایی مثل GraphQL، Serverless یا Containerization آسیب‌پذیری ‌هایی دارند که OWASP به‌طور مستقیم به آن‌ها نمی پردازد.


❗️ نتیجه گیری:
OWASP نقطه‌ی شروع ارزشمندی برای ایجاد ذهنیت امنیتی است، اما یک باگ هانترهای سطح بالا باید:

آسیب‌ پذیری ‌های خارج از OWASP را مطالعه و تمرین کند.

روی درک معماری سیستم و منطق تجاری (Business Logic) تمرکز کند.

به‌روزترین تحقیقات امنیتی و اکسپلویت ‌ها را دنبال کند.


⭐️ @Zerosec_team