Just a reminder: the Conficker/Downadup worm has a payload that will activate on April 1 (which is tomorrow here in Manila). Mainly, it will contact several domains, for what analysts can only speculate. For all we know, it could be this year’s biggest April Fool’s joke. While most antivirus companies downplay the danger (since Microsoft has since patched the vulnerability being exploited by this worm), it pays to be careful.

Most antivirus can detect and delete/quarantine most variants, so make sure your antivirus software is updated. Perform a full scan. Be careful when going online.

Read the Trend Micro Q&A here more more information.

The battle against malware has just become a bit harder. Welcome the MBR rootkit!

This new Windows MBR rootkit launches itself very early during the Windows startup process without requiring any registry or file modifications. In fact, it is quite surprising that it’s possible to write to the MBR from within Windows to begin with.

The MBR rootkit — known as “Mebroot” — is very advanced and probably the stealthiest malware we have seen so far. It keeps the amount of system modifications to a minimum and is very challenging to detect from within the infected system.

A rootkit allows a program to be hidden from the user – it is used as a stealth mechanism, to hide from old antivirus applications and plain computer users (like me). But most AV products nowadays can detect rootkits, so rootkits’ usefulness ebbed somewhat. An MBR rootkit changes the game.

A master boot record contains the first code loaded during the computer’s startup process. That means an infected MBR will load the suspect code even before your operating system is loaded. That means your AV product, if not updated, will not be able to find it. That means the rootkit is loaded every time the system is started.

Always update your security software, and be careful in downloading files from the Internet. Also, do not open email attachments, specially coming from untrusted sources.

Now, if this report is true, it changes our elementary computing concepts:

Typically we think of the hardware of our computers in a specific way. One of those is that the contents of RAM is gone as soon as you turn off the power. Makers of software such as ssh-agent, PGP software and hard disk encryption software rely on encryption keys in RAM that get erased when the system is turned off.

Newly published research goes a long way to show the hardware isn’t behaving like most of us think it is and that memory modules, even removed from the motherboard can retain data for seconds to minutes allowing retrieval of the cryptographic keys.

This scenario adds a new dimension to data security. As most laptops issued to employees by most companies involved data encryption of some form, losing a laptop becomes more unbearable than ever.

You may get the PDF report here.

A roundup of computer security-related posts that I think you should be aware of:

* McAfee Avert Labs Blog reports of an Adobe PDF exploit spreading in the wild. Given the fact that PDF is almost a standard document format, be careful in opening PDFs. Affected Adobe apps are Adobe Reader 8.1.1 and earlier versions; and Adobe Acrobat Professional, 3D, and Standard 8.1.1 and earlier versions. Temporary mitigating measure includes not opening PDF files coming from the Internet. Users are advised to upgrade their Adobe PDF apps.

Techie part: the exploit allows for a JavaScript embedded in a PDF file to download a Trojan. Of course, you have to open the PDF file first.

Really techie part: vulnerability reports by Securiteam (with suggested workaround) and iDefense.

* And this month being the season for love (yeah, right), expect to get a lot of spam exploiting Valentines Day. TrendLabs Malware Blog warns people that the most prolific worm of 2007 (and most prolly 2008), Storm, is exploiting this event. These spam emails contain links to Web sites. DO NOT CLICK ON THOSE LINKS, of course.

Securiteam reports of a vulnerability in WordPress’ cookie authentication. Through this vulnerability, an attacker can generate a valid login cookie for any user account without using a brute force attack (assuming that the attacker can gain at least read-only access to the WordPress database). When a cookie is generated, an attacker can perform limited SQL injection and be granted administrator access to that WordPress installation.

(Structured Query Language (SQL) injection is a technique used by hackers to execute destructive and admin-only SQL statements. Read more here.)

When a WordPress user (of any level) logs in, the WordPress system queries the database for the user name and password for authentication. If the credentials are OK, the system generates two cookies and save them in the user’s cookie cache. One of the cookies contain the user’s password encoded using double MD5 hash.

* Why save a cookie? A cookie allows a user to gain access to any WordPress administrative pages without signing in each time.
* MD5 is a cryptographic hash function used to protect passwords. When a new user registers with a WordPress-powered site, his password is encoded using MD5 and is saved in that form in the database.

Now, where is the problem? WordPress stores the password in the cookie in the MD5(MD5(password)) format. What does it mean? The password saved in the cookie is actually a password in the clear, which means that you can actually know what the password is using MD5!

What the hacker now needs is to gain access to a WordPress database. A hacker can do this by looking for a database backup that anyone can view, or looking for a WordPress installation that is vulnerable to SQL injection. When that happens, a hacker can gain administrative access.

Securiteam has listed several workarounds:

– Protect the WordPress database, and do not allow backups to be released.
– Keep your WordPress installation up to date. This should reduce the risk that your database will be compromised.
– Do not share passwords across different sites.
– If you suspect a database to be compromised, change all passwords to different ones. It is not adequate to change the passwords to the same ones, since WordPress does not “salt” the password database.
– Remove write permissions on the WordPress files for the system account that the webserver runs as. This will disable the theme editor, but make it more difficult to escalate WordPress administrator access into the capability to execute arbitrary code
– Configure the webserver to not execute files in any directory writable by the webserver system account (e.g. the upload directory).