Blog

Continuing with sharing my further experience around Ethical Hacking learning journey.

Was occupied with quite a few things on personal front recently hence couldn’t go with the speed I wanted but could juice out some productivity in the form of some reading and some practical exercises.

Read few chapters of The Web Application Hacker’s Handbook and the best part, read lots of publicly disclosed reports by HackerOne, Publicly Disclosed and Bugcrowd.

On the practical side, tried RCE on few Bugcrowd program sites though couldn’t succeed yet 😐 Also, the learning and discussions journey continued with awesome Santhosh Tuppad. So recently he gave me around ten exercises to crack. Let’s see how I approached them one by one.

Exercise#1

In the first exercise, I was supposed to crack username and password of a dummy login page. The hint was left in the source code that Base64 encoded value of username is password. I guess the agenda was to get the learner familiar with the encoding thing and to check whether he/she is checking the source code for hints. It took me a minute or so to use an online encoder to get the password expected value. However, due to some technical glitch in the dummy exercise application, it was not letting me get through(the error was genuine so it looked like expected working where access was denied).

Hence, even though my answer was right, I felt that it is not and kept on searching and trying new things. This technical glitch pushed me a for days where I kept on trying different things to crack through. Below are few things I tried, I know some of them are silly but I tried them anyway.

1. Admin as username and password as many sites actually have such password for admin panels
2. UserName as username and password, pwd as password (Hint from source code)
3. admin / admin123 as username and password (again from past experience and usual username-password patterns)
4. santhoshtuppad as username and password
5. santhoshtuppad as username and c2FudGhvc2h0dXBwYWQ= as password (The Correct answer, which I got to know only after trying everything)
6. comment as password (Hint from source code)
7. value of comment encoded in Base 64 as password (Hint from source code)
8. empty username, password
9. single space as username and password
10. Enabled token ID field on UI and tried SQL injection, 1=1′, 1=1–, 2=2–, and others (Tried SQL injection on CSRF token field by enabling it
11. Tried SQL Injection on username and password
12. Used tamper data plugin to play with parameters passed
13. Tampered cookie values
14. Added debug points using developer tool trying to understand the flow through script
15. Tried changing the method TYPE to GET from POST with same parameters and request data and executed same
16. Went through integrated scripts as well
17. Tried for context variations, /one/admin
18. Looked for XML-RPC
19. Knowing MySQL, tried few queries on mysql / information_schema, users table, etc. (as part of SQL injection)
20. Tried /exercise/one/admin as well with several credentials
21. Tampering the POST request

Exercise#2

The goal was to try dummy username and password in all the forms one by one and finding out the best error message and also explaining why other error messages are not recommended.

Here are my findings:

Messages Observed-

1. The password you entered for admin is incorrect.
2. Invalid username / password
3. Wrong password.
4. The username doesn’t exist

I put my money on would be on message#2.

While 3 and 4 clearly tell me if particular username I am using is registered with the system or not, which narrows down my target zone. OR

OR

It might also violate privacy as it tells me if a particular user is present/registered on system or not.

Message#1 is basically an incorrect message as it always throws standard message even if a user is not registered. So this, in turn, might confuse the registered user.

Exercise#3

Here, the goal was to find out a way to employ brute-force attack wherein you should be able to identify a way to bypass the “login lockout” policy and employ brute-force activity successfully.

My findings:

A cookie named MAX_LOGIN_ATTEMPTS was the key here, whose value starts at 10 and count goes down with every false login attempt.

With every hit, I deleted the cookie from the net panel so I always have 9 attempts remaining. I can go on with this forever.

Exercise#4

The goal here was to inspect the cookie values and see if there is something that shouldn’t exist as part of sensitive data.

My findings:

1. First is keeping the ‘MAX_LOGIN_ATTEMPTS’ cookie value at client side rather than keeping it at server side bound to Username/IP.
2. Second thing is cookie expiry which is set for 30 days, though I am not sure how this will harm especially being just a count of invalid logins.

Exercise#5

The goal here was to find if there exists any insecure way of handling authentication during login journey.

My findings: Could not complete this exercise due to a technical glitch. However, noticed that the insecure_login count is not getting incremented here even after multiple invalid login attempts, which gives attacker privilege to try as many times as he/she wants.

Could not complete this exercise due to a technical glitch. However, noticed that the insecure_login count is not getting incremented here even after multiple invalid login attempts, which gives attacker privilege to try as many times as he/she wants.

Exercise#6

The goal here was to find out the issues in the security answer in the web page. And why do you think they are issues relating to the security?

My findings:

First thing is there is no Captcha. Denial of Service attack is possible.

2nd and most important thing is, answer to the security question might be too easy to crack. In today’s social world, finding anyone’s birth place is no big deal and of the ones you know personally, it would be a cake walk.

Exercise#12

The goal here was to browse robots.txt file and report any sensitive URL’smentioned in the txt file.

My findings:

The robots.txt here was telling me the URL of the admin panel, Reports tab and User’s tab too. Which is helping me one step in my attack revealing admin console context.

Exercise#13

The goal was to find out a security issue in register form and also mention details about “why?” it’s a security issue.

My findings:

1. No password complexity policy, so any simple password is accepted.
2. No captcha/re-captcha implementation to identify if the user is actual user or bot. Hence allows one to launch Denial of Service attack with endless sign ups.

Exercise#18

The goal here was to inspect the requests sent after submitting the phone number and report if anything looks suspicious.

My findings:

Verification token is returned in next-linked get call (once I hit submit) in plain text(no encryption), allowing me to put someone else’s mobile number and still access the verification token sent via response and authenticate myself as the legitimate user.

______________________________________

That’s it for now. Will share Santhosh’s view on my submitted report or best will ask him to leave comments here.

Will soon write about the latest learnings and cracked assignments too. Will love to hear from you all if you see any different possible approach for solving above assignments or anything else I should be learning in this journey. Thanks.