6 posts from October 2012
October 31, 2012
 SQL Injection Disconnection
Pin It

This week, Imperva's ADC released the latest Hacker Intelligence Initiative Report.  Our focus this month was hacker forums. 

The purpose of studying hacker forums is simple:  learn about the hacking community by studying their chatter.  I have to give credit to Ericka from Dark Reading whose title best summarized our findings so I'm stealing her title:  The SQL Injection Disconnection.

Hackers are focusing a lot on this vulnerability for several reasons:

  1. SQL injection supports a proven, profitable business model:  steal data and sell it.  For hacktivists, stealing data helps demolish a company's value--just look at Sony's stock price the day after it was breached on March 15, 2011.
  2. Many tools exist to automated the attacks.  See our old blog on this.  
  3. Security teams continue to rely on IPS, network firewalls and antivirus--all of which don't even know a SQL injection from a hole in the wall.

The question is:  Why does SQL injection continue to be ignored?  One security journalist I spoke to was frustrated by constantly writing stories about how SQL injection with little impact.  Why is this?  Here are some possible reasons (and feel free to submit your own):

  1. Security is driven by renewals as Imperva's CEO Shlomo Kramer explained in this Forbes interview, "IT managers at large companies — typically chief information officers (CIOs) — prefer to sign checks for the same, established software to protect their web applications, rather than make the uncomfortable changes necessary. It’s easier to do the former than change how money is spent, which can require all manner of approvals."
  2. A strong reliance on traditional security technologies--IPS, AV and network firewalls--means many people simply aren't seeing how their applications are being attacked.  You can't protect yourself if you don't know what is hitting you.
  3. Compliance requires older technologies.  Many compliance mandates emphasize technologies that don't stop SQL injections (PCI is a notable exception).

For more on stopping SQL injections, please visit our extensive blog on the topic.

Our report is available here (no reg required).





October 29, 2012
 South Carolina Meets SQL Injection
Pin It

South Carolina in the news quite a bit last week.

What caused the breach? No one stated explicitly but as some may suspect, it was probably a SQL injection attack.  What are the indications?

First, according to official statements attacker took off with identity related information and not, for example, details of tax reports (which may be far more interesting) or bank account numbers (same here).

Second, look at the following statement:

On Oct. 16, Mandiant confirmed that in early September, unknown hackers "probed" agency systems, and sometime in the middle of the month, they were able to access the data that was stolen. On Oct. 16, the vulnerability that permitted the intrusion was closed.

Assuming that the timeline described in SC Magazine article is correct, it took Mandiant less than a day to figure out the attack and the dates, which indicates that they immediately went for the web server native logs and looked for SQL injection patterns. 

Third, we can rule out "insecure object reference" as a culprit since credit card information was stolen partly in encrypted format and partly unencrypted.  This indicates that the information was not taken from an HTML display but from the database. 

Sadly, there is some misinformation taking place.  Notice this statement by one reporter, “In August 2011, a group of hackers used Google to steal 43,000 Social Security numbers from faculty, staff and students of Yale University, due to an unprotected FTP server.”  The attackers didn’t use Google to steal information.  Rather, the attackers used Google to find out that the server was holding sensitive information.


October 26, 2012
 Banks told to step up security over DDoS attacks
Pin It

Banks have been asked to step up their DDoS protection.

The request, however, is mostly CYA. Take, for example, the call to check for vulnerabilities--which has nothing to do with DDoS attacks. I think that generally this is missing the point. In particular, it seems that the latest DDoS attacks were very massive and thus are hard to sustain over time by anyone that is not government sponsored.

In this case I would expect national authorities to be the ones to take steps against it rather than individual corporations. In general, I think that attacks of such magnitude should definitely be handled by authorities rather than by individuals. It makes sense to set up regulations for building a house that won't fall down due to a rainstorm. It does not make sense to expect individuals to build dams for the case of a Tsunami.




October 17, 2012
 Beating Automated SQL Injection Attacks
Pin It

Recently, US banks were warned about automated attacks coming from Havij, a SQL injection attack tool. While we've blogged on stopping SQL injection in the past, it is a topic always worth revisiting. 


First, let's make clear what WON'T help.  Earlier this month, Kevin Mitnick gave a talk at the US Naval Academy.  The first lesson?

All the firewalls and intrusion detection systems in the world won’t be a guarantee that networks won’t be breached.  There’s no such thing as an impenetrable system, and no such thing as bugless software. Kevin’s demonstration of exploiting vulnerabilities in widely used commercial software proves this. Moreover, this isn’t just software being used in the private sector.  Many of the exploits he demonstrated take advantage of software that’s become an integral part of the way the military handles its information.

Havij exploits vulnerabilities in software and is totally invisible to network firewalls/IPS.  Havij relies on a blind SQL injection vector, so if you protect against it you are safe.  Here's how:

  1. Negative security model:  Protect against SQL Injection by blacklisting certain known SQL injection manifestations.
  2. Positive security model:  Every injection violates the normal application usage profile.
  3. Identifying automated interactions:  Havij is not human and behaves like a robot.  You can detect it by merely detecting the specific user agent string but also more subtle details such as constant values within the SQL attack itself.
  4. Clean code.

From a technology standpoint, only three types of products will help defeat Havij:

  1. Vulnerability scanners
  2. Code scanners
  3. Web application firewalls

Often, we see companies using vulnerability scanners and, to a much lesser extent, code scanning.  These technologies are very important but they only find issues.  Scanners tell you have problems but you have to figure out where they may be.  Code review gives you a specific line to remediate, but this takes time.  If you are under an imminent Havij attack, these products won't help with immediate risk. 

OWASP has argued in the past that technologies focused on finding vulnerabilities are useful but have one major problem:  they don't block attacks.  This is why they recommend a web application firewall.  (Full disclosure:  we are a WAF vendor.)  WAFs do provide a shield against immediate attack and--at least in our case--we can recognize Havij and stop it.  Havij does come with some WAF evasion functionality--but it only works on Web Knight and ModSecurity.


October 11, 2012
 Firefox Vulnerability: Tech Details
Pin It

Firefox is leaking URLs data across domain, by not restricting javascript’s “location” method.  How does it work?

A “proof of concept” exploit for the vulnerability exists (for more, check this out).

  1. A user browses to the attacker site.
  2. That attacker opens a new window in Twitter from attacker site.
  3. If the victim is signed in to twitter, then the user gets redirected to a URL that contains a personal twitter ID.
  4. The attacker can now query the new window on the URL and obtain the victim’s personal twitter ID.

On previous versions of Firefox, this attack would fail:


There was a regression in Firefox 16 that allowed this attack to work:






October 02, 2012
 How to Spear Phish the White House
Pin It
Apparently there has been a cyber attack on the White House’s network.  The reported attack vector?  Spear phishing.  At least it appears that no data theft took place, yet. 

This incident reminds us how easy it is as an organization, even as secure and well funded like the White House, to get infected since antivirus is so porous.  Lucky for the White House, their team of security specialists were able to find the compromised entity, but it is not trivial and usually happens very late, if ever.

While "phishing" is a technique which by hackers mimic sites such as IRS , or your Bank etc, in order to lure you to submit your credentials.  “spear phishing” is the targeted technique of identifying an individual in an organization that the hacker wishes to compromise,and uses different techniques in order to lure that individual to activate malware on his/her computer. Effectively, creating the compromised insider.

As you can see below, finding an individual to target is fairly easy in todays social networking world. All a hacker has to do is look for “White House” as the current position and select which is pertinent:


There are several known as infection methods, the three most common include:

  • Email attachment of either executable in an EXE form ( less common now ) or a PDF with malicious code in it
  • Link distribution of an infected site, that once you go into you get infected. Can come via email or any form.
  • A gift. Something as simple as a USB given at a convention that contains malware

We would encourage you to read our “The Quantum Mechanics of Spear Phishing” blog to get yourself more familiarized with how it works.

As we said before, here is what you can do to protect yourself as a company or an individual :

  1. Assume you've been compromised.  For more, read this
  2. Treat Social Network messages like you do with your Emails. Check who is it from and understand context before you choose to reply.
  3. Make sure that in your social networks profiles, you are not sharing your contact information, unless you explicitly approve them.
  4. As an organization, have the tools to protect your employees from such scams, and a policy in place.
  5. Education:  train employees and raise the levels of awareness.

(NOTE:  An old Sunday School teacher taught, "repetition is the art of learning."  Let's hope that applies for spear phishing).



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