Slashdot Mirror

← Back to Stories (view on slashdot.org)

Hackers Compromise ICANN, Access Zone File Data System

Posted by timothy on from the that-should-be-a-boss-level dept.

Trailrunner7 writes with this news from ThreatPost: Unknown hackers were able to compromise vital systems belonging to ICANN, the organization that manages the global top-level domain system, and had access to the system that manages the files with data on resolving specific domain names. The attack apparently took place in November and ICANN officials discovered it earlier this month. The intrusion started with a spear phishing campaign that targeted ICANN staffers and the email credentials of several staff members were compromised. The attackers then were able to gain access to the Centralized Zone Data System, the system that allows people to manage zone files. The zone files contain quite bit of valuable information, including domain names, the name server names associated with those domains and the IP addresses for the name servers. ICANN officials said they are notifying any users whose zone data might have been compromised." (Here's ICANN's public note on the compromise.)

110 comments

  1. So that's why Slashdot has been screwed up! by TWX · · Score: 4, Funny

    This explains a lot! We're not posting on the real Slashdot at all! We're on someone's bad copy! The entire "beta" thing was just a hijack attempt!

    --
    Do not look into laser with remaining eye.
    1. Re:So that's why Slashdot has been screwed up! by Anonymous Coward · · Score: 0

      I'd like to think that the NSA would have devised something better than Slashdot Beta, if they were not only MITMing Slashdot (as they have done in the past) but replacing it with a whole new system. God only knows what kind of budget the NSA really has; you think they could have come up with a better system than Beta.

    2. Re:So that's why Slashdot has been screwed up! by TWX · · Score: 1

      No dice, huh?

      --
      Do not look into laser with remaining eye.
    3. Re:So that's why Slashdot has been screwed up! by MobSwatter · · Score: 1

      Wasn't the RIAA exposed to have interest in attacking DNS? No doubt NSA has been in there a long time but this news is recent, nothing like a batch of movie industry lawyers putting off the fact that movie sales are down because they have only been producing sh!t for movies lately, so they are doing the only intelligent thing. Pass the buck, blame it on piracy. I for the life of me can't figure out why anyone would want to pirate this crap.

  2. fire them by Megor1 · · Score: 1, Insightful

    Any employee dumb enough to fall for a phish should be fired.

    --
    Everyone that disagrees with me is a paid shill
    1. Re:fire them by CaptainDork · · Score: 3, Insightful

      Any IT shop that ain't got the sense god gave a pissant to identify a phishing attack programmatically and shield employees who work on the INCOME side of the ledger, as opposed to IT, which is on the EXPENSE side, needs to be hit over the head with a wet squirrel and stuff.

      --
      It little behooves the best of us to comment on the rest of us.
    2. Re:fire them by NatasRevol · · Score: 1

      I'm not sure a wet squirrel would hurt much...

      --
      There are two types of people in the world: Those who crave closure
    3. Re:fire them by Mr+D+from+63 · · Score: 2, Insightful

      Any employee dumb enough to fall for a phish should be fired.

      I agree, when you work for ICANN or an organization of similar responsibility, there has to be some accountability at the employee level.

    4. Re:fire them by cyberchondriac · · Score: 4, Funny

      I think the squirrel would disagree..

      --

      Look back up at my post, now look back down, you're on the Internet. Now look back up. I'm a signature.
    5. Re:fire them by WaffleMonster · · Score: 3, Informative

      Any employee dumb enough to fall for a phish should be fired.

      The messages were *targeted* they appeared to come from real people within the company. If your PM sent you a word doc detailing a new project proposal and you opened it should YOU be fired?

      SMTP email is a failed experiment causing untold damage to millions of users around the world.

    6. Re:fire them by CaptainDork · · Score: 1

      When I was a young lad and Moby Dick was a minnow, my dad took me squirrel hunting up in the piney woods of Southeast Texas.

      When I shot a squirrel with my .410 shotgun, invariably the rodent would fall into a creek or nasty bog.

      Upon picking it up, the wet squirrel smelled and felt like a musty old mop.

      It wasn't a matter of pain. It was the disgusting smell and texture.

      --
      It little behooves the best of us to comment on the rest of us.
    7. Re:fire them by Anonymous Coward · · Score: 0

      My guess is that the employee didn't see that the phishing email address came from icann.corn instead of icann.com.

    8. Re:fire them by Archangel+Michael · · Score: 3, Insightful

      If my PM sent me a word doc via email, especially if it was sensitive, I would fire the PM for incompetence. Files should be stored on servers where proper security can be enabled and monitored. Once a doc gets attached to email, you have lost all control over it.

      Document control systems need to be in place, and email is not a document control system.

      --
      Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
    9. Re:fire them by Anonymous Coward · · Score: 0

      Yes because we use a network, SAMBA, for distributing attachments instead of our mail server. If there are attachments in an e-mail I ALWAYS confirm that it was intended to be there.

    10. Re:fire them by Anonymous Coward · · Score: 0

      Ah, but wet with what? Water, you expected? Ha.

    11. Re: fire them by Anonymous Coward · · Score: 0

      SMTP is fine. The failed experiment is allowing binary attachments and HTML because "oooh, shiny!"

      Accommodating the wants of shallow unthinking users has been the ultimate cause of all Internet badness.

    12. Re:fire them by CaptainDork · · Score: 1

      I didn't say, PAID on ... I said WORK on ...

      My coworkers and bosses work hard to maintain or increase the revenue stream.

      I'm always asking for money and those people have to swim a little harder to make up the difference.

      --
      It little behooves the best of us to comment on the rest of us.
    13. Re:fire them by omglolbah · · Score: 5, Interesting

      We have a document control system at work, it has grown to such a degree that adding a document is a 3 day process involving a document controller and various other tasks. If the document does not fit a corporate template it may get rejected.

      At that point people tend to go "fuck it" and just send around work copies until it is finalized and THEN go through the hassle.

      It is unfortunate, but I've seen it happen in two different companies so far... both multinational, both ignoring their own procedures for sensitive data.

    14. Re:fire them by Anonymous Coward · · Score: 0

      I'm not sure a wet squirrel would hurt much...

      It will if it's just come out of the freezer.

    15. Re:fire them by sjames · · Score: 3, Insightful

      If anyone doesn't think IT is on the INCOME side, they should give the sales guys a pad and a pencil and shut down IT services for a week. Let's see how much INCOME they have then. Make that week during payroll and lets see what their INCOME looks like when nobody gets paid.

    16. Re:fire them by Anonymous Coward · · Score: 0, Flamebait

      Do you go out of your way to say stupid things, or does it just come naturally?

      To belabor the obvious, it's hard to do business without electricity or a building, too. That doesn't mean paying your electricity bill is the same thing as generating income. IT is a cost center, get over it.

    17. Re: fire them by Anonymous Coward · · Score: 2, Interesting

      No, the GP is correct. Our head accountant recently received an email from our "CEO" telling her to wire some money for services our CEO has used. The perpetrators had done their research, right down to the actual full name of our real CEO and person responsible for the finances. Replies were sent to the Return-Path: header that is not in our domain. Were it not for the difference in email address scheme (first initial, all last name @ domain vs. full first name @ domain) and our existing offline, verbal confirmation for wire transfers exceeding a certain amount, our accountant would not have caught it.

      This is conducted all in standard email. No attachments. No fancy HTML.

    18. Re:fire them by Anonymous Coward · · Score: 1

      I wholly support this sentiment! Especially when Corporate Executives launch unknown attachments from unknown recipients causing a virus outbreak.

      I know what you're thinking: why didn't the Antivirus software catch it!?!? That's a damn good question Bob. Damn good question!

    19. Re: fire them by Anonymous Coward · · Score: 0

      Better yet, anyone that falls for social engineering attempts gets executed immediately!!!

    20. Re:fire them by sjames · · Score: 1

      Put the cheetoes down so you can talk with your mouth instead of your butt.

      By that criterion, sales and marketing are also cost centers. It would be ever so much cheaper to do business if you could just ship product at random and actually get paid. Buty you can't, so you need sales and marketing. It would be nice if the building would clean itself so you could skip janitorial without swimming in trash and filth but you can't.

      Everything is a cost and in a well run business, everything in some way contributes to income. Get over it. Trying to divide entire functions into income or expense just demonstrates an incomplete and fragmented understanding of the system.

    21. Re:fire them by Anonymous Coward · · Score: 0

      Depends on the company. What if they routinely send employees emails with links to enter log-in information?

    22. Re:fire them by Anonymous Coward · · Score: 0

      It is obvious (to me) what he means to say and frankly if you don't pay your electricity his point stands that it would be awfully difficult to sell a service/hosting/whatever with the lights out. He is commenting on the INCOME center vs "COST" center bullshit thinking.

      No IT is not the only important thing but it is often difficult/depressing/outrageous how hard it is to get money for the IT that many businesses rely on these days.

    23. Re: fire them by networkzombie · · Score: 1

      Do you run your own SMTP server? No email with your FQDN should be accepted via public incoming SMTP port, only private encrypted SMTP port with AUTH should be used for MUAs and MTAs (message submission). Why would your server accept email from itself? Incoming SMTP ports should never accept email from it's own domain. This way, if you get an email as you describe, you can verify that the account has been compromised.

    24. Re:fire them by Anonymous Coward · · Score: 0

      Satan Lover?

    25. Re:fire them by Anonymous Coward · · Score: 0

      Yes, the Expense side, where company's notoriously slash budgets, hire the cheapest people they think might get the job done. and only keep people who are barely good enough to not get fired because anyone better gets out of companies like that and works for people who will actually pay them a decent wage and not look at their department as simply an expense. Your an idiot and your whole concept of how to run a business is the reason people are constantly getting hacked, because businesses that look at IT employee's as simply an expense they need to live with and minimize will never buy people talented enough to actually protect them, or have enough IT staff to worry about security after the regular care and feeding is done.

    26. Re: fire them by Anonymous Coward · · Score: 0

      Same here! Got phishers even calling on the phone using falsified caller-id and combining with mails from and to real e-mail addresses that only differ trivially from the domain belonging to the real company. In one instance caught because the person actually knew the voice of the person being impersonated, in another because the tone of the e-mail was subtly off, but in several others only because of company-mandated third-person security verification. S/MIME...

    27. Re: fire them by nabsltd · · Score: 0

      Incoming SMTP ports should never accept email from it's own domain.

      As you can see from his post, his server did not accept an e-mail "from it's own domain":

      Replies were sent to the Return-Path: header that is not in our domain.

      "Return-Path" is an SMTP header generated by the MTA based on the what it received in the envelope. It's generally only created by an intermediate internal server that forwarded e-mail, thus changing the "From:" envelope address.

      And, even a perfectly configured MTA that rejects any "From:" envelope address that is in a domain for which the MTA is an MX still can't stop phishers from forging the "From:" header, which is just part of the body of the e-mail. Unfortunately, the envelope address usually never gets to the MUA, so an e-mail can look like it's legitimately from an internal source. If you use an MUA like Outlook that hides all the technical info, it's easy to be fooled.

    28. Re: fire them by Obfuscant · · Score: 2

      "Return-Path" is an SMTP header

      SMTP doesn't have headers. SMTP is a protocol for message transport.

      thus changing the "From:" envelope address.

      There is likewise no "From:" envelope address. There is an envelope-sender (the argument to the SMTP "MAIL FROM" command) which is often inserted into a "Return-Path" header in the message, and is used in the mailbox separator "From" line in mbox email storage.

      ... still can't stop phishers from forging the "From:" header, which is just part of the body of the e-mail.

      The "From:" header is a header, not something in the body of the message. As a header, it is subject to rewriting by transport agents.

      Unfortunately, the envelope address usually never gets to the MUA,

      The MUA has access to all headers in an email, including "Return-Path". It is usually never shown to the user, but a good MUA will have an option to show raw email, including headers. Why? For just this reason.

      If you use an MUA like Outlook that hides all the technical info, it's easy to be fooled.

      Well, there you go. I did say a GOOD MUA ...

      There are several issues at play here:

      1. Employees at a company that manages a huge part of the control of the Internet can't detect phishing email by looking at the address replies will go to.

      2. The email system at said company creates email replies based on information that is supposed to be used ONLY for the transport system to report delivery issues.

      3. The offline verification process intended to stop such fraud worked, which makes this a non-story from the beginning.

    29. Re:fire them by CaptainDork · · Score: 1

      Mod +1 if I could.

      --
      It little behooves the best of us to comment on the rest of us.
    30. Re:fire them by kmoser · · Score: 1

      If these messages appeared to come from real people within the company but really originated outside, they should have had spam filters in place to detect that. In either case, I'm going to go out on a limb and guess they're all running Windows.

  3. Shocked I am not by damn_registrars · · Score: 1

    ICANN is a bunch of incompetent greedy buffoons. I wouldn't expect them to be any more capable of resisting a phishing attack than the pointy-haired boss from Dilbert.

    --
    Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
  4. Some people better be out of a job... by Anonymous Coward · · Score: 1

    ICANN is one of those places that are paid NOT to fuck up. Given that a phishing attack combined with a weeks to month long exploit time indicates a number of people weren't doing their job, followed best security practices, etc.

    Personally I am of the opinion that it is time for ICANN and the legacy DNS system to be obsoleted, all organizations related to it disbanded, and discusisons begun on doing the same for IANA. The bureacracy involved in each has been a tolerated evil on the internet since at least the 90s, but this latest failure just indicates that very little has been learned by the organizations in their 20+ year tenures.

    1. Re:Some people better be out of a job... by TWX · · Score: 4, Interesting

      And replace it with what, exactly?

      Seriously, how do you intend to manage all of the addressing, both the IP level and the human-readable level, without some form of central authority?

      --
      Do not look into laser with remaining eye.
    2. Re:Some people better be out of a job... by mmell · · Score: 4, Funny

      I'll bet he could tell you. He has written a hostfile manager that guards your home, brings you your slippers and makes your coffee in the morning.

    3. Re:Some people better be out of a job... by bmo · · Score: 1

      Peer Name Resolution.

      The problem is that it's patent encumbered, by Mickeysoft, so it's useless.

      There is also something called Hierarchical DHT-based name resolution.

      Abstract:

      Information-centric network (ICN) architectures are an increasingly important approach for the future Internet. Several ICN approaches are based on a flat object ID namespace and require some kind of global name resolution service to translate object IDs into network addresses. Building a world-wide NRS for a flat namespace with 10^1^6 expected IDs is challenging because of requirements such as scalability, low latency, efficient network utilization, and anycast routing that selects the most suitable copies. In this paper, we present a general hierarchical NRS framework for flat ID namespaces. The framework meets those requirements by the following properties: The registration and request forwarding matches the underlying network topology, exploits request locality, supports domain-specific copies of binding entries, can offer constant hop resolution (depending on the chosen underlying forwarding scheme), and provides scoping of publications. Our general NRS framework is flexible and supports different instantiations. These instantiations offer an important trade-off between resolution-domain (i.e. subsystem) autonomy (simplifying deployment) and reduced latency, maintenance overhead, and memory requirements. To evaluate this trade-off and explore the design space, we have designed two specific instantiations of our general NRS framework: MDHT and HSkip. We have performed a theoretical analysis and a simulation-based evaluation of both systems. In addition, we have published an implementation of the MDHT system as open source. Results indicate that an average request latency of (well) below 100ms is achievable in both systems for a global system with 12 million NRS nodes while meeting our other specific requirements. These results imply that a flat namespace can be adopted on a global scale, opening up several design alternatives for information-centric network architectures.

      http://dl.acm.org/citation.cfm...

      --
      BMO

    4. Re:Some people better be out of a job... by rdnetto · · Score: 1

      And replace it with what, exactly?

      Seriously, how do you intend to manage all of the addressing, both the IP level and the human-readable level, without some form of central authority?

      I've been playing around with some ideas lately on how to implement a decentralised DNS, and what it basically comes down to is how you resolve conflicts. e.g. Microsoft reserves www.microsoft.com, then I try to do so. Ideally, the order shouldn't affect the final result, because a first-come-first-server system encourages squatting. Crypto-based systems also have to consider if the domain name can be reacquired if the private key is lost/stolen.
      Here's a quick summary of the different approaches:

      Traditional DNS: uses first-come-first-serve (FCFS) and conflicts are resolved through legal means (trademark law). Conflicts are resolved by the registrar - the second application is denied because the name is already in use. Centralized.

      mDNS: uses multicast, impractical for global usage. No conflict resolution. This is the only decentralized approach that doesn't involve a DHT.

      Microsoft PNRP: requires registrars which sign names to handle conflict resolution. (The unsecured variant has no conflict resolution.) Also requires IPv6, which is currently impractical.

      Namecoin (decentralized with FCFS): Conflict resolution is implemented algorithmically. There is a small (1 cent) cost associated with updates.

      Decentralized with voting: whichever resolvent the majority decide is official gets the domain name. Impractical, due to ease with which fake votes could be created. (Can be mitigated by making voting expensive - the bitcoin approach.)

      Decentralized with trust-on-first-use (TOFU): conflict resolution is implemented by the resolver. Where there is a unique resolvent, it is used and added to a list of trusted resolvents. Where there are multiple resolvents, and the name has not been resolved by the user previously, the client may check white/blacklists published by other clients whom they have previously marked as trusted. If unique resolution is still not possible, manual intervention is required.

      Currently I'm leaning towards the TOFU approach, since it's an extension of what's currently used for SSH clients. The only issue is that allowing multiple clients to resolve the same name differently borders on breaking the internet (see RFC 2826). However, it does have the nice property that it's the only decentralized system where a name-holder have their private key seized by an attacker, and still recover the domain name (by creating new keys and having people blacklist the old domain name in favour of them).

      If anyone has some ideas/suggestions on this, I'd love to hear them.

      --
      Most human behaviour can be explained in terms of identity.
  5. DNSSEC by fph+il+quozientatore · · Score: 1

    So, I assume DNSSEC is screwedcompromised already?

    --
    My first program:

    Hell Segmentation fault

    1. Re:DNSSEC by Ethanol · · Score: 2

      No. DNSSEC keys are in stored in a vault and only brought out for signing ceremonies. As far as I can tell, bad guys will have gotten access to some potentially valuable identity information and passwords, and copies of TLD zone files; nothing related to DNSSEC.

    2. Re:DNSSEC by Anonymous Coward · · Score: 0

      Ah, no. DNSSEC does not work this way. The only DNSSEC data stored is public data that is deliberately widely disseminated in may ways. If the data was modified in any way, it would have simply broken validation for the world. That would effectively take all validating sites off-line, but would be easily fixed. DNSSEC is predicated on having no secret information on-line, especially at the root.

    3. Re:DNSSEC by marka63 · · Score: 1

      For the root zone there is very little that is actually signed as most of the root zone is delegating NS records (not signed just their presence in the NSEC record is signed) and glue address records (not signed). If you can alter the root zone contents you can introduce new DS records matching DNSKEY records you control. These would then get signed and if you can direct your targets to this alternate version of the TLD it will be accepted as valid. This will only work until the zone signing key is rolled at which stage the DNSSEC validation chain will no longer work and you will need to go back and get the DS re-signed. Actually changing the root zone contents like this will almost certainly be caught as it is a highly examined zone. In particular people checking DS/DNSKEY pairs looking for errors so they can be fixed quickly. Now if you can get someone to sign a isolated DS RRset that is not in the root zone but is for a TLD then this could go undetected for longer but that is a much harder problem than just changing the root zone contents. That still only has a limited lifetime as the RRSIGs need to be refreshed.

      The signing ceremony is where the DNSKEY RRset is re-signed to introduce / remove zone signing keys. The private part of the zone signing key has to be available on a day to day basis for the normal day to day changes in the root zone. That said the private part is still held in a HSM and the worst that can happen is that someone can get some data signed which can be used until the zone signing key is rolled.

  6. Apparently I've been a hacker for years by kdub007 · · Score: 4, Insightful

    I've been able to get all of that info for 15 years using the apparently malicious tool, WHOIS. Now, if they were able to change that data, that's different, but according to this post, all the "hackers" got was publicly available information.

    --
    The correct answer is 42.
    1. Re:Apparently I've been a hacker for years by kdub007 · · Score: 0

      Name: slashdot.org IP: 216.34.181.45 Domain: slashdot.org Querying root.rwhois.net:4321 for slashdot.org... Can not resolve host 'root.rwhois.net' Querying whois.pir.org for slashdot.org... Domain Name:SLASHDOT.ORG Domain ID: D2289308-LROR Creation Date: 1997-10-05T04:00:00Z Updated Date: 2014-03-14T22:12:11Z Registry Expiry Date: 2015-10-04T04:00:00Z Sponsoring Registrar:Tucows Inc. (R11-LROR) Sponsoring Registrar IANA ID: 69 WHOIS Server: Referral URL: Domain Status: clientTransferProhibited Domain Status: clientUpdateProhibited Registrant ID:tuE8gFbzWFO9qSj2 Registrant Name:Host Master Registrant Organization:Dice Holdings, Inc. Registrant Street: 1040 Avenue of the Americas Registrant Street: ATTN Slashdot Media Registrant Street: 16th Floor Registrant City:New York Registrant State/Province:NY Registrant Postal Code:10018 Registrant Country:US Registrant Phone:+1.8557527436 Registrant Phone Ext: Registrant Fax: Registrant Fax Ext: Registrant Email: mailto:hostmaster@slashdotmedi... Admin ID:tuVUNO2QRhDH8FrR Admin Name:DNS Admin Admin Organization:Dice Holdings, Inc. Admin Street: 1040 Avenue of the Americas Admin Street: ATTN Slashdot Media Admin Street: 16th Floor Admin City:New York Admin State/Province:NY Admin Postal Code:10018 Admin Country:US Admin Phone:+1.8557527436 Admin Phone Ext: Admin Fax: Admin Fax Ext: Admin Email: mailto:dns-admin@slashdotmedia... Tech ID:tuSiUEvdGR8LFGdK Tech Name:DNS Technical Tech Organization:Dice Hol dings, Inc. Tech Stree t: 1040 Avenue of the Americas Tech Street: ATTN Slashdot Me dia Te ch Street: 16th Floor Tech City:New York Tech State/Province:NY Tech Postal Code:10018 Tech Country:US Tech Phone:+1.8557527436 Tech Phone Ext: Tech Fax: Tech Fax Ext: Tech Email: mailto:dns-tech@slashdotmedia.... Name Server:NS3.P03.DYNECT.NET Name Server:NS1.P03.DYNECT.NET Name Server:NS2.P03.DYNECT.NET Name Server:NS4.P03.DYNECT.NET Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: DNSSEC:Unsigned Access to Public Interest Registry WHOIS information is provided to assist persons in determining the contents of a domain name registration record in the Public Interest Registry registry database. The data in this record is provided by Public Interest Registry for informational purposes only, and Public Interest Registry does not guarantee its accuracy. This service is intended only for query-based access. You agree that you will use this data only for lawful purposes and that, under no circumstances will you use this data to(a) allow, enable, or otherwise support the transmission by e-mail, telephone, or facsimile of mass unsolicited, commercial advertising or solicitations to entities other than the data recipient's own existing customers; or (b) enable high volume, automated, electronic processes that send queries or data to the systems of Registry Operator, a Registrar, or Afilias except as reasonably necessary to register domain names or modify existing registrations. All rights reserved. Public Interest Registry reserves the right to modify these terms at any time. By submitting this query, you agree to abide by this policy. Querying whois.arin.net for 216.34.181.45... # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou... # # If you see inaccuracies in the results, please report at # http://www.arin.net/public/who... # # # Query terms are ambiguous. The query is assumed to be: # "n 216.34.181.45" # # Use "?" to get help. # # # The following results may also be obtained via: # http://whoi

      --
      The correct answer is 42.
    2. Re:Apparently I've been a hacker for years by EndlessNameless · · Score: 1

      If you actually read the article, you would see that they had administrative access to the zone files. Which means they could have changed whatever they wanted. They also had access to usernames and passwords, so hopefully no one used the same credentials elsewhere.

      Get back to us when you pull that off with whois.

      --

      ---
      According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
    3. Re:Apparently I've been a hacker for years by Anonymous Coward · · Score: 0

      Completely misunderstands the situation and modded insightful. This site is turning into a trash heap.

    4. Re:Apparently I've been a hacker for years by Cramer · · Score: 1

      Nope. Lame summary: The zone files contain quite bit of valuable information... *Other* files with the CZDS held usernames and encrypted passwords. That is the only "valuable" non-public information.

  7. email credentials = root? by Anonymous Coward · · Score: 0

    How does capturing email credentials of a user give you access on the roots?

  8. Hey by Anonymous Coward · · Score: 0

    The attackers then were able to gain access to the Centralized Zone Data System

    Hey, I think I see the problem!

  9. Damn Sony! by Anonymous Coward · · Score: 0

    Now they've hacked ICANN to save some crappy movie and a little face for being so self absorbed?

  10. Is it old-fashioned of me to think.... by Glasswire · · Score: 2

    ... that administrative changes at this level should only be allowable from physical access to closed admin networks and the value of having staff be able to make changes in their PJs from some hotel room is overrated?

    1. Re: Is it old-fashioned of me to think.... by Anonymous Coward · · Score: 0

      Yeah, but what about mobile first and cloud only? What are you, stuck in 2013 or something?

    2. Re:Is it old-fashioned of me to think.... by Xest · · Score: 1

      This was my first thought when I read about this yesterday too. Why oh why isn't such an important system air gapped from the rest of the general drones in ICANN's offices?

      I mean seriously? Can the fucking receptionist communicate directly with these core servers for example?

      I know it's hard for many IT workers, but sometimes you just need to get off your fat arse and walk over to the system you need to administer to maintain security. Anyone working somewhere important like ICANN that puts convenience of being able to remain on their arse over security needs to be fired. If they want a job where they can put convenience over security then they can go work in 99% of other organisations that don't need that level of security.

  11. Infrastructure on the Internet by Anonymous Coward · · Score: 0

    I've said it before, and I'll say it again: critical infrastructure should NOT be on the Internet!

    Oh, wait...

  12. somewhat. SPEAR phishing by raymorris · · Score: 2

    I partially agree, but remeber this was SPEAR phishing. When you get an email from your boss, with your boss's normal signature, using terms and abbreviations that your company normally uses, your first thought probably isn't "is this a phish?"

    1. Re:somewhat. SPEAR phishing by RLaager · · Score: 1

      My SMTP server will not accept an email claiming to be from my boss* (in either the envelope or a From: header) unless it was sent by him using SMTP AUTH.

      * Or most of my users; this is our default, with an opt-out option.

    2. Re:somewhat. SPEAR phishing by Anonymous Coward · · Score: 0

      Why isn't everyone's boss using SMIME or PGP for authentication, if not also encryption? These tools are free, and SMIME is built into almost every non-web-based email program around. PGP is harder, because it requires an add-on of some sort, but it's not beyond the realm of the manageable. Companies, and especially entities like ICANN, ought to be provisioning SMIME certs to their employees and using authenticated SMTP; mailservers can filter out mail that claims a false identity before it even reaches employees, and the mail reader's authentication of the SMIME or PGP signature should serve as another level in a defense-in-depth strategy. As an added bonus, SMIME and PGP allow encryption if data is sensitive (the company can secure a copy of the provisioned keys somewhere for mail retention and archiving purposes).

      There's no excuse for spearphishing with an internal persona to work in 2014.

  13. Re:"He" has (what about you?)... apk by Anonymous Coward · · Score: 0

    * Boy, lol: I truly *REALLY * must've "gotten a piece of you" before, that you're SO obsessed with myself...

    Because TWX clearly knew which of hundreds of AC's had posted.

  14. Let me be the first to say that by organgtool · · Score: 4, Funny

    This never would have happened if there was an air gap between the DNS servers and the internet.

  15. CZDS isn't about managing zone files by MrCawfee · · Score: 4, Informative

    ...it is about publishing them. You can request a free account and download the current zone file for the root dns.

    Verisign also provides this service for free for .COM and .NET, CZDS is just a centralized place so you can get the zones for all the new gTLDs without requesting accounts at 500 registries.

    This hack, while bad, doesn't directly affect the root dns system.

  16. Re:When IANA & ICANN mess up zone data by Anonymous Coward · · Score: 0

    I do for 24 of my favorite sites where I spend 95++% of my time online

    Can I get a list of the other 23, so that I can blackhole them in my own resolver?

  17. DNSSEC by Anonymous Coward · · Score: 0

    Probably not - the private portion of the root zone key is stored in offline HSM's locked in vaults in data centers on either coast. The attackers could have changed the key in the zone file, then DNSSEC would have worked as advertised. DNSSEC validating clients would have detected the change and thrown errors. It probably won't have even gotten that far - Verisign actually signs the zone file and would have detected the change even before pushing it out to the authoritative servers.

    ICANN's policy is documented here: https://www.iana.org/dnssec/icann-dps.txt

  18. Re:"He" has (what about YOU off-topic troll?) by Anonymous Coward · · Score: 0

    mmell won't answer you. He's an off topic "ne'er-do-well" troll as you stated.

  19. You can get zone files here by Anonymous Coward · · Score: 0

    https://www.iana.org/domains/r... served from the authoritative DNS root servers http://www.root-servers.org/

    APK

    P.S.=> For anyone that's interested in the specifics here... apk

  20. Wouldn't happen IF you did this... apk by Anonymous Coward · · Score: 0

    Bypass DNS entirely, & be faster locally resolving + more reliable http://tech.slashdot.org/comme...

    * :)

    ("Onwards & UPWARDS...")

    APK

    P.S.=> Thus, for those of you with custom personal local hosts files on their systems, hardcoding the proper host-domain name translation resolution to IP Address, in hosts THIS IS NO ISSUE - as hosts files allow you to bypass compromised DNS entirely (vs. DNS redirect or records alteration + wipeout) & to resolve them locally, faster, for more reliability as well... apk

  21. Re:When IANA & ICANN mess up zone data by Anonymous Coward · · Score: 0

    So tell me what happens to your precious hosts file when the site operator changes the IP address three times in a week?

    Huh?

  22. You change hosts hardcodes then, simple by Anonymous Coward · · Score: 0

    See subject: My program helps you do so in its "Speedup Favorite Sites" tab http://start64.com/index.php?o...

    * Simple!

    APK

    P.S.=> Additionally, though I *really* shouldn't have to say it: Most GOOD website operators LET YOU KNOW they're doing so (usually when they find a better hosting plan that costs less, etc.)... apk

  23. Where are the by Anonymous Coward · · Score: 0

    CANN I HAZ jokes ? Maybe this is a fake bad copy of Slashdot.

  24. The bad puns... by Arterion · · Score: 1

    I know this it totally off-topic and may hurt my karma, but ICANN not resist the temptation. I just don't have the resolve. I'm phishing for puns. What's your best ICANN pun?

    --
    "That which does not kill us makes us stranger." -Trevor Goodchild
    1. Re:The bad puns... by Anonymous Coward · · Score: 0

      ICANN see your zones

    2. Re:The bad puns... by Anonymous Coward · · Score: 0

      ICANN't believe it's not better

    3. Re:The bad puns... by Anonymous Coward · · Score: 0

      I think ICANN I think ICANN said the little engine that could.

    4. Re:The bad puns... by Anonymous Coward · · Score: 0

      ICANN haz dns?

  25. Who are you? by mmell · · Score: 1

    (N/T)

  26. Why, thank you! by mmell · · Score: 2

    Coming from you Al, that's a compliment!

  27. Re: "He" has (what about YOU off-topic troll?) by Redmancometh · · Score: 1

    You're an idiot.

  28. When IANA & ICANN mess up zone data by Anonymous Coward · · Score: 0

    BYPASS poisoned DNS using hosts for favorite sites online (it works just as it does for the SONY/Hollywood debacle yesterday -> http://yro.slashdot.org/commen... ).

    I do for 24 of my favorite sites @ the TOP of my hosts file to avoid DNS redirect poisoning (kaminsky bug, of which 99.999% of ISP DNS are *NOT PATCHED* against mind you) & downed DNS too, resolving sites FASTER locally from RAM, once cached.

    That equates to approximately 2-3 MILLION indexed lookups (in wasted time querying remote DNS which is exploitable as hell & insecure, mostly) & works for me locally, faster & more reliably by far vs. such exploits this article notes + more, & 95++% of the time (per my router logs).

    Now - Sub 4% of the time, when I DO have to use remote DNS, I use OpenDNS (secured, filtered vs. threats, patched vs. the Kaminsky flaw & DNSSEC secured to its upstream updaters too).

    ---

    I use this to create such a useful file in hosts (to get more speed via the above technique WITH THE PROTECTION IT AFFORDS, & EVEN MORE SPEED, by blocking ads, protection vs. exploits from botnet C&C servers, rogue DNS server, malicious script housing sites/servers, known bad domains-subdomains/hosts, phish/spam, etc. - et al):

    APK Hosts File Engine 9.0++ 32/64-bit:

    http://start64.com/index.php?o...

    * It works better + more efficiently than *ANY* SINGLE "so-called 'solution'" out there, bar-none...

    The page lists SOME of what hosts can do for you, in added speed, security, reliability, (& even anonymity to an extent in the latter only).

    ( Nice part, how hosts compliment DNS Besides overcoming its security issues, such as this one & others shown, etc.? Hosts used thus also lightens dns server request loads - admins of them should like that...)

    APK

    P.S.=> Enjoy - it's 100% free, no strings attached, & my program is recommended + hosted by MalwareBytes' hpHosts (reputable + reliable as it gets) -> http://hosts-file.net/?s=Downl...

    ... apk

  29. Root DNS *was* affected... apk by Anonymous Coward · · Score: 0

    "This hack, while bad, doesn't directly affect the root dns system." - by MrCawfee (13910) on Thursday December 18, 2014 @11:54AM (#48626607)

    ICANN Hacked Including Root DNS Systems -> http://www.darknet.org.uk/2014... *OR* http://www.theregister.co.uk/2... on that account...

    * ANYONE WONDERING WHY I DO THIS TO OVERCOME THOSE SECURITY ISSUES ETC> IN DNS? Don't -> http://tech.slashdot.org/comme...

    APK

    P.S.=> It works... apk

  30. Mmell fails again vs. apk as always by Anonymous Coward · · Score: 0

    You vainly tried to hide what's in my subject above vs. this http://tech.slashdot.org/comme... where hosts files cure this problem and actually compliment DNS shoring up its security issues in redirects, records removals, and being down also as well as lightening up dns server request loads (and hosts do more than any single browser addon more efficiently too as a native part of the ip stack itself in kernelmode, not layering on more in a slower mode of operations with more messagepassing overheads in usermode). Downmodding apk's facts of all of this, 20 times now? You fail.

  31. Answer a question, mmell by Anonymous Coward · · Score: 0

    What's it like getting your ass kicked by apk + downmodding to hide it 20x http://tech.slashdot.org/comme... ?

  32. Answer a question, mmell by Anonymous Coward · · Score: 0

    What's it like getting your ass kicked by apk + downmodding to hide it 20x http://tech.slashdot.org/comme... ?

  33. You're weak & stupid by Anonymous Coward · · Score: 0

    Why can't you prove apk wrong? Hosts work vs. this DNS issue, no doubt about it.

  34. If it ever happens, I'll let you know. by mmell · · Score: 1

    N/T

  35. Have you written a better program? by Anonymous Coward · · Score: 0

    That solves this issue as apk has? No, obviously, since you wouldn't answer (or rather you couldn't, since you're not skilled enough to code) and instead you minus modded rampantly, 20 times or more, when confronted on that much.