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.
Friday, 6 April 2012
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.
Friday, 25 November 2011
Encrypted ZIP Archives Leak Information
This post is just a quick note to remind people who use encrypted ZIP archives to store or transfer confidential information, that the headers of the archive are not encrypted. Therefore, the filenames, dates and sizes of all the files within the archive can be read by anyone, without the key. Is this a problem?
Well, I believe it is. Many people and organisations have naming conventions for files. How do you know which report to open if the filename doesn't give you some clue? Often filenames will include project names or codes, departments and even the names of the people writing the report. Would you give this information out to anyone walking down the street? I have seen targeted Spear Phishing attacks on users whereby emails have been sent with what look like project spreadsheets attached with the correct naming conventions and project codes. These attacks were very convincing for an unsuspecting user. Filenames can leak enough data to start launching social engineering attacks and to concentrate cracking effort on the correct files.
What can you do? Either don't use encrypted ZIP archives to send sensitive data, or rename every single file to random names before adding them to the encrypted archive (remember that you should really do this to all files every time you want to add anything to an encrypted archive, even if the filename doesn't reveal anything as otherwise you will again be potentially advertising the really sensitive files).
Well, I believe it is. Many people and organisations have naming conventions for files. How do you know which report to open if the filename doesn't give you some clue? Often filenames will include project names or codes, departments and even the names of the people writing the report. Would you give this information out to anyone walking down the street? I have seen targeted Spear Phishing attacks on users whereby emails have been sent with what look like project spreadsheets attached with the correct naming conventions and project codes. These attacks were very convincing for an unsuspecting user. Filenames can leak enough data to start launching social engineering attacks and to concentrate cracking effort on the correct files.
What can you do? Either don't use encrypted ZIP archives to send sensitive data, or rename every single file to random names before adding them to the encrypted archive (remember that you should really do this to all files every time you want to add anything to an encrypted archive, even if the filename doesn't reveal anything as otherwise you will again be potentially advertising the really sensitive files).
Saturday, 5 November 2011
Flaw in email security means signed mails cannot be encrypted
I was at a company the other day that uses a well-known email encryption solution as they have some very sensitive information that they need to send both internally and externally. As is common for these solutions, it is possible to automatically sign the email by putting a keyword in the subject line, such as 'signemail'. Similarly, the mail will be encrypted automatically if the confidential flag is set or a keyword, such as 'encryptemail' is added to the subject.
So far, so good. There are no messy button presses or extra steps for the user. However, there is a flaw with the solution. (I should point out that at this moment it is unclear if it is a product problem or a configuration problem, hence my not mentioning the product.)
The issue is that the signing the message appears to take precedence over encryption. So, if you add both keywords to the subject then the message will only be signed and not encrypted. Now the encryption solution does also sign the message, so if you want it encrypted then you don't need to specifically sign it as well.
So is this really a problem or am I just making a fuss? Well, I can envisage several situations when it would be a problem. The most likely is probably replying to a signed message with confidential data. Let's say that Alice puts in a request for sensitive information from Bob via a signed email - only certain people can have access to the information so it is reasonable to expect Alice to digitally sign the request, but the request is not sensitive in itself.
Now, if Bob replies to that request with the sensitive information attached he will follow policy and mark it as confidential and add the encryption keyword, 'encryptemail', to the subject line. He will now assume that the information will automatically be encrypted. However, if he doesn't remove Alice's 'signemail' keyword it will just be signed and not encrypted. This then violates the policy and sends confidential information in plaintext while the user believes that it has been encrypted.
It also highlights that you shouldn't use a keyword that might be used as part of everyday language. For example, don't use the keyword 'sign' as someone could send a sensitive document with a subject something like 'Contract for you to sign'.
I suggest that everyone using this type of solution should test it to see if this happens on their system. If it does, you will, at the least, need to publish an advisory warning to your users.
So far, so good. There are no messy button presses or extra steps for the user. However, there is a flaw with the solution. (I should point out that at this moment it is unclear if it is a product problem or a configuration problem, hence my not mentioning the product.)
The issue is that the signing the message appears to take precedence over encryption. So, if you add both keywords to the subject then the message will only be signed and not encrypted. Now the encryption solution does also sign the message, so if you want it encrypted then you don't need to specifically sign it as well.
So is this really a problem or am I just making a fuss? Well, I can envisage several situations when it would be a problem. The most likely is probably replying to a signed message with confidential data. Let's say that Alice puts in a request for sensitive information from Bob via a signed email - only certain people can have access to the information so it is reasonable to expect Alice to digitally sign the request, but the request is not sensitive in itself.
Now, if Bob replies to that request with the sensitive information attached he will follow policy and mark it as confidential and add the encryption keyword, 'encryptemail', to the subject line. He will now assume that the information will automatically be encrypted. However, if he doesn't remove Alice's 'signemail' keyword it will just be signed and not encrypted. This then violates the policy and sends confidential information in plaintext while the user believes that it has been encrypted.
It also highlights that you shouldn't use a keyword that might be used as part of everyday language. For example, don't use the keyword 'sign' as someone could send a sensitive document with a subject something like 'Contract for you to sign'.
I suggest that everyone using this type of solution should test it to see if this happens on their system. If it does, you will, at the least, need to publish an advisory warning to your users.
Wednesday, 12 October 2011
Sony to send password reset email
Sony have detected someone trying to gain access to their various networks again, by using ID and password pairs that Sony conclude have been extracted from someone else's network. This may be a valid conclusion as it was only a small percentage of users that were affected (less than 0.1%, which is still 93,000). Sony have been upfront and quick to react, disabling the affected accounts and putting out a notice.
However, their next step, according to the notice given by their Chief Information Security Officer (CISO), is to send all the users who have been affected an email asking them to change their password.
Cue phishing scam!
Surely some bright spark will now construct a phishing email to send out to everyone saying that theirs was one of the 93,000 IDs compromised and could they now change their password. A simple copy of the site would then enable someone to lift thousands of valid credentials from accounts that weren't compromised. The problem is that Sony's users are now expecting an email to arrive to tell them to change their password. The work to trick someone to follow a link has already been done by Sony and the media.
How about not sending an email? Instead, publicise the attack and that some accounts have been disabled (Sony has done this). Next, let the users come to the Sony sites and try to log in. Then you can inform them that their account has been disabled and what the password reset procedure is.
However, their next step, according to the notice given by their Chief Information Security Officer (CISO), is to send all the users who have been affected an email asking them to change their password.
Cue phishing scam!
Surely some bright spark will now construct a phishing email to send out to everyone saying that theirs was one of the 93,000 IDs compromised and could they now change their password. A simple copy of the site would then enable someone to lift thousands of valid credentials from accounts that weren't compromised. The problem is that Sony's users are now expecting an email to arrive to tell them to change their password. The work to trick someone to follow a link has already been done by Sony and the media.
How about not sending an email? Instead, publicise the attack and that some accounts have been disabled (Sony has done this). Next, let the users come to the Sony sites and try to log in. Then you can inform them that their account has been disabled and what the password reset procedure is.
Tuesday, 11 October 2011
Password Protect Your Mobile
I know that many security 'professionals' will scaremonger and preach doom and gloom at every turn in order to drive up sales. However, they're not always wrong. I read the article 'Mobile device users fail to take basic steps to protect themselves, survey finds' and wanted to relate an event that happened this weekend. Many people are saying that mobile device security threats are hype and that nobody is actually exploiting them. That's possibly true to a certain extent at the moment, but for how long? Another article claims that identity theft is now more profitable than car theft! A mobile phone is a very good start for this purpose.
An interesting figure that comes from the article above is that 160,000 mobile phones are lost or stolen every day. I assume that this is just in America, as in Britain the figure is around 20,000 a day. Whether or not these figures are accurate is immaterial, the fact remains that a lot of phones go missing. What do you have access to from your mobile?
The recent incident that I mentioned above happened on Sunday. Someone left their iPhone at a sports training ground I was at. On inspection of the phone, there was no authentication set on it at all. I was able to see photographs, names, addresses and telephone numbers of family and friends. In addition to this, they had a Facebook App, which was still signed in. It would have been very easy to update their status with a malicious link for all their friends to visit. Worse than this, however, was the fact that they had access to their corporate email and address book from the phone - a FTSE 100 company. Again, this was still signed in with no additional authentication required. What corporate information could I have gained access to?
As it was, a phone call to the telephone number entered as 'Home' enabled the phone to be returned without stripping data off it or sending phishing messages. However, what if someone else had picked it up? The survey in the article stated that, of those interviewed, over 65% used their mobile phone to access corporate email and networks. "Do you send or receive sensitive information via email?" should have been the next question.
Businesses and employees should think carefully about the data held on their devices and the level of access they have to the corporate network. At the very least people should always have some form of authentication set on their phone, e.g. a PIN, password or stronger authentication. The majority of users leave applications, such as email and social media accounts, perpetually logged in and many users leave their devices unlocked. Even when they are forced to lock them due to policies, they don't always really secure the device. I have seen many users with corporate phones that require passwords use simple passwords (such as 'qwerty') so that they are easy to type. They site difficulties in typing complex passwords as being the major reason for choosing simple passwords, which is in line with the findings of the survey.
The bottom line is that these devices are part of the corporate network, whether the IT department is aware of them or not. They need protection. Even as an individual, protect your identity and your contacts by employing automatic locking of your mobile with passwords or long PIN numbers and don't leave apps permanently logged in. (I find it surprising/worrying that I have to give this warning/advise!)
An interesting figure that comes from the article above is that 160,000 mobile phones are lost or stolen every day. I assume that this is just in America, as in Britain the figure is around 20,000 a day. Whether or not these figures are accurate is immaterial, the fact remains that a lot of phones go missing. What do you have access to from your mobile?
The recent incident that I mentioned above happened on Sunday. Someone left their iPhone at a sports training ground I was at. On inspection of the phone, there was no authentication set on it at all. I was able to see photographs, names, addresses and telephone numbers of family and friends. In addition to this, they had a Facebook App, which was still signed in. It would have been very easy to update their status with a malicious link for all their friends to visit. Worse than this, however, was the fact that they had access to their corporate email and address book from the phone - a FTSE 100 company. Again, this was still signed in with no additional authentication required. What corporate information could I have gained access to?
As it was, a phone call to the telephone number entered as 'Home' enabled the phone to be returned without stripping data off it or sending phishing messages. However, what if someone else had picked it up? The survey in the article stated that, of those interviewed, over 65% used their mobile phone to access corporate email and networks. "Do you send or receive sensitive information via email?" should have been the next question.
Businesses and employees should think carefully about the data held on their devices and the level of access they have to the corporate network. At the very least people should always have some form of authentication set on their phone, e.g. a PIN, password or stronger authentication. The majority of users leave applications, such as email and social media accounts, perpetually logged in and many users leave their devices unlocked. Even when they are forced to lock them due to policies, they don't always really secure the device. I have seen many users with corporate phones that require passwords use simple passwords (such as 'qwerty') so that they are easy to type. They site difficulties in typing complex passwords as being the major reason for choosing simple passwords, which is in line with the findings of the survey.
The bottom line is that these devices are part of the corporate network, whether the IT department is aware of them or not. They need protection. Even as an individual, protect your identity and your contacts by employing automatic locking of your mobile with passwords or long PIN numbers and don't leave apps permanently logged in. (I find it surprising/worrying that I have to give this warning/advise!)
Tuesday, 20 September 2011
City Link and Gathering Data for Spear Phishing
I have just been sent an email giving me a tracking number for a City Link parcel due to be delivered. On checking this on their website, I found that I only need the tracking number to track the parcel and no other information. Is this a problem?
Well, I think it is. Via my tracking number I am able to find the company name of the sender and my postcode. Now, postcodes normally only relate to around a dozen properties at most. However, that's not the end of the story. By entering different numbers (based on the one that I received) I was able to get the details of other parcels being sent around. Incidentally, their format is AAAddddd - representing three uppercase letters followed by sequential numbering.
Does this matter? Well, by going backwards through the sequential numbering system I was able to find a parcel that had just been delivered (at 13.50 to be precise) to a postcode in West Yorkshire - BD22 (I have omitted the last part of the postcode here). Helpfully, they include the surname of the person that signed for the parcel. Then it was a simple matter of doing a quick search on the properties to find someone with the correct surname. I found Denise and Jonathan X living at that address for a number of years and was able to find additional information, such as the fact that Jonathan worked for a local University. Crucially, I was able to find email addresses for them. It would now be very simple for me to launch a phishing attack on them as I have real details with which to trick them. There is simply a privacy issue here as well. Do you want anyone and everyone knowing what deliveries you receive and from which organisations? This could make a very good profile.
How hard would it be for City Link to require some additional information before giving out the detail? A simple solution would be to ask for the correct postcode in addition to the tracking number, then it would be much harder for someone to extract the details. They have included a captcha that kicks in after a few attempts, but this doesn't work, and simply entering anything in the field over the minimum required length and containing a space will be accepted. Also, cycling through IP addresses or performing the requests slowly will bypass this requirement. Anyway, I'm off to write a script to extract the details for the postcodes of City Link employees, MPs and newspaper reporters to see where they shop...
Well, I think it is. Via my tracking number I am able to find the company name of the sender and my postcode. Now, postcodes normally only relate to around a dozen properties at most. However, that's not the end of the story. By entering different numbers (based on the one that I received) I was able to get the details of other parcels being sent around. Incidentally, their format is AAAddddd - representing three uppercase letters followed by sequential numbering.
Does this matter? Well, by going backwards through the sequential numbering system I was able to find a parcel that had just been delivered (at 13.50 to be precise) to a postcode in West Yorkshire - BD22 (I have omitted the last part of the postcode here). Helpfully, they include the surname of the person that signed for the parcel. Then it was a simple matter of doing a quick search on the properties to find someone with the correct surname. I found Denise and Jonathan X living at that address for a number of years and was able to find additional information, such as the fact that Jonathan worked for a local University. Crucially, I was able to find email addresses for them. It would now be very simple for me to launch a phishing attack on them as I have real details with which to trick them. There is simply a privacy issue here as well. Do you want anyone and everyone knowing what deliveries you receive and from which organisations? This could make a very good profile.
How hard would it be for City Link to require some additional information before giving out the detail? A simple solution would be to ask for the correct postcode in addition to the tracking number, then it would be much harder for someone to extract the details. They have included a captcha that kicks in after a few attempts, but this doesn't work, and simply entering anything in the field over the minimum required length and containing a space will be accepted. Also, cycling through IP addresses or performing the requests slowly will bypass this requirement. Anyway, I'm off to write a script to extract the details for the postcodes of City Link employees, MPs and newspaper reporters to see where they shop...
Subscribe to:
Posts (Atom)