About | Buy | Forum | Industry Watch | Learning Curve | Products | Search | Twitter | Xnews
Home » Learning Curve

On Kneber

Security 101 for the clueless.


Buy It

Try It

Most people know by now what Kneber is. As Jim Lehrer said just yesterday, 'there's a virus called botnet'. But most of the media hyenas are trying to make 'copy', not offer any perspective - something Brian Krebs justifiably laments.

But there's perspective and then there's perspective. There's the kind of advanced operational perspective Brian offers: he's been on the inside of the organised crime rings and no one knows better how they work.

There's the kind of perspective that looks not so much at the crime operation itself but at the excuse for an operating system it attacks.

Where There's Smoke

One's eyebrows go up as soon as one sees what these trojans have done of late. NetWitness found a botnet with control of 74,126 Windows systems spread around 196 countries. These systems are found at medical companies, insurance companies, educational institutions, energy firms, financial companies, Internet providers, and government agencies. You'd think companies such as those would be better at security - if they had a system to work with that offered them better security.

The picture grows all the more bizarre when one looks back to June of last year when Prevx came upon a cache with logon credentials for 74,000 FTP accounts. These accounts were for companies such as NASA, Cisco, Kaspersky, McAfee, Symantec, Amazon, Bank of America, Oracle, ABC, BusinessWeek, Bloomberg, Disney, Monster, and the Queensland government.

Now you'd really suspect something's wrong: the list includes Kaspersky, McAfee, and Symantec - the antivirus companies servicing the Windows market. They're the companies who are supposed to protect Windows users. Yet they obviously can't protect themselves. What good is their software if they can't even protect themselves with it? Why are people even buying it? And what is one to do if even these software products can't protect Windows?

And why for that matter would an operating system need a third party product to protect it? Why can't it protect itself?

This isn't a numbers game. It's not about reducing crime on the streets as they do in all those endless Hollywood-generated police procedurals. This is about being secure. Either you're secure or you're not. Period. And don't look now but it sure looks as if Windows can't be secured if even the defenders can get hacked willy-nilly.

The smoke leads to the fire.

The God of Botnets

Fortinet's Fortiguard Centre call the Zeus trojan the 'god of DIY botnets'. They have a rather thorough white paper on Zeus available at the following URL. A good idea is to read that paper right now before proceeding. And pay close attention to the section entitled 'Bot Distribution and Installation'. It's there one begins to see what's going on.

http://www.fortiguard.com/analysis/zeusanalysis.html

From the paper:

When the bot is executed on a victim's computer it goes through a number of steps to install and configure itself and to connect to the botnet. The filenames given here are for the tested version, and sometimes are changed in new versions. Outlined below are the steps taken upon initial execution:

It's the first five steps which are of particular interest.

1.

'1. The install function searches for the 'winlogon.exe' process, allocates some memory within it, and decrypts itself into the process.'

A few words about virtual memory and protected memory systems.

The essence of a protected system is that no process is able to gain access to any other process - not even memory used by that other process when it's finished running. There are any number of hurdles to this of course. User land (paged) processes never access memory directly anyway - the kernel sets up page tables for them so their idea of what memory addresses really are - virtual memory addresses - get translated into real memory addresses at runtime.

The processes themselves never see these real addresses. Their programmers have to act as if those virtual addresses are real addresses (when they're not).

A process is inviolate. There is supposed to be no way one process can even peek at another or worse - corrupt that process. This might have been OK back in the days of MS-DOS or MacOS but it's not OK in the modern world of secure computing. And this is actually one of the things Cutler's 'NTx' source tree's been tested for over the years.

But today there are - as one example - API functions that let user land processes create and run remote threads in other processes. This is just totally wrong - it's insecure - and it makes the type of thing happening with Zeus all the easier.

And winlogon.exe is no mere neighbourhood constable - it's a very important component of the Windows (security) system.

From Wikipedia.

Winlogon is the component of Windows responsible for handling the secure attention sequence, loading the user profile on login, and optionally locking the computer when a screensaver is running.

That's pretty central to system security. More from Wikipedia.

Winlogon is a common target for several threats that could modify its function.

But if winlogon.exe plays a central and critical role in system security, then why isn't it protected?

This is the process that greets the user with a login panel. It's run in a special 'no man's land' so it can't be hijacked. It can outsource the actual authentication to other processes. It establishes the user account access token so the system knows who the user is and what the user can and cannot do.

Why can't it be protected? Why does Windows let rogue threads simply land on a target system, poke around in this crucial process, and then load code into it and run it?

Vundo is another trojan that successfully attacks winlogon.exe. Here's what Wikipedia has to offer.

A Vundo infection is caused either by opening an email attachment or through a variety of browser exploits.

But mail clients don't run in privileged mode and browsers don't either. And the actual operation of corrupting a process central to system security is supposed to be impossible anyway.

2.

'2. The bot executable is written to the hard drive as C:\WINDOWS\system32\sdra64.exe.'

Windows files with an EXE extension are called executables. There are other types of files that can 'execute'. The extension doesn't imply the files can be run. Not from the beginning. 'EXE' is actually in contrast to the other older extension 'COM'. EXE 'binaries' are relocatable where the older COM binaries aren't.

The file being written to disk in this step (sdra64.exe) is an 'executable' or 'relocatable binary'. Nothing wrong with that. But there's something wrong with where it's being put: C:\WINDOWS\system32 is the most sensitive part of a Windows system - the area (as the name implies) for all the system files.

The scenario again is that an unwitting user gets a poison message or visits an infected site - and then all this starts happening. There is no privilege escalation, there is nothing running in any context other than that of the login user, and yet the system's most critical, most crucial disk areas are corrupted without any hint of resistance.

This is a secure system?

3.

'3. The directory C:\WINDOWS\system32\lowsec is created. The directory is not visible in Windows Explorer.'

Windows Explorer is the system file manager, now that Winfile is gone and presuming the user doesn't have more advanced tools like the X-file Suite. A simple user land process is able to corrupt the native system file manager to hide things.

And the trojan is mucking with that super-sensitive system32 directory again - something that should be impossible on a secure system. Except it's not. There's a bit of distinction between writing files and creating directories. But nothing matters here - Windows lets the trojan do whatever it likes.

4.

'4. The Winlogon ('HKLM/SOFTWARE/Microsoft/WindowsNT/CurrentVersion/Winlogon') Registry key's value is appended with the path of the bot executable: C:/WINDOWS/system32/sdra64.exe. This will cause the bot to execute when the computer restarts.'

Whoa. So not only is the Windows system disk unprotected, its Registry is too?

The Windows Registry is where all sensitive (configuration) information is stored. There are both hardware and software branches in this Registry. Some of this data should be configurable by the user but most should not. Getting at the system hardware configuration is tantamount to getting at the hardware itself - it should not be possible from 'user land'.

And yet it is. But it's actually a lot worse: a simple non-privileged write to this Registry replaces the all-important system login program file with another. Suddenly through a non-privileged operation the entire security of the system has been subverted.

This is a secure system?

5.

'5. The Windows XP firewall is disabled.'

Here's a picture of Apple's Mac OS X configuration panel for the system firewall.

Notice the lock in the lower left hand corner. You can't turn off the firewall without clicking the lock and clicking the lock results in the following.

It doesn't matter who you were when you logged in - you have to authenticate again. Why? Because any process can be running on your account - any Zeus, any Vundo, anything. The password keeps the bad guys out.

There are any number of examples of this behaviour in Windows. Security settings everywhere are only secure until the bad guys find where they're hiding. The Registry is (for some) an impenetrable maze but it's no challenge for the black hats. Yet Microsoft seem to think they can buy a few brief moments of respite by finding new hiding places for sensitive (unprotected) security settings. Your firewall is on? Flick a switch and it's off. Just like that.

'Security' on Windows is reactive as opposed to proactive anyway. Real systems practise proactive security: they're built from the ground up with security as part of the fundament. Windows is VAX built atop MS-DOS. It has no security. All Microsoft are doing - along with their buddies in the AV industry - is chasing the bad guys inside the perimeter. And that's futile.

Homework

The lesson to take home is you can't protect computer systems with Keystone Kops ad hoc security measures. Kneber's Zeus even proves antivirus is of no help anyway - Trusteer have shown that antivirus has not even one chance in four of finding Zeus, much less rooting it out.

And if that's the way you're thinking, you're doomed anyway. A computer isn't supposed to be like Times Square at midnight; it's supposed to be like a gated community, a data centre, where only the good guys get in, where everybody wears a badge at all times, where everyone has to continually authenticate to do anything serious to the system.

Most people don't have a chance to ever understand computers - or worse: computer security. But the nose often knows. And the system known as Windows emits a horrible stench.

About | Buy | Forum | Industry Watch | Learning Curve | Products | Search | Twitter | Xnews
Copyright © Rixstep. All rights reserved.