http://isc.sans.org en-us Sat, 04 Jul 2009 06:22:02 +0000 Fri, 03 Jul 2009 21:26:39 GMT (C) SANS Institute 2009 isc rss feed maker 30 handlers@sans.org (ISC Handlers) http://isc.sans.org/images/status.gif http://isc.sans.org http://isc.sans.org/diary.php?storyid=6721&rss http://isc.sans.org/diary.php?storyid=6721&rss Update: Authorize.net appear to be at least partially back up and running.


Cheers,

Adrien de Beaupr

EWA-Canada.com
Teaching SANS Cutting-Edge Hacking Techniques in Ottawa this September.
]]> Fri, 03 Jul 2009 21:26:39 GMT http://isc.sans.org/diary.php?storyid=6727&rss http://isc.sans.org/diary.php?storyid=6727&rss

Cheers,

Adrien de Beaupr

EWA-Canada.com
Teaching SANS Cutting-Edge Hacking Techniques in Ottawa this September.
]]> Fri, 03 Jul 2009 18:47:18 GMT http://isc.sans.org/diary.php?storyid=6724&rss http://isc.sans.org/diary.php?storyid=6724&rss

Cheers,

Adrien de Beaupr

EWA-Canada.com
Teaching SANS Cutting-Edge Hacking Techniques in Ottawa this September.
]]> Fri, 03 Jul 2009 17:25:35 GMT http://isc.sans.org/diary.php?storyid=6718&rss http://isc.sans.org/diary.php?storyid=6718&rss

Cheers,

Adrien de Beaupr

EWA-Canada.com
Teaching SANS Cutting-Edge Hacking Techniques in Ottawa this September.
]]> Fri, 03 Jul 2009 16:50:12 GMT http://isc.sans.org/diary.php?storyid=6715&rss http://isc.sans.org/diary.php?storyid=6715&rss


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 seehttp://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

]]> Fri, 03 Jul 2009 09:35:14 GMT http://isc.sans.org/diary.php?storyid=6712&rss http://isc.sans.org/diary.php?storyid=6712&rss 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.]]> Thu, 02 Jul 2009 10:08:35 GMT http://isc.sans.org/diary.php?storyid=6703&rss http://isc.sans.org/diary.php?storyid=6703&rss
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.
]]> Thu, 02 Jul 2009 02:44:50 GMT http://isc.sans.org/diary.php?storyid=6709&rss http://isc.sans.org/diary.php?storyid=6709&rss All the podcasts


Podcast through iTunes
-- Joel Esler | http://www.joelesler.net | http://twitter.com/joelesler]]> Thu, 02 Jul 2009 01:30:49 GMT