Blog|Login|中文Deutsche日本語
46 posts categorized "Barry Shteiman"
November 05, 2013
 The rise and rise of ColdFusion-driven breaches
Pin It

IStock_000004850249SmallYesterday, Brian Krebs wrote an article on how several high end car/limousine service companies were breached and customer information was stolen. This resonated very strongly since some of the victims were celebrities, lawmakers and top executives. Krebs notes that the vulnerable component in those sites is identified as the ColdFusion web application platform.

Some of you may remember an article by SC Magazine from May this year, where a ColdFusion vulnerability was the breach vector that resulted in 160,000 Social Security Numbers (SSN) being stolen from Washington state Administrative Office of the Courts (AOC).

Also, an article on InformationWeek from August this year covered a data breach with the Department of Energy (DOE) where personal information of 14,000 employees was compromised. The system breached was written in ColdFusion and was developed by a third party company.

Why this matters?

ColdFusion induced breaches are definetly on the rise, which teaches us that hackers and security researchers are looking into this platform more and more as a green field for hacking endeavors.

As more companies are becoming security aware, we would like to believe that the trivial security gaps become  harder to find and easier to deal with. However this breeds an uprising technique within the hacking community, which is – finding an auxiliary functionality that is supposed to be used indirectly only by an administrator of the specific system, but in fact can be used by a hacker.

If we look into one of the more interesting ColdFusion vulnerabilities (can be found here) that is exactly the case. It is a vulnerability that uses administrative function that isn’t properly hardened within the platform. 

What can companies do?

  1. Patch. Although difficult in production, patching to latest versions and latest security patches usually will help fix the problem sooner rather than later
  2. Educate yourself. Knowing the platforms that you have, the platforms that are used by third party companies/solutions that you work with – is key in understanding your security posture
  3. Install a Web Application Firewall. As we believe that these types of attacks are up and coming, we invest lots of our security research efforts into identifying them and blocking them before they hit the servers

 

October 08, 2013
 Threat Advisory: A vBulletin Exploit, Administrator Injection.
Pin It

IStock_000009353255SmallvBulletin is a popular proprietary CMS (content management system) that was recently reported to be vulnerable to an unspecified attack vector. vBulletin is currently positioned 4th in the list of installed CMS sites on the internet. Hence, the threat potential is huge.

Although vBulletin has not disclosed the root cause of the vulnerability or its impact, the Imperva Application Defense Center (ADC) has determined the attacker’s methods.

The identified vulnerability allows an attacker to abuse the vBulletin configuration mechanism in order to create a secondary administrative account. Once the attacker creates the account, they will have full control over the exploited vBulletin application, and subsequently the site supported by its CMS (vBulletin). 

Initial Analysis

Although vBulletin has not disclosed the root cause of the vulnerability or the impact on customers, they did provide a workaround in a blog post encouraging customers to delete the /install, /core/install in vBulleting 4.x and 5.x respectively.

Vb1

Additionally, on vBulletin internal forums a victimized user shared his server’s Apache log, providing some visibility into the attacker’s procedure: 

Vb2

This log indicates that the attacker continuously scans, using “GET” requests, for the “/install/upgrade.php” vulnerable resource. Once successful , indicated by the “200”response code, as opposed to “404” response code for non-existing resources, the attacker issues a “POST” request to the same resource with the attack payload. Since the Apache logger does not log the parameters of POST requests, the details of the attack are not yet revealed.

Into the Weeds

Once we had access to some concrete technical details on the vulnerability, we were able to effectively scan hacker forums in search of an exploit code. Soon after, we found PHP code that implements the attack.

Vb3

Next, we carefully installed the code in our lab. The interface clearly states the goal of the attack: injecting a new admin. In order to exploit the vulnerability and inject a new Admin user, the attacker needs to provide the following details:

  1. The vulnerable vBulletin upgrade.php exact URL
  2. The customer ID

In order to get these details, hackers had created an additional auxiliary PHP script. The script scans a site for the vulnerable path, exactly as shown above in the reported Apache log, and extracts the customer ID from the vulnerable upgrade.php page, as it’s embedded within the page’s source code. 

Consequently, the attacker now knows both the vBulletin’s upgarde.php vulnerable URL and the customer ID. With this information, the attack can be launched.

Here is an example of the POST request with the attack payload (the red fields match to the information the attacker needed to enter in the PHP interface above).

Vb4

The result of the attack was exactly what the exploit package described. A new admin user was created (“eviladmin”) that is under the control of the attacker. The site has been successfully compromised.

Recommendations

  1. vBulletin has advised its customers to delete /install and /core/install directories in versions  4.x and 5.x respectively.
  2. For vBulletin users not able to delete these directories – it is advised to block access or redirect requests that hit upgrade.php through via either a WAF, or via web server access configuration.

SecureSphere WAF Mitigation

Imperva customers have been updated with a signature to prevent unwanted access to the vulnerable php code via our regular content updates.

Where Can I learn More?

  • Imperva CMS Hacking webinar
  • An Article on CMS Hacking published on ITProPortal
  • vBulletin usage statistics and analysis can be found on w3techs.com
  • Comparative CMS distribution analysis could be found here

 

October 04, 2013
 Score sheet: Testing Some XSS Evasion Techniques Against Our WAF
Pin It

IStock_000016474569SmallA couple of months ago ModSecurity (SpiderLabs) issued an “XSS Evasion Challenge” where they actively asked security experts and hackers to try and bypass their own XSS filters. This is a blessed initiative by a security company, to go and find loopholes in their engines in order to improve on their security posture.

The exercise included two main challenges:

  • Evading the ModSecurity WAF regex (CRS)
  • Evading client side protection “sandbox”

Per the challenge results, ModSecurity filters were updated to add the logic that is required to block these evasion techniques.

With security in mind, we were interested in checking the evasion techniques against our SecureSphere WAF its default configuration. Here are the results:

Evasion Technique #1: - “Nul Bytes” – Blocked out of the box.

Xss1

Evasion Technique #2: Sandbox Evasion (MentalJS) – Blocked out of the box.

Xss2

Bottom line – We were able to block both evasion techniques out of the box. Our customers are protected.

We also agree with SpiderLabs’s conclusions:

  • Blacklisting attacks with signatures is not enough. We agree. Part of the reason that IPS/NGFW and manually configured WAF solutions don’t solve web application attacks is that they rely on blacklists.  Effective protection against application attacks requires a positive security model to understand how the application works. See our Blog on “What the IPS Didn’t See”.
  • SpiderLabs say that Regular Expression matching (Signatures) is not enough. We agree. Imperva’s Technology does not rely on RegExp matching alone, but also incorporates smart engines that are able to understand the attack’s logic.

 

 

 

October 01, 2013
 Trend Watch – DDoS: “We Need a Bigger Boat”
Pin It

IStock_000003953967XSmallIt’s no news that DDoS attacks are growing in frequency and scale. Earlier this year Spamhouse suffered from what security experts have cited as “the largest DDoS attack ever,” peaking at 300+ Gbps. The story recently resurfaced when the attacker was apprehended.

This morning, eWeek reported on a new attack, which will go down as one of the largest DDoS attacks of the year. While the identity of the target remains undisclosed, the attack details are available. This latest DDoS attack started on Sep 24th, lasted for nine hours, and peaked at 100 Gbps.

As reported in the eWeek article, the attacked organization was protected by the Imperva Incapsula DDoS attack mitigation service, and therefore did not suffer service disruption.

One of the lessons that an attack this big teaches us is that attackers are generating a high magnitude of traffic to take down a target. Most companies, even some carriers, don’t own the bandwidth to continue service through such an attack. And attacks are ever growing – one 50 times larger can be right around the corner. DDoS protection companies provide the extra bandwidth when you are under attack – so you have a bigger boat to absorb the load.

Indeed. We build bigger boats.

 

Where can I learn more?

  • Our HII Research Paper on DDoS
  • The Imperva Incapsula DDoS attack mitigation service

 


 

September 24, 2013
 Lost and Found in the Dark
Pin It

IStock_000010945810XSmallA recent DarkReading article by Robert Lemos covers the lack of security expertise in companies developing in-house applications. This timely article explains the importance of sourcing security expertise from firms that are focused on application threats (and the application of fixes to these found problems).

My recent post about SQL Injection (SQLi) findings, which references Veracode’s infographic and the pervasive lack of application-security awareness, notes that 30% of breaches still come from SQLi. This data point clearly points out the lack of awareness at minimum, but also suggests that most organizations don’t really know how to deal with the problem.

The DarkReading article could have gone further by covering what a fix is, and what applying a control to a problem really means for an organization. Just as organizations require expertise in uncovering vulnerabilities, they also need expertise in fixing these — both are critical and ongoing processes. Hence, finding the problem and fixing it must go hand in hand

One reason we invest so heavily in our ADC research team is the acknowledgment that our customers depend on us to mitigate web security threats. At the end of day, a WAF is application security expertise packaged in a product to mitigate web threats.

What can you do to fix web application vulnerabilities?

  • Educate yourself about web application security risks
  • Choose a company expert at helping you identify web application security problems in your own data center.
  • Mitigate the discovered problems (and other undiscovered problems) using a WAF. One example is our collaboration with WhiteHat.
  • Fix the code and patch the systems. Although not all problems can be fixed by a code patch, this is an important step in lowering the overall risk.

 

September 18, 2013
 SQLi still Alive and Kicking
Pin It

Alive-and-kickingRecently, Veracode published a compelling Infographic on the true costs of a data breach.

According to the graphic 30% of data breaches are caused by SQL Injection. How is that still possible? SQL Injection was solved 10 years ago with the introduction of the positive security model with Web Application Firewalls and with proper code audits. Sadly, we still see major data breaches caused by a dated attack vector caused by the following:

  • Misinformation of security officers, who are made to believe that signature-based technologies such as IPS would stop SQL Injection. In a previous article we explored the differences between an IPS and a WAF and why SQL Injection still prevails.  
  • The classic “I’m a small shop, no one targets me” misconception, that leads unaware business owners to believe that SQL Injection attacks and other web attacks are only targeted or worse – only targeted at big companies. Credit card data stored in a small mom-and-pop shop database has the same value of one stored at a large bank database.

Where can I learn more?

  1. “What the IPS Didn’t See” article, here
  2. “The Future of Web Security” article, here

 

August 27, 2013
 Trade Secrets Leaked for Two Years without Audit
Pin It

KeyToday, an article on TheRegister caught my eye. It was also reported on Bloomberg. Two ex-employees of a Wall Street trading company – Flow Traders – are facing criminal charges for leaking trading evaluation algorithms from their previous employer.

Now this is your typical information leakage story, where an employee steals company assets for personal gain. But here’s what’s truly astonishing.

Consider this quote:

“Vuu was charged with 20 counts of each offense, having emailed himself various materials related to Flow Traders' trading strategies and valuation algorithms over the period from August 2011 to August 2012” (emphasis is mine).

Not only did the trading company have an insider active for a year, the charges and investigation of the story comes out only now – one year later. From the beginning of the data leakage to the point of prosecution, two full years have elapsed. Only recently has one of the offenders left the trading firm, reportedly in March 2013.

Here is another quote from one of the ex-employee’s lawyers:

“I’m confident that when the DA’s office has completed their investigation they will find Flow Traders did not suffer any economic loss.”

Let’s step back for a second.

It’s difficult to assess the damage that results from data theft. But the potential fallout is truly mind boggling. A trading firm’s evaluation algorithms are their most precious IP. They are the unique factor that measures and automates buy/sell decisions. A firm loses that – and it’s out of business, period. Two years is ample time to sell stolen information to the highest bidder and destroy a business.

Companies with employees at different levels who access IP must take precautions to ensure that data is monitored and audited. In today’s data-driven world, a company simply cannot afford a breach that goes unnoticed for two years.

Flow Traders may have dodged a bullet. But future companies may not be so lucky.

 

August 08, 2013
 Thoughts on the FBI’s Preso at Black Hat
Pin It

ArmyguyAttending BlackHat is something that most security professionals look forward to. It’s an opportunity to meet similar folks on both sides of the security aisle, have a drink, share stories and compare notes.

FBI at Black Hat

One presentation really stood out for me at this year’s conference:  the Insider Threat presentation by FBI’s former CISO, Patrick Reidy. In the presentation, Reidy talks about the FBI’s approach to combating insider threats. What I really enjoyed was the striking similarity between the FBI’s analysis and what Imperva has been talking about for the past year. Even the FBI’s own resourceful research conclusions are in line with ours.

I used to look at all insider threat cases in more or less the same way. I always assumed that at one point, there would be an attempt to capture credentials or hack/use a system admin/privileged account in order to gain access to data. While CERT (CMU) would definitely agree with me on this point (see next paragraph), the FBI’s conclusions tell a different story. This makes me believe that there is a fundamental difference in cybercrime that occurs in government and non-government targets.

Interesting Findings

While CMU marked 90% of all IT sabotage coming from system admins, in the FBI’s case – only 0.8% were system admins, and only 1.5% of all incidents included privileged system administrator account usage.

Finding1

The numbers indicate a very significant difference between the expected targeted users who own system privileges in government versus non-government organizations. The number of Insider incidents originating in system admins are very high everywhere except within government. Common sense says that since government employees in agencies such as the FBI must have access to privileged and sensitive information, the Insider in government organizations could be anyone.

Are you malicious?

One other interesting fact from Reidy’s presentation was the difficulty in uncovering malicious insiders. During the presentation, he talked about a major problem in detecting users in an organization that start out with no malicious intent, but turn in time to the dark side for money or other ulterior purposes.

I agree. It is close to impossible to monitor each employee’s connections and private affairs outside of an organization, and to keep the finger on the pulse of things like financials and friends to gauge whether there is a potential problem that should be flagged.  This means that someone has ample opportunity to become an insider threat or engage in espionage.

Findings2

(Source: Patrick Reidy, Combating the Insider Threat at the FBI: Real World Lessons Learned – BlackHat USA 2013)

5 Lessons Learned

Reidy summarizes key lessons learned in his research with some calls to action for organizations:

1. Insider threats are not hackers
  • Frame and define the threat correctly and focus on the insider threat kill chain
2. Insider threat is not a technical or “cyber security” issue alone
  • Adopt a multidisciplinary “whole threat” approach
3. A good insider threat program should focus on deterrence, not detection
  • Create an environment that discourages insiders by crowd sourcing security and interacting with users
4. Avoid the data overload problem
  • Gather HR data and data egress/ingress logs
5. Detection of insider threats has to use behavioral based techniques
  • Base detection on user’s personal cyber baselines

Want to learn more?

Last month, we presented a webinar on Insider Threats and concluded with an 8 step plan on how to remedy them.

Imperva has also released an eBook to help educate and simplify the understanding of insider threats and the remediation process.

 

 

 

 

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 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 http://www.example.com/index.php 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 http://www.example.com/phppath/php 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.

Cve1

Figure 1: Sample of attack exploiting the vulnerability

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

Cve3_updated

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

Cve4

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

Cve5

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

 



 

 

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