User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive
Have been keeping up with the congressional requests to Equifax. Am proud of them for the questions they are asking.  At face value many of the queries in the letters do not seem like much.  That is the best part.  The details will be in the answers given.  Well done. Those people who have worked in Information Technology in regulated environments will understand. Even learned about some of the government contracts they have. 

So what do I think happened?  It's definitely speculative.  Equifax said there was an application vulnerability and the 'criminals' obtained access to the database files.  "Database Files" may be a poor choice of words and am going to assume they meant access to a database which means something different.  The amount of information stolen is most likely stored in a relational database such as Oracle, DB2, SQL Server, etc.  My guess is Oracle or DB2. There is a lot of confidence out there that the application was a free open source framework that is used to create web applications.  The timing of the hack coincides with a recent finding and disclosure of a 'bug'.

At first I thought the hackers used SQL Injection to get the data.  May still be the case.  What is SQL Injection?  Ask Bobby Tables or let me try to explain for him.  Those little text boxes on websites that you fill in are often pieces of information that go into a database.  If that piece of information you type in is a SQL (the language used to communicate with a database) statement then it could do something nefarious. 

In Bobby's case, his name is actually a SQL command that removes all of the student information in the school's database. Don't fear, there are plenty of ways to prevent SQL Injection from happening.  Most programmers are aware of it and take it into account when developing. In fact, a lot of programmers take pleasure in finding issues with someone else's code.  Good natured ribbing.

It's hard to be completely sure what happened.  Equifax has been quiet about it. Which is a little disappointing.  I am curious about what happened and the right thing would be to share some detail so other companies can prevent it.  Their silence is concerning.  It is probably too late now with all of the legal activity coming it's way.

An uniformed calculated guess as to what I think happened....
- Hackers exposed a vulnerability with a web page that allowed them to send a http request with code that could be executed on the web server.  They basically were able to do whatever the application had permissions to do on the server.
- They were able find the database credentials the application uses....and use them.  The credentials may include the server the database is located on, the port number to connect to the database along with a username and password.
- Then they used SQL commands to start pulling information.  Most likely placing it on some server connected to the internet.

That sounds pretty easy, doesn't it?  It could be easy.  I won't go into too much detail about the different ways to prevent this scenario, but it is easy to do too.  Cut Equifax some slack on the vulnerability in the "application" even if it was the recently discovered one with Apache Struts. Coordinating time to bring an application down to patch can sometimes be challenging. Hacking is going to happen.  Attempts may be happening on your device or computer right now.  If the hacker(s) obtained database files then this scenario doesn't completely fit. Getting the 'files' just doesn't seem likely. 

Let me try and explain a little bit about database security.  Picture a large hotel with thousands of rooms.  All of these rooms have files with specific data.  Each room also has keys that can open the door to the room.  One room key will let you do whatever you want to the files, another key only lets you look at the files, and another let's you add and remove files.  The hotel manager also has a master key that can open all of these rooms and do whatever it wants to the files.  Now that we have this key thing figured out..One room has stacks and stacks of files with peoples names along with their social security numbers and dates of birth.  Another adjoining room has files with addresses, phone numbers, etc.  Multiple people share the same address.  To save space and keep addresses consisent, there is no need to have more than one file for an address that is used by many people.  Another room may have files with credit card numbers, payments, etc.  This is a simple example of how a relational database is put together. 

To get someone's SSN and address for a report you will need the keys to at least two rooms, or the managers key.  Then you'll go into the rooms and get the related files and data for your report.  Anyone with keys to the rooms can do this.  What if you have an office across the street and have someoone get the information for you?  They'll need the keys too.  While they cross the street they could encounter a thief or drop the keys on the sidewalk for someone else to find.  The keys would now be in someoone elses posession.  This someone else can now open the doors and make copies of all the files.  Definitely a vulnerability. Let's call this access to the files the honeypot.

Putting a combination lock on the door could prevent unauthorized access. The hotel could also make a decision to employ people that have defined procedures in regards to what they can do with the files.  Each one can only go into pre-defined rooms and perform one activity.  For example, placing a new file in the room.  Nobody else can go into the rooms except these employees with the pre-defined tasks.  When the person crosses the street for the report they just give the hotel employee that performs the task the name of the person they want the report for.  No need to have keys and go into the rooms anymore.  There is someone that will do it for us.  Losing a key when crossing the street will not result in all of the files being copied because you don't have the keys to lose.  There still may be a doppleganger out there that can ask for something to be done in the rooms, but to get all the files the doppleganger will have to ask for each one individually.  Still a risk involved with using the hotel employees.  Much better, but not perfect yet.  So the hotel re-writes the files in a language that nobody can understand except the person who re-wrote them.   When the report comes back it won't make any sense so you have to ask this odd speaking person to translate.  The doppleganger can only get useless information.  They won't know who or where the translator is to help them.

To make things even better, you can build a walkway from your office to the hotel.  Add some doors, combinations, and super secret passwords to cross the walkway.  Build a wall around the hotel, hire security gaurds, put motion sensors in place, etc. the way, the hotel managers key is locked away in a safe and can only be used in emergencies.  At least that is the way it should be.

There is more to this security thing.  Wanted to share a simple explanation of how things work.   We just topically covered data modeling, sql injection, DML, stored procedures, views, database security, encryption, firewalls, etc.  :-) 

Couldn't figure a way to write this with a Dr Seuss theme.  Maybe next time.


Add comment

Security code