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.

Tag Injection vs. Cross-Site Scripting

As my last post pointed out, it is not necessary to actually modify the HTML on a page to cause Cross-Site Scripting. If the attack is reflected directly into JavaScript or a style tag/attribute, you can have Cross-Site Scripting through  JavaScript injection or CSS injection, without any extra HTML necessary.

XSS attack examples are usually given like

 

 

<script>bad stuff here</script>

 

 

Or

 

 

<img src=x onerror=”bad stuff!”>

 

 

…but what if the bad stuff isn’t actually script? If you blacklist <script> tags and event attributes, you may prevent a textbook XSS attack, but that doesn’t mean you’re safe. An attack that injects an <iframe> tag could be used for clickjacking, where a user could click on a hidden link or button (in the invisible iframe) when trying to click on a visible link or button “below” the hidden frame. Something as seemingly safe as an <img src=”/relative/path”> tag could be used for a Cross-Site Request Forgery attack, if the site is vulnerable (in which case, you should probably fix your CSRF vulnerability!).

 

A common reason why someone might want to use a blacklist to filter out XSS attacks but allow other HTML tags is to allow simple tags such as <b>, <i>, and <u> for formatting. If that’s the case, a safer approach may be to use a language specifically designed for this case, like some variation of BBCode. While such languages have occasionally had XSS problems, it’s generally safer to only allow a specific set of formatting options (whitelist) than to only try to filter out “dangerous” looking tags (blacklist). If possible, don’t allow embedding images directly through an [img] tag, unless you can restrict it to a specific directory or image library.

 

It’s important to understand the distinction between HTML Tag Injection and Cross-Site Scripting, as either one can exist without the other, and still cause grief. Guarding against both is important to keeping your site secure.

 

Users of WebInspect should note that WebInspect will send HTML Tag Injection attacks only after all Cross-Site Scripting attacks have failed. If you see HTML Tag Injection (check ID 10044) in your scan results, it means we were not able to execute script to verify an XSS attack, but were still able to modify the HTML. Don’t take this lightly just because it shows up as a “medium”! While it’s not as serious on its own, it could still lead to an attack if not dealt with.

Context Matters for Cross-Site Scripting Filters

During a recent pen-testing exercise, Cross-Site Scripting (XSS) was as usual the most common issue found. Some sites had issues numbering in the hundreds (with nearly every parameter on every page being vulnerable). This should no longer be surprising to anyone; XSS has been one of the most common vulnerabilities for years. What was most interesting was that in several of these cases, the web site in question was doing very effective HTML filtering. They were either completely stripping all HTML tags, doing some crazy parse-and sanitize routine, or some other filtering that would make a traditional XSS attack impossible. However, these pages were still vulnerable. Why? They were reflecting parameters inside of JavaScript, where different rules apply.

 

When a parameter is reflected inside of JavaScript, an attacker no longer needs to inject an HTML tag to execute script. After all, a script is already being executed. It’s usually only a matter of using one or two characters to break out of the current statement to begin executing arbitrary code. Consider the following simple case:

 

http://example.com/news.php?date=2010-01-01

...

news.php:

<script>
make_ up_some_news('<?php echo strip_tags($_GET["date"]); ?>');
</script>

 

PHP's strip_tags() would remove a traditional XSS attack of the form “<script>alert('XSS');</script>”, but no tags are needed here. http://example.com/news.php?date=');alert('XSS');// will execute script without needing < or >. Even PHP’s htmlspecialchars() would not fix this, unless it was also passed ENT_QUOTES, as it will allow single quotes to pass through by default. HTML only defines the following characters as “special”, which could break the flow of the page:

 

Character

Description

"

quotation mark

'

apostrophe 

&

ampersand

less-than

greater-than

 

To protect a reflection in JavaScript, you would need to filter out newlines, semicolons, curly braces, square braces, parenthesis, and nearly every other non-alphanumeric symbol, depending on where the parameter is being reflected. Reflecting a parameter inside of a <style> tag or attribute has similar problems. It’s not necessary to use angle brackets inside of CSS in order to execute JavaScript, fetch a remote URL, or do other potentially dangerous things.

 

Of course, any list of “dangerous” characters or sequences runs the risk of being non-comprehensive. By far the safest and easiest way to protect yourself is to use a whitelist-style filter instead of a blacklist-style one. Whitelisting involves accepting only what is ‘good’ instead of trying to reject everything that is bad.  Instead of using strip_tags, in this case, try to parse the input as a valid date matching the yyyy-mm-dd pattern you expect. If you’re expecting an integer, require an integer, etc. If it doesn’t match, throw an error. This is not a time to be liberal with what you accept (and reflect)! If these pages were only accepting input in a specific format instead of trying to remove “dangerous” characters or sequences, there would not be a problem, regardless of where it was being reflected.

ASP.NET Cross-Site Scripting Followup: Mono

While doing the research that led to my recent post on ASP.NET view state as a vector for XSS, I discovered that while Microsoft's implementation is secure by default, Mono was not.


The default for a Page's EnableViewStateMac property is true in Microsoft's .NET Framework (despite what some documentation says). In Mono, this defaulted to false. In addition, there were certain problems with configuration which made it more difficult to mitigate this vulnerability:


In web.config, setting:



<system.web> <pages enableViewStateMac="true" />


did not enable view state signing. Neither did setting



<%@ Page EnableViewStateMac="true" %>


inside a page's .aspx file. While these two may be considered ordinary bugs and not directly a security problem, they made it much more difficult to work around the problem for existing installations.


Although Mono's view state format is somewhat different from Microsoft's, it was possible to port the exact same attack I used on Microsoft's ASP.NET to Mono by changing the data structure slightly and using Mono's serializer.


The following link will display a Javascript alert when running the XSP sample project on Mono 2.6.3: http://localhost:8080/2.0/menu/menu1.aspx?__VIEWSTATE=DAwNEAIAAA4BBQEOAQ0QAg8BAQlpbm5lcmh0bWwBJzxzY3JpcHQ%2BYWxlcnQoJ0FTUC5ORVQgWFNTIScpOzwvc2NyaXB0PhAAAAAOAAAA


Affected Versions


Mono 2.6.3 and older


Fixed Versions


Mono 2.6.4
Fixes for older branches should be committed soon


Other info


http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1459
http://www.mono-project.com/Vulnerabilities#ASP.NET_View_State_Cross-Site_Scripting

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.

Top Five Web Application Vulnerabilities 5/12/09 - 5/25/09

1) Novell GroupWise WebAccess Multiple Security Vulnerabilities


Novell GroupWise WebAccess is susceptible to multiple vulnerabilities including Cross-Site Scripting and issues of security restriction bypass. Attackers who successfully exploit these vulnerabilities could steal cookie-based authentication credentials, and gain access to sensitive information.   Updates which resolve these vulnerabilities have been released. Contact the vendor for additional information.


http://www.securityfocus.com/bid/35066
http://www.securityfocus.com/bid/35061


2) Sun Java System Portal Server Error Page Cross Site Scripting Vulnerability


Sun Java System Portal Server is susceptible to a Cross-Site Scripting vulnerability. If successful, Cross-Site Scripting can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on end user systems. Updates which resolve these vulnerabilities have been released. Contact the vendor for further details.


http://www.securityfocus.com/bid/35082


3) Sun Java System Communications Express Multiple Cross-Site Scripting Vulnerabilities


Sun Java System Communications Express is susceptible to multiple instances of Cross-Site Scripting. Cross-Site Scripting occurs when dynamically generated web pages display user input, such as login information, that is not properly validated, allowing an attacker to embed malicious scripts into the generated page and then execute the script on the machine of any user that views the site. Updates which resolve these issues have been released. Contact the vendor for more information.


http://www.securityfocus.com/bid/34154
http://www.securityfocus.com/bid/34155


4) HP System Management Homepage Unspecified Cross Site Scripting Vulnerability


HP System Management Homepage is susceptible to an unspecified Cross-Site Scripting vulnerability. An attacker can leverage Cross-Site Scripting to execute script code in the browsers of unsuspecting users in context of the affected application, possibly leading to theft of authentication credentials and other attacks. Updates which resolve this issue have been released. Contact the vendor for additional details.


http://www.securityfocus.com/bid/35031


5) phpMyAdmin 'setup.php' PHP Code Injection Vulnerability


phpMyAdmin is susceptible to a PHP Code Injection vulnerability. An attacker can leverage this vulnerability to inject and execute arbitrary malicious PHP code in the context of the web server process, which could lead to a compromise of the application and underlying system.  Updates which resolve this issue are available. Contact the vendor for further information.


http://www.securityfocus.com/bid/34236

Top Five Web Application Vulnerabilities 4/28/09 - 5/10/09

1) Multiple Symantec Products Log Viewer Script Injection Vulnerabilities


Multiple Symantec Products are susceptible to browser-exploitable script injection vulnerabilities due to improper sanitization of user-supplied input used in dynamically created content.  Successful exploitation would give an attacker the means to steal cookie-based authentication credentials, or simply alter how the site appears.  Other attacks are likely possible.  Updates which resolve these issues have been released. Contact the vendor for additional details.


http://www.securityfocus.com/bid/34669


2) Citrix Web Interface Unspecified Cross-Site Scripting Vulnerability


Citrix Web Interface is susceptible to a Cross-Site Scripting vulnerability.  If successful, Cross-Site Scripting can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on end user systems. Updates which address this issue have been released. Contact the vendor for more information.


http://www.securityfocus.com/bid/34761


3) IceWarp Merak Mail Server Multiple Vulnerabilities


IceWarp Merak Mail Server is susceptible to multiple vulnerabilities including SQL Injection, Cross-Site Scripting, and other input validation issues. If exploited, these vulnerabilities could lead to compromise of the application, the theft of confidential information and authentication credentials, or be utilized in conducting additional database attacks. Updates which resolve these issues have been released. Contact the vendor for further information.


http://www.securityfocus.com/bid/34820
http://www.securityfocus.com/bid/34825
http://www.securityfocus.com/bid/34827
http://www.securityfocus.com/bid/34823


4) GlassFish Enterprise Server Multiple Cross-Site Scripting Vulnerabilities


GlassFish Enterprise Server is susceptible to multiple Cross-Site Scripting vulnerabilities. Cross-Site Scripting occurs when dynamically generated web pages display user input, such as login information, that is not properly validated, allowing an attacker to embed malicious scripts into the generated page and then execute the script on the machine of any user that views the site.  Updates which resolve these issues are available.  Contact the vendor for additional information.


http://www.securityfocus.com/bid/34824


5) Jetty Cross-Site Scripting and Information Disclosure Vulnerabilities


Jetty is susceptible to a Cross-Site Scripting and an information disclosure vulnerability. These vulnerabilities could be exploited to execute code in the browser of an unsuspecting user, steal cookie-based authentication credentials, or access sensitive information.  A fix which resolves these vulnerabilities has been released. Contact the vendor for more details.


http://www.securityfocus.com/bid/34800

Top Five Web Application Vulnerabilities 4/13/09 - 4/26/09

1) Apache Geronimo Application Server Multiple Remote Vulnerabilities


Apache Geronimo Application Server is susceptible to multiple vulnerabilities including Cross-Site Scripting, HTML Injection, directory traversal, and Cross-Site Request Forgery.   Successful exploitation could give an attacker the means to access sensitive information, steal cookie-based authentication credentials, and perform actions as an authenticated user. An update which addresses these vulnerabilities has been released. Contact the vendor for more information.


http://www.securityfocus.com/bid/34562


2) SAP cFolders Cross-Site Scripting and HTML Injection Vulnerabilities


SAP cFolders is susceptible to Cross-Site Scripting and HTML Injection vulnerabilities. Successful exploitation could give an attacker the means to steal cookie-based authentication credentials, execute arbitrary code in context of the site, or simply alter how the site appears. Updates which resolve these issues are available. Contact the vendor for more details.


http://www.securityfocus.com/bid/34658


3) CS Whois Lookup 'ip' Parameter Remote Command Execution Vulnerability


CS Whois Lookup is susceptible to a remote command execution vulnerability.  Remote attackers can exploit this vulnerability to execute arbitrary commands with the privileges of the affected application, possibly leading to its compromise as well as that of the underlying web server.  A fix has not yet been released. Contact the vendor for additional information.


http://www.securityfocus.com/bid/34700


4) phpMyAdmin Configuration File PHP Code Injection Vulnerability


phpMyAdmin is susceptible to a remote PHP code-injection vulnerability. An attacker can leverage this vulnerability to inject and execute arbitrary malicious PHP code in the context of the webserver process, which could lead to a compromise of the application and underlying system.  Updates which resolve this issue are available. Contact the vendor for more information.


http://www.securityfocus.com/bid/34526


5) Novell Teaming User Enumeration Weakness and Multiple Cross-Site Scripting Vulnerabilities


Novell Teaming is susceptible to multiple Cross-Site Scripting vulnerabilities and a user enumeration weakness. These vulnerabilities can be exploited to discover the names of legitimate users, execute code in the browser of an unsuspecting user, and steal cookie-based authentication credentials. Advisories with patch instructions have been issued. Contact the vendor for further details.


http://www.securityfocus.com/bid/34531

XSS+phishing in Italian bank hack

Netcraft is reporting today about a phishing attack leveraging XSS  against an Italian bank. From the article (emphasis mine)

An extremely convincing phishing attack is using a cross-site scripting vulnerability on an Italian Bank's own website to attempt to steal customers' bank account details. Fraudsters are currently sending phishing mails which use a specially-crafted URL to inject a modified login form onto the bank's login page.

This attack highlights the seriousness of cross-site scripting vulnerabilities on banking websites. It shows that security cannot be guaranteed just by the presence of "https" at the start of a URL, or checking that the browser address bar contains the correct domain name.

Cross-site scripting vulnerabilities on SSL sites also undermine the purpose of SSL certificates - while the attack detailed here injects external content via an IFRAME, it is important to note that a malicious payload could also be delivered solely via the vulnerable GET parameter. In the latter case, any SSL certificate associated with the site - included Extended Validation certificates - would display a padlock icon and apparently assure the user that the injected login form is genuine.


If this sounds familiar, it should. I gave a talk at Toorcon 2005, the Phuture of Phishing. This focused exclusively on current phishing techniques and defense and how XSS vulnerabilities takes phishing to a completely new level. From the slide 24 of the preso:


  • Current Phishing attacks revolves around deceiving the user into think a website is a different website.
  • Current Phishing defense revolves around:
    • Applications preventing HTML from deliberately hiding functionality or actions of links and script
    • Determining fundamental stats about a site to see if it truly is the site it claims to be
  • But what happens if the phishing site was the actual website?


Exactly! XSS vulnerabilities turns a banks website into the phishing site. SSL certs, reputation systems, DNS checks, blacklists, and other phishing defenses utter fail to handle XSS+phishing.

I'm certainly not the only one banging this drum. Jeremiah Grossman predates me by a few months with a good presentation about XSS+phishing. I've had a friendly battle running with Lance James for a few years now about the role of local malware vs. website XSS in the future of phishing.

This certainly isn't the first XSS+phishing attack reported in the press. It wouldn't be the last. Hopefully attacks like this will raise awareness about the dangers of XSS. Remember, XSS isn't just cookie theft, or just key logging, or just page vandalism; XSS is complete client-side code execution!

Labels: hacked| phishing| XSS

SPI Labs advises avoiding iPhone feature

The Apple iPhone’s Safari web browser has a special feature that allows the user to dial any phone number displayed on a web page simply by tapping the number. SPI Labs has discovered that this feature can be exploited by attackers to perform various attacks, including: 

  • Redirecting phone calls placed by the user to different phone numbers of the attacker’s choosing
  • Tracking phone calls placed by the user
  • Manipulating the phone to place a call without the user accepting the confirmation dialog
  • Placing the phone into an infinite loop of attempting calls, through which the only escape is to turn off the phone
  • Preventing the phone from dialing 

These types of attacks can be launched from a malicious website, from a legitimate website that has Cross-Site Scripting vulnerabilities, or as part of a payload of a web application worm. 

For example, an attacker could determine that a specific website visitor “Bob” has called an embarrassing number such as an escort service. An attacker can also trick or force Bob into dialing any other telephone number without his consent such a 900-number owned by the attacker or an international number. Finally, an attacker can lock Bob’s phone forcing Bob to either make the call or hard-reset his phone resulting in possible data loss. 

SPI Labs researchers reported these issues to Apple on July 6 and are working with Apple to remediate the problems. However, SPI Labs recognizes the unique urgency of these issues and the large number of people that could be affected. As such, SPI Labs recommends that iPhone users do not use the built-in Safari browser to dial telephone numbers until Apple resolves these issues.

Labels: iPhone| Safari| XSS

Speaking at Shmoo

I’m really excited to be speaking at Shmoocon again and especially excited about my presentation this Saturday at 1pm. Javascript Malware for a Gray Goo Tomorrow focuses on the increased scope of damage caused by Cross-Site Scripting (XSS) vulnerabilities in the last year. The Web 2.0 revolution has been built on the back of standards compliant browsers and enhancements to the JavaScript language. This homogenous platform, coupled with JavaScript’s new features has enabled attackers to perform advanced attacks using XSS that were thought to be impossible even 2 years ago. Self-propagating XSS+Ajax worms, advanced keystroke and mouse loggers, port scanning, fingerprinting, and assaulting intranet applications, as well as stealing search engine queries or browser histories are now all components in an attackers toolbox.

The first part of my presentation will provide an overview of all these new advanced threats. Specifically, how this attacks work and how they can be prevented. In the second half I’ll discuss how JavaScript is capable of crawling and auditing 3rd party websites just like a traditional web scanner. As a proof of concept, I created Jikto, a web scanner written in JavaScript. Although I will not be releasing the source code of Jikto, I will be giving a full live demo and provide a detailed discussion about its methodology and architecture. The purpose of this public discussion and demonstration is to raise awareness of the danger of a XSS vulnerability and educate web developers and administrators on how to create websites securely. The biggest tragedy of all would be if a developer decides to put off fixing a XSS vulnerability because they weren’t aware of all the damage that could be done.

I really believe people are going to see some cool tricks, learn more about how attackers are using the often misunderstood JavaScript to perform sophisticated attacks, and leave with the knowledge to design, code and deploy secure websites. Hope to see you all there!
Search
Showing results for 
Search instead for 
Do you mean 
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