Archive

Posts Tagged ‘Breaches’

An Analysis of the Analysis of the Apache.org Attack

April 18th, 2010 mstarks 2 comments

Over at the Apache blog, you’ll find a nice and detailed incident report on the recent, successful attack on Apache.org. I thought it might be worth a few minutes to share my thoughts on their write-up.

First, I would like to say that the level of transparency in this response is truly commendable. Rather than sweep this under the rug, they have chosen to share the details of what happened, why it happened (more on that in a moment) and what their plans are to, hopefully, prevent future breaches.

I encourage you to read the entire post, because it is a good account of how actual, real-world attacks happen. Targeted attacks take advantage of trust (both in people and machines), shared and weak passwords, too much privilege and an assortment of other security 101 vulnerabilities.

The attacks consisted of a XSS vulnerability, brute-force logins, a shortened URL, password sniffing, password re-use and social engineering. Pretty typical stuff, really.

What I find most interesting about this report is the emphasis on technical countermeasures in the What are we Changing? section, when the attack succeeded primarily due to vulnerabilities in human beings.

  • The Infrastructure Team members clicked on a cloaked and untrusted link, which launched a XSS attack.
  • A brute force login succeeded against a poorly chosen password. But prior to it being successful, no one seemed to be getting alerts on so many failed login attempts.
  • They once again exploited the Infrastructure Team by getting them to log in with a password that the team members, themselves, did not choose.
  • They took advantage of cached passwords on the server.
  • Slicehost didn’t respond to the attack when notified, which enabled one host to continue its attack against someone else.

These are all people issues. It’s the same stuff that we security types have been trying to hammer into the brains of people for years now. There are certainly technical countermeasures which could have helped, but this was an attack on people.

It’s easy for us to play armchair quarterback and be critical of the response, however that is not my intention, Rather, it is my intent to simply cast another light on the response so we can all learn and secure our assets more effectively.

A Public Lesson on How to Handle a Breach

March 15th, 2010 mstarks No comments

When I first heard about this, I thought to myself, “Say it isn’t so. Tell me this is just a big misunderstanding. Tell me that my favorite place to buy cables at great prices wasn’t breached.” Alas, it seems to be true. Monoprice.com had a breach.

I wasn’t too concerned since all of my credit card numbers are unique and automatically generated, and all of the e-mail addresses I use for businesses are also unique, but just the same, I checked my statement. So far, all is well.

As a security guy, I suppose I should forever relegate monoprice.com to the vendor blacklist. After all, they must have been doing something wrong to allow the bad guys to get in, right? That may indeed be the case. They may have had security so bad you could drive a truck though it. Then again, maybe it was very good.

Breaches happen. It’s very, very hard to cover every known threat, let alone the unknown. Security professionals have to anticipate and protect against all threats, while the criminal only has to find one vulnerability. Most of the time it’s not even under our direct control. We are charged with the responsibility of security and get the blame when a breach happens, but encounter fierce resistance when we tell management what really needs to be done to properly secure a site.

Unlike Gexa Energy, who took almost a year to notify affected customer of a breach, monoprice.com took the bold move of prominently and publicly placing a warning on the front page of their web site.  They further went on to stop accepting orders while the breach investigation was continuing. Right now they’re trying to get back on their feet.

Preventing a breach is difficult enough, but the truer measure of an effective security program is how you respond to a breach. Do you issue carefully-crafted letters from the PR department or do you level with your customers? Do you attempt to shun responsibility or do you recognize your mistakes and learn from them?

It seems that monoprice.com recognizes its responsibility to its customers and is doing the right thing. That, combined with my personal risk-mitigation strategies, probably means I will do business with them again.

How Not to Handle Notification of a Potential Security Problem

February 19th, 2010 mstarks 1 comment

Awhile back I signed up for the CouponMom.com newsletter (hey, who doesn’t like to save a few bucks), using a very unique and distinctive e-mail address used only for this purpose.

Awhile later, I started to get garden variety spam to this e-mail address (Viagra, etc).

There are a few reasons this could happen:

  1. I have been compromised and the spammers think it would be clever to use that address.
  2. Spammers start spamming that address as a matter of chance or because they think, “hey, this guy likes Coupon Mom, maybe he’ll like some male enhancement!”
  3. Coupon Mom is supplementing her income by spamming or selling the data, which makes its way into spammer’s hands.
  4. Coupon Mom has been compromised.

Usually, when this happens, it’s number 4.

I got to thinking, “hey, they might want to know there might be a problem. I should tell them.”

I fill out their contact form and wait. More than a week goes by with no response.

I try to post a cautionary word to the forum. More than a week goes by and I don’t pass moderation.

I fill out the form again, indicating that it would be better for them to investigate this and notify their members of a breach, if one happened, than it would be for me to speculate about it.

Finally, I get a response. The response, in part, states:

You must have signed up for a Google advertiser link on the site, since the email signups for my site are not shared with any other party.

I am sorry you have had this experience, but caution you against publicly slandering The Coupon Mom program and our member database as the source of the unsolicited email.

Can I say that the Coupon Mom database has been breached? Categorically, no. But I can say that there are symptoms which, in my opinion, should cause a reasonable person to take a closer look.

What’s the lesson here? When someone tells you of a potential problem with your security, don’t just assume you are impenetrable. That person may serve as an early warning of a serious problem you would want to be on top of.

Should Hannaford Pay?

October 12th, 2009 mstarks No comments

Awhile back, I wrote an article for the “Security Catalyst” blog about the economics of data breaches. In the article, I wondered if companies should compensate customers for poor handling of their information, even before a breach. Since companies often roll the dice with poor security, they have little financial incentive to change their behavior unless a breach happens and it hits the bottom line.

Now, Hannaford, who helped to enable the exploitation of millions of credit card numbers by their poor handling of the information, may be forced to compensate the victims.  At issue is whether one’s time and effort to prevent further damage to their identity, is worth compensation.

Previously, a judge ruled that since the banks offered the customer zero-liability protection, the customer wasn’t owed anything by Hannaford. That gave Hannaford some level of protection against costly lawsuits.

However, as the courts are now considering, one’s time may have value. If one is spending time trying to clean up Hannaford’s mess and prevent further harm, then maybe they should be compensated.

I agree that we need strong financial penalties to send the right message to the custodians of our information. Money seems to be the only thing most large corporations understand, so we need to make it more financially preferable to protect the information properly in the first place.

My concern is that we won’t really see improved security because of this. I envision the companies merely passing the breach cost off to consumers as they would an increase in corporate taxes. I’m not confident that they would “get it” and really start to take the responsibility of data custodianship seriously. That takes a conscience and that’s something many large companies lack.

To be fair, I’m also concerned that data breaches in companies who practice security very well would be seen as equivalent to those who shirked their responsibility. I work in the security profession and I’ll be the first to admit that even those who seem to be doing everything right have breaches. All it takes is one missing patch.

In the end, perhaps the solution to work toward is something of a hybrid between financial penalties for poor handling of information–even before a breach–and criminal penalties for the executives who enabled a breach to happen under their leadership. Just as one who is present at a murder scene can be charged as an accessory to a crime, perhaps an executive is also liable for enabling a breach to happen.

Finally, let’s not forget that the criminal who exploited the vulnerability is most at fault. Although the data custodians deserve their fair share of the blame, it takes someone at the other end of the keyboard doing something they shouldn’t be doing for a compromise to happen.