The tech and security news stream has been full of iPad AT&T hack coverage with AT&T trying to downplay the severity of the hack and security experts rebutting AT&T's claims stating that the ICC-ID can be used to determine other information.  I'm not an expert on 3G security and don't know much about ICC-IDs but I can tell you that this leak has serious indisputable security implications regardless of potential attacks via the 3G network which everyone seems to be focusing on at the moment.

The leak of verified email addresses, especially of high-profile individuals and those with security clearance, is a huge problem.  Obtaining current email addresses is the first step in targeted attacks like the recent one against Google and others. 

Now that these addresses are public you can bet many accounts on that list are receiving carefully crafted, targeted phishing emails known in the industry as "spear phishing" or "weaponized email".  A single click on a link in a very legitimate looking email could compromise not only the computer on which the link was clicked but potentially every computer on the same network.  Imagine if New York City Mayor Michael Bloomberg or White House Chief of Staff Rahm Emanuel, both whose emails were leaked, were to click on a malicious link in an email appearing to be from a legitimate source.  What kind of damage could that do?  If Google and other high-tech corporations could be hacked, I'm sure the US government is not unhackable.

My friend Paul tweeted about a new URL shortener like bit.ly and is.gd but with one major difference.  The domain for this shortener is only 2 letters "t-o" and they're not separated by a dot.  The link to the shortener was posted as http://to./ which appears to be an invalid link since it has no top level domain (com, net, org etc.) but low and behold, it worked.

Another letter to Steve Gibson that I'm reposting here in case it's not read on Security Now.

Hey Steve,

Just finished SN200. That was a good one. Just wanted to add a bit of info that you've never mentioned and might be valuable to your listeners.

Leo mentioned that his port 22222 is forwarded to his Skype machine and Skype is listening on that port so he feels it's safe about that hole. What may not be known to some listeners is that good-behaving programs will not bind to a port on which another process is already bound. In other words, if Skype is listening on 22222 then other, possibly exploitable, processes like Windows service host will not be listening on 22222.

It is possible for malware or security tools to listen in on bound ports which is why I said "good-behaving programs" but if you've got malware it's already too late.

Update 2009/07/07

I realized later that I neglected protocols. It's possible to have one process listening on TCP 22222 while another process listens on UDP 22222. Forwarding both TCP and UDP ports 22222 to your local IP when only one is "bound" by a known process is a security risk since the other could be open to exploits.

I often write in to Steve Gibson to ask questions, provide feedback, or just rant about a security topic. While I have received responses a few times, most go unnoticed due to the volume of feedback Steve receives so I've decided to repost all my feedback to Steve here on my blog.

In response to a comment by Shawn Polson of Middletown, Delaware, Steve and Leo revisit the idea of encrypting all network connections. Shawn states that SSL shouldn't be used everywhere for efficiency reasons since SSL connections are not cached locally nor by proxies. While he makes a good point, Shawn's is not a technical limitation but just an economical issue of bandwidth. Steve and Leo continue on by clarifying their point that it's more of a general wish that all connections for email, web etc are encrypted, not specifically SSL. I agree that all connections should be secure, and Shawn is also right that there will be a bandwidth hit if content is not cached. With that said, I think it should be noted that there is also a technical reason why you can't enable SSL on every site and it has to do with a limitation of name based virtual hosts.

My last post focused on SEO drawbacks of framed URL shorteners which is mostly a concern for content creators. I later realized that URL shorteners which frame entire pages, like the Diggbar and BurnURL, are even worse than I originally though. These services are not only stealing page rank points (and arguably stealing content) they are shifting the third-party distrust to the target site and essentially become a man-in-the-middle.

Tokyo is one of the greatest places to live but once in a while I find sites or services that prohibit connections from outside the US such as Pandora, Hulu, and some books on Audible. Fortunately I have a server in the US so I set about trying to get around these international restrictions by proxying certain connections through the server. Unfortunately my server's connection is not very fast and it's also asynchronous so needed to test proxying methods to determine which, if any, might be able to support streaming content. There may be other ways to proxy but I chose to test an SSH tunnel and a basic Squid proxy. Results below the break.

Let me start, as always, by saying that Security Now! is great podcast that I look forward to listening every week. In episode 154 Steve answers a question to a listeners who says he noticed a virus warning about "Wizmo", Steve's Windows tweaking tool. Steve answers by basically saying that Wizmo is safe and known to trigger false positives by some AV software so the warning can be ignored. That's some bad advice.

While I have no doubt that the Wizmo.exe file compiled by Steve is completely safe, the question is "is the copy of Wizmo.exe the listener downloaded exactly the same as the one Steve compiled?".

When considering where to place encrypted container files, many people recommend creating dummy files like "my_hawaii_vacation.avi" or creating deep subdirectories to hide your encrypted files. The AVI idea is nice because you can make a large container but it's easy to see it's fake since it won't play and deep directories are a hassle. Sure, Truecrypt has plausible deniability but any extra security/deniability that does not incur additional inconvenience is always a good thing.

According to the Truecrypt docs

This is my crazy password creation scheme. Using this method you will be able to create ridiculously strong passwords like Wh++2b$3,+@m@c3 yet still be able to remember the password after only a few tries. As far as I know, this scheme is not vulnerable to weaknesses in other password schemes. Read on to find out more.