Introduction

In a recent discussion about the TU Delft's A-Select Single Sign-On system it was said that the application ID, or app_id for short, was to be kept absolutely secret by whomever was given one to. This specific ID enables an application to communicate with the TU Delft A-Select SSO server, which in turn enables users to log in to your application. As long as app_ids do not leak, the administrators can control which applications can use the TU Delft SSO.

Oh, secrets!

The whole authentication process is nicely documented in the A-Select API (if it doesn't load, try the version cached by Google). A rouge outline of the authentication process is as follows:

1. The application initiates authentication with a request to the A-Select SSO server, and gets back (among other things) a URL.
2. The user is redirected to this URL, which points to a sign-in form on the SSO server where the user enters his/her credentials.
3. After verifying the credentials, the SSO server redirects back to the application with several parameters.
4. The application uses these parameters to check with the SSO server whether sign-on was successful and get some user details (e.g. username).
5. The user is now logged in to the application.

There's one minor (undocumented) detail about step 4: the response from the SSO server which contains the username, also contains our 'secret' app_id. Nothing serious you'd say: the application knows it's own ID anyway. But the nice thing about the A-Select system is that anyone who knows the parameters received from the server in step 3 can execute step 4. And actually anyone who can log in to the application can get those parameters, since they're passed in a simple URL redirect (which is trivial to intercept).

Once you have the parameters, all you have to do is make a request to the A-Select SSO server like the application would in step 4. Everything is nicely documented (cache), so that shouldn't be a problem. The SSO server responds with some data, including the app_id, which is then not so secret any more.

Now, to spoil all the fun: TU Delft Blackboard's app_id is simply 'blackboard' - who would've guessed that!?

What's so special about that ID?

Well, in addition to the ability to build 'normal' applications with SSO (without permission from the administrator), the server has now no way of differentiating between the official application to which the app_id belongs and any other application with the same ID.

This theoretically enables us to authenticate a user, intercept the ticket given out by the SSO server, and log in the the official application ourselves (pretending we are the user who just got a ticket). A classic man-in-the-middle attack.

Fortunately, all implementations the A-Select Authentication System I've seen are in some way invulnerable to this practice. A good way to protect an application would be to only accept authentication requests which were initiated by that same application (by tracking which rids are created). Locking a session to an IP address is only an option when the application does not inadvertently accept authentication requests initiated by a third party anyway.

Who likes that as a solution?

A more sensible way of patching this attack vector is avoiding that a third party can mess with the requests at all. This was suggested to me by the OpenASelect Team:

We recommend enabling request signing (signing_enabled) for production environments, so that a third party cannot send requests on behalf of another application. If request signing is disabled, it is indeed the application's responsibility to verify that it (and not some third party) has started the authentication process.

They also noted that OpenASelect (which supersedes A-Select 1.x as used by the TU Delft) solves our original problem by not making app_ids public (while noting that guessing is still an option).

I don't believe you!

I've created simple proof of concept code which gets the app_id from an application which uses the TU Delft A-Select SSO server. You can find it on my server. Also available is the source code in case you want to run it yourself (which would be a safe idea).

The research on this topic was done in July 2008; I never bothered to write up about it after discovering about Blackboard's vulnerabilities and knowing that the A-Select team was already aware of the issue. I therefore think that it is completely acceptable to fully disclose the issue. This blog post and the proof of concept code were written in January 2009, following up on the discussion referenced in the introduction.