bugbounty

Exploit-DB Local File Inclusion (Possible RCE/RFI)

8:05 PM



I am writing this blog post because both the teams that handled this bug were quite amazing. (Vulnerable 3rd party and Offensive Security) They acknowledged, fixed and rewarded my report in <1hr of my submission. (both of them) This, for someone with experience with responsible disclosure is unbelievable.

So it starts out like this, Offensive-Security's Exploit-db announced they just launched their new appearance. I checked it out, it’s quite beautiful, less darker and all… a white-hat’s place. It looked less like Inj3ctor and more like exploit-db. 

I noticed they are running wordpress, with a number of plugins. But they obviously were all updated and running latest version. I had to find a 0day. So I downloaded their new caching plugin for page performance, WP-ROCKET. (which by the way handled the bug quite well, and even acknowledged my report in multiple ways, Thank you!)

The code looked good, I found no SQLi, no XSS. But then, a very silly page seems to appear with a silly code.
/wp-content/wprocketfolder/inc/front/process.php line 44,

Says include ($rocket_config_path . $host . '.php');

Where $host is pre-defined as:

44: $host = trim(strtolower($_SERVER['HTTP_HOST']), '.');

This page can be accessed to anyone and requires no wordpress authentication. The HTTP_HOST header can be manipulated simply by tampering with the HOST header. (Edit: This is only applicable if certain Apache/php.ini are fulfilled.) I then wrote about the bug to Offensive-Security, they responded 12mins later saying they disabled the plug in.

In an LFI theory, an attacker can poison log files and include them as ../../logfile to cause Remote code execution. (RCE) Practically that would be hard to exploit for RCE because an attacker would need to bypass the WAF they are running called Sucuri. And also php doesn’t let null termination (%x00) work (because its patched since < 5.2.1), this would be difficult to achieve But...

This can be exploited by using php://filter for local file inclusion by sending a HOST headers like
php://filter/convert.base64-encode/resource=index then when the include happens, $host.'php'); our resource parameter will get index.php, this forces PHP to base64 encode the file before it is used in the include statement. From this point its a matter of then decoding the base64 string to obtain the source code for the PHP files. Simple yet effective..

Or This theoretically would also had been exploitable to RFI (Remote File Inclusion) if the path wasn't relative. In absolute URL cases, we can use the data:// Scheme to cause RFI. By encoding a PHP script in base64 and then URL encoding any special characters contained within this string we can successfully execute a script. Below example shows how phpinfo() can be executed using the above script to enumerate more information about the targe. Or a simple RCE by using the expect:// scheme (same as the one that caused the XXE RCE in Facebook)

<? phpinfo(); die();?>

// Base64 Encoded
PD8gcGhwaW5mbygpOyBkaWUoKTs/Pg==

// URL + Base64 Encoded
PD8gcGhwaW5mbygpOyBkaWUoKTs%2fPg==

// Final URL in HOST
data://text/plain;base64,PD8gcGhwaW5mbygpOyBkaWUoKTs%2fPg==

The die() statement is there to prevent the execution of the rest of the script or the execution of of the incorrectly decoded ".php" string which is appended to the stream.

Using a data stream over a standard remote or local file inclusion has several benefits:

  • It doesn't require a remote server.
  • Its doesn't require a null-byte to be appended to the end of the script.
  • It works behind a firewall that blocks outbound traffic.

However, exploitation was blocked because of a fair WAF called Suruci and The include being relative. Nevertheless, they treated the bug as critical as it is, and pushed a fix in < hr of my initial report  and added my name to their Special Thanks page.(of course with a bounty)!

Special Thanks to Julio Potier, a programer of the WP-Rocket team. He acknowledged my report, fixed the bug, and even issued a generous bounty.

Timeline

April 19, 6:54 am – Initial Report
April 19, 7:08 am – Confirmation
April 19, 7:43 – Complete Fix + Bounty

findings

Exploiting PHP Upload forms with CVE-2015-2348

4:06 AM

Today I would like to post about a recent bug I have found in PHP, CVE-2015-2348.
This bug is fairly severe. (considering the amount of developers affected).
I have to admit checking the file extension and saying a file is safe can still cause many
other security issues. However, checking for this exact vulnerability in your code is pretty
unrealistic, considering it can pass the Content-Type, Extension, Mime type, size checks...
etc won't save you from this.

The issue occurs in the very popular move_uploaded_files php function that is used to handle
uploaded files most of the time. This function checks to ensure that the file designated by
filename is a valid upload file (meaning that it was uploaded via PHP's HTTP POST upload
mechanism). If the file is valid, it will be moved to the filename given by destination.

Example:

move_uploaded_file ( string $filename , string $destination )

The problem with it is that there is a way to insert null-bytes (fixed multiple times before,
i.e: CVE-2006-7243). Using null-bytes an attacker can convince an upload box to ignore
extension checks and that the file is fairly safe and valid and upload malicious files that
can cause RCE. using the character \x00

I am going to take DVWA for an example here. DVWA's highest level is meant to be unbroken
for number of issues. the high upload box is meant to teach developers the safe way of handling
a safe upload. Lets just exploit that.

Here is the code snippet from https://github.com/RandomStorm/DVWA/blob/master/
vulnerabilities/upload/source/high.php:

$uploaded_name = $_FILES['uploaded']['name'];
$uploaded_ext = substr($uploaded_name, strrpos($uploaded_name, '.') + 1);
$uploaded_size = $_FILES['uploaded']['size'];

if (($uploaded_ext == "jpg" || $uploaded_ext == "JPG" || $uploaded_ext == "jpeg" ||
$uploaded_ext == "JPEG") && ($uploaded_size < 100000)){

if(!move_uploaded_file($_FILES['uploaded']['tmp_name'], $target_path)) {

$html .= '';
$html .= 'Your image was not uploaded.';
$html .= ''; }
else {
$html .= $target_path . ' succesfully uploaded!';
.
.

This is yes vulnerable to number of exploits (like XSCH, XSS and more), but not RCE.
Because since PHP 5.3.1 Null bytes are deprecated.

The problem with DVWA is that its passing user provided name to the move_uploaded_file()

Expected behavior for PHP to create:

move_uploaded_file($_FILES['name']['tmp_name'],"/file.php\x00.jpg")

That file should have created the file "file.php\x00.jpg"

Reality creates: file.php

This clearly bypasses the extension check. It has been proven many times the GD libraries
can also be defeated ( getimagesize(), imagecreatefromjpeg()... ),
read this by @secgeek for example.

Now even if you have had done multiple checks for this, it will be highly unlikely you blacklisted
the char \x00 so most upload forms running PHP before 5.4.39, 5.5.x before 5.5.23, and 5.6.x
before 5.6.7 are vulnerable for this particular attack.

Conclusion:

If you are on a vulnerable server, update homie!


bugbounty

Facebook Bug Bounty: Clickjacking

10:14 AM



Note: this is actually a guest post from a friend, Sahad Nk with his recently patched Facebook Clickjacking bug. The exploit was really interesting so I really hope you enjoy it.



ClickJacking:


According to OWASP: Clickjacking, also known as a "UI redress attack", is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the the top level page. Thus, the attacker is "hijacking" clicks meant for their page and routing them to another page, most likely owned by another application, domain, or both.

Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker.

According to me: Clickjacking is an interesting and simple way of exploiting a web application that can lead to serious issues (transfer funds, messaging...). The idea is actually really simple:

We frame a certain website A within an Iframe and using stylesheets, we made it invisible/hidden (when it exists in the background) and reconstruct another site before it. So while you click something on the attacker controlled site, I can actually make you click a button in the framed website.

Owasp have a good example for ClickJacking: For example, imagine an attacker who builds a web site that has a button on it that says "click here for a free iPod". However, on top of that web page, the attacker has loaded an iframe with your mail account, and lined up exactly the "delete all messages" button directly on top of the "free iPod" button. The victim tries to click on the "free iPod" button but instead actually clicked on the invisible "delete all messages" button. In essence, the attacker has "hijacked" the user's click, hence the name "Clickjacking".


The simplest and effective fix for this is the X-Frame-Options header. Even though, Facebook was using one, here is how I bypassed it to make me an attacker do post a status update. :)

The Exploit:

The exploit is really simple and effective; Facebook defends click-jacking in 2 ways. One is alternative to the other. They also use a technique called Frame-busting (using javascript to deny framing request). On interfaces which don't have a JS support it is sending XFO, not as a
HTTP header, but in a meta tag by putting it in a <noscript> tag

<noscript><meta http-equiv="X-Frame-­Options" content="deny"> </noscript>

Meta-tags that attempt to apply the X-Frame-Options directive DO NOT WORK. For example, <meta http-equiv="X-Frame-­Options" content="deny">) will not work. You must apply the X-FRAME-OPTIONS directive as HTTP Response Header.


The main point here is browsers ignores what is given in meta tag and do not defend framing, (tested in Firefox 35).

On interfaces which require JS support, it is possible to bypass JS frame-busting by giving a sandbox in the iframe like:

<iframe id="clickjacking" src="https://­iphone.facebook.com/­dialog/feed?app_id[APP ID]&picture­=http://example.com/­example.JPG&name=Test­&description=This%20­is%20a%20test&redire­ct_uri=http://­example.com/" width="500" height="500" scrolling="no" frameborder="none" sandbox="allow-forms­"> </iframe>

Simple as that, it was possible to iframe Facebook and make you do undesirable amount of things.
Here is a video demonstrating the seriousness of how this exploit might have been abused:


Reported - March 20
Clarification - March 21
Fix & Bounty  - March 24

Hope you enjoyed it! and thanks Sahad Nk!

bugbounty

Facebook: Another Linkshim Bypass

12:48 PM


I wasn't going to post about this but it turns out, this could be an interesting article to post because this is the 3rd vulnerability that got fixed in the same parameter 6 months later.

You can find my inital linkshim bypass to this exact position which later turns out to be XSS if you click here. In the first bug I found in the continue parameter, it is possible to bypass linkshim and force a redirection to a site before being checked but then, XSS. later, this resulted some media attention and now when I find another linkshim bypass, I taught why no one else actually found this bypass, after the first got public. and that is one of the main reasons I am posting this.

I am going to talk about a relevant and great technique I learned from the prompt.ml XSS Challenge(s) 4, you can find the DOM XSS challenge here. consider the code:

function escape(input) {
    // make sure the script belongs to own site
    // sample script: http://prompt.ml/js/test.js
    if (/^(?:https?:)?\/\/prompt\.ml\//i.test(decodeURIComponent(input))) {
        var script = document.createElement('script');
        script.src = input;
        return script.outerHTML;
    } else {
        return 'Invalid resource.';
    }
}

This is the JS source code of challenge 4. they basically want you to bypass a regex to get an external redirection. And the main problem here is that it uses decodeURIComponent(), a function that decodes supplied input from URL encoding. In this case, we can trick the browser believe the prompt.ml domain (allowed by the regex) belongs to our URL. This should be very simple using HTTP auth, like http://prompt.ml@attacker.com the above URL redirects to attacker.com and should bypass the regex because having the prompt.ml.

To bypass decodeURIComponent(), we simply have to use %2f which is a URL encoded representation for the /. And our bypass is: 
//prompt.ml%2f@á„’.ws/✌

“The trick to solve the level with 17 characters only lies hidden in a transformation behavior some browsers apply when converting Unicode characters to URLs. A certain range of characters resolves to three other characters of which one is a dot - the dot we need for the URL. The following vectors uses the domain 14.rs that can be expressed by two characters only.”

A url that starts with two forward slashes is treated as absolute by browsers.
Something similar seems to cause this issue (server-side), when given the continue parameter,
https://m.facebook.com/feed_menu/?story_fbid=808015282566492&id=100000740832129&confirm=h&continue=http://example.com

This successfully will send example.com for a check to a linkshim before extermal redirection which means https://m.facebook.com/feed_menu/?story_fbid=808015282566492&id=100000740832129&confirm=h&continue=http://evilzone.org should be malicious.

Now a stupid enough URL validator will consider //evilzone.org a relative location and won’t allow us create a hyperlink like <a href=”//evilzone.org”> and Facebook obviously have black listed //

The next try should be \/evilzone.org, since most browsers render \ back to / this usually bypass the check and create //evilzone.org (you can read more about this from @homrkov’s Evolution of Open Redirection post)

So // and \/ got caught. At this point I concluded the linkshim uses number of blacklist based checks from \\, //, \/ and started fuzzing.

Thanks to @FransRosen, he told me about a technique that could create this bypass. \%09/@site.com
This basically should be equivalent to //@site.com and since the regex won’t find \%09/ , \%0D/ or \%0A/ blacklisted, this will result // because the %09 should obviously get ignored while parsing. And the complete linkshim bypass will look something like:

https://m.facebook.com/feed_menu/?story_fbid=808015282566492&id=100000740832129&confirm=h&continue=\%09/@example.com



Feb 1, 2015 6:33am - Inital Report
Feb 1, 2015 6:47am - More Clarification sent
Feb 2, 2015 6:11am - More Classfication asked 
Feb 3, 2015 1:04pm - Some more clarifications sent
Feb 4, 2015 11:25am - Escalation of bug    
Feb 23, 2015 11:00am - Bug Fixed
  
Thanks you for reading! :-)


bugbounty

Facebook’s Oculus – Cross-Site Content Hijacking (XSCH) to Bypass SOP

8:42 AM




First off, before going in-depth about this I would like to paste you what a crossdomain.xml file is,here is something that are taken from Ookla, you can read more here.

What is the crossdomain.xml file?

The crossdomain.xml file is a cross-domain policy file. It grants the Flash Player permission to talk to servers other than the one it's hosted on.

In what circumstances do I need to use one?

You need a crossdomain.xml file when your Speedtest uses external hosts as testing servers.

Crossdomain.xml files

Flash Player’s default security model enforces the same origin policy similar to contemporary browsers and does not allow cross domain data read operations. However, it can make exception to this rule and disregard its default security model if a website in question hosts a cross-domain policy file (named crossdomain.xml) to allow data access from other domains. Insecurely written cross-domain policy files can expose critical application data over the internet. The example policy file below shows once such example where the website opens itself to read access from every running instance of Flash Player.

“

This forexample is how a (super) vulnerable crossdomain file looks like,


<cross-domain-policy>  
      <allow-access-from domain="*" />
</cross-domain-policy>


When flash requests to access that domain, it first asks the domain if it’s okay to snoop its contents. It does that by requesting domain.com/crossdomain.xml file and reading it, that crossdomain file says "Allow-access-from *(all) domains". This means, where ever our flash file is hosted (attacker.com/hack.swf), it will be able to read the contents of domain.com. This is much like a Cross Site scripting, but less in some case. We can only request and read, we cannot write. So it less.

Using this we can steal AntiCSRF tokens, craft CSRF exploits. Read html files using victim sessions (Messages, account balance…)

Here is a great example,”

  1. A user logs on to the banking website.
  2. The user then visits another website in different browser tab and that website hosts a malicious Flash file to retrieve user information from the bank website.
  3. When the Flash Player notices an attempt to perform cross-domain read operation, it retrieves crossdomain.xml file from the bank website to discover the permitted operations.
  4. It then sends out a read request to a known bank URL that returns sensitive information like user bank account numbers, account balance etc…
  5. The browser adds user’s session cookies to the outgoing requests and since the user is logged in, the malicious Flash file is served with critical user information.
  6. Th Flash file then passes it on to the malicious server.

“

You see? This is serious s***!

There is a particular flash exploit for this attack by Gursev Singh Kalra here.http://pastebin.com/EwqkGkxp

I was bored so I gave a shot of each oculus domain. All turned out to be safe, excpet one. It says

<allow-access-from domain="*.oculus.com" secure=”true”/>



It means everything that is hosted at *.oculus.com have read access at developer.oculus.com domain.  




Luckily, I know support.oculus.com have an upload box. While submitting a ticket, you can also upload image files. You see what I am going with this? I made my malicious flash.swf file, change the extension to flash.jpg, upload it at support.oculus.com and that file now have access to developer.oculus.com because the crossdomain allowed it.



The great about flash is, despite the file Mime, or format say flash.jpg, when we embed it as flash, it will act like flash despire its content/mime type.  

The exploit Scenario follows as:

1.       1. Create a malicious flash.swf that does malicious action, like read antiCSRF tokens or   messages.

2.       2. Change the extension of flash.swf to flash.jpg

3.       3. Navigate to support.oculus.com, create a ticket and upload our malicious flash.jpg file as a supporting image to the support team

4.       4. In our malicious domain (say attacker.com) host,  


<object type="application/x-shockwave-flash" data="https://support.oculus.com/attachments/token/APToMFwKw6O45WRIS5lf1HTP7/flash.jpg" width="1" height="1">

<param name="movie" value="https://support.oculus.com/attachments/token/APToMFwKw6O45WRIS5lf1HTP7/flash.jpg" />

</object>



5.       6. Now we navigate our victim to attacker.com and as soon as the flash files runs, Boom! We get everything we need. 

   Facebook had an amazing (better?) support about this. I got the fix (less than 9hrs)
   Hope you enjoyed the post! Comments would be nice! :)
    

   Report Timeline:

      Dec 29, 2014 6:59am - Initial Report
      Jan 27, 2015 9:09am  - Facebook Initial Confirmation
      Jan 27, 2015 6:55pm  - Fix!
     
Great cooperation guys! and I would like to thank the Facebook Security team and the program it self.

Conclusion:


-          Permit access from your crossdomain.xml because a simple mistake or “*” can cause a disaster.

-          In another option, make your uploaded files have a content-disposition header with appropriate values.