May 29, 15 12:36 am

Was this post helpful?

Reading through the IRS Hack: Failures and Analysis

May 29, 2015
| by:
Sherif Koussa

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 The Chicago Tribune:
"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 with our 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.

Was this post helpful?

About the Author

Sherif Koussa
Sherif Koussa is OWASP Ottawa Chapter Co-Leader, Software Developer, Hacker, and founder and CEO of Software Secured and Reshift. In addition to contributing to OWASP Ottawa for over 14 years, Sherif contributed to WebGoat, and OWASP Cheat Sheets. Sherif also helped the SANS and GIAC organizations launch their GSSP-Java and GSSP-NET exams and contributed to a few of their courses. After switching from the software development field to the security field, Sherif took on the mission of supporting developers shifting security left, and ship more secure code organically.
Share This Post

Leave a Reply

Your email address will not be published.

Related Post

Jul 4, 2023 by Cate Callegari

Common Security Misconfiguration Habits

Read more

Was this post helpful?

Jun 28, 2023 by Shimon Brathwaite

Risk of Broken Access Control

Read more

Was this post helpful?

May 17, 2023 by Omkar Hiremath

Risk of Security and Monitoring Logging Failures

Read more

Was this post helpful?

Office

301 Moodie Dr. Unit 108
Ottawa ON K2H 9C4

Designed by WP Expert
© 2023
Software Secured
cross