« Posts under x64

PCAUSA Rawether for Windows local privilege escalation

Rawether for Windows is a framework that facilitates communication between an application and the NDIS miniport driver. It’s produced by a company named Printing Communications Assoc., Inc. (PCAUSA), which seems to be no longer operating. Company websites can be still reached through web.archive.org:

http://web.archive.org/web/20151017034756/http://www.pcausa.com/
http://web.archive.org/web/20151128171809/http://www.rawether.net/

Rawether framework provides NDIS Protocol Driver similar to the NPF.SYS (part of the WinPcap). This framework is used by many different hardware vendors in their WiFi and router control applications. Exploit attached to this advisory targets 64bit version of PcaSp60.sys driver which is part of ASUS PCE-AC56 WLAN Card Utilities.

Identifying other affected vendors is quite problematic, since Rawether is just a framework it is possible that the driver name, device name or driver version info were changed. Additionally, verifying if the particular software is really vulnerable is sometimes not feasible, because installation package won’t install without specific hardware.

»Read More

GoGoGadget – kernel exploitation helper class

The aim of this class is to facilitate building kernel shell-codes and ROP chains (at least before RFG kicks in sometime next year) by providing easy access to some of the available kernel information leaks. Under the hood I am using well known NtQuerySystemInformation with following classes: SystemExtendedHandleInformation, SystemModuleInformation. This piece of code came to live as a part of an exploit that I was developing some time ago, but I can’t release it yet. Therefore I decided to publish it as a separate project, so everyone (or just future me) can reuse it for their own purposes. Code is written in C++ and should compile with Visual Studio 2015, for now it only supports x64 platform and some of the functionality is limited to Windows 10 (obtaining EPROCESS address of some of the system processes). I advise compiling Release build, since Debug is very slow due to extensive use of STL

GitHub: https://github.com/rwfpl/rewolf-gogogadget

»Read More

Leaking EPROCESS address of the specific SYSTEM processes

Today I would like to briefly describe a simple method of obtaining the EPROCESS addresses of some specific system processes, which can be later used as a part of the Local Privilege Escalation exploit. This is an extension to the well known NtQuerySystemInformation (SystemExtendedHandleInformation) EPROCESSes leak. In the typical scenario SystemExtendedHandleInformation class can be used to map all processes of the currently logged in user to the correct EPROCESS address (plus a few more processes that allow OpenProcess with the SYNCHRONIZE flag, but I’ll get to this point later). Implementation of this approach is quite straightforward (some details omitted for the sake of readability):

»Read More

IceCTF 2016 Slickserver/Slickerserver pwn writeup

It’s almost 6 months since the last post, so to keep some good yearly average it’s finally time to write something here. For the last couple of months, most of my spare time went into various CTF challenges. Since I’m very new to CTFs, usually I’m not able to solve top scoring tasks and people familiar with CTFs probably know that challenges with lower score are not really interesting enough to write anything more than a few lines writeup (and there is usually dozens of writeups already published, before I even think about writing something). So this time it might be a bit different since the IceCTF was 2 weeks long, and I could prepare some good writeup before competition ends. I did two pwn tasks, which are actually very similar to each other. First one was initially for 300 points, but the organizers figured out, that it’s easier than they thought, so they lowered score to 140pts and published improved version of the task for 300pts. Description for both tasks was pretty straight forward »Read More

wow64ext v1.0.0.6

New version of wow64ext library is available for download:
http://rewolf.pl/stuff/rewolf.wow64ext.v1.0.0.6.zip

Changelog

  • Bugfix for improperly aligned stack. It was aligned to 8, and it was failing when some x64 SSE code was executed as it needs 0x10 alignment. Thanks goes to Vlad, who pointed it out in some recent comment under previous release: http://blog.rewolf.pl/blog/?p=1097#comment-51893. This bug was present since the first version of the library, thankfully now it’s gone.

wow64ext v1.0.0.5

New version of wow64ext library is available for download:
http://rewolf.pl/stuff/rewolf.wow64ext.v1.0.0.5.zip

Changelog

  • Added VirtualProtectEx64
  • Bugfix for ReadProcessMemory64 / WriteProcessMemory64 lpNumberOfBytesRead / lpNumberOfBytesWritten is declared as SIZE_T pointer. SIZE_T on x64 platforms is 64bit value, but wow64ext library is 32bit, so SIZE_T will be 32bit. Passing this pointer directly to the x64 version of NtReadVirtualMemory / NtWriteVirtualMemory would lead to a buffer overflow. To keep backward compatibility, I’ve introduced intermediate DWORD64 value that is used internally by ReadProcessMemory64 / WriteProcessMemory64, result is cropped to 32bit value, but it shouldn’t be a problem most cases.
    Link to described fix:
    https://code.google.com/p/rewolf-wow64ext/source/detail?r=474542f2eb4fc29fd1dde4cd852c419bd6ad1ea0#

wow64ext v1.0.0.4 – bugfix release

Bugfix release, there was a problem with GetModuleHandle64 in the previous version of the library (only v1.0.0.3 was affected). Basically I’ve failed at InLoadOrderModuleList iteration and I was skipping the last element, which is (usually) wow64cpu.dll.

Link to library hosted on google code: http://code.google.com/p/rewolf-wow64ext/
Direct link to zip package: http://rewolf-wow64ext.googlecode.com/files/rewolf.wow64ext.v1.0.0.4.zip

wow64ext finally compatible with Windows 8

I’ve some good news for everyone who was complaining that wow64ext library doesn’t work on Windows 8. I’ve researched this topic a bit, and I’ve released fixed version of the library. Problem was very simple, but it couldn’t be fixed with just one line of code. On Windows 8/8.1 x64 version of NTDLL is loaded at address above 4GB, it wasn’t the case on previous versions of Windows, as x64 NTDLL was always loaded below 4GB. Also some of the system structures are mapped above 4GB (PEB_LDR_DATA64). To fix all the issues I had to introduce new memcpy-like function that can copy data from addresses above 4GB to addresses that are accessible by the standard x86 code. I’ve also fixed problem with case-sensitive GetModuleHandle64 that popped up recently. Below you can find direct link to the updated library:

Link to library hosted on google code: http://code.google.com/p/rewolf-wow64ext/
Direct link to zip package: http://rewolf-wow64ext.googlecode.com/files/rewolf.wow64ext.v1.0.0.3.zip

Evolution of Process Environment Block (PEB)

Update 2016.09.14: This post is a bit outdated, if you are interested in some more recent research in this topic check out Terminus Project

Over one year ago I’ve published unified definition of PEB for x86 and x64 Windows (PEB32 and PEB64 in one definition). It was based on PEB taken from Windows 7 NTDLL symbols, but I was pretty confident that it should work on other versions of Windows as well. Recently someone left a comment under mentioned post: “Good, but its only for Windows 7”. It made me curious if it is really ‘only for Win7’. I was expecting that there might be some small differences between some field names, or maybe some new fields added at the end, but the overall structure should be the same. I’ve no other choice but to check it myself. »Read More

Debugging ring 3 part of PE/PE+ loader

Someone may ask what is the purpose of debugging PE loader, here are a few reasons:

  • checking why executable is not loaded properly (imports, TLS, other initialization related issues)
  • looking for some hidden features (e.g. LdrpCheckNXCompatibility)
  • plain curiosity

Of course debugging ring 3 part of PE/PE+ loader can reveal only part of the truth, for the second part (or rather first part if I want to be strict) there is MiCreateImageFileMap function inside ntoskrnl (source code of this function can be found in Windows Research Kernel: \base\ntos\mm\creasect.c, it is a bit old, but most of the stuff hasn’t changed much). In this short article I’ll cover only x86 and x64 of ring 3 part.

»Read More