This is the second part in a series of posts here at StopTheHacker where we describe the various methods that malicious hackers use to infect benign and legitimate websites with web-malware.

This time, we will discuss one of the most prolific techniques used to compromise millions of websites: Cross Site Scripting. Cross Site Scripting attacks have been seen for many years now and remains a continuing threat. In fact, by the latest statistics, more than 75% of websites have at least one Cross Site Scripting vulnerability.

It is no wonder that thousands of sites are compromised every single day, only to infect their unsuspecting visitors and end up on blacklists. In this article, we will delve into detail on Cross Site Scripting, how to identify vulnerabilities, how to stop them from being exploited, and more.

What is Cross Site Scripting?
Cross Site Scripting is a an attack wherein a hacker exploits vulnerabilities in the software powering a website to launch an attack on the user. The attack can range from the display of a fake Anti-Virus advertisement to an unsuspecting user, all the way to a sophisticated port scan run using an injected toolkit.

Cross Site Scripting is primarily used to forward users to a URL that looks genuine, and is in fact pointing to a legitimate business website. However, when the user visits the URL in a browser, the content displayed is from a malicious source that can compromise and infect the visitor.

An important point to understand: Cross Site Scripting is not the same as Phishing. Phishing is the attempt to deceive someone that a web page actually belongs to a bank (or a similarly important institution), when it does not, in order to steal credentials.

Cross Site Scripting attacks direct users to a legitimate website with malicious content loaded from malicious sources. Cross Site Scripting attacks help hackers set up phishing campaigns and can be used as a tool to enable these malicious activities.

What is XSS?
XSS is an abbreviation for Cross Site Scripting. Some people also refer to Cross Site Scripting as CSS, though this conflicts with the more popular abbreviation of CSS, Cascading Style Sheets, a widely used term in web technology. XSS is less ambiguous abbreviation for Cross Site Scripting.

What is a code injection attack?
A code injection attack is an unwarranted effort to load malicious computer code onto a website, by exploiting weaknesses in the software that is powering the website or by other means, such as compromised passwords (FTP etc).

This attack usually manifests itself when a malicious hacker identifies a particular weakness in the way a website handles user input and exploits that weakness to load the malicious computer code, infecting the web pages on the website. This allows the malicious hacker to (1) steal information from the compromised website (2) infect visitors visiting the compromised website and more.

What kind of vulnerabilities allow XSS attacks to happen?
XSS attacks occur primarily due to improper sanitization of user input. Consider the case where a hypothetical website has a form on a webpage that accepts a user’s email address to send a newsletter to them.

The web application that process the email address might not have been well constructed. Due to defects in the computer code that accepts the input from the user and processes it, a hacker may be able to run their own malicious computer code. It is very important to ensure that user input is not trusted implicitly. Validation must be performed on all user input to verify that the data is benign.

What are the major types of XSS attacks?
There are two primary types of XSS attacks: Persistent XSS and Reflected XSS. Persistent XSS attacks lead to the injection of malware onto the webpages of a weakly secured website where it is stored. Reflected XSS attacks are often used to make the weakly protected website act as a vehicle for malicious actions, while there is no real malware stored on the webpages (hence the name reflected).

Persistent XSS Attack Example
A malicious hacker realizes that an input form, such as a password field is not properly sanitizing its input, tries to exploit it, succeeds and then is able to permanently store malware on the website by infecting its webpages.

Consider that the input form might be expecting the user to provide an email address for a newsletter subscription, but the hacker puts in a email address and then also attaches computer commands to the email address. Weakly secured code in the web application analyzes this input, stores the email address, and then runs the other commands that the hacker included. This can allow the hacker to load malware onto the webpages.

Reflected XSS Attack Example
A malicious hacker identifies the various fields accepted as user input and attaches malicious commands as the values to be submitted for some or all of the fields in order to cause the web server to display (reflect) the malware back to the unsuspecting user who clicked the malware laced link.

In this scenario, the malware is self-contained inside a HTTP link. This attack succeeds since most users are used to clicking on link URLs without checking the actual contents of the URL. Malicious hackers are banking on this. These malicious links can be distributed via email, and once a user clicks on the link, the web server of the legitimate, but insecure website, is used to display the malware contained in the link to the user via the browser that the user is using to view the malicious link.

Another XSS Attack Example
Consider a website that has URLs of the following type:

http://www.yoursite.com/index.html?name=Alex

Let us say the parameter “name” is used to define name values for the user. The website uses this value to say “Hello Alex” on the webpage. In this example, a malicious hacker can exploit the parameter “name” by attaching malware information to the parameter “name” instead of the expected name as below:

http://www.yoursite.com/index.html?name=<script>alert('XSS vulnerability')</script>

This shows a message box to the user displaying the words ‘XSS vulnerability’, but in reality, actual malware code could have been loaded via this exploit on a website employing the same technique.

This attack succeeds because the web application that analyzes this URL and powers the website, incorrectly trusts the user to always input safe data. It is not be prepared for threats like this. In this case, a malicious hacker has used a benign website to launch a malware attack on an unsuspecting customer, and the website owner usually has no idea that his or her website was exploited.

How to detect if your site is vulnerable to XSS attacks?
There are many ways to check if your website is vulnerable to XSS attacks:

1. Find out if any of the software powering your website takes user input directly and uses it directly, without sanitizing it. For example: can a user attach a semicolon, colon, or bracket symbol in the text they are providing to the website as input, and have these special characters displayed back to them un-escaped?
2. Find out if the software that powers your website is out of date. If it is, apply all recommended patches or upgrade to the latest version of the software.
3. Find out if the third party plugins that your website employs, are at risk to XSS attack vulnerabilities.
4. Conduct a vulnerability assessment scan of your website to find out if there are any XSS vulnerabilities that are identified. Any vulnerabilities should be fixed as soon as possible.
5. Use a Web Application Firewall (WAF) and a Firewall to prevent malicious access to the website.

Conclusion
XSS is a popular vector for malicious hackers to exploit and infect websites. We have seen what XSS is, how it is used by hackers, and how to protect your website.

StopTheHacker.com customers have access to resources and services that protect them against these kind of threats and help them recover from compromises should they occur. If you want to protect your website right now visit our services page.

Report, Security cross site scripting, malware, scripts, securityvulnerability, XSS

Services like Posterous have changed the way Internet users post information about themselves, their likes, and their dislikes. Posterous follows a very simple model.

A user simply needs to send an email to post@posterous.com and they can attach files, such as music that they like, and post it to their personal page. Its very easy to use. You can literally create your own page with a single email. Posterous has already chalked up thousands of avid users.

Motivation
The goal of this article is to highlight how a service like Posterous needs to harden itself against misuse by malicious individuals and groups. We will be exploring some of the potential loopholes of the posterous model. We will not be discussing or revealing any exploit code.

Exploring this facet of services like Posterous helps uncover the various attack surfaces that malicious entities can use to compromise such an excellent service. Through this exercise, perhaps we can help services like Posterous improve upon their existing architecture.

Methodology
We will use the following metrics to determine the safety of Posterous’s current service.

1. Can we post with an email where the originating server IP does not match the sender’s domain?
2. Can we post a malicious link (hyperlink)?
3. Can we post a malicious iframe?
4. Can we post a malicious script?
5. Can we post a malicious binary?

Before we proceed, we will outline how the experiment was set up. A new account was set up using an email sent to Posterous (by new account, we imply a new blog post, not a registered user account).

Once the blog post was created we analyzed the it to see if the content in the outgoing email to Posterous was actually present in the blog post. If the content was in the post, we analyzed it to see whether it was modified or not. The experiment was conducted on Friday, July 9, 2010.

Analysis
Now we will describe the results of some of the tests that we conducted.

1. Can we post with an email where the originating server IP does not match the sender’s domain? Yes
2. Can we post a malicious link (hyperlink)? Yes and No
   • For unregistered accounts, it seems that a hyperlink is prefaced with http://emailusername-kb3zz.posterous.com/ so a malicious link will not be triggered.
   • For registered accounts, it seems you can put up links without this prefix. We have confirmed posting of malicious links with examples from Malware Patrol, Google’s Safe Browsing List and others.
   • Update: Gary Tan from Posterous let us know that they are using link pre-filtering and will be expanding their capabilities by incorporating more lists. This is good to hear.
3. Can we post a malicious iframe? Yes
   In fact an iframe can be posted from non-registered mode. This is a mechanism that a bad guy might try to exploit (screenshot attached below, of course, its a benign iframe).
   • Update: Gary Tan from Posterous let us know that they prevent iframe posts from taking up the full page by sanitizing size attributes, mitigating the main problem with iframes.
4. Can we post a malicious script? No
   Posterous scrubs scripts attached to the email and does not let them post to the blog. It remains to be seen though, if any malicious encoding would allow a script get through.
5. Can we post a malicious binary? Not tested

Note: No malicious content (iframes, scripts, binaries) was ever uploaded to the blog during testing.

Conclusions
We have seen that there are some attack vectors which malicious entities could employ against services like Posterous as a tool to spread malware: primarily, the use of iframes and malicious links.

Even if Posterous begins to pre-filter links, as we have shown in a previous article (Analyzing URL Shorteners), these services are a thorn in the side of security policies. Unfortunately, as each new service like Posterous comes to life on the Internet, so do new attack vectors for malicious entities.

Till next time…

Update: Gary Tan from Posterous was kind enough to swiftly reply back to our questions and provide good information (Monday, July 12, 2010). Our findings have been updated appropriately.
Read more…

Report, Security iframe, posterous, sanitization', scripts