Unlocking the Power of Observation: How Experienced Hackers Stand Out in a Sea of Amateurs

1 year ago 67
BOOK THIS SPACE FOR AD
ARTICLE AD

Hackers have a superpower “Observation” but it doesn’t come naturally, a hacker gains it with experience and brainstorming but as automation and third party tools are becoming influential anyone with little computer knowledge is throwing random payloads and running automation and claiming to be “Hacker/Bug bounty hunter”

Unlocking the Power of Observation: How Experienced Hackers Stand Out in a Sea of Amateurs

Hackers need to embrace their superpower in order to become more efficient and meaningful, while doing bug bounty they have to search for weaknesses and also make sure that with their actions the application doesn’t crash.

Superpower

In the interest of time, let’s talk about one feature I saw in the middle of last year.

This functionality gives users the ability to claim a subdomain on the application (website) to create a workspace and work directly on that subdomain. (In simple words, the application allows users to create instances)

I’ve already touched on this, so I suggest you read my previous article. I assume you read this article, so let’s continue.

Application Flow : When a user tries to sign-up, the application doesn’t requires user to verify the email first and after completing the sign-up process successfully the user gets a “login token” and with the help of this “login token” user can login into his/her account without the password

Note: This token is “One Time Token”

Attack Mode : this is the same application the Attack (i) so again I created a new subdomain and on the claim subdomain request I replaced my email with the victim’s email and as I don’t know the password of the victim’s email I added “anything” in the password field.

{
"methodName": "onboard",
"params": {
"some_params": {
"some_name": "anything",
"some_modules": [
1
]
},
"user_params": {
"name": "CanBeAnything",
"email": "hunterzerocipher@gmail.com",
"password": "Anything"
},
"community_params": {
"name": "anything",
"slug": "anything",
"c_id": 715,
"client_time_zone": "Asia/Calcutta"
}
}
}

On the response I got the “login token” and made a browser GET request on the victim’s subdomain with the “login token” and I was logged-in in the victim’s account

https://victim.application.com/admin/login?login_token=xxxxxxxxxxx

Summary : In this example what happened is the application doesn’t actually generate the login token with multiple details of the user, it only used the email to generate the login token and as the login token only contains a pass to login as the user without checking the subdomain or the organization, allowing attacker to create login pass with the victim email.

I have to say this example is a bit funny

As the previous example I was trying to create a subdomain in the application and the url was

https://portal.application.com/register

and while login I noticed that the url is

https://login.application.com/admin/login

So I again tried to create a subdomain “xzcvb” and Intercepted the request in Burp Suite changed the subdomain name to “login” and sent the request and as a surprise I got “200 OK”

Crashed

What’s the Impact? Due to some reason (Well I think it happened because the application’s module which was responsible to create subdomains had over privileges) when a user tries to visit login.application.com or tries to recreate his/her session the application gets confused “where to take the user” making the subdomain not reachable ultimately making the application not reachable.

I hope it gave you a clear idea how efficient bug bounty and penetration testing becomes when you use your superpower rather than relaying on the automation and third party tools.

I hope you’ve learnt something new with this, if yes then please smash the clap button and if you want to discuss similar connect with me on Twitter and LinkedIn :)

Read Entire Article