Last Updated: 2009-02-12 09:19:14 UTC
by Swa Frantzen (Version: 1)
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
Last Updated: 2009-02-10 20:14:50 UTC
by Bojan Zdrnja (Version: 1)
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:
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:
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:
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.
Last Updated: 2009-02-10 19:46:46 UTC
by Swa Frantzen (Version: 1)
Overview of the February 2009 Microsoft patches and their status.
|#||Affected||Contra Indications||Known Exploits||Microsoft rating||ISC rating(*)|
|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.
No publicly known exploits
|MS09-003||Multiple vulnerabilities allow code execution and DoS.
|KB 959239||No publicly known exploits.||Severity:Critical
|MS09-004||An input validation vulnerability in a extended stored procedures leads to random code execution.
Replaces MS08-040 and MS08-052.
|KB 959420||Exploit code publicly available since December 2008||Severity:Important
|MS09-005||Multiple vulnerabilities allow random code execution with the rights of the logged on user.
|KB 957634||No publicly known exploits.||Severity:Important
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
- 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