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):
So, it seems that not only ASUS drivers allows unprivileged reading and writing to physical memory. Just a few months ago I was looking at the drivers that are loaded on my machine, and I found small MSI driver called NTIOLib_X64.sys. Out of curiosity I’ve looked at it in IDA and it turned out that it has almost the same functionality as the ASMMAP/ASMMAP64 ASUS drivers. I’ve tried to contact MSI through various different channels, but I haven’t really get past their customer support, so I’m not sure if anyone from the development team is aware of this design flaw. After almost 4 months I decided to publish my findings here.
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
I neither play CTFs, nor I do writeups for them. Well, both statements are not true anymore, but don’t expect too much CTF writeups on this blog anyway. The task was worth 500 points and according to my knowledge nobody submitted the flag on time (including me as well). So, enjoy the reading and I hope you will like it.
Recently I’ve got asked about this quite an old unpublished project that I actually forgot about and I decided to finally do something with it. I’ve mentioned it once in this post: http://blog.rewolf.pl/blog/?p=856 and I’ve shared below screen-shot with an annotation that it will be published soon as a part of dirtyJOE:
One and a half year passed and I did nothing regarding this integration. Even more, at some point I came to the conclusion that this project does not fit for dirtyJOE as it’s rather Proof of Concept than a proper solution to the problem (no matter if the proper solution even exists). I’m still not sure if I don’t change my mind and eventually make it a part of the dirtyJOE, but I’m 100% sure that JVM Operand Stack Viewer deserves a release. An open source release with the full description of the method used to obtain JVM operand stack.
Some time ago I was writing a small class that was supposed to list items from windows objects directory (like WinObj from Sysinternals). Given the fact that there are a lot of examples out there on the internet, it seemed like an easy task. I’ve started coding it without reading any documentation, except required functions definitions:
NTSTATUS WINAPI NtOpenDirectoryObject(
_Out_ PHANDLE DirectoryHandle,
_In_ ACCESS_MASK DesiredAccess,
_In_ POBJECT_ATTRIBUTES ObjectAttributes
NTSTATUS WINAPI NtQueryDirectoryObject(
_In_ HANDLE DirectoryHandle,
_Out_opt_ PVOID Buffer,
_In_ ULONG Length,
_In_ BOOLEAN ReturnSingleEntry,
_In_ BOOLEAN RestartScan,
_Inout_ PULONG Context,
_Out_opt_ PULONG ReturnLength
I’m not quite sure how I ended up deep inside DOSBox debugger, going through 16bit assembly and recovering decompression routine used to handle MM3.CC file, but it was definitely fun. I got the game from one of the recent humble bundles and somehow (this is the part that I’m missing) I’ve found Jeff Ludwig’s page. I’ve read about his approach to modding Might and Magic III and problems related to compressed/encrypted MM3.CC data file. One of the phrases sounded like an invitation:
“It turns out that this algorithm has been a particularly tough nut to crack, and no one has come up with a viable way of decrypting the data.”
I recommend reading the whole story as his method of dealing with this problem is also great. In this post I’ll describe how I’ve handled it, in the end there will be link to the open source utility that can not only decompress, but also compress valid MM3.CC file.
Two days ago VMware published new update for Workstation version 10 (release notes). According to the changelog it should fix some security issues reported in OpenSSL. That’s nice, however there is a small problem with this update. VMware.exe (the GUI part of VMmare) started crashing immediately after update. This was quite a learning experience, do not update critical software if you have something important to do, as the new version can be worse than the one you are using. Since I didn’t have the previous installer at hand, I had to somehow resolve this issue differently (yeah sure, I just wanted to debug it and see, why it is crashing).
Every once in a while I’m posting solution to some crackme that I consider interesting. By interesting, I mean the solution, so it is not exactly about key generation algorithm but also about technology and tricks that are utilized. Looking at the traffic statistics, it seems that this topic isn’t exactly the one that people would like to read (three posts – 5,63% of total unique page views), but I’m truly convinced that it has great potential for every single person that wants to learn something new. All in all, there is at least one person that benefits from those tutorials – ME :) Back to the topic, in this post I’ll describe warsaw’s Java Crackme 3. Crackme was published on 14th October 2012 on crackmes.de, I’ve picked it up around February 2013, so literally speaking, it took me one year to solve it (of course I had some huge breaks meanwhile). Difficulty of the crackme was set to 5 (Professional problem to solve) in the crackmes.de scale and I must fully agree with it. It is Java crackme, but it wasn’t written in Java, I’m 99% sure that it was written in Jasmin or other assembler for Java Virtual Machine (JVM). Hand-crafted assembler and bunch of obfuscation tricks renders all existing decompilers pretty much useless, so it will not be yet another simple Java analysis.
Bugfix release, there was a problem with GetModuleHandle64 in the previous version of the library (only v126.96.36.199 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.v188.8.131.52.zip