HTTP Header Injection

Sometimes user input may be reflected in the HTTP Response Header from the server. If this is the case we may want to inject additional headers to perform other tasks, e.g. setting extra cookies, redirecting the user's browser to another site, etc. One example of this is a file download from a website with a user defined filename that I tested.

The web application took a user inputted description for a dataset that was used in several places. It was passed through several layers of validation for output to the screen and to a CSV file for download. However, it was also used as the filename for the CSV download and was not subject to enough validation. The filename was written to the HTTP headers as an attachment, e.g.:

Content-Disposition: attachment; filename="output.csv"

However, if we want to add a redirect header to the response from the server then we have to manipulate the filename/description. If we add a CRLF (carriage return line feed – i.e. a new line) then we can add a new header, such as:

Refresh: 0; url=http://www.google.com/#q="password.csv"

This will redirect the user's browser to the URL after 0 seconds, i.e. give them no chance to abort it. We need to send the CRLF ASCII character codes to the server to force it to put a new line in. This can be achieved by adding %0d%0a (CRLF) into the description. In this case the .csv" was added to the end automatically, which could be ignored by the malicious website or used as in this example above. So the full description becomes:

output.csv" %0d%0aRefresh: 0; url=http://www.google.com/#q="password

The output of this in the HTTP Header is:

Content-Disposition: attachment; filename="output.csv"
Refresh: 0; url=http://www.google.com/#q="password.csv"

In this case, though, I came up with a problem. If I used the above injection I got the following error:

Error 500: Invalid LF not followed by whitespace

It turns out that the character set is not properly dealt with by the web server. You cannot just add a space after the codes either as this will appear as a space at the beginning of the header line that we are injecting, which is interpreted by the browser as a continuation of the previous header line. The solution came from https://www.aspectsecurity.com/blog/to-redacted-thanks-for-everything-utf-8/ where overly long data is inserted knowing that it will be truncated to the correct codes. The following codes will be truncated to the CRLF:

%c4%8a
%c8%8a
%cc%8a

Now the working attack payload becomes:

output.csv" %cc%8aRefresh: 0; url=http://www.google.com/#q="password

The simplest way to fix this is to use a hardcoded output filename, e.g. output.csv. The user can change this when they download it if they want. Otherwise, more sophisticated validation is required to look for certain character codes and sequences.

Security standards are like getting a driving license

When will people learn that compliance does NOT equal security? I blogged about this back in September 2009. Recently Global Payments has suffered a breach despite being PCI-DSS compliant (article from The Register)

Security standards, and being assessed against them, are like getting a driving license. Passing your driving test means that you have achieved a minimum standard of driving, but it doesn't mean that you are a good driver or that you will never have an accident. The same is true of compliance to a particular standard - it doesn't mean that you can be any less vigilant about security or that you will never be compromised, it just means that you have met an agreed minimum level.

People forget that the PCI-DSS is only concerned about payment card data and won't necessarily look at all systems and processes. It is perfectly possible that a system is legitimately considered out of scope, but that the compromise that system allows a platform to attack a system that is within scope. The penetration tests performed are usually more focused on external access to PCI data as well. What if I can compromise the administrator's laptop though? Attacks from more adept hackers won't always go straight for the target; there are often easier ways.

PCI-DSS, and any other standard, should not even be considered the minimum requirement. It should be a given that the organisation will pass their compliance as they should be aiming so far beyond the standards. I realise that resources are not unlimited, but that doesn't mean that you should be satisfied with scraping through audits. If fewer resources were wasted trying to fudge results to pass compliance then more could be spent on actually securing the environment and compliance would be practically automatic.

The goal is a secure, trusted environment, not getting a bit of paper from the auditors.

‘isSuperUser = true’ and other client-side mistakes

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.

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.

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).

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.

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.