Further to Pierre-Marc’s post on the 25th December about the resemblances between Waledac and Storm, I notice that Steven Adair of Shadowserver has been blogging some very nice notes on much the same topic. Well worth a look.
David Harley
Lots of fuss about the paper presented at the Chaos Communication Congress in Berlin yesterday by Alexander Sotirov et al. The paper describes a proof-of-concept attack using a weakness in the MD5 cryptographic hash function to create a rogue Cerification Authority certificate using a hash collision (essentially, two messages with the same MD5 hash value). The promotion of the paper’s title from “Making the theoretical possible” to “MD5 considered harmful today: Creating a rogue CA certificate” gives some idea of how seriously the issue is being taken. Not unreasonably, given the author’s claim that "This certificate allows us to impersonate any website on the Internet, including banking and e-commerce sites secured using the HTTPS protocol."
Is it serious? Certainly. It’s likely that there will be real-life attacks using similar techniques to impersonate secure websites. Perhaps the sanest summary I’ve seen to date is by Johannes Ullrich at the SANS Internet Storm Center (an excellent resource, by the way). Ullrich points out that the continuing use of a known weakness in MD5 by CAs poses a real problem that can’t be fixed by changing your browser, for example. However, limiting the number of CAs you trust is likely to help, as will keeping an eye on vendor announcements. Here are some currently flagged on the ISC page.
Mozilla:
http://blog.mozilla.com/security/2008/12/30/md5-weaknesses-could-lead-to-certificate-forgery/
ISC intend to flag other vendor announcements as they find them.
David Harley BA CISSP FBCS CITP
Director of Malware Intelligence
Here’s the second instalment of the "ten ways to dodge cyberbullets" that I promised you.
Keep applications and operating system components up-to-date with automated updates and patches, and by regularly reviewing the vendors’ product update sections on their web sites.
This point is particularly relevant right now, given the escalating volumes of Conficker that we’re seeing currently.Win32/Conficker is a network worm that propagates by exploiting a recently-discovered vulnerability in the Windows operating system (MS08-67). The vulnerability is present in the RPC sub system and can be exploited remotely by an attacker. The attacker can perform his attack without valid user credentials. As we mention in our Threat Report for November, Conficker tries to download additional malware likely to be connected with adware, typically the FakeAlert, Wigon families): it avoids infecting Ukrainian PCs. In addition, it shuts down the windows firewall and starts an http server on a random port.
Sometimes, it seems that the whole world assumes that the only vendor that suffers from vulnerabilities in its operating system and other software is Microsoft. To see how misleading claims like this can be, check out the weekly “Consensus Security Vulnerability Alert” published by SANS (see http://portal.sans.org), which summarizes some of the most important vulnerabilities and exploits identified in the preceding week. Even during a week that includes “Patch Tuesday”, you’ll typically find that problems are flagged with a frightening number of applications from other vendors. Certainly, any system administrator should consider making use of this resource.
While ESET has effective detection for Conficker, it’s important for end users to ensure that their systems are updated with the Microsoft patch, which has been available since the end of October, so as to avoid other threats using the same vulnerability. Information on the vulnerability itself is available here.
David Harley BA CISSP FBCS CITP
Director of Malware Intelligence
We’re closing in on the end of 2008 and about to start 7D9, or 2009 for those who do not speak hex. I thought it might be a good time to remind you to change your passwords. There are some important things to remember about passwords. Despite the IT policies that are prevalent throughout the world, really great passwords can be made that do not use upper and lower case letters with numbers and special characters. The really important thing is length. Actually, “The really important thing is length” is a much better password than $kW3P*v9.
There are several reasons why the sentence above is a better password. To begin with, you can remember it so you don’t have to write it down and keep it handy. Even more importantly, it will take a computer far longer to crack the sentence (unless it knows to look for a sentence) than the 8 character password with all of the funny characters, etc.
Adding numbers and special characters does help, but not as much as length does. There is a time when the special characters do become important. That is when you are limited to a short password. For example, the web site “Friendster.com” has a ridiculous policy of only allowing a 10 character password. In a case like this, you want upper case letters, lower case letters, numbers, and special characters. Actually, you want Friendster to get a clue, but you have to take your security into your own hands sometimes.
Reusing passwords can be really bad news. You don’t want to use the same password for your computer log on as for your bank. Important information should be protected with unique and strong passwords.
Changing your password regularly is important as well. How frequently you change your password will depend upon how important the information you are protecting is. Generally, once every three months is a really good idea. That way if your password is cracked, by the time a computer has cracked a good strong password you will have already changed it!
One of the problems with multiple passwords is remembering them all. Tools like Cygnus Password Corral (http://cygnusproductions.com/freeware/pc.asp) can be really helpful. Just remember that you need to keep it on a very safe computer and back up that password file!!!
One of my favorite tricks for creating passwords that I can easily remember and are nice and secure is to make a math equation. Something like “1hundred+5=Threehundred” is long enough to be secure, has a nice mix of characters, and the wrong answer is silly enough to be memorable!
So, make your New Year a little more secure and change those passwords!
It’s that time of year when everyone wants a top ten: the top ten most stupid remarks made by celebrities, the ten worst-dressed French poodles, the ten most embarrassing political speeches, and so on. Our research team came up with a few rather more serious ideas, most of which are considered at some length in our about-to-be-published Annual Global Threat report and November Threatsense report, but we thought it might be nice to post some of the information in one or two of those top ten lists here for those who may find the length of the full reports a little daunting, as well as a taster for those who don’t. Rather than simply reproduce those lists, we’ll consider individual items at more length over the next few days.
Perhaps one of the more useful ideas that was tossed around was a top ten of things that people can do to protect themselves against malicious activity. This is the item that we pretty much all agreed should be top of the list.
Disable Autorun in Windows: this facility is consistently exploited by the class of malware ESET detects as INF/Autorun, among other threats. We’ve been considering this issue in detail for quite a while, now: for instance, in Randy Abrams’ blog here. That class of malware has been consistently at or near the top of our monthly worldwide top ten reported threats as long as I’ve been tracking them. Don’t assume, though, that that single precaution will save you from every example of that type of threat. Most malware uses more than one technique to infect targeted systems.
More later.
David Harley BA CISSP FBCS CITP
Director of Malware Intelligence
Well, not so much about punishment, but I’m sitting in the lounge with Andrew Davies’s version of Dr. Zhivago in the background, so I’m in a Russian mood…
My colleague Jeff Debrosse, Director of Research in our San Diego office, drew my attention to the latest FBI challenge at http://www.fbi.gov/page2/dec08/code_122908.html. Like many people in this business, I’m fascinated by encryption and decryption, but I don’t have a particular talent for it, so I probably won’t attempt the challenge. I was interested enough to follow this link, though, which is a short primer on "Analysis of Criminal Codes and Ciphers" by Daniel Olson, a cryptanalyst forensic examiner with the bureau. As an introduction to some basic cryptographic techniques with some real-life (criminal) applications, it looks very readable. If you’re interested in something a bit more comprehensive but not particularly technical/mathematical, Simon Singh’s "The Code Book" is also very readable. Bruce Schneier has written a couple of books that are still practical rather than theoretical, if you fancy something with a bit more meat to it…
Speaking of Jeff Debrosse, he was recently featured on Fox 5 News, talking about cybercrime. We posted a link here. Nice one, Jeff. 
And since we’re blowing our own trumpets here, thank you Paul Lilly for a very positive review of ESET Smart Security in MaximumPC. 
David Harley BA CISSP FBCS CITP
Director of Malware Intelligence
I’ve just picked up a comment to a previous blog that pointed to what I presumed to be a malicious URL. We’re grateful for all such information, but for obvious reasons, we won’t approve comments that point to malicious code!
You can find information in our knowledgebase here about how to forward malware samples or false positive samples to our labs: it doesn’t specifically mention malicious URLs, but you can send those to the same address.
It’s not that we’re not willing to pass on information to the labs ourselves (and I’ve already forwarded the link), but it’s much more effective for you to send the information direct. As a case in point, it turns out that by the time I saw this comment and forwarded the link, our products had already been updated to detect this particular binary.
Thanks!
David Harley CISSP FBCS CITP
Director of Malware Intelligence
This is a sad item for Christmas Day morning. Castlecops have been making considerable efforts to fight crime on the Internet in many areas (surviving many an attack from the bad guys in the process) for a long time, but seem to have suspended the service on 23rd December. I hope there’s nothing more sinister behind this decision other than the difficulty of maintaining the service in the light of their other commitments, and wish Paul and Robin the best of luck for the future.
On a happier note, the ESET Research team would like to wish a very happy Christmas and a secure New Year to all our colleagues at ESET, our partners, our colleagues in the security industry, and all of you. Well, most of you. To the bad guys we know read this blog from time to time, we wish everything they wish to us…
David Harley CISSP FBCS CITP
Director of Malware Intelligence
Yesterday, we started to receive reports of emails pretending to carry links to holiday cards. These emails contain a link that points to a file named ecard.exe. Of course, this executable is not a seasonal holiday card but malware. The reason this wave of malware has attracted our attention is that it is very similar to the Storm Worm attacks we were seeing last year.
Although this attack uses fast-flux to make it harder to trace its web servers and a redirection page very similar to those used by Storm last year, this is not the resurrection of the Storm botnet. Analysis of the binary proves it to be different to Storm. It was programmed using a different programming language and includes different functionalities. This malware, detected as a variant of Win32/Waledac by ESET Antivirus, has no peer-to-peer capabilities and uses an open-source packer instead of the custom packers used by Storm. Also, the Waledac threat has cryptographic capabilities that were not present in Storm.
What we are observing today is proof that malware authors are learning from each other’s errors and successes. After seeing that Storm was able to infect thousands of systems last year with Christmas-related social engineering, the criminals behind other malware families are now trying to emulate that success.
Pierre-Marc Bureau
Researcher
I promised you some more thoughts on the AVAR conference. Randy Abrams and I put together a paper on user education for the conference (it should be up on our White Papers page quite soon) about the argument between the two main camps in security thinking on the topic. You could sum it up as "If user education was ever going to work, it would have worked by now!" versus "You can’t fix social problems with technological solutions!" And I guess you could sum up our position as "Since neither approach is going to eradicate security breaches, why not integrate the best elements of both approaches into a multi-layered strategy?" (Not as simple as it sounds, but it’s worked for both of us in our previous careers.)
While Randy was doing the presentation (it’s called delegation 
) I had one of those moments of blinding clarity. The trouble with these instances of dazzling insight is that sometimes they turn out to be about suddenly realizing something that the rest of the world has taken for granted since the Renaissance, but I’ll share it with you anyway.
I’ve spent a great deal of my working life in user support: not so much manning (personning?) the helpdesk phone – though I’ve a fair amount of flying time there, too – but second and third line support. You can certainly look at user education and training as a close relative and in some contexts a subset of user support functionality (no, that isn’t the insight).
There are, it occurs to me, two ways of approaching user support (not that they’re mutually exclusive): for each trouble ticket with your name on it you can take whatever technical measures are appropriate almost without reference to the end-user. That way, you often get a quick fix (re-install, disinfect, replace a malfunctioning component, reset a password) and you can move on quickly to the next job. Users are generally happy because you aren’t expecting any significant effort from them. But what if it’s a problem to which they contributed in some way? All they’ve learned is that if the problem reoccurs, you’ll come back and sort it again. You’ve treated the symptom, not the disease.
The alternative is to look at each trouble ticket (logged request for support) as (potentially) a learning experience. If the user has some understanding of what the problem is, he or she may also realize that there’s a better way of approaching the task that originally sparked the problem. Involving the customer more directly in the problem-solving process may add significantly to each incident resolution, but that’s not a problem if it results in some reduction of the overall volume of incidents. This is social engineering in its more general sense, persuading people to do what’s good for them and the groups to which they belong, not what’s good for some blackhat Svengali.
Of course, some users will resent any attempt to educate them: they will regard it as your job to fix anything they break, just as some AV users expect that because they’ve installed AV, they should be able to click on anything they like without thinking about it. Well, teachers don’t manage to educate all their pupils, either, but we haven’t given up founding schools and universities…
David Harley CISSP FBCS CITP
Director of Malware Intelligence
