At the time, I realized that our wireless client configuration instructions allowed man in the middle.   I’ve been trying to get this fixed for four years, and I finally got success this week!

The original config is below:   You’ll note that validate “user certificate is not checked”

By doing this, the client will connect to anything with a certificate!   It would be really easy to do what Josh and Brad talk about and set up a fake Access Point and Radius server.   The client would give their credentials to the attacker who would then log into the network.   The client could either than be allowed to stay connected and man in the middled, or drop their connection.  The client would be non-the-wiser.   They’d just try again and this time get in on the real access point.

I figured what needed to happen was get the public key for the certificate used in PEAP.   I started on the Wireless Control Server which is the wrong place to be.

Next, I looked at the client help file and found that for EAP-GTC, it is mandatory to list the server name in the “connect only to these servers” field.   But you need to know the CN or the SAN to do that.

So I found out the server name is our ACS server not the Wireless Control Server.   I got what we thought was the root certificate, and I tried to connect.   It didn’t work, but this time I was prompted to  accept a new certificate.   Apparently if I’d selected any of the root certificates, I would have been prompted to add the real one, but because none were selected the connection failed.

So we set up a profile set to validate certificates, and connect only to our ACS server.   We deployed the public key of the root server of the internal CA that issued our certificate, and configured the client to only trust that CA for this wireless connection.   Lastly we checked “do not prompt user to authorize new server”

If you don’t check “do not prompt user to authorize new servers”, if the user were man in the middled they would be prompted to accept the certificate.   Users always accept security warnings and continue so they can do their work.   So it is best to take the choice out of their hands.   The security goes hand in hand.   By only trusting certificates issued from my internal CA, it is unlikely they would have a certificate that could be accepted by the end user anyway.

That should have been fixed much sooner.   Once we answered the right questions of the right people, it turned out to be an easy fix.   It is quite common for companies to turn off certificate validation in their wireless setup rather than fixing the cause of problems.   This opens companies to man in the middle attacks.   Just because it is only open to people who can drive near your facility doesn’t mean it isn’t a big big problem.

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.

 ’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.

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.

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.

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.

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.

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.

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.

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.