Message-Id: <200901241132.n0OBWBeN012791@www3.securityfocus.com>
Date: Sat, 24 Jan 2009 04:32:11 -0700
From: thadeum@...il.com
To: bugtraq@...urityfocus.com
Subject: Benchmarking attacks and major security weakness on all recent
 Windows versions up to Windows 200

----------------------------------------------------------------------------------------------------
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

Powered by blists - more mailing lists