Threat Level: green Handler on Duty: Rob VandenBrink

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2007-02-12 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

New Java update (1.5.0u11) and a Microsoft Word 2000 vulnerability

Published: 2007-02-12
Last Updated: 2007-02-14 03:29:42 UTC
by Bojan Zdrnja (Version: 2)
0 comment(s)
Sun recently released (another) update for Java 1.5.0, Update 11. There are a bunch of bug fixes and I didn’t see anything serious related to security.
However, it is worth noting that this update contains time zone data that incorporates Day Light Saving changes for 2007 (we wrote about this previously, http://isc.sans.org/diary.html?storyid=2142, but will use another opportunity to remind you about the changes).
Java update should be available automatically now as well – just remember to remove the old update revisions if you don’t need them any more (after you’ve thoroughly tested all your applications, of course).

McAfee published information about a new 0-day exploit for Word. They’ve notified Microsoft and it looks like the vulnerability is limited to Denial of Service. We’ve updated the list of 0-days in Microsoft products which you can find here: http://isc.sans.org/diary.html?storyid=1940.

UPDATE

Just couple of things:
  • The time zone data part of the update is not related to the changes in the USA - that was covered by a previous update. The current time zone data covers some other countries (you can get the whole list by checking the release notes at http://java.sun.com/j2se/1.5.0/ReleaseNotes.html#150_11). Thanks Toby.
  • Jeff wrote to remind us that if you have installed the unlimited cryptography JARs that you will need to do that again.
Keywords:
0 comment(s)

* Another good reason to stop using telnet

Published: 2007-02-12
Last Updated: 2007-02-13 21:43:31 UTC
by donald smith (Version: 6)
0 comment(s)
There is a major zero day bug announced in solaris 10 and 11 with the telnet and login combination.
It has been verified. In my opinion NOBODY be should running telnet open to the internet.
Versions of Solaris 9 and lower do not appear to have this vulnerability.

The issue:
The telnet daemon passes switches directly to the login process which looks for a switch that allows root to login to any account without a password. If your telnet daemon is running as root it allows unauthenticated remote logins.

Telnet should be disabled. Since 1994 the cert.org team has recommended using something other then plain text authentication due to potential network monitoring attacks. http://www.cert.org/advisories/CA-1994-01.html
“We recognize that the only effective long-term solution to prevent these attacks is by not transmitting reusable clear-text passwords on the network.“

If remote shell access is required ssh is a better choice then telnet. We have done articles about securing ssh in the past. http://isc.sans.org/diary.html?storyid=1541

The FIX:
To disable telnet in solaris 10 or 11 this command should work.
svcadm disable telnet

The Mitigations:
Limit your exposure if you must run telnet on your solaris system it is recommend that you use firewall(s) to limit what IP can connect to your telnet services.

Change
/etc/default/login add CONSOLE=/dev/console
to limit where root can login from. This only prevents direct access to the root account other accounts can still be compromised.

Another mitigation that works in most cases is this:
inetadm -m svc:/network/telnet:default exec="/usr/sbin/in.telnetd -a user"
We have had one report of someone locking themselves out with this so use at your own risk.

- The Snort signature has been removed at the request of the author.

I am not going to include the site with the exploit. No special tools are required to exploit this vulnerability.

Sun response
Sun has issued a note at http://sunsolve.sun.com/search/document.do?assetkey=1-26-102802-1
pointing to a partial workaround that limits root login from the console only.

Thanks to Chris and Thomas who notified us of this issue and all the fellow handlers that helped verify, mitigate and review this report.
Keywords:
0 comment(s)

Encrypted malware and code reusability

Published: 2007-02-12
Last Updated: 2007-02-12 05:56:35 UTC
by Bojan Zdrnja (Version: 1)
0 comment(s)

About 3 weeks ago, one of our readers, Andrew, submitted a very interesting malicious binary. Andrew did some analysis himself and told us that he found encrypted files and some certificates which immediately caused interest amongst handlers.
If you are regularly reading ISC, you probably read the diary I wrote back in January about unsophisticated malware (http://isc.sans.org/diary.html?storyid=2022). Well, this time, things were completely different.

Initial analysis by Andrew showed that the machine was infected with a VML exploit. A small binary is dropped on the infected machine which, in this case, was a bit more than a typical downloader.

The analysis of unknown malicious programs can be a very difficult task. The first step in any analysis is to determine if the binary is packed or not. PEiD (http://peid.has.it), a tool I mentioned in the previous diary quickly determined that the binary was packed with UPX. UPX is a very common packer that is easy to unpack – various utilities exist that can help you with unpacking UPX and even doing it manually is very simple.

Once the binary was unpacked, you will typically want to run the strings command on the unpacked code, to see if there is anything that you can determine quickly by manually inspecting strings result.
The following two lines looked very interesting:

inflate 1.2.3 Copyright 1995-2005 Mark Adler
unzip 1.01 Copyright 1998-2004 Gilles Vollant - http://www.winimage.com/zLibDll


It looks like our malware has been linked with zLibDll, an open source ZLIB compression library. This also explained what Andrew was seeing as he said that a password protected ZIP file was downloaded by the downloader. A quick search of potential passwords did not result in anything so we concluded that the binary must either generate the password with some code, or download it from the Internet. In this case, the second assumption was correct.

Now we come to the most interesting (and difficult part). You could, of course, manually analyze disassembled malware code (IDA Pro is of great help here, if you can afford it), but an easier approach (in my opinion) is to run the downloader through a debugger and carefully watch what it is doing. The debugger of my choice is, of course, OllyDbg (http://www.ollydbg.de), which is the best free debugger for Windows operating system.
In order to debug a program you will need x86 assembly knowledge, so this would be a good time to refresh it (or read some books about it).

The debugging process is relatively simple: you load a file into the debugger, and execute it step by step while carefully watching what’s going on.
The downloader in question did the usual stuff. After copying itself into C:\Documents And Settings\All Users folder, it opened a HTTP connection to the control Web server:

http://ijk [dot] cc/cgi-bin/ [REMOVED] oadfile=q/q2_started_ok
(the site is still up)
Once it registered properly, the downloader downloaded a file called qa.zip, which was the password protected ZIP archive.
Now came the interesting bit. By stepping through the binary with the debugger, we were able to determine the password used to protect the archive. You can see how it is slowly appearing in the EDI register (the real password is much longer which makes brute forcing the ZIP archive difficult). A method similar to this one is always used when a malware generates a password programmatically – it will either keep it in one of the registers or somewhere in the memory.

OllyDbg

Knowing the password it is easy to extract the ZIP archive now and as the standard ZIP format was used this can be done even with a standalone ZIP program.

The archive contained some interesting binaries:

$ ls -l
total 144
drwxr-xr-x 2 test test 4096 Jan 10 19:57 .
drwxr-xr-x 4 test test 4096 Feb 12 14:05 ..
-rw-r--r-- 1 test test 1505 Aug 10 2005 cert.pem
-rw-r--r-- 1 test test 692 Jan 8 09:49 crontab.cb
-rw-r--r-- 1 test test 432 Jan 8 09:49 _qbot.cb
-rw-r--r-- 1 test test 96768 Jan 8 09:30 _qbot.dll
-rw-r--r-- 1 test test 20480 Dec 29 08:19 _qbotinj.exe
-rw-r--r-- 1 test test 600 Jan 8 09:49 updates.cb


Casual inspection of files did not show much and we concluded that all the .cb files were encrypted (or obfuscated) as they had purely binary contents. The cert.pem file was obviously used as some kind of a certificate to encrypt something. So we continued with the debugging of the main downloader.

After some time spent on it, the part that decrypted the *.cb files was executed. It was a simple obfuscation function. Typically in cases like this what most analysts do is write a perl program that does the same thing so you can decrypt the files without running the malware.
The file contents were pretty obvious – updates.cb contained list of URLs to update from and _qbot.cb contained information about the C&C IRC servers.

The last thing that puzzled us was the certificate – what was it used for? The answer was in the _qbot.dll file. This file contains the main IRC bot, that is injected in another process and executed. Analyzing this file revealed that it was linked with another package (this time commercial), called MatrixSSL. MatrixSSL is a library by PeerSec Networks (http://www.peersec.com/matrixssl.html) that allows application to support SSL/TLS. This was obviously used by the malware to encrypt its network communication. In this case, the cert.pem file was used to connect to the IRC C&C server and encrypt the session, so network IDS tools would not see any commands issued to the bot.

As most anti virus analysts already saw, malware authors often reuse their code. It’s not strange to see code from one malware family used in another. This case showed us that malware authors are happy to use open source or even commercial packages that can help them. And they treat their programs as full blown projects, as one string from the bots binary confirmed: J:\projects\qbot\matrixssl\src\matrixSsl.c.

Finally, the AV detection on submitted files is still very bad, even weeks after it has been released. The original downloader was detected by only a handful of AV programs, while the second stage (real bot) was detected by only 3 programs. It is clear that you can not rely only on the AV program and that you should have defense in depth. In this case, blocking outgoing TCP traffic would at least prevent the bot from contacting the C&C server and doing more harm on your internal network.

Keywords:
0 comment(s)
Diary Archives