IRS has reported that  thieves stole tax information from 100,000 taxpayers, pretty disturbing news on multiple levels. The first level of disturbance is obviously that an organization like the IRS which has more information on every single citizen – probably more than the citizens know about themselves – got hacked with that magnitude of a data breach is something to worry about. The other interesting level is that the attackers already had the victims’ Social Insurance Numbers, address information, date of birth and tax filing status.

The “Get Script” feature was taken-off line temporarily after the attack, so we didn’t have a chance to look at it closely. However, several resources are available online that pretty much sums up how it works.

Several Notes on The Application’s Security Design and Architecture:

1. Authentication Failure: Good authentication requires more than one of the following: “Something You Know”, “Something You Have” and “Something You Are”. Brief description of these are found here. IRS used 4 “Something You Know” factors, beyond the Social Security Numbers; The Address, Date of Birth and Tax Filing Status don’t really add much security. Apparently, the attackers didn’t even have to guess as they already knew this information. The question here is if they already knew what they are stealing, so what’s the point? This question will be answered later with more to come in the analysis section

2. Lack of Proper Attack Resistance Capabilities: Attack resistance is the application’s capability of preventing the attacker from executing an attack against it. To be fair; very few applications get this right and most organization outsource this to perimeter security and intrusion detection tools in particular. It was reported that IRS had several IP filters preventing requests after several “hundreds” of requests have been made from the same IP. A problem with this technique is that it does not work because attackers can randomize their IPs. While IPs are still important in detecting automated attacks, timing and geolocation are also important factors.

3. Using Predictable Data in Authentication is Bad: Using the Social Security Number as part of the authentication process is a big no-no in sound  security architecture practices for several reasons: first, the possible valid social security numbers are limited, there are several websites that explain the structure of a valid Social Security Number and others that will help you generate valid ones. So generating valid ones is extremely simple. Now, most probably the attackers didn’t go that route and they got this data from somewhere else. Nonetheless, using a predictable data in the authentication process is definitely a bad idea. Additionally, having the user to enter their Social Security Number in there could raise a bunch of other issues such as: caching, shoulder surfing and more.

Why Did They Do It?

Again, the big question is: if the attackers already had the victim’s Social Security Number, Data-of-birth, address and filing status, then what’s the point? what else could they gain from this hack? The answer is a lot…

1. Better Price for the Data: It turns out that a Social Security Number is only worth something ($3 – $5 each According to CNNMoney) if it was packaged with a Full Name. Assuming the attackers stole the PII (SSN, DoB, and Street info) but they didn’t have the victim’s names, full address and marital status, guess where they would find  this information? In the Transcripts, the image below shows a sample transcript which shows all the data the attackers would need to make a good sale of about $300,000 – $500,000.

2. Fraud: IRS reported the following:

“In all, about 200,000 attempts were made from questionable email domains, with more than 100,000 of those attempts successfully clearing authentication hurdles,”

 

This is a 50% success ratio (100K success out of 200k trials), so could this have been a data cleansing operation? This information was  stolen from somewhere but it didn’t have enough information to perform a full scale fraud operation. IRS paid identity thieves $5.2 billion in 2011 alone and according to MSN News:

“The agency is still determining how many fraudulent tax refunds were claimed this year using information from the stolen transcripts. Koskinen provided a preliminary estimate, saying less than $50 million was successfully claimed.”

3. Identity Theft:
With almost all the information a thief needs to steal someone’s identity; nothing stops them now from  launching identity theft attacks. Adding insult to injury; according to the 5th annual study conducted by the Ponemon Institute, a Michigan-based research center, medical identity theft rose sharply in 2014, with almost half a million reported incidents. The compromise of healthcare records often results in costly billing disputes. Ofcorse regular identity theft is also a possibility but the high success ratio (100,000 successful attempts out of 200,000) suggests that the data used was fresh which brings to mind the Anthem Health Insurance Hack.

The bottom line is it does not have to be like this; these attacks could be avoidable with simple  or more  comprehensive  security approaches. The billions lost to attackers and fraudsters could be put to other good use with only a fraction of that amount spent on security in the first place rather than covering up and dealing with the damage.

White Paper - Proving Adherence to Software Security Best Practices

White Paper - Proving Adherence to Software Security Best Practices

Industry standards and the best practices for developing secure software. Please provide your email and name to receive your copy.

Success! Your copy is on the way.

eight-myths

The 8 New Deadly Myths of Application Security

If you want to get clear on the best strategy for software security in your organization, you must first get clear on the problems. Many organizations identify the problems as cryptography, insecure SSL practices, or authentication issues.

This is why organizations get trapped within incorrect mindsets to find themselves struggling to prove proper adherence to software security best practicesor worse, in a middle of a data breach.

Enter your name and email below to understand the myths and start an application security program that works.

You have Successfully Subscribed!