Category: IT Optimization
Why Click Fraud Matters
Spending on Internet advertising in the US alone eclipsed $10 billion in 2010. Unfortunately, online sponsored advertising has a major downside: Click Fraud. Industry rivals, or other interested parties impersonate consumers by clicking on paid ads with no intent of making a purchase. These fraudulent clicks effectively drive up a company’s advertising costs without increasing sales. Click Fraud has become such a widespread issue that in the eyes of LinkShare CEO Stephen Messer, it “could wipe out ROI in search marketing.”
Initially, advertisers placed their trust in search companies such as Google, Yahoo and Microsoft to police fraudulent clicks. In 2006, Google CEO Eric Schmidt compromised that trust when he stated:
“Eventually the price that the advertiser is willing to pay for the conversion will decline because the advertiser will realize that these are bad clicks. In other words, the value of the ad declines. So, over some amount of time, the system is, in fact, self-correcting. In fact, there is a perfect economic solution, which is to let it happen.”
His statement led many companies to question the commitment of their providers to preventing Click Fraud.
At the heart of Click Fraud is the act of simulating a click. This is accomplished through multiple means. The simplest is to employ individuals who spend their time clicking on ads without ever purchasing an item. This act is both costly and time consuming if done inside the United States. In developing countries, this is not the case. In the words of Nir Kshetri, the fraudster “must often decide to employ the seemingly bottomless source of human clickers in developing countries, or use technology.” Kshetri goes on to point out that employing human labor becomes less attractive as PPC providers and advertisers become more adept at employing invalid click detection. Because the IP address of a human clicker is usually consistent, PPC providers can easily block traffic from it.
Another method for performing fraud is to write a program that simulates clicks. To do this, the program must perform many tasks normally undertaken by a web browser. The program must first execute JavaScript code to retrieve the HTML code of a web advertisement. It then parses the HTML code for links and sends an HTTP request to the advertiser’s web server. Since this type of fraud is simple to detect, the perpetrator must distribute the program across the Internet using a botnet. The botnets find their way onto unsuspecting users’ computers through many means. Tempting offers of free software, games or other goods from illegitimate websites lure many consumers into loading botnets unknowingly. Computers can also be infected by visiting legitimate websites that have been compromised by Click Fraudsters.
Unlike many other online crimes, Click Fraud has no offline counterpart. One impact of Click Fraud is that the legal system has not been able to keep pace with it. Online crime is growing at a rapid rate that legislators have been unable to match. Adding to the problem is a lack of regulation across borders. While new antifraud laws are slowly being passed in the United States and the European Union, other countries have little or no regulation. In India in 2006; for example, advertisements looking to hire people to click on ads ran in national newspapers.
As an industry, online advertising is not going away anytime soon. Click Fraud will not be going away either. Given my background in law, it is obvious to me that just like with other legal issues regarding technology, legislators cannot keep up with the rapid pace with which Click Fraudsters change their tactics. Add in the challenges of enforcing laws across international borders and the problem becomes even direr. It is therefore obvious that legal changes will not come soon, so other methods are necessary. With legal recourses lagging behind, it is up to industry to find ways to protect itself.
The Benefits of Logging Disk Space Warnings or Errors
Disk capacity requirements will vary depending on the purpose of the associated system and applications utilizing the storage space. When there is no longer any free disk space available, the effect can be minor to border-line catastrophic. And a catastrophic failure usually means that no remote access can be made to free up storage space and any resident applications will most likely be negatively impacted the inability to write disk. These types of situations can be caused by a number of circumstances and should be monitored from an operations, audit, and security perspective. Most environments will be a mixture of operating systems and devices and some may not provide this type of monitoring “out of the box”, requiring a third-party add on or a scripted process.
With Windows distributions (and some Linux), free disk space can be monitored and logged for subsequent alerting. Below are references to what needs to be configured to monitor disk free space.
Windows:
Open the registry, navigate to the following key and edit to define the specific percentage (DWORD value) of free disk space available before the OS writes to the SYSTEM Event log:
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\DiskSpaceThreshold
The default value (even if this parameter isn’t defined) is 10%.
NOTE: This will only be logged once until free space is made available and will log again if it drops back below the defined threshold.
Windows 2003 can also be set to log to the SYSTEM Event log when the percentage of free disk space falls below a defined threshold value (in MBs).
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\LowDiskSpaceMinimum
The default value is 400 MB. This will log frequently until free space is made available and above the defined threshold.
Linux:
Depending on the various make/distributions, this is typically done via a scheduled script that will perform this validation and if need be log to syslog or send a mail message to an appropriate recipient.
The process to perform this is typically a scheduled CRON job that executes a Perl script to assess the free space of the mounted disks. The script is usually named “diskcheck” and is configured by editing the file located here: /etc/diskcheck.conf.
Regardless of what operating system or device, if it’s possible to monitor the amount of free disk space and log the event, it can potentially remove the need for time-consuming recovery efforts. This frees up IT and support resources and ensures a high-percentage of uptime and system/application availability.
New Data Breach Study Shows Over 806.2 Million Records Disclosed, Estimated Cost of $156.7 Billion
In Digital Forensic Association’s report The Leaking Vault 2011, they estimate data breaches cost organizations over $157 billion dollars between 2005 and 2010 with the theft of over 806.2 million records. Additionally, these are low estimates given incidents are under reported, many reports did not include financial lost estimates, and the estimates did not include any financial ramifications beyond the actual data lost (impact to customers, interruption to productivity, impact to IT, etc).
The report acknowledges that criminal or malicious motivation in attacks makes for more expensive breaches and that the incidents of malicious insiders are increasing.
This brings up an interesting recommendation from the report, “The most important recommendation for this vector is know where your data is” (emphasis theirs).
Given the financial motivations behind a breach and the methods used to gain breach, this most sensible recommendation is to protect the target. This runs counter to most security practices to build protection around the network perimeter. Digital Forensic Association is recommending a step beyond best practices for a layered security approach. Even the report admits “This can be an enormous job for a large complex enterprise, but you must start somewhere”.
- What is considered valuable data to your enterprise?
- Where is this valuable data stored?
- Who should have access to this data?
- Who has access to this data?
- How can you track access?
Access logs are a critical part of recognizing who and when sensitive data has been touched, whether it was just looked at, copied, moved, or changed. However the collection of access logs will not protect the target. In fact, even with a log management system you may not even know you were breached. When a “bad guy” accesses sensitive data, they generally do not use a “bad guy” account. So they are going to use the account of someone who already had access. So the more interesting question is:
- Can you spot irregularities in access patterns?
What is an irregularity? Did a trusted account with correct credentials access your network from a location you do not normally operate in (China, Ukraine, Venezuela, etc). Or perhaps a trusted account logged in from a secure company location, but is also logged in from an external location. Is a trusted account with correct credentials using applications not normally used or sending traffic to locations not normally sent? Lastly, how could you detect these types of anomalies are occurring and take immediate if not automated action?
Whether through malicious code, insider threat, or external hack, breaches can occur to even the smallest companies and the financial motivation to do so is ever-growing. It is more important to begin a holistic, layered security method that takes into account not only detection of known malicious code or activity, but the recognition of threatening anomalous behavior.
Detecting and Defending against Insecure Direct Object Reference Vulnerabilities Using Log Data: Part 1
Understanding The Attack
The Open Web Application Security Project lists this type of attack as easy to exploit, and easy to detect. If that is the case, why then is this attack also listed as number four on their top ten of 2010 with a prevalence of common? Before we can dig into that enticing question, we should look at how a maneuver of this kind is carried out.
In its simplest form this vulnerability can be exploited by modifying a URL string with something like this:
http://vunerableSite.com/cms/accountInfo?LoggedIn=True&userID=45674 Your Account
http://vunerableSite.com/cms/accountInfo?LoggedIn=True&userID=45675 Not Your Account
Fun right? And there’s more fun to be had here. If you want to dig a bit deeper, load up your favorite proxy, poison some hidden parameters and you are on your way. What you will probably find is access to data the developer did not intend for you to see. These vulnerabilities seem to be most common right now behind one level of authentication, so log into the application you are testing first, and then twist data.
One would think that by now such easy web application hacks would rarely exist, emerging in conversations amongst veterans about the days of old. The reality however, as anyone who spends time researching web application vulnerabilities will likely tell you (and the OWASP top 10 of 2010 agrees), is that these Insecure Direct Object Reference Vulnerabilities (IDORV) are still common place. But enough on this easy attack, you found your hole, what’s next?
Level Two: Leveraging The Hole
Once an attacker has discovered a gap in your web app like this, they will likely script up to get to the next level. Using the previous example, we would write a script that cycled through a series of GET or POST requests, incrementing the poisoned parameter through values as necessary. The responses are then saved off and collected. The attacker may now have all possible data directly associated with the insecure object in question. In some cases this will be a lot of data that should not be accessible to any user.
OWASP lists these IDORV’s as easy to detect. But what did they have in mind? In my next post we will take a look at some of the different ways that I found to detect these kinds of attacks against your web applications using log data. Because many of the parameters in your GET and POST requests are not written to your web server logs by default we will have to looks for some other ways to observe this kind of behavior.
Closing the backdoor…
Closing the backdoor…
Today Mikko Hypponen from F-Secure announced they had retrieved and analyzed the excel file used to create a backdoor into RSA.
The attacker used a phishing attempt to send an excel file loaded with an embedded flash object to a recipient inside RSA. Once opened, the excel file used an advanced 0-day exploit executed by the embedded Flash object to create backdoor that allows full remote access to the infected workstation.
Certainly this brings up the obvious warnings of not opening strange attachments, etc. However, the reality is that spear phishing attempts work. This wasn’t even a case of a highly sophisticated spear phishing attack (you can see the original email on Mikki’s blog entry listed above). Examples of successful spear phishing, like the IMF breach and the Epsilon breach, highlight that we should not only continue to educate end users to recognize the red flags and the dangers of opening attachments, but be prepared for the inevitable human mistake.
If a user falls prey to a phishing attempt, and a 0-day exploit evades our endpoint security, what can we do?
- In this case, the backdoor opened connections to servers at mincesure.com that have been used in previous espionage attacks. Using an IP reputation list could have detected the initial connection and actions could have been taken to stop it.
- What if they hadn’t used a known IP address? If you can detect the IP address geo-location, you can see the location is Venezuela. Using geo-location could have detected irregular data traffic being sent to a uncommon destination.
- Or what if the location wasn’t interesting? Once the backdoor was established, having a mechanism to recognize which user accounts access files on the workstation could have identified abuse the system or other accounts.
- Maybe the user accounts had permission to the files. In that case it was the sequence of access to the files after the new connection to an unknown location had been created that could have registered that an attack was occurring.
While it’s important to continually educate our end users on attacks they can help prevent, as security professionals we must have safeguards for when mistakes are made. Although the attacks themselves may not be sophisticated, they can still bypass many of our traditional security solutions. However, with behavior analysis and pattern recognition we should be able to detect and prevent these types of breaches.
Tags: 0-day exploits, endpoint security, Epsilon Breach, F-Secure, hacking, IMF breach, IT security, logrhythm, network security, phishing, RSA
LogRhythm wins "Innovator of the Year" from SC Magazine. "This is not your father's log manager."