Microsoft August 2006 Patches: STATUS
Overview of the known problems and publicly known exploits ofthe August 2006 Microsoft patches.
0 comment(s)
| # | Known Problems with this patch |
Known Exploits |
client rating | server rating |
|---|---|---|---|---|
| MS06-040 | Issue with:
|
Botnets actively exploiting this in the WILD Exploit available in easy to use package
read more... |
PATCH NOW |
PATCH NOW |
| MS06-041 | No reported problems |
Critical | Critical | |
| MS06-042 | Critical issue:
More info: Issue #1:
Issue #2:
|
Original MS06-42: fixes a.o. a FTP vulnerability that;s well-known since 2004 First revision of the MS06-042 patch's buffer overglow has details public.
|
PATCH NOW |
Important |
| MS06-043 | No reported problems | Important | Less urgent | |
| MS06-044 | No reported problems | Critical | Critical | |
| MS06-045 | No confirmed problems | Critical | Less urgent | |
| MS06-046 | No reported problems | Critical | Important | |
| MS06-047 | No reported problems | Trojan dropper reported in word document by Symantec, Trendmicro(1) and Trendmicro(2). The dropper loads a backdoor: Trendmicro, Symantec. See also diary. |
Critical | Less urgent |
| MS06-048 | No reported problems | Trojan dropper in Powerpoint | Critical | Less urgent |
| MS06-049 | Unconfirmed reports about corruption of files on compressed volumes. [Windows 2000 only patch] |
Important |
Less urgent | |
| MS06-050 | No reported problems | Critical | Important | |
| MS06-051 | Although unconfirmed by Microsoft so far, there seem to be problems related to Terminal Services and multiple users loading certain DLLs as part of some applications. Details and fixes or workarounds are too sketchy so far. See also the problem with .ini files and citrix at the citrix support forum. We're still lookign for a more detailed discription of the problems. |
Critical | Critical |
We will update issues on this page as they evolve.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
More on encoded malware
ISC reader Jan Monsch was sufficiently intrigued by today's diary entry on "Decoding Malware" that he started experimenting on his own. By the simple expedient of saving a Word document with an embedded "EICAR" file in different formats and running the resulting files through VirusTotal was he able to show that ... quite a number of AV programs seem to have BIG problems with decoding even the simplest text based file formats. As Jan correctly writes:
[Update 1656UTC: We've had two reports that testing with locally installed AV yielded different/better results than the ones reported by Virustotal for the same AV product]
[Update 2151UTC: The author and we are well aware that in order to _run_, the malware/eicar would have to be unpacked from the Word document, and that AV would likely catch it then. This isn't about virus detection on the endpoint, it's about evading detection by proxy and email gateway anti-virus filters on the way _to_ the endpoint.]
Apart from having lots of up-to-date virus patterns the quality of a virus scanner is to a large extent defined by the number of formats it is able to decode.
As it turns out, only two AV programs were able to spot the EICAR in all seven of the functionally equivalent MSWord formats. The full 15-page PDF with Jan's analysis can be found on http://www.iplosion.com/isc/alternativ_word_formats_v2.0.pdf , or rather, because this box seems to sit on the far end of a very slow connection, as a locally mirrored copy here on http://handlers.sans.org/dwesemann/alternativ_word_formats_v2.0.pdf[Update 1656UTC: We've had two reports that testing with locally installed AV yielded different/better results than the ones reported by Virustotal for the same AV product]
[Update 2151UTC: The author and we are well aware that in order to _run_, the malware/eicar would have to be unpacked from the Word document, and that AV would likely catch it then. This isn't about virus detection on the endpoint, it's about evading detection by proxy and email gateway anti-virus filters on the way _to_ the endpoint.]
Keywords:
0 comment(s)
Cisco Advisories
Seems Cisco VPN concentrators can be played with over FTP. Why anyone would want to allow FTP to their VPN concentrator escapes me though. See http://www.cisco.com/warp/public/707/cisco-sa-20060823-vpn3k.shtml
Another one you sure are also going to like is a Cisco advisory with a truly lovely title. They call it "Unintentional Password Modification Vulnerability in Cisco Firewall Products". I wonder if there is a vulnerability that allows intentional password modification. Or an unintentional feature that allows the same. But oh well: http://www.cisco.com/warp/public/707/cisco-sa-20060823-firewall.shtml has the details of an apparently rare glitch that can make PIXes and ASAs lose their EXEC password.
Another one you sure are also going to like is a Cisco advisory with a truly lovely title. They call it "Unintentional Password Modification Vulnerability in Cisco Firewall Products". I wonder if there is a vulnerability that allows intentional password modification. Or an unintentional feature that allows the same. But oh well: http://www.cisco.com/warp/public/707/cisco-sa-20060823-firewall.shtml has the details of an apparently rare glitch that can make PIXes and ASAs lose their EXEC password.
Keywords:
0 comment(s)
PHP Security Update
In response to yesterday's tip of the day on PHP security, a number of readers wrote in to point to the minutes of a PHP developer meeting, discussing upcoming changes in PHP 6. Now PHP 6 may seem far away. But you can't start early enough to think about how to make sure project work well with it.
From a first read, I am not quite happy with the security related changes. But the document is brief and may not explain all the details. So here a few of the security related highlights.
For the full document, see Minutes PHP Devlopers Meeting.
From a first read, I am not quite happy with the security related changes. But the document is brief and may not explain all the details. So here a few of the security related highlights.
- Dealing with Unicode. Not directly security related. But this could affect some validation functions. Overall there appears to be a global switch covering how to deal with unicode.
- register_globals is going to go away (Finally ;-) ). This option, which "way back" used to be the default, has been one of the big problems in the past.
- magic_quotes is going to go away. Not sure if I like this. 'magic_quotes' has been an issue for developers who had no control over the php configuration (e.g. shared hosting) and had to cover both cases (quotes on/off). But it has been a valuable safety net for others.
- safe_mode feature is going to be removed. Another questionable choice IMHO. The feature had problems in the past, but then again, I would rather see them fixed then have them go away.
- the SOAP extension will support more security options. But it will also be turned on by default.
- the "Hardened PHP patch" will be included (at least pieces of it. Nice!).
- looks like there will be no 'taint' mode, but there may be 'sandboxing'. The notes are a bit brief on this.
- No more '<%'. This could be an issue if your PHP code is using '<%' and will now no longer be parsed, but instead the source code will be visible.
For the full document, see Minutes PHP Devlopers Meeting.
Keywords:
0 comment(s)
Decoding malware
When ISC handler Bojan Zdrnja mentioned a "pretty interesting piece of malware" he had found, those of us who like to analyze and reverse-engineer such critters immediately jumped onto it.
The malware was talking to a handful of servers over HTTP to fetch additional content, and only by faking user agent headers to look exactly like the malware was setting them was Bojan able to retrieve the additional files. The files he got were "big strings" of ASCII character sequences which Bojan quickly figured out how to decode/translate from the Ceasarean substitution cipher into URLs. But when requesting one of these URLs, all he got was another messy big string, and one whose coding method was different:
FOEJIDBDBABDBDBDBHBDBDBDOMOMBDBDKLBDBDBDBDBDBDBDFDBDBDBDBDBDBDBDBDBDBDBDBDBDBDBD
BDBDBDBDBDBDBDBDBDBDBDBDBDBDBDBDBDBDBDBDNLBDBDBDBNAMKJBNBDKHBKNODCKLBCFPNODCEHHL
HKGADDGDGBHMHEGBHCHODDHAHCHNHNHMGHDDHBHGDDGBGGHNDDHKHNDDFHFMEADDHOHMHHHGDNBOBOBJ
DHBDBDBDBDBDBDBDBGMODBNBAMBABABEFOELELFDFGEKFHFCEKFFFNFBEKFFFAFCELACANBGBHBAEKBE
AMBEBDBDBDBDBDBDBDBDBDBDBDBDBDBDBDBDBDBDFCKPFPICBDBDBDBDBDBDBDBDBDBDBDBDBDBDBDBD
EDFGBDBDFPBCBABDKKGNNFFHBDBDBDBDBDBDBDBDPDBDBMBCBIBCBFBDBDJDBDBDBDADBDBDBDEDBCBD
[...]
KHBKNODCKLBCFPEHHLHKGADDGDGBGMOIOMOMHMHEGBHCHODDHAHCHNHNHMGHDDHBHGDDGBGGHNDDHKBB
FHFMEADDHOHMHCOMNCONHHHGDNBOBOBJDHFAGEPFNGHDCAJELICABANLCEMMOOFLIILECACBBEKDIILG
CACCMIILLCCACEJMCOOFMLLMBMHDLHKBBEHJLHKLBMCAJELJNCNFIFNOCAKMECILCLDEKOCECPKBOEKC
KNBEEBHKHAHLEEKIEDFGHMJEGOKIFPBCOGLDGNNFFHAAPDNODCBIBCAOKIBGKKBFBKLFADBHAAGJOEHP
OFKKMEBHADBAAABKADBMAOKBIIGOMKBEBDDDBGDEDJBBBDEKKBHGHMBBBEBFDNOPFCFFMIBAFMKHPOAD
BGBDHPBIAGKFBIIDHHFLBBANNBBNMIOPDNGHHGGLGHCLONIDBCILODHNONMMIIBDBHPDDNHHHCGHHCGL
KJBAOIOPAMNIIFBABDDANDEAHLHCGBHGHHIHIOPPKLDHCGCLMDBHDDDEKCNKPOPOODDNDGHPHMHAMILN
(broken up for readability here - the original was one single long line with no CR/LF)
At first, we were convinced that the long string we were looking at was just another collection of URLs. But all the pattern matching we could cook up did not turn up anything looking like an encoded URL. So it was time to try a different approach - statistical analysis. Counting characters and character sequences can frequently tell something about the code or cipher used.
Starting with how many different "single" characters were in the cipher:
daniel@debian:~$ cat bigstring.txt | perl -ne 's/\s//g; s/(.)/$seen{$1}++/eg; foreach $c (keys %seen) {print "$seen{$c} $c\n"}' | wc -l
16
Hmm. Sixteen different chars. Let's see how many different two-character sequences we have:
daniel@debian:~$ cat bigstring.txt | perl -ne 's/\s//g; s/(..)/$seen{$1}++/eg; foreach $c (keys %seen) {print "$seen{$c} $c\n"}' | wc -l
256
Well well, another power of two. This can't be coincidence :-)
daniel@debian:~$ cat bigstring.txt | perl -ne 's/\s//g; s/(....)/$seen{$1}++/eg; foreach $c (keys %seen) {print "$seen{$c} $c\n"}' | wc -l
13160
Four-character sequences, on the other hand, don't seem to be anything special, what with 13160 different ones in the file. So most likely what we are dealing with here is a code that translated two-byte hexadecimal chars into a different alphabet. Let's see the 16-char alphabet and related frequency:
daniel@debian:~$ cat bigstring.txt | perl -ne 's/\s//g; s/(.)/$seen{$1}++/eg; foreach $c (keys %seen) {print "$seen{$c} $c\n"}'
4077 A
3523 F
3415 J
3496 O
3380 N
4108 P
3361 K
6790 B
3332 E
4334 H
3338 M
4718 C
6530 D
3623 I
3730 G
3781 L
Hmm. The frequencies dont help anything, but these are the first 16 chars of the alphabet. Maybe someone was lazy and did a simple substitution of the 16 hex values into the first 16 chars of the alphabet - which would mean that an "A" is 0, a "B" is 1, etc until "P" which would equal 0xF - 15 in Hex. Trying this hypothesis on the file meant to convert the sixteen characters found in the file into their corresponding value. Done quick and dirty in PERL, this meant subtracting 65 from the ASCII code of each of the characters (65 is the ASCII code of "A" - consequently ascii(A)-65 equals 0, as desired):
daniel@debian:~$ cat bigstring.txt | perl -ne 's/(.)/printf "%x",ord($1)-65/ge' > stage1.txt
which had the resulting "stage1" file look something like this:
5e4983131013131317131313ecec1313ab1313131313131353131313131313131313131313131313
1313131313131313131313131313131313131313db1313131d0ca91d13a71ade32ab125fde32477b
7a603363617c7461727e3370727d7d7c673371763361667d337a7d33575c40337e7c77763d1e1e19
371313131313131316ce31d10c1010145e4b4b53564a57524a555d514a5550524b020d1617104a14
0c1413131313131313131313131313131313131352af5f8213131313131313131313131313131313
435613135f121013aa6dd5571313131313131313f3131c1218121513139313131303131313431213
[...]
These were still hex values. In order to translate them into the corresponding characters, another line of PERL-fu had to be applied:
$cat stage1.txt | perl -pe 's/(..)/chr(hex($1))/ge' > stage2.bin
This line takes the hex codes from the "stage1" file and converts them into one-byte characters.
Taking a look at the resulting "stage2.bin" file with a hex-dumper, we got:
daniel@debian:~$ hexdump -C stage2.bin | more
00000000 5e 49 83 13 10 13 13 13 17 13 13 13 ec ec 13 13 |^I..........ìì..|
00000010 ab 13 13 13 13 13 13 13 53 13 13 13 13 13 13 13 |«.......S.......|
00000020 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 |................|
00000030 13 13 13 13 13 13 13 13 13 13 13 13 db 13 13 13 |............Û...|
00000040 1d 0c a9 1d 13 a7 1a de 32 ab 12 5f de 32 47 7b |..©..§.Þ2«._Þ2G{|
00000050 7a 60 33 63 61 7c 74 61 72 7e 33 70 72 7d 7d 7c |z`3ca|tar~3pr}}||
00000060 67 33 71 76 33 61 66 7d 33 7a 7d 33 57 5c 40 33 |g3qv3af}3z}3W\@3|
00000070 7e 7c 77 76 3d 1e 1e 19 37 13 13 13 13 13 13 13 |~|wv=...7.......|
00000080 16 ce 31 d1 0c 10 10 14 5e 4b 4b 53 56 4a 57 52 |.Î1Ñ....^KKSVJWR|
00000090 4a 55 5d 51 4a 55 50 52 4b 02 0d 16 17 10 4a 14 |JU]QJUPRK.....J.|
000000a0 0c 14 13 13 13 13 13 13 13 13 13 13 13 13 13 13 |................|
000000b0 13 13 13 13 52 af 5f 82 13 13 13 13 13 13 13 13 |....R¯_.........|
[...]
000001c0 46 43 4b 23 13 13 13 13 13 43 12 13 13 03 13 13 |FCK#.....C......|
000001d0 13 13 13 13 13 17 13 13 13 13 13 13 13 13 13 13 |................|
000001e0 13 13 13 13 93 13 13 f3 46 43 4b 22 13 13 13 13 |.......óFCK"....|
000001f0 13 93 13 13 13 73 12 13 13 69 13 13 13 17 13 13 |.....s...i......|
00000200 13 13 13 13 13 13 13 13 13 13 13 13 53 13 13 f3 |............S..ó|
00000210 3d 61 60 61 70 13 13 13 13 03 13 13 13 f3 12 13 |=a`ap........ó..|
00000220 13 11 13 13 13 6d 13 13 13 13 13 13 13 13 13 13 |.....m..........|
00000230 13 13 13 13 53 13 13 d3 13 13 13 13 13 13 13 13 |....S..Ó........|
00000240 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 |................|
While this might still look like gibberish to some of you, folks who have looked at malware binaries in a hex dump before will notice the same we did: This sure does have the same structure as an UPX compressed EXE binary - with the difference that normal binaries don't have a file header full of "0x13" but rather a "0x00" in those places, and that "normal" EXEs also start with the tell-tale "MZ" byte sequence and not with "^I".
The simplest trick in the book to get to "0x00" from "0x13" is a binary XOR operation. XOR-ing something with the same value twice in a row yields the original byte again, so let's try a XOR with 0x13 to get from 0x13 back to 0x00:
daniel@debian:~$ cat stage2.bin | perl -pe 's/(.)/chr(ord($1)^0x13)/ge' > stage3.bin
daniel@debian:~$ file stage3.bin
stage3.bin: MS-DOS executable (EXE), OS/2 or MS Windows
Yee-Hah! The resulting decoded file is indeed an UPX packed windows binary.
Looks like the days are over when a running malware foolishly gave away its presence by trying to download additional components in EXE form. First, we had EXEs, then EXEs with JPG extension, then EXEs with JPG header - and now plain ASCII blobs. The task of your perimeter (proxy) anti-virus filter has just gotten a couple notches more daunting.
-- Daniel Wesemann
The malware was talking to a handful of servers over HTTP to fetch additional content, and only by faking user agent headers to look exactly like the malware was setting them was Bojan able to retrieve the additional files. The files he got were "big strings" of ASCII character sequences which Bojan quickly figured out how to decode/translate from the Ceasarean substitution cipher into URLs. But when requesting one of these URLs, all he got was another messy big string, and one whose coding method was different:
FOEJIDBDBABDBDBDBHBDBDBDOMOMBDBDKLBDBDBDBDBDBDBDFDBDBDBDBDBDBDBDBDBDBDBDBDBDBDBD
BDBDBDBDBDBDBDBDBDBDBDBDBDBDBDBDBDBDBDBDNLBDBDBDBNAMKJBNBDKHBKNODCKLBCFPNODCEHHL
HKGADDGDGBHMHEGBHCHODDHAHCHNHNHMGHDDHBHGDDGBGGHNDDHKHNDDFHFMEADDHOHMHHHGDNBOBOBJ
DHBDBDBDBDBDBDBDBGMODBNBAMBABABEFOELELFDFGEKFHFCEKFFFNFBEKFFFAFCELACANBGBHBAEKBE
AMBEBDBDBDBDBDBDBDBDBDBDBDBDBDBDBDBDBDBDFCKPFPICBDBDBDBDBDBDBDBDBDBDBDBDBDBDBDBD
EDFGBDBDFPBCBABDKKGNNFFHBDBDBDBDBDBDBDBDPDBDBMBCBIBCBFBDBDJDBDBDBDADBDBDBDEDBCBD
[...]
KHBKNODCKLBCFPEHHLHKGADDGDGBGMOIOMOMHMHEGBHCHODDHAHCHNHNHMGHDDHBHGDDGBGGHNDDHKBB
FHFMEADDHOHMHCOMNCONHHHGDNBOBOBJDHFAGEPFNGHDCAJELICABANLCEMMOOFLIILECACBBEKDIILG
CACCMIILLCCACEJMCOOFMLLMBMHDLHKBBEHJLHKLBMCAJELJNCNFIFNOCAKMECILCLDEKOCECPKBOEKC
KNBEEBHKHAHLEEKIEDFGHMJEGOKIFPBCOGLDGNNFFHAAPDNODCBIBCAOKIBGKKBFBKLFADBHAAGJOEHP
OFKKMEBHADBAAABKADBMAOKBIIGOMKBEBDDDBGDEDJBBBDEKKBHGHMBBBEBFDNOPFCFFMIBAFMKHPOAD
BGBDHPBIAGKFBIIDHHFLBBANNBBNMIOPDNGHHGGLGHCLONIDBCILODHNONMMIIBDBHPDDNHHHCGHHCGL
KJBAOIOPAMNIIFBABDDANDEAHLHCGBHGHHIHIOPPKLDHCGCLMDBHDDDEKCNKPOPOODDNDGHPHMHAMILN
(broken up for readability here - the original was one single long line with no CR/LF)
At first, we were convinced that the long string we were looking at was just another collection of URLs. But all the pattern matching we could cook up did not turn up anything looking like an encoded URL. So it was time to try a different approach - statistical analysis. Counting characters and character sequences can frequently tell something about the code or cipher used.
Starting with how many different "single" characters were in the cipher:
daniel@debian:~$ cat bigstring.txt | perl -ne 's/\s//g; s/(.)/$seen{$1}++/eg; foreach $c (keys %seen) {print "$seen{$c} $c\n"}' | wc -l
16
Hmm. Sixteen different chars. Let's see how many different two-character sequences we have:
daniel@debian:~$ cat bigstring.txt | perl -ne 's/\s//g; s/(..)/$seen{$1}++/eg; foreach $c (keys %seen) {print "$seen{$c} $c\n"}' | wc -l
256
Well well, another power of two. This can't be coincidence :-)
daniel@debian:~$ cat bigstring.txt | perl -ne 's/\s//g; s/(....)/$seen{$1}++/eg; foreach $c (keys %seen) {print "$seen{$c} $c\n"}' | wc -l
13160
Four-character sequences, on the other hand, don't seem to be anything special, what with 13160 different ones in the file. So most likely what we are dealing with here is a code that translated two-byte hexadecimal chars into a different alphabet. Let's see the 16-char alphabet and related frequency:
daniel@debian:~$ cat bigstring.txt | perl -ne 's/\s//g; s/(.)/$seen{$1}++/eg; foreach $c (keys %seen) {print "$seen{$c} $c\n"}'
4077 A
3523 F
3415 J
3496 O
3380 N
4108 P
3361 K
6790 B
3332 E
4334 H
3338 M
4718 C
6530 D
3623 I
3730 G
3781 L
Hmm. The frequencies dont help anything, but these are the first 16 chars of the alphabet. Maybe someone was lazy and did a simple substitution of the 16 hex values into the first 16 chars of the alphabet - which would mean that an "A" is 0, a "B" is 1, etc until "P" which would equal 0xF - 15 in Hex. Trying this hypothesis on the file meant to convert the sixteen characters found in the file into their corresponding value. Done quick and dirty in PERL, this meant subtracting 65 from the ASCII code of each of the characters (65 is the ASCII code of "A" - consequently ascii(A)-65 equals 0, as desired):
daniel@debian:~$ cat bigstring.txt | perl -ne 's/(.)/printf "%x",ord($1)-65/ge' > stage1.txt
which had the resulting "stage1" file look something like this:
5e4983131013131317131313ecec1313ab1313131313131353131313131313131313131313131313
1313131313131313131313131313131313131313db1313131d0ca91d13a71ade32ab125fde32477b
7a603363617c7461727e3370727d7d7c673371763361667d337a7d33575c40337e7c77763d1e1e19
371313131313131316ce31d10c1010145e4b4b53564a57524a555d514a5550524b020d1617104a14
0c1413131313131313131313131313131313131352af5f8213131313131313131313131313131313
435613135f121013aa6dd5571313131313131313f3131c1218121513139313131303131313431213
[...]
These were still hex values. In order to translate them into the corresponding characters, another line of PERL-fu had to be applied:
$cat stage1.txt | perl -pe 's/(..)/chr(hex($1))/ge' > stage2.bin
This line takes the hex codes from the "stage1" file and converts them into one-byte characters.
Taking a look at the resulting "stage2.bin" file with a hex-dumper, we got:
daniel@debian:~$ hexdump -C stage2.bin | more
00000000 5e 49 83 13 10 13 13 13 17 13 13 13 ec ec 13 13 |^I..........ìì..|
00000010 ab 13 13 13 13 13 13 13 53 13 13 13 13 13 13 13 |«.......S.......|
00000020 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 |................|
00000030 13 13 13 13 13 13 13 13 13 13 13 13 db 13 13 13 |............Û...|
00000040 1d 0c a9 1d 13 a7 1a de 32 ab 12 5f de 32 47 7b |..©..§.Þ2«._Þ2G{|
00000050 7a 60 33 63 61 7c 74 61 72 7e 33 70 72 7d 7d 7c |z`3ca|tar~3pr}}||
00000060 67 33 71 76 33 61 66 7d 33 7a 7d 33 57 5c 40 33 |g3qv3af}3z}3W\@3|
00000070 7e 7c 77 76 3d 1e 1e 19 37 13 13 13 13 13 13 13 |~|wv=...7.......|
00000080 16 ce 31 d1 0c 10 10 14 5e 4b 4b 53 56 4a 57 52 |.Î1Ñ....^KKSVJWR|
00000090 4a 55 5d 51 4a 55 50 52 4b 02 0d 16 17 10 4a 14 |JU]QJUPRK.....J.|
000000a0 0c 14 13 13 13 13 13 13 13 13 13 13 13 13 13 13 |................|
000000b0 13 13 13 13 52 af 5f 82 13 13 13 13 13 13 13 13 |....R¯_.........|
[...]
000001c0 46 43 4b 23 13 13 13 13 13 43 12 13 13 03 13 13 |FCK#.....C......|
000001d0 13 13 13 13 13 17 13 13 13 13 13 13 13 13 13 13 |................|
000001e0 13 13 13 13 93 13 13 f3 46 43 4b 22 13 13 13 13 |.......óFCK"....|
000001f0 13 93 13 13 13 73 12 13 13 69 13 13 13 17 13 13 |.....s...i......|
00000200 13 13 13 13 13 13 13 13 13 13 13 13 53 13 13 f3 |............S..ó|
00000210 3d 61 60 61 70 13 13 13 13 03 13 13 13 f3 12 13 |=a`ap........ó..|
00000220 13 11 13 13 13 6d 13 13 13 13 13 13 13 13 13 13 |.....m..........|
00000230 13 13 13 13 53 13 13 d3 13 13 13 13 13 13 13 13 |....S..Ó........|
00000240 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 |................|
While this might still look like gibberish to some of you, folks who have looked at malware binaries in a hex dump before will notice the same we did: This sure does have the same structure as an UPX compressed EXE binary - with the difference that normal binaries don't have a file header full of "0x13" but rather a "0x00" in those places, and that "normal" EXEs also start with the tell-tale "MZ" byte sequence and not with "^I".
The simplest trick in the book to get to "0x00" from "0x13" is a binary XOR operation. XOR-ing something with the same value twice in a row yields the original byte again, so let's try a XOR with 0x13 to get from 0x13 back to 0x00:
daniel@debian:~$ cat stage2.bin | perl -pe 's/(.)/chr(ord($1)^0x13)/ge' > stage3.bin
daniel@debian:~$ file stage3.bin
stage3.bin: MS-DOS executable (EXE), OS/2 or MS Windows
Yee-Hah! The resulting decoded file is indeed an UPX packed windows binary.
Looks like the days are over when a running malware foolishly gave away its presence by trying to download additional components in EXE form. First, we had EXEs, then EXEs with JPG extension, then EXEs with JPG header - and now plain ASCII blobs. The task of your perimeter (proxy) anti-virus filter has just gotten a couple notches more daunting.
-- Daniel Wesemann
Keywords:
0 comment(s)
Tip of the day: Test, don't ping
Ping is the all-time favorite of "monitoring" in IT. Looking at network traffic on the job, I have seen servers being pinged by various "monitoring" tools all across the enterprise no less than every second or so. I usually refer to this as "theft prevention", because the "monitoring" application will - if at all - only turn "red" if someone grabs your box and walks away with it. It ain't no secret that true monitoring requires that you monitor the key functionaliy, and not the existence, of a device.
While this concept is increasingly in use for operational (service availability) monitoring, it seems to me this hasn't quite caught on yet for the monitoring of security filters. Experience tells that security filters which you think are in place but aren't, or are not working anymore, make for nasty surprises. Here's a few hints on how to avoid them:
Case #1: Proxy Anti-Virus
If you have a proxy server that is supposed to do AV filtering, a simple script that pulls an EICAR test file through the proxy can go great lengths in detecting whether the AV is still working. It won't tell you if the patterns are up to date, but it WILL tell you if, for example, the AV process has crashed and the solution is in "fail open" state.
Case #2: Proxy URL Filtering
If there is something in place that supposedly should keep your users from going to www.morelength.porn, then having a script that tries exactly this access can tell you if your URL filter is working as desired.
Case #3: Proxy Content Filtering
If your proxy is configured to prevent downloads of, say, files with .scr extension, trying to grab such a file through the proxy makes a good test, too. Not that I advocate blocking by extension only, read my earlier post on "Decoding Malware" to see how current malware avoids extension and content filters. But if having such a block is part of your defense strategy, testing that it still works should also be part of it.
Case #4: EMail Content Filtering
Pretty much the same as #3, but due to the load of spam and virii on the email side, content and extension based blocking still makes a lot of sense here. If you can get away with it, even better are white lists that only allow a pre-defined set of attachment types. In any case, testing that these filters still work as advertised is highly recommended. You can set up an external server to send "known blocked" email types against your mail gateway. You can even address such test emails to the operations or abuse team mailbox, and if they ever get one of the test mails complete with attachment delivered, they know right away something is broken (test mails which have been filtered correctly can be moved into a folder automatically, so they dont clutter the inbox)
Case #5: EMail Anti-Spam and Anti-Virus
Trying to send inbound EICARs and GTUBEs via email, following the same approach as above, will tell you if your spam filter and AV are doing their job as desired.
If you have some neat feat to share on how you test the working condition of your security filters, please let us know and I'll update this diary later today with the best tips we receive.
While this concept is increasingly in use for operational (service availability) monitoring, it seems to me this hasn't quite caught on yet for the monitoring of security filters. Experience tells that security filters which you think are in place but aren't, or are not working anymore, make for nasty surprises. Here's a few hints on how to avoid them:
Case #1: Proxy Anti-Virus
If you have a proxy server that is supposed to do AV filtering, a simple script that pulls an EICAR test file through the proxy can go great lengths in detecting whether the AV is still working. It won't tell you if the patterns are up to date, but it WILL tell you if, for example, the AV process has crashed and the solution is in "fail open" state.
Case #2: Proxy URL Filtering
If there is something in place that supposedly should keep your users from going to www.morelength.porn, then having a script that tries exactly this access can tell you if your URL filter is working as desired.
Case #3: Proxy Content Filtering
If your proxy is configured to prevent downloads of, say, files with .scr extension, trying to grab such a file through the proxy makes a good test, too. Not that I advocate blocking by extension only, read my earlier post on "Decoding Malware" to see how current malware avoids extension and content filters. But if having such a block is part of your defense strategy, testing that it still works should also be part of it.
Case #4: EMail Content Filtering
Pretty much the same as #3, but due to the load of spam and virii on the email side, content and extension based blocking still makes a lot of sense here. If you can get away with it, even better are white lists that only allow a pre-defined set of attachment types. In any case, testing that these filters still work as advertised is highly recommended. You can set up an external server to send "known blocked" email types against your mail gateway. You can even address such test emails to the operations or abuse team mailbox, and if they ever get one of the test mails complete with attachment delivered, they know right away something is broken (test mails which have been filtered correctly can be moved into a folder automatically, so they dont clutter the inbox)
Case #5: EMail Anti-Spam and Anti-Virus
Trying to send inbound EICARs and GTUBEs via email, following the same approach as above, will tell you if your spam filter and AV are doing their job as desired.
If you have some neat feat to share on how you test the working condition of your security filters, please let us know and I'll update this diary later today with the best tips we receive.
Keywords: ToD
0 comment(s)
×
![modal content]()
Diary Archives
© 2024 SANS™ Internet Storm Center
Developers: We have an API for you! 
Comments