Accidentally typo to bypass administration access

A new post from me to kill some times.

This was from an old invited private program in one of the bugbounty platform. This program offers $15,000 in total. There were several targets given, but most of them were limited in term of functionalities and forms.

One of the application in scope attracted me as it responded differently if viewed in a different browser's platform. Which means, you will only allowed to access their mobile site if the application detected your user agent is coming from Mobile. This application just consist of few functionalities such as

• query for available *item*
• view for available schedule
• information of the certain *item*
• no login

Based on the above functionalities, this seems like a common website that provides with a general information of their product/items. I spent few days looking on their Desktop Website and found few XSS. Looking at the source page of the website, I've noticed there's a script that contain a hyperlink to a mobile site. It looks something like below:

 <script type="text/javascript">
   var attr = "href";
   var value = "/mobileapps";
   elem.setAttribute(attr, value);
</script>

However, I was not able to access it directly using Desktop browser. I tried to change my user agent into Android's string, it worked!

Now I'm in their mobile site. Found another few XSS. Good. Considering the current findings, I'm probably will be rewarded up to $2000 in total. Good enough. But then, something is bothering me where from my Burp's request, there's a 302 redirect response whenever the Burp's Spider tried to access /admin path. Weird. I tried to check if there's any JS files that I can use to bypass this thing as what I did like in my previous blogpost.

No success. sadpanda.

But then, during the testing I've mistakenly typo'ed the /admin into /Admin (This happen regularly since using Macbook. The keyboard quite small for my finger's size)
To the surprise, due to that typo, I was able to access into the administration page. What a magic. It seems there was a weak configuration at their backend which only restrict access for /admin BUT not if the word contain at least one capital letter. /Admin, /aDmin/, /ADMIN all of these words can be used to bypass the check.

Now I'm in administration page. There were lots of functionalities inside and ALL of them were vulnerable. Reflected and Stored XSS, SQLi, CSRF, and etc. Submitted all of them. Out of $15000, 70% was mine :)

Lessons:

1.  Do not forget to test in mobile environment 
2.  Do not forget to test target's mobile site
3.  Do not give up if the application looks really simple, there's probably a hidden administration page in it
4.  Look on the application's response. If weird, try to bypass.

Till next time.
Cheers.

From JS to another JS files lead to authentication bypass

This was found in a private bug bounty. The scope is limited to a few of features that available to the public. Based on the previous reported issues (5 bugs submitted by others so far when I was initially invited), seems it is hard to find a new issue. It also mentioned in the bounty details that

If you manage to get into Administration page, report immediately and do not pivot or further testing in /admin

However, there is an administration page which was restricted to unauthenticated and unauthorised users. Browsing to /login or /admin will redirect us to https://bountysite.com/admin/dashboard?redirect=/

Bruteforcing the login page probably an option but I'm not a fan of bruteforcing a login page. Looking at the source page, nothing much useful. I started looking on the application's structure. It seems the JS files were located in few directories such as /lib, /js, /application and etc.
Interesting.

I run the BurpSuite and run the Intruder to identify any accessible JS files in these directories. Set the path of attacking/fuzzing points at https://bountysite.com/admin/dashboard/js/*attack*.js 
Yep, make sure you didn't forget the .js so we will receive the 200 response if the file is accessible. Interesting, again. Because one of the accessible JS files was /login.js

Accessing the JS file https://bountysite.com/admin/dashboard/js/login.js redirect me to the Administration page :) But, I have no permission to view it. Only partial of the interface can be seen.

SadPanda.jpg

But I didn't stop at here. It seems weird why the page is loaded as an HTML while I browsed to a .js file? After playing around, I noticed that the actual reason that allowed me to get into this administration page was because the *login* word. Yes, as long the request after /dashboard/ contains a word with the string of *login* (exception to 'login', this will only redirect me back to the login page.), will allow us to get into this Administrator's interface, but without a right authorisation.

Further tests were performed from this limited Administration's interface. I looked into the source page and again, trying to understand the structures. From this interface, there are some other JS files that helps me to understand how an administrator can perform an action. Some of the action require a valid token. I tried to perform the action using the leaked token in one of the JS file, not working. The request will be redirect back to the login page. Looked on another JS file, I found there's another path that actually exist which served some content. It was /dashboard/controllers/*.php

Again, I run the Intruder to check if there's any other path which can be accessed from here. From the second Intruder attacks, I found few other paths that were exist but have no authorisation to access it. This was based on the 500 or 200 HTTP response.

SweetPanda.jpg

Back on the structures that I learnt in the first phase of recon, I found that these path were defined by /controllers and being used thru /dashboard/*here*/
However, another bump, directly accessing the path will redirect me to the login page. Seems the session checking quite tough over here. I was about to give up at this point and also sleepy too, but I want to try a last attempt. What if I used the same method to access the Administrative page to access and perform these actions?
Interesting, climax. :) I'm able to do so.

By browsing to the /dashboard/photography/loginx redirected me to the Admin Photography page with the full functionality that I can use.

Photography functions.

From here, I'm able to perform and access all the available actions and paths in  /dashboard/* which was full with other vulnerabilities such as SQLi, XSS, File Upload, Open Redirect and etc. However, I didn't attempt more on it as all of these issues were out of scope as what had been defined by the program to immediately report to them if the Administration's authentication was found broken. Also, additional notes that I noticed from the debug error enabled on the Administration's page, what made I'm able to access these Administration pages was because of the misconfiguration of the application at /dashboard/controllers/* lines where whenever a *login* found in the request, the application should redirect to the main login page, however, it was not working as it was intent.

It was a fun day indeed :)
I was rewarded with the Max amount of this program.

Chio.

Blind SQL Injection in er..I'm not sure what's the DBMS is.

A short blogpost from me.
Recently participated in a private bounty program and found an SQL Injection issue on one of the available parameter.

Injection looks like follow:

id=11) and (1=1

Normal eh? But SQLmap and few test cases from me could not determine the DBMS it used. High chance it is MSSQL, MS Access or Jet Database. This is from the observation seen on the patterns that can be seen. I've also asked people around to conclude this. Manage to provide a simple POC such as

id=11) and 1=1 and (1=1 

id=11) and 12 and (1=1

to show the existense of TRUE FALSE condition. But still, to convince the program owner, at least, we need to show it is possible to extract table_name or column_name. After a day of trying, I've figured out how to make the POC. How silly, it is so simple!

 id=11) and (<column_name>=<column_name>

So, if the column_name is exist, it'll be TRUE while if not exist, it'll be FALSE. How to automate it?
All we need to do is run our Burpsuite, send the vulnerable parameter to Intruder. Use Battering Ram attack type, and choose our own wordlist contain the list of column_name. I used the one in SQLmap common_columns.txt

Result as follow:

Easy!

Thanks