7/21/2017 0 Comments Vista SetwindowshookexIf you have not seen it yet, check out the Software Marketing Glossary created by Al Harberg, who runs the press release distribution company DP Directory. FAQ Excel Consultez toutes les FAQ. Nombre d'auteurs : 46, nombre de questions : 845, dernière mise à jour : 30 mars 2017. Practice for certification success with the Skillset library of over 100,000 practice test questions. We analyze your responses and can determine when you are ready. Welcome to VBnet, providing the enhanced functionality of the win32 api to intermediate and advanced visual basic developers using 'VB. Detecting Injection Inside Session 0 Isolation and the UI Detection Service – Part 2 « Alex Ionescu’s Blog. In part 1 of the series, we covered some of the changes behind Vista’s new Session 0 Isolation and showcased the UI Detection Service. Now, we’ll look at the internals behind this compatibility mechanism and describe its behavior. First of all, let’s take a look at the service itself — although its file name suggests the name “UI 0 Detection Service”, it actually registers itself with the Service Control Manager (SCM) as the “Interactive Services Detection” service. You can use the Services. MMC snap- in to take a look at the details behind the service, or use Sc. UI0. Detect) to query its configuration. In both cases, you’ll notice the service is most probably “stopped” on your machine — as we’ve seen in Part 1, the service is actually started on demand. But if the service isn’t actually running yet seems to catch windows appearing on Session 0 and automatically activate itself, what’s making it able to do this? The secret lies in the little- known Wls. Scott Field from Microsoft as a really bad name for a DLL (due to its similarity to a malicious library name) during his Blackhat 2. The version properties for the file mention “Session. Viewer Window Hook DLL” so it’s probably safe to assume the filename stands for “Win. Logon Session 0 Window Hook”. So who loads this DLL, and what is its purpose? This is where Wininit. Wininit. exe too is a component of the session 0 isolation done in Windows Vista — because session 0 is now unreachable through the standard logon process, there’s no need to bestow upon it a fully featured Winlogon. On the other hand, Winlogon. Local Security Authority Process (LSASS), the SCM, the Registry, starting the process responsible for extracting dump files from the page file, and more. These actions still need to be performed on Vista (and even more have been added), and this is now Wininit. By extension, Winlogon. Windows. One of Wininit. Winlogon) is to register the Session 0 Viewer Window Hook Dll, which it does with an aptly named Register. Session. 0Viewer. Ein Rootkit (englisch etwa: HPOWERNOTIFY WINAPI RegisterPowerSettingNotification( Window. Hook. Dll function, called as part of Wininit’s Win. Main entrypoint. If the undocumented Disable. S0. Viewer value isn’t present in the HKLM\System\Current. Control. Set\Control\Win. Init registry key, it attempts to load the aforementioned Wls. Session. 0Viewer. Window. Proc. Hook inside it. If all succeeds, it switches the thread desktop to the default desktop (session 0 has a default desktop and a Winlogon desktop, just like other sessions), and registers the routine as a window hook with the Set. Windows. Hook. Ex routine. Wininit. exe then continues with other startup tasks on the system. I’ll assume readers are somewhat familiar with window hooks, but this DLL providesjust a standard run- of- the- mill systemwide hook routine, whose callback will be notified for each new window on the desktop. We now have a mechanism to understand how it’s possible for the UI Detection Service to automatically start itself up — clearly, the hook’s callback must be responsible! Let’s look for more clues. Inside Session. 0Viewer. Window. Proc. Hook, the logic is quite simple: a check is made on whether or not this is a WM. If it is, the DLL first checks for the $$$UI0. Background window name, and bails out if this window already exists. One of the many exciting changes in Windows Vista’s service security hardening mechanisms (which have been aptly explained and documented in multiple blogs and. This window name is created by the service once it’s already started up, and the point of this check is to avoid attempting to start the service twice. The second check that’s done is how much time has passed since the last attempt to start the service — because more than a window could appear on the screen during the time the UI Detection Service is still starting up, the DLL tries to avoid sending multiple startup requests. If it’s been less than 3. DLL will not start the service again. Finally, if all the checks succeed, a work item is queued using the thread pool APIs with the Start. UI0. Detect. Thread. Proc callback as the thread start address. This routine has a very simple job: open a handle to the SCM, open a handle to the UI0. Detect service, and call Start. Service to instruct the SCM to start it. This concludes all the work performed by the DLL — there’s no other code apart from these two routines, and the DLL simply acknowledges window hook callbacks as they come through in cases where it doesn’t need to start the service. Since the service is now started, we’ll turn our attention to the actual module responsible for it — UI0. Detect. exe. Because UI0. Detect. exe handles both the user (client) and service part of the process, it operates in two modes. In the first mode, it behaves as a typical Windows service, and registers itself with the SCM. In the second mode, it realizes that is has been started up on a logon session, and enters client mode. Let’s start by looking at the service functionality. If UI0. Detect. exe isn’t started with a command- line, then this means the SCM has started it at the request of the Window Hook DLL. The service will proceed to call Start. Service. Ctrl. Dispatcher with the Service. Start routine specific to it. The service first does some validation to make sure it’s running on the correct Win. Sta. 0\Default windowstation and desktop and then notifies the SCM of success or failure. Once it’s done talking to the SCM, it calls an internal function, Setup. Main. Windows, which registers the $$$UI0. Background class and the Shell. Window window. Because this is supposed to be the main “shell”window that the user will be interacting with on the service desktop (other than the third- party or legacy service), this window is also registered as the current Shell and Taskbar window through the Set. Shell. Window and Set. Taskman. Window APIs. Because of this, when Explorer. Part 1, you’ll notice certain irregularities — such as the task bar disappearing at times. These are caused because Explorer hasn’t been able to properly register itself as the shell (the same APIs will fail when Explorer calls them). Once the window is created and a handler is setup (Background. Wnd. Proc), the new Vista “Task” Dialog is created and shown, after which the service enters a typical Get. Message/Dispatch. Message window message handling loop. Let’s now turn our attention to Background. Wnd. Proc, since this is where the main initialization and behavioral tasks for the service will occur. As soon as the WM. It then initializes its list of top level windows, and registers for new session creation notifications from the Terminal Services service. Finally, it calls Setup. Shared. Memory to initialize a section it will use to communicate with the UI0. Detect processes in “client” mode (more on this later), and calls Enum. Windows to enumerate all the windows on the session 0 desktop. Another message that this window handler receives is WM. The service listens either for remote or local session creates, or for disconnections. When a new session has been created, it requests the resolution of the new virtual screen, so that it knows where and how to display its own window. This functionality exists to detect when a switch to session 0 has actually been made. Apart from these three messages, the main “worker” message for the window handler is WM. All the events we’ve seen until now call Set. Timer with a different parameter in order to generate some sort of notification. These notifications are then parsed by the window procedure, either to handle returning back to the user’s session, to measure whether or not there’s been any input in session 0 lately, as well as to handle dynamic window create and destroy operations. Let’s see what happens during these two operations. The first time that window creation is being acted upon is during the afore- mentionned Enum. Windows call, which generates the initial list of windows. The function only looks for windows without a parent, meaning top- level windows, and calls On. Top. Level. Window. Creation to analyze the window. This analysis consists of querying the owner of the window, getting its PID, and then querying module information about this process. The version information is also extracted, in order to get the company name. Finally, the window is added to a list of tracked windows, and a global count variable is incremented. This module and version information goes into the shared memory section we briefly described above, so let’s look into it deeper. It’s created by Setup. Shared. Memory, and actually generates two handles. The first handle is created with SECTION. The handle is then duplicated with SECTION? The type name is UI0. The function we just described earlier (On. Top. Level. Window. Creation) uses this structure to save all the information it detects, and the On. Top. Level. Window. Destroy does the opposite. Now that we understand how the service works, what’s next? Well, one of the timer- related messages that the window procedure is responsible for will check whether or not the count of top level windows is greater than 0. If it is, then a call to Create. Clients is made, along with the handle to the read- only memory mapped section. This routine will call the Win. Station. Get. Session. Ids API and enumerate through each ID, calling the Create. Client routine. Logically, this is so that each active user session can get the notification. Finally, what happens in Create. Client is pretty straightforward: the WTSQuery. User. Token and Impersonate. Logged. On. User APIs are used to get an impersonation logon token corresponding to the user on the session ID given, and a command line for UI0. Detect is built, which contains the handle of the read- only memory mapped section. Ultimately, Create. Process. As. User is called, resulting in the UI0. Detect process being created on that Session ID, running with the user’s credentials.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |