Affected operating systems:
—————————

Windows XP Pro
Windows 2003
Windows Vista
Windows 2008
(all service packs…)
And probably some UNIX/Linux systems with some variants… Look by yourself.

================================================== ==================================================

Abstract:
———

This paper makes a short introduction on benchmarking attacks and then focuses on one kind of these techniques which can be used to globally weaken the security of many applications running under modern Windows operating systems (tested up to Windows 2008 in date of 27/01/2009).  This paper includes a detailed proof of concept of the weakness applied to the “runas.exe” application, thus allowing a malicious user to _easily_ guess the password length typed in when “runas” is used to launch an application under another user’s privileges. Note that we consider the vulnerability not being in “runas.exe” but in the operating system itself. That will be explained in the last part of the paper. Get a more detailed version of this advisory with complete tutorial in Haking9 Magazine of May 2009.

Introduction before speaking of benchmarking attacks:
—————————————————–

When you speak of security threats you mostly speak about unsecure protocols, weak encryption algorithms, buffer overflows, privileges escalation, human factor, etc. There are also another class of attacks that are quite well documented and based on an environmental
analysis of a secure component you want to unsecure. These are known as “timing attacks”. Timing attacks were very popular years ago and this field of research is still under progress. Briefly, timing attacks consist of analyzing the time it takes for a system to compute data in order to predict private information about these data. The information you obtain from a timing attack will lower the security of the component under analysis. Benchmarking attacks include timing attacks and I found relevant enough to speak of timing attacks prior speaking of benchmarking attacks for those of you who are not familiar with this field of research.

Timing attack scenario examples :
———————————

If you are already familiar with timing attacks you can skip this chapter. Let’s take a brief example of a timing attack scenario aiming to predict real user logins on a specific system :

1. A system is running a server application ‘login.exe’ which takes a username, a password and then opens a shell or refuses connection if authentication fails.

2. When you type a login and password the ‘login.exe’ application will check the login, then check the password, then will allow or deny access to a shell.

3. If the login is wrong the application returns without checking password. The system denies the access in N milliseconds.

4. If the login is correct but the password is not the application checks the password and then denies access. It takes N + M milliseconds to realize the operation.

5. You got it. If you can measure the number of milliseconds it takes for the system to reply on a real login you are aware of (Administrator, root, …) then you can predict other real logins by discarding all the attempts that ran only ~(N) milliseconds as you are only looking for attempts that took ~(N + M) milliseconds to be processed. There is a security advisory published in 2003 by Marco Ivaldi detailing exactly this kind of flaw against SSH [1]. More recently, also about SSH, Dawn Xiaodong Song, David Wagner and Xuqing Tian wrote an interesting paper detailing an attack based on keystrokes intervals analysis [2].

Now about benchmarking attacks:
——————————-

Timing attacks are harder to realize on local environments and against specific applications because modern CPUs are designed for multi-threading (as are applications) and current clock frequencies make the millisecond a pretty obsolete unit of measurement. You have to think of more complicated strategies to obtain exploitable information against a specific component. This is where benchmarking becomes useful. When you speak of a ‘benchmark’ you are not only speaking about how fast a process is running but also about how efficient it is. In order to evaluate that you must rely on many more indicators, making the time a process runs only a part of a benchmark result.

A benchmark can also imply to analyze the following indicators:
– number of threads ran by process
– size of memory allocated by process/threads
– CPU consumption
– number of open handles, file descriptors, sockets, …
– command line arguments, environment variables
etc.

You can think ‘benchmarking attacks’ as a higher level of attacks that also includes timing attacks. Benchmarking attacks are simply based on all the indicators you can grab to analyze the way a component is running.

I was looking such exploitable data on Linux 2.6 (/proc and potential syscalls) but it is on Windows that such weakness appeared very distinctly. As the attack detailed hereafter is absolutely not based on any timing measurement I thought it as a ‘benchmark attack’.

Benchmarking attack against ‘runas.exe’:
—————————————-

runas is a critical component of Windows and is available on all the modern Windows versions. It permits you to launch an application under another user’s privilege. It is widely used by administrators in corporate environments.

Syntax is (in cmd.exe) : runas /user:[USER] [APPNAME]
Eg.: runas /user:Administrator explorer.exe

The attack permits a Guest user to predict the password length entered by any user who ran runas and typed a password in. This is very easy to do and is based on analyzing the I/O bytes computed when executing runas.exe.

First you have to consider this : on Windows any unprivileged user can grab information on highly privileged running processes. This is where the flaw is.

I found the issue by realizing some very simple steps that you can reproduce following:

1. Log in as guest
2. Run taskmgr.exe (CTRL+ALT+DEL)
3. Go in “view”, “select columns” and tick “I/O Other Bytes”. Apply. (see Annex about this column)
4. Start runas.exe, with :
C:\> runas /user:Administrator explorer.exe
5. The prompt is asking for the password. Start OllyDBG (no setup, ready to use)
6. Configure OllyDBG to only break on Thread exit.
7. Release the process and type no password (immediately press enter)
8. Repeat the process again, same steps, but type a password for this time.

Goal is to get the last value of the “I/O Other Bytes Counter” just before the process is destroyed by the kernel. Fortunately the last value of this indicator is the one that interests us. This is why you can use OllyDBG to break on thread exit, but you can also forge a software that will permanently track this data in a loop when it detects runas in process list. Last tracked value will be the one needed. We will assume that, in first instance, the “I/O Other Bytes” counter when no password was entered gave a “700” result. This value will always be the same over various executions and will grow according to the password length the user typed in :

{0} letters – 700 (thereafter named ‘BASE’)
{1-4} letters – 708
{5-8} letters – 716
{9-12} letters – 724

Consequently the algorithm to predict the password length is :

RESULT – BASE = UNICODE STRING LENGTH
then,
UNICODE STRING LENGTH / 2 = PASSWORD LENGTH

As you saw the software pads the password string to round it up to a multiplier of 4. That means that you have an uncertainty of three letters in your guess of the password length.

Eg.: result is 716, so you know that the password is AT LEAST 5 letters and AT MAX 8
letters.

Using this weakness an attacker will easily discriminate strong and weak passwords as he also may gain a lot of time in passwords brute-force attempts.

Benchmarking attacks and security:
———————————-

You could think the flaw is in runas.exe : this software should pad the password to a huge and invariable length in order to hide the password length when computing it. That’s true but that is not enough. It is obvious that benchmarking attacks can work against a huge number of softwares proceeding data in such ways. But will you ask all developers to master time execution, memory allocation, I/O operations in order to hide sensible and private data ? No, that’s nonsense. The main problem is that a process can access other process information just by watching its own available environment. There is the major flaw: unprivileged process grabbing data on critical process. A secured environment must be absolutely hermetic and then watch carefully what it discloses to other users or process. Windows clearly fails on that point, as a badly protected Linux does when anyone can read the command line typed by a user just by running a ‘ps’. Finally for binaries that are started by administrators from user environments (such as runas) they need to be identified somehow so critical information do not leak once started. With their bit-suid binaries we can say UNIX-like systems have an advantage for security against benchmarking attacks.

h4cKm4sHiNe