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!


Popular Posts

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

Web Hosting Security Policy & Guidelines

I have seen so many websites hosted and developed insecurely that I have often thought I should write a guide of sorts for those wanting to commission a new website. Now I have have actually been asked to develop a web hosting security policy and a set of guidelines to give to project managers for dissemination to developers and hosting providers. So, I thought I would share some of my advice here. Before I do, though, I have to answer why we need this policy in the first place? There are many types of attack on websites, but these can be broadly categorised as follows: Denial of Service (DoS), Defacement and Data Breaches/Information Stealing. Data breaches and defacements hurt businesses' reputations and customer confidence as well as having direct financial impacts. But surely any hosting provider or solution developer will have these standards in place, yes? Well, in my experience the answer is no. It is true that they are mostly common sense and most providers will conform

Trusteer's Response to Issues with Rapport

I have been getting a lot of hits on this blog relating to Trusteer's Rapport, so I thought I would take a better look at the product. During my investigations, I was able to log keystrokes on a Windows 7 machine whilst accessing NatWest. However, the cause is as yet unknown as Rapport should be secure against this keylogger, so I'm not going to share the details here yet (there will be a video once Trusteer are happy there is no further threat). I have had quite a dialogue with Trusteer over this potential problem and can report that their guys are pretty switched on, they picked up on this very quickly and are taking it extremely seriously. They are also realistic about all security products and have many layers of security in place within their own product. No security product is 100% secure - it can't be. The best measure of a product, in my opinion, is the company's response to potential problems. I have to admit that Trusteer have been exemplary here. Why do I