Friday, December 9, 2016

Bug Bounty : Account Takeover due to a Misconfiguration

First of all, I would like to thanks Bugcrowd's analyst especially beemo_bugcrowd for patiently updating the issue during the validation process.

Fiat Chrysler Automobiles announced their public bug bounty program through Bugcrowd in July 2016. More details can see it here:
As always, I will try to poke around to see how many of the reports are currently being handled by the Bugcrowd for this program as if there are too many crowd, usually I will opt out from it. And the result, yes, there are lot of them especially XSS and CSRF issues. That was the reason these two issues immediately excluded to allow analyst team to filter out them.

I'm targeting Mopowerconnect.

Due to that, I try to look on the other angle and I noticed something which is weird in my view which is the way account was created in Mopowerconnect (was in scope but now excluded). Why? Please refer the figure below:

Authentication process

*this is just based on my observation and own hypothesis during the testing.

To detail the figure above:
  1. When a user creates an account at Mopowerconnect, the request will be sent to Chrysler to generate the authorisation and then at the same time will create another independent account which only be used by Sharepoint.
  2. Means, if you create User1 at Mopowerconnect, Chrysler will processing it and provide you with the authorisation for Mopowerconnect as User1, and at the same time it will create another account for you which is to be used in Sharepoint, assume as UserS1.
How do I know there's a Sharepoint at the backend? This is because there's a misconfiguration which allow an attacker to directly access that framework through URL such as /_catalogs/masterpage/etc/etc . I first submit the misconfiguration issue, it was a dupe. Then I went to look around this Sharepoint pages to understand why it exist. There I noticed that, I'm browsing the Sharepoint pages using UserS1 account, not User1. 

Sharepoint UI

I went back to check on my Burp HTTP history to look on all of the responses. Then I found the request and the parameter that supply my another account, UserS1. It was weird to see there are two types of ID on the request.

Request made at Chrysler

 Then I created another testing account to double verify my hypothesis. And it is proven. At this point, I still can't think what's the best scenario I can do. Then, the idea came in. What if I try to reverse the process? Reset the password :)

The request when resetting the password looks similar. Thru Mopowerconnect UI you request to reset the password, then Chrysler will process it and send the information to the Sharepoint to be updated. Interesting.

Again, I reset the password but this time I've modified one of the value before Chrysler send it to the Sharepoint which is PRF_UID. I changed it into my second account and voila! The account was compromised :)

Combining with the issues due to the misconfigured access to the Sharepoint, I'm able to enumerate list of PRF_UID belongs to another users including the admin. And yes, I can takeover the admin's account as well.

Submitted to Bugcrowd, and it is not smooth as I assume because the request was actually being made at Chrysler domain which is out of scope. I knew that but since the issue is considered as Critical, I kept on insist them to forward the report to the client and let FCA themselves decide on this. Two different analysts reviewed the report and marked as Out of Scope. I was at the point to give up until I made a decision to email the issue to the FCA team myself. I used the Bugcrowd's support medium to deliver the message to the FCA team and also did ping another technical team from Bugcrowd to re-review it.

A week later, 

FCA team replied

 At a month later, the issue was fixed!

Sunday, April 24, 2016

Drag Drop XSS in Google ;)


It was started with a tweet from Dr. Mario here

Trying to understand the issue, I read on the comments and there's someone mentioned it is possible due to different format copied from OpenOffice such that. And Dr. Mario share his research on this and it is really interesting.

Then, end of last year, noticed there's an XSS discovered by Harry in Google Docs using the drag drop technique. And due to improper validation HTML code read by Google Docs, the XSS can be executed 

I tried to look around Google Docs. Harry's submission did resolved, however, there's a module in Google Docs/Sheets/Drawing/Presentation where it allow a user to create a drawing. This module however does not fix yet.

Create a simple HTML file with our XSS payload, drag and drop into the drawing module, and the XSS is there :)

What make it interesting is that, I did take a look on the response given by the Google whenever a valid image or other different payload used. There were differ!

The drawing module was actually only looking for a valid image where it can come from user's computer or external source. If the source contain a valid image, the image then will be uploaded and properly embedded. If the image is broken, then it is broken. This is where the XSS payload below take in place.
<img src=nonvalid.jpg onerror=alert(0)>

This is because, the payload will execute if the source is broken (error). I tried using another payload such as onload,onmouseover etc, the XSS would not working! So here's a challenge. How we are going to make sure the image is loaded on victim's side, but once the victim drag into Google Docs, the image then will broken? Simple thought I used the valid image that exist in most of Windows users C:\Users\Public\Pictures\Sample Pictures :)

 However! This submission was submitted by another researcher and this became a duplicate..but..

It was not in Google Images :)


Saturday, February 27, 2016

A Quite Rare MSSQL Injection


Going to share a vulnerability that was discovered last year (for bounty program) that for me, quite a rare one and it was the first that I had found since my involvement in pentesting world.

The website was using Microsoft SQL Server and one of the parameter was vulnerable to Blind SQL Injection attack. How did I know? Obviously by triggering the TRUE/FALSE condition.

http://bounty/yadayada.asp?id=8888'+AND+'1'+LIKE+'1 --> page will be loaded normally.
http://bounty/yadayada.asp?id=8888'+AND+'2'+LIKE+'1 --> page will be blank. 

Nothing fancy here. Just a normal/common testing to check on the vulnerability. The problem came after that where:

  1. It is only shows the SQL Injection behaviour in Blind Attack
  2. Scanner/SQLMap was not working
  3. Seems it was using Stored Procedure method (I not sure, I'm noob here)
Few ways tried but none were successful in order for me to provide a working POC to the program. Further analysis I noticed that, the application was actually only able to response integer value with the user's privilege in used.

Had no idea on that until found a post by v1d0q in

The last query shown was new to me on that time, but surprisingly it was working!
http://bounty/yadayada.asp?id=8888'+AND+(@@TEXTSIZE>@@LANGID)+AND+'1'+LIKE+'1 --> page will be loaded normally.
http://bounty/yadayada.asp?id=8888'+AND+(@@LANGID>@@TEXTSIZE)+'1'+LIKE+'1 --> page will be 
Further read I found that what I was actually trying to query is an existing Transact-SQL inside a MSSQL where its return types is either integer or smallint. And usually, these return types already have their own value.

Such as an example:
@@LANGID usually will be 0 for default (English language)
@@TEXTSIZE can be bigger than 1000

Didn't stop at there, I tried using another Transact-SQL to ensure my result is not a false-positive. And most of the query did the positive job :)
Submitting this limited POC to the program's owner, luckily they view and confirm the issue at their backend as well. Rewarded and satisfied!

Here are examples performed on a testing server.

Disclaimer: I still don't know the exact explanation behind this issue. Need to locate some times and do some research in future :)


Friday, January 8, 2016

HQL Injection on Web Application Running Oracle Database


Recent pentest encountered me with an application that it seems at first glance to vulnerable to SQL Injection as the common test usually I tested shows some firm behavior.

https://site.yappare/index.jsp?id=1' error
https://site.yappare/index.jsp?id=1'' no error / normal page
I believe this should be an Oracle SQL Injection after few tests. However, no result! SQLMap shows that this can be exploited via Time-Based but also no success at the end. During the fuzzing, an error message triggered as shown:

 Googling the error message pointing me to result as shown:

So, my initial understanding is slightly wrong. I should focus on Hibernate. Did some reading and looking for any good references for Hibernate Injection. These links really help me.

After understand a little bit on how to do the injection. Did it via Blind technique as described by Paulsec, and voila! able to dump the current Hibernate version.

https://site.yappare/index.jsp?id=1') and substr(org.hibernate.cfg.Environment.VERSION,0,1)=’n' and ('1'='1
where n is actually numbers/characters that we are querying for.

Hibernate version 3.0.2

This is not enough to demonstrate the impact. Tried to read about hibernate/orm structure it seems they are using prepared statement query. I'm not able to get any clue how to query the database information. It'll be harder to me. Luckily Mikhail Egorov and Sergey Soldatov recent presentation helps me!

It is possible to query a standard injection via DBMS_XMLGEN.getxml(‘SQL’) for Oracle dbms.
and Voilaa!! 
https://site.yappare/index.jsp?id=1') and NVL(TO_CHAR(DBMS_XMLGEN.getxml('Boolean Blind SQL Injection') and ('1'='1




Tuesday, January 5, 2016

Referrer Leakage from HTTPS to HTTPS

From my recent bounty program participation, I failed to find any awesome bug for the whole bounty period. Requiring me to have an iOS9 to perform the full application test also one of the disadvantage as I don't own any Apple product :(

Then, I tried to look for any low hanging fruits on the application. Gotcha! HTTP Referrer Leakage!

When the password reset token provided to the user - after they reset - usually it'll come in a Hyperlink format where there are two ways for the user to use it. Either directly click on it or safely copy and pasted it in the browser.

I choose the second option in order to demonstrate the reset token is leaked to another external URL. And as can see in the figure below, the reset token actually being sent to the website.

Submitted this issue to the program's owner and the analyst responded that this is an issue that in 'Won't Fix' category. The first reason I obtained was it is because the referrer leaked from HTTPS to another HTTPS.
This is what actually hit something on my mind. I never thought about this before. Is the HTTP Referrer will not be logged by the external URL if both are using HTTPS?
With a help from my friend, we tried to simulate the situation. There are two cases. One from HTTPS to HTTP, the second one from HTTPS to HTTPS.

Doing some research  and found that, it is NOT!

Test Cases
HTTPS to HTTP will not leak the referrer

HTTPS to HTTPS will leak the referrer

By summary:

  • HTTP Referrer will not be leaked to another URL if it is transmitted from HTTPS to HTTP. 
  • HTTP Referrer will  be leaked to another URL if it is transmitted from HTTPS to HTTPS
So I get back to the bounty program to ask for review the submission again. Another staff replied with a better explanation why they consider this as a 'Won't Fix' issue. The reason are any of these:
(1) the impact is too low to qualify for a reward 
(2) a prerequisite to exploit the issue is heavy social engineering 
(3) a prerequisite to exploit the issue is being a man-in-the-middle or having theoretical access to a separate restricted resource
 So I believe the 1st reason is the suitable for this situation as the reset token in this case only one-time usable. The situation for an account to get reset via this issue is really rare by looking on the likelihood of it to happen. Furthermore, MiTM attack would not help in this case as the request is transmitted over SSL.

Nevertheless, no harm to submit the issue as they're are certain program that accepting this issue as a minor flaw and got rewarded.