Again.
Folks,
What we have here is yet another case of DLL injection.
Same story, seasoned with a bit of international intrigue.
Do you find this fascinating?
I do, but, not in the way the author hopes.
It's fascinating that the direction is turned away from Microsoft onto the 'hackers' and the 'mode of infection'.
DLL injection has been going on for years now, in fact, Computerworld just the other day wrote an article about IE users most at risk from DLL Injection
Now, we are supposed to be engaged by this most interesting article, yet it overlooks the seriousness of this defect in Microsoft Windows.
I respond to you with this:
Please avoid using Microsoft Windows to access the internet.
Be proactive and install Ubuntu Linux as your base system (Jason Perlow did) and if you truly need Windows, then install it into a VM, e.g., VirtualBox.
Then make the virtual machine 'immutable', which keeps the VM from getting infected.
Or, simply surf the internet with Ubuntu Linux Firefox running in an AppArmor sandbox.
To enable the FF profile for AA, open a terminal window and type:
$sudo aa-enforce /etc/apparmor.d/usr.bin.firefox
Your machine will never get infected if you do this. NEVER.
So, don't be a victim. Take my advice and run Ubuntu Linux as your base system.
Be Safe.
Ubuntu Linux: The safest operating system on the planet.
I stake my reputation on it.
By Liam O Murchu
The following is a possible attack scenario. It is only speculation driven by the technical features of Stuxnet.
Industrial control systems (ICS) are operated by a specialized assembly like code on programmable logic controllers (PLCs). The PLCs are often programmed from Windows computers not connected to the Internet or even the internal network. In addition, the industrial control systems themselves are also unlikely to be connected to the Internet.
First, the attackers needed to perform reconnaissance. As each ICS is quite custom, the attackers would first need design documents. These design documents may have been stolen by an insider or even retrieved by an early version of Stuxnet or other malicious binary. Once attackers had the design documents and potential knowledge of the computing environment in the facility, they would develop the latest version of Stuxnet. Each feature of Stuxnet was implemented for a specific reason and for the final goal of potentially sabotaging the ICS.
[ Inside Stuxnet: Researcher drops new clues about origin of worm ]
Attackers would need to setup a mirrored environment that would include the necessary ICS hardware, such as PLCs, modules, and peripherals in order to test their code. The full cycle may have taken six months and five to ten core developers not counting numerous other individuals, such as quality assurance and management.
In addition their malicious binaries contained driver files that needed to be digitally signed to avoid suspicion. The attackers compromised two digital certificates to achieve this task. The attackers may have compromised these digital certificates by physically entering the premises of the two companies and stealing them as the two companies are in close physical proximity.
To infect their target, Stuxnet would need to be introduced into the target environment. This may have occurred by infecting a willing or unknowing third party, such as a contractor who perhaps had access to the facility, or an insider. The original infection may have been introduced by removable drive.
[ Stuxnet attackers used 4 Windows zero-day exploits ]
Once Stuxnet had infected a computer within the organization it began to spread in search of Field PGs, which are typical Windows computers but used to program PLCs. Since most of these computers are non-networked, Stuxnet would first try to spread to other computers on the LAN through a zero-day vulnerability, a two year old vulnerability, infecting Step 7 projects, and through removable drives.
Propagation through a LAN likely served as the first step and propagation through removable drives as a means to cover the last and final hop to a Field PG that is never connected to an untrusted network.
While attackers could control Stuxnet with a command and control server, as mentioned previously the key com- puter was unlikely to have outbound Internet access. Thus, all the functionality required to sabotage a system was embedded directly in the Stuxnet executable. Updates to this executable would be propagated throughout the facility through a peer-to-peer method established by Stuxnet.
When Stuxnet finally found a suitable computer, one that ran Step 7, it would then modify the code on the PLC. These modifications likely sabotaged the system, which was likely considered a high value target due to the large resources invested in the creation of Stuxnet.
Victims attempting to verify the issue would not see any rogue PLC code as Stuxnet hides its modifications.
While their choice of using self-replication methods may have been necessary to ensure they’d find a suitable Field PG, they also caused noticeable collateral damage by infecting machines outside the target organization. The attackers may have considered the collateral damage a necessity in order to effectively reach the intended target.
The attackers likely completed their initial attack by the time they were discovered.
* Liam O Murchu is a researcher in Symantec’s security response team. He co-wrote a dossier on Stuxnet with Nicolas Falliere and Eric Chien.
(Click image for full-size version)
