White paper: Exploiting the Win32 API.
Andrey Kolishak
I believe nothing new it that issue. WM_TIMER tricks were described by
Matt Pietrek in 1997, in Microsoft's MSJ
http://www.microsoft.com/msj/defaultframe.asp?page=/msj/0397/hood/hood0397.htm&nav=/msj/0397/newnav.htm
(sample included)
So it was noted already at least 5 years before Jim Allchin.
There is also well known trick with SetWindowsHookEx function (exploit
sample http://www.uinc.ru/scripts/load.cgi?articles/19/InjectDLL.zip
by buLLet) and so forth.
There is also article of Symeon Xenitellis "A New Avenue of Attack:
Event-driven system vulnerabilities" http://www.isg.rhul.ac.uk/~simos/event_demo/
So it's strange that issue looks new for somebody, especially
experts.
Best regards,
Andrey mailto:an...@sandy.ru
CP> I have written a white paper documenting what I believe is the first
CP> public example of a new class of attacks against the Win32 API. This
CP> particular attack exploits major design flaws in the Win32 API in
CP> order for a local user to escalate their privileges, either from the
CP> console of a system or on a Terminal Services link. The paper is
CP> available at http://security.tombom.co.uk/shatter.html
CP> In order to pre-empt some of the inevitable storm about responsible
CP> disclosure, let me point out the following.
CP> 1) The Win32 API has been in existence since the days of Windows
CP> NT3.1, back in July 1993. These vulnerabilities have been present
CP> since then.
CP> 2) Microsoft have known about these vulnerabilities for some time.
CP> This research was sparked by comments by Jim Allchin talking under
CP> oath at the Microsoft / DoJ trial some 3 months ago.
CP> http://www.eweek.com/article2/0,3959,5264,00.asp Given the age of the
CP> Win32 API, I would be highly surprised if they have not known about
CP> these attacks for considerably longer.
CP> 3) Microsoft cannot fix these vulnerabilities. These are inherent
CP> flaws in the design and operation of the Win32 API. This is not a bug
CP> that can be fixed with a patch.
CP> 4) The white paper documents one example of these class of flaws.
CP> They have been discussed before on Bugtraq, however to my knowledge
CP> there have been no public working exploits. I have just documented
CP> one way to get this thing working.
CP> 5) This is not a bug. This is a new class of vulnerabilities, like a
CP> buffer overflow attack or a format string attack. As such, there is
CP> no specific vendor to inform, since it affects every software maker
CP> who writes products for the Windows platform. A co-ordinated release
CP> with every software vendor on the planet is impossible.
CP> Chris
Marc Maiffret
http://www.atstake.com/research/advisories/2000/a090700-1.txt is an example
of one. In fact you would be surprised at the number of services vulnerable
to these types of attacks. From personal firewalls, to anti-virus and so on.
priv. escalation through windows message attacks is nothing new. back when i
was in rhino9, 4 or so years ago, we were performing similar attacks to do
priv. escalation from IUSR to SYSTEM.
out of box the way windows messaging works i think is flawed... yes there
are things you can do to protect from most of these attacks. however windows
should install out of box with these attacks in mind... secure by default
and all that jazz ;-) there is a lot that can be done at the OS level to
protect from programmers who do not know any better.
I know Microsoft keeps saying they will be secure by default... however I
doubt we will see that anytime soon. especially for lower level stuff like
this.
Besides... its next to impossible to keep a local user from getting SYSTEM.
There are just to many ways to do it. From service exploitation, to windows
api's, to core flaws within windows architecture.
any OS where locally you can input a chunk of data to some graphic routines,
as an unprivileged user, and then b00m be executing code within the
kernel... you cant trust that OS for local privilege separation of users and
such. makes you wonder if you can even trust it in remote scenarios. :-o
Signed,
Marc Maiffret
Chief Hacking Officer
eEye Digital Security
T.949.349.9062
F.949.349.9538
http://eEye.com/Retina - Network Security Scanner
http://eEye.com/Iris - Network Traffic Analyzer
http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities
-----Original Message-----
From: John Howie [mailto:JHo...@securitytoolkit.com]
Sent: Tuesday, August 06, 2002 10:44 AM
To: Chris Paget; bug...@securityfocus.com
Subject: RE: White paper: Exploiting the Win32 API.
Chris,
This class of attack is not new, it has been discussed before. While you
can assert that the blame lies with Microsoft (and I'll admit they do
have some responsibility to address the problem you describe) the chief
blame lies with the vendor of the software whose bad programming you are
exploiting. There is no excuse to put a window for a process with the
LocalSystem security context on a user's desktop. I am not aware of any
Microsoft application that makes such a mistake.
John Howie
-----Original Message-----
From: Chris Paget [mailto:iveg...@tombom.co.uk]
Sent: Tuesday, August 06, 2002 9:14 AM
To: bug...@securityfocus.com
Subject: White paper: Exploiting the Win32 API.
I have written a white paper documenting what I believe is the first
public example of a new class of attacks against the Win32 API. This
particular attack exploits major design flaws in the Win32 API in
order for a local user to escalate their privileges, either from the
console of a system or on a Terminal Services link. The paper is
available at http://security.tombom.co.uk/shatter.html
In order to pre-empt some of the inevitable storm about responsible
disclosure, let me point out the following.
1) The Win32 API has been in existence since the days of Windows
NT3.1, back in July 1993. These vulnerabilities have been present
since then.
2) Microsoft have known about these vulnerabilities for some time.
This research was sparked by comments by Jim Allchin talking under
oath at the Microsoft / DoJ trial some 3 months ago.
http://www.eweek.com/article2/0,3959,5264,00.asp Given the age of the
Win32 API, I would be highly surprised if they have not known about
these attacks for considerably longer.
3) Microsoft cannot fix these vulnerabilities. These are inherent
flaws in the design and operation of the Win32 API. This is not a bug
that can be fixed with a patch.
4) The white paper documents one example of these class of flaws.
They have been discussed before on Bugtraq, however to my knowledge
there have been no public working exploits. I have just documented
one way to get this thing working.
5) This is not a bug. This is a new class of vulnerabilities, like a
buffer overflow attack or a format string attack. As such, there is
no specific vendor to inform, since it affects every software maker
who writes products for the Windows platform. A co-ordinated release
with every software vendor on the planet is impossible.
Chris
--
Chris Paget
iveg...@tombom.co.uk
Kenn Humborg
>
> Allowing unpriveleged processes to send control messages to priveleged
> processes is not a flaw in the Win32 API because there is a mechanism
> for applications to protect themselves from this type of attack
> (alternate Windows Stations/Desktops).
>
> But the mechanism effectively prevents the priveleged processes from
> providing a GUI because the user won't be able to actually see the
> alternate Windows Stations/Desktops without some kind of Station
> switching tool, and/or extra training in how to do this.
>
> So, the result is that no applications actually use this mechanism.
>
> What part of "this is broken" doesn't make sense?
Well, there is a Right Way of controlling privileged processes
from the user's desktop. Simply banging a window up on the
desktop is not the Right Way.
There should be a separate UI/management tool which runs under
the user's credentials on his desktop and uses some IPC mechanism
to control the privileged process (RPC, DCOM, named pipes, tcp
sockets, whatever). This IPC interface is the security boundary.
To make an analogy in the Unix world, it would be like a deamon
running as root opening an xterm on the users desktop to manage
it. Nobody would say "X is broken" in this case - I think we'd
all agree that the app is broken.
Later,
Kenn