madison

Zero Day

Ryan Naraine and Dancho Danchev

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

By | February 9, 2010, 5:27pm PST

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?

TalkBack.

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

Topics

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

Disclosure

Dancho Danchev

More details on Dancho Danchev's current and past professional affiliations, can be found in his LinkedIn profile.

Biography

Dancho Danchev

Dancho Danchev is an independent security consultant and cyber threats analyst, with extensive experience in open source intelligence gathering, and cybercrime incident response. He's been an active security blogger since 2007, and maintains a popular security blog sharing real-time threats intelligence data with the rest of the community on a daily basis. More details on Dancho Danchev's current and past professional affiliations, can be found in his LinkedIn profile. You can also follow him on Twitter

Talkback Most Recent of 22 Talkback(s)

  • 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?
    Wtf?
    ZDNet Gravatar
    AzuMao
    9th Feb 2010
  • 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 happened .

    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
    injections.

    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 type
    safe 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
    also produce. Inconsistent, slow, weakly
    typed, buggy and memory-corrupting, rife with
    gotchas and error prone.
    ZDNet Gravatar
    honeymonster
    10th Feb 2010
  • 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?
    ZDNet Gravatar
    AzuMao
    10th Feb 2010
  • 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 string
    coercion . 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
    safemode?

    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 triple ===
    operator. Maybe this time we'll get it right!

    1g) Buggy memory management. So buggy that PHP
    still 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.
    LINQtoSQL:

    // 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
    injection.

    4) No, by no means. All apps need to validate
    input. Problem is that with string
    interpolation even valid 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?
    ZDNet Gravatar
    honeymonster
    10th Feb 2010
  • I think you misunderstood my questions.
    1)
    I was talking about mysql_real_escape_string.

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

    3)
    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?

    4)
    I sanitize it with the appropriate function depending on what it is
    supposed to be.
    ZDNet Gravatar
    AzuMao
    11th Feb 2010
  • 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.....
    ZDNet Gravatar
    storm14k
    10th Feb 2010
  • 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.
    ZDNet Gravatar
    CobraA1
    11th Feb 2010
  • I don't understand the question, sorry.
    It is how things work.

    SQL queries, shell commands, everything that works
    on text, must parse text... :/
    ZDNet Gravatar
    AzuMao
    11th Feb 2010
  • 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?
    ZDNet Gravatar
    zkiwi
    9th Feb 2010
  • ZDNet Gravatar
    AzuMao
    9th Feb 2010
  • 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 batches 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 application bugs - nothing to do
    with the server.
    ZDNet Gravatar
    honeymonster
    10th Feb 2010
  • 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.
    ZDNet Gravatar
    HackerAce
    10th Feb 2010
  • Ack!
    Google fail. 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".
    silly
    ZDNet Gravatar
    AzuMao
    10th Feb 2010
  • 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.

    JMO
    ZDNet Gravatar
    no_axe_to__grind
    10th Feb 2010
  • 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.
    ZDNet Gravatar
    AzuMao
    11th Feb 2010

Talkback - Tell Us What You Think

Formatting +
BB Codes - Note: HTML is not supported in forums
  • [b] Bold [/b]
  • [i] Italic [/i]
  • [u] Underline [/u]
  • [s] Strikethrough [/s]
  • [q] "Quote" [/q]
  • [ol][*] 1. Ordered List [/ol]
  • [ul][*] · Unordered List [/ul]
  • [pre] Preformat [/pre]
  • [quote] "Blockquote" [/quote]
Click Here

The best of ZDNet, delivered

ZDNet Newsletters

Get the best of ZDNet delivered straight to your inbox

Facebook Activity

White Papers, Webcasts, & Resources