Friday, November 18, 2011

Mass Joomla Component LFI Attacks Identified

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.

Screen shot 2011-11-17 at 10.27.01 AM

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: - - [17/Nov/2011:17:48:15 +0900] "GET /index.php?option=com_bca-rss-syndicator&controller=../../../../../../../../../../../../../../../../../../../../../../../..//proc/self/environ00 HTTP/1.1" 404 224 - - [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)" - - [17/Nov/2011:10:14:27 +0900] "GET /index.php?option=com_cvmaker&controller=../../../../../../../../../../../../..//proc/self/environ00 HTTP/1.1" 404 216 - - [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 AttacksIP AddressCountry CodeCountry NameRegionRegion NameCity
8674.50.25.165USUnited StatesCACaliforniaAnaheim
58180.151.1.68INIndia07DelhiNew Delhi
5167.23.229.237USUnited StatesNYNew YorkNew York
4264.92.125.26USUnited StatesCOColoradoDenver
38174.122.220.10USUnited StatesTXTexasHouston
3672.47.211.229USUnited StatesCACaliforniaCulver City
33122.201.80.95AUAustralia02New South WalesSydney
32174.37.16.78USUnited StatesTXTexasDallas
3164.13.224.234USUnited StatesCACaliforniaCulver City
27109.75.169.20GBUnited Kingdom
2565.98.23.170USUnited StatesCACaliforniaSan Francisco
24193.106.93.131RURussian Federation
1050.73.66.4USUnited States
9173.245.78.42USUnited StatesCACaliforniaFremont

Joomla Components Targeted

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



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.

Sunday, August 7, 2011

What Web Application Security Monitoring Can Learn From Casino Surveillance

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:

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.