Threat Level: green Handler on Duty: Guy Bruneau

SANS ISC InfoSec Handlers Diary Blog


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

Java up to date ?

Published: 2009-02-10
Last Updated: 2009-02-12 09:19:14 UTC
by Swa Frantzen (Version: 1)
2 comment(s)

Roseman wrote in with a link to http://java.com/en/download/installed.jsp, where one can test if the installed java environment is up to date. Great for home users, but the corporate types need to make sure they have their entire fleet up to date (and get rid of old versions -a not so small task when it comes to java environments-).

Roseman did indicate his update for the first time did remove the old update 11 environment. Finally! But he also indicated it still reset his preferences from daily check for updates to monthly as well as other preferences.

The latest release is Java 6 update 12:

--
Swa Frantzen -- Section 66

Keywords: java update
2 comment(s)

More tricks from Conficker and VM detection

Published: 2009-02-10
Last Updated: 2009-02-10 20:14:50 UTC
by Bojan Zdrnja (Version: 1)
0 comment(s)

Following my yesterdays diary (http://isc.sans.org/diary.html?storyid=5830), here are some other interesting things Conficker does.

If you tried to clean Conficker from an infected machine, you probably noticed that you can't open the registry key it creates for its service. The registry key is located in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\[random] where [random] is just a random text string Conficker generated. This registry key contains information about Conficker's service, so in order to prevent users from disabling it, Conficker modifies ACLs on this registry key. As shown in the screenshot below, Conficker calls the RegSetKeySecurity() function from ADVAPI32.dll which sets appropriate permissions on this key:

OllyDbg registry ACL change

The permissions are very simple – Conficker removes all access to the key except for SYSTEM. The screenshot below shows what the ACL on this key looks after the function mentioned above is called:

Modified registry permissions

This will effectively prevent a user from opening the key, even if he is a local Administrator. Old trick, but still effective, let's move on.

In order to make analysis more difficult, Conficker tries to detect if it is running in a virtual machine. Back in 2007 I wrote a diary (http://isc.sans.org/diary.html?storyid=3190) explaining how the Storm worm detected if it was running in a virtual machine. Conficker uses a different trick though:

OllyDBG SLDT

During the execution, Conficker calls the SLDT instruction many times. The SLDT instruction stores the Local Descriptor Table in a register that is then compared by Conficker with certain values. This allows Conficker to detect if it's running in a virtual machine – LDT of a native system will be 0x0000 while in VMWare (or VirtualPC) LDT will be relocated (for example, in VMWare 4 it will often be 0x4058). You can see in the code above that Conficker compares the result of the SLDT instruction with 0. If it is 0, the execution continues, otherwise Conficker calls the Sleep function with the value of -1 (0xFFFFFFFF) – this will cause the process to sleep for 29826 hours (so, like forever).
It is worth nothing that a similar trick was initially published by Joanna Rutkowska and further developed by Tobias Klein in his ScoopyNG tool (http://www.trapkit.de/research/vmm/index.html).

After all this we can definitely say that the Conficker authors were not amateurs – this looks like professionally written code. Stay tuned for more tricks at the SANS ISC.

Mega thanks to h4z4rd for spotting the SLDT trick.

--
Bojan
INFIGO IS
 

0 comment(s)

February Black Tuesday Overview

Published: 2009-02-10
Last Updated: 2009-02-10 19:46:46 UTC
by Swa Frantzen (Version: 1)
0 comment(s)

Overview of the February 2009 Microsoft patches and their status.

# Affected Contra Indications Known Exploits Microsoft rating ISC rating(*)
clients servers
MS09-002 Cumulative MSIE patch, adds fixes for multiple vulnerabilities that lead to random code execution with the rights of the logged on user
Replaces MS08-073 and MS08-078.
Internet Explorer

CVE-2009-0075
CVE-2009-0076
KB 961260

No publicly known exploits

Severity:Critical
Exploitability:1,1
Critical Important
MS09-003 Multiple vulnerabilities allow code execution  and DoS.
Replaces MS08-039.
Exchange

CVE-2009-0098
CVE-2009-0099
KB 959239 No publicly known exploits. Severity:Critical
Exploitability:2,2
N/A Critical
MS09-004 An input validation vulnerability in a extended stored procedures leads to random code execution.
Replaces MS08-040 and MS08-052.
SQL server

CVE-2008-5416
KB 959420 Exploit code publicly available since December 2008 Severity:Important
Exploitability:1
Critical (**) Critical
MS09-005 Multiple vulnerabilities allow random code execution with the rights of the logged on user.
Replaces MS08-019.
Visio

CVE-2009-0095
CVE-2009-0096
CVE-2009-0097
KB 957634 No publicly known exploits. Severity:Important
Exploitability:2,2,2
Critical Important
We will update issues on this page for about a week or so as they evolve.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
(*): ISC rating
  • We use 4 levels:
    • PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
    • Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
    • Important: Things where more testing and other measures can help.
    • Less Urgent: Typically we expect the impact if left unpatched to be not that big a deal in the short term. Do not forget them however.
  • The difference between the client and server rating is based on how you use the affected machine. We take into account the typical client and server deployment in the usage of the machine and the common measures people typically have in place already. Measures we presume are simple best practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.
  • The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threat for affected systems. The rating does not account for the number of affected systems there are. It is for an affected system in a typical worst-case role.
  • Only the organization itself is in a position to do a full risk analysis involving the presence (or lack of) affected systems, the actually implemented measures, the impact on their operation and the value of the assets involved.
  • All patches released by a vendor are important enough to have a close look if you use the affected systems. There is little incentive for vendors to publicize patches that do not have some form of risk to them.

(**): If the vulnerable component is installed

--
Swa Frantzen -- Section 66

0 comment(s)
Diary Archives