Benchmarking attacks and major security weakness on all recent Windows versions up to Windows 200

[thadeum@xxxxxxxxx]

----------------------------------------------------------------------------------------------------
Benchmarking attacks and major security weakness on all recent Windows versions 
up to Windows 2008
----------------------------------------------------------------------------------------------------

+ Author: Fabien KERBOUCI
+ Version/Date: 27/01/2009
+ Keywords: [ benchmark timing benchmarking attacks Windows runas vulnerability 
password length ]

Get a more detailed version of this advisory with complete tutorial and video 
in Haking9 Magazine 
of May 2009.

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

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.


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

Annex: What are I/O other bytes?
--------------------------------

Answer from Microsoft (quoted from Task Manager's help):

"The number of bytes transferred in input/output operations generated by the 
process that are 
neither a read nor a write, including file, network and devices I/Os. An 
example of this type of 
operation is a control function. I/O Other Bytes directed toCONSOLE (console 
input object) handles 
are not counted."

Got it ?

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

References:
-----------

[1] : "OpenSSH/PAM timing attack allows remote users identification", by Marco 
Ivaldi -
http://lab.mediaservice.net/advisory/2003-01-openssh.txt

[2] : "Timing Analysis of Keystrokes and Timing Attacks on SSH", by Dawn 
Xiaodong Song, 
David Wagner and Xuqing Tian - 
http://www.cs.berkeley.edu/~daw/papers/ssh-use01.pdf

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

GREETINGS:
----------

SALUT Thibaut and KERIHUEL Julien for showing great interest on the topic
antto, dex, HonkingZebra and HM for reading before release
Clad Strife because without him nothing would have been written