Stuxnet Missing Link Found, Resolves Some Mysteries Around the Cyberweapon

Cross-posted from WIRED.

Ahmadinejad-at-Natanz-in-2008

As Iran met in Kazakhstan this week with members of the UN Security Council to discuss its nuclear program, researchers announced that a new variant of the sophisticated cyberweapon known as Stuxnet had been found, which predates other known versions of the malicious code that were reportedly unleashed by the U.S. and Israel several years ago in an attempt to sabotage Iran’s nuclear program.

The new variant was designed for a different kind of attack against centrifuges used in Iran’s uranium enrichment program than later versions that were released, according to Symantec, the U.S-based computer security firm that reverse-engineered Stuxnet in 2010 and also found the latest variant.

The new variant appears to have been released in 2007, two years earlier than other variants of the code were released, indicating that Stuxnet was active much earlier than previously known. A command-and-control server used with the malware was registered even earlier than this, on Nov. 3, 2005.

Like three later versions of Stuxnet that were released in the wild in 2009 and 2010, this one was designed to attack Siemens PLCs used in Iran’s uranium enrichment program in Natanz.

But instead of changing the speed of spinning centrifuges controlled by the PLCs, as those later versions did, this one focused on sabotaging the operation of valves controlling the flow of uranium hexafluoride gas into the centrifuges and cascades — the structure that connects multiple centrifuges together so that the gas can pass between them during the enrichment process. The malware’s goal was to manipulate the movement of gas in such a way that pressure inside the centrifuges and cascade increased five times the normal operating pressure.

“That would have very dire consequences in a facility,” says Liam O’Murchu, manager of security response operations for Symantec. “Because if pressure goes up, there’s a good chance the gas will turn into a solid state, and that will cause all sorts of damage and imbalances to the centrifuges.”

The new finding, described in a paper released by Symantec on Tuesday (.pdf), resolves a number of longstanding mysteries around a part of the attack code that appeared in the 2009 and 2010 variants of Stuxnet but was incomplete in those variants and had been disabled by the attackers.

The 2009 and 2010 versions of Stuxnet contained two attack sequences that each targeted different models of PLCs made by Siemens being used in Iran’s uranium enrichment plant — the Siemens S7-315 and S7-417 models of PLC.

In these later variants of Stuxnet, however, only the 315 attack code worked. The 417 attack code had been deliberately disabled by the attackers and was also missing important blocks of code that prevented researchers from determining definitively what it was designed to do. As a result, researchers have long guessed that it was used to sabotage valves, but couldn’t say for certain how it affected them. There were also mysteries around why the attack code was disabled — was it disabled because the attackers had failed to finish the code or had they disabled it for some other reason?

The 2007 variant resolves that mystery by making it clear that the 417 attack code had at one time been fully complete and enabled before the attackers disabled it in later versions of the weapon. And because the 2007 variant only contained the 417 attack code — with no code attacking the Siemens 315 PLC — it appears that the attackers disabled the 417 code in later versions because they wanted to change their tactics, dropping their focus on sabotaging the valves in order to focus instead on sabotaging the spinning centrifuges.

Natanz_Satellite2Symantec discovered the 2007 variant a few months ago during a routine search of its malware database while looking for files that matched patterns of known malware.

Though the variant was only recently found, it had been in the wild at least as early as Nov. 15, 2007, when someone uploaded it to VirusTotal for analysis. VirusTotal is a free online virus scanner that aggregates more than three-dozen brands of antivirus scanners and is used by researchers and others to determine if a file discovered on a system contains signatures of known malware. It’s not known who submitted the sample to VirusTotal or in what country they were based, but Symantec believes the 2007 version was very limited in its reach and likely only affected machines in Iran.

Until now, the first known variant of Stuxnet uncovered was released in June 2009, followed by a second variant in March 2010 and a third in April 2010. Researchers always suspected that other variants of Stuxnet existed, based on the version numbers the attackers gave their code, as well as other clues.

The June 2009 variant, for example, was labeled version 1.001. The March 2010 variant was 1.100, and the April 2010 variant was 1.101. The gaps in version numbers suggested that other versions of Stuxnet were developed, even if they were not released into the wild. That theory bore out when the researchers discovered the 2007 variant, which turned out to be version 0.5.

Though Stuxnet 0.5 was in the wild as early as 2007, it was still active when the June 2009 version was released. Stuxnet 0.5 had a stop date of July 4, 2009 coded into it, which meant that after this date it would no longer infect new computers, though it would still continue to sabotage machines it had already infected, unless it got replaced with a new version of Stuxnet. The 2007 version was also programmed to stop communicating with command-and-control servers on Jan. 11, 2009, five months before the next version of Stuxnet was released. It’s possible that when the June 2009 version was released, which had the ability to update older versions of Stuxnet via peer-to-peer communication, it replaced the older 2007 version on infected machines.

Stuxnet 0.5 was much less aggressive than later versions in that it used fewer spreading mechanisms. The researchers found no zero-day exploits in the malware to help it spread, which is probably one reason it never got caught.

By contrast, the 2010 variants of Stuxnet used four zero-day exploits as well as other methods that caused it to spread wildly out of control to more than 100,000 machines in and outside of Iran.

Stuxnet 0.5 was very surgical and spread only by infecting Siemens Step 7 project files — the files that are used to program Siemens’ S7 line of PLCs. The files are often shared among programmers, so this would have allowed Stuxnet to infect core machines used to program the 417 PLCs at Natanz.

If it found itself on a system that was connected to the internet, the malware communicated with four command-and-control servers hosted in the U.S., Canada, France and Thailand.

The domains for the servers were: smartclick.org, best-advertising.net, internetadvertising4u.com, and ad-marketing.net. All of the domains are now down or registered to new parties, but during the time the attackers used them, they had the same home page design, which made them appear to belong to an internet advertising firm called Media Suffix. A tag line on the homepage read, “Deliver What the Mind Can Dream.”

Like later versions of Stuxnet, this one had the ability to deliver updates of itself to machines that were not connected to the internet, using peer-to-peer communication. Though later versions used RPC for the peer-to-peer communication, this one used Windows mailslots. All the attackers had to do was use the command-and-control server to update the code on one infected machine that was connected to the internet, and others on the local internal network would receive the update from that machine.

Stuxnet-CC-Home-Page

Once Stuxnet 0.5 found itself on a 417 PLC, and determined that it had found the right system, the attack proceeded in eight stages, sabotaging 6 out of 18 centrifuge cascades.

In the first part, Stuxnet simply sat on the PLC watching normal operations in the cascades for about 30 days and waiting for the systems to reach a certain state of operation before the attack progressed.

In the next part, Stuxnet recorded various data points while the cascades and centrifuges operated normally, in order to replay this data to operators once the sabotage began and prevent them from detecting changes in the valves or gas pressure.

Each cascade in Natanz is organized in 15 stages or rows, with a different number of centrifuges installed in each stage. Uranium hexafluoride is pumped into cascades at stage 10, where it spins at high speed for months. The centrifugal force causes slightly lighter U-235 isotopes in the gas (the desired isotope for enrichment) to separate from heavier U-238 isotopes.

Centrifuge-Stages_SymantecThe gas containing the concentration of U-235 is then siphoned out of the centrifuges and passed to stage 9 of the cascade to be further enriched, while the depleted gas containing the concentration of U-238 isotopes is diverted to cascades in stage 11. The process repeats for a number of stages, with the enriched uranium becoming more concentrated with U-235 isotopes at each stage until the desired level of enrichment is achieved.

There are three valves on a cascade that work in unison to control the flow of gas into and out of centrifuges, as well as auxiliary valves that control the flow of gas into and out of each stage in a cascade and into and out of the cascade itself.

When the sabotage kicked in, Stuxnet closed and opened various centrifuge and auxiliary valves to increase the gas pressure, thereby sabotaging the enrichment process. Stuxnet closed valves on six out of 18 cascades and modified other valves on randomly chosen individual centrifuges to prevent operators from detecting a pattern of problems. In the final step of the attack, the sequence was reset to begin the attack over again at the first stage.

It’s long been suspected by some experts that Stuxnet was already sabotaging cascades at Natanz sometime between late 2008 and mid-2009. The new finding from Symantec supports that theory.

Stuxnet 0.5 was looking for a system in which cascade modules were labeled A21 through A28. Natanz has two cascade halls — Hall A and Hall B. Only Hall A was operating in 2008 and 2009 when Stuxnet would have been active on infected machines.

Hall A is divided into cascade rooms that are labeled Unit A21, Unit A22, etc up to Unit A28. Iran began its installation of centrifuges in two rooms in Hall A in 2006 and 2007 — Unit A24 and Unit A26 — and later expanded to other rooms. In February 2007, Iran announced that it had begun to enrich uranium at Natanz.

According to reports released by the UN’s International Atomic Energy Agency, which monitors Iran’s nuclear program, by May 2007, Iran had installed 10 cascades, consisting of a total of 1,064 centrifuges, in Hall A. By May of 2008, Iran had 2,952 centrifuges installed, and Iranian President Mahmoud Ahmadinejad announced plans to increase the number of centrifuges to 6,000. The numbers did increase throughout 2008 and early 2009, with gas being fed into them shortly after they were installed. But the number of cascades that were being fed gas and the amount of gas being fed began to drop sometime between January and August 2009 when Iran appeared to be having problems with some of its cascades. In late 2009, IAEA inspectors noticed that technicians at Natanz were actually removing centrifuges from cascades and replacing them with new ones. All of this would seem to coincide with the timing of Stuxnet.

ISIS-chartOne final interesting detail of note about the new variant — during the installation process of Stuxnet 0.5, the malware created a driver file that caused a forced reboot of a machine 20 days after the malware infected it. It did this by generating a BSoD (Blue Screen of Death) — the infamous blue screen that appears on Windows machines when they crash.

Stuxnet was first discovered in June 2010 because some machines in Iran on which it was installed kept crashing and rebooting. Researchers were never able to determine why those machines crashed and rebooted, because other machines infected by Stuxnet did not respond in this way.

Though the version of Stuxnet found on those machines was not Stuxnet 0.5, it raises the possibility that multiple versions of Stuxnet might have infected those machines even though only one was recovered when they were examined. O’Murchu thinks it’s unlikely, however, that VirusBlokAda — the antivirus firm that first discovered Stuxnet — would have missed another variant on the machines.

Internet Explorer 10 for Windows 7 [Download Links]

Internet Explorer 10 is available worldwide in 95 languages for download today.

Read more in IE Blog: http://blogs.msdn.com/b/ie/archive/2013/02/26/ie10-for-windows-7-globally-available-for-consumers-and-businesses.aspx

ie10_start

Download Links:

x86: http://www.microsoft.com/en-us/download/details.aspx?id=36808
x64: http://www.microsoft.com/en-us/download/details.aspx?id=36806
Other (Non-English) Languages: http://windows.microsoft.com/en-us/internet-explorer/downloads/ie-10/worldwide-languages

Doc blocker : Oxford University blocked Google Docs

ox_small_cmyk_posFor about two and a half hours on Monday, students at Oxford University couldn’t access Google Docs after the University’s Computing Services team decided to take “extreme action” to halt phishing attacks and also to put pressure on Google.

Robin Stevens of OxCert explained in a blog post that, in the past, Google has been slow to respond to requests to help the university. The university’s problem is that phishers are frequently using Google Docs to present phishing forms to its users, with a legitimate domain shown to the user and not detectable by firewalls as Google traffic is over SSL. If phishing mail directing users to pages like this gets past the defenses, it is hard to detect and respond to.

Google’s security team have pointed the university at the “Report Abuse” button at the bottom of the Docs pages, but this takes time, at least a day or two and sometimes weeks, before Google respond. By that time the phishing attack is long gone; any users who would have been fooled will have most likely clicked a link within hours of the dubious mail arriving.

On Monday afternoon, the security team at Oxford were seeing multiple phishing incidents taking place and that tipped things over the edge; after considering the impact on legitimate business, it blocked Google Docs to prevent the phishing attacks deploying their information extracting forms. Stevens says the impact was actually greater on legitimate business than expected due to Google’s tight integration of Docs with other services, so, after two and a half hours, the restrictions were lifted.

He hopes that the temporary block will at least draw attention within the university to the dangers of phishing. He also hopes that Google will, with the resources at its disposal, find some way to automate responses to abuse reports. He closes saying “Google may not themselves be being evil, but their inaction is making it easier for others to conduct evil activities using Google-provided services.”

Source: http://h-online.com/-1806280

Dropbox Makes PDF Viewing Less Painful, Adds Push Notifications For Shared Folders

Dropbox-Logo-BGJust a few days after adding a new set of features to Dropbox for Teams, the cloud storage company rolled out a new version of its iOS application which introduces a few useful additions as well. For starters, it has added an improved PDF viewer, which lets you navigate to any page in the document by tapping on the thumbnail. It’s rather awesome, in fact. The update also introduces push notifications for folders shared with you – a feature that’s now available on Android, too.

dropbox-pdf-viewerThe revamped PDF viewer will be particularly welcome for business users, as it not only offers the multi-page layout for easier navigation, it lets you search for keywords or phrases in the PDF file, too. An interesting side note on this – Dropbox is actually using a paid, third party component called PSPDFKit for the viewer. Dropbox’s Stephen Poletto shared this news on Twitter earlier today.

Another new addition which will again appeal to professionals on the service, is the ability to now sort files by the date they were modified – that’s handy for those using shared folders as they collaborate on files that are under revision.

A small thing, perhaps, in the grand scheme of things, but one that’s going to make life easier on a large number of users.

It’s also shows that Dropbox is thinking about the kind of things its business users need. The little pain points that, when combined, can add up to an overall poor experience.

The push notifications option will alert users when someone shares a folder with them. This feature will be handy for both consumers and enterprise alike. While it’s new to Android and iOS, the PDF viewer has not yet made its way to Android at this time. That should change soon, though, as Dropbox tries to keep its platform releases relatively close together.

The updated app is here on iTunes, and the Android version is here.

Credit: TechChurch

Facebook Got Hacked Last Month and Is Just Telling You Now

Cross-posted from Gizmodo:

facebook_logoFacebook just announced that it was hacked last month in a short statement on its website. Apparently, an unknown number employees visited a compromised developer site and were infected with malware. Facebook’s being very cagey about all this, but we’ve been able to scrounge up some details.

According to the statement, the company reacted swiftly with an investigation and remediation following the “sophisticated attack.” The company won’t say which law enforcement agencies it’s working with. It claims no user data was compromised.

What a surprise, Facebook waited until the end of the day on a Friday to tell us about an oopsies.

Here’s the full statement from the company.

Last month, Facebook Security discovered that our systems had been targeted in a sophisticated attack. This attack occurred when a handful of employees visited a mobile developer website that was compromised. The compromised website hosted an exploit which then allowed malware to be installed on these employee laptops. The laptops were fully-patched and running up-to-date anti-virus software. As soon as we discovered the presence of the malware, we remediated all infected machines, informed law enforcement, and began a significant investigation that continues to this day. We have no evidence that Facebook user data was compromised in this attack

We’ve reached out to the company for additional comment regarding the nature of the hack and other details. We’ll update when we hear back. [Facebook]

Facebook responded to our request for comment with the following. The company says it isn’t commenting further at this time.

We were able to investigate user data compromise [sic] by forensic analysis on the affected devices and infrastructure.

New Adobe Vulnerabilities Being Exploited in the Wild

adobe readerAdobe posted a vulnerability report warning that vulnerabilities in Adobe Reader and Acrobat XI (11.0.1) and earlier versions are being exploited in the wild. Adobe is currently investigating this issue.

According to the FireEye blog posted earlier today, the malicious file arrives as a PDF file. Upon successful exploitation of the vulnerabilities, two malicious DLL files are dropped.

Symantec detects the malicious PDF file as Trojan.Pidief and the two dropped DLL files as Trojan Horse.

We are currently investigating the possibility of further protections for these vulnerabilities and will provide an update to this blog when possible.

A subsequent advisory posted by Adobe indicates the following versions of Adobe Reader and Acrobat are vulnerable:

  • Adobe Reader XI (11.0.01 and earlier) for Windows and Macintosh
  • Adobe Reader X (10.1.5 and earlier) for Windows and Macintosh
  • Adobe Reader 9.5.3 and earlier 9.x versions for Windows and Macintosh
  • Adobe Acrobat XI (11.0.01 and earlier) for Windows and Macintosh
  • Adobe Acrobat X (10.1.5 and earlier) for Windows and Macintosh
  • Adobe Acrobat 9.5.3 and earlier 9.x versions for Windows and Macintosh

Opera Switches to WebKit and Chromium

After many years of dealing with site compatibility issues, Opera found the solution: it will switch from its proprietary rendering engine (Presto) to WebKit and will be powered by Chrome’s open source version, Chromium.

“Presto is a great little engine. It’s small, fast, flexible and standards compliant while at the same time handling real-world web sites. It has allowed us to port Opera to just about any platform you can imagine. (…) It was always a goal to be compatible with the real web while also supporting and promoting open standards. That turns out to be a bit of a challenge when you are faced with a web that is not as open as one might have wanted. Add to that the fact that it is constantly changing and that you don’t get site compatibility for free (which some browsers are fortunate enough to do), and it ends up taking up a lot of resources – resources that could have been spent on innovation and polish instead,” explains an Opera employee.

“For all new products Opera will use WebKit as its rendering engine and V8 as its JavaScript engine. It’s built using the open-source Chromium browser as one of its components. Of course, a browser is much more than just a renderer and a JS engine, so this is primarily an ‘under the hood’ change. Consumers will initially notice better site compatibility, especially with mobile-facing sites – many of which have only been tested in WebKit browsers. The first product will be for Smartphones, which we’ll demonstrate at Mobile World Congress in Barcelona at the end of the month. Opera Desktop and other products will transition later,” mentions Bruce Lawson.

The problem with Opera is that it has a low market share on the desktop (about 1-2%) and not many web developers bother to test their sites in Opera. Google’s sites have always had issues in Opera and most Google web apps don’t officially support Opera (check the system requirements for Google Drive). Gmail’s help center actually mentions that “We don’t test Opera, but believe it works with all of Gmail’s features.” Probably Google doesn’t want to allocate resources for testing sites in a desktop browser that’s not popular, but it has a completely different rendering engine.

google-docs-in-opera

In a perfect world, browsers and sites would just follow the standards and everything would work well, but it takes time to create the standards and browsers implement their own version in the meanwhile. Not to mention that browsers have all kinds of quirks.

Google launched Chrome in 2008 and one of the reasons why it chose WebKit was that “we knew we didn’t want to create yet another rendering engine. After all, web developers already have enough to worry about when it comes to making sure that all users can access their web pages and web applications.”

WebKit started in 2001 as an Apple fork of KDE’s KHTML engine, it was used to build Safari, a few years later it was open sourced and Nokia ported WebKit to Symbian. WebKit is now the most popular mobile rendering engine, since it powers Safari Mobile and all iOS browsers (other than thin clients like Opera Mini), Android’s stock browser, Chrome for Android and many other mobile browsers. WebKit’s combined market share is now more than 40%, according to StatCounter and Wikimedia’s stats.

Credit: Google Operation System blog

Dorkbot worm lurks on Skype and MSN Messenger again

The Dorkbot/Rodpicom worm, which spreads via messaging applications and leads to additional malware infections, is currently doing rounds on Skype and MSN Messenger, warns Fortinet.

skype-msnThe vicious circle starts with potential victims receiving a direct message from a contact, asking “LOL is this your new profile pic? http://goo.gl/[removed]”. Those who follow the link land on a malicious site and are infected with the worm.
Apart from being able to send out the aforementioned message to further potential victims, the malware is also capable of opening a backdoor into the infected system, downloading more malicious software, spamming, reaching out to its C&C server, downloading a new version of itself, and other malicious activities. The computer is essentially enslaved into a botnet and is ready to do the botnet master’s bidding.
It’s interesting to note that the worm waits until the victims log into the chat app they use and then send out the messages. It is also able of changing the language of the message to be consistent with the language of the installed Windows operating system, making it more believable that the message has been sent by the user.
According to FortiGuard Labs researcher Raul Alvarez, the malware is also equipped with a number of evasive and obfuscation techniques aimed at hiding its existence both from AV software and researchers.

Credit: Net-Security.org