Data Breaches

Blaming the Auditor for Bad Security

Heartland Security has attempted to point the “Public Finger of Blame” at the hapless QSA auditor they used for PCI compliance, saying that the “QSA let us down.” So who is in charge of security, Heartland or the auditor?

Security is a corporate posture, not a pass/fail compliance test. You can pass the test and the next day change settings on the firewall that turn it into a router. Is the QSA still responsible? Nope. We don’t really know all the details of what happened at Heartland. But we do know that being compliant does not equal being secure. Never has, never will.

For a well written post excising this “Finger,” check out this article on CSO, written by Ben Rothke and Anton Chuvakin. Let’s just say that blaming the door lock when you’ve left the windows open is not a viable public relations option.

The corporate security posture should provide a mandate, from the top down, of the company’s position on information security. The power of C-level executives enforcing the mandate has to come into play. Otherwise it’s just window dressing - and open windows are no way to manage the security of your environment.

What IS the corporate policy? How effective is it? Is management promoting AND funding it? Policies that are effective also protect the information of employees. Everybody wins, even, long term, the stockholders.

Which One is More Clueless? I Can’t Decide

I ran across a story about a former employee who “broke into” his employer’s computers, according to a news story from a TV station, entitled Cops: Former Worker Hacked Casino Computers.

Now, here’s the real story: If you read the article, the guy did not “hack in.” He used his VPN connection from his home (Clueless Number 1) to go into his employer’s network and access computers to mess up some programming.

His VPN connection had obviously not been disabled (Clueless Number 2) by his employer.

The police (Clueless Number 3) referred to him as a “computer whiz” for using his VPN connection from his home to get into his employer’s network.

Whiz? Cheese Whiz, maybe?

Things NOT to Do When You’ve Been Hacked, Part II

I finally asked that deadly question: “What do your Incident Response Procedures say?” Whoops, there goes all the buddy-buddy geekiness: I have morphed into The Auditor Who Asks Questions.

“Umm, well, they pretty much say to do what we just did.” I notice the vagueness of the reply, but decide to let it pass, for the moment. They don’t really know what their procedures say they should do. Probably the procedures are too generic.

“OK. But what if he has jumped to this box from another box he compromised first? How would you know?” More pained and irritated looks coming my way. “By now, you won’t really be able to tell what happened unless you go to a backup and start analyzing whatever you can find for connection information. But that won’t necessarily give you rootkit information. If you’re lucky, you might see a netcat connection, but only if he hasn’t erased the Event Logs.”

“Even so,” I continue, knowing I am now excluded from the Kool Kids Klub, “If he has gotten your SAM database off the server, wouldn’t he know the administrator password? Is that password the same on every server?”

Turns out the password IS the same, and the Event Logs overwrite according to defaults. Now they can’t trust the server OR the administrator password. But I’m leaving, and besides, this isn’t an audit anyway, just some consulting.

So they left the server alone, because “There are all those websites on it, the users would scream and we’ll watch it carefully.” And never mind about passwords because “It’s a really tough one they’ll never crack.”

I wonder what will happen next, don’t you?

Things NOT To Do When You’ve Been Hacked, Part I

The problem with being a “geek” is that we truly love to tinker, to fix, to improve, to test….etc. So when you announce to a bunch of us that a website on the network has been broken into, there’s lots of leaping into action.

Which is exactly what you don’t want to do. At all.

While visiting a client to talk about network architecture, an engineer rushed into our room to announce that one of their websites had been hacked. We all hopped up and went out with him. (My lecture was boring, anyway.) I wanted to see what they were going to do, and if they were going to follow their own Intrusion Detection Policy. Plus, I was, like them, vastly interested.

Turns out it was a fairly generic attack, with the break-in artist simply using the website for cross-site scripting and redirection.

By the time we got there, two engineers had already been working on the web server, analyzing the code in the html, and checking other settings on the server. They took the web server offline, removed the offending code, looked at the event logs and brought it back up. All good, they said.

“Not really,” I said. “You do know that you can never trust this box again?”

“Not to be a party-pooper, but there’s no way of really knowing if a rootkit has been installed, is there? He could come back tomorrow.”

The four geeks looked pained. “What should we do?”

“Well, we can start with reformating the disk and reinstalling the OS.” I knew the minute I said that I was not going to be the most popular girl in the room. That sort of thing is awfully tedious and boring; no fun for geeks.

“But there’s ten other websites on this server!” Oops, this was going to be a LOT of work.

We segued briefly into the advantages of virtual machine backups, and then returned to the discussion of what to do.

I finally asked that deadly question: “What do your Incident Response Procedures say?”

ATMs that just spit out money - Nice!

As you may know, one of my favorite posting topics has to do with ATMs. I call them Automatic Theft Machines because there are way too many stories of equipment being hacked, and/or swiping hardware being installed, or people just driving away with them.

Well, along comes a story about the progression of this issue: In Eastern Europe, the bad guys have perfected the art of getting the machine to spit out all its money on demand.

According to the article (linked above), authorities say there must be some sort of inside access to allow software to be installed. The articles claims that after unlocking the security, the inside equipment is quite vulnerable.

Hmmm, hard on the outside, yummy and soft on the inside….where have we heard that before? And something else interesting to note: many of the ATMs appear to be Diebolds; the same company that makes voting machines for us……and was implicated in another attack earlier this year, also in Eastern Europe.

The ATMs utilize a scaled down version of Windows XP, which actually doesn’t make me feel any better at all.

Encrypt Your Laptops NOW

SC Magazine has reported that a laptop belonging to the State of Oklahoma was stolen, with 1 million names, Social Security numbers, birth dates and home addresses of Oklahoma’s Human Services’ clients receiving benefits from programs such as Medicaid, child care assistance, nutrition aid and disability benefits.

All this was secured with a password. The State of OK seems to think that is adequate protection - has nobody there heard of a Linux boot disk? It will ( and probably already has) taken a cracker ten minutes or less to gather the SAM database, and probably not much time to crack the password.

No excuses! Get it done. The cost of losing a laptop is now estimated at $50,000, after the cost of corporate security efforts, bad publicity, and lawsuits. No one is too small to get sued.

The Beginning of the End for PIN Codes

Yesterday Wired released a story that reveals a startling detail about the TJMaxx data breach: hackers were able to cash in on stolen debit cards because they had a way to crack PINS.

This “minor detail” was buried in an affadavit last year, but Wired has put it together with some other information afloat on the NET, and the article is a really good read on what happens to your PIN from your debit card as it transits various networks to receive approval. Your PIN gets decrypted and re-encrypted by a Hardware Security Module (HSM) each time it transits a network. Lots of opportunities for capture with the help of an insider or some sniffing malware.

“While statistically not a large percentage…in 2008, attacks against PIN information represent individual data-theft cases having the largest aggregate exposure in terms of unique records,” says the report. “In other words, PIN-based attacks and many of the very large compromises from the past year go hand in hand.”

Although there are ways to mitigate the attacks, experts say the problem can only really be resolved if the financial industry overhauls the entire payment processing system.

Ouch.

Clearly, PIN-based authentication has been cracked, and will be cracked more and more. Leave your debit card at home and Pay Cash Instead.

When News Isn’t News

A client of ours was notified recently by their financial institution that some of their credit cards had been compromised by a vendor.

The rational question followed: “Which vendor?” To which the bank replied, we aren’t going to tell you in order to protect the reputation of the vendor. Given that a high percentage of vendors have had more than one security breach, why are banks protecting them? Wouldn’t you want to know which company had been broken into so that you could pay extra attention to transactions from that company?

This kind of financial behavior is what drives people to enacting regulatory requirements for notification.

“Citibank contacted my husband and told him that they would be re-issuing him a new account number because a “major merchant” had notified authorities that its secure data had been compromised. They would not release the name of the merchant, instead saying that it was “the kind of thing we would probably hear about in the news,” she writes.

Why do we have to hear about it from the news? Why are we protecting organizations that are not protecting their data? Because it would cost the vendor money, and that would impact the profits at the bank. It’s the same reason VISA doesn’t shut down big PCI violators - and it’s why we really need independent oversight.

Making it Easy For Hackers

How many rules do you have in your firewall? How many rules allow access directly into your network? How many rules allow ANY/ANY?

The more rules you have in your firewall rulebase, the higher your risk of allowing attackers in. I’m not talking about opening access to your webserver in the DMZ. But the rules are not linear, which many people (including some professionals) do not understand.

Firewall rules are inherited, like Access Control Rules, so that you can end up with some unintended consequences. If the ANY/ANY rule is above the tighter rules, the ANY/ANY rule will prevail. This is exactly what happened in a rulebase I looked at not too long ago. The company was not convinced until we ran a packet capture and I could demonstrate that IP addresses from Russia AND China were banging on internal IP addresses.

Allowing ingress to your internal network using any protocol is fraught with peril. Terminal Services/RDP allowed in? Somebody will be running scripts against the Administrator ID trying to log in all the time. FTP? There are too many ways to badly configure an FTP server. That’s what a DMZ is for. So is your Outlook Web Access. If any internal server is compromised, it becomes a jumping off point into the rest of your network. This goes for printers, too, which have little miniature hard drives.

ANY/ANY rules are red flags to the auditor - they tell me someone is sloppy, and hasn’t taken the time to ascertain what ports are absolutely necessary to open. Yes, we’re all busy, but think how busy you will be cleaning up after hackers. Or, worse yet, cleaning up your resume on the unemployment line.

Have a rule labeled TEMP? Put an expiration date and a contact person in the notes. If you are run over by the turnip truck, the next engineer will have a clue as to what is going on and will offer up burnt offerings in gratitude.

Hijacking Your Website

With all the publicity going on about the Heartland breach, not much attention has been paid to what happened to CheckFree last December. The event is also much more challenging to explain to the average consumer, but it was a significant technical attack that you and I should be aware of.

And they did it without hacking into CheckFree. Simply, they redirected visitors to a faux CheckFree customer login page on a Web site in Ukraine that tried to install password-stealing software.

There’s all sorts of pharming, phishing (I’m getting a little weary of the “ph” naming convention, frankly) out there. What is important here is that the bad guys got into the Domain Registrar in order to redirect traffic. They didn’t go for breaking into domain servers; they used a legitimate admin name and password to log into Network Solutions and change the information.

So think for a moment about how you maintain your domain registration, and how important that is to your company. Over the course of five hours the bad guys captured who knows how many IDs and logins for CheckFree.

CheckFree is not just any company, it’s owned by Fiserv, and is the backend company for financial institutions that utilize billpay services.It manages between 70% and 80% of this type of financial service. So while no data was captured from CheckFree servers, the possible loss of login information is significant. Up to 160,000 users may have been impacted.

Even though the information on Network Solutions was corrected after five hours, the badguys had set up the information to last for 48 hours in the TTL (Time to Live) configuration. So unless a massive PUSH was made (and it wasn’t) DNS servers that received that information didn’t have to check back for another 48 hours.

Registrars are becoming increasingly attractive targets. At one point the IP address in the Ukraine held multiple fake sites.

It’s worth thinking about how your business might be impacted. And what kind of username and password you’re using with your Domain Registrar. How was the ID and password to Network Solutions captured? They don’t know. Can we imagine an admin’s PC getting infected?