An ISC reader asked us about reports of malware that's locking user accounts. According to several media reports (1, 2), a "virus" has affected computers of the Vancouver School Board (VSB) on January 7. The most noticeable effects of the infection were user accounts getting locked. The district's staff were told not to turn on their computers to curtail the spread of the malware.

VSB seems to consider the worm a simple nuisance. However, the observed lockouts might be a side effect of an infection capable of other threats. A worm might inadvertently an auto-lockout defense when attempting to brute-force passwords. That might be the reason for the denial of service condition observed by VSB.

Though we received no other reports of this infection, its effects are reminiscent of the W32.Downadup worm we described in a December 31 diary. The worm spread by exploiting the RPC vulnerability (MS08-067). It also attempted to brute-force user passwords when connecting to the ADMIN$ share of systems on the local network. However, we have no additional information about the VSB incident, so we cannot confirm whether VSB's infection is, indeed, tied to W32.Downadup.

Update 1: We received a report of another school district experiencing problems of a similar scale. In this case, the user accounts are not being locked out. This worm "adds its own information" under the Windows XP logo during startup. "It then hijacks some processes and continues to spread.  Although it seems like an easy clean, according to Symantec, this worm is quite the annoyance." In this district, the worm is being detected as W32.Downadup.

Update 2: F-Secure published a list of the domains used by the Win32.Downadup worm earlier. Today they published another list of additional 1,500 sites used by the worm.

-- Lenny

Lenny Zeltser
Security Consulting - Savvis, Inc.

Lenny teaches a SANS course on analyzing malware.

Scans for vulnerabilities in Roundcube, popular web mail software, seem to be on the rise. We reported two vulnerabilities in this popular software in the past month.

According to a report we received today, scans for problems in Roundcube's msgimport feature are very active (see earlier diary). According to @lbhuston of twitter, this might be the same vulnerability announced on Help Net Security in December. For additional details about scans for this vulnerability, look at the the posting  at the MSI :: State of Security blog. For another data point, see the list of systems that, according to @codewolf on Twitter, are scanning him for Roundcube vulnerabilities.

The other vulnerability is in the html2text.php file (CVE-2008-5619), and is probably being targeted too (see earlier diary). There is a fix to the html2text.php problem, but I don't think the msgimport issue has a patch.

Update 1: Here are examples of Web server access logs that show recent attempts to exploit msgimport:

66.154.97.57 - - [09/Jan/2009:04:31:36 +0000] "GET /nonexistenshit HTTP/1.1" 404 212 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
8.208.193.113 - - [09/Jan/2009:06:24:55 -0500] "GET /mail/bin/msgimport HTTP/1.1" 404 391 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
88.208.193.113 - - [09/Jan/2009:06:24:55 -0500] "GET /bin/msgimport HTTP/1.1" 404 386 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
88.208.193.113 - - [09/Jan/2009:06:24:55 -0500] "GET /rc/bin/msgimport HTTP/1.1" 404 389 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
88.208.193.113 - - [09/Jan/2009:06:24:55 -0500] "GET /roundcube/bin/msgimport HTTP/1.1" 404 396 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
88.208.193.113 - - [09/Jan/2009:06:24:55 -0500] "GET /webmail/bin/msgimport HTTP/1.1" 404 394 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"
58.215.88.10 - - [09/Jan/2009:09:01:13 -0500] "GET /mail/bin/msgimport HTTP/1.1" 404 391 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5"

Update 2: Steven Adair from Shadowserver noticed two additional user agent strings being used by the scanners:

Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
Toata dragostea mea pentru diavol (this one was reported in our earlier diary)

Also, thanks to Ken for mentioning in the comments that Emerging Threats has Snort rules to alert on these activities. According to Ken, search emerging rules for SIDs 2008990 and 2008991.

Update 3: Nathan shared with us a few pointers to Roundtube developer discussions of the msgimport vulnerability. "Based on http://lists.roundcube.net/mail-archive/dev/2009-01/0000055.html it seems versions prior to 0.2-alpha are vulnerable." Additional messages on the list: 1, 2. "They appears to be providing little information publicly about the exploit but appear to have acknowledged it."
 

-- Lenny

Lenny Zeltser
Security Consulting - Savvis, Inc.

Lenny teaches a SANS course on analyzing malware.

We received a report of a Swedish company that was just subjected to a targeted attack. The company's high-ranking executives received an email message with an attached executable file named "Likviditetsrapport december prel.xls .exe". (This translates to "Analysis of the current acquisition market.xls  .exe".) The file's icon looked like that for an Excel document.

The targeted company employs has approximately 6,000 users; however, no one besides the executives received the message. The message was in the form of a bounced email with the subject "Undelivered Mail Returned to Sender."

If the executable was launched on the victim's system, it would connect to an IP address on TCP port 3460 using a hostname hosted at the dynamic DNS provider no-ip.org. (See the ThreatExpert report.)

According to the VirusTotal scan, only two vendors consider the file malicious, tagging it as a dropper.

Update: Steven Adair identified the executable as a variant of the Poison Ivy trojan that acts as a backdoor and lets the attacker fully control the infected system. For additional information, see the F-Secure write-up and page 28 of this whitepaper. This trojan uses the default mutex ")!VoqA.I4".

-- Lenny

Lenny Zeltser
Security Consulting - Savvis, Inc.

Lenny teaches a SANS course on analyzing malware.

The following list presents common information security mistakes and misconceptions, so you can avoid making them.

Security Policy and Compliance

• Ignore regulatory compliance requirements.
• Assume the users will read the security policy because you've asked them to.
• Use security templates without customizing them.
• Jump into a full-blown adoption of frameworks such as ISO 27001/27002 before you're ready.
• Create security policies you cannot enforce.
• Enforce policies that are not properly approved.
• Blindly follow compliance requirements without creating overall security architecture.
• Create a security policy just to mark a checkbox.
• Pay someone to write your security policy without any knowledge of your business or processes.
• Translate policies in a multi-language environment without consistent meaning across the languages.
• Make sure none of the employees finds the policies.
• Assume that if the policies worked for you last year, they'll be valid for the next year.
• Assume that being compliant means you're secure.
• Assume that policies don't apply to executives.
• Hide from the auditors.

Security Tools

• Deploy a security product out of the box without tuning it.
• Tune the IDS to be too noisy, or too quiet.
• Buy security products without considering the maintenance and implementation costs.
• Rely on anti-virus and firewall products without having additional controls.
• Run regular vulnerability scans, but don’t follow through on the results.
• Let your anti-virus, IDS, and other security tools run on "auto-pilot."
• Employ multiple security technologies without understanding how each of them contributes.
• Focus on widgets, while omitting to consider the importance of maintaining accountability.
• Buy expensive product when a simple and cheap fix may address 80% of the problem.

Risk Management

• Attempt to apply the same security rigor to all IT assets, regardless of their risk profiles.
• Make someone responsible for managing risk, but don't give the person any power to make decisions.
• Ignore the big picture while focusing on quantitative risk analysis.
• Assume you don't have to worry about security, because your company is too small or insignificant.
• Assume you're secure because you haven’t been compromised recently.
• Be paranoid without considering the value of the asset or its exposure factor.
• Classify all data assets as "top secret."

Security Practices

• Don't review system, application, and security logs.
• Expect end-users to forgo convenience in place of security.
• Lock down the infrastructure so tightly, that getting work done becomes very difficult.
• Say "no" whenever asked to approve a request.
• Impose security requirements without providing the necessary tools and training.
• Focus on preventative mechanisms while ignoring detective controls.
• Have no DMZ for Internet-accessible servers.
• Assume your patch management process is working, without checking on it.
• Delete logs because they get too big to read.
• Expect SSL to address all security problems with your web application.
• Ban the use of external USB drives while not restricting outbound access to the Internet.
• Act superior to your counterparts on the network, system admin, and development teams.
• Stop learning about technologies and attacks.
• Adopt hot new IT or security technologies before they have had a chance to mature.
• Hire somebody just because he or she has a lot of certifications.
• Don't appraise your manager of the security problems your efforts have avoided.
• Don't cross-train the IT and security staff.

Password Management

• Require your users to change passwords too frequently.
• Expect your users to remember passwords without writing them down.
• Impose overly-onerous password selection requirements.
• Use the same password on systems that differ in risk exposure or data criticality.
• Impose password requirements without considering the ease with which a password could be reset.

The above list of common security mistakes and misconceptions incorporates contributions from fellow ISC handlers. (Thanks!) If you'd like to print this list on a single page, you're welcome to use the PDF version from my site.

-- Lenny

Lenny Zeltser
Security Consulting - Savvis, Inc.

Lenny teaches a SANS course on analyzing malware.

SANS started its 2009 Log Management Survey. The survey is using the "surveymonkey" website and can be found here. If you are dealing with logs and log management, please take a few minutes to take the survey. The survey will run for a couple months, and results will be announced via a Webcast as well as during the SANS WhatWorks in Log Managment Summit in April.

SANS Log Manangement Survey

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute

Creating RFPs for security solutions and processing the responses is not an easy task. Having responded to a fair number of such RFPs, I found that many of them are created hastily, and don’t allow the issuer to benefit from quality responses.

Here's my list of the top 10 mistakes organizations make when crafting a security RFP:

1. Create the RFP in a silo, without considering input from stakeholders throught the organization.
2. Provide very little information about the infrastructure in scope for the security solution.
3. Use the RFP process in situations where it slows you down, without offering substantial benefits.
4. Avoid defining a criteria for objectively evaluating RFP responses.
5. Select the solution or vendor in advance, using the RFP to mark a checkbox.
6. Underestimate the time your staff needs to devote to processing RFP responses.
7. Don't define a process for allowing RFP responders to ask clarifying questions.
8. Don't ask detailed clarifying questions after receiving RFP responses.
9. Forget to define your business requirements, hoping that RFP responders will do that for you.
10. Issue the RFP before your organization is ready to make use of the requested solution.

If this is useful to you, you may also benefit from the longer "cheat sheet" I created for issuing RFPs specific to security assessments.

-- Lenny

Lenny Zeltser
Security Consulting - Savvis, Inc.

Lenny teaches a SANS course on analyzing malware.

As a follow-up to the story from yesterday on the BIND DNS server updates (as a result of the OpenSSL signature validation bug)... It is difficult to tell whether the default BIND9 configuration turns on DNSSEC support by default.  I reviewed the BIND documentation and the CHANGES file today.  It certainly appears that the default settings for DNSSEC have been recently changed in the 9.6.0b1 and 9.5.0a1 releases.  If you are running BIND DNS servers with DNSSEC, then you probably care that signatures check-out and you need to patch regardless of what the default settings are.  Otherwise, this isn't an exploitation bug and you don't need to patch immediately.