Reports: SQL injection attacks and malware led to most data breaches

Reports: SQL injection attacks and malware led to most data breaches

Summary: With millions of personal records and payment card information stolen on a regular basis, several recently released reports independently confirm the main sources of breaches. Not surprisingly, that's not zero day flaws, not even insiders, but good old fashioned SQL injections next to malware.


With millions of personal records and payment card information stolen on a regular basis, several recently released reports independently confirm some of the main sources of breaches. Not surprisingly, that's not zero day flaws, not even insiders, but good old fashioned SQL injections next to malware infections.

With companies investing more resources into ensuring their networks and employees are protected against the very latest threats, some are clearly overlooking the most basic threats, usually requiring simple or average attack sophistication on behalf of the cybercriminal.

Let's review the reports detailing the true impact of SQL injections and malware in the context of data breaches.

- UK Security Breach Investigations Report - An Analysis of Data Compromise Cases - 2010

7Safe's recently released Breach Report for 2010, states that based on the analysis performed by their forensic investigations, 40% of all the attacks relied on SQL injections, with another 20%, a combination of SQL injection attacks and malware. Not only was the source of the attack external in 80% of the cases, but also, a weakness in a web interface was exploited in 86% of the cases, with the majority of affected companies operating in a shared hosting environment.

- Trustwave's Global Security Report 2010

Trustwave's Global Security Report for 2010, offers similar insights related the use of SQL injections (third position in the initial attack entry list) for obtaining unauthorized access to payment card information. The report makes an interesting observation, stating that based on their analysis in 81% of the cases the compromised computers were managed by a third-party, compared to the 13% self-managing themselves.

Furthermore, the report details the most common types of malware that contributed to the loss of customer data, stating that in 54% of the cases the attackers harvested the data in transit.

What malware types were the attackers relying on? Memory parsers (67% of the cases), followed by malware using keylogging (18% of the cases) and network sniffing (9%) of the tactics, and 6% of the cases using credentialed malware, also known as ATM malware (Diebold ATMs infected with credit card skimming malware).

With such basic attack techniques, it shouldn't be surprising that the data exfiltration methods used clearly speak for the insecure state of the companies in question, with Microsoft Windows Network Shares used in 28% of the cases, followed by Native Remote Access Application (27%) and File Transfer Protocol used in 17% of the cases. As far as encrypted channels are concerned, Trustwave's report states that they've only found a single case of an encrypted channel used to exfiltrate the data from the company's network.

- The Poneman Institute - Cost of a Data Breach

Despite that the report emphasizes on recommendations and includes valuable metrics to be considered in a cost-benefit analysis, it also states that based on their research, data breaches due to malware attacks doubled from 2008 to 2009, with the cost of a data breach due to a malicious attack higher than the cost of breaches caused by negligent insider or system glitches. Interestingly, it also states that notifying affected customers right away costs more than delaying the notification. That's of course from the perspective of the customer, not the affected customer whose financial data may have already been abused for fraudulent purchases, depending on the data breach in question.

- Verizon's 2009 Anatomy of a Data Breach Report

Last but not least, is Verizon's 2009 Anatomy of a Data Breach Report, according to which malware and SQL injections were the main sources of the data breaches, as well as responsible for the majority of exposed records. Clearly, this average combination of attack tactics is surprisingly effective against companies who not just supposed to, but obliged by law to have properly secured their infrastructure.

How do cybercriminals known that these corporations are susceptible to such easily, and often exploitable in a point'n'click fashion flaws? Are they shooting into the dark, or do they rely on some kind of methodology which assumes that the low hanging fruit is an inseparable part of every thought to be secure network? Here are some of key issues to consider:

- The KISS (Keep It Simple Stupid) principle within the cybercrime ecosystem

A cybercriminal that doesn't have a clue about what he's doing -- government sponsored/tolerated cyber spies and cyber warfare units are an exception although the KISS principle still applies -- would spend months preparing, possible investing huge amounts of money into buying a zero day vulnerability into a popular web browser in an attempt to use it in gaining access to the company's network. A pragmatic cybercriminal, would on the other hand be "keeping it simple", and would logically assume that there's a right probability that the company overlooked the simplest threats, which he can easily exploit.

With such a realistic mentality, and due to the fact that the cost of executing these attacks is so small, intentionally or unintentionally he comes to the conclusion that the perceived level of security within an organization, appears to be misleading. In this case, complexity is fought with simplicity, starting from the basic assumption that technologies are managed by people, and are therefore susceptible to human errors which once detected and exploited could undermine the much more complex security strategy in place.

The same mentality is applicable to a huge percentage of the "botnet success stories" over the past few years. Instead of assuming that the millions of prospective victims have patched their operating systems (Does software piracy lead to higher malware infection rates?), next to all the third-party software running on their hosts, and start look for ways to obtain the much desired zero day vulnerability, a cybercriminal would basically assume that the more client-side vulnerabilities are added to a particular web malware exploitation kit, the higher the probability for infection.

And sadly, he'd be right.

- The role of automated web application vulnerability scanning in the process of achieving a (false) feeling of security

A report "Analyzing the Accuracy and Time Costs of WebApplication Security Scanners" published earlier this month, indicated that Point and Shoot, as well as Trained scanning performed with the scanners, missed 49% of the vulnerabilities they were supposed to detect. The report also pointed out that the scanners that missed most of the vulnerabilities, also reported the highest number of false positive, the worst possible combination. Clearly, what's more dangerous than insecurity in general (Review of Web Applications Security and Intrusion Detection in Air Traffic Control Systems), is the false feeling of security.

Remember China's much-speculated "unhackable OS" Kylin, which was perceived as a threat to the offensive cyber warfare capabilities of other nations, who've spent years building them on the basis of known operating systems? Just like any other operating system, it's weakness is in the balance -- or the lack of such -- of usability vs security, in this case it's the insecurely configured web applications that would allow the attackers to reach the level of usability offered to legitimate users.

Not by investing resources into looking for OS-specific flaws, but by exploiting the "the upper layers of the OSI Model". It's not just more cost effective, it's just that sometimes the attackers keep it simple.

Why do you think companies neglect the simplest threats, which are also the ones with the highest risk exposure factor due to their ease of exploitation? What do you think?


Topics: Malware, Data Management, Security

Dancho Danchev

About Dancho Danchev

Dancho Danchev is an independent security consultant and cyber threats analyst, with extensive experience in open source intelligence gathering, malware and cybercrime incident response.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Completely inexcusable.

    All that's needed to make SQL injection impossible is sanitizing user
    input with mysql_real_escape_string (or whatever function does this in
    the language you're using).

    How can that be to hard for so many professional coders out there?
    • Because mysql_real_escape_string is an ugly hack

      it was designed to stop-gap the even more
      scandalous automatic quoting.

      It is just two examples of how horribly bad PHP
      has been designed. Strike that. PHP was never
      designed. PHP <i>happened</i>.

      The reason you still see these injections in
      mainly PHP sites is that PHP makes the wrong
      way the easiest and the correct way the
      hardest. Cue string interpolation. A good idea
      borrowed from Perl, but which should NEVER had
      found a place in web scripting. String
      interpolation is an open invitation to both SQL
      injection, XSS injections and even PHP

      Compare to Java or C# which each have a much
      better culture and features which (especially
      for C#) makes the correct way actually easier
      then the incorrect. Cue LINQ (LINQtoSQL, LINQ
      to NHibernate or LINQtoEntities). LINQ queries
      are succinct, strongly typed and <i>type
      safe</i> with no possibility of injections.

      Java does have JDBC which could be as bad as
      PDO et. al from PHP, but the Java culture has
      adopted proper ORM frameworks a long time ago.

      PHP is the worst PoS ever to hit the servers.
      It is an accident, and an unfortunate example
      of what the open source community can
      <i>also</i> produce. Inconsistent, slow, weakly
      typed, buggy and memory-corrupting, rife with
      gotchas and error prone.
      • Four questions;

        1) What's wrong with it?
        2) Do you think it wouldn't stop SQL injection?
        3) Do you have a better (more secure and/or easier to implement) solution?
        4) Do you think PHP is the only language that needs inputs sanitized?
        • Four answers

          1) Lots of things wrong. Just to name a few:

          1a) PHP adopted string interpolation from Perl.
          String interpolation make it all too easy to
          synthesize SQL statements, require statements
          and output directly from variables by <i>string
          coercion</i>. That's where practically all of
          PHPs injection problems come from. SI makes
          sense in a trusted environment, e.g. CLI
          scripting. Not on a webserver processing
          insecure data.

          1b) Using proper parameterized queries are
          hard. To build a proper statement with (typed)
          parameters requires more code and is less
          legible than string interpolation.

          1c) Weak typing, not just dynamic typing. Type
          coercion makes matters worse. 1=="1one ranger"
          evaluates to true! You simply don't know what
          is inside.

          1d) Poor isolation, dependency on C extensions
          which have often been the source of system-
          compromise vulnerabilities. Need I say

          1e) Poor performance when object-orientation is
          being used. Class loading confusing and context dependent.

          1f) Patchy, see-sawing culture. Magic quotes?
          Yes! Ah no forget that. Safemode? Uh, no,
          regret that. Object orientation? somewhat.
          Strongly or weakly typed? Let's see: Super
          weakly typed. Except for those strange
          interface hints. The == equals doesn't work as
          expected? Let's invent the <i>triple</i> ===
          operator. Maybe this time we'll get it right!

          1g) Buggy memory management. So buggy that PHP
          <i>still</i> needs to just throw it all away
          between requests. Any attempt at holding onto
          even the tiniest state leads to memory
          corruption and leaks. Excute and reset. Execute
          and reset. Sometime the memory corruption will
          *still* bite you within the short timespan of a
          single request.

          1h) ...

          2) Yes, dropping string interpolation and
          innovating to make parameterized SQL queries
          easier to write (and read) would go a long way.

          3) Yes, LINQ. Easy to use, full-featured
          parameterized queries would lure programmers to
          write the correct code. Cue C# with LINQ, e.g.

          // search string in "search" variable
          var customers = from c in db.Customers where
          c.Name.Contains(search) select c;

          That's actually a strongly typed, lazy
          evaluated query, ie not possibility of SQL

          4) No, by no means. All apps need to validate
          input. Problem is that with string
          interpolation even <i>valid</i> input (e.g.
          names containing quotes) will sometimes crash
          your app. Do you outlaw apps, use magic quotes
          (ugh!) or convert to an internal "quoted"
          string which is almost just as bad? Or do you
          accept that the string is indeed valid and just
          pass it through a parameter?
          • I think you misunderstood my questions.

            I was talking about mysql_real_escape_string.

            What I meant was, can SQL injection attacks occur when the input is
            sanitized with mysql_real_escape_string or equivalent functions?

            It would take much longer to convert all your stuff to use LINQ than
            it would be to wrap inputs in mysql_real_escape_string(). So you're
            saying it is a more secure way? What attacks does it prevent that the
            latter does not?

            I sanitize it with the appropriate function depending on what it is
            supposed to be.
      • Theres only one problem....

        A couple of summers ago there was a huge rash of
        SQL injection attacks that were executed against
        ASP.Net sites. The developers were simply
        ignorant of the devices within the platform to
        protect against SQL injection. In fact I worked
        with a guy one day that found out about SQL
        injection and realized he had written many
        vulnerable apps and called up a previous
        employer to offer to fix them.

        You can write SQL injection prone code in any
        language. The .Net framework has ways to avoid
        and and so does PHP via its frameworks such as
        Zend and Symphony. If you're still writing apps
        in raw php that don't amount to a simple
        internal guestbook or something you shouldn't be
        writing apps.

        I do agree that its very easy to write complete
        BS apps and thats why it has gained a bad rap.
        But its easy to do the same with C++ so.....
    • Why is it even possible to accidentally execute a string?

      Why is it even possible to accidentally execute a string?

      It's absurd.

      Executing queries inside strings should be explicit - it should be the case that the developer has to purposely tell the system to use the string as a query.

      It should not be the case that SQL automatically executes any code it finds in the string.

      Frankly, that's really the part that's completely inexcusable.
      • I don't understand the question, sorry.

        It is how things work.

        SQL queries, shell commands, everything that works
        on text, must parse text... :/
  • One does wonder which SQL products is most boinked

    Microsoft's stuff, Oracle's, IBM's, mySQL, which? Is there an even balance of "responsibility" or what?
    • SQL injection has nothing to do with the underlying DBMS.

      None of them are at fault.
      • But an unfortunate powerful feature of MS SQL Server

        does tend to allow more serious damage once an
        application allows SQL injections.

        Unlike e.g. Oracle where the "scripting"
        language is actually more pascal-like, MS SQL
        Server holds more true to the SQL philosophy.
        This means that the "scripting" inside SQL
        server is actually built as <i>batches</i> of
        SQL statements. This is quite nice to work with
        because SQL is such a high level (set-oriented)
        compared to e.g. PL/SQL.

        Unfortunately this also means that the syntax
        in general allows batches. Once a SQL injection
        is found it is easier to break into other
        server objects because of this.

        But you are quite correct, SQL injection bugs
        are <i>application</i> bugs - nothing to do
        with the server.
  • RE: Reports: SQL injection attacks and malware led to most data breaches

    There are many factors that contribute to the state of insecurity leading to exploitation of web applications. Take for example the legacy programmer that is new to web development. I find that these people are blissfully unaware of the pitfalls of poor sanitation of inputs and the related need to escape outputs. Just ask your developers what they think of the OWASP top 10. I usually get a blank stare.
    • Ack!

      <a href=>Google fail</a>. First link = WTF!?

      Third one works.. and I'm rewarded by.. common sense! YAY!

      While they're at it they should make it the top 11 by adding "don't post your password to Twitter".
  • Load of crap

    >>With millions of personal records and payment card information stolen on a regular basis,<<

    This is unmitigated crap... there has never been one known instance of cc info being stolen during a data transmission. Sure, if the server security is subject to SQL injection, there's a possibility of breach, but the FUD distributed by the "security" industry is pure BS.

    The so-called "reports" are speculative at best. There's little, if any, foundation in any of them.

    I defy anyone to demonstrate security breaches that have resulted in credit card theft in any computing environment where anything beyond no security is present. Breaches occur only in settings where there is absolutely no security taken.

    The whole security industry is based on BS, smoke and mirrors.

    It just doesn't happen.

    • That's weird..

      ..I could have sworn that a day or two ago there
      was a story in the headlines about several hundred
      thousand dollars being stolen and not reimbursed.
      • My point, exactly

        "..a day or two ago...", "...a story in the headlines..."

        Where, when? If it was "in the headlines" then it MUST have been true. Right?

        That's the kind of unsupported FUD we see from security technologists. It's all crap. Like I said, there is not one documented instance of cc info being grabbed during a transmission, yet the security "gurus" would have us believe we all need hundreds of $$ worth of BS firewall and security software to protect ourselves.

        Don't give me "I could have sworn...". Show me the facts, and not just the article, but the factual evidence.
        • Show me the factual evidence..

          ..that you are a human.

          Not just a picture of a human that could be
          anyone, or an article saying you're a human, but
          proof that [i]you[/i] are a human.
  • RE: Reports: SQL injection attacks and malware led to most data breaches

    Speaking about false sense of security, we should probably also note that looking just at the web app level makes you fall in a false sense of (in)security in general.
    It's just like saying "Car make X can withstand rear impact without significant deformations to the cabin". Looks fine until you realize that (a) in reality impact may come also from the front, left, right and car may actually roll and sustain impacts from top/bottom and (b) lab environment sometimes tells little to real life (I mean it is certainly going to make difference if impact comes from Tata or Dodge RAM3500 hitting your car...)
    Essentially testing your scanner in a lab environment (and sites provided by vendors ARE lab environments) provides a limited insight into how these scanners would perform in real life. Besides, in real life, not only web applications are vulnerable, operating system, all sorts of infrastructure software (app/web servers etc), network equipment are among some of the most prominent sources of risk.
    So that if you really want to gain insights into the state of security of your web application, it's not even the best of the breed web scanner that could give you the answer. You should match attack patterns that cover much more - from the networking up to the web app, including operating systems, web servers and anything in between. And even then you should remember that users are actually the main culprit in most of the cases - somebody with malware infected host inside of your network leaking either passwords or maybe even the cc information of your customers so that bad guys don't even need to touch your web servers...
  • RE: Reports: SQL injection attacks and malware led to most data breaches

    Good article. Agreed that SQL Injection is one of the biggest attacks occuring at Application layer. I am curious as to what are the next 4 attacks in terms of their occurance at Application layer?

    R Paul Singh
  • It's a miracle

    A well written article, citing sources, that is focused on a useful aspect of current technology.

    Instead of flame bait, they took an unbiased view at a problem many software developers face and we had a technical, reasonable talkback discussing the merits and pitfalls. I even feel like I may have gained some knowledge by reading all this.

    As I said, it's a miracle.