HP Security Products Blog
From applications to infrastructure, enterprises and governments alike face a constant barrage of digital attacks designed to steal data, cripple networks, damage brands, and perform a host of other malicious intents. HP Enterprise Security Products offers products and services that help organizations meet the security demands of a rapidly changing and more dangerous world. HP ESP enables businesses and institutions to take a proactive approach to security that integrates information correlation, deep application analysis and network-level defense mechanisms—unifying the components of a complete security program and reducing risk across your enterprise. In this blog, we will announce the latest offerings from HP ESP, discuss current trends in vulnerability research and technology, reveal new HP ESP security initiatives and promote our upcoming appearances and speaking engagements.

Configuration is Half the Battle: ASP.NET and Cross-Site Scripting

Although it's not a new problem, a recent advisory and BlackHat presentation have brought attention to an ASP.NET mis-configuration that can leave you wide open to Cross-Site Scripting (XSS) attacks, even if you are diligently sanitizing your other user-supplied data. If the view state is not cryptographically signed, it is possible for an attacker to overwrite properties of any of your server-side controls and modify HTML returned to the user, opening a vector for XSS.


On the Attack


An early example from the 2004 article “Understanding ASP.NET View State” does not really explain the full scope of the problem:


“Nefarious users could parse the view state, modify the prices so they all read $0.01, and then deserialize the view state back to a base-64 encoded string. They could then send out e-mail messages or post links that, when clicked, submitted a form that sent the user to your product listing page, passing along the altered view state in the HTTP POST headers. Your page would read the view state and display the DataGrid data based on this view state. The end result? You'd have a lot of customers thinking they were going to be able to buy your products for only a penny!”


The potential for damage is much worse than that, and the attack is even easier to carry out.



  1. It’s not necessary to fully parse the view state. Without the signature, the only protection the view state has left is the page hash, which always occurs at the same location and can be extracted by just Base64-decoding the right bytes.

  2. As an extension of #1, it’s not necessary to modify properties that are already being put in the view state. The view state parser does not expect any particular properties to be set (or not set), so you can modify nearly anything you want.

  3. The actual attack can, of course, consist of a malicious script and not just modified text.

  4. It’s not necessary to POST the view state data. In fact, the postback event validation makes it even more difficult. Simply encoding the view state data in a GET parameter named __VIEWSTATE will allow you to provide a malicious link to be clicked, not require a user to post a form.


The attacks I created for WebInspect were based on two more discoveries:



  1. Nearly every ASP.NET control is vulnerable (especially ASP.NET 2.0)

  2. A vulnerable control will almost always appear at index 1


The first point comes from the fact that most ASP.NET controls inherit from HtmlContainerControl, which has an InnerHtml property. The results of modifying InnerHtml should be obvious. While ASP.NET 1.1 would throw an exception if you tried to set that property on another type of control, it seems that most ASP.NET 2.0 controls will just set it as an attribute after performing a weak HTML-encoding. This allows for an easy attribute-based XSS attack, even if you can’t set the inner HTML of the control, leaving nearly all classes of controls vulnerable. Actually finding a control to attack brings me to point #2: how the control indexes work. On the ‘base’ page state, the list of control indexes corresponds to the order that they appear on the page. All text that is not part of a server-side control gets placed in a LiteralControl. This does not take open/closing tags into consideration, which is why most controls will first appear at index 1; index 0 will contain a LiteralControl for all text in the page (doctype, open tag, etc) leading up to it. The full list of controls, in general, alternates LiteralControls and subclasses of HtmlControl.


Detecting a Vulnerable ASP.NET Site


One of the biggest problems with this attack is how easy it is to detect a vulnerable site. In most cases, the actual exploit is also rather easy. WebInspect has been detecting an unsigned ASP.NET 1.1 view state since 2005, by just checking the last 2 bytes of the view state. A signed ASP.NET view state will end in 20 bytes of garbage, but an unsigned view state will end in “;>” or “>>”, due to the serialization format. We might get a false positive every 32k pages or so, but overall it’s a pretty effective test. In ASP.NET 2.0, the format changed to a binary serialization which requires reading the entire view state to determine if there is any extra data at the end (no more “<” and “>” tokens). It’s much slower, but still only a few lines of code when you use the ObjectStateFormatter available to you.


When doing my research for this vulnerability, I did a quick survey of 336 random sites running ASP.NET. Of those sites, I found 30 (9%) with unsigned view states. That may not sound like a lot compared to the number of total sites with XSS vulnerabilities (some estimates say at least half, others two-thirds). However, finding most XSS vulnerabilities usually requires checking hundreds of inputs with different kinds of validation. Finding a site with an unsigned view state is fast, simple and passive.


Of course, having an unsigned view state is not a guarantee of being exploitable. Some of those sites had a very minimal view state, which likely means that view state was disabled for the page (ASP.NET will still insert a “stub” view state). If your view state is disabled, disabling signing could be a legitimate performance improvement. If you are not disabling view state, but disabling signing, you’re almost certainly vulnerable.


Protect Yourself!


Protecting yourself is quite simple: don’t disable view state signing! It can be turned off in your web.config, a page’s .aspx file, or code-behind class. A full text search for “EnableViewStateMac“ should be all you need to check your own code. If you’re not changing it anywhere, you’re secure by default. WebInspect users can Smart Update to the latest SecureBase to get updated checks. We can detect an unsigned view state for ASP.NET 1.1 and 2.0 (and later; 3.5 still uses the same view state format), and attempt to attack both of them as well.


While you’re at it, there are a few other settings you may wish to review. If you are putting any sensitive information in the view state, it can be easily decoded and read by a 3rd party. You can set ViewStateEncryptionMode="Always" in your web.config or in individual pages. Since the signing key is always the same, it could be possible to construct a malicious, but valid, view state and then give the link to someone else, creating a Cross-Site Request Forgery attack (CSRF). This would be more difficult to execute than the XSS attack, but it’s just as easy to prevent. Set the ViewStateUserKey property in your page to a user-specific value, like the session ID. This adds a salt when signing, so that two users with the same view state data will have different signatures. If it were me, I would have all 3 options enabled, (salting, signing and encrypting), but everyone should evaluate the needs of their own applications.

Microsoft's ClickOnce Firefox add-on

With Firefox, I just went to download a certain new version 2.0 web browser and and was surprised that after hitting the license accept button Firefox started up an installer, downloaded the application and installed it without any prompts or questions. This is not the security experience with Firefox I've been accustomed to.


I did some digging around in the page's code, a little searching, and found I had the "Microsoft .NET Framework Assistant" installed into my Firefox add-ons. A little more digging and I found it was silently installed with .NET 3.5 SP1. Yes, that's right, I said silently. What's more, the default settings of this add-on allow sites to start installers without prompting.



That second checkbox also points to another minor annoyance--that the add-on reports the installed .NET versions to every website you visit via the User-Agent string. Nice.


While you can change the settings via Firefox, and even disable it, the icing on the cake you can't actually uninstall it without jumping through hoops. Microsoft's Brad Abrams, in a blog post, said:


We added this support at the machine level in order to enable the feature for all users on the machine.  Seems reasonable right?  Well, turns out that enabling this functionality at the machine level, rather than at the user level means that the "Uninstall" button is grayed out in the Firefox Add-ons menu because standard users are not permitted to uninstall machine-level components.  


Oh, Brad, I'm frightened. What kind of a place is this? No--it doesn't sound reasonable. Microsoft should have published it in Mozilla's add-on directory like everyone else and not quietly changed their biggest (browser) competitor's product , drastically weakening its security in the process.


To uninstall the extension completely, you'll have to follow the steps outlined in Brad's post, which involve registry editing and directly editing Firefox's configuration.


While this is not exactly ground-breaking news here on the internet--there are plenty of pages crying foul with this whole deal--I hadn't heard of it, so it seemed worth posting about to spread the word just a little bit. And we should all review our primary browser's add-ons/extensions on a regular basis.

Labels: Microsoft

URL Authentication - IE Silliness

IE dropped support for URL authentication (e.g., http://user:smileytongue:ass@example.com/) around 2004. There are plenty of discussions out there about the merits and problems with URL authentication, so I won't comment on it yet again. However, it is still in the RFC.


If you try to load a URL with authentication in IE 6, you see the message "Invalid Syntax Error: Page Cannot Be Displayed" -- which at least points to the fact that there may be a problem with the link you followed. However, I happened to notice in IE 7 that they've dumbed it down a little further: "Windows cannot find 'http://user:smileytongue:ass@example.com/'. Check the spelling and try again"


If you don't put the "http://" in your browser (because for years browsers have been teaching people not to type the protocol), you get the completely different error "The webpage cannot be displayed."  


Way to go IE team! Rather than providing a better user experience, you hint that the site name is incorrect and leave it alone. Good job helping to educate your users.


Incidentally, Firefox, Safari and Opera will ignore invalid syntaxes like http://@example.com/ so you could create links that exclude IE users, should you be into that sort of thing for fun or profit.

Finding SQL Injection with Scrawlr

 Yes, we know that other blogs on this issue have included this comic, but it's just too perfect to not reference it


You have likely been tracking the mass SQL Injections that are currently sweeping through the net. Just last night I was shopping on www.ihomeaudio.com when I noticed they had been injected (they have since fixed their site). HP started to observe these attacks in January. They spread to over 500,000 sites by April before calming down and then picking up again in May. Most of the sites hit were initally Microsoft IIS ASP applications, causing many security companies to mistake this for some sort of new vulnerability in IIS and leading Microsoft to research the possibility, but alas, it's just our old friend, SQL Injection. Indeed we now see this attack hitting ASP and PHP sites and thanks to Google, it's easy to see just which sites out there have been hit.


While we were closely following the situation, the nice folks at Microsoft contacted us to see if we could work together to help people identify and cope with this issue. Together we quickly developed an action plan. The Microsoft Security Response Center (MSRC) was in a tough spot, hundreds of thousands of ASP sites were getting hacked, yet the vulnerability wasn't something Microsoft could release a patch for. SQL Injection is an issue that occurs because of poorly written web code interfacing with the web sites backend database and the solution was much more complicated than a simple patch. Developers were going to have to learn about security and were going to have to patch their code if they were going to solve this. Microsoft's Security Vulnerability Research & Defense has a blog about this problem as well where they share Microsoft's recomendations for this problem.


Now if you are no stranger to web security, you might be saying "well duh" right about now. Unfortunately to at least 500,000 sites on the Internet this concept is still pretty new and if you are one of the folks who are just now learning what SQL Injection is, I highly recomend you read HP's Web Security Research Group white papers on verbose and blind SQL injection located in our HP application security resource library.


Introducing HP Scrawlr



 



When Microsoft contacted us, they asked us to equip their customers with the tools necessary to quickly find SQL Injection vulnerabilities in their sites. HP's application security software, DevInspect, QAInspect and WebInspect all find SQL Injection and countless other security vulnerabilities. DevInspect can even inspect your source code for SQL Injection as well and guide developers through the process of fixing their code. But what if you need to just quickly look for SQL Injection before you decide how you are going handle the issue? We needed something quick, highly accurate and easy to download and install.


Scrawlr, developed by the HP Web Security Research Group in coordination with the MSRC, is short for SQL Injector and Crawler. Scrawlr will crawl a website while simultaneously analyzing the parameters of each individual web page for SQL Injection vulnerabilities. Scrawlr is lightning fast and uses our intelligent engine technology to dynamically craft SQL Injection attacks on the fly. It can even provide proof positive results by displaying the type of backend database in use and a list of available table names. There is no denying you have SQL Injection when I can show you table names!


Technical details for Scrawlr



  • Identify Verbose SQL Injection vulnerabilities in URL parameters

  • Can be configured to use a Proxy to access the web site

  • Will identify the type of SQL server in use

  • Will extract table names (verbose only) to guarantee no false positives


Scrawlr does have some limitations versus our professional solutions and our fully functional SQL Injector tool



  • Will only crawls up to 1500 pages

  • Does not support sites requiring authentication

  • Does not perform Blind SQL injection

  • Cannot retrieve database contents

  • Does not support JavaScript or flash parsing

  • Will not test forms for SQL Injection (POST Parameters)


Download Scrawlr


You can download Scrawlr by visiting the following link: https://h30406.www3.hp.com/campaigns/2008/wwcampaign/1-57C4K/index.php?mcc=DNXA&jumpid=in_r11374_us/en/large/tsg/w1_0908_scrawlr_redirect/mcc_DNXA.


Scrawlr is offered as-is and is not a supported product. Assistance may be available from other Scrawlr users in our online Scrawlr forum located at http://www.communities.hp.com/securitysoftware/forums/198.aspx.


You can learn more about the HP Web Application Security Group and the HP Application Security Center by visiting our Security Community site at www.communities.hp.com/securitysoftware/ or by visiting our product information page at www.hp.com/go/securitysoftware/

Search
About the Author(s)
Follow Us


HP Blog

HP Software Solutions Blog

Labels
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation