Forbidden Page. Really?

Readers will most likely be familiar with the concept of HTTP status codes, or at least the most common ones. For the curious, you can read this page to review the complete list and an explanation of each.

Most web servers can be configured to displayed a specific page on each error code. This is most commonly used for response to ‘page not found’ (404) or ‘permission denied’ (403) responses in order to display a page vaguely useful to the human who may have mis-typed the URL.

Typical 404 error page

Typical 403 error page

Users typically trust such pages, and set about checking the URL, fixing the typo, or moving on. Just like with a lot of web content, they have implicit trust in the content served back to them. Malware uses this fact all the time – the recent growth in malicious attacks using compromised web servers provides some evidence of this.

Today saw an attack using a fake permission denied error (403). Whether the site has been constructed solely for the attack, or is a compromised machine is not instantly clear (but I suspect the former). Attempting to browse the site one is presented with a minimal looking 403 page:

Malicious 403 error page

The spelling mistake may prompt the curious to dig further, and if you do, you can see an obfuscated Javascript lurking:

<script language=JavaScript>
function sban(x){var l=x.length,b=1024,i,j,r,p=0,s=0,w=0,t=Array(63,3,7,...);
- snip -
Eror 403<br>
Access Denied

This is detected as Mal/ObfJS-A. When decrypted, the Javascript writes an iframe to the page (yawn) loading another malicious script content from a remote server (via a redirect, of course!). Do not fear, the final destination domain from where the malicious script is downloaded was used in another attack back in mid-March and is already classified as high risk by Sophos (as of 20070315), so users behind a WS1000 are already protected.