Monthly Archives: April 2013

Playing with security blogs

I’ve found a new weekend hobby – it takes only a few minutes, is easily interruptible, and reminds me that the state of web security is such that I will never be out of a job.

I open my favourite search engine (I’m partial to Bing, partly because I get points, but mostly because I’ve met the guys who built it), search for “security blog”, and then pick one at random.

Once I’m at the security blog site – often one I’ve never heard of, despite it being high up in the search results – I find the search box and throw a simple reflected XSS attack at it.

If that doesn’t work, I view the source code for the results page I got back, and use the information I see there to figure out what reflected XSS attack will work. Then I try that.

[Note: I use reflected XSS, because I know I can only hurt myself. I don’t play stored XSS or SQL injection games, which can easily cause actual damage at the server end, unless I have permission and I’m being paid.]

Finally, I try to find who I should contact about the exploitability of the site.

It’s interesting just how many of these sites are exploitable – some of them falling to the simplest of XSS attacks – and even more interesting to see how many sites don’t have a good, responsive contact address (or prefer simply not to engage with vuln discoverers).

So, what do you find?

I clearly wouldn’t dream of disclosing any of the vulnerabilities I’ve found until well after they’re fixed. Of course, after they’re fixed, I’m happy to see a mention that I’ve helped move the world forward a notch on some security scale. [Not sure why I’m not called out on the other version of that changelog.] I might allude to them on my twitter account, but not in any great detail.

From clicking the link to exploit is either under ten minutes or not at all – and reporting generally takes another ten minutes or so, most of which is hunting for the right address. The longer portion of the game is helping some of these guys figure out what action needs to be taken to fix things.

Try using a WAF – NOT!

You can try using a WAF to solve your XSS problem, but then you’ve got two problems – a vulnerable web site, and that you have to manage your WAF settings. If you have a lot of spare time, you can use a WAF to shore up known-vulnerable fields and trap known attack strings. But it really doesn’t ever fix the problem.

Don’t echo my search query

If you can, don’t echo back to me what I sent you, because that’s how these attacks usually start. Don’t even include it in comments, because a good attack will just terminate the comment and start injecting HTML or script.

Remove my strange characters

Unless you’re running a source code site, you probably don’t need me to search for angle brackets, or a number of other characters. So take them out of my search – or plain reject my search if I include them in my search.

Encode everything

OK, so you don’t have to encode the basics – what are the basics? I tend to start with alphabetic and numeric characters, maybe also a space. Encode everything else.

Which encoding?

Yeah, that’s always the hard part. Encode it using the right encoding. That’s the short version. The long version is that you figure out what’s going to decode it, and make sure you encode for every layer that will decode. If you’re putting my text into a web page as a part of the page’s content, HTML encode it. If it’s in an attribute string, quote the characters using HTML attribute encoding – and make sure you quote the entire attribute value! If it’s an attribute string that will be used as a URL, you should URL encode it. Then you can HTML encode it, just to be sure.

[Then, of course, check that your encoding hasn’t killed the basic function of the search box!]

Respond to security reports

You should definitely respond to security reports – I understand that not everyone can have a 24/7 response team watching their blog (I certainly don’t) – you should try to respond within a couple of days, and anything under a week is probably going to be alright. Some vuln discoverers are upset if they don’t get a response much sooner, and see that as cause to publish their findings.

Me, I send a message first to ask if I’ve found the right place to send a security vulnerability report to, and only when I receive a positive acknowledgement do I send on the actual details of the exploit.

Be like Billy – Mind your XSS Manners!

I’ve said before that I wish programmers would respond to reports of XSS as if I’d told them I caught them writing a bubble sort implementation in Cobol. Full of embarrassment at being such a beginner.

Using URL anchors to enliven XSS exploits

I hope this is original, I certainly couldn’t find anything in a quick bit of research on “Internet Explorer”, “anchor” / “fragment id” and “onfocus” or “focus”. [Click here for the TLDR version.]

Those of you who know me, or have been reading this blog for a while know that I have something of a soft spot for the XSS exploits (See here, here, here and here – oh, and here). One of the reasons I like them is that I can test sites without causing any actual damage to them – a reflected XSS that I launch on myself only really affects me. [Stored XSS, now that’s a different matter] And yet, the issues that XSS brings up are significant and severe.

A quick reminder

XSS issues are significant and severe because:

  • An attacker with a successful XSS is rewriting your web site on its way to the user
  • XSS attacks can be used to deliver the latest Java / ActiveX / Flash / Acrobat exploits
  • Stored XSS can affect all of your customers, and can turn your web server into a worm to infect all of your users all of the time
  • A reflected XSS can be used to redirect your users to a competitor’s or attacker’s web site
  • A reflected or stored XSS attack can be used to void any CSRF protection you have in place
  • XSS vulnerability is usually a sign that you haven’t done the “fit and finish” checks in your security reviews
  • XSS vulnerability is an embarrassing rookie mistake, made often by seasoned developers

Make it “SEXY”

So, I enjoy reporting XSS issues to web sites and seeing how they fix them.

It’s been said I can’t pass a Search box on a web site without pasting in some kind of script and seeing whether I can exploit it.

So, the other day I decided for fun to go and search for “security blog” and pick some entries at random. The first result that came up – blog.schneier.com – seemed unlikely to yield any fruit, because, well, Bruce Schneier. I tried it anyway, and the search box goes to an external search engine, which looked pretty solid. No luck there.

A couple of others – and I shan’t say how far down the list, for obvious reasons – turned up trumps. Moderately simple injections into attributes in HTML tags on the search results page.

One only allowed me to inject script into an existing “onfocus” event handler, and the other one allowed me to create the usual array of “onmouseover”, “onclick”, “onerror”, etc handlers – and yes, “onfocus” as well.

I reported them to the right addresses, and got the same reply back each time – this is a “low severity” issue, because the user has to take some action, like wiggling the mouse over the box, clicking in it, etc.

Could I raise the severity, they asked, by making it something that required no user interaction at all, save for loading the link?

Could I make the attack more “sexy”?

Try something stupid

Whenever I’m faced with an intellectual challenge like that, I find that often a good approach is to simply try something stupid. Something so stupid that it can’t possibly work, but in failing it will at least give me insight into what might work.

I want to set the user’s focus to a field, so I want to do something a bit like “go to the field”. And the closest automatic thing that there is to “going to a field” in a URL is the anchor portion, or “fragment id” of the URL.

Anchor? What’s that in a URL?

You’ll have seen them, even if you haven’t really remarked on them very much. A URL consists of a number of parts:

protocol://address:port/path1//path2?query#anchor

The anchor is often called the “hash”, because it comes after the “hash” or “sharp” or “pound” (if you’re not British) character. [The query often consists of sets of paired keys and values, like “key1=value1&key2=value2”, etc]

The purpose of an anchor is to scroll the window to bring a specific portion to the top. So, you can give someone a link not just to a particular page, but to a portion of that page. It’s a really great idea. Usually an anchor in the URL takes you to a named anchor tag in the page – something that reads “<a name=foobar></a>” will, for instance, be scrolled to the top whenever you visit it with a URL that ends with “#foobar”.

[The W3C documentation only states that the anchor or fragment ID is used to “visit” the named tag. The word “visit” is never actually defined. Common behaviour is to load the page if it’s not already loaded, and to scroll the page to bring the visited element to the top.]

This anchor identifier in the URL is also known as a “fragment identifier”, because technically the anchor is the entire URL. Not what people make as common usage, though.

XSS fans like myself are already friendly with the anchor identifier, because it has the remarkable property of never being sent to the server by the browser! This means that if your attack depends on something in the anchor identifier, you don’t stand much chance of being detected by the server administrators.

Sneaky.

The stupid thing

So, the stupid thing that I thought about is “does this work for any name? and is it the same as focus?”

Sure enough, in the W3C documentation for HTML, here it is:

Destination anchors in HTML documents may be specified either by the A element (naming it with the name attribute), or by any other element (naming with the id attribute).

[From http://www.w3.org/TR/html4/struct/links.html#h-12.1]

So, that means any tag with an “id” attribute can be scrolled into view. This effectively applies to any element with a “name” attribute too, because:

This attribute [name] names the current anchor so that it may be the destination of another link. The value of this attribute must be a unique anchor name. The scope of this name is the current document. Note that this attribute shares the same name space as the id attribute. [my emphasis]

[From http://www.w3.org/TR/html4/struct/links.html#adef-name-A]

This is encouraging, because all those text boxes already have to have ids or names to work.

So, we can bring a text box to the top of the browser window by specifying its id or name attribute as a fragment.

That’s the first stupid thing checked off and working.

Bringing it into focus

But moving a named item to the top of the screen isn’t the same as selecting it, clicking on it, or otherwise giving it focus.

Or is it?

Testing in Firefox, Chrome and Safari suggested not.

Testing in Internet Explorer, on the other hand, demonstrated that even for as old a version as IE8, all the way through IE9 and IE10, caused focus behaviour – including any “onfocus” handler – to trigger.

The TLDR version:

Internet Explorer has a behaviour different from other browsers which makes it easier to exploit a certain category of XSS vulnerabilities in web sites.

If you are attacking users of a vulnerable site that allows an attacker to inject code into an “onfocus” handler (new or existing), you can force visitors to trigger that “onfocus” event, simply by adding the id or name of the vulnerable HTML tag to the end of the URL as a fragment ID.

You can try it if you like – using the URL http://www.microsoft.com/en-us/default.aspx#ctl00_ctl16_ctl00_ctl00_q

OK, so you clicked it and it didn’t drop down the menu that normally comes when you click in the search field on Microsoft’s front page. That’s because the onfocus handler wasn’t loaded when the browser set the focus. Try reloading it.

You can obviously build any number of test pages to look at this behaviour:

<form>

<input type="text" name="exploit" id="exploitid" onfocus="alert(1)" />

</form>


Loading that with a link to formpage.html#exploit or formpage.html#exploitid will pop up an ‘alert’ dialog box.


So, that’s a security flaw in IE, right?


No, I don’t think it is – I don’t know that it’s necessarily even a flaw.


The documentation I linked to above only talks about the destination anchor being used to “visit” a resource. It doesn’t even say that the named anchor should be brought into view in any way. [Experiment: what happens if the ID in the fragment identifier is a “type=hidden” input field?]


It doesn’t say you should set focus; it also doesn’t say you should not set focus. Setting focus may be simply the most convenient way that Internet Explorer has to bring the named element into view.


And the fact that it makes XSS exploits a little easier doesn’t make it a security flaw either – the site you’re visiting STILL has to have an XSS flaw on it somewhere.


Is it right to publish this?


Finally, the moral question has to be asked and answered.


I start by noting that if I can discover this, it’s likely a few dozen other people have discovered it too – and so far, they’re keeping it to themselves. That seems like the less-right behaviour – because now those people are going to be using this on sites unaware of it. Even if the XSS injection is detected by the web site through looking in their logs, those same logs will tell them that the injection requires a user action – setting focus to a field – and that there’s nothing causing that to happen, so it’s a relatively minor issue.


Except it’s not as minor as that, because the portion of the URL that they CAN’T see is going to trigger the event handler that just got injected.


So I think the benefit far outweighs the risk – now defenders can know that an onfocus handler will be triggered by a fragment ID in a URL, and that the fragment ID will not appear in their log files, because it’s not sent to the server.


I’ve already contacted Microsoft’s Security team and had the response that they don’t think it’s a security problem. They’ve said they’ll put me in touch with the Internet Explorer team for their comments – and while I haven’t heard anything yet, I’ll update this blog when / if they do.


In general, I believe that the right thing to do with security issues is to engage in coordinated disclosure, because the developer or vendor is generally best suited to addressing specific flaws. In this case, the flaw is general, in that it’s every site that is already vulnerable to XSS or HTML injection that allows the creation or modification of an “onfocus” event handler. So I can’t coordinate.


The best I can do is communicate, and this is the best I know how.

Credential Provider update–Windows 8 SDK breaks a few things…

You’ll recall that back in February of 2011, I wrote an article on implementing your first Credential Provider for Windows 7 / 8 / Server 2008 R2 / Server 2012 – and it’s been a fairly successful post on my blog.

Just recently, I received a report from one of my users that my version of this was no longer wrapping the password provider on Windows Server 2008 R2.

As you’ll remember from that earlier article, it’s a little difficult (but far from impossible) to debug your virtual machine to get information out of the credential provider while it runs.

Just not getting called

Nothing seemed to be obviously wrong, the setup was still executing the same way, but the code just wasn’t getting called. For the longest time I couldn’t figure it out.

Finally, I took a look at the registry entries.

My code was installing itself to wrap the password provider with CLSID “{60b78e88-ead8-445c-9cfd-0b87f74ea6cd}”, but the password provider in Windows Server 2008 R2 appeared to have CLSID “{6f45dc1e-5384-457a-bc13-2cd81b0d28ed}”. Subtle, to be sure, but obviously different.

I couldn’t figure out immediately why this was happening, but I eventually traced back through the header files where CLSID_PasswordCredentialProvider was defined, and found the following:

   1: EXTERN_C const CLSID CLSID_PasswordCredentialProvider;


   2:  


   3: #ifdef __cplusplus


   4:  


   5: class DECLSPEC_UUID("60b78e88-ead8-445c-9cfd-0b87f74ea6cd") 


   6: PasswordCredentialProvider; 


   7: #endif


   8:  


   9: EXTERN_C const CLSID CLSID_V1PasswordCredentialProvider;


  10:  


  11: #ifdef __cplusplus


  12:  


  13: class DECLSPEC_UUID("6f45dc1e-5384-457a-bc13-2cd81b0d28ed") 


  14: V1PasswordCredentialProvider; 


  15: #endif 


  16:  

As you can see, in addition to CLSID_PasswordCredentialProvider, there’s a new entry, CLSID_V1PasswordCredentialProvider, and it’s this that points to the class ID that Windows Server 2008 R2 uses for its password credential provider – and which I should have been wrapping with my code.

The explanation is obvious

It’s clear what happened here with a little research. For goodness-only-knows-what-unannounced-reason, Microsoft chose to change the class ID of the password credential provider in Windows 8 and Windows Server 2012. And, to make sure that old code would continue to work in Windows 8 with just a recompile, of course they made sure that the OLD name “CLSID_PasswordCredentialProvider” would point to the NEW class ID value. And, as a sop to those of us supporting old platforms, they gave us a NEW name “CLSID_V1PasswordCredentialProvider” to point to the OLD class ID value.

And then they told nobody, and included it in Visual Studio 2012 and the Windows 8 SDK.

In fact, if you go searching for CLSID_V1PasswordCredentialProvider, you’ll find there’s zero documentation on the web at all. That’s pretty much unacceptable behaviour, introducing a significantly breaking change like this without documentation.

So, how to support both values?

Supporting both values requires you to try and load each class in turn, and save details indicating which one you’ve loaded. I went for this rather simple code in SetUsageScenario:

   1: IUnknown *pUnknown = NULL;


   2: _pWrappedCLSID = CLSID_PasswordCredentialProvider;


   3: hr = ::CoCreateInstance(CLSID_PasswordCredentialProvider, NULL, CLSCTX_ALL, IID_PPV_ARGS(&pUnknown));


   4: if (hr == REGDB_E_CLASSNOTREG)


   5: {


   6:     _pWrappedCLSID = CLSID_V1PasswordCredentialProvider;


   7:     hr = ::CoCreateInstance(CLSID_V1PasswordCredentialProvider, NULL, CLSCTX_ALL, IID_PPV_ARGS(&pUnknown));


   8: }

Pretty bone-dead simple, I hope you’ll agree – the best code often is.

Of course, if you’re filtering on credential providers, and hope to hide the password provider, you’ll want to filter both providers there, too. Again, here’s my simple code for that in Filter:

   1: if (IsEqualGUID(rgclsidProviders[i], CLSID_PasswordCredentialProvider))


   2:     rgbAllow[i]=FALSE;


   3: if (IsEqualGUID(rgclsidProviders[i], CLSID_V1PasswordCredentialProvider))


   4:     rgbAllow[i]=FALSE;



If that wasn’t nasty enough…



Ironically, impacting the Windows XP version of the same package (which uses a WinLogon Notification Provider, instead of a Credential Provider), another thing that the Windows 8 SDK and Visual Studio 2012 did for me is that it disabled the execution of my code on Windows XP.



This time, they did actually say something about it, though, which allowed me to trace and fix the problem just a little bit more quickly.



The actual blog post (not official documentation, just a blog post) that describes this change is here:



Windows XP Targeting with C++ in Visual Studio 2012



What this blog indicates is that a deliberate step was taken to disable Windows XP support in executables generated by Visual Studio 2012. You have to go back and make changes to your projects in order to continue supporting Windows XP.



That’s not perhaps so bad, because really, Windows XP is pretty darn old. In fact, in a year from now it’ll be leaving its support lifecycle, and heading into “Extended Support”, where you have to pay several thousand dollars for every patch you want to download. I’d upgrade to Windows 7 now, if I were you.