Skip to main content

Trojan Keylogger Screensaver Compromising Novell Client for Windows

I've been talking about 2-factor authentication and improving authentication mechanisms for a while now and trying to get companies to implement such solutions. One such organisation uses the Novell client for Windows on Windows XP. When a user attempts to log in they are not required to press Ctrl+Alt+Del. Many forums and reviews state that this is an advantage, as users don't like it! The point of pressing Ctrl+Alt+Del (CAD) on Windows is to stop all applications from running and kill Trojans, etc. Novell have replaced the MSGina.dll with NWGina.dll so that they can capture the CAD key combination. This is the standard way to override the built-in login screen and replace it with a custom one. However, Novell have decided to allow administrators to eliminate the need for the CAD key combination. This, obviously reduces the overall security of the system.

I know that there are many ways to write a keylogger, some more sophisticated than others, but a lot of these low-level system keyloggers can be picked up by AV (Anti-Virus) software. I wanted to show that you don't need to be able to create this type of keylogger to obtain the username/password combination from a system that doesn't require the CAD key combination. Another reason for not going down this route is that I wanted to show that this could be put on a live system, not just in the lab. Therefore, it mustn't trigger the AV when installed or when running. The solution I decided to try was to write a screensaver to mimic the Novell login screen, capture the username/password, write these to a web service and then hand back to the real Novell client.

I have just listed a few things there without explanation. Why don't I just take the details and log the user in myself, then pass the username/password to my web service? Well, this would require either modifications to the NWGina or System calls that would trigger the AV and other protection mechanisms. I wanted this to remain undetected. Basically, a screensaver is just an application that is run automatically, rather than explicitly by the user. Indeed, when you write a screensaver you produce an .exe file and just rename it as .scr. Obviously there are a few things you have to do to make it function as a screensaver, like be full-screen and always on top. You also have to handle mouse and keyboard events to end the screensaver and return control of the desktop to the user. However, instead of immediately exiting our application and returning control, why not pop up another form to mimic the login dialog and fool users into giving us their password? It's easy really.

So what do we do once the user has entered their details? Well, the screensaver writes the data to a simple web handler that I wrote for this purpose. All it does is take an HTTP GET request with URL parameters and return a simple text confirmation to the screensaver. I don't care that it's in plaintext and somebody might read it. Obviously, I would have to anonymize the server so that it couldn't be traced, but I'm not actually trying to deploy this. Once the screensaver has confirmation that the username/password have been logged, then it displays the 'incorrect password' dialog and immediately exits to reveal the real login dialog. In this way, the user will most likely think that they have mistyped their password. As a little trick, I decided to make the ruse more plausible by turning the CAPS Lock on as soon as the user clicks the login button.

The final thing to evade detection was to set a limit as to how many times the Trojan would appear. Nobody mistypes their password the first time they log in every time, so I decided that a 1 in 5 rule would probably be acceptable. Here I assumed that users might accept that they have mistyped their password 1 in 5 times, particularly with the CAPS Lock trick as well. You could go for a lot less than this, but then you'd have to make sure it was on the machine for a while to capture the passwords. Again, this is simple to do, generate a pseudo-random number to determine whether to show the Trojan dialog or exit the program.

Having written the screensaver I had to test it. Well, I have access to a corporate laptop and desktop with the Novell client on and McAfee AV software. It works a treat. Very realistic and not picked up by the AV. I have asked people to look at it and try it (without using their real username/password combination) and they have said that they wouldn't have realised. I'm not sure it's particularly ethical to try this on a real network, so I'll probably leave it there, however there is still the issue of mass distribution of such a Trojan. I don't believe that this will be terribly difficult though, especially if using a bit of social engineering as well.

So, how do you defeat this method? Don't disable CAD, or if it is disabled then press it anyway!

Comments

Popular Posts

Coventry Building Society Grid Card

Coventry Building Society have recently introduced the Grid Card as a simple form of 2-factor authentication. It replaces memorable words in the login process. Now the idea is that you require something you know (i.e. your password) and something you have (i.e. the Grid Card) to log in - 2 things = 2 factors. For more about authentication see this post . How does it work? Very simply is the answer. During the log in process, you will be asked to enter the digits at 3 co-ordinates. For example: c3, d2 and j5 would mean that you enter 5, 6 and 3 (this is the example Coventry give). Is this better than a secret word? Yes, is the short answer. How many people will choose a memorable word that someone close to them could guess? Remember, that this isn't a password as such, it is expected to be a word and a word that means something to the user. The problem is that users cannot remember lots of passwords, so remembering two would be difficult. Also, having two passwords isn't real

How Reliable is RAID?

We all know that when we want a highly available and reliable server we install a RAID solution, but how reliable actually is that? Well, obviously, you can work it out quite simply as we will see below, but before you do, you have to know what sort of RAID are you talking about, as some can be less reliable than a single disk. The most common types are RAID 0, 1 and 5. We will look at the reliability of each using real disks for the calculations, but before we do, let's recap on what the most common RAID types are. Common Types of RAID RAID 0 is the Stripe set, which consists of 2 or more disks with data written in equal sized blocks to each of the disks. This is a fast way of reading and writing data to disk, but it gives you no redundancy at all. In fact, RAID 0 is actually less reliable than a single disk, as all the disks are in series from a reliability point of view. If you lose one disk in the array, you've lost the whole thing. RAID 0 is used purely to speed up dis

Trusteer or no trust 'ere...

...that is the question. Well, I've had more of a look into Trusteer's Rapport, and it seems that my fears were justified. There are many security professionals out there who are claiming that this is 'snake oil' - marketing hype for something that isn't possible. Trusteer's Rapport gives security 'guaranteed' even if your machine is infected with malware according to their marketing department. Now any security professional worth his salt will tell you that this is rubbish and you should run a mile from claims like this. Anyway, I will try to address a few questions I raised in my last post about this. Firstly, I was correct in my assumption that Rapport requires a list of the servers that you wish to communicate with; it contacts a secure DNS server, which has a list already in it. This is how it switches from a phishing site to the legitimate site silently in the background. I have yet to fully investigate the security of this DNS, however, as most