3 posts from July 2013
July 25, 2013
 What Can Happen On Your Watch? Exposing the SDLC Myth
Pin It

Sdlc1We’ve all seen it happen in the movies before. The security guard walks the hallways once an hour, looking for broken locks and open doors/windows. While he’s in between patrols, thieves break in through an unprotected air vent and steal the diamond.

Web application breaches aren’t much different. Besides a known vulnerability, they also require an opportunity, one that is ripe for exploiting.

In our Annual WAAR report that we just released, an interesting figure came up. For some of the applications we monitored for 180 days, attack attempts were observed for up to 176 days. That’s 98% of the time!

Is SDLC really solving your security problem?

Software development lifecycle (SDLC) is an ongoing process for companies, which includes a security element in the form of code review and vulnerability cleanup when a new version is released. While SDLC is a critical ongoing process, the security portion of it only comes at near the end, right before a version is finalized. However, In between releases, vulnerabilities and misconfigurations can be found.  

In an average organization, the security component of SDLC is designed to fix vulnerabilities as they’re discovered, either as a part of the release process of the software, or as new vulnerabilities are publicly found and reported. Schematically, the process looks like this:

  • A consultant/QA engineer/Automated Scanner finds and reports a vulnerability
  • A developer is assigned to create a patch to fix it
  • The patch is deployed in a staging area to validate it
  • The patch is deployed in production or towards the final release, all’s good

At best this process takes approximately 30 days.

Now, the fact that a vulnerability was found means that it existed on the application before it was found. According to data presented in WhiteHat’s Annual Report, it’s not uncommon for sites to be in a “pre-fixed” condition for about 150 days.

All told, there are roughly 180 days of exposure while the vulnerability is live.

What does this mean?

If the application is vulnerable for 180 days and it’s being attacked up to 98% of the time, hackers will find and exploit that vulnerability. It’s inevitable, really.

While SDLC helps to secure the application in the long run, it is done on periodic basis only, and requires a long window before the application can be fixed.

Organizations need a different approach to plug these gaps.

What should you do?

Banks no longer rely only on guards to do hourly patrols. In addition, they rely on alarms, window breach sensors, locks, and entry audits to protect their monetary assets. It’s time for companies to do the same thing to protect their digital assets.  

Here’s how:

  • Deploy a WAF which monitors application access and behavior in real time
  • Automated scanning to increase the velocity of security checks on new applications
  • Always patch systems to the latest patch and virtually patch 0-days


July 11, 2013
 Why One Employee Is Your Greatest Security Threat
Pin It

Security ThreatsToday’ most precious commodity is data. It’s in very high demand. And where there is demand, there’s a market just waiting for someone to capitalize on it. This goes a long way in explaining why advanced targeted attacks are becoming increasingly more sophisticated—and focused. It’s not unusual for hackers to target specific individuals within an organization to breach security perimeters. Only one user has to be compromised for an attacker to burrow into a company’s network and filch IP, deal data, legal documents, and more.

7 Steps of a Targeted Attack

Although the motivations for different attacks are many, their structure is often the same.

Step 1 – Size up the Organization

Hackers leverage social media to identify an individual within the targeted organization. For instance, LinkedIn is a fantastic tool for hackers to identify a database administrator at an organization, and then using the available contact information for spear phishing purposes.

Step 2 – Compromise a User

Through a spear phishing campaign, or an exploit of a vulnerability, hackers gain access to the compromised user's machine, and deploy malicious software that allows control and data gathering.

Step 3 – Login & Begin Initial Exploration

Using credentials obtained by a compromised user, cyber criminals can begin a reconnaissance of company data. A prize finding might be charts and illustrations of the network’s architecture. Just like that, a hacker has a blueprint for success.

Step 4 – Solidify Presence within the Organization

Hackers steal additional usernames and passwords, leveraging them to increase their efficiency. Now they can install back doors like phantom user accounts and gain entry to the network at a later time.

Step 5 – Impersonate a Privileged User

Because privileged users are closely monitored, a hacker will escalate permissions of compromised users to extend his reach throughout the datacenter. Greater reach means greater opportunity to uncover valuable data.

Step 6 – Steal Confidential Data

It’s every hacker’s favorite s-word. Yep, he can steal the data he wants, at a time of his own choosing.

Step 7 – Cover Tracks & Prepare for Return Visit

Like every criminal, a hacker will try to avoid detection by covering his tracks. This includes deleting interim accounts and log records, and resetting registry settings and returning escalated permissions. A clean exit is a prelude to a return visit at a later time.

How To Protect Your Data From A Targeted Attack

There’s an irony at work here. The datacenter often contains the most sensitive and important information. But it often has the weakest security controls in place. If valuable data is in such high demand, an improved security stance should be, too.

If you’re interested to learn more about protecting your organization from malware and targeted attacks, download our SlideShare presentation.


July 03, 2013
 Community Defense in the Wild
Pin It

With the announcement of SecureSphere version 10.0, Imperva added a crowd-sourced threat intelligence service that aggregates and validates attack data from WAFs to protect against hackers, automated clients, and zero-day attacks. We can then validate the data and stop attack campaigns in almost real-time. The “Community Defense” service has already proven successful in deterring new and original attacks when they strike the first time.

In a spirit of collaboration, our ADC team wants to share an example of a threat we have analyzed, researched and mitigated for the entire community.

This is an interesting case where the second that the vulnerability got announced, we were able to identify exploitation attempts coming from attackers around the world. Community Defense was able to mitigate the threat early on and keep our clients safe.

A Wild CVE is on the Prowl

On June 6 the “Parallels Plesk Panel phppath/php vulnerability” was publicly disclosed. According to Parallels and The Vulnerability Notes Database:

“Parallels Plesk Panel versions 9.0–9.2.3 on Linux platforms may be exploited by a combination of CVE-2012-1823 and the Plesk phppath script alias usage. There have been reports that this vulnerability is being exploited in the wild.”

In case you don’t know, CVE-2012-1823 is a vulnerability in php-cgi, enabling remote attackers to execute arbitrary code by placing command-line options in the query string. For example, if the URL is requested and php is configured to work in cgi mode, then a remote attacker can set php.ini security directives and execute arbitrary PHP code.

The “Plesk phppath script alias” relates to a php-cgi configuration directive on the web server — namely, ScriptAlias /phppath/ "/usr/bin/" — which tells the web server that any request for a resource beginning with /phppath/ should be served from the directory /usr/bin/ and treated as a CGI program.

Now if the URL is requested, the web server will attempt to execute the file /usr/bin/php and return the output. And since /usr/bin/php is a default PHP path and the file is executable, the php interpreter is called directly.

By exploiting the combination of these two vulnerabilities, a remote unauthenticated attacker can run arbitrary code under the context of the web server user.

Capturing the CVE in action

Imperva has seen this vulnerability exploited in the wild. An example is shown below in Figure 1. The attacker sends a specially crafted HTTP request to the URL /phppath/php of the vulnerable web application. Here are the names of the parameters in the request’s body:

  • Set PHP environment flags, as described in CVE-2012-1823
  • Execute shell commands on the attacked server via PHP (using the PHP security bypass created by the environment flags). The shell commands can, for example, download and install a shell environment controlled by the attacker.

The attacks we observed very nearly coincided with the disclosure of the vulnerability, as can be seen in Figure 2. Many web applications were repeatedly attacked every few hours using this vulnerability over a long period of time (Figure 4).

As we’ve seen before, a single web application can be targeted by multiple attack sources (according to their IP addresses). At the same time, a single attack source can target multiple potentially vulnerable applications. Figure 4 illustrates the complex relationship between attackers and targets.

A similar relationship exists between attackers and injected shell URLs (Figure 5). A successful exploit of the vulnerability downloads a malicious shell code and executes it on the web server. ADC has also seen that URLs from which malicious shell codes are downloaded are used by more than one attacker and originating in more than one geo location.

As is often the case for this type of malware, it’s written in Perl and remotely controlled by the attacker using an IRC channel.  One of the commands the controller can issue to the shell that runs on a compromised server is to look for other vulnerable web applications, in order to virally spread itself on the web.


Figure 1: Sample of attack exploiting the vulnerability

Figure 2: HTTP traffic exploiting the vulnerability (each target application marked with a different color)


Figure 3: HTTP traffic exploiting the vulnerability targeting 4 sample web applications


Figure 4: Attackers (in red) and targets (web applications, in green) during 23/6-30/6


Figure 5: Sample of attackers and injected URLs during 23-29/6




Find Us Online
RSS Feed - Subscribe Twitter Facebook iTunes LinkedIn YouTube
Monthly Archives
Email Subscription
Sign up here to receive our blog: