Slashdot Mirror


More on Last Year's Cisco Source Code Theft

grazzy writes "The New York Times has a story about last year's theft of Cisco source code: 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. "

7 of 266 comments (clear)

  1. Question for an expert... by wcitech · · Score: 5, Interesting

    I'm without a doubt no networking expert, so I'd like to ask one of you who is: if the source code for cisco's equipment is leaked, would that person have the ability to create some kind of virus/malware that could bring the internet to a screaching halt? What can they do, infect routers with viruses now? I guess I'm unclear on the real dangers in a situation like this.

  2. Timing.. by gmerideth · · Score: 5, Interesting

    Rather good timing that last night on "24" we see Cisco's name all over the screen's at the CTU command center and the actress works in the line "the Cisco network is defending itself" followed immediately by an Alienware laptop on the screen.

    Just in time for major articles about how bad Cisco's security was that they had some source code stolen. /golfclap foxtv

    And people wonder why I don't watch television. Sad..just sad.

    --
    Why do overlook and oversee mean opposite things?
  3. Thef by Doc+Ruby · · Score: 4, Interesting

    What do Slashdot "authors" (editors) do all day? They publish about 35 stories in a 24 hour cycle, usually about 4 editors participating. That's about 1-2 stories an hour, with 1-2 authors overlapping shifts. The summaries take about 2 minutes max to read, and the stories take max 5-10 minutes. That seems ample time to catch dups, fix typos, spelling and punctuation errors. Why not? What else are they doing? Maybe they don't read Slashdot after they've published, so they don't see all the feedback on their poor editing performance.

    --

    --
    make install -not war

    1. Re:Thef by Doc+Ruby · · Score: 4, Interesting
      Moderation 0
      50% Interesting
      20% Troll
      20% Redundant

      Where's another post running a time analysis of Slashdot editing? Even given Slashdot's absence of features to prevent comment redundancy, isn't a chorus of "not again!" appropriate? And how is my coherent, accurate comment, which I haven't seen before, a "Troll"?

      Perhaps this comment is just the criticism uberpost, destined to point out all the serious flaws in Slashdot's publishing system model. If so, here's some constructive suggestions for fixing it:

      1. Submitted story queue filter: editors see a story, with links listed separately (already a Slashcode function). Links already published in a previous story are indicated, linked to the previously published story. Publishing such links includes an "ongoing coverage" indication in the new published story.

      2. Submission spell/grammar checker

      3. Submission link checker: links in stories in submission queue are interlinked through a Slashdot redirection script which sets a flag. Until each link's flag has been set, by following the link (through the script) to the linked object, the story cannot be published.

      4. Mod comments: Negative moderation must be accompanied by an explanatory comment, which can be viewed by metamoderators. Metamoderation gets more "teeth", with 3 "unfair" metamods cutting modpoints for a month, and 3 such suspensions cutting modpoints forever.
      --

      --
      make install -not war

  4. This is actually kinda funny by Jetifi · · Score: 4, Interesting

    I mean, 'cybersecurity' bigheads are all worried about Terrorists disabling our Internet Infostructure etc., but in real life it turns out that any vulnerabilities that could be used to break into (e.g.) the JPL, White Sands, the DoD etc. have already been exploited by petulant teenagers.

    So in this sense, the script kiddies of the Internet are kinda like an early warning system: it's almost certain that before someone with serious intentions finds a nasty flaw and uses it, it'll be discovered by some kid who will promptly boast about it on IRC.

    How lucky we are that terrorists find themselves vastly outnumbered by people with too much free time on their hands!

  5. We got hit. by glockenspieler · · Score: 4, Interesting

    My laboratory was hit. We're all linux machines. Turns out that I still had an account on a system at Stanford where I was faculty and I transferred some files via scp to my machine at my current university. 4-5 days later, i see some logins from Stanford to my machine but I because I had been using the Stanford account recently, it just didn't register.

    One day later, I'm on another lab machine using my lab /home directory (different from my main machine) and i notice a program (it was either brk.c or dobrk.c I think) that was on an unpatched system, allowed a priviledge escalation. I switch to root and look at the history and see a command to stop recording the command history but he (and the article indicates the person is male) misstypied it so i could see that he logged into this machine from mine, grabbed the source code for the exploit from a warez site, compiled, ran, got root, and just tooled around a little.

    Because our machines are pretty isolated and don't have any hint of financial stuff, he seemed to just drop it. I called the sysadmin at Stanford, turned out that on a machine with over 500 accounts (i won't say which department), the machine had been rooted about 2 months prior and every password was being captured during that time. The breakin was tracked back through a couple of departments, then back to University of Michigan, then to Uppsala.

    Three valuable and perhaps obvious lessons here. Local priviledge escalation exploits are important even if your system has very few users. Keep your system patched (duh...), and remember, if you log onto your machine from another, ask yourself "What do I know about the integrity of this machine?". I really assumed that my stanford account was pretty secure and so I didn't even think about logging from that machine to my current one. No more.

    The other interesting thing was that the local exploit used on my machines was announced well after the Stanford machine was hit. I don't think I ever heard of how that machine was comprimised.

  6. Re:Doesn't make sense by rcw-home · · Score: 4, Interesting
    Cisco uses two factor one time passwords for remote access. I don't see how planting a trojaned copy of SSH on the lab computers would give the hacker access to Cisco's systems.

    I don't know how Cisco has their stuff set up, but it's easy to imagine such a breach playing out:

    1. Black hat replaces ssh client at University lab computer.
    2. Authorized but unwitting user uses University computer to VPN into Cisco's network and then uses the trojaned ssh client to connect to a computer on Cisco's network.
    3. The trojaned ssh client is now able to execute arbitrary code as the unwitting user on an internal Cisco computer. It uploads an executable to the internal Cisco computer that regularly makes outgoing TCP connections (they could even look like web browser traffic) to a computer under the black hat's control. The black hat sends control commands through these connections which the executable gladly obeys.
    4. The black hat is now free to scan the internal network to look for a host they can get root on, or hope that the user's account on the internal server they control will be used to connect to other internal systems, perhaps using more highly privileged accounts. (Any admins ever had to sit down at a users' computer and ssh into a server to fix something?) The longer the initial breakin is left unidentified, the better the chances of this occurring.
    5. Eventually the black hat will strike paydirt and get root on a system. From then on, the rootkit that the black hat installs can use any credentials anyone uses to access any systems remotely. Ssh into something? It can run commands on the remote host. Connect to a file server? It can replace executables that you have write access to and wait for someone else to run them.

    While an attacker would need a fairly deep understanding of the software infrastructure he is attacking and of the usage habits of the users there to pull this off, the same basic strategy is applicable to UNIX, Windows, anything. I remember reading several years ago that the breakins at Exodus and VA Linux happened this way.

    We're only used to the stuff we hear about not doing any real damage, because it's all dumb worms running without anyone at the controls. Just because we can fend off that stuff doesn't mean that someone with determination, knowledge, and patience won't get in and stay in.