Exploit Development for Fun & Profit

Last week I pulled together a posting for DarkReading covering the commercial aspects of exploit development - "The Business of Commercial Exploit Development". I hope you find it interesting... it sheds some light in to a side of the security business that few understand or operate within, but has a huge impact on what the threat landscape looks like in reality.

Persistent Threat Detection (on a Budget)

If there’s one simple – high impact – thing you could do to quickly check whether your network has been taken over by a criminal entity, or uncover whether some nefarious character is rummaging through your organizations most sensitive intellectual property out of business hours, what would it be? In a nutshell, I’d look to my DNS logs.

It’s staggering to me how few security teams have gotten wise to regularly interrogating the logs from their recursive DNS servers. In many ways DNS logging can be considered sprinkling flour on the floor to track the footsteps of the culprit who’s been raiding the family fridge. Each step leaves a visible impression of where and how the intruder navigated the kitchen, and their shoe size.

Whenever an electronic intruder employs their tools to navigate your network, tries to connect back to their command and control server, or attempts to automatically update the malicious binaries they've installed upon the system they have control over (or wish to control), those victim devices tend to repeatedly resolve the domain names that that attacker is operating from. Therefore, armed with a list of known bad domain names and/or IP addresses, it’s a trivial task to mine the DNS logs and identify any successful intrusions.

Depending upon how authoritative your “blacklist” of criminal domains is, and how picky you are about the IP destinations that the domain names are resolving to, you can rapidly spot those nefarious shoe impressions in the flour.

One word of caution though, this isn’t a comprehensive technique for detecting persistent threats operating within your network – but it is one of the simplest! It also has the highest impact – particularly if you’re operating on a shoestring budget.

An obvious limitation of DNS log mining is the depth and accuracy of the blacklist you’re matching DNS events to – so you’ll want to ensure that the list you’re using covers the types and classes of threats you’re most interested in detecting. While there are plenty of free blacklists out there, the vast majority of them deal with spam, phishing and drive-by hosts… so you’ll want to invest some time shopping around a little.

Here are a few tips to using DNS as a means of detecting persistent threats (advanced or otherwise):

• Turn DNS logging on! Seriously, do it now… you can read the rest of this blog after you've turned it on.
• Select a bunch of relevant blacklists that contain malicious domains associated with the threats (and criminal actors) you’re most interested in.
• Create a list of IP address ranges for countries, companies or regions that computer systems within your organization shouldn’t be communicating with, and use this as a second-pass filter for spotting other unwanted or likely malicious traffic.
• Scrape your DNS logs frequently – ideally at least once per week.
• If you’re worried about a handful of specific threats (e.g. a criminal operator or state that is likely targeting your organization), scrape your DNS logs for relevant domain names hourly – and alert upon their discovery.
• Even if you’re only scraping you’re DNS logs weekly, don’t throw them away after you’re done. Try to keep your DNS logs for multiple years at least. (Note: DNS logs compress to almost nothing – so they’re not going to take up much space).
• Consider scraping all the older logs (going back up to 5 years) once a month or so. New domains will be added to the blacklists you’re using over time, and new intelligence can shed new insight in to past intrusions. It’ll also help to establish when the intruder first compromised your network when you do find one.
• If your DNS server allows it, turn on logging of “failed” lookups – i.e. NX domain requests. While these events won’t help in your blacklist lookups, they will help identify malware families that make use of domain generation algorithms (DGA) as well as “broken” applications within your network that need some tuning in finding their legitimate destinations.
• DNS log scraping can be conveniently done off-line through simple batch script processing. So the impact on the team responsible for securing the corporate infrastructure is minimal after a nominal development investment.

If you’re not happy with the quality of the blacklist you’ll be able to bring to bear in uncovering the persistent threats likely already operating within your environment, or if it would be helpful to do a “one-off” check of your DNS logs and to help build the internal business case for investing in a more permanent detection solution, let me know.

Point of Sale (POS) and Card Reader Tampering

In the field of consumer retail the most important piece of equipment is the cash register; better known by those in the trade as the Point of Sale (POS) terminal. In essence, if the retailer can’t complete a sale by successfully taking the money from the customer, then there is no business. Which means it’s a critical component of the business and needs to be treated as such.

Over the last two decades POS technology has evolved considerably. Today’s systems are predominantly networked computers capable of not only processing a sale, but also querying inventory, managing customer loyalty programs and even delivering news and mandatory training materials directly to the store employee.

At their heart, these modern POS terminals are often a standard desktop PC adorned with a number of card readers, money drawers and barcode scanners and, as such, are all too often vulnerable to the same threats that affect any other PC around the world. Some all-in-one POS systems incorporate a number of physical safeguards to protect against the everyday insertion or removal of attached peripherals, and to also prevent theft of the equipment – which you rarely see on corporate desktop systems.

In many stores you go to you’ll also encounter a separate card reader (often with a touch-screen and numeric keypad) that’s designed to allow the customer to swipe and complete a credit or debit card transaction by themselves. These card readers are typically owned and managed by the merchant bank that processes the financial transfers for the retailer and, while there are many different types, a handful are more popular than others.

These merchant-supplied card readers typically include any number of logical and physical anti-tampering technologies – most of which are designed to elevate the retailers trust in the reader, and to help protect against semi-sophisticated criminals. There are entire books and engineering courses in anti-tampering technology, but an interesting paper I came across a few years ago will likely be a good primer for hinting at the sophistication of the anti-tampering technologies found in the POS card readers, and the techniques available to organized criminals for defeating them.

Check out “Thinking inside the box: system-level failures of tamper proofing” by the University of Cambridge from 2008. It has a few pretty pictures too.

It should be no surprise that the criminals have access to many of the tools and techniques to alter even the most sophisticated anti-tampering technology. It’s interesting to note that there are online tutorials and walkthroughs on many hacking sites and (more importantly) carding forums. Here is just one example:
A carder forum at carderbase.cc

If you’re a retailer, what should you be doing to protect yourself from POS (and card reader) tampering? I’m sure there are a number of audit points within the PCI standards that cover this topic but, frankly, it’s so difficult to locate those points and distil them into something immediately actionable I’d recommend the following as a bare minimum:

• Maintaining a list of the POS terminals and card readers within the store – that includes the type, make, model and serial number. This list and terminals should be checked on a daily basis.

• Checking that serial numbers on the terminals match the serial numbers displayed on the terminal screen.

• Checking for signs of terminal and component tampering; and making sure that staff are trained in identifying evidence of physical tampering.

• Checking that stickers and other visual identifiers are unchanged.

• Prohibiting unauthorised people from accessing terminals and any CCTV equipment.

At the end of the day, modifying the card reader and defeating the anti-tampering technologies within them is not a trivial task for the uninitiated… unlike installing a piece of malware, keylogger or battery-powered card skimmer on the POS computer. However, as we’ve already seen with the growing sophistication and almost commoditization of ATM card skimmers (see Brian Krebs excellent series of blogs on the topic: “All about skimmers“), this has become a business and the sophisticated fraud can be achieved with a relatively low investment by the criminal.

Nitol and 3322.org Action by Microsoft

Reading this morning's blog from Microsoft about "Operation b70" left me wondering a lot of things. Most analysts within the botnet field are more than familiar with 3322.org - a free dynamic DNS provider based in China known to be unresponsive to abuse notifications and a popular home to domain names used extensively for malicious purposes - and its links to several botnets around the world. So it was a surprise to hear that Microsoft was able to team up with Nominum to usurp control of the 3322.org domain (zone) and effectively block the known malicious domains, while other regular users can carry on with their business or businesses.

Microsoft presented the need to take control of this cluster of malicious domains as a necessary action against the Nitol botnet and to protect and secure the supply chain. While I don't quite understand all of the logic behind this argument (there's just not enough info public at this point in time), at the end of the day Microsoft have managed to remove a thorn from the community's side.

The Nitol botnet is, in general terms, bothersome but not a wide scale threat. Damballa Labs has been tracking the threat for quite some time and, as botnets go, is a rather small and tired affair. If you're a victim of Nitol though, yes, it's a pain-in-the-bum DDOS agent.

The 3322.org angle is much more interesting to me than the Nitol botnet that formed the legal excuse for being able to seize control of the domain.

From a Damballa Labs perspective, we currently track around 70 different botnets that currently leverage 3322.org's DNS infrastructure for C&C resiliency - using a little over 400 different third-level domain names of 3322.org. With a bit of luck I'll have some size information about those botnets later today.

Will the usurping of 3322.org kill these botnets? Unfortunately not. There may be a little disruption, but it's more of an inconvenience for the criminals behind each of them. Most of these botnets make use of multiple C&C domain names distributed over multiple DNS providers. Botnet operators are only too aware of domain takedown orders from law enforcement, so they add a few layers of resilience to their C&C infrastructure to protect against that kind of disruption.

Take Nitol for example - it employs multiple domains from several free dynamic DNS providers, including other four-digit .ORG domain services such as 6600.org, 7766.org, 2288.org and 8866.org.

Interestingly enough, the (former) owners of 3322.org are providing new support advice to their inconvenienced customers in how to bypass this interuption by Microsoft:

Or, after some Google translation:

Good to know that it's business as usual...

 The story isn't over yet!

Trend Micro - You're doing it wrong!

In my Monday morning blog catch-up I stumbled upon Trend Micro's blog "Big Data Analytics and the Smart Protection Network". I don't normally bother reading or commenting on such self-serving marketing crud, but I worry that Trend Micro may starting to believe their own marketing fluff.

There are a number of things that are worth commenting upon, but the following is more dire than many...

"Every day, we receive 430,000 files for analysis, of which 200,000 are unique. That results in 60,000 new signatures for detection every day."

Trend Micro - you're doing it wrong! Who in their right mind still pumps out 60,000 new signatures for yesterdays malware? The fact that any vendor is forced to write signatures for each new threat is obviously a depressing aspect of the whole legacy approach to antivirus. There are considerably smarter ways in dealing with this class of threat. From my own past observations those 200,000 unique samples are more than likely serial variants of only a handful of meaningful malware creations. A ratio of 200:1 or 500:1 is pretty common nowadays - and even then more modern "signature" approaches could shrink the ratio down to between 4000:1 or 10,000:1 by the time you start interpreting the code contained within the malicious binary.

Why is all this important? Firstly, perhaps it's my German heritage, but inefficiencies can be grating. Just because you're been pumping out the same crud the same way for decades, doesn't mean you can't learn something from the younger dogs at the park. Secondly, these 1:1 transformations of signature to unique malware sample are redundant against the current state of the threat. The bad guys can generate a unique malware variant for every single visitor every time they get infected or receive an update. Thirdly, the signature you're pushing out is redundant - it's a marketing number, not a protection number, it wouldn't even serve as a SPF number on a bottle of sunscreen. Finally (and it's only "finally" because I've got a day job and I could go on and on...), "200,000 are unique" - I think you've missed more than a few...

"Thanks to our leadership in the reputation and correlation area, we get many requests from law enforcement to help them identify and jail criminals."

I suppose blind self-promotion works best if evidence is contrary. I'm sorry, but there's a lot more to reputation than blacklisting URL's and whitelisting "good" applications nowadays - and there's an ample list of companies specializing in reputation services that do this particular approach much better. The problem with these (again) legacy blacklist approaches is that the threat has moved on and the criminals have been able to ignore these dilapidated technologies for a half-decade. Server-side domain generation algorithms (DGA), one-time URL's, machine-locked malware, Geoip restrictions, blacklisting of security vendor probing infrastructure, etc. are just a sampling of tools and strategies that the bad guys have brought to bare against this legacy framework of reputation blacklists and correlation.

Don't get me wrong, the data you're gathering is useful for law enforcement. It can be helpful in identifying when the criminals screw up or when a newbie comes on to the scene, and it can be useful in showing how much damage has been done in the past by the bad guys - it's just not too effective against preemptively stopping the threat.

Speaking of the data, I'd love to know who's buying that data from Trend Micro? From past experience I know that most governments around the world pay a pretty penny for knowing precisely what foreign citizens are browsing on their computers, what type of Web browser they're using and what's the current patch level of their operating system... it's traditionally useful for all kinds of spying and espionage but, more importantly nowadays, for modeling and optimizing various cyber-warfare campaign scenarios.

DGA-based Botnet Detection

There are essentially two types of magic in the world – those that deceive an audience in to believing something impossible has occurred, and that which is best defined by Arthur C. Clarke as “any sufficiently advanced technology is indistinguishable from magic”.

The antivirus industry is rife with the former – there’s no shortage of smoke and mirror explanations when it comes to double-talking “dynamically generated signature signature-less engines” and “zero false-positive anomaly detection systems”.

I’m going to introduce you to the later kind of magic. Technological approaches so different from traditional approaches that, for many folks out there in Internet-land, it’s indistinguishable from magic. More than that though, I’m going to try to explain how such techniques are reversing the way in which threat discovery has occurred in the past. However what I’m not going to do is to even try to explain a fraction of the math and analytics that lies behind that magic – at least not in a blog!
Oh where, oh where should we start?

Let’s begin, for arguments sake, by classifying malware as a tool; a weapon to be more precise. In the physical world it would be easy to associate “malware” with the bullets from a gun, and the gun in turn likened to perhaps a drive-by download site or a phishing email. In response to that particular physical threat, there are a number of technological approaches that have been deployed in order to counter the threat – we have metal detectors and x-ray machines to alert us to the presence of guns, sniffing technologies to identify the presence of explosive materials, CCTV and behavioral analysis systems to identify the suspects who may be hiding the gun.

A fundamental premise of this layered detection approach is that we’ve encountered the threat in the past and already classified it as bad – i.e. as a “weapon”. Gun equals bad, knife equals bad, metal corkscrew equals bad, and so on. Meanwhile everything else is assumed to be good – like an ostrich egg – until it happens to be used as a weapon (such as when “Russell pleaded guilty to assault using an ostrich egg as a weapon, assault, and breaching a protection order“) and inevitably some new detection technique is proposed to detect it.

Traditionally the focus has been on “preventing” the threat. In particular, detecting the presence of a known threat and stopping it from reaching its target. In the physical world, in general, the detection technologies are pretty robust – however (and it’s a big “however”), the assumption is that the technology needed to provide this prevention capability is ubiquitous, deployed everywhere it could potentially be needed, and that it works every time. Sure, at high value targets (such as airports) you’ll find such technology employing its optimal capability, elsewhere though (such as the doorway into your home) it’ll not be encountered. There are obvious parallels with the cyber-world here – except arguably the Internet-equivalent technologies are a little more ubiquitous, but considerably less capable in preventing the malware threat.

For the mob hitman, serial killer, or other kind of mass murderer, the threat of sparsely deployed metal detectors is an easily avoided problem. Subversion or avoidance of the detection systems is pretty easy and, more importantly, an appropriate choice of location negates the problem entirely. Even then, such a detection strategy, operated in isolation, isn’t a serious inhibitor for new murders. If such a technology exists to only detect the guns and bullets, but is not capable of providing attribution (e.g. this gun was used in 16 different murders over the last 2 weeks and the owner of this gun is the murderer), then the criminal only ever loses a tool each time they get caught – since the prevention technology is divorced from association with the victims (past or prospective).

But there’s an entirely different side to dealing with that kind of threat – and that’s the forensics element. While our not-so-friendly murderer can avoid the detection technologies, they’re much less capable of avoiding the evidence of violent past actions. Starting from the first murder, it is possible to build a case that points to a specific criminal by analyzing the components of the crime scene(s).
I know, the argument is that everything should be done to prevent the crime in the first place. That’s clearly very difficult in the physical world, but you’re basically living in a fantasy land of Goblins and Unicorns if you’re expecting it to work better in the cyber-world.

Which basically brings me to the discussion (and subsequent detection) of the latest generation of sophisticated malware – malware that uses domain generation algorithms (DGA) to locate their command and control infrastructure and upload their stolen data. Malware with this capability are designed to evade all those conventional prevention technologies and, once successfully deployed within their victim populace, evade all other methods of traffic filtering and takedown processes. Even if a malware sample is accidentally captured, its DGA capabilities will go undetected.
Detecting DGA-based malware is, as I implied earlier, both “magic” and a reversal of conventional prevention approaches. In order to detect DGA-based threats early on, you start with the victims first…

DGA-based malware use an algorithm to pick out candidate domain names in order to hunt for their prospective C&C servers. The vast majority of the domain names they’re looking for simply don’t exist. In the world of DNS, attempting to resolve a domain name that doesn’t exist will result in a “no such domain” (i.e. an NX) response from an authoritative DNS server somewhere down the line. So, in essence, DGA’s are noisy if you’re watching DNS activity – and lots of NX responses are a key feature of an infected host. Unfortunately, the average Internet-connected device typically tries to look up lots of things that don’t exist, and there’s often a lot of legitimate NX traffic which can disguise the flapping of the malware.

Assuming some kind of algorithmic basis to the domain candidates being created by the malware, you could suppose that it would be possible to develop a unique signature for them. If only it was that easy – the criminals are smarter than that. And you’re also assuming that you’ve already encountered a copy of the malware before in order to create a signature for that particular DGA-based malware.

Instead there’s a much better way – you monitor all your DNS traffic and NX responses, and you identify clusters of devices (or IP addresses) that are generating roughly similar domain name requests. This first pass will provide a hint that those devices share some kind of common ailment (without ever needing to know what the malware is or have ever encountered a sample before). In a second pass you focus upon identifying just the domain names that are structurally very similar across all the afflicted assets and classify that DGA based upon a number of features. Classifying the DGA makes it easier for attribution and uniquely tracking a new threat.

At this point you’re pretty much sure that you have a new malware outbreak and you know who all the victims are, and you can easily track the growth (or demise) of the botnet within your network. Unfortunately you’re also dealing with a brand new threat and you probably don’t have a malware sample… and that’s where an additional layer of analytics comes into play and more “magic” happens as you automatically begin to identify the domain names that are tried by the DGA-based malware that actually succeed and engage with the criminals server.

Let’s work through a simple example uncovered last week by Damballa Labs. Over the weekend one of our NX monitoring tools identified a few thousand IP addresses within our customer base that were generating clusters of NX DNS traffic very similar to the following:

9ftor9srimbna-q.com, 0sso151a47nztrxld6.com, 0ubpccgkvzrnng.com, dq2yl1zxcmvko2.com, wfj-5i5p4uhq8tylhiz.com, 1sj4rh1i5l8-4tca.com, zv7dfcgtusnttpl.com, om2air5ah5lisj7.com, qmyuvaftpgve2tzwhcjr.com, fndskzqmsob5r2bzby.com, f5p2vxn7dcdkujhbguqb.com, 6q5sigkfu3fl3q.com, zpbm3emcuosopagdttxi.com , trsmw3wceik79krk5.com, qtxfmfyulnnjpxwqo.com, ikh9w-3vdmlndafja.com, udf-szhubujmuhp1jj.com, 4v8hohrphizcas.com, nhb72anz8ifdyzgckqf.com, rcu4n0lzoghuj2.com, dklfebjexiabttkwvgos.com, fjg56xwoupqpdxr.com, drxyuezdllerpd.com, t407bqgh56jbkv4ua.com, 49ubufqnjzvhct.com, n7c3qfpslcjosy-5.com, nvnzihl6krkyfo8zp.com 

While you’d be hard pressed to write a “signature” for the domain names that wouldn’t cause false positives out the wazoo, the features of the combined victim’s traffic (frequency, distribution, commonality, etc.) work fine as a way of associating them to a shared new threat.

Armed with this knowledge, it is then possible to identify similarly structured domain names that were successfully resolved by the victims that also shared timing elements or appeared to alter the flow of NX domain responses. For example, if the DGA-based malware is designed to locate a “live” C&C server, once it’s found a server it probably doesn’t need to keep on looking for more and will likely stop generating NX domain traffic for a period of time.

Based upon our observations of this particular botnet outbreak, it was possible to identify the following C&C servers being operated by the criminals:

• ###.133. ###.247 – idpd1y###-elywj.com
• ###.133. ###.247 – k7-cwubgsrqj###rb.com
• ###.133. ###.247 – omz###1k1vgrqf.com
• ###.133. ###.247 – taqwucpzj###an.com
• ###.133. ###.247 – vhrey###-ooz6ig.com
• ###.133. ###.75 – o###pp1k1vgrqf.com
• ###.133. ###.75 – rm6dol7###cxje-ajl.com
• ###.133. ###.191 – id###yzib-e###j.com
• ###.133. ###.191 – k7-c###gsrqjebzrb.com
• ###.133. ###.191 – ###gpp1k1vgrqf.com
• ###.133. ###.191 – rm6dol###wcxje-ajl.com
• ###.133. ###.191 – taqwucpzj###an.com
• ###.133. ###.191 – vhreyveh-ooz###.com

[NOTE: We've temporarily obfuscated some of this data while we continue to investigate and enumerate the global pool of victims. We'll release the technical details of this particular DGA-based botnet soon…]


So, by this point we know who the victims are, how many C&C servers the criminals are operating, what their IP addresses are and, subsequently, which hosting facilities they are operating from:

• AS13237 LAMBDANET-AS Lambdanet Communications Deutschland GmbH

What about the malware piece? While we know who the victims are, it would be nice to know more about the tool that the criminals behind this botnet prefer and ideally to get to know them more “personally” – if you know what I mean…

As it happens, there are some malware samples that have been discovered in the very recent past that also like to contact C&C’s running upon the same hosts at this facility. For example:

• d977ebff137fa97424740554595b9###

Fortunately, while the malware sample wasn’t detected by any antivirus products, it had previously been automatically executed within our dynamic analysis environment and we’d already extracted all of its observable network features, including an additional (successful) C&C engagement:

• m8###ecc9lsnks6kbcrv7.com using ###.133. ###.75, ###.133. ###.191, and ###.23. ###.139

This, in turn, helped identify the following additional hosting facility based in the Netherlands:

• AS49981 WORLDSTREAM WorldStream

There’s obviously much more to this particular threat, and if you’d like to get involved digging into it and helping with the attribution please let me know…

But, getting back on track, this approach in identifying brand new threats – while sounding like magic to many – works really well! We’ve found it to be immensely scalable and fantastically accurate.

However, there’s one fly in the ointment (as it were)… the approach identifies new threats long before the malware component is typically uncovered by the security community and is independent of the the vector used to infect the victims,the malware tool that was deployed and ultimately the actual endpoint device type.

Think of it this way. Based upon the forensics of the blood splattered bodies and evidence left in the room that the murderer left behind, we know that the victims were bludgeoned to death with an ovoid object approximately 6 inches in diameter, weighing 3 pounds and composed of a calcium shell. We also know that the murderer was 5 foot 11 inches, weighed 240 pounds and wears size 11 Reeboks.

You can keep your metal detectors for all the good that’ll do in this case…

Electronic Accountability in Syria Civil War

In today's story by the BBC covering Syria they note the the conflict has now officially evolved in to a civil war - http://www.bbc.co.uk/news/world-middle-east-18849362

By being legally categorized as a civil war all participants are now subject to the articles of war - such as the Geneva convention. It also means that the persons behind any crimes and atrocities committed during this war can be prosecuted as international war criminals even after the conflict ends.

With the trials currently underway in the Hague against the leaders of the Bosnia war, I was thinking how different prosecutions of war crime in Syria will likely be different - given a considerably more networked world and advances in electronic monitoring.

When I read about the most recent murders of 100 souls, it is inevitable that there will be a kind of electronic trail that did not exist for wars of even a decade ago.

The instructions and target coordinates of the artillery will have been communicated and authorized electronically - not just as written communications, but also as digital voice and CB radio. The point though is that there will be a recoverable record somewhere. Given the high level of electronic eavesdropping by the combatants and other observers (e.g. NATO forces and local non-combatants), even those localized communications between regional commands and tank drivers can be intercepted, stored, and shuttled to appropriate authorities relatively easily.

Those issuing criminal commands can expect to not only be held accountable, but can expect those crimes and attribution to be documented to an excruciating level of detail - leaving little ambiguity to future courts.

Some may argue that encryption will be their savior. I doubt it. The tools they're using to generate and decipher those communications will become available to investigators post-conflict. And, regardless of access, as we're observing with the prosecutions relating to a conflict that occurred practically two decades ago, technology advances. How sure would you be that  even your 128bit encrypted digital radio messages will hold up to decryption techniques and capabilities in 20 years?

No, leaders and those issuing commands will be held accountable with evidence that has never been so rich and attributable.

One Billion Creditcards Stolen

"The details of one billion stolen credit cards were posted yesterday upon hundreds of Web sites around the world." What would we we if that actually happened? (and how do you know it hasn't happen today?)

Practically every day there's some kind of public disclosure about some company-or-other having been infiltrated and the credit card details of a bunch of their customers were stolen. Despite several years of increased disclosures and ever-higher volumes of cards being stolen, I'm not actually sure what the impact is. Granted, every so often you'll see some followup story about how XYZ Corp is being sued due to third-party losses due to the data breach; but really, what would happen if there were more data losses... much more...

I don't know how many credit and debit cards there are in circulation around the world, but I'm pretty sure it's going to be measured in the multiple billions. So what could happen to the world if one billion (i.e. 1,000,000,000) credit cards and all the appropriate card owners details were intercepted and dumped on the Internet for all to see (and use?) at midnight tonight?

You might question the logistics of such an interception and accumulation of that many cards. Here are (just some) some ways in which it could happen:

• A number of popular underground carder forums (used to match buyers with sellers of stolen credit cards) get hacked, and all the accounts of the carders that sell their stolen wares through the forum in turn have their accounts hacked in to. A few domino's fall and, before you know it, the hacker has breached the credit card repositories of a few dozen prolific sellers and steals their stolen data. To undermine those hacker carders and their illegal businesses, the hacker dumps copies of all the data on a few hundred pastebin and anonymous file-hosting sites (making it impractical for law enforcement to take down the data after the fact).
• A small number of disgruntled IT employees at one of the major payments processing companies backdoor a number of critical servers and data repositories - continually running batch jobs that store the relevant metadata in an encrypted archive, that is updated with any new card details. 24 hours after they resign (or are laid off due to restructuring) they extract the data dump they had been preparing for months and dump it on the Internet because they hated the company and what it did to them.
• A foreign power has spent 2 years infiltrating Visa International and a few dozen of the largest merchant banks using digital and human intrusion techniques, and has managed to accumulate the details of all their customers. The attackers filter the stolen credit card data for only US and EU and anonymously release the data in order to undermine those economies.

I don't know how far-fetched the last couple of scenarios are (and I know that plenty of safe-guards have been installed to counter various scenarios) but, at the end of the day, it doesn't really matter. The data exists somewhere in digital form and, given the right skills, circumstances, and motivations, it would be possible to accumulate and dump the details of one billion stolen credit cards.

So, the stolen data is stolen, made publicly available for all and sundry to access and potentially use, what happens now? Does our financial system collapse? Do organizations begin to sue one-another over overestimated (potential) losses they've incurred? Do the owners of those stolen credit cards loose everything? Does anyone who has their own credit card stop using it - loosing faith in that aspect of the banking system?

I think this is a discussion that we really need to have. To be frank, getting hold of the data related to a (few) billion credit cards is getting easier every day. I believe it is inevitable that truly colossal dumps of stolen data will occur sometime soon.

 The impact will be huge.

Lets ignore all of the behind-the-scenes shenanigans the lawyers and bankers will perform and, for once, focus on just one person... and maybe that happens to be you. What happens if you wake up tomorrow morning, head on in to work, stop by the Starbucks on the corner to grab your morning coffee and your card is denied. So you try another card, and it too is denied. You get on the phone to your bank to try to find out what happening and you're greeted with a robo-message that hundreds of millions of the bank-issued credit cards have been stolen and that they've taken action to ensure that no fraudulent charges will be made to your cards. The downside? None of your cards work in the meantime and it'll be at least a couple of weeks before the bank can issue and post out the replacements (and that's being damned optimistic - given the scale of the problem). I hope you have enough cash for gas to get home that evening.