iDRAC6 web session hijacking


iDRAC provides out-of-band access to managed servers.

It allows you to manage a remote server, providing access to the screen. Most server providers offer similar capabilities.

In effect, it’s an IoT device that is wired into the server allowing access even while the server is powered off.

It provides a web interface, and this tool affects that component.

When a new user loads the web interface they are assigned a session cookie (if one is not already present). The cookie name is _appwebSessionId_ and it will have a value which contains a pseudo-random hex string.

While repeated sessions will provide seemingly unrelated session values, in reality they’re closely related and predictable.

Inside the web service there are 3 values which are being used to generate these session values:

  • A heap structure pointer
  • A Unix timestamp (in seconds)
  • A counter

These three values are converted to a hex string, and then used as the input for MD5. The resulting MD5 hash is assigned as the session cookie.

printf "%08x%08x%08x" pointer timestamp counter | md5sum

Each time a new session is assigned, the counter is incremented. The pointer is static and persists for the duration of the web server process, and the timestamp has almost no real variance and can more or less be discounted.

Since the pointer exists within a limited area of memory, the timestamp is known (from the server Date header, for example) and the counter wraps after 16 bits there is not a lot of entropy in this value.

To start our attack, we will request the login page for the device to obtain a session cookie. We will then make reasonable guesses as to the pointer and counter and timestamp values and hash them locally, until our local guess matches the value we received from the iDRAC.

At this point, we can synchronise ourself with the RNG on the remote device and we perform the first step of the attack.

We request a second session cookie, and we use our previously discovered values to speedup the cracking process to only a few guesses. However, we can use newly recovered the counter value to tell if another user has requested a session, since we can see how many times the counter has been incremented since the previous request.

At this point, the trap is set. We’ll continue to monitor the counter and wait to see this value increase. Once we see an increase, we will generate a set of candidate cookie values, using their counter value and the known heap pointer and a set of possible timestamps.

If the user who was assigned the session cookie has since logged in, then their session cookie can be used to retrieve pages that unauthenticated cookies can’t.

By submitting our candidate session cookies to such a page, we can find a logged in session.

At this point, you can retrieve some information from the device (things like boot videos and screenshots can actually be retrieved without any authentication which is it’s own issue) but to interface with the API to make changes, a second set of session values are assigned upon login by the device.

Two values are assigned and used via javascript (they’ll be in the address bar and are given the identifiers ST1 and ST2).

This too takes 3 inputs as it’s seed value:

  • A counter
  • A Unix timestamp (in seconds)
  • The pid of the web server.

These 3 values are added together and then used in combination with srand()/rand(). Since these feed back into each other, the first 32 bits are all that really matters. You can test this yourself, by taking the first 32 bits of an ST1 value and use it as the input for srand() and see if rand() outputs the next 32 bits.

We’ll brute-force the keyspace for this, and submit a request with the session cookie and the ST2 value to an API endpoint on the device. This is an online attack, so takes longer.

Once we receive a success response from the API endpoint, we know that we’ve successfully forged the credentials of the admin session.

At this point, the tool will use CVE-2018-1212 to obtain code execution as root on the device. There is a second exploit utilising the remote ISO mount utility which also provides code execution detailed in the source code comments.

You can review the tool (and some helpful hints in the comments).