Archive for the ‘General’ Category.

Encrypted Files, Check; Password saved with the Files, doh!

You would like to think auditors would be doing things securely.   Even though the auditors sent on site are often fresh out of college, you’d like to believe that the company they represent has been around long enough to be versed in security practices.   Unfortunately that often isn’t the case.   How many times when they have asked for information have I wondered if this is part of the audit.   “Am I dumb enough to mail the auditor unencrypted information about my internal network to their external account.”

In a recent case cited by Sophos as reported by the Birmingham News it is worse than that.  Ernst & Young auditors lost a USB fob.   Fortunately the information was encrypted.   Unfortunately the password was with the fob.   Obviously that defeats the purpose.  Some people are just destined to be examples for others.

 

Dear Bruce – On Zero Days

I dont mean to do a pretentious open letter, think of this as more of a writing style than an actual letter.
Hey Bruce,
I was trying to understand your comments from the opening greetz at shmoocon this year.
As I understand it, you’re saying that we need more public zero days to secure people.   That caused me some cognitive dissonance, so I tried to spend some time thinking this through so I could understand your point better.   Let me know if I’m misrepresenting you.
I found your defcon 15 slides where you seem to talk about this a bit.  (my paraphrase)
 ’full disclosure is dead’   Whether you believe in “responsible” disclosure or not, the people in the bug bounty programs believe in it, so the choice is really get paid or not.   As a side effect people aren’t dropping oh-days all over conferences, which sucks as a conference organizer.
In your slides, you said “[the people selling bugs] are profiting at the expense of the end user.”   How is that?
I’m guessing it is because many software companies patch very very slowly except when there media pressure due to public exploitation.   That leaves a hole in which private exploitation can take place if the bad guys also found the vulnerability.
Lets not forget that dropping a zero day starts the clock early.   The bad guys are exploiting while the good guys at best have a workaround.   I have a hard time seeing that a good thing.  I’m guessing your answer would be at least then you know about the vulnerability
As a guy doing the vulnerability management program at my company, I like the predictability of patch Tuesday.   I’ve got plenty of other things to deploy.   Those unexpected patches really foul things up.
Full/Responsible Disclosure approaches a religious debate with some people.  I dont mean to mean to do that.

Shmoocon 2012: Credit Card Fraud – The Contactless Generation

The idea of Credit Card fraud through the new generation of “contactless” cards isn’t new.   It was even in a NCIS episode last year.   Here’s a news story that was done on the problem.  Chris Paget presented a talk at Shmoocon 2012 titled “Credit Card Fraud: The Contactless Generation.”  The hook that got me into the talk was finding out if any of the common countermeasures are effective.

Credit Card companies are quietly deploying new cards that have a RFID chip to allow for contactless payment at terminals that can take such.   When it is talked about, Credit Card companies present it as more secure and similar to the pin and chip system used in Europe.   The issue is that it is actually less secure.

The card is ready to respond to any reader whether in the grocery store or while walking down the street.   A bad guy could have a reader and “clone” your card with you being completely unaware.   With previous card thefts, a bunch of people would have a fraudulent charge, and an investigator would notice that all of the cards were used at a specific company.   It was easy to find a credit card skimmer installed at the location to collect card data.   If the bad guy is collecting data from people who walk by on the street, a virtual pickpocket if you will, there isn’t a way to determine the malicious source.

We’ve all ordered items on line and had to provide the CVV number off the back of the credit card.   The credit card actually has three CVV codes.   One encoded in the magstripe, one you can read off the back and a variable number given when the contactless payment is used.   If I made a contactless payment at the store, and the number were harvested they wouldn’t be able to reuse that CVV.   The issue is that a bad guy with his own reader could ask my card multiple times for a CVV.   He can then attempt as many transactions as he collected numbers.   If I made a charge before the attacker attempted to use the stolen credentials, the other numbers are not valid.   It is like trying to use the wrong securID token.   You’ll get locked out.

While CVV offers some protection, the bad guy will likely be able to get single transactions performed against a wide number of victims.   Many if not most people don’t monitor their credit cards activity so there is a likelihood of success.

So what can you do about it?

Accepting the risk is always one way to deal with it.   American credit card laws make it pretty easy to dispute charges.   If occurences are rare than this could be a rational choice.

Protective sleeves, tin foil, and passively shielded wallets have been a proposed solution.  This is generally laughed at by anyone not going to Defcon because it seems like overkill or paranoia.   Hopefully this report on Chris’ talk will convince you it isn’t paranoia.   Unfortunately Chris’ research shows that a determined attacker most likely wouldn’t be working with a low powered receiver like you’d find in a store.   Those are designed to read cards from two to four inches away.  An attacker would be using a higher powered right from up to 25-30 feet away.   He tested the various common shields and found them lacking.   Some might be ok against specific wavelengths.   But they sounded like a waste of time and money.

Chris’ company is working on GuardBunny, an active shield to protect against this sort of thing.   Until then you can microwave your card to kill the RFID chip and still have it work with the traditional swipe method.   3 seconds kills the chip, 5 seconds sets it on fire.   Given the wide range of Microwave power, I’d recommend not doing that.

I think for now, I’ll stick to aluminum foil when on trips to hacker cons, while their the card stays in the safe away from the convention floor.

How do you know my password?

I don’t plan to mention every security related thing I see in TV, but this one made me chuckle.

On The Finder, a new show on Fox, Michael Clarke Duncan’s character, finds a character logged into the computer as him.   He asks in his booming voice, “How do you know my password?”

The answer, “you say it to yourself as you type it in.”

I’ve caught myself doing that a few times.   The worse is when the password is a phrase from a song.

ProxyClient, Error 400 and MS12-006

This is just a case of bad timing.

Back in August, BlueCoat implemented some changes to the BlueCoat WebFilter.  It introduced some new categories and renamed some other categories.   On the ProxySG, no change was necessary for the renamed categories.   However for ProxyClient (the client side install that provides protection when off the corporate network), you needed to manually update the config.

Unfortunately for us, no one bothered to update that config.   While reviewing some BlueCoat best practices, I doublechecked our existing settings and found that we still had the old categories selected in ProxyClient.  I made the required changes and saved to server.   On my client, ran the updater and got an error back, “Received status 400 from server”.   I received the same error testing directly from my browser.

Opening a case with support they directed me to a Technical Alert – ProxyClient Installation is Failing with HTTP 400 response from server.   I’d seen that before running into this problem, but hadn’t read it since I wasn’t installing ProxyClient.   Didn’t remember the error 400 tiein.   It turns out, the problem occurs when making the SSL connection from the client to the server to pick up the configuration.   This is true of a new install or an updated configuration.

The cause of the problem is MS12-006.   Since this contains SSL fixes for the BEAST vulnerability, I’m going to have to ignore BlueCoat’s suggested workaround of uninstalling the Microsoft security update.   Not sure if this can be fixed with a new ProxyClient version or if I’ll be waiting for a ProxySG release which would involve much more testing.

DreamHost Database Intrusion

“Prevention is ideal but detection is a must.”

That is what my immediate reaction was to DreamHost announcing it has detected an intrusion.   I love that.

How many companies would even notice before all their customers were calling asking why they were owned?compan

How many companies would refuse to talk about security incidents or blame the customer?

How many would take the PR hit to preëmptively perform password resets immediately instead of waiting until the investigation was complete.   A week, or a month from now we could know that the passwords were’t gotten, but in an abundance of caution action is taken now to prevent damange.

Maybe I’ve drunk on the koolaid, but I think DreamHost did the right things from the reports I’ve seen.

Does Anybody Really Know What Time it is

Does anybody really care (about time)?

This Chicago song came to mind for today’s blog post about NTP.

I was walking down the street one day.    ok, I’ll stop.   I was reviewing my firewall logs and I noticed systems going to external services for NTP.

It is best practice (and company policy) for all systems to be using the same time source.  It is very difficult to match up logs from different systems when they may have different times.

It turns out there were two problems at play.   The first is default configurations.   People setting up specific equipment didn’t update NTP or assumed because it was set on one system it would replicate to other appliances part of that “group”.   The other thing that happened was an issue with the internal NTP server caused the Unix admin to point his servers elsewhere for time.

Your internal NTP server needs to be rock solid.

Another item that still needs to be addressed here, is secondary NTP.   People are going to the same primary NTP server and then using whatever was default on the device as the backup NTP.   Yeah, not such a good idea.

WordPress 3.3.1 Released

If you haven’t logged into your WordPress today, this is news to you.   Version 3.3.1 has been released to fix a XSS vulnerability.

According to ThreatPost, this is only a vulnerability if you installed WordPress by browsing to the IP.   Most installs are hosted and you would browse to the site FQDN to install.   These systems aren’t vulnerable.

The update also fixed 15 bugs.   So review the release notes and determine if you need to update.   Or just do it.

Wi-Fi Protected Setup

Wi-Fi Protected Setup (WPS) is a method common on home access points  for users to connect without having to type in a long encryption key.   Instead a PIN is printed on the access point and anyone with physical access can add themselves to the wireless.   This has always seemed kind of hinky to me so I disable WPS after all my devices are setup.

Research posted earlier this week by Stefan Viehbock reports WPS design flaws and implementation flaws that can result in an attacker accessing your network.  

Flaw #1 – WPS is vulnerable to brute force attacks

Flaw #2 – The access point sends a authfail if the first half of the PIN is incorrect.   Uh huh. 

A brute force tool has been written but has not been released at the time of this posting.
Where possible, users should disable WPS on their home access point when they are not actively adding new wireless clients.

F-Secure on Java

F-Secure generated a lot of traffic in the blogosphere with their post declaring Java harmful and better to not be installed on computers.   To me the only surprising part is the discussions this generated.   Isn’t this old news?   Principle of least privilege says to remove it if you don’t need it.   So when you’re regularly updating an application for security fixes it may be time to consider alternatives.

F-Secure links Larry Seltzer’s month without Java from 2010.   Brian Krebs posted a blog article around the same time recommending Java be removed.   I couldn’t find an earlier article, but I thought Krebs had been banging this drum for much longer.

Removing software you don’t need certainly lowers the attack surface area.   At work, I’d caution that you’re likely to find groups of users using Java for internal applications.   If you don’t put Java on your system image, they are going to install the ancient version of Java supplied by their application developer.   I found a couple users with Java 1.6.0 update zero.   When I removed that and installed the latest Java 1.6, the application still worked fine.    If you’re actively patching your environment having Java installed may not be that bad.

The articles liked mention alternatives such as only allowing Java to run on specific sites.   Sometimes I install Java only for use on my non-day-to-day browser.   I’m not sure either solution scales into the enterprise where you have to account for all sorts of computer literacy.