Over the last few days, Stuxnet has been covered extensively in the mass media. And it's been covered differently by different sources. "Iran", "Bushehr nuclear plant" and "cyber-weapon" are phrases which are already inexorably linked to Stuxnet. One of the main arguments behind the "Iranian" theory is that Iran is the epicentre of the epidemic, as it has the largest number of computers identified as being infected.
However, any estimates about the number of infected machines can only be based on the data which AV companies get from their clients' machines. And such data only comes from those countries where a company actually has clients. So if there aren't any clients, or the antivirus product in question isn't widely used, any estimates have to be regarded as having a serious margin of error.
As soon as we identified the vulnerability we informed Microsoft about the problem and they confirmed our findings. The vulnerability has been identified as “Print Spooler Service Impersonation Vulnerability” and rated “critical”. Today Microsoft released MS10-061, a patch which fixes this vulnerability. Analysis of the vulnerability shows that it’s computers with shared access to a printer which are at risk of infection. During analysis, we searched our collection for other malicious programs capable of using this vulnerability. Happily, we didn’t find anything. On top of all this, we've identified yet another zero-day vulnerability in Stuxnet's code, this time an Elevation of Privilege (EoP) vulnerability. The worm uses this to get complete control over the affected system. A second EoP vulnerability was identified by Microsoft personnel, and both vulnerabilities will be fixed in a security bulletin in the near future. The fact that Stuxnet uses four previously unidentified vulnerabilities makes the worm a real standout among malware. It’s the first time we’ve come across a threat that contains so many “surprises”. Add to this the use of Realtek and JMicron certificates, and remember that Stuxnet’s ultimate aim is to access Simatic WinCC SCADA systems. Stuxnet was undoubtedly created by professionals who’ve got a thorough grasp of antivirus technologies and their weaknesses, as well as information about as yet unknown vulnerabilities and the architecture and hardware of WinCC and PSC7. Together with Microsoft and other AV companies, so far we’ve spent more than two months looking at Stuxnet. We’ll be presenting our findings, including a detailed look at how the vulnerability works, at the end of the month at the Virus Bulletin conference.
We're raising our threat level by a notch. Not something that we do as often as we used to. There are several reasons for this decision, but one of them really stands out.
We've identified a worm called VBMania. This might not sound like anything much, but in contrast to most worms today, it spreads via email. Real old school. Additionally, it works on the the principle of "download and run".
The worm spreads by sending emails from the infected computer. The messages have a subject line of "Here you have" and random text such as "This is The Free Dowload Sex Movies,you can find it Here". Of course, the messages also include a link to a file on the Internet.
Click on the link, save and run the file and voila - your machine is infected.
In spite of this primitive propagation routine, the worm is pretty active, and currently sending out significant amounts of mail.
Because of this, and also because there's been a lot of news about this worm flying around, we've decided to raise the threat level with the aim of informing as many people as possible.
The worm's written in Visual Basic, and our products detect it proactively using heuristics as Suspicious:HEUR:Trojan.Win32.Generic.
Last night we also added signature detection (Trojan-Win32.Swisyn) which we're going to rename to Email-Worm.Win32.VBMania.
UPDATE:As of 1600 GMT, all the malicious worm files which were located on members.multimania.co.uk had been deleted. This means the worm won't be able to propagate further. However, infected computers will continue to send emails until they're disinfected.
While analysing the worm we also identified an earlier variant - Trojan.Win32.Swisyn.ajgd. It was first detected in August this year, had similar functionality, and was also spread from the member areas on members.multimania.co.uk and lycos.co.uk.
So far in our series about Stuxnet we’ve focussed on the main issue: the threat posed by the zero-day vulnerability in the processing of LNK files, and the fact that cybercriminals have somehow got their hands on digital certificates. What we haven’t done in any detail is look at the worm’s functionality.
Anyone following the story has probably already read about how the worm, in addition to replicating, attempts to gain access to industrial systems running WinCC from Siemens.
I can’t remember which journalist or antivirus researcher first mentioned power plants (some of which certainly do run WinCC) in connection with Stuxnet. Since then, the whole story’s taken on the air of a Hollywood movie, with dark and repeated murmurings of ‘attacks on industry’ and ‘inter-government espionage’.
Stuxnet does attempt to connect to the WinCC SCADA visualization system using the default password from Siemens. Part of the worm is a very interesting component, a dll, which acts as a wrapper for the original Siemens dll. It’s this wrapper that tries to connect to WinCC, redirecting the majority of the functions to the original dll, while emulating the remaining functions itself.
The functions are:
The module also contains several encrypted blocks of data – here’s an example of a decrypted block:
Siemens is currently conducting its own investigations and analysis of the malware. They’ve published official information about the incident, which reports one confirmed case of infection of a WinCC client in Germany.
From the report:
"Currently there is still only one known case where a customer's WinCC computer has been infected. The virus infiltrated a purely engineering environment of a system integrator, but was quickly eliminated. A production plant has not been affected so far."
"There is only one known case of infection in Germany. We are, at present, trying to find out whether the virus caused any damage."
Siemens also confirms that the worm is able to transmit process and production data, and that it attempts to establish a connection with the cybercriminals’ servers. At the moment, however, the servers are apparently inactive.
P.S. Siemens has just issued an update:
"Currently we know of two cases worldwide where a WinCC computer has been infected. A production plant has so far not been affected."
A few days ago we wrote about a new variant of the Stuxnet worm’s rootkit component, signed not with Realtek’s digital signature, but with one owned by JMicron. Costin posted about it in detail.
The media jumped on the news, and there was a lot of talk about “New worm variant discovered”. However, the situation isn’t quite as simple as the headlines made out.
There wasn’t a clear answer to the main question i.e. where’s the worm which the signed driver would have come from? The fact that the driver was created on 14 July could indicate that a new variant of the worm, potentially with new functionality, was out in the wild.
However, all of our attempts to find the dropper of the second rootkit driver (there are meant to be two) came to nothing.
Over the last few days, all the discussions have boiled down to two possible explanations: either cybercriminals stole the digital certificates using a Trojan, or it was the work of an insider. Our failure to find the dropper or second driver, though, makes the whole story all the more complicated.
So we decided to look at some statistics: how many times has the Kaspersky Security Network detected Rootkit.Win32.Stuxnet.c (the driver signed with the JMicron certificate)? The numbers are discouraging – since 20 July, the module’s been detected all of twice, once in Russia and once in Ukraine. These figures look pretty silly when compared to the detection statistics for the rootkit component signed with the Realtek signature.
Verisign has now revoked the JMicron certificate, making it invalid. Our whitelisting database contained 124 programs which had been signed using the certificate – all of them, of course, were clean.
At the moment, I’m not drawing any conclusions about the origins of this mythical driver. I don’t doubt that it is a modified variant of mrxcls.sys. We’re still looking for whatever is launching it, or computers which it’s infected.
If we look at the stats relating to the initial Stuxnet variant, they show epidemics in India, Iran, and Indonesia. The number of infected computers increases by about a thousand every day, and this is only what our monitoring systems show us. In other words, it’s merely the tip of the iceberg.
Apart from the three countries hit by Stuxnet, Azerbaijan and Afghanistan have also been heavily affected, with more than a thousand infected machines each.
The geographical spread of the Trojan, together with the “missing” variant, has given us all a lot to think about.
The geographical distribution of Stuxnet infections is just as interesting as the Trojan itself. We detect the rootkit component (the signed drivers) as Rootkit.Win32.Stuxnet, and the other files as Trojan-Dropper.Win32.Stuxnet.
Over the last four days, KSN has identified Trojan components (although the program should really be thought of as a worm, as it spreads via removable storage media) on more than 16,000 computers around the world. A map with infection statistics shows three countries (all starting with the letter I!) are at the centre of the epidemic - Iran, India and Indonesia.
Having finished episode 1 on a botanical note, let’s continue our trip into the undergrowth by taking a look at the Stuxnet Trojan’s digital signature.
Digitally signed malware is a nightmare for antivirus developers. Digital signatures have a lot riding on them – they act as proof that an application is legitimate, and are a key concept in information security. They also have considerable influence on how effective a security solution is – it’s no secret that a digitally signed file will be “trusted” by security software and will often automatically be whitelisted.
However, sometimes cybercriminals do somehow manage to get their hands on their very own code signing certificate/ signature. Recently, we’ve been seeing regular instances of this with Trojans for mobile phones. When we identify cases like this, we inform the appropriate certification authority, the certificate is revoked, and so on.
However, in the case of Stuxnet, things look very fishy indeed. Because the Trojan isn’t signed with a random digital signature, but the signature of Realtek Semiconductor, one of the biggest producers of computer equipment.
Recalling a certificate from a company like this simply isn’t feasible – it would cause an enormous amount of the software which they’ve released to become unusable.
A few days ago, colleagues from the Belarussian antivirus company VirusBlokAda (VBA) announced they’d come across an interesting new malicious program. They published a short analysis of the program which highlighted two innovations:
1. Using lnk files to launch files from USB storage devices, a method which hasn’t been used before.
2.The malicious driver has a valid digital signature from Realtek.
The VBA article is well worth taking a look at – great research, guys!
Over here at Kaspersky, we’ve also taken a look at the malware, and we’ve also come up with a few interesting things.
The vulnerability in the Windows Help and Support Center (CVE-2010-1885) has been a constant irritation to antivirus experts for the third week in succession. I will try to provide an analysis of the problem with the help of KSN.
We first detected samples of the exploit on 10 June and at the time of writing, over 14,000 attacks using CVE-2010-1885 have been registered.
The graph above shows the number of detections per day.
However, the most important feature is the figure indicating the exploit’s distribution on the Internet. According to KSN, on 2 July, 2010 the total number of websites hosting the exploit averaged 300.
Happy Friday 13th!
Friday 13th! If you're at all superstitious, today is bad news. But for those of us in the antivirus industry, Friday 13th is a special day.
It's not an officially recognized holiday, and of course we're not taking the day off: we're here 24/7/365. But Friday 13th is when we remember when and why the antivirus industry really started...
22 years ago, in October 1987, a new file virus which infected COM and EXE files was identified in Jerusalem. Like similar, earlier programs, it was able to self-replicate, but it also had an additional, malicious payload which triggered on Friday 13th: when an attempt was made to run any program, the program file would be deleted, and DOS would say that the file couldn't be found. This meant that any file called using the Exec function got deleted.
The virus spread widely (even though neither the Internet or email had really caught on at that stage) on disks which got passed around and BBS.
13th May 1998 was D-day: thousands of messages about the virus started pouring in from around the world, and particularly from the US, Europe, and the Middle East. Jerusalem had become one of the first MS-DOS viruses to cause a pandemic.
The virus had managed to spread unnoticed to thousands of computers: antivirus software wasn't commonly used, and lots of people simply didn't believe that computer viruses were real. And it was in the same year that Peter Norton, a guru of the computing world, said that computer viruses were an urban legend, comparing them to the crocodiles which supposedly live in the sewers of New York. (This bold statement didn't deter Symantec, however, from developing its own antivirus software – Norton Anti-Virus.)
It was a watershed: new companies developing antivirus software started appearing, most of them of the "two men and a dog" variety. The antivirus programs themselves were nothing more than the simplest scanners which used contextual search to detect unique strings of virus code. "Immunizers" were popular too; these modified programs so that malware would think the programs were already infected, and not "re-infect" them.
Jerusalem's malicious payload went beyond deleting files: dozens of other viruses appeared which also had payloads designed to trigger on Friday 13th. Not surprisingly, those in the computer world started to associate Friday 13th with viruses; some people thought it was safer not to switch a computer on when the fateful date cycled round, and some altered the date on their machines, to the 12th or the 14th. The virus writers picked up on this and started playing the same game, producing "Thursday 12th" and "Saturday 14th" viruses.
As for us – well, today we want to wish everyone in the antivirus industry a happy Friday 13th! Yes, we have our differences - in ideology, philosophy, opinion and market share. But let's remember what we have in common, and why we're in this game in the first place. If we can't do that – then what are we doing here?