Category: Security

  • Apple iPhone “Jailbreak” FUD

    Apple may well have good and fair reasons to keep users from “jailbreaking” their iPhones, however the arguments as presented in the article are just FUD:

    http://www.eweek.com/c/a/Midmarket/Apple-Claims-Jailbreaking-iPhones-Could-Crash-Cell-Towers-803734/?kc=EWKNLNAV07312009STR1

    If AT&T’s cell network is this vulnerable, we have far greater worries than a little iPhone hacking. After all, Apple’s argument is essentially to keep jailbreaking out of the hands of otherwise honest iPhone users (most likely people who would like to install non-Apple approved apps and/or move their iPhones to another carrier than AT&T).

    Unfortunately all that is going to do is just that – keep jailbreaking out of the hands of the honest. Those with nefarious intent will still jailbreak their phones and if the networks are as vulnerable as indicated, will happily attack these shortcomings.

    Frankly it’s just dumb. Clearly other phones can be hacked as indicated so if these were real issues, we’d already see the fallout.

    In short that makes it FUD, or speaking more directly, a lie.

    Again Apple may have every legitimate right to protect their iPhones and intellectual property (I’ll leave that to others to argue), however it really irks me when people or corporations stoop to lies to attain their agenda. If they can’t stand on the truth, then maybe they ought to lose to the EFF anyway.


  • Useful browser check…

    Apparently a lot of compromised browsers purposefully send a modified “UserAgent“, for instance:

    UserAgent Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1;
    AntivirXP08; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1; .NET
    CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)

    that “AnitvirXP08” isn’t supposed to be there and best guess is it helps web sites that work with these viruses/trojans know the system is compromised.

    A web site to verify your agent to see if it has one of these is:

    http://whatsmyuseragent.com

    Unfortunately I imagine in time they’ll mask these a little better, like putting a bugus “.NET CLR” value that looks close enough to make it hard to see, but isn’t real and they can identify.


  • A moment of mourning…

    Time to hold a moment of mourning. It appears that WPA (fortunately not WPA 2 yet) has been cracked:

    http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9119258&source=NLT_AM&nlid=1

    http://www.itworld.com/security/57285/once-thought-safe-wpa-wi-fi-encryption-cracked

    I realize Erik Tews is probably a good person and all and probably believes he’s helping the world by finding this vulnerability before the “real” hackers do, but ultimately I’m unimpressed. The fact is, the real hackers aren’t finding the majority of these major holes, the researchers are. The hackers are just using the holes found by the researchers and exploiting them. Its not clear that if the researchers were to leave things “as they were”, that say WPA TKIP would have have ever been cracked.

    The truth is, and I’m not trying to insulting to Erik, that this is as much about the researchers’ egos as any efforts toward the supposed “common good”. In the end these hacks aren’t necessarily helping anyone but the bad guys.

    Ok, that’s a little too general. Some of these hacks/cracks are just too obvious, but some, like this one, clearly need the kind of effort that is less likely to be found in the hacker community and more likely to be found in the research community. In the end, since the later group is supposed to be the “good guys”, it would be better if they perhaps focused on something more constructive.

    Or perhaps to put it another way, “Stop helping us!”


  • Just when you thought it was safe in the Universe again…

    Dang, now that’s a hack allright:

    http://government.zdnet.com/?p=3996&tag=nl.e539

    Fortunately they missed the “Create Black Hole” setting…


  • RedHat gets hit this time…

    It just goes to show, if you think you’re safe, you’re not. This time RedHat was hit:

    http://blogs.zdnet.com/security/?p=1784&tag=nl.e550

    This is pretty ugly since it involves the signing of certificates used to validate the RPM repositories and RPMs themselves. RedHat claims that the “passphrase“s for the certificates weren’t compromised, so no harm no foul. However it’s very concerning and in order to sufficiently mitigate may require manual intervention by all users or at least changes on all users’ systems.

    The problem here is if RedHat is wrong, forged RPMs could be created that appear “valid” and in theory if installed could infect customer systems compromising binaries et al. It would take quite a bit of effort here, including getting the RPMs into the repositories without anyone noticing, but it is not out of the realm of possibility, particularly when you consider what this hack in itself says about security.


  • Brilliant article with x-Hannaford CIO

    StorefrontBacktalk has a short but brilliant article with the former CIO, Bill Homa, of Hannaford grocery chain who suffered a major breach of credit card data:

    http://storefrontbacktalk.com/story/071108homa

    There are three particular points that stand out:

    1. That Microsoft is still so hole ridden as to put your company at additional risk.
    2. That PCI is still not sufficiently strong.
    3. That a security posture based only on perimeter defense is ultimately fallacious.

    In my experience PCI (also called CISP or PCI DSS) while certainly better than nothing, is still well below what is necessary to protect customer confidential data. Furthermore certain components of the credit card processing stream require less than ideal levels of encryption (I’m being generous here), providing simplified points of collection and attack for hackers (to note, there are plans to improve this).

    In regards to depending on “perimeter defense”, this quote particularly stands out:

    Most retailers have the philosophy of keeping people out of their network. It’s impossible to keep people out of your network. There are bad people out there. How do I limit the damage they can do? If you don’t do that, they’ll have free reign to do whatever they want.

    However I hardly think this mentality is limited to retailers. In my discussions with numerous peers in the computing industry, many shops, large and small, retail or non-retail are inflicted with this mentality. In fact I would consider it pervasive – “keep the intruders out and you’ll be ok.”

    But the honest truth is you can never keep them out and like a game of chess, everyday some new hole is found to subvert your external protections. Nor for that matter should you really trust your own employees, which are ultimately one of the largest sources of data compromise, and they are on the inside.

    The answer is “defense in depth“, with layers of security, some strong, some weaker, some on perimeter, some on the host, some in the software tools themselves, but the sum total providing sufficient security for the value of the asset(s) being protected (based on “risk analysis“).

    Until corporations start thinking this way, we can expect to see breaches like Hannaford’s continue for some time.


  • WPA versus WPA2?

    So what’s the difference?

    Not much or a lot depending on your opinion. WPA uses TKIP for key management, whereas WPA2 uses AES-CCMP. Usually depending on how the AP has been set up, you can use either (TKIP or AES-CCMP) interchangeably, thus using WPA or WPA2 as needed. Many older devices like those running Windows Mobile 5, only support WPA with TKIP, while WPA2 is now required for Wi-Fi Alliance‘s “WiFi CERTIFIED” moniker.

    This is a pretty rough overview, however in the end the general consensus is WPA2 is more secure due in part to it’s use of the government/industry preferred AES protocol for key protection. However WPA is probably sufficient for the vast majority of uses and is infinitely better than using WEP protocol. WEP really is only useful for keeping your average neighbor off your network – any mildly serious attacker will be able to compromise a WEP based wireless network.

    As long as I’m on the subject, hiding your SSID is also basically a useless joke as there are so many tools to sniff them even when not set to “broadcast”. Either use WPA(2) or further encapsulate your traffic over a VPN connection. Still, in general as an extra layer of protection, you ought to disable “broadcast SSID“, though because of the way the protocol works the benefit is honestly nearly nil. Still, “layered security” is the way to go.


  • WPA resources

    When researching using WPA on Ciscos I ran into a lot of useful URLs as resources. If you’re in the same bind, you may find them helpful too:

    Not a pretty list, but still good to put somewhere!


  • What is 802.1x?

    If you’re investigating things like enterprise WPA and/or NAC based network control you’ll probably run into the fact that it uses 802.1x protocol. So what is 802.1x?

    Basically the long and short of it is IEEE 802.1x is just a protocol to pass EAP over wired/wireless LANs. EAP on the other hand is just a protocol to take the AP/RAS/switch/router out of the stream of authentication. It is a way of tunneling the authentication request to a Radius server and let the two figure out the authentication without the AP/RAS/switch/router having to handle it.

    A good primer on the subject is here:

    http://www.networkworld.com/research/2002/0506whatisit.html

    Incidentally the user unfriendly term “supplicant” will often come up. Much as it sounds like something fancy, it isn’t. In most regards it just means the client you’re trying to connect to the network, however more officially it’s the process(es) on the client taking care of the 802.1x authentication. The client runs the supplicant to authenticate, to quote:

    The wireless node that requests authentication is often called Supplicant, although it is more correct to say that the wireless node contains a Supplicant. The Supplicant is responsible for responding to Authenticator data that will establish its credentials. The same goes for the access point; the Authenticator is not the access point. Rather, the access point contains an Authenticator. The Authenticator does not even need to be in the access point; it can be an external component.

    So ultimately the “supplicant” is really a program running on the client. Also see:

    http://tldp.org/HOWTO/html_single/8021X-HOWTO

    which also is a useful document.

    As a final note, often the EAP passed in the 802.1x conversation is encapsulated in what’s called “PEAP” (yes, all of the acronyms are a pain!). Essentially PEAP is a public key based method of encrypting the EAP payload via SSL/TLS, thus protecting the authentication from prying eyes.


  • If using WPA-PSK, use a long key!

    If you must use WPA-PSK (meaning WPA with a pre-shared key, rather than WPA using 802.1x authentication via Radius), make sure your key is sufficiently long. Ideally 20 characters or more.

    To quote:

    Robert Moskowitz’s article, “Weakness in Passphrase Choice in WPA Interface,” describes a theoretical attack on WPA passwords. The tools WPA-psk-bf, CoWPAtty and WEP Crack are implementations of this attack and have demonstrated the ability to break WPA-PSK keys that are 20 characters or fewer. The Aircrack tool suite operates in an active or passive mode to gather the data required to launch these attacks. In passive mode, the Aircrack tools capture the four-packet authentication handshake between an AP and client. The handshake is then processed through a WPA breaking tool for an offline brute-force attack. If the attacker has not captured the handshake, the Aircrack tools active mode will force a disassociation and reassociation.

    For more see this article:

    http://www.chips.navy.mil/archives/05_jul/web%20pages/Wireless_networks.htm

    which gives a fairly comprehensive overview of the challenges here.


  • And this is why security REALLY matters…

    Imagine if you went to file your income tax return, only to find out that someone had already filed it and gotten your refund:

    http://csoonline.com/article/381513/UnitedHealthcare_Data_Breach_Leads_To_ID_Theft

    That is exactly what happened to 155 graduate and medical students of UC Irvine who were victims of identity after UnitedHealthcare’s (the provider of their medical insurance) records were breached.

    Too many IT professional don’t see security in real terms. This is a great example of a very real effect. I can tell you, I would be pissed (er, technical term there)!