Re: White paper: Exploiting the Win32 API.
On Wed, 28 Aug 2002 10:25:08 -0700, you wrote: Anytime a developer has an application running as system which is a rare need, they must realize the security ramifications of what they are doing. (That, if a flaw is found in their software, they will elevate the privileges of the user). Agreed. It's way past time for the paradigm shift in the Win32 world that took place a long time ago in the *nix world, that being that applications should *always* run with the lowest privileges they require. In this respect, Microsoft should be leading the pack instead of trailing it - the only MS services I've ever seen that don't install themselves as LocalSystem are the various Windows Media services. Maybe it's time Microsoft implemented setuid() on Win32? Even the Cygwin group have had trouble with it - according to http://www.cygwin.com/cygwin-ug-net/ntsec.html#NTSEC-SETUID Because of the nature of NT security an application which needs the ability has to be patched Since it also requires three privileges that not even Administrators have by default, their solution seems a tad clumsy. While you can exploit other applications not running in a higher privilege space in this manner, this gains you nothing which you can not do with just running an binary as that user. I'd disagree with this. If you have a UI that is partly disabled waiting for some form of user validation (scroll to the bottom of the license agreement before you click OK, or type in a valid username and password before you can click that administration button) you can do a lot. Also, personal firewalls are going to have a hard time of it - I can circumvent all personal firewalls I've tested by injecting my code into a trusted application (IE in my case). The firewall never bats an eyelid, since IE is allowed to access the network. Some clever shellcode can then do whatever you'd like. Chris -- Chris Paget [EMAIL PROTECTED]
RE: White paper: Exploiting the Win32 API.
All of this brings up a couple of questions for me: 1. As I understand it, all this can be avoided by applying the simple, longtime standard maxim of trust no input, correct? (If correct, this leads me to murmur rhetorically Have today's developers no discipline?) 2. If the above is incorrect, and system messages such as event notifications (onClick, etc.) can be compromised, then developers using tools such as Visual Basic are essentially helpless to harden their applications. Other than going back to writing in assembly, what is the modern developer to do? We have here an exclusive or: Which is it - 1 or 2 or neither? Thanks, -Greg === Ford CIRT [EMAIL PROTECTED] === -Original Message- From: Paul Starzetz [mailto:[EMAIL PROTECTED]] Sent: Monday, August 26, 2002 10:47 AM To: Andrey Kolishak; [EMAIL PROTECTED] Subject: Re: White paper: Exploiting the Win32 API. Andrey Kolishak wrote: 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/ In fact, the problem is similar to U*ix signals, except that there is no jump-to-address argument for usual. Remember that old ping bug which allowed users to flood the network by sending SIGALRM in some old ping implementations. Maybe reading some manuals about safe signal handling would be a good lecture for Windows developers too: http://www.faqs.org/faqs/unix-faq/programmer/secure-programming/ Section 3.3 especially regards /ih
RE: White paper: Exploiting the Win32 API.
-Original Message- From: Rothe, Greg (G.A.) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 27, 2002 10:00 AM To: 'Paul Starzetz'; Andrey Kolishak; [EMAIL PROTECTED] Subject: RE: White paper: Exploiting the Win32 API. All of this brings up a couple of questions for me: 1. As I understand it, all this can be avoided by applying the simple, longtime standard maxim of trust no input, correct? (If correct, this leads me to murmur rhetorically Have today's developers no discipline?) 2. If the above is incorrect, The above is NOT correct as several posters have already shown. Anytime a developer has an application running as system which is a rare need, they must realize the security ramifications of what they are doing. (That, if a flaw is found in their software, they will elevate the privileges of the user). http://www.atstake.com/research/advisories/2000/a090700-1.txt This is a well known need, even if this type of attack - and therefore prevention - is not well known. and system messages such as event notifications (onClick, etc.) can be compromised, then developers using tools such as Visual Basic are essentially helpless to harden their applications. Other than going back to writing in assembly, what is the modern developer to do? You generally will have very few types of applications on your system which require to run *as* system and can receive messages (Most that I can think of are actually security apps that are designed to restrict unprivileged users -- but maybe I am biased). While you can exploit other applications not running in a higher privilege space in this manner, this gains you nothing which you can not do with just running an binary as that user. We have here an exclusive or: Which is it - 1 or 2 or neither? Thanks, -Greg snip
Re: White paper: Exploiting the Win32 API.
Andrey Kolishak wrote: 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/ In fact, the problem is similar to U*ix signals, except that there is no jump-to-address argument for usual. Remember that old ping bug which allowed users to flood the network by sending SIGALRM in some old ping implementations. Maybe reading some manuals about safe signal handling would be a good lecture for Windows developers too: http://www.faqs.org/faqs/unix-faq/programmer/secure-programming/ Section 3.3 especially regards /ih
Re: White paper: Exploiting the Win32 API.
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.htmnav=/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, Andreymailto:[EMAIL PROTECTED] 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
RE: White paper: Exploiting the Win32 API.
I am aware of a Microsoft application that has made such a mistake. 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:[EMAIL PROTECTED]] Sent: Tuesday, August 06, 2002 10:44 AM To: Chris Paget; [EMAIL PROTECTED] 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:[EMAIL PROTECTED]] Sent: Tuesday, August 06, 2002 9:14 AM To: [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
RE: White paper: Exploiting the Win32 API.
So let me get this straight. 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
Re: White paper: Exploiting the Win32 API.
Dear All, The issue of vulnerabilities in event-driven systems has been mentioned last month (7th July 2002) in the vuln-dev mailling list at http://online.securityfocus.com/archive/82/280912/2002-07-04/2002-07-10/0 Perhaps vuln-dev is not that popular as bugtraq :'(. Time to switch mailling lists. As part of my studies (http://www.isg.rhul.ac.uk/~simos/) I examined security issues in event-driven systems and the results have been published in two (academic) papers, found at http://www.isg.rhul.ac.uk/~simos/pub/ For the demonstration of these issues, there is a page available at http://www.isg.rhul.ac.uk/~simos/event_demo/. There are also a demonstration application and some exploitation ideas. Regarding the issue whether event-driven system vulnerabilities are a new type of attack or not, depends on how you classify a new attack. One way to classify it is to regard an application as an independent entity that can be attacked from specific types of dangerous inputs like command line parameters, reading data from a file (like gets() reading from STDIN) or reading data from the network. We describe an input as dangerous if an attacker can manipulate it somehow. The command line parameters of a SUID application is dangerous input, the cookies that a WWW server is receiving from a WWW browser is dangerous FOR the WWW server, the cookies that a WWW browser receives from a WWW server is dangerous FOR the WWW browser and so on. In [Wheeler, 2002]** there is such a list of dangerous inputs. Thus, one way to classify classes of vulnerabilities is to arrange by inputs that a potential attacker can manipulate. In our case, events form such an input that an attacker can manipulate. Thus they can be technically a new class of attacks. These vulnerabilities exist in Windows because an attacker can enumerate other people's windows and find the window handles. Then, the attacker can send crafted events to those windows. The problem arises from the fact that a normal user can send events to an administrative account. The reason I see this happening is that of usability. You can copy and paste between Windows from different users and it's flexible to do so. Furthermore, it is common in event-driven systems like Windows to have interface-based security, that is, an application using the window controls like text boxes to enforce security. An attacker can bypass these security measures. It is similar to the JavaScript filtering in specific WWW pages for information sent to CGI scripts. You can bypass JavaScript and sent directly to the CGI script. In addition, as [Forrester et al., 2000]* have shown, you have the added issue of an application malfunctioning if it receives a sequence of events that it was not designed to receive. The internal state of the running application gets messed up and you can possible make it do things that it should not do. This is due to the complicated interactions of the different events that an application can receive and can have consequences with other event-driven systems employed in hardware devices, ATMs and so on. Finally, an additional issue is the richness of the parameters of the event types in Windows. You can put pointers to data structures (also noted by [Forrester et al., 2000]*) or even addresses to subroutines as it happens with the WM_TIMER event type [Xenitellis, 2002a]***, [Xenitellis, 2002a] and more recently by Chris Paget at http://security.tombom.co.uk/shatter.html By using the functionality of window stations you can fix the issue. However, as long as the attacker and victim windows run in the same window station, I cannot see currently a way to filter events. There could be filtering if the receiver of events could know what is the origin of the event and cut off those that it does not feel comfortable with. This is putting access controls to the fuctionality of sending events. However, it will make things more complicated for application writers. The way I see all these being handled by the software companies is through the risk management cycle. If there is a high profile incident, then something may happen. Otherwise things will stay the same. It happens all the time. It's a rule of nature. Thanks for your time, Simos Xenitellis * Forrester, J.E. and Miller, B.P. (2000) An empirical study of the robustness of Windows NT applications using random testing, In Proceedings of 4th USENIX Windows System Symposium, USENIX. ** Wheeler, David (2002), Secure Programming for Linux and Unix HOWTO. http://www.dwheeler.com/secure-programs/, 2002. *** Simeon Xenitellis (2002a), Security vulnerabilities in Event-Driven Systems , IFIP / SEC2002 Security in the Information Society : Visions and Perspectives, May 7-9, 2002, Cairo, Egypt, In Security in the Information Society: Visions and Perspectives, Kluwer Academic Press, pages 147-160. Simeon
