Recently I have tested a couple of commercial web-based applications that send configuration details to the client-side to determine the functionality available to the user. These details were sent as XML to a Java applet or JavaScript via Ajax. So, what’s the problem?
The applications in question had several user roles associated with them, from low privilege users up to administrative users. All these users log into the same interface and features are enabled or disabled according to their role. In addition, access to the underlying data is also provided based on their role. However, in both cases, features were turned on and off in client-side code – either XML or JavaScript. One application actually sent isSuperUser = true for the administrative account and isSuperUser = false for others. A simple change in my client-side proxy actually succeeded in giving me access to administrative features.
The other application had several parameters that could be manipulated, such as AllowEdit. This gave access to some features, but I noticed that there were other functions available in the code that weren’t called by the page. It was a simple matter of looking for the differences between the page delivered to the administrator and that delivered to a low privilege user to find the missing code to call the functions. This was duly injected into the page via a local proxy again and new buttons and menus were added that gave administrative functionality enabled by manipulating the parameters sent, as above. Some might argue that this attack isn’t realistic as I needed an administrative account in the first place, but the code injected would work on every install of the application. You only need that access to one installation of the application, which could be on your own machine, then you can copy and paste into any other instance (or you could simply Google for the code).
It shouldn’t be this easy! Anything set on the client can be manipulated by the user easily. The security of a web application must reside on the server, not on the client. Web application developers must start treating the browser as a compromised client and code the security into the server accordingly.
Showing posts with label browser. Show all posts
Showing posts with label browser. Show all posts
Friday, 6 April 2012
‘isSuperUser = true’ and other client-side mistakes
Saturday, 10 December 2011
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.
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.
Wednesday, 22 September 2010
McAfee Secure Short-URL Service Easy to Foil
McAfee have launched a Beta URL shortening service with added security features. As Brett Hardin pointed out they are a little late to the game. However, there are so many abuses of URL shortening services that I commend them for trying.
Basically, what their service does is allow you to create short easy URLs (like any other service). However, unlike other services, when you click on the link, it opens a frames page with the content in the bottom frame and the McAfee information in the top frame. This information includes details about the domain you are connecting to, the type of company it's registered to and a big green tick or red cross to tell you whether the site is safe or not. This is decided by their 'Global Threat Intelligence', which will block known bad URLs and phishing sites. That's good, if it works.
I said above that I commend them for trying to provide this service. There are some obvious failings in their solution though, that render their protections useless other than to make it easier for people to phish users as the page has the McAfee stamp of approval. Below is their site working properly to block a known bad phishing URL.

As you can see, this site was blocked and marked as a phishing URL, which it was. Excellent, it's working! Hold on a minute though. Have a look at the screenshot below where I can access the same URL through their service by embedding it in an iframe. I now get the big green tick and I'm told that it is safe. You can see from the source that the iframe is showing the exact same URL as was blocked before. Incidentally, the page says that the site is a Business Internet Services company, which is extremely misleading as I can assure you that this wasn't put on a domain run by a Business Internet Services company.

Also, what about if I code my page to not accept being in a frames page? Then the service falls down again. The screenshot below is of Twitter accessed through this service. The problem is that I can hide all sorts of other links in the page to fool McAfee and the user won't see them. I know McAfee will block these URLs in time, but they will only be blocking the host page and they will have to block all of them. Also, if you click on a link within the page that directs you to another domain, then that is not checked, so I could just redirect you to a phishing URL and you'll still get the big green tick.

It's a nice idea, but it just doesn't work. Interestingly, other services also have some security in them. TinyURL, for example, wouldn't allow me to create a short URL for this phishing site in the first place as it was recognised as such. McAfee happily let me produce the short URL, they just blocked it later - not such a good strategy in my opinion. I know that a new phishing URL would fool TinyURL as well, but I particularly chose a URL that had been around for the best part of a month to give them a chance and I think TinyURL has done better. Incidentally, TinyURL also allowed me to produce a short URL for my test page. One good thing about TinyURL is the preview facility, but that doesn't protect me against a site that looks like the real thing.
Moral: follow any links at your own risk and don't think that a green tick makes it safe!
Basically, what their service does is allow you to create short easy URLs (like any other service). However, unlike other services, when you click on the link, it opens a frames page with the content in the bottom frame and the McAfee information in the top frame. This information includes details about the domain you are connecting to, the type of company it's registered to and a big green tick or red cross to tell you whether the site is safe or not. This is decided by their 'Global Threat Intelligence', which will block known bad URLs and phishing sites. That's good, if it works.
I said above that I commend them for trying to provide this service. There are some obvious failings in their solution though, that render their protections useless other than to make it easier for people to phish users as the page has the McAfee stamp of approval. Below is their site working properly to block a known bad phishing URL.

As you can see, this site was blocked and marked as a phishing URL, which it was. Excellent, it's working! Hold on a minute though. Have a look at the screenshot below where I can access the same URL through their service by embedding it in an iframe. I now get the big green tick and I'm told that it is safe. You can see from the source that the iframe is showing the exact same URL as was blocked before. Incidentally, the page says that the site is a Business Internet Services company, which is extremely misleading as I can assure you that this wasn't put on a domain run by a Business Internet Services company.

Also, what about if I code my page to not accept being in a frames page? Then the service falls down again. The screenshot below is of Twitter accessed through this service. The problem is that I can hide all sorts of other links in the page to fool McAfee and the user won't see them. I know McAfee will block these URLs in time, but they will only be blocking the host page and they will have to block all of them. Also, if you click on a link within the page that directs you to another domain, then that is not checked, so I could just redirect you to a phishing URL and you'll still get the big green tick.

It's a nice idea, but it just doesn't work. Interestingly, other services also have some security in them. TinyURL, for example, wouldn't allow me to create a short URL for this phishing site in the first place as it was recognised as such. McAfee happily let me produce the short URL, they just blocked it later - not such a good strategy in my opinion. I know that a new phishing URL would fool TinyURL as well, but I particularly chose a URL that had been around for the best part of a month to give them a chance and I think TinyURL has done better. Incidentally, TinyURL also allowed me to produce a short URL for my test page. One good thing about TinyURL is the preview facility, but that doesn't protect me against a site that looks like the real thing.
Moral: follow any links at your own risk and don't think that a green tick makes it safe!
Tuesday, 30 March 2010
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.
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.
Subscribe to:
Posts (Atom)

