Just 2 days… and 3 duplicate findings 😅🔥
- Race Condition
- Privilege Escalation (×2)
Still early, still grinding with my team.
@MahmoudEmam809@youseftolba208
Valid is coming 💪🚀
سلسلة كل يوم شرح ثغرة بسيطة:
Day3
ثغرة تعداد المستخدم :
التعداد ان الخادم يرد اذا اليوزر موجود بقاعده البيانات او لا
اختبارها :
١- ابحث عن لوحة تحكم وجرب يوزرات شائعة مثل admin , test , root , toor
٢- ابحث عن تسريب لليوزرات من خلال api
ملاحظة (مواقع الwordpress يتم اعتبارها معلوماتيه)
- تأكد من الثغرات الغير مقبولة
المكافاة من ٥٠ الى ٢٠٠$ او على حسب البرنامج
Weird graphQL IDOR / access control bypass:
In this one, graphQL would check the "tin" (tax identification number), if supplied, against the Bearer token. If the Bearer did not have access to the tin, you would get access denied. Normal stuff there. So my thought was, how could I make the server still lookup the tin value without the access check?
It regularly expected:
\"tin\"
This causes the server, since "tin" is present, to check access control prior to returning data.
What worked was:
\"tin\\\"\"
So adding \\\" after tin bypassed the access control logic (for some reason), meanwhile the graphQl query still ran and sent back the PII for any TIN I sent it.
#bugbounty is just strange sometimes. Some of the battle is finding neat endpoints and places, and some of it is endless tinkering.
Race Condition IDOR, $36,750
Where automation fails is often in the gray areas. In the case of this bug, an IDOR existed by integer "orderId", which would allow viewing and hijacking someone else's order by simple swapping the order number - but ONLY IF the order had not yet completed.
We see here that the order is 10099780. If we increment up by 1 to 10099781, it may have said "not found" (404) or access denied (403), and we keep incrementing upwards to maybe 10099788 (eight orders higher), and suddenly we get data back (200). You tinker around a bit more, come back to that same number, and now it says access denied (403). Hrmm.
So you increment up again, and get another hit, which again turns to access denied in a matter of seconds or minutes. After some pondering, you realize it turns out that once an order is completed, the access control kicks in, but not while the order is still in progress. Well ain't that fun.
From an attackers perspective, what can we do with this? What is the risk? Imagine you could change the shipping address on someones uncompleted order and intercept the product they are about to pay for. Or increasing the quantity of the product they are purchasing. Suddenly you have a warehouse full of goods you didn't pay for. That's not good for the company!
Perhaps automated tooling was used to scan this, but if no other orders were in progress in lower environments, maybe it got missed. Sometimes things just don't get found until they are in production for so many reasons.
If you are gonna do some #hacking, may as well do it on #bugbounty programs and get paid for it instead of wasting time on HTB and random labs.
"Hey random guy, how did you get so good at hammering?"
Random Guy: "I used the hammer every day for 5 years."
How to automate bug bounty tasks:
- Pick a target.
- Use your methodology and write down every action you take.
- Once you are finished, check the list and ask yourself which actions you repeated multiple times.
- Use AI to write mini-scripts to automate those specific actions.
Thank me later.
@Azx7af I mainly focus on private programs. I understand This CVE in public programs are often duplicates. Even if there’s no bounty, I’ll earn points.