NYT: Internet attack called broad and long lasting
Internet Attack Called Broad and Long Lasting by Investigators By JOHN MARKOFF and LOWELL BERGMAN Published: May 10, 2005 SAN FRANCISCO, May 9 - The incident seemed alarming enough: a breach of a Cisco Systems network in which an intruder seized programming instructions for many of the computers that control the flow of the Internet. [...] See the New York Times for the rest of the story.
O, my god. Primitive hack, primitive ssh exploit.... I watched it all 6 years ago, bnothing changed since this. It is _minor_ incident, in reality. ----- Original Message ----- From: "Sean Donelan" <sean@donelan.com> To: <nanog@merit.edu> Sent: Monday, May 09, 2005 10:32 PM Subject: NYT: Internet attack called broad and long lasting
Internet Attack Called Broad and Long Lasting by Investigators By JOHN MARKOFF and LOWELL BERGMAN
Published: May 10, 2005
SAN FRANCISCO, May 9 - The incident seemed alarming enough: a breach of a Cisco Systems network in which an intruder seized programming instructions for many of the computers that control the flow of the Internet.
[...] See the New York Times for the rest of the story.
Alexei Roudnev wrote:
O, my god. Primitive hack, primitive ssh exploit.... I watched it all 6 years ago, bnothing changed since this.
It is _minor_ incident, in reality.
Primitive I can understand, but _minor_? First, I don't really see why an attack should be estimated by the tool used. If a 10 years old exploit would work, why should an attacker look for and use a 0day? It's silly allocation of resources. Burrowing from that, if the attack is successful, and the loss is significant, I think the way there - although cute, is irrelevant except for the defender. Gadi.
On Wed, 11 May 2005 13:44:22 +0300, Gadi Evron said:
First, I don't really see why an attack should be estimated by the tool used. If a 10 years old exploit would work, why should an attacker look for and use a 0day? It's silly allocation of resources.
Burrowing from that, if the attack is successful, and the loss is significant, I think the way there - although cute, is irrelevant except for the defender.
Actually, it *is* relevant for the "rest of us". Given the number of boxen that got whacked, and the number of sites involved, "the defender" *is* "the rest of us", and "we as an industry" obviously need to get our collective act in gear. Remember - *Your* boxes may be hardened beyond all belief and plausibility, but you're *STILL* screwed if some teenaged kid on another continent has more effective control of the router at the other end of your OC-48 than the NOC monkey you call when things get wonky....
Valdis.Kletnieks@vt.edu wrote: [snip] Hi Vladis!
Actually, it *is* relevant for the "rest of us".
Given the number of boxen that got whacked, and the number of sites involved, "the defender" *is* "the rest of us", and "we as an industry" obviously need to get our collective act in gear. Remember -
Which is exactly my point... People keep worrying about 0days, when I'd only start worrying about them once I made sure that current (old) and known vulns can't get me. Once they are inside, it doesn't matter how they got in until a later time when you do forensics and try to make sure it doesn't happen again, which is what I referred to as the defender side. Fact is, the break in was serious because serious data was stolen.. so why should the fact it was an old vuln distract us from that except for perhaps reintroduce the facts that people simply don't do enough security and/or best practices, which we already knew?
*Your* boxes may be hardened beyond all belief and plausibility, but you're *STILL* screwed if some teenaged kid on another continent has more effective control of the router at the other end of your OC-48 than the NOC monkey you call when things get wonky....
Well, I suppose it's not really a great idea to wait until things get wonky to establish good and operational relations with your uplink. Gadi.
On Wed, 11 May 2005 16:59:56 +0400, Gadi Evron said:
Well, I suppose it's not really a great idea to wait until things get wonky to establish good and operational relations with your uplink.
Fortunately for me, we've got such good operational relations with our primary uplink that I don't even have to go outside to get to their NOC. ;) The problem is that for most sites, "good operational relations with the uplink" isn't 100% congruent to "uplink has their security act together". As a result, you get to have the "Hello, Uplink? You guys get hacked?" "Umm.. yeah" phone call...
*Your* boxes may be hardened beyond all belief and plausibility, but you're *STILL* screwed if some teenaged kid on another continent has more effective control of the router at the other end of your OC-48 than the NOC monkey you call when things get wonky.... It is mostly fantasy. DNS security is much much more important and much more real issue, vs this fictions. If talking about Cisco, we have much more worries about chained bugs, vs teens controlled OC-48 routers...
I mean - it is _real_, but it is far behind _much more realistic_ problems.
Alexei Roudnev wrote:
*Your* boxes may be hardened beyond all belief and plausibility, but
you're
*STILL* screwed if some teenaged kid on another continent has more
effective
control of the router at the other end of your OC-48 than the NOC monkey
you
call when things get wonky....
It is mostly fantasy. DNS security is much much more important and much more real issue, vs this fictions. If talking about Cisco, we have much more worries about chained bugs, vs teens controlled OC-48 routers...
I mean - it is _real_, but it is far behind _much more realistic_ problems.
You should listen to Vladis, he knows what he is talking about. There have always and will always (sigh) be bugs. However, as people keep saying... guns don't kill people, people kill people.
On Thu, 12 May 2005 01:30:36 PDT, Alexei Roudnev said:
It is mostly fantasy. DNS security is much much more important and much more real issue, vs this fictions.
Very true, but.... Sites that have their routers tied down right tend to get the DNS right too, and sites that are lax with the routers tend towards botching the DNS too. Remember - the single *biggest* chunk is that the people in charge have to make a conscious decision that "tying stuff down tight is important". Once that happens, routers and DNS and customer-tracking all usually fall into place. And if they haven't decided that a large bucket full of security-kloo is needed, you *WILL* end up calling them and saying "Did your XYZ get hacked?". Which piece of gear is XYZ this week is mostly random chance and the phase of the moon.... (For a *LONG* time, the single *biggest* easy-to-check predictor of "is this machine a spam source?" wasn't the various RBLSs, but whether they had a PTR for the IP. The same sort of sites that can't/don't get their PTRs in order (even to the point of a generic 'a.b.c.d.in-addr.arpa PTR d.c.b.a.ISP.net') are the same sort that can't check a new customer against ROKSO or find and neutralize a spam-zombie PC.
Alexei Roudnev wrote:
O, my god. Primitive hack, primitive ssh exploit.... I watched it all 6 years ago, bnothing changed since this.
It is _minor_ incident, in reality.
Primitive I can understand, but _minor_?
First, I don't really see why an attack should be estimated by the tool used. If a 10 years old exploit would work, why should an attacker look for and use a 0day? It's silly allocation of resources. I agree. But I saw, how hackers intruded into XXX agency (USA's, I mean) 6 years ago. Cisco sources never was a great secret (a lot of people saw them; they are almost useless without Cisco's infrastructure; they are interesting for competitors in some cases, because of very interesting technical ideas, but not for the hackers). It is _MINOR_ in reality. Major can be, for example, stealing 100,000 credit card numbers, because it make sence for 100, 000 people. Just Cisco sources... hmm, 100 total people in the world will be affected, big deal...)
But I agree - it just showed old truth - good security is not technical issue. Just simplerst _never use standard ports_ policy could prevent this case. Better, _use One Time Passwords and single point signature_. Primitive host based IDS (Osiris, for example). Any _real_ security policy, of course (or better, ACCESS policy, because security is nothing - ACCESS mater! No access required - no security issues...) It is amazing. Cisco made a lot of noice about IDS, IPS, etc etc.... while no one in reality need these super expansive and complex tools (except few dozens of companies under the DDOS risk); but missed so simple thing as ssh exploit in their own nest. (It is not harmless - we found ssh trojan on my previous job, just exactly the same case - ssh opened to Internet, port #22! Since this, I never allow ssh on port 22, Terminal Service on port 3389, managemen t web on port 80 or 443, and so on... /even when servcie is allowed, which is policy issue/...
Burrowing from that, if the attack is successful, and the loss is significant, I think the way there - although cute, is irrelevant except
I mean _MINOR_ because lost was minor, in reality. No because it was ssh exploit.
for the defender.
Gadi.
I agree. But I saw, how hackers intruded into XXX agency (USA's, I mean) 6 years ago. Cisco sources never was a great secret
Then you shouldn't be talking about it.
(a lot of people saw them; they are almost useless without Cisco's infrastructure; they are interesting for competitors in some cases, because of very interesting technical ideas, but not for the hackers). It is _MINOR_ in reality. Major can be, for example, stealing 100,000 credit card numbers, because it make sence for 100, 000 people. Just Cisco sources... hmm, 100 total people in the world will be affected, big deal...)
Okay, so if it is a Good Thing for competitors and a Bad Thing for Cisco which is a commercial company with a vested interest in not giving away their secrets to competitors, how is this not a major loss? _EVEN_ if only in reputation? Sorry, but I really don't understand why you keep trying to under-play this from different angles, and am just trying to understand your meaning.
But I agree - it just showed old truth - good security is not technical issue. Just simplerst _never use standard ports_ policy could prevent this case. Better, _use One Time Passwords and single point signature_. Primitive host based IDS (Osiris, for example). Any _real_ security policy, of course (or better, ACCESS policy, because security is nothing - ACCESS mater! No access required - no security issues...)
It's not a technical issue, yet you just told me how to do security in detail.
It is amazing. Cisco made a lot of noice about IDS, IPS, etc etc.... while no one in reality need these super expansive and complex tools (except few dozens of companies under the DDOS risk); but
IDS.. IPS.. etc.. etc... DDoS risk? I can agree with many on the complete uselessness of IDS for most companies (I can't live without it!).. IPS systems are a different matter.
missed so simple thing as ssh exploit in their own nest. (It is not harmless - we found ssh trojan on my previous job, just exactly the same
Let me Google you and find where you worked. :o)
case - ssh opened to Internet, port #22! Since this, I never allow ssh on port 22, Terminal Service on port 3389, managemen t web on port 80 or 443, and so on... /even when servcie is allowed, which is policy issue/...
And I'll port-scan you to find out what port you are running SSH on, as it is open to the net.
Burrowing from that, if the attack is successful, and the loss is significant, I think the way there - although cute, is irrelevant except
I mean _MINOR_ because lost was minor, in reality. No because it was ssh exploit.
Okay, I still don't follow you. I don't mean to be annoying but I really don't. Let's not move too much into the realm of security and stay in net ops. How is this not a loss and not a risk? If we can't reach an agreement I suggest we take this off-list. Gadi.
I agree. But I saw, how hackers intruded into XXX agency (USA's, I mean) 6 years ago. Cisco sources never was a great secret
Then you shouldn't be talking about it.
I mean - such things was common even 6 years ago. There was (always) some level of rooted servers, some level of teen hackers, some level of compromised passwords. Absolutely nothing new. If you (like Cisco) have a wide cooperation, are big, and decided (reasonably) do not sacrify in productivity because of paranoiic security - you have some risk of be intruded. It just means _use simple, sometimes primitive, but effective measures for additional protection_. Host based IDS-es on ALL (ALL) servers, single time passwords for everything, non standard ports - at least one of such list (teher are much more on the list).
Okay, so if it is a Good Thing for competitors and a Bad Thing for Cisco which is a commercial company with a vested interest in not giving away their secrets to competitors, how is this not a major loss? _EVEN_ if only in reputation? No, exclude reputation from my list - I did not estimated it. 100% agree about reputation. But cisco's reputation is not major thing for anyone outside of Cisco.
I underplay it because it is overplayed by the media. If (IF!) cisco code had not backdoors from developers (and I believe, it had not), then this particular event is major for Cisco, but minor for the rest of the world (even for competitors). You can not do much with this code, except if you are Cisco or are contrafacting Cisco's as a clone - it (as any such code) require the whole infrastructure around to be used. (It's as egg cell - we need a whole women around to get use of it).
It is amazing. Cisco made a lot of noice about IDS, IPS, etc etc.... while no one in reality need these super expansive and complex tools (except few dozens of companies under the DDOS risk); but
IDS.. IPS.. etc.. etc... DDoS risk?
I can agree with many on the complete uselessness of IDS for most companies (I can't live without it!).. IPS systems are a different matter.
missed so simple thing as ssh exploit in their own nest. (It is not harmless - we found ssh trojan on my previous job, just exactly the same
Let me Google you and find where you worked. :o) Ok, but we do few simpler measures (sometimes on 0 cost) which dramatically decrease a chance of intrusions, and other measures to prevent any chance of intrusion into important areas. And we do not forget to patch 'ssh' and 'ssl' (after all -:)).
IDS and IPS are good, if you have it on _EVERYTHING_ (which means, btw, that they can not be very expensive because you will never be able to use expensive tool on _everything_) and, most important, main IDS and IPS have brand names _cluefull admin and cluefull manager_. But we got aside. My point for this forum was _do not overestimate real harm from this Cisco sources leak_. It is almost harmless (except for repuation) vs consumer data leaks, consumer password's leaks, consumer OS exploits, medical data leaks and so on. If someone get control on ISP xxx routers - trust me, it will happen because he found admin passwords and because clueless admin allowed in-band access from Internet, or because NOC's server was compromised - but not because someone had Cisco sources.
Burrowing from that, if the attack is successful, and the loss is significant, I think the way there - although cute, is irrelevant except
I mean _MINOR_ because lost was minor, in reality. No because it was ssh exploit.
Okay, I still don't follow you. I don't mean to be annoying but I really don't. Let's not move too much into the realm of security and stay in net ops.
How is this not a loss and not a risk? If we can't reach an agreement I suggest we take this off-list.
Because it is useless for hackers, except if Cisco have a backdoors and embedded trojans. And (most important) because it distract NOC's and security guys from securing NOC's, access pathes to the routers, use changable passwords and so on. Simple question - do you control all changes on your routers and firewalls? I mean - something like CCR system (which sends daily change reports) or Cisco Works (as I know, do the same)? How often do you change enable passwords? Is it enough for intruder to set up sniffer in the NOC, steal password, then loging and change config (and be unnoticed)?
Gadi.
participants (5)
-
Alexei Roudnev -
Gadi Evron -
Gadi Evron -
Sean Donelan -
Valdis.Kletnieks＠vt.edu