Wifi security story on news

[Mike]

I watched some more of the series and the threat is a man in the middle attack with a twist. Since it appears to be a real threat where personal data can be compromised, I would suggest that the answer has been given in at least 2 of the segments, by the expert Mr. Lanterman, and that is, don't use wifi, particularly in public places. He also said MiFi is a slightly better option, but also not completely fool proof, and that a cellular or ISP individual data plan is the best option.
It will be interesting to see just how much farther this story goes, beyond the local news team that have produced the initial segments, if it does.

Going back to the exploding car analogy, if there was a reasonable chance that the vehicle could explode, and you had irrefutable evidence of same, wouldn't you approach the manufacturer, as they have already done, and then the NHTSA, to report the problem, so that everyone else in the car manufacturing business could do due diligence, and examine their products for similar shortcomings? Not just do a couple of 3 minute segments on a local TV news broadcast and notify a few unnamed victims? That's as far as it seems to have gone, so far. I think it's a matter of perception of the overall problem severity, and I'm pretty sure that if this was potentially a really big deal, it would have gone national by now (not the National Enquirer, btw). Any local reporter would relish breaking a major news story to gain a Cronkite or Murrow moment, and would likely pursue a real story, if one exists, IMO.
I wonder why Mr. Lanterman has only now come forward with this disturbing information? How long has he been sitting on it, and why? Might be another angle to the saga.
For fun, I googled (kleenexed?) "man in the middle attack prevention", and there are some hits for it that I have yet to sift through. I'll see if there are any light bulb moments there to be considered when I get some more time.

[booster]

If KSTP follows their, and the other local news guys, pattern, they won't contact any regulators ahead of time, or right after. They usually wait until an agency contacts them about the story, after getting questions from the public, and then they go back on the air with the "after our story XXX agency got a hold of us to get more information and is now addressing it". I think public safety comes a bit after ratings. It would seem logical to get the info to them ahead of time, but many times they don't. I don't recall if KSTP contacted any of the companies that failed before the broadcast, or not, in this case.

I would expect that they will have a followup on it in the future, as they still have it pretty prominently on their news website. I hope they ask for, and get, some of the IT folks from the affected companies to be on for interviews.

We will see how it all shakes out.

[Mike]

Works for me. I'm assuming we'll hear about it if it really is a big deal. I'm still leaning towards tempest in a teapot, mainly due to the secrecy of who it was that they called "major financial institutions". That sort of subterfuge can work two ways, either they are afraid of litigation if they reveal the names of the parties involved, or they aren't as sure about the severity of the issue at second take, and don't want to look like making big deal out of some minor security exposures of some substantial, but local, businesses. They really only named websites that have been known for having data security issues, and that have been attacked in the past, so that doesn't tell us much about the severity of the problem. I'm curious how it all ends. It still strikes me as odd that they're only just coming out with it now, considering the security flaw has been there for over 4 years, maybe longer. Stay tuned?
The man in the middle attack prevention webpages describe several of the MITM attack scenarios, and from what I can tell, and I'm no expert, the websites being compromised had expired, invalid, or just plain bad verification certificates, possibly due to neglect, or simply not realizing the importance of keeping them current/valid. The certificate is one of the things that identifies the website to the client, and is part of the handshake that leads to creation of the secure connection by sending and receiving a temporary encryption code to be used by both parties for the duration of the transaction. If it goes much deeper than that, it's beyond me. I was a mainframe tech, not a desktop guy.
Like you, I'm also probably not going to stop driving in the short term, fearing an accident, but that might change, too. It's just that free wifi on the road is so damned convenient. I'll probably keep on using it, and evaluating each individual hotspot as we go, and avoid the ones that don't feel right.

[mlts22]

I've been in IT for so long, so my natural cynicism is showing. The one tenant to security is not to stand still. Let keys expire or sit on an unpatched machine, there goes the neighborhood. Of course, in business, a lot of companies will tell you that because to them security has no ROI, they will pay little to no attention to it. History also shows that there are zero long-term consequences to security breaches, so even if something does happen, it isn't something that a few ads and a couple E-mails for people to change their passwords won't remedy.

I will take proper precautions, but there is a point where there are diminishing returns. I will encrypt all my computers' hard disks, but I'm not going to physically yank drives and store them in a safe when done for the night. I'll set a long password on my home Wi-Fi segments (63 characters), but I'm not going to switch it off unless I'm off for a vacation.

Security is hard. There is a lot of BS out there, and not much actual helpful info oftentimes.

[Davydd]

I'm going to be more cognizant of any Kleenex boxes sitting on tables at Starbucks.

[markopolo]

There's some info here: https://www.grc.com/fingerprints.htm that is useful.
You could store a text containing the "fingerprints" of secure sites that you might need to visit over WiFi when on the road. Then you would compare the saved fingerprint to what your browser reports.

It's cumbersome but not difficult to do.

I just compared what GRC reported and what my Firefox browser reported for login.live.com and the two match. It should because I am at home and also because login.live.com uses an Extended Validation (EV) certificate which can't have been altered and pass according to GRC.com as long as you are using Firefox or Chrome browsers.

My browser reported:


GRC reported:

[Mike]

That's a long read. Since EV turns the address bar text of webpage info green, wouldn't that be a sufficient test that all is well? At least the ones that use EV verification. Unless the green color can somehow also be spoofed?
Also, and this wasn't mentioned by the author, why couldn't the people who set up the spoofed certificates, in the compromised browsers, simply add a script into the browser address resolution routines that quickly checks GRC for the real site certificate thumbnail string before returning the certificate info to the security certificate request, and substitute it to the browser during the test? That way the user gets the correct character string to compare to his/her prepared list of certificates from GRC, and thinks all is well. The script could key on click of the lock symbol on the web address bar to trigger it, and since the GRC website is a public one, the bad guys have access to it too, don't they? Parse the browser website address destination, scoot over to GRC.com, test and fetch the website address from the GRC thumbnail test window, return the real address to the user as the requested security certifictae, all appears well. Or, not, since I'm no expert on what could and couldn't be done in a very short amount of time when someone tests a website's security certificate.
Either way this sounds like a good, albeit manual, way of testing whether your browser is compromised and being monitored, or not. I'm not sure it would prevent someone from getting hacked by a MITM attack at an internet cafe, since I'll assume that our web browsers are pristine and not compromised by a 3rd party, since we installed them ourselves, and didn't add any additional Pseudo Certificate Authority as part of the install process.
Does that make sense, or am I missing some piece of the logic of this process?
It's all very desktop nuts and bolts. Not my specialty.

[markopolo]

I don't know much about this stuff really but I don't think a third party would be able to fake the fingerprint as it is created from the certificate and the public key (my understanding).

You, or the bad guy, don't need to use GRC.com at all. Instead, just compile a list of fingerprints at home on your known secure network by visiting the site(s) and recording the fingerprint your browser reports. I'm not suggesting that we carry out secure transactions over random public WiFi but the list you make might come in handy in an emergency such as if you absolutely had to access your bank for example.

I could see regularly checking the fingerprint when accessing email on the road as it would be much more likely that I'd check email using public Wifi than purchasing something or doing any banking.

As was pointed out earlier in this topic - a cellular connection for secure transactions is a better way to do it.

It looks like more companies http://redmondmag.com/articles/2009/01/ ... t-ssl.aspx are inspecting outgoing encrypted web traffic (in addition to incoming encrypted web traffic). To inspect encrypted traffic you have to have the key so those companies are essentially carrying out MITM type activities by substituting the certificate/key.

Force TLS is a useful Firefox add-on allowing you to require using HTTPS for select sites. https://addons.mozilla.org/en-US/firefo ... force-tls/

Does anyone know of any other ways to detect MITM type activity? (other than fingerprint checking)

[Mike]

Originally Posted by markopolo

I don't know much about this stuff really but I don't think a third party would be able to fake the fingerprint as it is created from the certificate and the public key (my understanding).

Sorry, let me try again. I didn't mean fake the fingerprint, necessarily. More like faking the response to the verification request. I was suggesting that, as soon as the victim's browser is directed to a website that a "bad guy" wants to impersonate, he could present a fake address bar lock/certificate verification button, and when the user clicks it, quickly do the fingerprint check himself, return the correct result to the victim's browser, but still maintain the connection to the faked website. There might be a slight delay in the appearance of the time it takes the victim's browser to get the response to clicking the lock button to do the certificate fingerprint check, but it might go largely unnoticed on public wifi, or assumed to be slow due to it being a busy website, or the web is just slow that day/time. My point was that since access to the real fingerprints is available in the public domain, the bad guys might find a way to take advantage of the fingerprint info they can get at GRC, because it's the same as what you or I can get. If everyone (particularly banks and FIs) used the EV (extended validation) it would be easier to simply look for the green address bar indicator that all was well. I always assume email is open to the public. Even though the providers all say their security is impeccable.

Originally Posted by markopolo

You, or the bad guy, don't need to use GRC.com at all. Instead, just compile a list of fingerprints at home on your known secure network by visiting the site(s) and recording the fingerprint your browser reports. I'm not suggesting that we carry out secure transactions over random public WiFi but the list you make might come in handy in an emergency such as if you absolutely had to access your bank for example.

I read the info about the ways one might get false failures when checking, and I was wondering if the real websites change their private keys regularly, and that might also be a confusing factor. Your test might show the website is fake, when it's real. It's an interesting way to try to verify the identity of a website.

Originally Posted by markopolo

I could see regularly checking the fingerprint when accessing email on the road as it would be much more likely that I'd check email using public Wifi than purchasing something or doing any banking.

As was pointed out earlier in this topic - a cellular connection for secure transactions is a better way to do it.

It looks like more companies http://redmondmag.com/articles/2009/01/ ... t-ssl.aspx are inspecting outgoing encrypted web traffic (in addition to incoming encrypted web traffic). To inspect encrypted traffic you have to have the key so those companies are essentially carrying out MITM type activities by substituting the certificate/key.

Force TLS is a useful Firefox add-on allowing you to require using HTTPS for select sites. https://addons.mozilla.org/en-US/firefo ... force-tls/

Does anyone know of any other ways to detect MITM type activity? (other than fingerprint checking)

I've added HTTPS Everywhere (by EFF, and associated with the TOR Project) to Firefox and Chrome, and so far it's behaved itself.
https://www.eff.org/https-everywhere
They state that some bugginess can occur in some situations, and they provide a list (SSL Observatory) of website certificates for comparison. By enabling the Observatory function, you can run your website certificates through their Observatory and it's supposed to flag bad ones. You can also interact by sending them info about web forgeries and suspected MITM attacks, if you suspect a website has a problem. I just let it do it's thing in the background, and hope that it's working.
Have a look, EFF sounds like it detests snoops and MITM attacks and exploits. Another layer of safety, maybe? The TOR Project is all about anonymous web surfing and proxy servers, and they also aren't fans of "big brother", legal or otherwise.
Also, avoid using IE, based on the comments from the GRC website guy. He suggests MSN encourage network and website admins to snoop on their users, and says Internet Explorer is set up to be compromised.
I just went to both Amazons and Ebay and both use EV added to their certificates. They were two of the websites that failed the initial tests performed by Lanterman and KTSP. More confusion? HTTPS isn't good enough to protect you and certificate validation may be meaningless?

[markopolo]

I hope it can't happen like the first part of your post. MD5 has been broken but SHA-1 hashes still hold up. SHA-256 will be what we move to.

SSL / TLS / HTTPS is all about encryption right?

I think the problem with Amazon is that you can enter either via http or https. It is that initial http entry that could make the site fail the test. That where HTTPS Everywhere or Force TLS helps by forcing you to use https from the start of the session.

[Mike]

That's what I thought was happening during the testing that failed when the reporter logged into the various social and other websites, he used HTTP only, and the expert was scanning the wifi traffic. Which would explain the ease with which he was able to see the text of the traffic. Still, they implied he was getting around the encryption somehow, stripping it away.

This analysis and the resolution which is taken by some of the sites "The websites that passed our test identify unencrypted data, are suspicious of it, and take steps to prevent the data from being intercepted. " would seem to imply that as long as the website is suspicious of unencrypted data (probably forces or only accepts HTTPS logins) it's safe to deal with.