Slashdot Mirror

← Back to Stories (view on slashdot.org)

RSA Admits SecurID Tokens Have Been Compromised

Posted by CmdrTaco on from the hey-i-have-one-of-those dept.

A few months ago, RSA Servers were hacked, and a few weeks ago Duped tokens were used to hack Lockheed-Martin. Well today Orome1 writes "RSA has finally admitted publicly that the March breach into its systems has resulted in the compromise of their SecurID two-factor authentication tokens. The admission comes in the wake of cyber intrusions into the networks of three US military contractors: Lockheed Martin, L-3 Communications and Northrop Grumman — one of them confirmed by the company, others hinted at by internal warnings and unusual domain name and password reset process."

39 of 219 comments (clear)

  1. Is this an act of war? by cultiv8 · · Score: 4, Interesting

    Sit back peoples, get some popcorn, this should be interesting...

    --
    sysadmins and parents of newborns get the same amount of sleep.
    1. Re:Is this an act of war? by TheRaven64 · · Score: 3, Insightful

      Cold wars are better for business than fighting wars. In a cold war, you get lots of funding but don't actually have to deliver anything. Cyberwar is even better, because whatever you do deliver becomes obsolete about ten seconds after deployment (at the latest), so you can keep getting the funding. A cyberwar with China is perfect, because there's always the possibility that it will turn into a shooting war, so you need to keep spending money on jets, drones, aircraft carriers, and so on, but there's no real chance that it will, so you don't have to waste much money on things like soldiers (who inconveniently take money away from shareholders' pockets, where it belongs).

      --
      I am TheRaven on Soylent News
  2. Cyber intrusions by ArAgost · · Score: 4, Insightful

    1992 called, they wanted the adjective “cyber” back.

    1. Re:Cyber intrusions by Trepidity · · Score: 2

      Ted Nelson was even complaining about its overuse in the late 1960s. Seems not to have really stopped.

      --
      10 PRINT CHR$(205.5+RND(1)); : GOTO 10
    2. Re:Cyber intrusions by TerranFury · · Score: 5, Interesting

      ...and 1947 turns the dial on its rotary phone to call both '92 and '84:

      From here:

      It is worth noting that the Greek word for governor is k u ße r n a n . In 1947, Norbert Wiener at MIT was searching for a name for his new discipline of automata theory- control and communication in man and machine. In investigating the flyball governor of Watt, he investigated also the etymology of the word k u ße r n a n and came across the Greek word for steersman, k u ße r n t V . Thus, he selected the name cybernetics for his fledgling field.

      In other words...

      (Cyber = steering/adjustment/feedback) + (net = networks/interconnection) + (ics = study of)

  3. Dear Customers... by fuzzyfuzzyfungus · · Score: 5, Insightful

    Golly Shucks. As it turns out, maintaining a copy of the seed keys for devices we sold specifically as a high-security access control solution on our under-secured network might have been a less than totally good idea... Well, lessons learned, eh?

    1. Re:Dear Customers... by Anonymous Coward · · Score: 3, Insightful

      I think we're all assuming (for the most part) that the attack was over a network. If the keys were physically stolen from an offline box, then that's a different matter. If they had their high-security seed keys--as GP refers to them--accessible remotely in any manner, that was probably an avoidable mistake.

    2. Re:Dear Customers... by fuzzyfuzzyfungus · · Score: 5, Insightful

      My main issue was with retaining the seed keys in any network accessible location.

      Those things should have been deleted upon transfer to the customer or(if so requested) stored on archival media in a vault somewhere unless needed by the customer for recovery purposes.

      My point isn't "Ha Ha, their network guys fucked up, I could have done better!" My point is "for something as interesting as the seeds you would find useful in compromising a laundry-list of high-profile, high-security targets, basically no configuration would be sufficiently secure, and storing them in an insufficiently secure manner is hugely irresponsible.

      After the the tokens were seeded, there was no further need for RSA to have them anywhere that they could be accessed electronically.

    3. Re:Dear Customers... by thijsh · · Score: 5, Insightful

      For master encryption keys anything other than offline physically secure storage is a risk that is too high... The extra hassle of having a guy physically go to the storage when new certificates need to be signed is what you pay the security premium for right? This is not about discount SSL certificates that need to be sent with an automated process, no need at all to hook the machines to the internet... under-secured or super-duper-unbreakable-secure(tm) does not matter, just don't.

    4. Re:Dear Customers... by fuzzyfuzzyfungus · · Score: 3, Insightful

      RSA's customers certainly need to have a copy of their tokens' seed keys on their authentication server; but RSA doesn't need a copy of their customers' seed keys...

    5. Re:Dear Customers... by yodleboy · · Score: 2

      i think his point was that they sell a "high security" product and then store the keys on an apparently "low security" network. probably a bad idea.

    6. Re:Dear Customers... by hublan · · Score: 2

      Perhaps by keeping the machine that hosts the seed secured? Like using a protocol between the publicly facing machine and the seed machine that doesn't allow for remote shell access? Really basic stuff, actually.

      --
      My spoon is too big.
    7. Re:Dear Customers... by c0lo · · Score: 2

      RSA's customers certainly need to have a copy of their tokens' seed keys on their authentication server; but RSA doesn't need a copy of their customers' seed keys...

      Unfortunately, I imagine they do need the copy: otherwise how do they make sure they never issue duplicates to different customers?

      --
      Questions raise, answers kill. Raise questions to stay alive.
    8. Re:Dear Customers... by AJH16 · · Score: 2

      Perhaps they kept them around for initializing more fobs if necessary without having to transfer the root key again. Granted, it would probably be better to use a new root key and have a system support multiple, but then you have a key distribution problem where you need to distribute another key as well. It might not have been the most secure choice, but it seems it could have a lot of benefits for the sake of convenience if they thought they had it protected enough. Everything in security is about trade offs of usability versus security. You may not agree with where they drew the line and hind sight is always 20/20, but it still doesn't make it a wrong choice necessarily.

      I'm way more annoyed with the lack of good information about the nature of the data compromised than I am about the fact the breach was able to happen.

      --
      AJ Henderson
    9. Re:Dear Customers... by fuzzyfuzzyfungus · · Score: 3, Informative

      If they need to check the list of seeds they've already used, their seed length is arguably way, way, way too short. With sufficient seed length, the risk isn't quite zero; but it is so vanishly close that it doesn't matter.

      Since the algorithm that the tokens use is public knowledge, anybody can, for a given seed, compute the token display value at time T. If the seed-space were so small that RSA needed to do duplicate checks, rather than just resting assured in the fact that they'd need to issue a fob to every proton in the universe before the risk of duplication rises above 1%, then there would be the theoretical danger that an attacker could just brute-force things by computing each seed chain, and then inferring the target fob's seed by sampling its output at one or more times and seeing which seed chain it matched...

    10. Re:Dear Customers... by vlm · · Score: 3, Insightful

      RSA's customers certainly need to have a copy of their tokens' seed keys on their authentication server; but RSA doesn't need a copy of their customers' seed keys...

      Unfortunately, I imagine they do need the copy: otherwise how do they make sure they never issue duplicates to different customers?

      LOL that one was funny, and some PHB requirement like that is probably the cause of the whole problem. Like intro to crypto 101 problem funny. To the noobs out there, the solution involves storing the hash of the existing keys instead of the keys themselves. Supposedly, can't turn a hash back into a key, but if the hash of your new key matches a pre-existing hash, then its a dupe, make another and try again.

      That's only needed if it's required to prove there's no dupes... realistically, if you have a 1024 bit key and 16 bits worth of customers, the odds of a collision, which wouldn't matter anyway, are 1 in 2 ** (1008) or in other words quite unlikely.

      --
      "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
    11. Re:Dear Customers... by swillden · · Score: 2

      For master encryption keys anything other than offline physically secure storage is a risk that is too high

      I would agree with you if secure hardware security modules (HSMs) didn't exist. Buy a FIPS 140-2 Level 4 certified device, get people who know what they're doing to configure it for you (including ensuring that the device will never, under any circumstances, export the master keys) and it is acceptable to have the device networked. You still need to have strong physical security around it, though that's more to prevent the DOS attack that results from having the device stolen than due to concern about someone extracting the keys from it, and of course it's always a good idea to secure the network it's on as well just out of due diligence and an abundance of caution, but in such a device your keys are extremely safe from both remote and physical extraction attacks.

      With a good HSM, what you really focus your security efforts around isn't physical or network security, it's access control policies. If an attacker can fire requests at the HSM and have them serviced, he doesn't need the keys or physical possession of the HSM, he can just ask the device to encrypt/decrypt/sign whatever he'd like.

      When managing keys used to derive other keys (which is probably what is meant by "master key" here, though I didn't RTFA), the most important goals are to ensure that no one, regardless of access, can re-derive and re-export an already-exported key and to carefully control the export and personalization path to ensure that a derived key cannot be duplicated or diverted during personalization. ("Personalization" here refers to the process of loading a derived key into the device that will use it.)

      This is all very doable. Obviously, RSA didn't do it, which is baffling.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    12. Re:Dear Customers... by fuzzyfuzzyfungus · · Score: 5, Insightful

      I suspect that the first question falls into the "Very interesting, pity we'll never find out..." category.

      As for the second, I suspect that it is largely a matter of manufacturing convenience and/or fob tamper resistance. With RSA doing the keyfill at point of manufacture, the customer just needs to load the seed file for the entire batch onto their authentication server and then hand out the tokens, which are glued shut with considerable enthusiasm, and have no externally accessible electrical connections of any sort. If the customer did the fill, that would be extra effort (and a step where grunt manual labor would meet very sensitive data, not a pleasant HR situation...) for them, and would mean that RSA would have to validate their design against attacks on the exposed connectors. Neither is impossible to overcome; but under the(now invalid) assumption that RSA wouldn't fuck it up, certainly easier to avoid than to deal with.

    13. Re:Dear Customers... by clodney · · Score: 5, Interesting

      Admittedly for a company in the security business they get a big fail on this one.

      But I suspect that properly securing them is more difficult than it would appear to the outside observer. At one job I had, we had a signing key of some sort, which was on a USB key in a sealed envelope in a safe. We only took that key out when it needed to be used, which was maybe once a year. Easy enough to observe all the necessary precautions, even if it felt like overkill.

      But remember that RSA presumably manufactures these tokens every single day. So the seed values have to be handled correctly all the time, and that makes the air gap restrictions tremendously onerous to comply with. The seed values need to be known to the authentication servers, and customers will likely demand that RSA could provide them the necessary data to reload authentication servers in the event of a major crash (yes, I know, backups, etc. - but the real world is not always like that).

      So I suspect that RSA themselves was hurt by the classic security vs usability tradeoff. They need ongoing access to the data that they need to keep secure, and the security restrictions impacted usability, to the point where the policies were weakened, either officially or just by being sloppy.

      Defenders have to be good all the time. Attackers only have to succeed once.

    14. Re:Dear Customers... by Tim+C · · Score: 4, Insightful

      I like how everything is now "under-secured" as if you have any first hand knowledge of the nature of the attack at RSA or the security measures they had in place.

      Someone got in. Seems to me that that is a very good, practical definition of "under-secured".

      --
      It's official. Most of you are morons.
    15. Re:Dear Customers... by PIBM · · Score: 4, Informative

      I remembered reading about this, and the failure mode were quite important to me. Let me quote wikipedia on this:

      Section 4.1.1 of the specification describes additional attacks that may require mitigation, such as differential power analysis. If a product contains countermeasures against these attacks, they must be documented and tested, but protections are not required to achieve a given level. Thus, a criticism of FIPS 140-2 is that the standard gives a false sense of security at Levels 2 and above because the standard implies that modules will be tamper-evident and/or tamper-resistant, yet modules are permitted to have side channel vulnerabilities that allow simple extraction of keys.

    16. Re:Dear Customers... by WuphonsReach · · Score: 2

      Perhaps they kept them around for initializing more fobs if necessary without having to transfer the root key again.

      In simpler terms - convenience won out over security.

      --
      Wolde you bothe eate your cake, and have your cake?
    17. Re:Dear Customers... by makomk · · Score: 2

      With RSA doing the keyfill at point of manufacture, the customer just needs to load the seed file for the entire batch onto their authentication server and then hand out the tokens, which are glued shut with considerable enthusiasm, and have no externally accessible electrical connections of any sort.

      They don't do that though. As far as anyone outside RSA can tell, the keyfill port is a row of 7 PCB contacts hidden behind a little rectangular stick-on plastic cover on the back of the device. The cover doesn't even seem to be tamper-evident let alone tamper-resistant - you just press it back down again after you're done gawking and it sticks right back into place.

  4. Comment removed by account_deleted · · Score: 4, Insightful

    Comment removed based on user account deletion

  5. Anybody know? by fuzzyfuzzyfungus · · Score: 3, Interesting

    Are there any big, important checkbox-compliant certifications that RSA's customers might have been using the (Not Cheap) RSA tokens to obtain that, as a consequence of this sordid episode, might no longer be attainable with RSA gear? That seems like it would be a fitting punishment for RSA's questionable security practices and even more questionable disclosure practices; but I'm afraid that I haven't wrapped my head around the alphabet soup of compliance acronyms in different areas enough to know.

  6. RSA is Offering to Replace Tokens by chill · · Score: 2

    Here is a link to RSA's official statement made yesterday. They are offering to replace tokens for "customers with concentrated user bases typically focused on protecting intellectual property and corporate networks".

    That is corporate VPN, not the people who use tokens issued to get to websites, such as banking info.

    --
    Learning HOW to think is more important than learning WHAT to think.
    1. Re:RSA is Offering to Replace Tokens by fuzzyfuzzyfungus · · Score: 4, Insightful

      Dear customers who don't matter,

      We are committed to providing you with a customer experience commesurate with what we can get away with. XOXOXO,
      RSA

  7. Re:And they worry about retailers and PCI by surgen · · Score: 2

    These guys want the big targets.

    What guys? Are you implying that every malicious actor is part of one large homogenous blob of shared targets and interests?

    Criminals are going to aim at the top of the food chain, not at the mom and pop store.

    Or they'll go for the low-hanging fruit, the payoff might be smaller, but they sure can hit a lot more targets.

    You're advocating "lets fly under they radar, we'll be fine", that's terrible security. Besides, if they really are that small, they don't really need the robust kind of credit card processing you're talking about. It'd be cheaper for them to get some self-contained units and dedicated phonelines for them.

  8. Reparations by TardisX · · Score: 5, Funny

    RSA is expected to replace practically every one of the 40 million SecurID tokens currently used.

    Nah, how about just offer them a "sorry" and a couple of old games and call it even?

    --

    Command attempted to use minibuffer while in minibuffer
  9. Glad We switched to YubiKey long ago. by VortexCortex · · Score: 4, Interesting

    Our secure tokens are Yubikeys. We use RFID for physical access and the challenge response protocol for authentication.

    We didn't like the thought of having to trust a 3rd party with our keys, so we run our own authentication services and use our own "seeds". This way we have one less attack/exploit surface (the MFG) to worry about -- Looks like it paid off for us this time!

    Key Lifecycle Management

    Re-configuration of YubiKeys by customers

    For high security environments, customers may select not to share the
    AES key information for their YubiKeys outside of their organization.
    Customers may also for other reasons want to be in control of all AES
    keys programmed into the Yubikey devices. Yubico therefore supports the
    use of a personalization tool to reconfigure the YubiKeys with new AES
    keys and meta data.

    If RSA has your keys... are they really secure?!?!!

  10. two factor? by vlm · · Score: 4, Insightful

    All I can find is the usual journalistic garbage, some fear mongering here and there, some harsh comments about RSA, some financial "news" commentary. No real information.

    Can anyone on /. with technical knowledge, comment on the hack breaking the entire system (essentially, rooting the auth system) or is it just breaking one of the two factors, that being able to predict the "random" number generation of the keyfobs, so I'm down to merely having a pretty good "one factor"?

    Also is the protocol poorly enough designed that the attackers don't need to know anything about the keyfobs, or rephrased, does keeping the serial number info etc about individuals keyfobs secret prevent the break?

    --
    "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
    1. Re:two factor? by Anonymous Coward · · Score: 2, Insightful

      They have got the key to generate the "random" token. So, yes, it's down to one factor.

      But I guess the password is the easy part.. Password reuse, keylogger, etc....

    2. Re:two factor? by AHuxley · · Score: 2

      http://arstechnica.com/security/news/2011/06/rsa-finally-comes-clean-securid-is-compromised.ars offers hints?

      --
      Domestic spying is now "Benign Information Gathering"
    3. Re:two factor? by makomk · · Score: 2

      OK that's exactly what I'm looking for. So its no worse than dropping back to "one factor".

      Unfortunately, RSA have tended to encourage customers to use a 4 digit numeric password with SecurID in the past because the security of the dongle supposedly made this safe, and this is the single factor that their level of security has now been reduced too. Hence why they were so keen to encourage the use of strong passwords by their customers when they first discovered they'd been hacked.

    4. Re:two factor? by Julie188 · · Score: 2

      It says that RSA isn't really coming clean with the details. Story says, "Coviello defended the company's decision by saying that they didn't want to reveal to the hackers how to mount further attacks." Of course, blackhats already know how to mount the attack ... by not coming clean with the details the ones that don't know how this happened and what they could be doing to protect themselves are the users.

      Julie
      Open Source Subnet

  11. Comment removed by account_deleted · · Score: 3, Insightful

    Comment removed based on user account deletion

  12. Re:After it was obvious to all by i_ate_god · · Score: 2

    Their public statement, and their NDA-protected message given directly to clients are two, very different things.

    --
    I'm god, but it's a bit of a drag really...
  13. Comment removed by account_deleted · · Score: 2

    Comment removed based on user account deletion

  14. Re:And the worst part.... by Anomalyst · · Score: 2

    Which is great until you slip and stab yourself in the fucking hand.

    So use use the hand not involved in carnal relations, duh.

    --
    There is no right to feel safe thru security vaudeville at the expense of everyone's freedom, privacy and tax money.