Wednesday, 4 January 2017

Account Compromise though brute forcing FB disavowed link - Multiple Subdomains


Another bug in Facebook. This time on multiple subdomains of FB are found to be vulnerable to brute forcing.

Facebook is not limiting the attempts made to access disavowed page, resulting account take over by brute force.

Vulnerability Type : Missing rate limiting or anti automation measures
Vulnerable Service : Facebook Disavow
Vulnerable URL : https://www.facebook.com/hacked/disavow?u=100007881843952&n=JIjLVAuY

Vulnerable Domains : All the following domains are found to be vulnerable with the same flaw.

  www.facebook.com
  www.beta.facebook.com
  m.facebook.com
  m.beta.facebook.com
  iphone.facebook.com
  developers.facebook.com
  lookaside.facebook.com

Attack Scenario :

Assume victim has forgot his/her password and used the forgot password feature to reset his/her account password. Now facebook will send a password reset confirmation mail, which contains a link for incase if the password was actually reset by any attacker. Users can use this link to gain access to the account which was believed to be already compromised by an attacker.

However this link is not having any rate limiting, which makes it possible for an attacker to brute force the victims disavowed feature, resulting to accoount compromise again.

steps to reproduce:
1. reset any facebook user account and facebook will send a mail to the users account which contains a link just like below.

https://www.facebook.com/hacked/disavow?u=100007881843952&n=JIjLVAuY&l=en_US&ext=1462982490&hash=AS8kzJqt8UJNKrgI

2. Now try and brute force the parameter " n " to gain access to the victim's account. Note that params ext, hash are not getting validated. You can ignore them or remove them from the brute force requests.

ex: https://www.facebook.com/hacked/disavow?u=100007881843952&n=JIjLVAuY

3. Once successfull brute force, application will redirect to a page where it will ask to secure the account by one of the available method.
ex: enter correct DOB or an photo ID. These information can be acquired by other measns such as accessing victim's profile before started attacking (assuming most people dont keep DOB private).

or

Any Photo ID will be accepted if it is not already set.

4. Once you complete the above step, victim's accoount will be successfully taken over by Attacker.

Impact :
Total FB account can be taken over. Or by successfull initiation of disavow process will hide the FB account from active FB accounts till the securing process is completed, there by causing a temporary blcoking.

Video POC :

However, the possibility of brute forcing is very less as the 'n' value takes alphabets with both upper and lower cases, which means the number of possible combinations is a bit high. But with a proper computational resources and time, it is possible to break the same.

Wednesday, 4 May 2016

Instagram - Account Compromise through Password brute forcing

Instagram application is not validating the number of requests made to login into user account, which made it possible to brute force the password of any Instagram user Account.

Issue reported to Facebook through their whitehat program, but unfortunately I am not the first one to do so. So the report was made duplicate and the issue is found to be fixed in few hours.

While brute-forcing, the application throughs an error in the response body, but sets an authenticated session cookie. So, once we refresh, the browser uses the newly set cookie and establishes logged in browsing session. The following is a video demonstrating the same (post brute force action, not the actual brute force).


Monday, 18 April 2016

Cross Site Scripting and URL redirection ...

Hi Guys,

Almost 2 years back I found a cross site scripting and a Dom based Open Url redirection bugs on a certain web site. Since the issues are still not patched, even after 2 years, I have decided to write a blog on them.

Cross Site Scripting:
As per owasp, "Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it."

While testing xxxxx.com, I ended up working on the support page pointing to xxxx.yyyy.com . After playing around the site, I found that it is vulnerable to the reflected cross site scripting on the following url.

http://xxxxx.yyyy.com/customer/portal/topics/266877-xxxxx-extend-for-ios

The payload used is a simple   <style/onload=alert(document.location)>

so the execution URL is :

http://xxxxx.yyyy.com/customer/portal/topics/266877-xxxxx-extend-for-ios?pid=aaa<style/onload=alert(document.location)>

Make sure to use a mobile browser or a browser with mobile user agent....

Reproduction Instructions / Proof of Concept

1. Navigate to the vulnerable URL using mobile browser (or change the useragent details to any mobile browser UA and open the vulnerable link) for verification.

2. On the bottom of the page you can observe that a variable pid is displayed as "pid=undefined"

3. So pass a variable pid with any XSS payload through the URL hence executing the XSS payload.

POC: 


The same website is vulnerable to URL redirection as well.

Open redirection vulnerability:

As per owasp, "Unvalidated redirects and forwards are possible when a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input. By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Unvalidated redirect and forward attacks can also be used to maliciously craft a URL that would pass the application’s access control check and then forward the attacker to privileged functions that they would normally not be able to access."

The Vulnerable URL is : http://xxxxx.yyyy.com/customer/portal/articles/search?return_url=

Payload used is : http://www.facebook.com

So the execution URL is :

http://xxxxx.yyyy.com/customer/portal/articles/search?return_url=http://www.facebook.com

Reproduction Instructions / Proof of Concept

Make sure to use a mobile browser or a browser with mobile user agent....

1. Navigate to the vulnerable URL using mobile browser (or change the user-agent to any mobile browser UA and open the vulnerable link) for verification.

You will find yourself redirected to m.facebook.com as it is a mobile browser.

POC: As this is DOM based redirection, can not disclose the poc without disclosing the target :(


Thanks for reading.. As always suggestions and queries are welcome.

Saturday, 16 April 2016

How I could Delete Instagram Captions and Comments that are not mine,.....

Its been a while since i published my last post. So, here i come with a write up for chaining of multiple issues in Facebook Acquisition - Instagram, that could allowed me to delete entire comments/captions from the Instagram DB.


Instagram Web and mobile Applications
For the first 2 hours or so, I could not find anything as each request is added with a signature and I am lazy enough not to understand/reverse the signature logic. So as usual, i was about the close my Mac and then, saw a request without signature.


request without a signature
Bingo..something to play around. so i started working on the request, trying to find most common bugs, like sqli,xss, csrf etc.. Then to cross verify a csrf issue, I used my browser. But to my surprise, in later requests in browser app, there is no signature at all, but of-course csrf issue is properly protected.

So while testing with both the App and Browser together, I realised that there is an authorisation flaw in the comment deletion action. But it requires certain comment ID values, which are (supposed to be) not available for comments other than your's.. So basically, you can not delete other's comments as you wont be having other's comment IDs (such a nice logic).

request used for deleting comments

So i went back through the 10mb of all my burp logs to find, if the comment ids are leaked somewhere. And bingo, there is an api which shows comment ids of all the comments of a picture.


request that fetches comment ids

So now we have all the elements needed to do some DAMAGE....

url :     https://www.instagram.com/web/comments/<phto id>/delete/<comment/description id>/

photo id & owner id: to extract the ids of the target photos/comments, make a GET call to


https://www.instagram.com/<target username>/

comment/description id : to extract the comment id of the target comment, make a GET call to


https://i.instagram.com/api/v1/media/<photo id>_<owner id>/comments/

Now is the time to Delete some comments.... simply make a POST call with web app cookies to


https://www.instagram.com/web/comments/<photo id>/delete/<comment id>/

(but don't forget to add the csrf token into headers) and Done.. we have successfully deleted the target comment.

A better and easy (different way of enumeration of necessary information) to exploit the same bug is given in the below video demonstration.


After playing around the api for some more time, i realised that there is no rate limiting applied on the Delete api. 

So i made a small python script which will make a call to target instagram user account to fetch all the photo ids. Then it will make another request to fetch all the comment ids on each photo id. Then finally it will make requests to delete each comment on each photo, there by deleting all comments and captions ever added on any photo of the target user.


deleting all comments on all photos of target user

Thanks for reading/watching... And as usual, suggestions and queries are always welcome.


Saturday, 23 May 2015

Multiple Vulnerabilities in eFront CMS v3.6.15.4

Hi friends,

I am back with Three stories Today. There are multiple critical bugs effecting the e-front, one of the Top 10 e-learing cms available, version 3.6.15.4 build 18023. The details are as follows.
  1. Directory Traversal       (CVE : 2015-4461)
  2. Local File Inclusion      (CVE : 2015-4462)
  3. Bypass for Blocked extension file uploads      (CVE : 2015-4463)
About the e-front:
 
E-front is one of the Top 10 e-learning cms available free on the market till date. A small description from the vendor's site:

"The core of eFront is distributed as an open-source project. We have created a superior training product and we are not afraid to let you try it! The open-source edit of eFront will cover a wide range of your needs. If you are looking for a specialized solution then take a look at different efront editions."

The Issues are fixed as part of new release, efront v3.6.15.5 build 18024. You can find the change log here

Point of the Story:
 
e-front has a wide range of security precautions when using publicly. For example, server side files like php, jsp, asp and/or exe files are not supported to use within e-front. So, as a security researcher, I am curious to find the security holes in the cms and hence started to dissect the code and application. Finally I was able to find 3 critical vulnerabilities effecting the latest version of the cms (v3.6.15.4 build 18023).

Background Story:

Once the CMS is installed successfully, it creates 3 user roles namely Admin, Professor and Student. The user privilege required for these attacks is the Professor role. The issues are effecting all the e-front editions earlier than 3.6.15.4 and also applicable for both environments on Linux and Windows (32bit and 64bit editions).

Foreground Story:

1. Directory Traversal Attack :
For Professor role users, there is a feature designed to upload files as the content for different lessons. In the same feature, professor's can create multiple directories within the content/lessons directory. After creating the new directory, while opening the directory contents through the application, application sends a GET request with the absolute path of the directory as follows.

http://localhost/www/professor.php?ctg=file_manager&ajax=filesTable&limit=20&offset=0&sort=&order=desc&other=C:/xampp/htdocs/Portal/www/content/lessons/1/java/

The Parameter "other" is found to be vulnerable to path traversal attack. By pointing the parameter "other" to your target directory, we can traverse to the directory and lists all the contents of the directory.
 
 
2. Local File Inclusion :
 
In the same file uploading feature, we will have two options to upload files into the directory. one is using file upload and the second options is using files from remote urls.
 
e-front before 3.6.15.4 version accepts local files also within this 'files from remote url' option. By exploiting this weakness, I was able to upload local files into the application server file system.
 
For example, php.ini file of the server:
 
 
vulnerable parameter:  url_upload
vulnerable payload : c:\xampp\php\php.ini



once the request is processed, an instance of php.ini file is copied into the current directory and can be accessed directly from the location : /www/content/lessons/<lesson no>/<directory name>/php.ini



The same can be directly access from the url  http://localhost/www/content/lessons/2/Test/php.ini



3. Unrestricted Remote file Inclusion :

The same file upload feature has another weakness which enabled me to upload blocked extension files including php and exe files into the target server file system.

e-front has inbuilt security features to block file uploads of restricted file types like php, jsp and exe etc. If we try to upload any remote file with extension php, application throws an exception related to blocked file extensions.



Here, we can see that the application is validating the file extension of the given URL. But I was able to find a bypass for this blacklist based input validation.

To bypass this validation, I added an additional parameter at the end of the url, such as login=test. Here, login and test are not having any significance apart from bypassing the validation.



By adding an additional parameter at the end of the url, extension based validation is bypassed and the file is uploaded successfully into the file server. However, the file content is not as I expected.

In this process, when I uploaded the phpinfo.php file, a file with the exact name is created, but the content of HTML code which is a result of the file execution on my own domain. So when I executed the file, the output is always same and also it is not from the original server.

So my challenge is to upload a php file with content of php code. For this, I created my own php file with name phpinfo.php with the following content.

phpinfo.php ( on 192.168.6.58 - attacker controlled domain):
<?php
    echo "<?php  phpinfo();  ?>";
?>

which is executed on the 192.168.6.58 (my own domain) and sends <?php  phpinfo();  ?> as the output and hence   <?php  phpinfo();  ?>    is written into phpinfo.php  on target server.

phpinfo.php ( on 192.168.0.55 - target victim domain):
<?php
    phpinfo(); 
?>



Once the php file is created, the file is available in the same location as previous, which is, http://localhost/www/content/lessons/18/phpinfo.php



In this way, I was able to upload any blacklisted extension files into the file server and can execute also.

This is it guys... Done for today... Will be back with more again.. stay tuned.

As always, suggestions and questions are always welcome.. Thanks for reading.... Bye
 

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