cyberworm

Siteminder Memory Leak

Written by

cyberworm

in

,

CA Siteminder is an authentication provider for web interfaces.

It’s widely deployed and can be used as a Single Sign-On for web services.

It has an interesting bug which is surprising for a web interface, it was incorrectly decoding URL encoded content.

This provides two interesting attacks, one more serious the other only useful as part of a chain.

The url decoding code is written in C++, similar to this…

for ( j=0, k=0; j < len; j++, k++ ) {
    switch( temp[j] ) {
        case '+':
            target[k] = ' ';
            break;
        case '%':
            c1 = tolower(temp[++j]);
            if ( isdigit(c1) ) {
                c1 -= '0';
            } else {
                c1 = c1 - 'a' + 10;
            }
            c2 = tolower(temp[++j]);
            if ( isdigit(c2) ) {
                c2 -= '0';
            } else {
                c2 = c2 - 'a' + 10;
            }
            target[k] = c1 * 16 + c2;
            break;
        default:
            target[k] = temp[j];
            break;
    }
}

The first thing you’ll notice is that it doesn’t actually check that the characters following the % symbol are actually valid hex characters.

This is the less dangerous of the issues, it’s possible to create input which is junk URL encoded content but will be correctly decoded on the target application. In testing, this allowed us to smuggle payloads past a WAF that would otherwise be blocked, since it didn’t recover the same payload as the actual application would.

The more serious issue that a keen observer may have spotted is that it also doesn’t check if there are characters beyond the % symbol but will attempt to copy them anyway.

On the system, this allows us to send an input that results in an incorrectly terminated string. It’s very common for input values to be reflected back to the client in the rendered page.

The entire query string is decoded in one go, so to exploit this we will construct a URL where the last value listed in our query string is terminated with a %. When it later reflects this value back to us, it will read beyond the end of our input and return chunks of memory (up until the next null byte or page fault).

This vulnerability is relatively widespread and indicates that many large vendors haven’t patched in years. These include technology, aerospace and defence, financial industry, etc.

The tool itself is using a regex submatch to extract the leaked data, which isn’t ideal but demonstrates the bug.

You can review the tool (and some example vulnerable systems in the comments).

More posts