Microsoft August 2006 Patches: STATUS

Published: 2006-09-11
Last Updated: 2006-09-11 23:05:04 UTC
by Swa Frantzen (Version: 13)
0 comment(s)
Overview of the known problems and publicly known exploits ofthe August 2006 Microsoft patches.

# Known Problems with this patch
Known Exploits
client rating server rating
MS06-040 Issue with:
  • Huge memory allocations on Windows 2003 server SP1 (32bit & 64bit), XP (64bit) and 32bit application.
  • Microsoft Business Solutions?Navision 3.70 on above platform.
  • Websense Manager when using terminal services
Fix:
  • Hotfix available by calling Microsoft.
More information:
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:
  • This patch introduces a new arbitrary code execution vulnerability on MSIE 6 SP1.
Fix:
  • Microsoft re-released MS06-042 on Aug 24th 2006.
  • It is unclear if the hotfix that was available earlier fixes this problem as well.

More info:

Issue #1:
  • MSIE 6 SP1 crashes while using multiple application such as Peoplesoft, Siebel, Sage CRM and websites using HTTP 1.1 and compression such as the register.
  • Roll-up patch so it has all older issues as well.
Workaround:
  • Workaround to disable HTTP/1.1
  • Use alternate browser (for problem sites)
Fix:
  • Upgrade to MSIE 6 SP2
  • The re-release of the August 24th is intended to fix this. The fix was supposed to be published by Microsoft on August 22nd, 2006 but was delayed.
More Information:
Issue #2:
  • CA Unicenter Service Desk can cause MSIE to crash, on XP SP2 and Windows 2003 SP1
Workaround:
  • Use the supported Firefox or Mozilla browsers
  • KB923996
Fix:
  • The re-release of MS06-042 is not fixing this problem as far as we know.
More information:

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.
  • Microsoft released it first on the 22nd
  • actual code fragments were publicly released on the 24th after the patch was updated
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
0 comment(s)

More on encoded malware

Published: 2006-08-23
Last Updated: 2006-08-23 21:56:08 UTC
by Daniel Wesemann (Version: 1)
0 comment(s)
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:

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

Published: 2006-08-23
Last Updated: 2006-08-23 19:43:23 UTC
by Daniel Wesemann (Version: 1)
0 comment(s)
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.


Keywords:
0 comment(s)

PHP Security Update

Published: 2006-08-23
Last Updated: 2006-08-23 16:25:53 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)
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.
  • 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.
So thats the quick summary of the (already quite brief) document. For a more detailed discussion you will likely have to check the PHP developer mailing lists. I am not that familiar with PHP politics, so I am not sure how flexible these changes are. There are PHP 6.0 development snapshots available at this point. But at least to me, PHP 5 is still quite new ;-). PHP has had a good history of supporting older versions, so there is no reason to panic quite yet.

For the full document, see Minutes PHP Devlopers Meeting.
Keywords:
0 comment(s)

Decoding malware

Published: 2006-08-23
Last Updated: 2006-08-23 10:33:53 UTC
by Daniel Wesemann (Version: 1)
0 comment(s)
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

Keywords:
0 comment(s)

Tip of the day: Test, don't ping

Published: 2006-08-23
Last Updated: 2006-08-23 07:50:01 UTC
by Daniel Wesemann (Version: 1)
0 comment(s)
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.

Keywords: ToD
0 comment(s)

Comments


Diary Archives