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