Slashdot Mirror


Word Vulnerability Compromised US State Dept.

hf256 writes "Apparently hackers using an undisclosed (at the time) vulnerability compromised the State Departments network using a Word document sent as an email attachment. Investigators found multiple instances of infection, informed Microsoft, then had to sever internet connectivity to avoid leaking too much data!"

4 of 207 comments (clear)

  1. Re:Microsoft Logic by neil.orourke · · Score: 3, Informative

    It doesn't necessarily mean that there are more security holes. Remember the Win2K patch that killed Compaq desktops with a particular network card?

  2. How the **** is this insightfull? by Mr+44 · · Score: 3, Informative
    Wheres the -1, Misinformed?

    That's where "sane" operating systems differ. User space and the OS are heavily separated, in fact, user space for each user is separated from other users, and almost all services run as a unique user. This intentional separation provides very robust security, and is absolutely necessary to creating a secure system.

    Are you implying that is not the case with windows??? A quick look in task manager shows some system processes running as your user account, some as "LOCAL SERVICE", some as "NETWORK SERVICE", (both restricted accounts) and some as "SYSTEM" (=root). And a quick look at top on my linux box sure doesn't show "almost all" services running as unique users.

    And sure, its up to the administrator to configure it so the user account is not an administrator, but I've never seen a government system where a domain user account has local admin rights.

    In the specific case of this vulnerability, the word document was able to run arbitrary executable code as the current user. This presumably allowed access to network shares, and then sending the data back out (via HTTP most likely). That sort of thing would be possible with any operating system.

    The only area you are correct in is that on linux the flaw could be patched quicker... But in a large organization, it likely could still be preferable to block the exploit with IDS/firewall rules than by rolling out a client patch...
  3. Re:Scary by ArsenneLupin · · Score: 4, Informative

    The crux of the problem here is that MS Word needs or provides Internet access for some of it's functions. Even if it had any buffer overflows, the problem would not be exploitable from remote systems. Although Word does probably provide Internet access to its macros and other nasties, this was not a necessary condition for this to work. Even if MS Word didn't have any code within to connect to the internet, any supposed exploit would have been able to supply its own. And from the looks of it, this is what happen here. Apparently, this was some kind of call-back program that would somehow tunnel out through the firewall, connect to the hacker's control console and accept instructions from there.

    Such a thing is rather complex, and probably not pre-existing within word. It was brought in by the trojan itself.

  4. Re:Scary by ArsenneLupin · · Score: 2, Informative

    Excuse me... how would such a call-back program be initiated, "Shell code". Typically, a buffer overflow causes some user data (contained in Word document) to overwrite the stack, including the return address. The function in Word where this happened would thus not "return" to its intended spot (the caller), but rather to some other place in memory. This would be chosen by the attacker in such a way as to point to some place within the document. The document would contain machine-language code for the rest of the program (presumably, it would drop an exe somewhere, and register it as a service or an autorun application).

    The trick of course is to hide the code in such a way that it doesn't appear as gibberish in Word. But that could be achieved by hiding it inside unused data of a picture or whatever.

    and how would it perform the desired function Once Word has been tricked to execute the attacker's code, that code can basically do anything it likes, as it can now directly talk to the OS, without going through whatever functionality Word provides.

    Does it not mean that Word has the provision / bug of being able to initiate external programs that can perform actions at a higher privilege Until very recently (Vista), opening network sockets didn't require any particular privileges. Word would have those privileges, even if it did not use them itself.

    Is that not a serious architectural bug in Word AND IN Windows as well? Nope, only in Word. Before Vista, all programs could connect to the network.

    I think 'the trojan' is a weak and misleading description for this program. It is an exploit for a hole in the operating system... nothing less. Nope. It's only an exploit in the application (Word). The OS at that time (spring last year) was not yet supposed to block this kind of actions.

    Frankly, I wonder how you can speculate with any accuracy regarding this problem, since the article is extremely short on meaningful data regarding the bug exploit. Learn to read between the lines ;-)
    • Although they were aware of the program's existence (and presumably did some reverse engineering on it), they were "surprised" when they saw that the program was indeed shipping sensitive documents outside ===> this implies to me that the whole behavior was not coded within the program itself. Instead, it must have been set up in a way to take commands from an outside source (on which communication they presumably eavesdropped, having reverse-engineered the trojan)
    • It's common sense that the state department is protected by some firewall ===> but once you've got some agent inside (i.e. that trojaned Word doc), it's relatively trivial to tunnel through any firewall (for instance just connect back to a Web server hosted by you, and use that to take commands / report back status). Depending on the specifics of the firewall, other methods may exist (tunneling via DNS, ICMP ping packets, IRC, MSN, etc.)
    • Microsoft addressed this as some kind of "new" vulnerability ===> which pretty much excludes macros, which (in Microsoft's mindset...) are not a vulnerability, but "by design". The most likely candidate would be a buffer overflow.