 All right. Our next presenter is Brett Moore, CTO at securityassessment.com, who today will be presenting Sheeper Messenger using window messages to exploit Win32 applications. Without further ado, here is Brett. They told me I was going to present in the tent. I thought it was going to be really, really hot, but it's nice to be in Vegas. You actually go inside to cool down. You can't hear me? All right. That's cool. Okay. Okay. First of all, we're going to talk about some stuff, just to put it into context. When the first real shadow attack was made public back in 2002, everybody can hear me? Okay. Back in 2002, when the first shadow attack was made public, it was not really a huge security issue. Even Microsoft and sales took some time to realize that there were some problems here. If we look at the ... I'll try again. All right. If we look at the Windows operating system, it's not historically been considered secure enough to be used in highly secure networks. While other operating systems have gone through this vulnerability discovery phase, this was something new to Windows, and like any new system, it had holes big enough to go up a bus through. Does this make sense? Everyone can hear me? All right. Okay. Next slide. Now, right now, it's new exploitation methods. Shadow attacks are maturing. It's now acknowledged they no longer just affect the WM time and message. The scope of the shadow attack problem is widening. We are starting to see some very solid news from Microsoft towards security. They're releasing operating systems with default settings off. You've got a boot and firewall now, and of course, there's XP sales back too. With this advancing Windows security, there are going to be more and more Windows machines inside secure networks, and that's more and more untrusted users. Okay. So the shadow attack exploitation problem is going to widen in scope, and hopefully this presentation will discuss and demonstrate some of the areas in which it is hidden. It will happen one day that the Windows operating system will be considered secure, and as such, they will be deployed everywhere throughout secure networks, and there are restrictions that are put in place on the workstations will be considered enough to control the access to the network and the data, as well as restricting the user's privileges and what actions they can take. All right. Okay. So shadow attacks or GUI attacks, 132 messaging attacks, they affect more than just the core operating system. Any third-party application or service that ran with an elevated privilege may be vulnerable to these types of attacks. This means that even if Microsoft patched every vulnerable instance in their products, like you're sure, your workstations that are running the Windows operating system may still be vulnerable. Excuse me. Now, it is possible that Microsoft will apply a fix at the core of the problem, the messaging system, but this is very unlikely, and even so, it would not be ready anytime soon. In a real-world environment, how can shadow attacks affect the system? Now, of course, privilege escalation is the major impact of these attacks, and in general scope, the most important, there goes the jet. Now, currently, they are restricted. I say currently, they are restricted to local exploitation. Now, this also includes remote desktop sessions, as well as the possibility of worms, trojans, and other malicious programs utilizing these attacks to increase their access to a system. Now, currently, programs such as personal firewalls, antivirus systems, and other monitoring software that run evaluated rights, they have even found vulnerable to these attacks. Most third party applications, especially in the antivirus industry, are vulnerable to these attacks, so we will eventually see viruses that attack antivirus programs to gain system rights. Now, yes, so successful attacks could allow untrusted users to elevate their privileges to a higher level, allowing them to store malicious program, yeah, that's what I wrote. Keyloggers, sniffles, et cetera. Okay, so we've talked about if an application runs at a higher user account, a malicious person can gain elevated rights. All Windows programs include default handling for messages such as WM close, WM quit, NNC destroy, et cetera. So this can allow people to shut down firewalls, personal firewalls, antivirus monitoring. So once again, we're going to find, we're going to have viruses that gain elevated rights, shut down antivirus software, and of course, in spread. Now, other attacks can involve the manipulation of controls to allow access to a thick client area. Within thick client areas of the applications that are restricted by having a disabled button, disabled toolbar or a menu, a user can simply send an enable message and then this could allow them to have access. We'll talk a little bit about thick clients later. If data from a user input is used or data from a GUI control is used, it could cause ESCAL injection attacks, file reading, file access attacks, and of course, textbook buffer overflows. Now we're done with that. So the Windows operating system uses a mechanism known as Windows messaging. This is used to communicate events such as user input, system notifications and control information between Windows. Unlike the old days, I was going to say the good old days but I'm old, where an application would stop and wait for user input. Windows messaging allows an application to process input. Only when there is input waiting for a window owned by the application. Every window created on the desktop has a unique window handle which is used to identify it within the system. Messages are passed to the system which in turn directs the messages to the appropriate window to handle the message. The window then processes this message depending on how it was sent and what parameters were passed with it. Now every control such as a text box, a list box or a form, it's all derived from the base window class. So throughout this presentation when I'm referring to a window, I'm referring to any type of GUI control. So the problem with this method of sending messages is that the operating system allows any user to send any message to any application. And in most instances the application will blindly accept the message and act on them accordingly. So by exploiting known weaknesses in the messaging system, an attacker can manipulate applications for an arbitrary advantage. So how does a message get from point A to point B? So there are two main API calls that are used to pass messages to windows and various sub-APIs underneath these. Like I said before, all of the API functions, they pass the message to the system which in turn directs it to the appropriate place. Now post-message and its related functions, they pass the message data to the message queue of the thread that owns the destination window. And the sending application then continues without awaiting a response. A thread's message loop is constantly called the message queue. Removing and dispatching any messages to the appropriate window procedure for the window identified by the unique window handle passed through the API function. Now the sending message family functions as it passes the message directly to the window procedure of the target window. And after the window procedure, it processes the message and returns the sending application and then continues. Okay we're back. Now the window procedure is where the message contents are processed. It is in this function where the decision is made based on the message type to handle a message or to ignore it and pass it up the handler chain. Every window has a window procedure and it's just derived from the base window procedure for the class of the control. Okay, it's going to eventually that you can overwrite class structures, subclass classes before they're defined by the system, create your own window procedure which are then going to be derived throughout the system applications. Every thread which uses a GDI function has a message queue and therefore every thread that creates a window has a message queue. So we need to keep this in mind when thinking about what sort of applications are vulnerable to these attacks. Some applications or services which do not normally have a window can be enticed to create one. We think about the net send, some more pop-up message box, the printer print spooler, the system level window is created by that and various other services do the same sort of thing. I hope I'm making sense because I can really hear my accent coming back at me. So to help with the understanding of how a message becomes exploitable, I broke them down into three categories. We have a type one message, the data is marshalled correctly, everyone behaves properly, it works. If we think about a WM set text, we pass a text string, it sets the caption of a window, etc. The data goes from one application to another one, and everything works correctly. Now a type two message, the data doesn't need any marshalling. It's a long value, it's a pointer, it's used directly. Sorry, it's used on a pointer because that'd be marshalled. So these type of messages, they can be used to control GUI properties, sizes, etc. And in some cases, they too can be exploitable. If we think about the WM timer message, it worked properly, everyone behaved, the data didn't need marshalling, it just was written insecurely and allowed you to pass an address that was then used as a callback. So a type three message can be used to overwrite arbitrary memory. It does not go through this marshalling process, but it should. A value is passed as an offset to a data structure and because it is not marshalled, it allows us to control the area of memory in memory where the receiving application writes the return data. So what is message marshalling? So, message marshalling is the process of taking message parameters from one thread and passing it into another. Now generally, messages between the same application, sorry, are passed between the same application, so accessing of memory is not a problem. When messages are passed between applications though, from one to another, memory addresses they need to be modified so that the data from the sending application is valid in the receiver. So, I found this on MSDN and it says any message with a value less than WM user is marshalled automatically by the system. There are system defined messages and the operating system is aware of what parameters need to be handled and how it should be modified. And as you can see here on the slide any message above WM user is not marshalled automatically. If you think about the list view control, the tab view, the tree view, all the new common controls, all the messages are above WM user. So, it's not surprisingly that there are a large number of these messages that are not marshalled. And some of them can be used for various methods of exploitation. So we've got a couple of examples here. Yeah, thank you because probably you'll read better than me at the moment. We have the common control, we have HTML first, 1200, man, that's way above WM user and you've got gear item wrecked. Way up there. Even fine text with a rich edit control. WM user plus 56. If you've got visual studio, just look through your libraries, your includes, they're all there. Okay, so the messages were an idea less than WM user, marshalling depends on the function of the message. Like I said before, if the message is passing in numeric values like a type 2 message, no marshalling is required. And we've got here, for example, the WM timer. The timer clock is passed directly, it doesn't need updating, it doesn't need marshalling. But if the message is passing a block of data, such as a text string, then the block of data and the relevant pointer need to be managed so that the receiving application can access the data. If you think about it, if we've got one application here and it's got a text string and it wants to pass it over to this application, it can't just pass a pointer because this application can't access the first application's memory. So we did a bit of research to try and find out where this went. Okay, so the GDI shared handled table, it's a block of memory that is shared between all GUI threads. This table holds the handles of all opened objects from any GUI thread and has enough space for 4,000 entries. We thought that was really interesting. It's like, oh wow, so we can access a handle from any application for an opened control. We thought, oh, what if we could start writing in there and overwriting stuff. But we found out it was read only. So at this point, someone's got to look in there further. Anyway, so a pointer to this location can be found in the process environment block at 7FDFO94. 60,000 bytes up from there is the start of the process mapped heap. Now, it is in this heap block that the system marshals the data into. Because every GUI thread has this heap block mapped into their address space, the system can copy the data into here and any other GUI thread, or any other GUI thread application process, can then access this shared heap to retrieve the data from it. So what happens is the system, the first attack application sends a message to the system. The system takes it, and it takes the data and it moves it into the shared heap, and it updates the pointer, and then passes that pointer parameter to the receiving application. Okay, so every GUI thread, like I said, it has this memory mapped into their address space, but it's at a different base location. But the actual data remains at the same offset within that heap space. So the process is mapped here, but it appears to be mapped at a static location per application, which allows us to calculate an offset between two applications. So what I'm trying to say is, the utility manager might have the base heap here, and the print spooler might have it here, but because it's a shared heap, so it's the same size, so if we can find the data in one application, by adjusting it, we can find the data, the exact location of that data in another application. So of course this removes GUI guesswork involved in getting data into another application, and allows for exploitation of more complicated messages. So I hope it's pretty self-explanatory. In the second app, we've got the map heap at 4900,000, and the target app is up at 53, so that's the difference of A00000. But if we found our data at 53 at CO, we just simply add A00000, and we know exactly where it is in the other application. Okay, so we'll come back to that in a sec. Well, I don't know man, it's going really fast. Okay, so we'll mention some points on shellcode. When I'm talking about shellcode, it's any data that's been used in an exploit structure block, text string, bytecode that runs a command shell. Now if it is a command shell that's required, exploit the shellcode, it only needs to call the system API to give you a system shell. You can make it more robust by calling load library, and load the appropriate DLLs. But because the shellcode is crowded and executed locally, any relocatable addresses can be correctly assigned before sending the exploit. Now, this removes the need for a function address lookup code which is normally found in remote exploits, and it allows you to craft an exploit that is completely operating system and service back independent. Now, all the APIs that are used to pass messages, they have wide character or unicode equivalents. So this means that complete byte arrays can be passed, and in most cases they can contain null bytes. Now, the setWindowTextW function is a wide character wrapper for the sendMessage API, and to send the WMSetTextMessage. So this can be used to set the title caption of windows, and it's an ideal way to pass our shellcode. Once again, I hope the slides are self-explanatory. Of course, the string is terminated by a wide character null. The two nulls are in the wrong place. It's a null termination of the string, and it won't be passed. The setWindowTextW, it will use the same address space. If the length of the text string is the same or less than what was previously used. So if it is required that we need to write shellcode, bytecode, or data structure into an application's address space that does contain wide character nulls, we can do it in a reverse manner. We can see here we want to write a wide character null, so we do it by writing the last part of the shellcode first, and then by sending smaller and smaller bits. The shellcode will be created properly as we need it. So there's been various methods that are used to locate the shellcode for shadow attacks. And while these can all be successful, they have been downfalls in the past. So this guessing the address technique makes it difficult to exploit messages that require even the simplest of data structures. There's been brute force, arbitrary byte writing, memory reading, et cetera, et cetera. Now, of course, Padgetty released something I think last year at Black Hat, and he noticed that when you create a message box, that text in the message box is copied to every application. Now, what I think he was saying or what I think he was seeing was the process mapped deep that I explained before. So we can use the process mapped deep to pass our data, our shellcode, into another application, and find the exact location of it. So for the target application, we simply open the process, read it from the BEB, and adjust it. Now, of course, yeah, this requires the bug rights, but so does it when you're creating a remote exploit. So that's done on a computer under control of the attacker, like I said before. The application has the base mapped at a static location. So if we find it on our computer, it's the same on that computer or that computer. The base address for the exploit or the attacking application can, of course, just be read locally at runtime from the BEB and adjust it. And this thing gives us an offset between the two applications. So like I said before, using the setwindow.txt.w function, it's a great way to place our shellcode into the mapped deep. Now, on this graphic, we've shown the setwindow.txt.w message being sent to the target application. That's not necessary. We're going to send it to ourselves and set our own caption. Either way the data will be in the mapped deep and therefore accessible to all GUI threads. The attacking application then simply looks through its mapped deep, finds the offset of the data, adjusts with that offset that we discovered on the previous slide, giving us the exact memory location in the target application where our data is. So to recap, it's sort of like we can now place arbitrary data containing any values into a non-location in any application. So this forms the basis for all messaging attacks going forward and allows us to exploit messages that require complex data structures, including pointers into pointers. So the callback attack, the classic Shatter attack back in 2002, WM Timer. These sort of attacks exploit messages that pass a function address to be used as a callback, as well as callback addresses. Okay, so Microsoft announced this was a problem with the WM Timer and they released a patch. The patch was we won't accept messages for addresses that are not previously registered. So far it seems to be working. But since then a number of other messages have been found vulnerable to these attacks. Of course we've got the EMSit with big proc, LVMSort items and we've got a few others that accept a callback within a structure. So it should be realized that any message that takes a callback as a parameter is possibly susceptible to these type of attacks. So the attack starts, we get the shell code into the non-location of the application and as we explained before, we can use the process map to heap and we simply send the callback message personally addressed that we've discovered and that's it. There's no guess work. It's all sweet hours. So the callback message is sent specifying the location of the shell code as the callback function and in most cases the application will blindly accept it and the shell code is executed. So not too long ago, Ovidio and Malo released a package with the name of Easy Shatter. I thought this was quite funky when I found this. What he realized was that the callback function for the EMSit word by proc EX message, it took a pointer to a text string as its first parameter and he realized that the load library function also took a pointer to a text string as its first parameter. So his exploit involved typing or pasting the name of a DLL file into a textbox and seeing the EMSit word by proc EX message with the address of the load library function as a callback address. So what this meant was that any DLL that he had typed into this textbox was then loaded by the target application and then the initialization code in the DLL was run. So this removes the need to write or find any shell code in the target application. And it's pretty much typical return to libc type exploit. So if we look for other APIs that sort of fit this mold, we've got setUnhandledExceptionFilter and the SystemAPI to my two that is spring to mind now. The setUnhandledExceptionFilter it would involve sending the shell code to a textbox and then sending the callback message with the address of the setUnhandledExceptionFilter as the callback that would then set the top-level exception filter to address of our shellcode would then cause an exception and the shellcode is run. The SystemAPI would be much easier to use and simply involve typing command EXC in a textbox and sending the EMSit word by proc EX message with the address of the SystemAPI as the callback function. So this is what we've done here to exploit the EMStremeInMessage. Now the EMStremeInMessage takes a pointer to an editStream structure that holds a cookie value and the address of a callback function. So using the setWindowTextWAPI we're able to create this valor structure in the process map heap and find the exact location of it. Now the actual editStream callback function is past the cookie value as its first parameter. So by setting the cookie in the editStream structure to the address of the string to execute and the callback address to the system function we're able to cause the rich textbox to open a command shell. Now the chance of a system application having a rich textbox is about zero but what we're trying to show here is that it's now possible to exploit more complicated messages that require complex data structures even including pointers into themselves. So back in 2003 it was discovered that various messages could be used to write arbitrary data to memory locations. Now the exploitable messages revolved around the use of two different types of message, you know, set the size, retrieve the size into a location. So some people discovered that the value passed with the LVM getItemRect structure or message it was not marshaled properly so it could be used to write a Rect structure to arbitrary locations. This was used in conjunction with the set column width message to achieve arbitrary byte writing. What we've got here is a head on the screen but behind that if we set the width of the first column that adjusts the left member of the second column. So if we set the width to five and then retrieving the Rect structure of the second column we can have five written wherever we like. It's all documented in papers. Using multiple calls we can write our shellcode to a line location. That's alright but we use the process map heap now so we know where our shellcode is so it's not that important anymore. So we've got a whole lot of messages this is all with public exploit code and you can see it affects quite a few mainly the common control, the new one, the common control 32. These are the buttons under XP. We thought it was really quite neat when Oliver released that code where a button allows you to write arbitrary bytes into an arbitrary location. Alright, so like I said before we can use the process map heap now to find out where our shellcode is so the arbitrary byte writing is not such a big deal but we still need to get our code to execute. So what can we execute? What can we overwrite to gain execution? So the top level exception handler or the unhandled exception filter is commonly used in remote exploits, you know, overwrite SEH, get control so we can use the same method. We write our shellcode up to a non-location, a non-writeable address and then overwrite the top level exception handler and it calls an exception and the shellcode is written run. But in some cases the SEH method it may not work so an attacker can overwrite various other windows like memory locations such as the PEB lock and unlock pointers. So as with SEH the shellcode is written somewhere but we're not able to overwrite the PEB byte by byte because it will be used between our message send so what we need to do is we need to write it to a location in the heap that contains the lowest significant word of the original PEB pointer and then by overwriting the third byte the zero automatically written to the end so I hope that makes sense. We write our shellcode to the heap somewhere that you can see like at 7.9103 and then we use the original 9103 of the original PEB pointer and just overwrite the other part. So we've got a graphic here, messages flying around somewhere. Alright but in some cases you can't overwrite the PEB, they don't exist on some writing systems. So we're going to overwrite the GDI dispatch table pointer. Now this point is the location of a table of functions and can be overwritten in a similar manner. Once again it can't be overwritten byte by byte because it gets used in between our messages so we use the same method we just tried to explain about overwriting the PEB but we've got one extra step here, we put our shellcode somewhere like a way up in the PEB and into the heap like using the lower significant word of the original GDI dispatch table where a whole block of pointers to our shellcode and then we overwrite the GDI dispatch table, system will come back and it says I want to make a GDI call at userland so give us the table where's the function called our shellcode. It's also possible to overwrite the C run time terminators these are called from the exit routine on normal or abnormal application shutdown. So even though we're talking local attacks here these pointers can be overwritten by remote exploits as well. As you can see here these are aesthetic pointers. Okay so what happens if we overwrite we address our shellcode like we write it to 7803014C then when the app shuts down, either by sending a WM close or causing an exception, abnormal or normal shutdown our shellcode will once again be called. Okay so we can place our shellcode in a normal location, there are multiple ways of having execution either through arbitrary byte writing or through callback attacks there's not much more to go. Okay we got just like any of the numerous security vulnerabilities that are caused by these unsafe user input, the message data needs to be sanitized and checked before it is used. MSO3045 proved that even messages that use data that is marshaled correctly may not be safe from exploitable conditions. So the buffer overflow in user 32DLL could be caused by sending a large directory name to a list box through the LVDuer message. So sending this attack against the list box within utility manager allowed an attacker to escape the proof of it as you can get root, get your system this cool. So yeah I don't know how many of you read, if you've read running secure code from Microsoft so not too bad. Includes a couple of paragraphs about some dangerous messages, Michael Howard stresses if you're going to use any of these messages that you need to send the get text or the get length messages, the corresponding get length messages first. What makes these messages stand out is that there's no way to pass the length to restrict the data the length of the data that you're getting back. That's all cool that's good advice but as you can see they're all above WM user anyway so most of them can be used for arbitrary byte writing. So this whole thing about request the length allocate your buffer and then request the data this is just like race condition stuff. So if you're going to the lengths to try and protect your applications you need to be aware that if you request the length and then like create a buffer of 100 but I mean it's too late because the attack has already increased the length of the text to 500. If you then read that in through one of those vulnerable messages we just told on previous slide you have textbook buffer overflow stuff. So spy plus plus which comes with visual studio, that's probably the utility we've used the most during our research. It allows you to quickly list all the windows that are open, find out the thread, the process that owns them and grab the window handle. It also shows you a few various window properties which are starting to get interesting. I mean this whole thing about how you can look at a window that any application owns and start discovering stuff about it. I mean that just sounds wrong already. So there's a lot of stuff there to look at but it just needs to look at it. So on windows 2000 the task manager doesn't show you what user the app is running under. But if it's running under system you can't close it. Under windows XP of course it does excuse me, it does show you the user the applications running under. So I mean that's really easy. I mean it's sought by user and it's like there's still a dozen service level apps. So once a target window has been acquired, you can run a message fuzzer against it. A message fuzzer is just like any other type of fuzzer. It should be on the CD or on the website, there's a whole lot of code. So it iterates through a range of messages forever. It's sending different types of data, 0, 1, 1, 0, 1, 1, 1, none. And it is really quite interesting because you can kill anything. Every application is vulnerable to a message fuzzer. You just run it and things start dying. Now if you do want to write a fuzzer have a look at the code because I sort of hacked it out quickly but it does work. I mean there's some messages you want to avoid. There's no point in sending a WM close to an application and then thinking that it's going to keep processing messages because it's shut down. Also your fuzzer might see messages that cause local exceptions. If you've seen WM set text with one as the parameter, well it's not going anywhere. And check the event log. The MSO 3045 I think it was. We ran the fuzzer against the list box on your silly manager and it was like, oh wait man, your silly manager died? What's happening? And we couldn't work out. It's like, oh, have a look at the event log. It's like crash, crash, crash, sweet. So then you've got to get a bugger on it and start reverse engineering. What's going on? Have a look at it. So it's kind of what we did here to exploit the WinHelp 32. So I haven't got notes on this so I'm going to try. What happened is we realized that the context sensitive help from Utility Manager was that tool tip that pops up. It's actually WinHelp 32. That's what Task Manager is. We could see that it was, WinHelp 32 has now been loaded as system. It's like, oh great. So what it is it's like another attack avenue. We've got another app that's running a system that shouldn't be. So we ran a fuzzer against it. Just passing by. We found this message. We passed one as the parameter. So what you can see is it caused an exception. Pretty basic stuff. Trying to access four. Which is like EDI plus three. So that's cool. We passed this message and we controlled EDI. But EDI didn't get your execution. So we wrote a whole block of ones up in the pub and we updated EDI to point to our block of ones. And then we continued running. So then we got another exception. This time we got the registers over there and the ESI points to 11191. So it's like oh cool man. We loaded ESI with the value from our block of data that we pointed EDI to and we controlled EDI. So in theory we controlled ESI. But it still doesn't help us. So what we've ended is we updated ESI to point to our block of ones again and continued running. And as you can see in the call stack down there, execution ended up at 11191. And it's like aha so we controlled EDI and through that we controlled ESI. And through that we now control EIP. So what we tried to craft was a callback attack using an undocumented message against an application. So what we had to do was create an export structure. It's consisting of a block of pointers pointing to another block of pointers pointing to the shellcode. And we put the structure up in the process map heap to find out where it was since seeing the message passing the address of our structure. So we're sitting EDI at the address of our point at one block which would be accepted, great. And then it would show the previous slides. ESI would then be loaded with the address of point at two block. And then as before when it does the call ESI plus 36 it loads the address of the shellcode. The shellcode is executed. I mean that was great. Cesar Cerudo, he does some really cool stuff on following up with us. And he's found this like much easier. He just sent a WM command help message. But we thought this was kind of strange because what we were trying to do is find new stuff. And this is like undocumented messages against applications. So what I'm really trying to say here is like there's more messages out there than just the ones that are in EMSDN, just the ones that are in your library. Every application can have its own custom messages. And of course this opens up the avenues for more and more attacks. Okay. Alright. So another thing that programmers or hackers or of us need to be aware of is default behavior that some controls exhibit. You've got things like the list box and the combo box for example. I like you to imagine it works off the funny one day going to kill it. But by default the LBDuer and the CBDuer message can be used to display directory listening. So what we've got here is got the list box of utility manager. I mean we've sent messages to resize it, that's cool. But we've got Sender and LBDuer and we can read any directory as system. It's things to be aware of that that's a list box that we can use to view any directory. What about when you get stuff that you can like load files? So you're like loading files with system. So you've got like system apps that display an about screen with a hyperlink. You know, come to our website, they might load the browser as system. Because then you can browse local drive. Right mouse clip, open with Command-DXE, you've got a system level shell again. Any system application that allows you to load files. Right mouse clip, open with, blah blah. Okay, we got, we tested one recently and they tried to avoid this problem by using the older file dialog type box, which is the one down the bottom left there. But guess what, you know your right mouse clip has got what's this, that's a tool tip, that's 1-HELP32, load it as system again, exploit it. So I don't know if you guys are any of you do write system level applications you want to protect, but these are some of the things that you may want to be aware of that there's more to this stuff than what meets the eye. There's a lot of stuff in the background that just happens by default. And like I said before, Cesar Saruda, I mean we talked about it, but with his latest exploit that he put out, it's pretty much any system level app that has context-sensitive help, you can send his exploit against it to give you a command shell. Anyway, we'll keep going. So what happened, just a bit of history on that problem is, like I said before, we discovered that utility manager was loading 1-HELP32 as system, it could be exploited, Microsoft patched that, but all they did was they removed the question mark button. I mean they forgot about this default behavior. All forms will accept the WCM help message and give you tooltipped help. If there's a help file set up when you compile your application, because Microsoft just removed the question mark, it's like, yeah, we'll just hide it. And I mean it took him like 20 seconds to re-break it. But what was kind of interesting about his thing was that first we had to send a, I can't remember exactly what it is, but it's just a message to pop up the system menu, right click on the control bar, but you had to post message that, and then send message for WM command help. So that's something else. I mean if you're running fuzzers and whatnot, you gotta be aware that different messages will have different effects maybe used in conjunction. Alright, so where are we going to go with these GUI-based attacks? The scope's going to widen, attacks will become public that no longer depend on the user controls and messages. Exploits, they'll focus on the APIs that can be used to manipulate GDI data, not just Windows messages. We've done some research into the crosswind station desktop attack, you know, if you've got an iOS, iWam user shell, can you get system, so far not, we're running out of time and that's kind of boring. Okay, so we look at these other APIs, these other manipulation ones. Okay, oh you can read. Yeah, MSDN it states, you know, the set parent, the new parent and the child window must belong to the same application. That's not right, you know, any application can set the parent of any other window. Now, like I said before, we haven't been able to exploit this against a system-level app yet. We have been able to exploit it against just apps running, you know, test apps and normal apps running on our desktop, but this is the theory, you know, exploit becomes the parent, the window with the application, request the parent through a get parent, and then ask the parent for some data so the exploit just returns corrupt data, causing exploitable conditions. So, Windows properties, yeah, I mean every window can store a whole list of data that's relevant to itself. I've got an example, it's like an MDI application might store a unique ID associated with each window, that's a link back into the database. See, I'll getProp and setProp. Now that's the same problem, any application can get and set, can get and set the properties of any other application's window. So, we went able to exploit this against any core Windows OS services in our one-week testing before we came here, but the first third-party application we tested was vulnerable. As you can see here, Windows subclasses, all on FC derived Windows to handle specific activation issues. Again, it stores it in a window proc, we can overwrite the window proc, and it's chained because it's the subclass thing. So, we simply overwrite the window proc with the address of our shellcode, which is in the process map, and once again, we get in control. And this is like through a non-message based GUI attack, or Shatter attack, or whatever the name's gonna end up being. So, we've got some thoughts on protection. You know, there's been discussions about using filter messages, only allow some, don't allow others. It's not just messages. You know, I mean, these things are gonna expand, hopefully. You know, I want people to go there and look for stuff. It's like, it's not just this, man. It's now this, that, that. So, there's a lot of stuff out there to look for. Windows shouldn't be created via privileges, blah, blah, blah. Applications find messages. If you write your own application, it uses custom messages. Can they be exploited? Again, service should talk to GUI using RPC, sockets, name pipes. That'll be fun. Alright, and we've got a registry sitting here. You can turn off interactive services. You know, I thought, I mean, I found this guy's had to fill in some slides before I came here. And I thought it was, it's got a cool way. You know, you turn this registry setting off, and what happens is you now have services popping up error boxes with system level access. I mean, what's the point in that? And understanding the threat, the problem getting up there and finding some stuff. That's it. Okay. Sorry. Are there any questions? Okay.