Cold Fusion web sites getting compromised
There have been a high number of Cold Fusion web sites being compromised in last 24 hours. We received several e-mails about this.
It appears that the attackers are exploiting web sites which have older installations of some Cold Fusion applications. These applications have vulnerable installations of FCKEditor, which is a very popular HTML text editor, or CKFinder, which is an Ajax file manager. The vulnerable installations allow the attackers to upload ASP or Cold Fusion shells which further allow them to take complete control over the server.
The attacks we've been seeing in the wild end up with inserted <script> tags into documents on compromised web sites. As you can probably guess by now, the script tags point to a whole chain of web sites which ultimately serve malware and try to exploit vulnerabilities on clients.
What's interesting is that the group behind this is probably connected (if not the same) as the group that performed a lot of similar attacks back in March. I wrote several diaries about them – see http://isc.sans.org/diary.html?storyid=6001 and http://isc.sans.org/diary.html?storyid=6010
Back in March, once they gained access to the server, they used a local privilege escalation exploit for a vulnerability that was, at that time, unpatched. If your servers are up to date with Microsoft patches, the vulnerability has been patched but they still can modify local web site files in a lot of cases (and sometimes even more, depending on Cold Fusion's configuration).
We'll be carefully monitoring the situation with this, of course. In the mean time, make sure that all applications you are running are up to date and fully patched. Another thing you might want to do is check for any old software you might have on your servers – it is very common for applications to leave old, vulnerable parts that are not used any more hanging around. And such applications are just waiting to be compromised.
Thanks to Adam for giving us an early heads up.
UPDATE
We received some additional information about this whole case with ColdFusion. It appears that there are two attack vectors (both using vulnerable FCKEditor installations though) that the attackers are exploiting.
First, version 8.0.1 of Cold Fusion installs a vulnerable version of FCKEditor which is enabled by default. This is very bad news, of course, since the attacker can just directly exploit FCKEditor to upload arbitrary files on affected servers. Information on how to disable this is available on the ColdFusion web site at http://www.codfusion.com/blog/post.cfm/cf8-and-fckeditor-security-threat
The second attack vector is again through vulnerable FCKEditor installations, but which are this time dropped through 3rd party application. One of the common applications that has been seen in attacks is CFWebstore, a popular e-commerce application for ColdFusion. Older versions of CFWebstore used vulnerable FCKEditor installations -- if you are using CFWebstore make sure that you are running the latest version and that any leftovers have been removed.
--
Bojan
Unpatched Bloatware on new PCs
I recently purchased a netbook, and while I like the highly portable on-the-go computing that it offers very much, booting it up for the first time was frustrating. The box took its sweet time to install a big pile of bloatware, ranging from Acer's own useless tool suite over trial versions of McAfee Internet Security and MS Office 2007 "Home Edition" all the way to the common culprits like Google Desktop & co. Software I didn't want, had never wanted, and knew full well I would have to tediously uninstall again as soon as the device finished booting. And indeed, the first start up not even fully complete, the nag screens began to appear, begging for attention and money.
Undesired pre-installed software would be annoying enough all by itself. But all this software can (will!) also contain vulnerabilities that require patching in future. As stated in my earlier post today, patching of PC applications is an unsolved problem. By forcing unwanted trialware onto customers, the hardware vendors are contributing to making the patching problem worse.
A secure and bloat-free configuration out of the box would be highly appreciated. We already have enough to worry about keeping a PC secure and up to date during its lifespan, without hardware manufacturers stacking the odds against us even further.
What do you do with the undesired software pre-installed on new PCs? Let us know in the poll on this page.
Getting the EXE out of the RTF
Recently, when the targeted attack with malicious RTF attachments was making the rounds, I wondered how to best get the embedded EXE extracted from the RTF for further analysis. On a Windows system, you would most likely simply copy/paste the embedded object from within RTF to an Explorer window, and end up with the original file. Since I do my malware analysis on Unix, this wasn't an option. Looking at the file, it appeared as if RTF was using some sort of hexadecimal encoding:
Now, as a command line Perl addict, hex is something I know how to deal with :-).
$cat detail.rtf | sed -e '1,3d' | perl -ne 's/(..)/print chr(hex($1))/ge' > detail.bin
$cat detail.bin | hexdump -C | more
00000000 02 00 00 00 08 00 00 00 50 61 63 6b 61 67 65 00 |........Package.|
00000010 00 00 00 00 00 00 00 00 1c e4 00 00 02 00 4d 69 |.........ä....Mi|
00000020 63 72 6f 73 6f 66 74 20 57 6f 72 64 20 20 45 6e |crosoft Word En|
00000030 64 4e 6f 74 65 20 78 32 20 65 72 72 6f 72 2e 20 |dNote x2 error. |
00000040 50 6c 65 61 73 65 20 64 6f 75 62 6c 65 20 63 6c |Please double cl|
00000050 69 63 6b 20 68 65 72 65 20 74 6f 20 76 69 65 77 |ick here to view|
00000060 20 74 68 65 20 6f 72 69 67 69 6e 61 6c 20 63 6f | the original co|
00000070 6e 74 65 6e 74 2e 73 63 72 00 43 3a 5c 55 73 65 |ntent.scr.C:Use|
Sweet, we get something printable! The “sed” command deletes the first three lines, because they don't contain hex and would confuse the Perl statement that follows. The Perl code eats up two digits at once and converts them to the corresponding ASCII character, iterating through the entire file. I'm using “perl -ne” combined with “print” instead of “perl -pe” because the former makes it easier to ignore the pesky CR/LF line end markers that make Windows text so annoying on Unix. The output gets piped into “hexdump -C”, because we expect this content to be an embedded EXE file, and thus it likely contains a lot of non-printable characters that would not be fun to look at in “vi” or “more”.
A bit further down in the output, there was indeed the tell tale “MZ” marker of the beginning of a MSDOS PE header.
00000170 6c 20 63 6f 6e 74 65 6e 74 2e 73 63 72 00 00 e0 |l content.scr..à|
00000180 00 00 4d 5a 50 00 02 00 00 00 04 00 0f 00 ff ff |..MZP.........ÿÿ|
00000190 00 00 b8 00 00 00 00 00 00 00 40 00 1a 00 00 00 |..¸.......@.....|
000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
Easy, I thought. Let's carve out the file beginning with the MZ and we should have the EXE:
$ dd if=detail.bin of=detail.exe bs=1 skip=386
61870+0 records in
61870+0 records out
61870 bytes (62 kB) copied, 0.269451 s, 230 kB/s
$ file detail.exe
detail.exe: PE32 executable for MS Windows (GUI) Intel 80386 32-bit
“if” and “of” are the input and output files of the “dd” command. “bs=1” sets the step size to one byte, and “skip”, well, skips the given number of bytes at the beginning of the file. 386 is the decimal equivalent of 0x182, the offset of MZ visible in the hexdump above.
While the “file” command confirmed that I had indeed carved out an executable, something was wrong – the file didn't want to run in the emulator, and when I uploaded it to threatexpert.com, their service called it “invalid”. I quickly figured out that the RTF has a lot of crud at the end as well, which also needs to be cut off, but I still couldn't reliably determine the correct length, and hence didn't know where the last byte of the embedded executable was.
Well, time for the malware reverse engineering equivalent of the “known plaintext attack”. I used a Windows PC to embed a copy of notepad.exe into an otherwise empty RTF document of my own, and then went about analyzing this RTF until I was able to carve out the original notepad.exe. The main “AHA!” moment was when I realized that the bytes between the filename and the “MZ” header actually are the length of the embedded file. If we use our hexdump from before
00000170 6c 20 63 6f 6e 74 65 6e 74 2e 73 63 72 00 00 e0 |l content.scr..à|
00000180 00 00 4d 5a 50 00 02 00 00 00 04 00 0f 00 ff ff |..MZP.........ÿÿ|
00000190 00 00 b8 00 00 00 00 00 00 00 40 00 1a 00 00 00 |..¸.......@.....|
000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
the length of the file in this case is 0x00E000, which is 57344 in decimal. Back to the sample:
$ dd if=detail.exe of=detail-fixed.exe bs=1 count=57344
57344+0 records in
57344+0 records out
57344 bytes (57 kB) copied, 0.268809 s, 213 kB/s
$ file detail-fixed.exe
detail-fixed.exe: PE32 executable for MS Windows (GUI) Intel 80386 32-bit
$ md5sum detail-fixed.exe
82a44254c1ce2019936a8428c93f5354 detail-fixed.exe
This time, the emulator, ThreatExpert and VirusTotal were all happy with the file, and while anti-virus coverage at the time was poor, the EXE/SCR embedded within the RTF attachment was quickly confirmed as unfriendly.
Internet Storm Center Podcast Episode Number Fifteen
Hey everyone, sorry it has taken so long to get around to recording another podcast episode! The audio should be a bit better on this podcast, and we are going to try and get these out more often now. Enjoy!
-- Joel Esler | http://www.joelesler.net | http://twitter.com/joelesler
Time to update updating on PCs for 3rd party apps
As Alan Paller wrote in last week's SANS @Risk Newsletter, home PCs contain a lot of software with a lot of vulnerabilities. The recent Shockwave hole is only one example. Yes, there are tools, like Secunia's PSI, that can help in determining which software on a PC needs urgent patching. In my experience though, the average home user is not tech savvy enough to use such tools.
Some software packages try to fix the problem by building an "auto update" feature into their product. Looking more closely into how these update mechanisms work shows that many do not verify or authenticate the updates received. If recent malware like Conficker protects its updates better than application software protects its auto-downloads, something's amiss.
Even assuming that a software package does everything right, there's still the hurdle of the OS to overcome. How do you explain to your mom or uncle or grampa the difference between a "bad" UAC prompt in Windows Vista (eg. when malware wants to sneak in) and a "good" UAC prompt (eg. when Firefox wants to apply its important security update) ?
Basically, a message box telling a user that a program needs updating doesn't work anymore. We've seen just too many pop-ups, too many annyoing requests to install Chrome or Silverlight or - worse - SuperMegaAntivirus2009, and this has left the users largely immune to anything that requests installation. The more glaringly something asks for attention, the higher the chance it will be ignored.
Microsoft has come a long way with Windows Update. Of course we still worry about the PCs of our family members whenever there's a new vulnerability, but once the patch is out, we know we can stop worrying: Windows Update works well enough that on all PCs of friends and family that I was recently pressed into duty to "check out", the Windows patches were actually current.
Now .. how do we get to the same level with all the application programs ?
Comments