| WIKI | FAQ | Tech FAQ | |
 http://csua.com/feed/ | |
| ||||||
| 5/24 |
| 2002/8/11 [Computer/SW/OS/Windows] UID:25540 Activity:nil |
8/9 YA Windows Exploit:
http://security.tombom.co.uk/shatter.html
\_ yawn. http://slashdot.org/article.pl?sid=02/08/06/1828256
and it's more like a VirusScan exploit.
\_ no. it's a windows exploit. the virusscan characteristic is
a variety rather than a species.
\_ no, it's a virusscan exploit because virusscan is the one
providing a gui window as a root process.
\_ gee, I'm sure there are no other windows applications that
do that.
\_ gee, then don't run those if you're concerned about this.
\_ Er. did you read the paper at the url you posted?
Hell, there are microsoft applications that do the
same damn thing. |
| 5/24 |
|
| security.tombom.co.uk/shatter.html More information Introduction This paper presents a new generation of attacks against Microsoft Windows, and possibly other message-based windowing systems. The flaws presented in this paper are, at the time of writing, unfixable. The only reliable solution to these attacks requires functionality that is not present in Windows, as well as efforts on the part of every single Windows software vendor. This research was sparked by comments made by Microsoft VP Jim Allchin who stated, under oath, that there were flaws in Windows so great that they would threaten national security if the Windows source code were to be disclosed. He mentioned Message Queueing, and immediately regretted it. However, given the quantity of research currently taking place around the world after Mr Allchin's comments, it is about time the white hat community saw what is actually possible. This paper is a step-by-step walkthrough of how to exploit one example of this class of flaw. Several other attack methods are discussed, although examples are not given. There are many ways to exploit these flaws, and many variations on each of the stages presented. Background - the Win32 messaging system Applications within Windows are entirely controlled through the use of messages. When a key is pressed, a message is sent to the current active window which states that a key was pressed. When Windows decides that an application needs to redraw its client area, it send a message to the application. In fact, when any event takes place that an application needs to know about, it is sent a message. These messages are placed into a queue, and are processed in order by the application. This is a very reliable mechanism for controlling applications. However, on Win32 the mechanism for controlling these messages is flawed. Any application on a given desktop can send a message to any window on the same desktop, regardless of whether or not that window is owned by the sending application, and regardless of whether the target application wants to receive those messages. There is no mechanism for authenticating the source of a message; It is this lack of authentication that we will be exploiting, taking into consideration that these messages can be used to manipulate windows and the processes that own them. Since the VirusScan Console runs on my desktop as LocalSystem and I am logged on as a guest user, the objective is to trick VirusScan into running my code to elevate my privileges. Locate a suitable window within VirusScan (an edit box is perfect), and obtain a window handle to it. Remove any length restrictions that may be present on that edit box, so that I can type in an arbitrary quantity of data. Force VirusScan to execute my code (as LocalSystem) This is actually very easy to do. Windows conveniently provides all of the functionality that we will be needing. I have written a small application called 11 Shatter which implements this functionality. You'll also need a hex editor that is capable of copying binary data to the clipboard (I use 12 UltraEdit), and a debugger (I use 13 WinDbg). The scanner is correct in flagging it - the code in this file is designed to open a command shell and bind it to a network socket. This is a bad thing to do in general, so the scanner is correct in generating an alert. This code is designed to be malicious in terms of its functionality, but the scanner is incorrect when labelling it as a virus. Windows messages consist of three parts, a message identifier and two parameters. The parameters are used differently depending on what message is sent. This makes our life simpler, since we only have to worry about four things; Stage 1: Locating a window We need to locate an edit control of some kind - something that we can type stuff into. Fire up the VirusScan console, and hit the first button - "New Task". Conveniently, at the top of the dialog, there's an edit box. Now, we need a handle to that control so that we can interact with it. Windows is more than happy to give us a handle to any window we like - we just have to ask it. Fire up Shatter, and position it so that you can still see the VirusScan edit control underneath it. Click on "Get cursor window" - Shatter should add an item in the list box beneath like "102f2 - Get cursor window". This is because we've asked Windows to give us a handle to the window directly underneath the cursor. Move the cursor over the VirusScan edit control and hit Space to trigger Shatter again. Shatter should clear the list box, and tell you the handle for the target window - in my case it's 30270. So, we can now interact programmatically with a window that is running with higher privileges than we are. Stage 2: Removing Restrictions Now that we have a window handle, we can send any messages we like to that control and it will blindly execute them. First things first - let's make sure we have enough space for our shellcode. Within Shatter, type your window handle into the "Handle" box. The message to set the maximum text length of an edit box is EM_SETLIMITTEXT. The first parameter is the new maximum text length, and the second parameter is ignored. Click on EM_SETLIMITTEXT to send the message, and try to type something into the VirusScan edit box. Stage 3: Injecting Shellcode Next up, let's try pasting something into the box. Yes, OK, you could just right-click and choose Paste, but for the sake of argument let's work as if we couldn't do that. Back in Shatter, we want to send VirusScan a "Paste clipboard contents" message, which is WM_PASTE. Both parameters for this message should be zero, so set the WPARAM and LPARAM to zero, leaving the handle the same. Click WM_PASTE, and watch your text appear in the VirusScan edit box. Clear the VirusScan edit box again, and fire up your hex editor. It's hard-coded to send a command shell to the loopback adress on port 123, so now's probably a good time to fire up a Netcat listener before you forget. Copy the shellcode to the clipboard, making sure you get all of it (including the FOON at the beginning - we'll need that in a sec). You should now see a whole load of nasty-looking characters in the VirusScan edit box; Stage 4: Executing the code This is the only part of the process that requires any skill. The WinDbg command is s -a 00000001 10000000 "FOON" but you might use a different debugger. Note down the memory location that the string appears at; On my system, the shellcode appears at 0x00148c28, it shouldn't be far off if you're using the same version. Now, kill the debugger, log on as a guest user, and prepare to receive localsystem privs. Follow stages 1 through 3 again, noting that everything still works as a guest user. At this point, you might be thinking that attaching a debugger is a privileged operation. However, much the same as when writing a buffer overflow exploit, you can do that part on any system; Most applications have their own exception handlers (VirusScan certainly does), so if they generate an access violation, they just deal with it and move on rather than crashing. So, there's nothing to stop you pasting in a few hundred kilobytes of NOPs and then just iterating through memory until you finally hit the right address and your shellode executes. The final message that we're going to make use of is WM_TIMER. This is a slightly odd and very dangerous message, since it can contain (as the second parameter) the address of a timer callback function. If this second parameter is non-zero, execution will jump to the location it specifies. As far as I know, the message doesn't even go into the message queue, so the application doesn't even have the chance to ignore it. So, within Shatter, the handle should be set to the VirusScan edit control containing our shellcode. The first parameter can be anything you like, and the second parameter should be 512 bytes or so above the address we picked out of the debugger earlier (we have 1K of NOP's in front of the shellcode, so we should land slap bang in the middle of them); Hit WM_TIMER, and your netcat listener should come alive with a command prompt. A quick WHOAMI will reveal that you have indeed gone from guest to l... |
| slashdot.org/article.pl?sid=02/08/06/1828256 Public Terminal Log in 58 Create a new account Related Links 59 ChrisPaget 60 paper 61 CNET interview 62 More on Security 63 Also by timothy This discussion has been archived. Change The Fine Print: The following comments are owned by whoever posted them. AFAIK by dimator (Score:2) Tuesday August 06, @06:38PM * 75 Re:Someone discovered Windows is insecure. For example, you could layer a transparent window on top of a display, that passed keypresses and mouse events to the window beneath it - and capture everything the user did. You see, most people used xhost for security - which meant that you gave control of your display to anyone who had access to the machine your X client application was running on. Anyone who says a security hole "can't" be fixed is naive - even if the fix is a kludge. MIT Magic Cookie is easily snoopable, so that's another security problem. The X11 protocol itself is easily intercepted, so we have to tunnel over SSH. Linux users who take it on faith that they are secure are sadly misguided - as are those who believe that Windows is inherently less secure. Ultimately, it comes down to the skill of the sysadmin to secure any OS. It was only later that I found out about the DRM component of the EULA. I'm asking a legal question: does removal of the software constitute rescinding your agreement? Or if Microsoft has somewhere noted your initial agreement, is it in perpetuity? If you remove the software, you will be limiting your damages to the damage you caused prior to the removal. But the real question is this: Is Microsoft going to sue you? Is Microsoft damaged if you use their products to steal music? No, unless Microsoft gets sued by RIAA for providing software that facilitates your violation of copyright and then loses, after which they'll come after you in an action for indemnity. Until then, Microsoft isn't going to get anything from you in a courtroom because you haven't caused them any damage at all - and that means until RIAA and the MPAA sue Microsoft, you don't have anything to worry about. If you can get the user to run arbitrary code, they're already dead. Not to say that windows is secure, but this seems to be picking nits to me. He's talking about NT/2000/XP, where you have privilege and non-privilege accounts, and where even as a non-privilege account, you can have stuff running as the Windows equivalent of "root", and you can use any window that "setuid root" application pops up to root the box yourself. The example he gave is the anti-virus program that runs with administrator privs (because it has to do stuff to the registry), when you're logged in as Joe User without admin privs. The anti-virus program pops up a window, and bam, you've hijacked the window, given yourself admin privs, made a new administrator login for yourself, and you're away to the races. If the application in question makes use of the WM_COPYDATA message, this might prove to be trivial. Even if it isn't, you can still map arbitrary data into an application's memory space using WM_COPYDATA. Once the data has been copied into the exploited app's address space, nothing the developer does can secure it 100%. The described exploits relies on two properties of the Win32 API: 1) It lets you copy arbitrary data into another process. It's actually the default window procedure that does this. So, in theory, there should be a certain class of applications that would allow you to inject an exploit into their address space, using WM_COPYDATA, and then jump to that data (from another thread, possibly, introducing the delicate timing issues), and executing it. Note that this can be done before the application code gets a chance to look at the WM_COPYDATA message. Upon closer reading of the WM_TIMER message documentation, several things come to mind that could make this attack less problematic. The OS could filter all WM_TIMER messages, and discard the ones whose LParam doesn't contain an address that was previously registered as a timer callback. They want to get past some restriction on their account - like maybe locate and disable any nasty corporate keyloggers that might get them fired for pr0n-mining, or plant some nasty stuff on a shared PC to grab other accounts credentials so somebody ELSE gets fired for it? Lots of attacks come from inside and lots of *nix attacks are described as "local root" compromises - thats what we have here. If any user can get arbitrary code to run with a higher privilege level than their own, this kind of hole exists. Now, under win32, the application you start, runs under the user you log in with. The virusscanner window in the example, SHOULD run under the user that is logged in, but instead, it's a GUI created from the service, running under 'System'. Not from Microsoft, but from the Virusscanner developer. They should have created, AS stated by MS, a GUI less service (the virusscanner engine) and a GUI application which talks to that service via a named pipe or any other process communication mechanism. That GUI should then be started by the logged in user (since that user sees the gui and works with it), so there wouldn't have been ANY flaw like this, since the GUI isn't ran under 'System', but under the user who's logged in, in the example the 'guest' account. There ya go, a DoD attack which isn't fixable, you can get that attack-script at any hardwarestore. Ummm NO (Score:4, Insightful) by 250 spacefrog (313816) on Tuesday August 06, @08:24PM ( 251 #4022409) How are you arriving at the conclusion that this dialog runs with system priviliges? It uses a fairly secure RPC/IPC mechanism to talk to Windows. A simple trip through spy++ will even tell you the owner process in about 5 seconds. One more commenter who didn't even read the article aren't you? The exploit doesn't require app to blindly trust the user. It's like opening a socket for doing basic network communication and Windows API allowing certain pre-determined 'helper' messages to be handled by OS before your app has any say to handling. You are of course right about UI separation part -- as long as Microsoft really has made it totally clear that's what has to be done, for the security reasons article explains. But that hardly invalidates the claim this is a serious issue, esp. ME) Our network associates have found a bug in the network system. ME) Yes, it seems there is a particularly nasty roving virus that when it hits your system through an open port, can cause your computer to get stuck in an n-th complexity infinite binary loop* *- note blatantly stolen bogus virus description! I'm sure that good open source developers are responsible enough to apply for a key. The real question is, will an non profit open source project be allowed to get a key, or will Redmond only talk to companies that can wave some cold hard cash in their direction? Whoever designed sprintf() and gets() should be shot since there's no way to specify the buffer size. We should all stop using the C library since it's fatally flawed. Or perhaps we can come to understand that some APIs have limits and not use them in sensitive situations. If you read the MS reply, he's saying that they recommend that a system service should not interact with the desktop, and recommends they take this up with Mcafee since they wrote Viruscan. In this case it is always safe to have the buffer be 3+4+1 == 8 bytes in size. It's not just a feature, it's a MUST if you process input of unknown length. You can't blame the library if programmers act stupid and produce unsafe code. And this is different from the Windows misconception in the article, since you'd need to patch the format string here first to be able to exploit this in any way. On the other hand, if you already have right to change code of an SUID binary, you don't need an exploit anymore. You can't complain about Microsoft's lack of security, and then whine when they decide to implement security measures. Palladium is designed to guard against this exact kind of attack. His 'shatter' application would be prevented from accessing the memory of the VirusScan. I liked Microsoft's response to him- his "attack" already requires that 2 of... |