Rixstep
	`About \| ACP \| Buy \| Industry Watch \| Learning Curve \| News \| Products \| Search \| Substack`

Home » Learning Curve

An OS Behaving Badly

A guide between the lines of the US-CERT Stuxnet advisory.

Get It

Try It

US-CERT have now released their official update on the USB hack targeting Siemens SCADA systems. The hack compromises all versions of Windows because the attack vector is universal to all versions.

There are more details on what it targets and how poorly the targeted company performed here.

System engineers and security experts are supposed to understand the ramifications of such an attack; lay persons aren't. But the basic facts are easy enough to understand if they're explained correctly.

The exact attack vector used has not yet been publicly disclosed. It has something to do with the way the system shell processes paths to image files used to display shortcuts.

But that's not interesting here. What's interesting instead is the propagation - what this hack is able to do once it gets to ground.

Remember: this infection process requires no extraordinary user intervention. The processes involved do not require authentication to run. No authorisation is given or even asked for.

A few basic definitions first.

Definitions

All systems claiming to be better than 'standalone' have different real or symbolic login accounts. Most Windows users avail themselves of a default account in the user group 'Administrators' which then gives them nearly full access to the machine.

But there is another account with even higher privileges that's rarely used. All self-respecting systems have such an account. The generic term for such an account is superuser; the specific term used on Windows is 'SYSTEM'.

The idea with a superuser account is to keep sensitive (critical) resources out of reach. Ordinary users - administrators or otherwise - have to authenticate in some way (password, retina scan) to escalate to superuser level.

Having a superuser account means you can lock away critical things like system files because you assign ownership to the superuser account. And then you make sure no one else can do anything to them.

You can stop ordinary user processes from even reading the files. From modifying them. From running them if they're program files. From renaming them or removing them.

You can also stop unauthorised processes from interfering with the directories they're contained in. You can stop other users from adding files to these directories or in any way modifying them.

And you nest this protection as far down in the system as you want. Perhaps ordinary users (even administrators) can't even see the files (or the directories) they're in. (This is certainly true of the Registry.)

Trojans, viruses, worms - malware - can't do anything then. They may be able to annoy you personally but they won't be able to corrupt your system as a whole.

That's how a secure/securable system works. That's how every system in the world today works except Windows.

The US-CERT Advisory

And now onto the US-CERT advisory on this latest attack on Windows. It's already been given at least ten (10) different names by the security industry parasites. (Somehow that's about all they can do.)

Stuxnet, Trojan-Dropper.Win32.Stuxnet.a, WORM_STUXNET.AWORM_STUXNET.A, Troj/Stuxnet-A, TrojanDropper:Win32/Stuxnet.A, Trj/CI.A, Trojan.Stuxnet.1, Trojan-Dropper.Win32.Stuxnet, W32/Stuxnet.C, Exploit:W32/WormLink.A

[Good job, boys.]

Again: nobody's revealed yet how this thing actually gets to run. But what US-CERT describe in detail is what it does once it's running. That's what we'll look at here.

Taken directly from the US-CERT advisory:

'The malware appears to launch when a USB storage device is viewed using a file manager such as Windows Explorer.' Precisely. Nothing is activated in the normal sense. No applications are run. The user doesn't double-click anything. It's code related to displaying icons that gets screwed up.
'Because the malware exploits a zero-day vulnerability in the way that Windows processes shortcut files, the malware is able to execute without using the AutoRun feature.' Correct again. Nothing needs to be run. No autorun, nothing. It's all about the display of icons.
'Based on current reporting, the malware drops and executes two driver files: mrxnet.sys and mrxcls.sys.' Yes. But hold on. The 'sys' extension is normally for system files, for device drivers - the files closest to the hardware. Where are these files going to be dropped?
'These files are placed in the %SystemRoot%\System32\drivers directory.' Whoa again. There is no more critical directory on a Windows system. System32 is the BMOC and drivers is its child. No mere mortal should be allowed in there. Unless that mysterious hack is able to corrupt code running as 'SYSTEM' then there should be no way to drop those files in that directory. But things don't work like that on Windows, do they? No they don't.
'The mrxnet.sys driver works as a file system filter driver, and mrxcls.sys is used to inject malicious code.' Drivers don't run simply because they're there on the disk. They have to be authenticated. But there's no user intervention here at all. And this business of injecting malicious code deserves a chapter unto itself.
'The two drivers are used to inject code into system processes to hide themselves. Using this method, the malware files are not visible on an infected USB storage device.' What's happened at this stage is the two 'unauthenticated' files were able to put a 'rootkit' with a cloaking device onto the system. They're controlling very low-level Windows processes. So that even if you ask to list all files in their directory, you won't see them. Yes, this is really scary shit and no, it doesn't happen often outside the world of Windows. But it is truly scary, yes.
But code injection is even worse (if that's possible). For you're now not only doing things that no one but the superuser can do, you're now also doing things that even the superuser shouldn't be able to do!

For 'protected' ('protected mode') systems (basically all systems 32-bit or better) prohibit (by design and by definition) processes from poking into the inner workings of other processes. Which stands to reason.

But this 'code injection' is a common occurrence on Windows - it's the type of thing that's not allowed anywhere else in the world of IT.

Windows users often think computer systems in general are vulnerable as soon as any 'bad stuff' finds them and comes into contact with them. But that's only the way Windows works. Other systems don't work like that at all.

Take another look at that install path for the malware.

%SystemRoot% - that's Registry shorthand for your 'Windows' directory. It can have any name at all. This is a resource that should be protected - accessible for modification only by the superuser.
System32 - another resource that should be protected. But in this case it should already be nested inside another directory that's protected. So there should be no risks at all, should there?
drivers - another resource that should be protected. But in this case it's nested way the heck down there. So no one should be able to get at it. Yet they do. Continually. Effortlessly.

Windows has some advanced security features thanks to the VMS legacy (the system from Digital Equipment Corporation it's based on). But those features are often left inaccessible for ordinary users and they're neither sufficiently granular nor user-friendly and so are mostly ignored after system install. And Windows has nothing to replace that.

Windows users have to be careful where they surf, what attachments they open, and so forth, and so on. They have to live online in a constant state of fear and tension (unless they're complete idiots - most likely the neighbours of a Unix geek who works overtime for them, fixing their systems every other week).

Computers were never meant to work like that. No computer but a Windows computer works like that.

The hack exploits an error in Microsoft system code. Things like that happen. People always make mistakes. But the hack can thereafter run rampant through Windows, alter critical system directories, run drivers without express user authorisation, even root and cloak the system itself.

Of course it's perfectly possible (although highly improbable) that the GUI request for a simple display icon kicks in some superuser code snippet. But this type of thing - corrupting the system without privilege escalation - happens all the time on that system known as Windows.

Operating systems are supposed to make it harder for hackers to go to ground. Start looking around for another OS vendor.