Fascinating breach detail: Illinois Department of Financial and Professional Regulation
Here’s detail from a InformationWeek story, “Hackers Blamed For Data Breach That Compromised 300,000:”
A hacker broke into the computer network at the Illinois Department of Financial and Professional Regulation this past January and accessed a server that held information on about 1,200,000 people who have licenses or applied for licenses with the department. Susan Hofer, spokeswoman for the department, said in an interview that about a quarter of the stored information was compromised.
A quarter of the information? Really? I’d love to understand their logs, which seem to be well designed. Compare and contrast to all the organizations that say “we’re not really sure what happened.”
Kudos to the Illinois Department of Financial and Professional Regulation for having good logs.
“The server, according to Hofer, held sensitive information — names, addresses, Social Security numbers — on people who hold or have applied for loan origination licenses or for real estate broker and agent licenses. The server also was being used to test new software.”
Mixing production and test software, and using live data for test isn’t quite a best practice.
I dunno about their logs, but determining that 300K of 1200K could be done through a variety of means having little to do with log quality. Details would help, especially since they seem to have waited two months to look at those logs (which of course is extremely common).
1. I didn’t make mention of that mixing here, just that they had logs.
2. http://www.emergentchaos.com/archives/2005/01/ben_rothke_on_b.html
3. http://www.emergentchaos.com/archives/2006/08/so_this_ummm_friend_of_mi.html
Chris said: Mixing production and test software, and using live data for test isn’t quite a best practice.
I’m too lazy to look that up, but isn’t that a violation of GLBA?
My guess is that it was an iterative attack against the query string on the Web site, so they were able to run a `grep -c “attack_string”` against their Web log and 400,000 popped out the other side.
Of course, let’s not forget that this would be a late-1990’s type of Web App vulnerability, right up there with hidden form fields for prices in shopping cart apps. Makes me shiver to wonder how many “modern” vulnerabilities they still have.
As a former state employee (not of Illinois), but a resident of Illinois, that would be the only way I’d expect to see them able to provide that level of detail.
The real questions I’d like to have answered center how long the attack ran before they noticed it, how they noticed it, and why it took that long (assuming it was, in fact, an iterative attack against the Web server).
My guess is that it was an iterative attack against the query string on the Web site, so they were able to run a `grep -c “attack_string”` against their Web log and 400,000 popped out the other side.
Of course, let’s not forget that this would be a 1990’s type of Web App vulnerability, right up there with hidden form fields for prices in shopping cart apps. Makes me shiver to wonder how many “modern” vulnerabilities they still have.
As a former state employee (not of Illinois), but a resident of Illinois, that would be the only way I’d expect to see them able to provide that level of detail.
The real questions I’d like to have answered center around how long the attack ran before they noticed it, how they noticed it, and why it took that long (assuming it was, in fact, an iterative attack against the Web server).
SQL injection is believable, too. The DB may maintain a log of how many records a query returned.
This reminds me of one of the NY cases I have reports on, but in that case it was an overzealous search engine that did the deed: http://www.cwalsh.org/BreachInfo/primary_sources//pdfs/NYSBanking-20060829.PDF
They assessed the extent of the exposure using web server logs.
Speaking of test data issues, here’s a great blog post on the topic:
http://storefrontbacktalk.com/story/061507testdata.php