My previous column emphasized the most prevalent attack techniques used by hackers. By studying thse types of attacks we can enhance our solutions. Here’s how.
Remote File Inclusion as a case study
While Remote File Inclusion (RFI) is an often overlooked vulnerability, we saw that it’s actually one of the top four most prevalent attack techniques. Observing RFI attack traffic is a helpful task and a good example of how we can use these insights to enhance Web defense mechanisms. To recall, RFI uploads an attacker script. Traditionally, RFI detection is performed by matching the Web request against signatures of known vulnerabilities of common Web applications that may be vulnerable to RFI. The problem with this approach is that it works well for protecting popular applications with enough mileage that their security weaknesses were investigated and published. However, attackers may succeed in bypassing signature-based defenses by exploiting newly discovered vulnerabilities in Web applications or custom code. Now, consider the case where we know that a certain script is flagged as malicious. How about then matching a request to the application against signatures that test for that particular script? This enhancement is less application-specific and can be updated whenever an attack is detected in any set of sites. Another idea would also be to flag a source spewing a known attack technique as malicious when receiving other types of requests from this source. In fact, as shown in the last column, Directory Traversal (DT) is used in conjunction with RFI attacks as a reconnaissance stage. Flagging an attack source that used DT will also block future RFI requests coming from that source.
When Automation Goes Awry
Automation is a pillar of the hacker industry, making automated requests important to identify. The way hackers have leveraged automation is one of the most significant innovations in criminal history. You can’t automate car theft, or purse snatching. But you can automate data theft online. According to a recent Web Application Attack Report (WAAR), applications are probed by attackers about once every two minutes. However, when under a peak attack, applications suffer about 25,000 attacks per hour; roughly seven attacks per second. The high rate and frequency is a telltale sign that automation is being used.
Most of the automated attack traffic comes from compromised machines. Hackers employ these machines, which are known as bots, not only to hide their identity, but also to carry out more powerful and automated attacks. My previous column cited a LulzSec chat log that showed their plan to employ an 8,000 server-based botnet to conduct their RFI attack. Considering that one compromised server is equivalent to 3,000 PC-based bots, this was a forceful automated attack equivalent of 24 million PCs. The compromised machines spewing malicious automated attacks should be flagged as having a bad reputation. Certain communities such as Shadowserver.org supply details of bots. According to their stats, the number of active bots fluctuated this past year somewhere between 50,000 to 400,000.
But there’s more to automation. If you recall, just a couple of months ago USA Today reported on 8 million infected websites. These websites all ran the OSCommerce platform, which had a vulnerability that hackers were able to exploit. How did the hackers obtain a list of sites that might be vulnerable? Through Google! Using Google dorks, the attackers were able to conduct a distributed, yet coordinated, search for these attacks. And here’s the call for Google as they have such a wide view of traffic: use insights from suspicious queries to flag malicious sources. Search engines can use the IP blacklist to issue warnings to the registered owners of the IPs that their machines may have been compromised by attackers. Such a proactive approach could help make the Internet safer, instead of just settling for limiting the damage caused by compromised hosts.
The Value of Reputation-based Controls
Remember the RSA hack back in March? According to Uri Rivner's “Anatomy of an Attack” blog post, the attack involved three URLs: Good[DOT]mincesur[DOT]com | up82673[DOT]hopto[DOT]org | www[DOT]cz88[DOT]net. Security blogger Brian Krebs then noted that these URLs already earned the reputation of attack launch pads. The RSA hack was recently put in the spotlight again after security researchers found the email that contained the malware used to compromise the company’s data. The suspicious email was uploaded to VirusTotal – a database of known malware variants – to test its authenticity. Looking back, the researchers saw that this same email originated from 15 other unique addresses.
Reputation Controls – Not a single sign-off
|Part in a Series on Cybercrime - Read Noa's Other Featured Cybercrime Columns Here|
While we increasingly see the value of reputation-based controls in stopping attackers, hackers are becoming more aware of the deployment of these solutions and are finding ways to bypass them. Hackers often use different bots in an interchangeable fashion, where they switch bots every four to five hours. As such, these reputation-based lists must be maintained and constantly updated to continue being effective against attacks. Further discoveries from the Web Application Attack Report showed nearly 30% of attacks as coming from ten identifiable IP addresses. This underscores the importance of the role reputation controls can play.
Although reputation controls in Web attacks are a relatively new idea, we’ve actually seen them employed for years in a different domain – spam. Industry collaboration exists also in the fight against spam. Spamhaus.org, for example, is a popular site that maintains such blacklists which can be used to deny mail coming from known malicious sources. But IP blacklisting is not as black or white as it sounds. In fact, IP intelligence work needs to be put in place to correctly flag a malicious Web attack source. In my next column, I’ll discuss the scope of that work and what organizations should take into consideration.