Hackers Compromise ICANN, Access Zone File Data System
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.)
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.
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.
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.
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.
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.
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.
... 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?
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.
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.
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?"
This never would have happened if there was an air gap between the DNS servers and the internet.
...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.
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.
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.
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.
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.
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.
Coming from you Al, that's a compliment!
"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.