Tales from the Crypto : General Security

My take on the SSL MITM Attacks – part 3 – the FTPS attacks

Alun Jones — Thu, 19 Nov 2009 05:02:00 GMT

[Note - for previous parts in this series, see Part 1 and Part 2.]

FTP, and FTP over SSL, are my specialist subject, having written one of the first FTP servers for Windows to support FTP over SSL (and the first standalone FTP server for Windows!)

Rescorla and others have concentrated on the SSL MITM attacks and their effects on HTTPS, declining to discuss other protocols about which they know relatively far less. OK, time to step up and assume the mantle of expert, so that someone with more imagination can shoot me down.

FTPS is not vulnerable to this attack.

No, that’s plainly rubbish. If you start thinking along those lines in the security world, you’ve lost it. You might as well throw in the security towel and go into a job where you can assume everybody loves you and will do nothing to harm you. Be a developer of web-based applications, say. :-)

FTPS has a number of possible vulnerabilities

And they are all dependent on the features, design and implementation of your individual FTPS server and/or client. That’s why I say “possible”.

Attack 1 – renegotiation with client certificates

The obvious attack – renegotiation for client certificates – is likely to fail, because FTPS starts its TLS sessions in a different way from HTTPS.

In HTTPS, you open an unauthenticated SSL session, request a protected resource, and the server prompts for your client certificate.

In FTPS, when you connect to the control channel, you provide your credentials at the first SSL negotiation or not at all. There’s no need to renegotiate, and certainly there’s no language in the FTPS standard that allows the server to query for more credentials part way into the transaction. The best the server can do is refuse a request and say you need different or better credentials.

Attack 2 – unsolicited renegotiation without credentials

A renegotiation attack on the control channel that doesn’t rely on making the server ask for client credentials is similarly unlikely to succeed – when the TLS session is started with an AUTH TLS command, the server puts the connection into the ‘reinitialised’ state, waiting for a USER and PASS command to supply credentials. Request splitting across the renegotiation boundary might get the user name, but the password wouldn’t be put into anywhere the attacker could get to.

Attack 3 – renegotiating the data connection

At first sight, the data connection, too, is difficult or impossible to attack – an attacker would have to guess which transaction was an upload in order to be able to prepend his own content to the upload.

But that’s betting without the effect that NATs had on the FTP protocol.

Because the PORT and PASV commands involve sending an IP address across the control channel, and because NAT devices have to modify these commands and their responses, in many implementations of FTPS, after credentials have been negotiated on the control channel, the client issues a “CCC” command, to drop the control channel back into clear-text mode.

Yes, that’s right, after negotiating SSL with the server, the client may throw away the protection on the control channel, so the MitM attacker can easily see what files are going to be accessed over what ports and IP addresses, and if the server supports SSL renegotiation, the attacker can put his data in at the start of the upload before renegotiating to hand off to the legitimate client. Because the client thinks everything is fine, and the server just assumes a renegotiation is fine, there’s no reason for either one to doubt the quality of the file that’s been uploaded.

How could this be abused? Imagine that you are uploading an EXE file, and the hacker prepends it with his own code. That’s how I wrote code for a ‘dongle’ check in a program I worked on over twenty years ago, and the same trick could still work easily today. Instant Trojan.

There are many formats of file that would allow abuse by prepending data. CSV files, most exploitable buffer overflow graphic formats, etc.

Attack 3.5 – truncation attacks

While I’m on FTP over SSL implementations and the data connection, there’s also the issue that most clients don’t properly terminate the SSL connection in FTPS data transfers.

As a result, the server can’t afford to report as an error when a MitM closes the TCP connection underneath them with an unexpected TCP FIN.

That’s bad – but combine it with FTP’s ability to resume a transfer from part-way into a file, and you realize that an MitM could actually stuff data into the middle of a file by allowing the upload to start, interrupting it after a few segments, and then when the client resumed, interjecting the data using the renegotiation attack.

The attacker wouldn’t even need to be able to insert the FIN at exactly the byte mark he wanted – after all, the client will be sending the REST command in clear-text thanks to the CCC command. That means the attacker can modify it, to pick where his data is going to sit.

Not as earth-shattering as the HTTPS attacks, but worth considering if you rely on FTPS for data security.

How does WFTPD Pro get around these attacks?

1. I never bothered implementing SSL / TLS renegotiation – didn’t see it as necessary; never had the feature requested. Implementing unnecessary complexity is often cause for a security failure.

2. I didn’t like the CCC command, and so I didn’t implement that, either. I prefer to push people towards using Block instead of Stream mode to get around NAT restrictions.

I know, it’s merely fortunate that I made those decisions, rather than that I had any particular foresight, but it’s nice to be able to say that my software is not vulnerable to the obvious attacks.

I’ve yet to run this by other SSL and FTP experts to see whether I’m still vulnerable to something I haven’t thought of, but my thinking so far makes me happy – and makes me wonder what other FTPS developers have done.

I wanted to contact one or two to see if they’ve thought of attacks that I haven’t considered, or that I haven’t covered. So far, however, I’ve either received no response, or I’ve discovered that they are no longer working on their FTPS software.

Let me know if you have any input of your own on this issue.

My take on the SSL MitM Attacks – part 2 – clarifications

Alun Jones — Thu, 12 Nov 2009 05:20:00 GMT

Since the last post I made on the topic of SSL renegotiation attacks, I’ve had a few questions in email. Let’s see how well I can answer them:

Q. Some stories talk about SSL, others about TLS, what’s the difference?

A. For trademark reasons, when SSL became an open standard, it had to change its name from SSL to TLS. TLS 1.0 is essentially SSL 3.1 – it even claims to be version “3.1” in its communication. I’ll just call it SSL from here on out to remind you that it’s a problem with SSL and TLS both.

Q. All the press coverage seems to be talking about HTTPS – is this limited to HTTPS?

A. No, this isn’t an HTTPS-only attack, although it is true that most people’s exposure to SSL is through HTTPS. There are many other protocols that use SSL to protect their connections and traffic, and they each may be vulnerable in their own special ways.

Q. I’ve seen some posts saying that SSH and SFTP are not vulnerable – how did they manage that?

A. Simply by being “not SSL”. SFTP is a protocol on top of SSH, and SSH is not related to SSL. That’s why it’s not affected by this issue. Of course, if there’s a vulnerability discovered in SSH, it’ll affect SSH and SFTP, but won’t affect SSL or SSL-based protocols such as HTTPS and FTPS.

Q. Is it OK to disable SSL renegotiation to fix this bug?

A. Obviously, if SSL didn’t need renegotiation at all, it wouldn’t be there. So, in some respects, if you disable SSL renegotiation, you may be killing functionality. There are a few reasons that you might be using SSL renegotiation:

Because that’s how client authentication works – while you can do client authentication without renegotiation, most HTTPS implementations use renegotiation to request the client certificate. Disabling renegotiation will generally prevent most clients from authenticating with client authentication.
After 10 hours, renegotiation is required, so as to refresh the session key. Do you have SSL connections lasting 10 hours? You probably should be looking at some disconnect/reconnect scenario instead.
Because you can’t disable SSL renegotiation in all cases. In OpenSSL, you can only disable renegotiation if you download and install the new version, and in other SSL implementations, there is no way to disable renegotiation outside of modifying the application.

Q. Since this attack requires the attacker to become a man-in-the-middle, doesn’t that make it fundamentally difficult, esoteric, or close to impossible?

A. If becoming a man-in-the-middle (MitM) was impossible or difficult, there would be little-to-no need for SSL in the first place. SSL is designed specifically to protect against MitM attacks by authenticating and encrypting the channel. If a MitM can alter traffic and make it seem as if everything’s secure between client and server over SSL, then there’s a failure in SSL’s basic goal of protecting against men-in-the-middle.

Once you assume that an attacker can intercept, read, and modify (but not decrypt) the SSL traffic, this attack is actually relatively easy. There are demonstration programs available already to show how to exploit it.

I was asked earlier today how someone could become a man-in-the-middle, and off the top of my head I came up with six ways that are either recently or frequently used to do just that.

Q. Am I safe at a coffee shop using the wifi?

A. No, not really – over wifi is the easiest way for an attacker to insert himself into your stream.

When using a public wifi spot, always connect as soon as possible to a secured VPN. Ironically, of course, most VPNs are SSL-based, these days, and so you’re relying on SSL to protect you against possible attacks that might lead to SSL issues. This is not nearly as daft as it sounds.

Q. Is this really the most important vulnerability we face right now?

A. No, it just happens to be one that I understood quickly and can blather on about. I think it’s under-discussed, and I don’t think we’ve seen the last entertaining use of it. I’d like to make sure developers of SSL-dependent applications are at least thinking about what attacks can be performed against them using this step, and how they can prevent these attacks. I know I’m working to do something with WFTPD Pro.

Q. Isn’t the solution to avoid executing commands outside the encrypted tunnel?

A. Very nearly, yes. The answer is to avoid executing commands sent across two encrypted sessions, and to deal harshly with those connections who try to send part of their content in one session and the rest in a differently negotiated session.

In testing WFTPD Pro out against FTPS clients, I found that some would send two encrypted packets for each command – one containing the command itself, the other containing the carriage return and linefeed. This is bad in itself, but if the two packets straddle either side of a renegotiation, disconnect the client. That should prevent the HTTPS Request-Splitting using renegotiation.

One key behaviour HTTPS has is that when you request a protected resource, it will ask for authentication and then hand you the resource. What it should probably be doing is to ask for authentication and then wait for you to re-request the resource. That action alone would have prevented the client-certificate attacks discussed so far.

Q. What is the proposed solution?

A. The proposed solution, as I understand it, is for client and server to state in their renegotiation handshake what the last negotiated session state was. That way, an interloper cannot hand off a previously negotiated session to the victim client without the client noticing.

Note that, because this is implemented as a TLS handshake extension, it cannot be implemented in SSLv3. Those of you who just got done with mandating SSLv2 removal throughout your organisations, prepare for the future requirement that SSLv3 be similarly disabled.

Q. Can we apply the solution today?

A. It’s not been ratified as a standard yet, and there needs to be some discussion to avoid rushing into a solution that might, in retrospect, turn out to be no better – or perhaps worse – than the problem it’s trying to solve.

Even when the solution is made available, consider that PCI auditors are still working hard to persuade their customers to stop using SSLv2, which was deprecated over twelve years ago. I keep thinking that this is rather akin to debating whether we should disable the Latin language portion of our web pages.

However, it does demonstrate that users and server operators alike do not like to change their existing systems. No doubt IDS and IPS vendors will step up and provide modules that can disconnect unwarranted renegotiations.

Update: Read Part 3 for a discussion of the possible threats to FTPS.

My take on the SSL MITM Attacks – part 1 – the HTTPS attack

Alun Jones — Tue, 10 Nov 2009 04:26:00 GMT

If you’re in the security world, you’ve probably heard a lot lately about new and deadly flaws in the SSL and TLS protocols – so-called “Man in the Middle” attacks (aka MITM).

These aren’t the same as old-style MITM attacks, which relied on the attacker somehow pretending strongly to be the secure site being connected to – those attacks allowed the attacker to get the entire content of the transmission, but they required the attacker to already have some significant level of access. The access required included that the attacker had to be able to intercept and change the network traffic as it passed through him, and also that the attacker had to provide a completely trusted certificate representing himself as the secure server. [Note – you can always perform a man-in-the-middle attack if you own a trusted certificate authority.]

The current SSL MITM attack follows a different pattern, because of the way HTTPS authentication works in practice. This means it has more limited effect, but requires less in the way of access. You gain some security advantage, you lose some. The attacker still needs to be able to intercept and modify the traffic between client and server, but does not get to see the content of traffic between client and server. All the attacker gets to do is to submit data to the server before the client gets its turn.

Imagine you’re ordering a pizza over the phone. Normally, the procedure is that you call and tell them what the pizza order is (type of pizza, delivery address), and they ask you for your credit card number as verification. Sometimes, though, the phone operator asks for your credit card number first, and then takes your order. So, you’re comfortable working either way.

Now, suppose an attacker can hijack your call to the pizza restaurant and mimic your voice. While playing you a ringing tone to keep you on the line, he talks to the phone operator, specifying the pizza he wants and the address to which it is to be delivered. Immediately after that, he connects you to your pizza restaurant, you’re asked for your credit card number, which you supply, and then you place your pizza order.

Computers are as dumb as a bag of rocks. Not very smart rocks at that. So, imagine that this phone operator isn’t smart enough to say “what, another pizza? You just ordered one.”

That’s a rough, non-technical description of the HTTPS attack. There’s another subtle variation, in which the caller states his pizza order, then says “oh, and ignore my attempt to order a pizza in a few seconds”. The computer is dumb enough to accept that, too.

For a more technical description, go see Eric Rescorla’s summary at Understanding the TLS Renegotiation Attack, or Marsh Ray’s original report.

Let’s call these the HTTPS client-auth attack and the HTTPS request-splitting attack. That’s a basic description of what they do.

HTTPS client-authentication attack

The client-authentication attack is getting the biggest press, because it allows the attacker one go (per try) at persuading the server to perform an action in the context of the authenticated user. From ordering a pizza to pretty any activity that can be caused in a single request to a web site can be achieved with this attack.

Preventing the attack at the server.

Servers have been poorly designed in this respect – but out of some necessity. Eric Rescorla explains this in the SSL and TLS bible, “SSL and TLS” [Subtitle: Designing and Building Secure Systems] on page 322, section 9.18.

“The commonly used approach is for the server to negotiate an ordinary SSL connection for all clients. Then, once the request has been received, the server determines whether client authentication is required… If it is required, the server requests a rehandshake using HelloRequest. In this second handshake, the server requests client authentication.”

How does HTTP handle other authentication, such as Forms, Digest, Basic, Windows Integrated, etc? Is it different from the above description?

A client can provide credentials along with its original request using the WWW-Authenticate header, or the server can refuse an unauthorised (anonymous) request with a 401 error code indicating that authentication is necessary (and listing WWW-Authenticate headers containing appropriate challenges). In the latter case, the client resends the request with the appropriate WWW-Authenticate header.

HTTPS Mutual Authentication (another term for client authentication) doesn’t do this. Why on earth not? I’m not sure, but I think it’s probably because SSL already has a mostly unwarranted reputation for being slow, and this would add another turnaround to the process.

Whatever the reason, a sudden dose of unexpected ‘401’ errors would lead to clients failing, because they aren’t coded to re-request the page with mutual auth in place.

So, we can’t redesign from scratch to fix this immediately – how do we fix what’s in place?

The best way is to realise what the attack can do, and make sure that the effects are as limited as possible. The attack can make the client engage in one action – the first action it performs after authenticating – using the credentials sent immediately after requesting the action to be performed.

A change of application design is warranted, then, to ensure that the first thing your secure application does on authenticating with a client certificate is to display a welcome screen, and not to perform an action. Reject any action requested prior to authentication having been received.

Sadly, while this is technically possible using SSL if you’ve written your own server to go along with the application, or can tie into information about the underlying SSL connection, it’s likely that most HTTPS servers operate on the principle that HTTP is stateless, and the app should have no knowledge of the SSL state beyond “have I been authenticated or not”.

Doubtless web server vendors are going to be coming out with workarounds, advice and fixes – and you should, of course, be looking to their advice on how to fix this behaviour.

The best defence against the client-authentication attack, of course, is to not use client authentication.

Preventing the attack at the client

Not much you can do here, I’m afraid – the client can’t tell if the server has already received a request. Perhaps it would work to not provide client certificates to a server unless you already have an existing SSL connection, but that would kill functionality to perfectly good web sites that are operating properly. Assuming that most web sites operate in the mode of “accept a no-client-auth connection before requesting authentication”, you could rework your client to insist on this happening all the time. Prepare for failures to be reported.

Again, the best defence is not to use client authentication right now. Perhaps split your time between browsers – one with client certificates built in for those few occasions when you need them, and the other without client certs, for your main browsing. That will, at least, limit your exposure.

HTTPS Request-splitting attack

Preventing the attack at the server

The HTTPS Request-splitting attack is technically a little easier to block at the server, if you write the server’s SSL interface – there should be absolutely no reason for an HTTP Request to be split across an SSL renegotiation. So, an HTTPS server should be able to discard any connection state, including headers already sent, when renegotiation happens. Again, consult with your web server developer / vendor for their recommendations.

Preventing the attack at the client?

Again, you’re pretty much out of luck here – even sending a double carriage return to terminate any previous request would cause the attacker’s request to succeed.

The long term approach – fix the protocol

As you can imagine, there are some changes that can be made to TLS to fix all of this. The basic thought is to have client and server add a little information in the renegotiation handshake that checks that client and server both agree about what has already come before in their communication. This allows client and server both to tell when an interloper has added his own communication before the renegotiation has taken place.

Details of the current plan can be found at draft-rescorla-tls-renegotiate.txt

Final thoughts

Yeah, this is a significant attack against SSL, or particularly HTTPS. There are few, if any, options for protecting yourself as a client, and not very many for protecting yourself as a server.

Considering how long it’s taken some places to get around to ditching SSLv2 after its own security flaws were found and patched 14 years ago with the development of SSLv3 and TLS, it seems like we’ll be trying to cope with these issues for many years to come.

Like it or not, though, the long-term approach of revising TLS is our best protection, and it’s important as users that we consider keeping our software up-to-date with changes in the security / threat landscape.

Update: read Part 2 of this discussion for answers to a number of questions.

Update: read Part 3 for some details on FTPS and the potential for attacks.

Why changing passwords should be done regularly

Alun Jones — Tue, 03 Nov 2009 04:59:19 GMT

A little birdie sent me a copy of today’s SANS ISC diary entry. That’s a good thing, because I’m at home sick with alleged piggy flu, and I’m not able to keep up with a whole lot.

The diary entry argues that regular changes of passwords are often done for no other reason than “because we’ve always done it that way”.

Apparently, people responsible for security policy have “read somewhere” that you’re supposed to change passwords every ninety days, and having no other basis on which to proceed, that’s the policy carved in stone.

When asked why this policy is the way it is, the usual response is “good security practice” – and in such environments it’s difficult to give a good response to someone who pushes back, arguing that changing passwords in their application is ‘difficult’ or, more often, ‘expensive’. This is, after all, business, and if one side pleads “expense”, while the other side pleads “good thing to do”, the latter side will lose.

So, why is it best practice?

One reason is that you have to recognise that for all that we tell users not to share their passwords, not to use the same password on multiple sites (aka “share their passwords”), etc, very often users will do exactly that. So, every ninety days, you change your password and you cut off everyone with whom you previously shared your password (to an extent).

Another reason is to allow changes in password policy to propagate out to new passwords. If you suddenly realise that passwords can be easily hacked if they are only six characters, you change the password policy to require punctuation as well, and then you realise that because no one has to change their password, the new policy will never be applied.

Those are the common arguments for regular password changes, and there are a few others, but there’s one I rarely hear being made.

What about when you do get an exposure?

In my professional career, I have seen, or heard of, a number of cases of exposure of password information. Sometimes it’s as simple as a departing employee who knows far too much information and may not be trusted, or as mind-boggling as a team sharing a list of important passwords, and one of the team members losing the list. Other times it’s more complex.

Each time, the response from security is the same – if the existing passwords are in danger of being used because of such exposure, then those passwords need to be changed.

Most times, the response from the business is the same – that the passwords haven’t been changed in so long, and they’re spread through so many different applications, that they have no idea what will be affected if they change the password.

Once you hit that scenario, it can be months before you get the password changed. Yes, months. And all during that time, the account may be compromised.

How do you prevent this?

Think of your disaster recovery drills – when there’s a process that needs to be followed quickly and correctly in an emergency situation, you achieve that by meticulous planning and regular exercise. You create the process and test it regularly, updating the process as you find there’s a need.

If you don’t change passwords on these high-value accounts once every 90 days (or so), how do you know that you’ll be able to change those passwords after an exposure or compromise? How will you guarantee that your password change procedures are current, without testing them? How will you enforce changes being documented if you don’t check the documentation against reality once in a while?

White House moves to Open Source

Alun Jones — Tue, 27 Oct 2009 04:15:59 GMT

Subtitle: Media posts uninformed rubbish as commentary

From the MSNBC story “White House opens Web site coding to public”:

"Security is fundamentally built into the development process because the community is made up of people from all across the world, and they look at the source code from the very start of the process until it's deployed and after," said Terri Molini of Open Source for America, an interest group that has pushed for more such programs.

Expecting Open Source to be more secure because the general public contributes to and reviews it is like expecting a televised football match to be safer, because the folks at home are engaged in crowd control and looking for pickpockets.

While you might luck out in finding a few talented, devoted, and dare I say it, obsessed individuals who will call the police every time they see an infraction on screen, most of the people tuning in are going to be watching the game; and those that are trying to help are often clueless about how the security in the grounds works, and you’ll get many calls from people who see the security guards searching bags on entry as pickpockets.

Lots more to pick on

There’s lots more to pick on in the article – for instance, the inability to determine the difference between a content management system and the web site it serves (akin to not knowing the difference between a story and the typewriter on which it was written), which itself significantly reduces the need for this one Open Source product to be secure.

The news article barely hints at some of the true advantages of Open Source – that others can drop additional components in at their pleasure, and that you can pick up whichever of those components you need. [Of course, the same is true of closed source products with good published interface specifications, so perhaps this is only an advantage in the extreme case that the provided interfaces are incomplete.]

Is Open Source more or less secure?

There are plenty of reasons to believe that Open Source offers security advantages – it’s possible, for instance, to do your own deep security investigations and fix problems when you become aware of them. Of course, that’s rather like saying an advantage of buying an old car is that you get to do your own services – great if you’re a mechanic, not so good if you have to check the owner’s manual to remember which end to put petrol into.

Software is more secure because it is written by good, dedicated, experienced programmers, reviewed by other good, dedicated, experienced programmers, analysed by tools and experienced programmers looking for security flaws, and tested pretty much to destruction.

Don’t forget, as well, that there is little perceivable difference between secure software, lucky software, and uninteresting software. All will appear to be unhacked – until luck runs out, or the software becomes interesting to an attacker.

I don’t claim to be able to determine that all Open Source is more or less secure than all Closed Source.

Just that the “more eyeballs” line doesn’t remotely provide anything close to an explanation.

Phishing at Hotmail, GMail, Yahoo! Mail, etc.

Alun Jones — Sun, 25 Oct 2009 19:24:31 GMT

Recent password exposures at a number of online email services remind me to give a little advice on passwords.

Definitely use this as a reminder to do something about your passwords – but don’t do the obvious thing. Don’t rush round and change all your passwords right away.

Don’t change your passwords, change your password habits.

Don’t use the same password everywhere.
If your password gets exposed, or the service owner is malicious (or has a malicious staff member), you’ll be exposed everywhere.
Many times, of course, you will be unable to use the same password everywhere, because one site will require a symbol, and another will not allow that symbol. It is better to cope with this than to have to try and synchronise all your passwords.
Write down some of your passwords.
What, seriously? Yep. Write down those passwords you don’t frequently use, and lock them away. Or store them in a password-protected (encrypted) file, whether that’s a Word file, Excel spreadsheet or any number of other storage mechanisms that will allow you to encrypt your passwords and store them away. Now you have replaced multiple passwords to remember with one.
See point 1, though, make sure the password encrypting your password store is one you don’t share with any other sites.
There are products out there which will protect your passwords for you – whether they are called password safes, vaults, strongboxes etc, they all do basically the same kind of thing.
Consider what passwords should be accessible to others.
This may sound like bad security – and in a managed environment where others can always exert administrative rights to access files and systems that your passwords were used for, you should generally not be sharing your passwords.
But think on this – a friend of mine received a traumatic train/brain injury, and though his recovery borders on the miraculous, there are many things he has forgotten. Passwords seem to be the hardest for him to hang on to, and he has had to recover through other means – sometimes simply wiping and recreating the system.
Just as you have a will to direct people how to continue after your passing, store safely away account details and passwords so that your affairs can be brought into control if you are interrupted like my friend, or more permanently disconnected from the Internet. And make sure someone trustworthy and reliable can find that store when necessary.
Plan to change your passwords.
If you don’t occasionally change your passwords, you will not know how to change them when it comes time to do so in a hurry.
At several times in my professional career, I’ve had to deal with accounts whose passwords might have been exposed, whether through departing employees, lost password sheets, and at some of those occasions the natural security response of ‘change the passwords as soon as possible’ results in major push-back, by teams who have never changed their passwords, don’t know how to achieve it quickly, and aren’t sure what other applications depend on those passwords.
If you don’t regularly change your important passwords, you’ll be flummoxed and panicked when it’s actually necessary to do so, and you may break something that depends on those passwords being synchronised.
Change your passwords often enough, but not too often.
How often is too often?
How often is enough?
Difficult questions – often enough that you can remember changes to the systems to figure out why a password change caused some difficulty, and often enough to cover departing employees or others who might have had legitimate access once, but shouldn’t have access any more.
Too often is when you get so tired of changing your passwords that you start regretting the process entirely.

There are no doubt dozens more things that could be suggested as good password practice, but these five will stand you in good stead.

SAL-like code annotations for Java

Alun Jones — Wed, 21 Oct 2009 03:44:34 GMT

http://types.cs.washington.edu/jsr308/ seems to be talking about a set of type annotations for Java that are similar to those provided in Microsoft Visual C++ by SAL, the Standard Annotation Language.

One thing that the Java annotations have going for them over the SAL is that these annotations are going to be a part of the Java 7 standard, so it’s something that will come with the language no matter who implements it, whereas the C++ SAL extensions are specific to Microsoft. Of course, when I say “no matter who implements it”, I’m not aware of any significant currently supported implementations of Java outside of Sun, so it’s possible that such a statement is necessarily limited.

[Note that the SAL extensions can be included in C++ code that is compiled with other compilers, you just won’t see any benefit from them when using other compilers.]

What do annotations do?

As explained in the blog post that Michael Howard put out when SAL was first made available, these code annotations add something to object and function prototypes. What they add is the ability to turn run-time issues into compile-time errors.

So, for instance, a null pointer dereference, that would be an instant denial of service on your application, is trapped at compile time, because you declared in your function or class prototypes that you expect the pointer not to be null.

Adding these annotations to your code can certainly be a time-consuming task, since you have to revisit old code and add them in by had, recapturing assumptions that you had originally made about objects you reference. That in itself can be a learning experience, of course, and because you will capture a number of outstanding reliability, quality and security bugs, it’s far from being an empty investment.

What do the Java annotations capture?

The first checker that the Java annotations implement is the Nullness checker. This allows you to declare whether you are expecting a reference or value to be null or not. This generally avoids you seeing exceptions through dereferencing null.

The Interning checker prevents you from seeing poor results when comparing two objects (such as two instances of “Integer(2)”) using “==” or “!=”. Without the Interning checker, using “==” to compare two Integer variables each containing an instance of Integer(2) will produce the result ‘false’. This can cause logical processing errors, which the Interning checker will address.

The Mutability (IGJ or Javari) checker allows you to specify that an object reference should not be used to modify the contents of that object.

The Lock checker prevents locking errors by allowing you to declare that objects can only be accessed when guarded by a lock, or to declare that a function can only be called when holding a particular lock.

The Tainted checker allows you to mark an object as coming from an untrusted source (think “user”). Marking some functions as expecting Untainted data will prevent them from being fed Tainted data, and will ensure that other developers accessing such a function will call checking routines to convert the data from Tainted to Untainted before passing it to your functions.

The Linear checker prevents your code from holding more than one reference to objects marked as Linear. Since Java, like C#, likes to copy references to objects, rather than the objects themselves, this checker can prevent you from finding unexpected side-effects from objects being modified through aliases you weren’t expecting.

Further checkers appear to allow you to write your own checkers, but I haven’t got the Java programming chops to really play with these.

Should I include these annotations in my Java projects?

Definitely. Or something like them. Using annotations to define to the compiler some of the expectations you make of your code (a hyped-up interface contract, if you like) allows the compiler to check more deeply into whether those assumptions can hold true throughout your code.

My own experience of SAL-annotated code is that it has allowed me to discover some relatively subtle bugs in my programs. Or bugs that weren’t quite so subtle, but just weren’t jumping out at me.

A quick look at these Java annotations suggests that they will do the same for Java projects. Frankly, the more help you can get from these static analysis tools, the better. Analysis tools don’t catch all problems, and they aren’t a substitute for good programming, but they do provide a second check on your own assumptions that can be very useful.

Previous articles on SAL:

Sometimes It Seems Like Unix(*) Needs to Learn from Windows

Alun Jones — Sun, 27 Sep 2009 03:22:00 GMT

(*) By “Unix”, I mean Linux, Unix, AIX, OS/X, and similar flavours.

Way back when, about twenty or so years ago, I was a Unix admin, and a Unix developer. I had to be both, because I was the only person in the company who could spell Unix.

My favourite game was to go along to presentations for Microsoft Windows ‘new features’ and say “Oh, but hasn’t Unix had that for the last twenty years?”

Sure enough, there were countless things that Windows users and developers were just discovering (TCP/IP, shared libraries, multiple sessions on the same computer) that had been in Unix for some time. Linux was yet to make a mention, but as I’ve moved firmly into the Windows world, and left Unix behind, I’ve pretty much assumed that technologically speaking, if Windows has it, Unix and the like must also have the same functionality.

As I re-engage with Unix and Linux developers and IT professionals in recent months, though, I can see that there are some areas – particularly in security - where Windows is far ahead of the *x operating systems. Here’s a few:

Where’s my EFS?: EFS, the Encrypting File System, is one of Windows’ best-kept secrets. It’s not really a secret, of course, but it acts like one – there are so few people willing to use it, and mostly because they’re scared of or don’t understand it.; EFS allows users (under administrative control and with appropriate recovery measures in place) to choose files to encrypt, and to declare which other users can access the encrypted files.; EFS-encrypted files are encrypted on disk, and the keys cannot be broken simply by mounting an offline attack, because the key for each file is encrypted with users’ public keys, and the private keys are held securely in the users’ certificate store.; What does *x have in response? Whole disk encryption by third-party products (OK, Windows has Bitlocker and any number of third-party products). EFS protects individual files, and is far more fine-grained than the ‘all or nothing’ access of WDE (or FDE, Full Disk Encryption, if you prefer).
Single Certificate Store: This isn’t really a “single” store so much as a predictable location for the certificate store. If you want to read a user’s certificates and keys, you know where to find them (although you generally only have access if you are the user in question. Private keys from the certificate store are protected using the DPAPI, appropriately protecting them (apart from some key recovery scenarios, you have to log in using the password associated with the keys).; Similarly, certificates and keys belonging to the system and its service accounts are also in predictable locations.; This makes life easy for tools that need to scan for certificates due to expire.; Where are certificates and keys stored in *x? All over the place. Generally in “PEM” files, usually (but not always) in the same directory in which the application that installs them is.; How are these private keys protected in *x? There’s sometimes a password to open up the private key from the PEM file, and usually the PEM file has a restrictive access mask on it. [Read further for more problems with this]
Single SSL Library: It’s not uncommon to see several instances of OpenSSL installed on any particular system, whether it’s *x or Windows, if the system runs applications that use OpenSSL.; Windows developers, of course, can simply use the SSL API built in to Windows (CryptoAPI, CAPI and SChannel), and not have to worry about shipping an SSL library with their application, or keeping up with new versions as they come out, or tracking down customers and notifying them of updates to address security flaws (such as the Debian Linux key generation flaw I posted about a while ago).
Single SSL Configuration: If I want to disable SSL v2, or ciphers with fewer than 128 bits, on Windows I can change a few registry settings and know that I’ve fixed every application that uses SChannel. I can even do that remotely, with remote registry editing from a script or group policy tattooing the registry.; To do the same for OpenSSL, it seems that I have to find every application that uses OpenSSL and change the configuration files there.
Data Protection API and configuration file protection: This is the one that really started me on this article.; How do you store a password in a configuration file?; Yes, the ‘right’ security answer is “you don’t”, but that’s naive. The fact is that there are many instances wherein you have to store a password – to access and authenticate to a remote application, or (if you’re using OpenSSL) to open a password-protected PEM or PFX file in order to read out the private key.; On Windows, the Patterns and Practices team have documented how to do this – basically, you use the DPAPI to encrypt the password into the config file, and again to decrypt it back out – and your DPAPI keys are encrypted by your master key, which is derived from your password. The end result is that you can’t get those DPAPI keys without the password.; What do the *x platforms have?; ”Put the password in plain text, and protect it with a restrictive access mask”, is what I’m told. And in a search, I couldn’t find anything better being recommended. OK, one person recommended encoding the password with base64, but that’s hardly a security measure.; Jesper brought up the excellent question of “how is it different?” – in the *x system, the password is marked as only being accessible to the correct user. I was about to answer him when Steve F spoke up for me, and noted that in the DPAPI case, you have to read the file, and then an API has to be called to decrypt the password; in the *x case, you simply have to read the file. There are many many more exploits that allow the reading of a file under privileged rights than there are exploits that allow the execution of code.
Patch Management and Group Policy: Microsoft has done a really good job of implementing enterprise-level management features into their operating systems, from Group Policy and WMI to WSUS and other update management tools.; The *x systems I’ve seen seem to be built from the perspective that each system has its own attendant administrator, who is only too happy to manually deploy patches or tweak settings in line with some policy on a scrap of paper or post-it.

Maybe I’m missing some huge advances, and maybe some of these issues are resolved with a third-party tool – but then, maybe that’s part of the problem too. All of the above are a part of the operating system in Windows, and can be relied on to exist by developers, and their use by applications can be expected by IT professionals.

[Disclaimer: Yes, I know there are still areas where Microsoft needs to learn from Unix and Linux, and perhaps it’d be good if you’d educate me on those, too. This isn’t a “Windows is better than *X” debate, it’s a “hey, even if you think *X is better than Windows, here are some areas *X needs improving in”.]

Edit: There have been some excellent comments posted overnight in response to this article, and as I had hoped, I am mostly still 'in the dark' about what Linux and Unix-like systems offers. I'll be looking at these as I have time, and responding when I can. For now, just let me say that I am impressed to see so much technical content in the responses, and so little of the "fanboy" behaviour that often characterises these discussions.

Would you behave differently in a shared office?

Alun Jones — Wed, 22 Jul 2009 05:09:41 GMT

How would you change your behaviour at work if you knew the person seated one desk over worked for a competitor?

How would your behaviour change if you knew the person one cubicle over was about to work for a competitor?

What if you knew that your cubicle neighbour was going to lose her job (be fired or laid off) in the next six months? Do you think she’d be looking to work in a different industry, or the one where she had the most recent experience?

What if the economic situation was such that you just couldn’t be sure who in your office would still be with you a year from now?

How would you protect your data then?

My point is less about pointing out that the current economic situation seems very like this harsh threatening landscape, but to ask you to consider that the answer to this question is actually the answer you should give all the time.

A recent study from Ponemon stated that six out of ten departing employees will take data with them as they leave, whether that’s customer data or business intelligence. Why do they do this? Well, we could get into the whole motivation of why, but the real answer is simple:

Because they can, and because they think they can benefit from doing so. Not because they won’t get caught – because, really, what are you going to do, fire them?

Behave (and design!) as if you’re in an open environment.

Design your data and processes around the idea that important, private, or proprietary data should only rest with individuals or in stores for as long as it is needed to do the job at hand.

After that, then what?

If you no longer need it, or can reconstruct or re-collect it when you next need it, why not just destroy the data?

If you need it, return it to a secure data store, from which it can’t be fetched again without business need, and appropriate authorisation.

If you never needed it in the first place, why collect it at all?

Protecting systems, networks, applications – that’s just resiliency and protection of a few thousand dollars of assets. The real money – and the real requirement for security protection – is in the data.

Act (and architect!) like the data is, AND isn’t, yours.

I used to say that people should “act like the data isn’t yours in the first place” – makes logical sense, doesn’t it?

Sure, if you think that way – if you think that you should be careful with other people’s possessions that they’ve loaned to you.

Over several jobs and several years, I’ve come to realise that we aren’t all of the same species of thought. Some of us are careless with other people’s possessions, and are only concerned with taking care of what’s ours.

So, my explanation has changed – now, the explanation is still that the data doesn’t belong to us, but we have possession of it, and therefore we, as application designers and architects, have a double requirement to be careful with it. We must protect it because it isn’t ours, and we must protect it because it is in our care. To be loose with other people’s data would be to cause them damage, and to be loose with data in our care would be to cause our business damage by reducing the value that we get from holding that data.

How FTP Data Connections Work Part 2 (OR: Fun With Port 20)

Alun Jones — Tue, 14 Jul 2009 06:48:26 GMT

As we mentioned in the 1st part of this series, FTP is a more complex protocol than many, using one control connection and one data connection.

A recap of the first post…

In typical Stream Mode operation, a new data connection is opened and closed for each data transfer, whether that’s an upload, a download, or a directory listing. To avoid confusion between different data connections, and as a recognition of the fact that networks may have old packets shuttling around for some time, these connections need to be distinguishable from one another.

In the previous article, we noted that two network sockets are distinguished by the five elements of “Local Address”, “Local Port”, “Protocol”, “Remote Address”, and “Remote Port”. For a data connection associated with any particular request, the local and remote addresses are fixed, as the addresses of the client and server. The protocol is TCP, and only the two ports are variable.

For a PASV, or passive data connection, the client-side port is chosen randomly by the client, and the server-side port is similarly chosen randomly by the server. The client connects to the server.

For a PORT, or active data connection, the client-side port is chosen randomly by the client, and the server-side port is set to port 20. The server connects to the client.

All of these work through firewalls and NAT routers, because firewalls and NAT routers contain an Application Layer Gateway (ALG) that watches for PORT and PASV commands, and modifies the control (in the case of a NAT) and/or uses the values provided to open up a firewall hole.

Isn’t there a totally predictable data connection?

For the default data connection (what happens if no PORT or PASV command is sent before the first data transfer command), the client-side port is predictable (it’s the same as the source port the client used when connecting the control channel), and the server-side port is 20. Again, the server connects to the client.

Because firewalls and NATs open up a ‘reverse’ hole for TCP sockets, the default data port works with firewalls and NATs that aren’t running an ALG, or whose ALG cannot scan for PORT and PASV commands.

Why would an ALG stop scanning for PORT and PASV commands?

There are a couple of reasons – the first is that it doesn’t know that the service connected to is running the FTP protocol. This is common if the server is running on a port other than the usual port 21.

The second reason is that the FTP control connection doesn’t look like it contains FTP commands – usually because the connection is encrypted. This can happen because you’re tunneling the FTP control connection through an encrypted tunnel such as SSH (don’t laugh – it does happen!), or hopefully it’s because you’re running FTP over SSL, so that the control and data connections can be encrypted, and you can authenticate the identity of the FTP server.

So how do you get FTP over SSL to work through a firewall?

In the words of Deep Thought: “Hmm… tricky”.

There are a couple of classic solutions:

Allow PASV data connections, select a wide range of ports, and open that range for incoming traffic from all external addresses in your firewall configuration; hope that your FTP server can be configured to use only that range of ports (WFTPD Pro can), and that it has protections against traffic stealing attacks (again, WFTPD Pro has). Still, this option seems really risky.
Block all PASV connections, and make the clients responsible for opening up holes in their firewalls. If you’re convinced the risk is too great to do this on your server, how does it look to convince your users that they should accept that risk?
After you’ve authenticated the server and provided your username and password in the encrypted control connection, issue the “CCC” (Clear Control Channel) command, to switch the control connection back into clear-text. I dislike this as a solution, because it requires the ALG pay attention to a lot of SSL traffic in the hope that there might be clear-text coming up, and because you may want the control channel to remain encrypted.

Awright, clever clogs, you solve the problem.

The astute reader can probably see where I’m going with this.

The default data port is predictable – if the client connects from port U to port L at the server (L is usually 21), then the default data port will be opened from port L-1 at the server to port U at the client.

The default data port doesn’t need the firewall to do anything other than allow reverse connections back along the port that initiated the connection. You don’t need to open huge ranges at the server’s firewall (in fact you should be able to simply open port 21 inbound to your server).

The default data port is required to be supported by FTP servers going back a long way- at least a couple of decades. Yes, really, that long.

If it’s that simple, why isn’t everyone doing it?

Good point, that, and a great sentence to use whenever you wish to halt innovation in its tracks.

Okay, it’s obvious that there are some drawbacks:

In stream mode, the data transfer is ended by closing the stream. This means that you have to open a new control connection. Not good, given the number of round-trips you need for a logon, and the work needed to start an SSL connection.
Most FTP clients view the default data connection as, at best, a fail-over in case the PORT or PASV commands fail to work. Obviously, that means it’s not likely to be a well-tested or favoured solution on these clients.

Even with those drawbacks, there are still further solutions to apply – the first being to use Block-mode instead of Stream-mode. In Stream-mode, each data transfer requires opening and closing the data connection; in Block-mode, which is a little like HTTP’s chunked mode, blocks of data are sent, and followed by an “EOF” marker (End of File), so that the data connection doesn’t need to be closed. If you can convince your FTP client to request Block-mode with the default data connection, and your FTP server supports it (WFTPD Pro has done so for several years), you can achieve FTP over SSL through NATs and firewalls simply by opening port 21.

For the second problem, it’s worth noting that many FTP client authors implemented default data connections out of a sense of robustness, so default data connections will often work if you can convince the PORT and PASV commands to fail – by, for instance, putting restrictive firewalls or NATs in the way, or perhaps by preventing the FTP server from accepting PORT or PASV commands in some way.

Clearly, since Microsoft’s IIS 7.5 downloadable FTP Server supports FTPS in block mode with the default data port, there has been some consideration given to my whispers to them that this could solve the FTP over SSL through firewall problem.

Other than my own WFTPD Explorer, I am not aware of any particular clients that support the explicit use of FTP over SSL with Block-mode on the default data connection – I’d love to hear of your experiments with this mode of operation, to see if it works as well for you as it does for me.

How FTP Data Connections Work Part 1 (OR: Don’t Open Port 20 in your Firewall!)

Alun Jones — Thu, 09 Jul 2009 06:18:42 GMT

This will be the first of a couple of articles on FTP, as I’ve been asked to post this information in an easy-to-read format in a public place where it can be referred to. I think my expertise in developing and supporting WFTPD and WFTPD Pro allow me to be reliable on this topic. Oh, that and the fact that I’ve contributed to a number of RFCs on the subject.

Enough TCP to be dangerous

First, a quick refresher on TCP – every TCP connection can be thought of as being associated with a “socket” at each device along the way – from one computer, through routers, to the other computer. The socket is identified by five individual items – the local IP address, the local port, the remote IP address, the remote port, and the protocol (in this case, the protocol is TCP).

Firewalls are essentially a special kind of router, with rules not only for how to forward data, but also rules on connection requests to drop or allow. Once a connection request is allowed, the entire flow of traffic associated with that connection request is allowed, also – any traffic flow not associated with a previously allowed connection request is discarded.

When you set up a firewall to allow access to a server, you have to consider the first segment – the “SYN”, or connection request from the TCP client to the TCP server. The rule can refer to any data that would identify the socket to be created, such as “allow any connection request where the source IP address is 10.1.1.something, and the destination port is 54321”.

Typically, an external-facing firewall will allow all outbound connections, and have rules only for inbound connections. As a result, firewall administrators are used to saying things like “to enable access to the web server, simply open port 80”, whereas what they truly mean is to add a rule that applies to incoming TCP connection requests whose source address and source port could be anything, but whose destination port is 80, and whose destination address is that of the web server.” This is usually written in some short hand, such as “allow tcp 0.0.0.0:0 10.1.2.3:80”, where “0.0.0.0” stands for “any address” and “:0” stands for “any port”.

Firewall rules for FTP

For an FTP server, firewall rules are known to be a little trickier than for most other servers.

Sure, you can set up the rule “allow tcp 0.0.0.0:0 10.1.2.3:21”, because the default port for the control connection of FTP is 21. That only allows the control connection, though.

What other connections are there?

In the default transfer mode of “Stream”, every file transfer gets its own data connection. Of course, it’d be lovely if this data connection was made on port 21 as well, but that’s not the way the protocol was built. Instead, Stream mode data connections are opened either as “Active” or “Passive” connections.

Active and Passive Data Connections

The terms "Active" and "Passive" refer to how the FTP server connects. The choice of connection method is initiated by the client, although the server can choose to refuse whatever the client asked for, at which point the client should fail over to using the other method.

In the Active method, the FTP server connects to the client (the server is the “active” participant, the client just lies back and thinks of England), on a random port chosen by the client. Obviously, that will work if the client's firewall is configured to allow the connection to that port, and doesn't depend on the firewall at the server to do anything but allow connections outbound. The Active method is chosen by the client sending a “PORT” command, containing the IP address and port to which the server should connect.

In the Passive method, the FTP client connects to the server (the server is now the “passive” participant), on a random port chosen by the server. This requires the server's firewall to allow the incoming connection, and depends on the client's firewall only to allow outbound connections. The Passive method is chosen by the client sending a “PASV” command, to which the server responds with a message containing the IP address and port at the server that the client should connect to.

The ALG comes to the rescue!

So in theory, your firewall now needs to know what ports are going to be requested by the PORT and PASV commands. For some situations, this is true, and you need to consider this – we’ll talk about that in part 2. For now, let’s assume everything is “normal”, and talk about how the firewall helps the FTP user or administrator.

If you use port 21 for your FTP server, and the firewall is able to read the control connection, just about every firewall in existence will recognise the PORT and PASV commands, and open up the appropriate holes. This is because those firewalls have an Application Level Gateway, or ALG, which monitors port 21 traffic for FTP commands, and opens up the appropriate holes in the firewall. We’ve discussed the FTP ALG in the Windows Vista firewall before.

So why port 20?

Where does port 20 come in? A rather simplistic view is that administrators read the “Services” file, and see the line that tells them that port 20 is “ftp-data”. They assume that this means that opening port 20 as a destination port on the firewall will allow FTP data connections to flow. By the “elephant repellant” theory, this is proved “true” when their firewalls allow FTP data connections after they open ports 21 and 20. Nobody bothers to check that it also works if they only open port 21, because of the ALG.

OK, so if port 20 isn’t needed, why is it associated with “ftp-data”? For that, you’ll have to remember what I said early on in the article – that every socket has five values associated with it – two addresses, two ports, and a protocol. When the data connection is made from the server to the client (remember, that’s an Active data connection, in response to a PORT command), the source port at the server is port 20. It’s totally that simple, and since nobody makes firewall rules that look at source port values, it’s relatively unimportant. That “ftp-data” in the Services file is simply so that the output from “netstat” has a meaningful service name instead of “:20” as a source port.

Coming up in part 2…

Next time, we’ll expand on this topic, to go into the inability of the ALG to process encrypted FTP control traffic, and the resultant issues and solutions that face encrypted FTP.

Microsoft TechFest

Alun Jones — Tue, 03 Mar 2009 23:45:49 GMT

Last week, I went to Microsoft’s TechFest as part of their “Public Day”. This is the first time MVPs as a group have been invited to this event, and although it’s clear we missed some of the demonstrations that are not public-ready, this is something that I hope can be extended to us in future, even if only to Washington-state MVPs

For general news links on MS TechFest 2009, you can search news.google.com for “TechFest”. Here’s a couple of samples:

http://www.king5.com/video/index.html?nvid=335707 – I didn’t see these guys there.

http://www.guardian.co.uk/technology/blog/2009/feb/25/microsoft-software - I bumped into this guy.

I also saw Chris Pirillo there from LockerGnome and Chris.Pirillo, but he hasn’t written anything yet. I only mention him because it’s about time that I thanked him for being one of the earliest online writers (they were called “e-Zines” back then, apparently) to mention WFTPD in his column. Sadly, I don’t have a copy to remember what it is that he said :(

Apologies to anyone who expected to reach me by email that day – the usual computers spread around the Microsoft Conference Centre for email and web browsing were missing, possibly because the Press were there, and they’ll steal anything that isn’t nailed down, before coming back with crowbars.

So, here’s some description of the things I saw, ranging from the exciting and relevant to the “why is Microsoft spending money on that?” [Note that this is not meant to be disrespectful of ‘pure research’ – often, today’s “useless meanderings” become tomorrows product – WFTPD itself started from a momentary “how hard can it really be?” lapse in my own judgement, followed by a little research and a lot of effort.]

Specification Inference for Security: To improve focus on potential security faults in static analysis tools, this is a toolset whose approach is to divide functions into Sources, Sinks and Sanitizers (although that alliteration is liable to lead to confusion) – Sources generate untrustworthy data from input, Sinks consume data that they trust will fit their expectations, and Sanitizers transform the data along the way, ideally making sure that it goes from untrustworthy to trusted. Thinking in terms of a SQL injection, the Source would be a web server receiving input from a user containing a SQL command, the Sink would be the SQL server, and the Sanitizer would be whatever code packages the input and determines whether to pass it to the SQL server, and what changes to make (such as requiring proper quoting, or using a stored proc or parameterized query). Once these categorizations have been made, the static analysis tool can check that Sanitizers actually do sanitize – rather than having to try and analyse every function for possible sanitization. http://research.microsoft.com/merlin
Concurrency Analysis Platform and Tools: Enhances your test tool set by allowing tests to run with multiple permutations of concurrency. Race conditions are usually caught by users, or in production environments, because the environments cause different threads or processes to run at different speeds – with this toolkit, you get to try out multiple combinations of execution sequence, so that you are more likely to trigger the race condition. Of course, you still have to write tests that consider the prospect of doing more than one thing at a time, and because there are a large number of concurrency permutations, it’s not a turn-key solution, but it does allow you to debug concurrency issues more methodically, and catch those that appear more frequently. http://research.microsoft.com/chess - and this one’s available for download as an add-on to Visual Studio!
Lightweight Software Transactions for Games: Not just for games, the ORCS platform (Object-based Runtime for Concurrent Systems) makes coding multi-threaded applications easier and more problem-free. http://research.microsoft.com/orcs
Closed-Loop Control Systems for the Data Center: Power consumption monitoring and control allows for servers to be brought online or offline as computing demands change, so that as usage ramps up, more servers are turned on, and as usage declines, servers are turned off. I don’t think this is entirely original.
Algorithms and Cryptography: Cryptographic solutions with leakage. Unfortunately, the lady who came up with this wasn’t on hand to discuss her work, and her husband standing in for her didn’t seem to understand much about it either. The poster claimed an algorithm whereby you could leak some of your key to an attacker without reducing the strength of the key. I’m not sure how this works, or where it differs from having redundant information in the keys, or something like M of N crypto, but maybe it’ll be something that will affect our field in the years to come.
Opinion Search: Full of marketing jargon and too dense for me to penetrate, this is something that we could potentially use in the business side of Expedia, making use of customer opinions to allow search results to match the user’s opinion against the opinions of others with whom they have consistently agreed in the past, and can be expected to do so in the future.
Low-Power Processors in the Data Center: Using Netbook processors for data processing in a parallel environment allows for significant power savings.
Audio Spatialisation and AEC for Teleconferencing: Relying on the rise of computer-phone integration, and the fact that most computers have stereo speakers, this is a system for teleconferencing where different parties are given a different spot in the stereo spatialisation. Makes it much easier to tell who’s talking.
SecondLight: Surface computing taken to another level, literally. The surface on which images are projected is usually a light diffuser, so that the image effectively “stays” on the surface. In this implementation, the surface is rapidly switched between diffuse and transparent, so that you can use a secondary diffuser surface on top, which shows a different image. You have to see a demonstration to understand it - mms://wm.microsoft.com/ms/research/projects/secondlight-cambridge/secondlight.wmv - it’s a little flickery, in real-life too, but the team assured me that it can be made less so.
Commute UX – Dialog System for In-Car Infotainment: Will this stop executives requesting shorter passwords for unlocking their phone while driving? Probably not.
Back-of-Device Touch Input: Anyone using an iPhone or similar touch-based device will be familiar with the issue that your fingers are covering the image you’re trying to manipulate. By putting a sensor panel on the back of the device, you can reduce the size of the display without making it impossible to read while you select.
Augmented Reality: Combining GPS location with stock footage of the place you’re in, this is all about placing extra information into a view (such as a cell-phone with a video camera, or maybe eventually a heads-up display in glasses / goggles) of the world around you, by recognising where you are. Can be used for games, directions, advertising, city guides, or post-it notes without the paper.
Recognizing characters written in the Air: Entertaining just to watch people dragging an apple around to make letters on a screen in front of them. Probably more useful in the mode where the lid of an OHP pen is the “bright spot of strong solid colour” being tracked in mid-air.
Colour-structured Image Search: Draw a rough colour picture of the image you want to see, and get a page of search results from around the web. The demonstrations consisted of drawing pictures of flowers, or flags, or a sunset. I foresee widespread abuse once deployed, although it will mean that people who usually draw on bathroom walls will be moving their talents online.

If Your GPS Worked Like An Information Security Team

Alun Jones — Sat, 07 Feb 2009 03:38:00 GMT

… it would fend off dangerous drivers from hitting you.

… it would give you regular statistics on the number of accidents on your daily route, so you could make decisions to avoid newly bad parts of town.

… it would help you plan your route to avoid the sorts of areas that have bad accidents, so that you would not be a part of one.

… it would give you hints on how to be a better driver, and train you every so often to keep your driving skills sharp.

… it would observe other accidents and gauge trends, to advise you what previously safe driving habits to avoid.

… it would co-operate with you in planning a trip, to help you choose the quickest, safest route to your destination.

… it would teach you how to read maps, so you could make safe routing decisions for yourself.

… it would work with your mechanic, so that every time your car went in for a service, it would come back safer.

… it would work with the police to let them know where the bad parts of town are, so that they could be cleaned up.

… it would let you know any time you were about to run a stop-light or exceed the speed limit, so that you could make an informed decision, rather than accidentally break the law and get pulled over.

Yes, it’s another argument by analogy, which is something I dislike in general – but I see too many times when the Information Security Team is perceived as a “STOP” sign. The Security Team is employed by the same organisation as you, and therefore has the same business goals – just a different focus. Its focus is to ensure that the company can carry on doing business without interruption by hackers, crackers, viruses, spyware, regulatory and contractual damages, or public relations disasters caused by inappropriate data disclosure.

I think a GPS is a better analogy, then – if you follow the Security Team's advice, or at least listen to it, you’ll be aware of the risks of the different ways to your –our- destination.

When “All” isn’t everything you need – Terminal Services Gateway certificates.

Alun Jones — Tue, 03 Feb 2009 01:47:10 GMT

Setting up Terminal Services Gateway on Windows Server 2008 the other day.

It’s an excellent technology, and one I’ve been waiting for for some time – after all, it’s fairly logical to want to have one “bounce point” into which you connect, and have your connection request forwarded to the terminal server of your choice. Before this, if you were tied to Terminal Services, you had to deal with the fact that your terminal connection was taking up far more traffic than it should, and that the connection optimisation settings couldn’t reliably tell that your incoming connection was at WAN speeds, rather than LAN speeds.

But to get TS Gateway working properly, it needs a valid server certificate that matches the name you provide for the gateway, and that certificate needs to be trusted by the client. Not usually a problem, even for a small business operating on the cheap – if you can’t afford a third-party trusted certificate, there are numerous ways to deploy a self-signed certificate so that your client computers will trust it.

I have a handily-created certificate that’s just right for the job.

I ran into a slight problem when I tried to install the certificate, however.

The certificate isn’t there! In this machine, it isn’t even possible for me to “Browse Certificates” to find the certificate I’m looking for. On another machine, the option is present:

That’s promising, but my certificate doesn’t appear in the list of certificates available for browsing:

I checked in the Local Computer’s Personal Certificates store, which is where this certificate should be, and sure enough, on both machines, it’s right there, ready to be used by TSG.

So, why isn’t TSG offering this certificate to me to select? The clue is in the title.

The certificate that doesn’t show up is the one with “Intended purposes: <All>” – the cert that shows up has only “Server Authentication” enabled. Opening the certificate’s properties, I see this:

Simply selecting the radio-button “Enable only the following purposes”, I click “OK”:

And now, back over in the TSG properties, when I Browse Certficates, the Install Certificate dialog shows me exactly the certificates I expected to see:

This isn’t a solution I would have expected, and if that one certificate hadn’t shown up there, I wouldn’t have had the one clue that let me solve this issue.

Hopefully my little story will help someone solve this issue on their system.

Debugging SSTP error -2147023660

Alun Jones — Wed, 28 Jan 2009 14:57:45 GMT

Setting up an SSTP (Secure Socket Tunneling Protocol) connection earlier, I encountered a vaguely reminiscent problem. [SSTP allows virtual private network – VPN – connections between clients running Vista Service Pack 1 and later and servers running Windows Server 2008 and later, using HTTP over SSL, usually on port 443. Port 443 is the usual HTTPS port, and creating a VPN over just that port and no other allows it to operate over most firewalls.]

The connection just didn’t seem to want to take, even though I had already followed the step-by-step instructions for setting up the SSTP server. I thought I had resolved the issue originally by ensuring that I installed the certificate (it was self-signed) in the Trusted Roots certificate store. [If the certificate was not self-signed, I would have ensured that the root certificate itself was installed in Trusted Roots]

The first thing I did was to check the event viewer on the client, where I found numerous entries.

I found error -2147023660 in the Application event log from RasClient. This translates to 0x800704D4, ERROR_CONNECTION_ABORTED. That was pretty much the same information I already had, that the connection was being prevented from completing. So I visited the server to see if there was more information there.

On the server, I couldn’t find any entries from the time around when I was trying to connect. Not too good, because of course that’s where you’re going to look. In some cases, particularly errors that Microsoft thinks are going to happen too frequently, the conditions are checked at boot-time, and an error reported then, rather than every time the service is called on to perform an action.

Fortunately, it hadn’t been that long since I last booted (and I had a hint or two from the RRAS team at Microsoft), so my eyes were quickly drawn to an Event with ID 24 in the System Log, sourced at Microsoft-Windows-RasSstp. The text said:

The certificates bound to the HTTPS listener for IPv4 and IPv6 do not match. For SSTP connections, certificates should be configured for 0.0.0.0:Port for IPv4, and [::]:Port for IPv6. The port is the listener port configured to be used with SSTP.

Note that this happens even if your RRAS server isn’t configured to offer IPv6 addresses to clients.

So, here’s some documentation on event ID 24 :

http://technet.microsoft.com/en-us/library/cc733844.aspx

This is one of those nasty areas where there is no user interface other than the command-line. Don’t get me wrong, I love being able to do things using the command line, because it’s easy to script, simple to email to people who need to implement it, and it works well with design-approve-implement processes, where a designer puts a plan together that is approved by someone else and finally implemented by a third party. With command-line or other scripts, you can be sure that if the script didn’t change on its way through the system, then what was designed is what was approved, and is also what was implemented.

But it’s also easy to get things wrong in a script, whereas a selection in a UI is generally much more intuitive. It’s particularly easy to get long strings of hexadecimal digits wrong, as you will see when you try and follow the instructions above. Make sure to use copy-and-paste when assembling your script, and read the output for any possible errors.

The CWE Top 25 Programming Mistakes

Alun Jones — Thu, 22 Jan 2009 12:39:00 GMT

I’ve read some debate about the top 25 programming mistakes as documented by the CWE (Common Weakness Enumeration) project, in collaboration with the SANS Institute and the MITRE . That the list isn’t complete, that there are some items that aren’t in the list, but should be, or vice-versa.

I think we should look at the CWE top-25 as something like the PCI Data Security Standard – it’s not the be-all and end-all of security, it’s not universally applicable, it’s not even a “gold standard”. It’s just the very bare minimum that you should be paying attention to, if you’ve got nowhere else to start in securing your application.

As noted by the SANS Institute, the top 25 list will allow schools and colleges to more confidently teach secure development as a part of their classes.

I personally would like to see a more rigorous taxonomy, although in this field, it’s really hard to do that, because in large part it’s a field that feeds off publicity – and you just can’t get publicity when you use phrases like “rigorous taxonomy”. Here’s my take on the top 25 mistakes, in the order presented:

Insecure Interaction Between Components

“These weaknesses are related to insecure ways in which data is sent and received between separate components, modules, programs, processes, threads, or systems.”

CWE-20: Improper Input Validation

What’s proper input validation? Consider the thought that there is no input, no output, only throughput. A string is received at the browser, and turned into a byte encoding; this byte encoding is sent to the web server, and possibly re-encoded, before being held in storage, or passed to a processing unit. For every input, there is an output, even if it’s only to local in-memory storage.
Validating the input portion falls broadly into two categories – validating for length, and validating for content. Validating for length seems simple – is it longer than the output medium is expecting? You should, however, check your assumptions about an encoding – sometimes encodings will add, and sometimes they will remove, counts of the members of the sequence – and sometimes they may do both.
Validating for content can similarly be broken into two groups – validating for correctness against the encoding expected, and then validating for content as to “business logic” (have you supplied a telephone number with a square-root sign or an apostrophe in it, say). Decide whether to strip invalid codes, or simply to reject the entire transaction. Usually, it is best (safest) to reject the entire transaction.

CWE-116: Improper Encoding or Escaping of Output

The other part of “throughput validation” – and while we constantly tell programmers that they should refuse to trust input, that should not be held as an excuse to produce untrustworthy output. There are many times when your code is trusted to produce good quality output. Some examples:

When you write a web application visited by a user, that user trusts you not to forward other people’s code on to them. Just your own, and that of your business partners. [See Cross-Site Scripting, below]
When your application is used internally [See SQL Injection, below]

Be conservative in what you send – make sure it rigorously follows whatever protocol or design-time contract has been agreed to. And above all, when sending data that isn’t code, make sure to encode it so that it can’t be read as code!

CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection')

SQL Injection is a throughput validation issue. In its essence, it involves an attacker who feeds SQL command codes into an interface, and that interface passes them on to a SQL database server.
This is almost an inexcusable error, as it is relatively easy to fix. The fix is usually hampered somewhat in that the SQL database server is required to trust the web server interface code, but that means only that the web server interface code must either encode, or remove, elements of the data that is being passed in the SQL command sequence being sent to the server. The most reliable way to do this is to use parameterised queries or stored procedures. Avoid building SQL commands through concatenation at almost any cost.

CWE-79: Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')

I hate the term “cross-site scripting”. It’s far easier to understand if you just call it “HTML injection”. Like SQL injection, it’s about an attacker injecting HTML code into a web page (or other HTML page) by including it as data, in such a way that it is provided to the user as code.
Again, a throughput content validation issue, anything that came in as data and needs to go out as a part of an HTML page should be HTML encoded, ideally so that only the alphanumerics are unencoded.

CWE-78: Failure to Preserve OS Command Structure (aka 'OS Command Injection')

Like SQL injection, this is about generating code and including data. Don’t use your data as part of the generation of code.
There are many ways to fix this kind of an issue – my favourite is to save the data to a file, and make the code read the file. Don’t derive the name or location of the file from the user-supplied data.

CWE-319: Cleartext Transmission of Sensitive Information

What’s sensitive information? You decide, based on an analysis of the data you hold, and a reading of appropriate laws and contractual regulations. For example, with PCI DSS, sensitive information would include the credit card number, magnetic track data, and personal information included with that data. Depending on your state, personal contact information is generally sensitive, and you may also decide that certain business information is also sensitive.
Seriously, SSL and IPsec are not significant performance drains – if your system is already so overburdened that it cannot handle the overhead of encrypting sensitive data, you are ALREADY too slow, and only providence has saved you from problems.
Especially where the data is not your own, make an informed decision as to whether you will be communicating in clear text.

CWE-352: Cross-Site Request Forgery (CSRF)

Another confusing term, CSRF refers to the ability of one web page to send you HTML code that your browser will execute against another web page. This really is cross-site, and forges requests that look to come from the user, but really come from a web page being viewed in the user’s browser.
The fix for this is that every time you display a form (or even a solitary button, if that button’s effects should be unforgeable), you should include a hidden value that contains a random number. Then, when the “submit” (or equivalent) button is pressed, this hidden value will be sent back with the other contents of the form. Your server must, of course, validate this number is correct, and must not allow the number to be long-lived, or be used a second time. A simple fix, but one that you have to apply to each form.
This really falls under a category of guaranteeing that you are talking to the user (or the user’s trusted agent), and not someone pretending to be the user. Related to non-repudiation.

CWE-362: Race Condition

Race conditions refer to any situation in which the execution of two parallel threads or processes behaves differently when the order of execution is altered. If I tell my wife and son to go get a bowl and some flour, and to pour the flour into the bowl, there’s going to be a mess if my wife doesn’t get the bowl as quickly as my son gets the flour. Similarly, programs are full of occasions where a precedence is expected or assumed by the designer or programmer, but where that precedence is not guaranteed by the system.
There are books written on the topic of thread synchronisation and resource locking, so I won’t attempt to address fixing this class of issues.

CWE-209: Error Message Information Leak

Be helpful, but not too helpful. Give the user enough information to fix his side of the error, but not so much that he has the ability to learn sensitive information from the error message.
“Incorrect user name or password” is so much better than “Incorrect password for that user name”.
“Internal error, please call technical support, or wait a few minutes and try again” is better than “Buffer length exceeded at line 543 in file c:\dev\web\creditapp\cardcruncher.c”
Internal information like that should be logged in a file that is accessible to you when fixing your system, but not accessible to the general end users.

Risky Resource Management

“The weaknesses in this category are related to ways in which software does not properly manage the creation, usage, transfer, or destruction of important system resources.”

CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer

The old “buffer overflow” – a throughput length validation issue. Any time you take data from one source and place it into another destination, you have to reliably predict whether the destination is large enough to hold it, and you also have to decide what you will do if it is not.
Don’t rely solely on .NET or Java “protecting you from buffer overruns” – when you try and access an element outside of a buffer’s limits, they will simply throw an exception – crashing your program dead in its tracks. This in itself could cause half-complete files or other communications, which could feed into and damage other processes. [And simply catching all exceptions and continuing blindly is something I’ve complained about before]

CWE-642: External Control of Critical State Data

By “Critical State Data”, this refers to information about where in the processing your user is. The obvious example of bad external control of critical state data is sending the price to the user, and then reading it back from the user. It obviously isn’t too hard from an attacker to simply modify the value before sending it to the server.
Other examples of poorly chosen state being passed includes the use of customer ID numbers in URLs, in such a way that it is obvious how to select a different customer’s number.
State data such as this should generally be held at the server, and a ‘reference’ value exchanged to allow the server to regain state when a user responds. If this value is populated among users sufficiently sparsely, it’s close to impossible for an attacker to steal someone else’s state.

CWE-73: External Control of File Name or Path

This is related to forced-browsing, path-traversal, and other attacks. The idea is that any time you have external paths (such as URLs) with a direct 1:1 relationship to internal paths (directories and paths), it is usually possible to pass path control from the external representation into the internal representation.
Make sure that all files requested can only come from a known set of files; disable path representations (such as “..”, for ‘parent directory’) that your code doesn’t actually make use of.
Instead of trying to parse the strings yourself to guess what file name the operating system will use, always use the operating system to tell you what file name it’s going to access. Where possible, open the file and then query the handle to see what file it really represents.

CWE-426: Untrusted Search Path

Windows’ LoadLibrary is the classic example of this flaw in design – although the implicit inclusion of the current directory in Windows’ execution PATH searched is another.
When writing programs, you can only trust the code that you load or call if you can verify where you are loading or calling it from.
A favourite trick at college was to place ‘.’ at the front of your path, add a malicious shell file called ‘rm’, and invite a system administrator to show you how to kill a print job. The “lprm” command he’d run would call “rm”, and would run the local version, rather than the real command. Bingo, instant credentials!
Don’t search for code that you trust – know where it is, and if it isn’t there, fail.

CWE-94: Failure to Control Generation of Code (aka 'Code Injection')

I find it hard to imagine the situation that makes it safe to generate code in any way based off user input.
Perhaps you could argue that this is what you do when you generate HTML that contains, as part of its display, user input. OK then, the answer here is to properly encode that which you embed, so that the code processor cannot become confused as to what is code and what is data.

CWE-494: Download of Code Without Integrity Check

Either review the code that you download, or insist that it is digitally signed by a party with whom you have contracted for that purpose. Otherwise you don’t know what you are downloading or what you are executing.

CWE-404: Improper Resource Shutdown or Release

This covers a large range of issues:

Don’t “double-free” resources. Make sure you meticulously enforce one free / delete for every allocation you make. Otherwise, you wind up releasing a resource that you wanted to hang onto, or you may crash your program.
If the memory you’re about to release (or file you’re about to close) contained sensitive information, make sure it is wiped before release. Verify in the release build that the optimiser hasn’t optimised away this wiping!
Make sure you release resources when they are no longer in use, so that there are no memory leaks or other resource overuse problems that will lead to your application becoming bloated and fragile.

CWE-665: Improper Initialization

Lazy languages like Javascript, where a mistype becomes an instant variable assignment, should be avoided.
Define all variables’ types – no “IMPLICIT INTEGER*4 (I-N)” (Am I showing my age?)
Put something into your variables, so that you know what’s there. Don’t rely on the compiler unless the compiler is documented to guarantee initialisation.
By “variable”, I mean anything that might act like a variable – stretches of memory, file contents, etc.

CWE-682: Incorrect Calculation

Again, a multitude of sins:

“should have used sin, but we actually used cos”
divide by zero – or some similar operation – that causes the program to halt
length validation / numeric overflow – in a single byte, 128 + 128 = 0

As you can see, a denial of service can definitely occur, as can remote execution (usually a result of calculating too short a buffer, as a result of numeric overflow, and then overflowing the buffer itself)
Don’t underestimate the possible results of just plain getting the answer wrong – cryptographic implementations have been brought to their knees (and resulted in approving untrustworthy access) because they couldn’t add up properly.

Porous Defenses

“The weaknesses in this category are related to defensive techniques that are often misused, abused, or just plain ignored.”

CWE-285: Improper Access Control (Authorization)

This one pretty much speaks for itself. There’s public parts of your application, and there’s non-public parts. Make sure that you have to provide authentication before crossing that boundary, and make sure that the user account verified in authentication is the one that’s used for authorisation to access resources.
Carry user authentication information around carefully, without letting it be exposed to other forms of attack, but also to make sure that the information is available the next time you need to authorise access to resources.

CWE-327: Use of a Broken or Risky Cryptographic Algorithm

Translation – get a crypto expert to manage your crypto. [Note – this is why I recommend using CryptoAPI rather than OpenSSL, because you have to be your own expert to use OpenSSL.]
New algorithms arise, and old ones become obsolete. In the case of cryptographic algorithms, obsolete means “no longer effectively cryptographic”. In other words, if you use an old algorithm, or a broken algorithm, or don’t use an existing algorithm the right way, your data isn’t as protected as you thought it was.
Where possible, use a cryptographic framework such as SSL, where the choice of cryptographic algorithms available can be adjusted over time to deal with changing realities.

CWE-259: Hard-Coded Password

If there’s a hard-coded password, it will be discovered. And when discovered, it will be disseminated, and then you have to figure out how to get the message out to all of your users that they can now be owned because of your application. Not an easy conversation to have, at a guess.
This is a “just don’t do it” recommendation, not a “do it this way” or “do it that way”.

CWE-732: Insecure Permission Assignment for Critical Resource

If a low-privilege user can lock, or corrupt, a resource that is required for high-importance transactions, you’ve created an easy denial-of-service.
If a low-privilege user can modify something that is used as a basis for trust assignments, there’s an elevation of privilege attack.
And if a low-privilege user can write to your code base, you’re owned.

CWE-330: Use of Insufficiently Random Values

Give me a random number. 7. Give me another random number. 7. And another? 7.
How do you tell if a number is random enough? You hire a mathematician to do a statistical analysis to see if the next number is predictable if you know any or all of the previous numbers.
This mostly ties into CWE-327, don’t do your own crypto if you’re not a crypto expert (and by the way, you’re not a crypto expert). However, if you’re hosting a poker web site, it’s pretty important to be able to shuffle cards in an unpredictable manner!
Remember that the recent Kaminsky DNS attack, as well as the MD5 collision issues, could have been avoided entirely by the use of unpredictable numbers.

CWE-250: Execution with Unnecessary Privileges

Define “unnecessary”? No, define “necessary”. That which is required to do the job. Start your development and testing process as a restricted user. When you run into a function that fails because of lack of privileges, ask yourself “is this because I need this privilege, or can I continue without?”
Too many applications have been written that ask for “All” access to a file, when they only need “Read”.
Too many applications demand administrator access when they don’t really need it. I’m talking to you, Sansa Media Converter.

CWE-602: Client-Side Enforcement of Server-Side Security

I’ve seen this one hundreds of times. “We prompt the user for their birth date, and we reject invalid day numbers”; “Where do you reject those?”; “In the user interface so it’s nice and quick”. Great, so I can go in and make a copy of your web page, delete the checks, and input any number I like. Don’t consider it impossible that an attacker has written his own copy of the web browser, or can interfere with the information passing through the network.

What’s missing?

Glaringly absent, as usual, is any mention of logging or auditing.

Protections will fail, always, or they will be evaded. When this happens, it’s vital to have some idea of what might have happened – that’s impossible if you’re not logging information, if your logs are wiped over, or if you simply can’t trust the information in your logs.

Maybe I say this because my own “2ndAuth” tool is designed to add useful auditing around shared accounts that are traditionally untraceable – or maybe it’s the other way around, that I wrote 2ndAuth, because I couldn’t deal with the fact that shared accounts are essentially unaudited without it?

Of course, that leads to other subtleties – the logs should not provide interesting information to an attacker, for instance, and you can achieve this either by secreting them away (which makes them less handy), or by limiting the information in the logs (which makes them less useful).

Another missing issue is that of writing software to serve the user (all users) – and not to frustrate the attacker. [Some software reverses the two, frustrating the user and serving the attacker.] We developers are all trained to write code that does stuff – we don’t tend to get a lot of instruction on how to write code that doesn’t do stuff.

Another mistake, though it isn’t a coding mistake as such, is the absence of code review. You really can’t find all issues with code review alone, or with code analysis tools alone, or with testing alone, or with penetration testing alone, etc. You have to do as many of them as you can afford, and if you can’t afford enough to protect your application, perhaps there are other applications you’d be better off producing.

Other mistakes that I’d like to face head-on? Trusting the ‘silver bullet’ promises of languages and frameworks that protect you; releasing prototypes as production, or using prototype languages (hello, Perl, PHP!) to develop production software; feature creep; design by coding (the design is whatever you can get the code to do); undocumented deployment; fear/lack of dead code removal (“someone might be using that”); deploy first, secure later; lack of security training.

“Fully Stealthed” means fully spoofable

Alun Jones — Wed, 21 Jan 2009 00:50:19 GMT

Every so often, someone on one of the security mailing lists to which I subscribe will post a frothing rant from someone who has discovered their own personal “magic bullet” which solves all their security woes. This time, it’s a guy who was convinced that Microsoft’s recent out-of-band Internet Explorer patch MS08-078 is actually a conspiracy by Microsoft (and the government, of course) to invade your computer.

Okay, now aside from the point that, technically, Microsoft “pwns” your computer if you run their OS, and they don’t need to install patches to continue to do so; aside from the Ballmer defence (“If we were actually evil, don’t you think we’d be doing a better job at it?”; aside from that and many other considerations, what evidence did this guy have that the patch is a conspiracy?

Gibson Research’s ShieldsUp site reported that his system was “Fully Stealthed”.

[For those of you non-geeks reading the blog, that means that his firewall was closed up so tight that his system was not responding to any attempt to connect.]

Many other people have made, or will make, the obvious note that the patch is for a browser client bug, whereas the firewall ignoring all incoming requests only protects against server-related bugs, so I’ll leave it to those people to discuss that.

My concern is that Gibson is still pitching the idea that “Fully Stealthed” is a good idea.

TCP/IP, the network protocol on which much of the Internet is currently based, is designed around certain error reporting mechanisms that keep the system able to route around trouble.

One of these mechanisms is the TCP RST (reset) flag. The reset flag a great tool, as it says in a single bit “I received this packet, but I can completely guarantee that it’s not meant for me”. Another similar mechanism is the “ICMP Host Unreachable” response, which says “You appear to be trying to send a packet through me to another machine, but although I’m not a bad place to send that packet through, I can’t seem to reach that machine just now”.

When you’re “Fully Stealthed” (or completely non-responsive, if you prefer), it’s like you’re a black hole, and neither the TCP RST flag nor the ICMP Host Unreachable errors are returned from your system.

That’s great, right, because it means that your attackers can’t tell you’re there? It’s like you’re a black hole, no one can see you, right?

That sounds good in theory, except that even black holes can be seen, because they don’t act like the empty space that might otherwise be there.

Similarly, a “Fully Stealthed” machine gives away its presence by occupying an IP address that will not respond at all when you try to contact it. Very much like a black hole, it’s clear that it’s there, because if there was nothing there, the upstream routers would be passing back ICMP Unreachable messages.

OK, so maybe they know that I’ve got a machine here, at this IP address, but it’s safe, because it’s Fully Stealthed – Stealth just sounds so cool, especially since it’s a verbed noun! It’s alright that I look like a hole to the rest of the Internet, because nobody can do anything to me!

Wrong again.

The attacker can pretend to be you, because there’s nothing you’re going to say about it.

Let me qualify that – of course, the attacker can’t use your password if he doesn’t know it, nor can he use your private keys. But he can use another thing that some sites use as part of the proof that you are who you claim to be.

He can use your IP address.

A few things prevent this normally:

The attacker never gets to see responses to his traffic – but for the most part, he may be able to guess these, and perhaps he can see those responses, if he’s sniffing your line, for example.
You get to see the responses to the attacker – this allows your computer to say “I received this packet, but I can completely guarantee that it’s not meant for me” – in other words, to send a RST back.
If the attacker can’t see his responses, he needs to guess the random sequence number that is supplied in the SYN-ACK packet. Again, this isn’t a problem for the attacker if he’s sniffing your line, but it’s also not a problem for the attacker if he can guess the sequence number somewhat reliably. This happens every now and again, as network stack developers fail to predict ways in which their own randomness can be predicted.

So, number 1 and 3 aren’t always a barrier – number 2 is definitely a barrier if the attacker needs to maintain the connection for more than a few fractions of a second, as the RST from the spoofed IP address will cause the server to drop the connection and ignore what the attacker is trying to do.

So, this is a valuable protection that a “fully-stealthed” firewall is going to throw away for you – the ability to spot when someone is spoofing your IP address, and to respond back to say “uh, that isn’t me – stop talking to him”.

A firewall should behave as if the machine is present but disinterested, and should actively refuse misguided connection attempts and responses, not merely ignore them. There’s a big difference between the two behaviours. Don’t use the sensationalist terminology of a poor substitute for an expert as a replacement for understanding of your risks and threats.

Microsoft Security Advisory – MD5 collisions

Alun Jones — Fri, 02 Jan 2009 03:31:35 GMT

I would hardly be able to call my blog “Tales from the Crypto” if I didn’t pass at least some comment on the recent Microsoft Security Advisory, and the technical pre-paper on which it is based.

To an uninformed reader, the advisory (and especially the paper) doesn’t make a whole lot of sense, as with most cryptography documents. If there’s an attack on a cryptographic technology, doesn’t that mean it’s broken and we should stop using it?

Not really, no. We should stop using, or shore up, those components that have an increased vulnerability.

First, let’s remember that cryptography is necessarily full of mathematical theory and that it is very much a developing field. If I say something along the lines of “magic happens here”, please accept that at face value. It means that there is something hugely full of mathematical complexity that I don’t understand, but which has been assessed by mathematicians who know more than I do about the subject.

How do certificates work?

So, a little background, and an explanation of the attack, before we get to the mitigations.

Every time you use HTTPS (HTTP over SSL / TLS), there’s an identifying exchange – at the very least, the server identifies itself to you, and possibly you identify yourself to the server. In SSL, this is almost always done using certificates – strictly speaking, X.509 certificates.

A certificate is a list of statements about the identity of the party it represents, followed by a mathematically-derived encrypted value called a “signature”. The signature is based on a hash function, which is chosen to be resistant to attack. Typical hash functions are MD5, SHA1, and the “SHA-2” family which are identified by the number of bits of output they produce (i.e. how well they uniquely represent the original information to be hashed). The signature is the hash of the identity statements, encrypted using the issuer’s private key. This means that anyone can decrypt the hash, but in doing so, they will recognise both that only the issuer can have created the signature, and that the identity claims made in the certificate are accepted as valid by the issuer.

This allows you to trust the owner of the certificate, on the basis that you trust the issuer. Sometimes you don’t know if you can trust the issuer, either, and so you have to find out if you can trust the issuer – by looking at their certificate, seeing what claims it made, and what other issuer signed it, and so on, up a “chain of trust”, until you either meet a certificate you do trust, or you meet a certificate that is “self-signed” – that is, that it claims to be its own issuer, and has no other signatory.

So, from this description, you should be able to envisage a chain of trust, where the “leaf certificate” of the site whose identity you want to verify, is signed by an intermediate certificate authority (CA), which may in turn be signed by an intermediate CA, and so on, until you meet a certificate that is signed by a “root CA” – a self-signed certificate whose trust you can use as a basis for trusting the leaf certificate.

Many root CAs are installed by default in operating systems, or applications that use SSL, with the intent that you should be able to trust all certificates issued by those CAs, because they take adequate steps to verify the certificates they issue, and because they use modern technology.

Where’s the attack?

There’s nothing surprising about this attack to those of us who follow cryptography news. One of the problems with hashes is that it is possible to generate two paired documents, that have different content, but whose hash is the same. It has been known since 2004 that you can generate such colliding documents using MD5 as a hash without quite as much effort as the “brute force” technique of trying to generate documents and see if they match. From that, we have (or should have) predicted that this attack was possible, though not easy.

The attack is this – the attacker requests a bona fide web-site, or email (or any other) certificate from a reputable certificate authority. The certificate request is generated along with a second ‘shadow’ certificate – the two differ in areas chosen by the attacker, and with sufficient care to make sure that the issued certificates will both match the same signature.

This gives two certificates, which each appear to have been issued by the certificate authority, but only one of which actually contains information that was seen by the certificate authority.

The method of attack beyond this point will depend on what the shadow certificate was. The simplest way to attack this would be to have both certificates be web site certificates (or both be email certificates, etc), so that you could ask the CA for a certificate for your own name, but wind up with a certificate for someone else’s name – a big company or an important individual, say. That’s useful, but it only gives you one usable certificate per request. Keep that up, and you are sure to be detected.

The method outlined in the research paper, however, goes a step further than that – the certificate request that the CA sees is, as before, a simple web site certificate request. But the shadow certificate is designed to be that of an intermediate CA itself. Once this attack is successful, you can use the intermediate CA to issue any number of web site, email, code-signing, and even other CA certificates. Because these certificates chain up through your bogus intermediate CA, and then to a trusted root, they too will be trusted.

What about defence?

There are several defences to consider, and I’ll address them from the perspective of various different parties.

1. The Certificate Authority

First of all, all certificate authorities need to move to stop using MD5 when signing other people’s certificates. They should have stopped doing this some time ago, as it was clear that the generation of colliding certificate requests was an ever-increasing possibility. Also on the way out should be SHA1 (although that does mean older systems and software may have issues, because they may not be able to support newer SHA-based hash and signature algorithms). Note that this (particularly the dropping of SHA1) is a recommendation that should be followed with glacial slowness, over years, rather than days. We’re not that broken yet.

Even if the CA continues to use MD5 and SHA1, they can adequately protect against this attack by using non-predictable serial numbers when generating the certificate signatures. This is essentially the area where the CA can most easily and most effectively prevent this attack from succeeding, relying as it does on being able to predict precisely the contents of the returned certificate. This will continue to work so long as the attackers can only generate two colliding paired documents – if there is ever a sustainable attack that allows creating a document that matches the hash of another document without generating them together, this too will be a cause to doubt those certificates.

Another defence against this (but not the simpler form of the attack) is to ensure that you use different CAs to issue leaf certificates than you use to issue intermediate CA certificates, and that you set limits on how long the chain may be as signed by your CAs. That way, a leaf certificate request cannot be used to create a shadow intermediate CA certificate, because verification of the chain will fail because of length constraints.

Check your certificate requests, and make sure that you have not seen a large number of certificate requests from substantially the same source, in an attempt to generate a desired serial number. Offer your existing customers, if they are worried about MD5-signed certificates, the option to replace their certificates with certificates signed by other hash schemes.

2. The Web-Site Owner

There’s really not anything the web-site owner can do, beyond checking any reports of hijacked sessions, or web sites not appearing to be correctly identified, and then taking legal action to remove such pretender sites when they are found.

One thing that can be done is to champion the use of Enhanced Validation (EV) SSL Certificates, as specified by the Browser Forum. These certificates are required to use a chain that has no MD5 signatures in anything other than the root CA. Push the message to your customers and users that the green bar indicates a higher level of trustworthiness. You’ve not only identified yourself to the CA’s satisfaction, but your CA and you are committed to a more up-to-date technical configuration.

Ask your CA if you need to take action with your existing certificates – if they are signed by using MD5 hashes, it may be that some customers will refuse to accept your certificates. Your CA may have a reasonable offer on replacing your certificates with ones signed by SHA1 or other hashes.

3. The Web-Site Visitor

These are the guys that really matter – because if they can be fooled, then the attack has succeeded.

The first thing that has to be drummed into web-site users’ heads is that a certificate error message should be reason for you to stop your visit to the web site with the error, and to not place any orders with them, or supply it with your private information (password, personal details, etc) until you have resolved with their technical support what the issue is. This step alone is something that I have emphasised before, and I emphasise it again now, not because it is the best fix for this issue (because a clever attacker will try to produce a certificate that doesn’t error), but because it’s something that protects against the far easier attacks, and it is still not a habit that users have gotten into.

Next, keep up-to-date with patches. If there are interesting ways to block this at the browser, those will be distributed through security patches to your browser or other applications. If you use a lot of OpenSSL-based applications, keep looking for updates to those; if you use a lot of CryptoAPI-based apps, updates should come to you automatically through Windows Update.

Read Microsoft’s Security Advisory, as well as entries on the Microsoft Security Response Center Blog and the Microsoft Security Vulnerability Research & Defense Blog.

4. The software developer

Consider, if you already verify certificate chains yourself, adding or documenting features to refuse chains that flow through CA certificates signed with MD5; also to refuse chains that flow through CA certificates with too much ‘cruft’ (this attack uses the “Netscape Comment” field and fills it with binary that doesn’t look very comment-like).

Make sure that your verification routines check for chain length constraints, as well as corrupt or absent revocation list locations. Again, this attack had no space to put a valid CRL location in place.

If you develop IDS solutions, you may want to try and check for an SSL negotiation that includes certificates signed by intermediate CAs that are themselves signed by using the MD5 hash algorithm – although this is a little complex to track, it shouldn’t be completely impossible.

And, in summary (phew – at last!)

This is a proof of concept of a theoretical attack, and has generated some interest because it’s a shoe we’ve been waiting to see drop. Repeating the work with the information supplied by Sotirov et al would require a lot of significant and serious mathematics. I know that’s not something to make it impossible, but I think it’s enough to suggest that the sort of people with enough resources to hire advanced mathematicians would find it cheaper and easier to just use something more like social engineering to achieve the effect of having visitors trust your web site.

In several months, the tools will become more widely available, but by then, CAs should be smart enough to stop using MD5, and be considering a move to SHA256 and above. And if they aren’t, I’m sure there will be further advisories with instructions on which root CAs to remove from your trusts.

This is a thoroughly interesting attack, and exciting to people like me. That shouldn’t be taken as an indication that the world is about to collapse, or that you can’t go on trusting HTTPS the way you currently do. Even though we now have the ‘perfect storm’ of a serious DNS flaw backed with a way to subvert SSL, it doesn’t appear to be in use at the present, and with the information on how this attack was achieved, it’s possible for a root CA to comb back through their records and find suspicious behaviours that match this attack.

Link: Verisign’s statement (they own RapidSSL, the CA that was the subject of this attack).

Redmond Report says “Vista Kernel Flawed”

Alun Jones — Wed, 10 Dec 2008 04:52:22 GMT

This is just some lovely reporting:

Vista Kernel Ready To Pop?

Vista, due largely to its lockdown of user rights, is far more secure than XP. But it's not 100 percent safe. In fact, the kernel itself has an issue that could lead to buffer overflow attacks, or so says security company Phion.

Well, that's hardly surprising, we know how common buffer overflow attacks are, and how difficult they are to prevent. Go on...

The exploit, which does require admin privileges, is pretty well-documented by Phion. And there's no patch -- just a workaround from the company. Hmm. Is Phion looking for new customers?

Uh... if the 'exploit' needs admin privileges to start with, exactly how is it an "exploit"? It's a bug. By the time you have admin privileges, you can replace the operating system with one that does your bidding anyway, so how is it an 'exploit' that you can do so without replacing the OS core?

Pre-announcing this kind of flaw is like giving bullets to insurgents before our soldiers have a chance to put on helmets and bulletproof vests: dangerous.

No, it's rather like suggesting that there's a flaw in that if the Commander-in-Chief is secretly supporting the terrorist cause, he can order our soldiers to be needlessly sent into a dangerous war zone without sufficient arms or armour.

There are other bugs where I would agree that it’s important to avoid announcing the flaw before the vendor has been given a reasonable chance to fix it for find a workaround – this isn’t that case, though.

The flaw in question is worth noting, though, in that it's something that can be abused by members of the Network Operators group - and there are many sites that put users into this group simply so that they can turn off or on the wireless networking card on their laptops (for those that don't have a simple hardware switch). So, while Microsoft may assert that "Network Operators are just like administrators", there are many ordinary users who have been dropped into the Network Operators group.

Nobody stopped me, as I put the second laptop into my bag...

Alun Jones — Sat, 08 Nov 2008 22:46:53 GMT

I have two laptops that I carry with me most places I go. This isn't showing off, it's just something I do for a number of reasons. (One laptop is for work, the other is personal)

On a recent trip, I wanted to leave one with my wife as she dropped me off at the airport (flying with more than one laptop just seems silly, all that extra weight) - but she drove off before I could take the superfluous laptop out.

So I proceed to the TSA line, wondering what they're going to say about me packing two laptops.

Nobody noticed. Nobody at all raised an eyebrow at me sliding two laptops into my bag.

That has me somewhat concerned - although it made my trip rather easy.

The implication is that if I am smooth enough of a criminal, I can pick up my laptop and yours, and slide them both into my bag without anyone except you caring – and you’re on the other side of the metal detector from me.

Although it would have slowed my progress through the security line, quite frankly I'd rather someone questioned me about the fact that I was doing something extraordinary in sliding more than the average number of laptops into a bag.

On a number of occasions, my wife (a seasoned traveler) has seen people accidentally swap laptops with her, walk off without their own laptop, or been worryingly detained through the metal detector as their laptops are sitting unprotected and unwatched at the other end of the security scanner.

Recently the TSA produced statistics that showed that many thousands of laptops are abandoned at security lines at the nation's airports - I would be interested to know how many thousands of laptops are not abandoned, but are purloined - accidentally or with criminal intent - by someone other than their rightful owner.

What should the TSA do to prevent theft and/or loss at the security checkpoint? Could the security lines survive if staff insisted on not letting the next person (or their carry-on luggage) proceed until the last person had finished collecting theirs from the output?