Citrix & RemoteApp File upload and Breakout using MS Office

It is possible to deliver applications remotely to users via a solution such as Citrix or Microsoft RemoteApp (part of their Remote Desktop solution). This has the advantage of only delivering the application rather than the whole desktop to the user. The user isn't even necessarily aware that the application is running remotely, as it will appear like any locally installed application when running. An example of the type of application delivered in this way might be Microsoft Office.

If, however, the Citrix or RemoteApp environment hasn't been set up properly, then this can lead to security problems such as arbitrary file upload and running commands remotely. I'm not going to look at macro security, even though this can lead to complete compromise of a system. However, what some people are not aware of is that you can upload files through the Open and Save As dialogs in Office. These files can then be executed on the remote system through the same dialogs.

The figure below shows the options in the Open dialog of Word, with All Files (*.*) selected as the file type and having navigated into the Windows directory. Selecting either Open or, in this case, Run as administrator will execute the application. The same could be done with a batch file or script file after first uploading it by copying and pasting into this same dialog. Arbitrary files can be uploaded to a remote system and executed in this way.

What if you don't have direct access to Office applications? If they are installed on the system, you may still be able to exploit this. Consider Internet Explorer for instance. If this application is delivered remotely and Office is installed on the system, then you will probably have the option to edit the page in Office as the screenshot below shows, with the 'Export to Microsoft Excel' option in the context menu.

In a remote application environment, this will open a new window to allow you to interact with the new application. You can then upload your file and execute it as before. If you are deploying remote applications, you will have to think carefully about what you are delivering and secure the deployment properly with group policies, etc., to make sure that you do not fall foul of such simple tricks.

Which Browser is the Most Secure?

I was recently talking to a fellow security professional who develops secure plug-ins for browsers and we started talking about the security of various different browsers. Most of the talk around browsers centres around how fast they are and what sort of features they have, but rarely do people talk about the security of their browser. Unfortunately, the browser is one of your weak points on the network as users have the ability to navigate to sites containing malware or phishing attacks as well as install plug-ins or run scripts that are malicious. So, which browser is the most secure? Any guesses?

All browsers (and all security products for that matter) have security weaknesses and vulnerabilities. However, the architecture of the browser and certain features can make browsing safer. The feature I'm going to put forward first is web browser protection against socially-engineered malware (phishing sites). According to many of the big AV and security vendors, phishing is on the rise and set to be the biggest headache of this year. Two statistics worth quoting are: according to Trend Micro, 53% of malware is delivered via Internet downloads against only 12% via e-mail; and Microsoft claim that 0.5% of the download requests through IE8 are malicious and they block a download for one in 40 users every week. In January 2010 NSS Labs tested five of the latest browsers against socially-engineered malware. Their full report is worth reading, but I have shamelessly reproduced their main graph here.


According to NSS Labs, Internet Explorer 8 blocked 85% of these malware sites using their SmartScreen Filter. The next nearest was Safari 4 at 29% and 0.2% behind that was Firefox 3.5. Chrome 4 was worse, on only 17%, and Opera 10 was bottom of the pile, achieving less than 1% blocking. By far the best of the pack was IE8, but even that still lets through 15% of malware. An interesting and noteworthy aside to this is that I believe Safari and Firefox use Google's Anti-Phishing API and achieve a 29% blocking rate, yet Google's Chrome only achieves 17%. If you want to see what the SmartScreen blocking looks like in IE8, you can see an example below, where IE8 is blocking it and Comodo's Dragon (a Chrome derivative) is not.

Also, again according to NSS Labs, Firefox had an 'average add time' of 5.7 hours, the fastest, versus Microsoft's 6.7 hours. The average add time is how long on average does a user have to wait before a visited malicious site is added to the block list. Speed is very important here, but it does actually have to get blocked in the end to make this a valid metric. These figures are better than the other three browsers, which scored: Safari - 9.0 hours; Chrome - 14.7 hours; Opera 82.4 hours.


Having mentioned Comodo's Dragon now I will give you a brief introduction, if you haven't heard of it before. It is a free Chrome derivative browser from Comodo. This browser has been designed to be more secure than the average browser. It doesn't perform well in the above tests, but has several other features up its sleeve centred around privacy. Some of the main features include not sending the HTTP Referrer so that you cannot be tracked from site to site, it won't send crash and problem reports (so your history remains on your machine only), it highlights DV only secured sites and will give a visit history with the certificates. If you don't know the difference between a DV and an EV SSL/TLS Certificate then read this blog post. An example of the DV certificate warning can be seen in the screenshot below.


One problem I have with the privacy tag associated with this browser is the UserAgent string. I have blogged about Cookieless Browser Tracking by using the UserAgent string before. The point is that the string sent to a web server by your browser to identify its and your machine's capabilities gives about a third of the information required to uniquely identify you. There will only be a handful of machines with the same UserAgent string, especially if you stray from the most common browsers (IE & Firefox). I also think that 'Never save passwords' should be the default setting and 'Allow all cookies' should not be the default setting. It is a new browser though, and I'm sure it will improve over time as the company is committed to security in many guises. Certainly its positive features are good and something that other browser vendors should follow.

The next point is about actual downloads from the Internet. Dragon, and other browsers, will give a warning when downloading executable files, but will just download ZIP, PDF, etc., and allow you to open them without warning. Bear in mind that PDFs and ZIP archives can contain malware. IE8, on the other hand, will ask you to confirm the software used to open a download, regardless of its type. This will always give you the chance to opt out if it wasn't what you were expecting. Also, IE8 will tell you if it is a signed or unsigned download, if it is a plug-in or an executable. Other browsers do not support this feature. What does it mean though? Well, if I am a software vendor, like Adobe, and I want you to download and install my plug-in I will sign it with a digital signature. When you download it, you can verify the signature, which will tell you that I (or Adobe) created and signed the download and that nobody has tampered with it in the meantime. If the download isn't signed, then how do you know that this isn't a phishing or pharming site pretending to be Adobe (or intercepting the download with a proxy) giving you a version containing a Trojan or some other malware? The answer is that you don't!

So, you should only download and install signed plug-ins and executables. Unfortunately, Internet Explorer is one of the few browsers that will control this for you and it makes a distinction between signed and unsigned plug-ins even when they are installed. Which brings me onto my final point (as this post is getting very long and a bit like a rant). Internet Explorer is, I believe, the most attacked browser as it has, until recently, been the most widely used. Due to this, Microsoft has had to build it in a secure fashion, controlling all plug-ins carefully. Firefox, on the other hand, performs many of its tasks by using a plug-in architecture, even for standard functionality. As far as I am aware, there is little or no distinction between a 'built-in' plug-in and one installed from a third party at a later date. This is very dangerous in my opinion. Firefox now enjoys the top position for browsers and it won't be long before the hackers make the switch from attacking IE over to Firefox. I think it will be harder to secure Firefox against this onslaught than it will be for Microsoft to keep up with their architecture.

It is interesting to note that the speed of the browser runs roughly inversely to the graph at the beginning of this post, i.e. Chrome is very fast and IE is considered the slowest of the big 4. However, security always comes at a price - processing being a big loser. Could it be that the reason why IE is such a leviathan and slower than its rivals is because they're doing much more checking and keeping you much more secure? I think so. Microsoft have a way to go though and can't rest on their laurels. I will be watching Comodo Dragon with interest to see if they can really push for the top spot in terms of a secure browser. It certainly does something for user education and privacy.

ATM & Bank Card Security

I recently read an article in New Scientist entitled "Want to clone bank cards? Just press 'print'". They state that it has been discovered that

"... a devious piece of criminal coding that has been quietly at work in a clutch of cash machines at banks in Russia and Ukraine. It allows a gang member to walk up to an ATM, insert a "trigger" card, and use the machine's printer to produce a list of all the debit card numbers used that day, including their start and expiry dates - and their PINs. Everything needed, in fact, to clone those cards and start emptying bank accounts."

This is possible because ATM Terminal vendors have succumbed to financial pressures, and the demand for greater functionality, and moved to using standard modular PC architectures and off-the-shelf operating systems, such as Microsoft Windows and Linux. These ATM devices then become vulnerable to similar malware as their desktop counterparts.

SpiderLabs, part of Trustwave, identified that in this case a new version of the 50KB lsass.exe Windows XP file is loaded onto the system via a compromised Borland Delphi installer utility, isadmin.exe (note, that's LSASS.EXE, not 1SASS.EXE as some have reported). You can view the full report from Trustwave as a PDF here. The legitimate lsass.exe executable is used to cache session data in Windows, so that users don't have to re-enter passwords when receiving new emails or returning to a website, which is essentially what the malware developers want to do with the card data. Actually, this has no place on an ATM, but may not be picked up, due to the fact that it is, by default, on most Windows XP installs.

If a trigger card is not detected, the malware stores the transaction data to a file called tr12 and key or PIN data to a file called k1 in the C:/WINDOWS directory. If a trigger card is detected, then a menu of 10 options is displayed for 10 seconds, with functions including: uninstalling, deleting logs, printing logs via the built-in printer encrypted with DES and possibly the ability to export the data onto the trigger card. This particular malware only works on transactions in US dollars, Russian Rouble or Ukrainian Hryvnia. It is also said that chip-and-PIN cards across Europe are not vulnerable to this malware as the PIN is encrypted in the secure PIN pad.

It has been speculated that deploying the malware was either an inside job or the result of bribes and threats; the reasoning being that an attacker would have to have physical access to the ATM to deploy the malware. However, the ATMs and banking network, although separate from the Internet, have not necessarily been hardened enough. Back on 25th November 2003 the first known case of a worm (Welchia) infecting Windows XP based ATM machines was reported, which used the closed financial network to propagate. This was possible because the ATMs weren't patched by the financial institutions in question. This brings on the whole problem of patch management on ATMs as well as placing greater restrictions on the financial networks. How long will it be before keyloggers are available for chip-and-PIN cards as well?

Lack of true Identity Verification forces need for EV SSL Certificates

What are EV SSL Certificates? Simply they are Extended Validation SSL Certificates. What does this mean? Well, simply put the Certification Authority goes to more lengths to validate the identity of the person asking for (paying for) the certificate. The EV SSL Certificate then will make the browser address bar go green to certify that this really is the site you think it is and not a phishing or pharming site. It gives the user a very visual check of the validity of the website that they are using.

Isn't this what Digital Certificates were supposed to do in the first place? Yes, but the Certification Authorities were more interested in taking people's money than verifying that they actually were the people in question. This led to almost anybody being able to sign up for a certificate claiming to be almost anybody. This, obviously, isn't a workable situation, so EV SSL Certificates were introduced to do the intended job, only at a higher price than the standard SSL Certificate (in part due to the actual identity validation performed no doubt). That being said, they are not expensive in the grand scheme of things and should be used far more widely than they currently are - for example NatWest still doesn't use an EV SSL Certificate at the time of writing this, instead they have ended up implementing Trusteer's Rapport at a much higher cost.

To give you some idea of cost of a digital certificate, Comodo's price is £214 per year (US$359/€359) for a single fully qualified domain name (i.e. per website); this includes their 'Corner of Trust' logo. Compare this with somewhere near $1 per customer for Trusteer's Rapport or even hosting fees and business profits! Admittedly, their cheapest SSL Certificate is only £41.95 per annum, but is £214 too much to ask when you are giving customers peace of mind, assurances over authentication and tackling phishing & pharming?

Why aren't normal certificates secure? Well, the problem is that most Certification Authorities don't do very much checking. Usually they check your domain name by sending you an email to an address that has the same domain name extension. All this says is that someone who has access to an email address on that domain wants to set up a secure web server. They don't actually check who you are. They are more interested in whether you will pay than if they should issue the certificate. This was demonstrated at IPICS today, when it was shown that VeriSign had given out a Digital Certificate to someone using the name William Gates! They have also fallen for scams, where they were duped into issuing a code signing certificate for the Microsoft Corporation by someone proving the point that they are not careful enough.

I decided to see if this was the case with other organisations, and it is. I have set up an SSL certificate just by being able to view an email sent to an address on that domain. I also wanted to know if I could be Steve Ballmer - the new Bill Gates. So, I set up an email account: Steve.Ballmer@live.co.uk using details about him, such as his year of birth: 1956. I then decided to try Thawte out, as they provide free email certificates for personal use. Sure enough, after entering the data below, I was sent an email to my address with codes to verify myself. I now have a digital certificate to sign emails from Steve.Ballmer@live.co.uk.

Surname: Ballmer
Forenames: Steve
Date Of Birth: 1956/03/24
Nationality: the United States
Email: steve.ballmer@live.co.uk
Where were you born? Detroit
Where did you go to school? Detroit Country Day School
First company you worked for? Procter & Gamble
What is your spouse's Name? Connie Snyder
How many children do you have? 3

Now, Thawte has a little trick up its sleeve here, which aides security. Before they will assign the name Steve Ballmer to the certificate, I must pass their Web of Trust, i.e. I must convince some other users that I am indeed Steve Ballmer first by meeting them face-to-face. However, if I could supply them with details such as passport number and social security number, then I'd be set. So, I can still sign my email, but if users look closely at the signature and check the certificate, they will see that I haven't been verified. However, if they don't actually look at this carefully, and with knowledge of what it means, then they will be fooled into thinking I really am Steve Ballmer. Why should the ordinary user know about this? Comodo and VeriSign, on the other hand, provide no such backup. So, I can now sign my email as Steve Ballmer. Here's my Public Key for Steve Ballmer from Comodo showing that I really am Steve Ballmer!

This isn't really good enough in this day and age of phishing scams.

Post Script Edit
Two things have happened since writing this blog post. Firstly, I have become aware of an attack on SSL Certificates by using a null value inserted in the domain name to trick the CA into issuing a certificate on an invalid domain. For example, www.natwest.com[null value].phishers.org will result in an SSL certificate being issued for www.natwest.com to the phishers.org site, which will appear valid in many browsers (but not all). Link to blog post. This won't (shouldn't) affect EV SSL Certificates though, only the Domain Validated ones.

Secondly, Comodo, to their credit, do admit that this is a problem and are takling it. They have sent me a link via email to a video clip, which in turn links to more information. That can be found here. The bottom line really is that these EV certificates are more secure, don't cost that much and should be the norm. As an industry we should be educating users into recognising and looking for these security features.

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!

InfoSecurity Europe 2009

Well, a couple of weeks ago I went to InfoSecurity Europe 2009 at Earl's Court, as I do every year. If you've never been, but are at all interested in network and information security or are looking for vendors, then I highly recommend visiting. To my surprise, and for the first time I can remember, Microsoft wasn't there. Apart from that, however, all the usual players were there and, to be honest, it was all much the same as before. There was no new emerging technology or hot topic, just new developments of old technologies. A couple of years ago we had the hot topic of 'social engineering' and 'securing the user'; ok, we all knew that the users were our weak link and phrases like "we spend all our time securing the first 2000 miles and forget about the last 2 feet", and "our network would be totally secure, reliable and fully functional if we didn't let users login", have always been commonplace, but there were new mass threats, new education programmes and new tools at the disposal of net admins to deal with them.

However, this year was different; nothing really sprang out. OK, cloud computing and Software-as-a-Service (SaaS) has expanded and matured, but other than that we see the same products and services as before. What amazes me is how some vendors and speakers can get it so wrong and don't appear to understand the actual level of security offered or operating environment in which their products will be used. I'm not going to list actual vendors here, but how can an encryption solution for mobile users that doesn't encrypt the data at rest be viable? Encrypting network traffic is commendable, but not the only safeguard required. What if they now lose their laptop, mobile or pen drive? A secure USB pen drive vendor admitted, when questioned, that files were decrypted into the C:\Temp folder while in use, then deleted after encrypting for storage on the drive again. They couldn't tell me if this was a secure delete or a simple removal of the pointer in the file allocation table as normal. Regardless of the deletion process, however, how many applications can read and write to that folder? What's to stop me from writing a very small bit of code to monitor that folder every few seconds and take copies? This might be secure enough if it is on a corporate machine, but why not just store the file on it then and not bother with the drive?

Similarly, email security is always a problematic area, with almost no solution fitting the technology properly. The big advantage of email, and the reason we all use it, is that it is independent of firmware - i.e. it doesn't matter what hardware, OS or email app we use, it still works. Unfortunately, security was never built in to email, so every email is like sending an electronic postcard. However, I would argue that a solution that only allows you to send encrypted email within your organisation is of limited value. What about all your customers and partners? There are also still solutions that store your files on their servers and send a link to the recipient. Why trust your files to them? I asked several vendors how they deal with password transfer, only to be told that they don't. "It's up to the user how they tell the recipient what the password is," was a common reply. We know users are unreliable, why leave it to them? I had to transfer some confidential files to someone via email recently (the only transport method they would accept), only to be told that they didn't want the hassle of decrypting it, so could I send them in plaintext. Having got over that hurdle, they wouldn't give me a mobile phone number so that I could transfer the passphrase via a call or SMS (as people seem to need them written down), asking me to email it to them. I know there are technologies out there to solve these problems, but they aren't without any problems.

This is turning into a bit of a rant and I'm getting off topic, so back to InfoSec. I was pleased to see that there were some voices of caution out there about the wholesale adoption of virtualisation without considering the security implications. One that springs to mind is Steve Moyle who has produced 10 points to consider implementing on his blog here. Virtualisation is a good technology for a number of reasons, but it does bring in new security threats and it must be implemented with these in mind and secured accordingly. I do also think that cloud computing and SaaS could be very important to SMEs (Small to Medium-sized Enterprises) who don't have the in-house expertise or large budget. They can still have large enterprise-level configurability and security, without the overheads. Finally, people seem to be taking information governance and user education seriously rather than just paying lip-service to them. In all, the show was encouraging, but many vendors are not quite there yet, which only goes to highlight that the majority of organisations are not taking the new threat-landscape seriously enough and countermeasures must be lacking.