Reflections on 100k

I just hit 100,000 reputation on Information Security StackExchange! 🎉

I thought this would be a good moment to talk about why StackExchange is so important to me, and what my journey into security looked like. The story starts way back in 2012, before I worked in infosec. Back then I was a few months out of university, having studied for a computing degree (basically compsi + dev management), working my first job as an entry-level developer. I had already been interested in security for over a decade by then, but I had no idea it was a career path. I knew about StackOverflow – who didn’t? – and later discovered that they had a whole host of sister-sites for other topics.

Within no time I was hooked. The gamification of reputation points and badges were a nice distraction, but more than anything I really enjoyed answering questions. From around July 2012 to January 2013 I was consistently answering around 50% of questions submitted to the site every day, which shot me up to around 20,000 reputation. Want to know a dirty little secret? I didn’t know the answers.

See, back then I had no formal education in security. I had learned some things through experimentation – mostly messing around with computers and writing bad code – but I’d never really been taught any fundamentals. I’d picked up a few tricks from websites that taught you how to hack or how exploits worked. I’d played HackThisSite and been to all the usual questionable places. So, in the early days of answering questions on Security StackExchange, the best I had was a little background understanding and my ability to Google. It turns out that this is a fantastic way to learn. In university you’re being introduced to a new concept or idea every few days. In a job you’re perhaps working on a new challenge every week or so. On StackExchange I was getting my teeth into at least ten security concepts a day, both new and old. It built my level of understanding up in no time.

One thing that I hadn’t appreciated at the time is that it was teaching me how to communicate effectively. Back in my school days I never really engaged with long-form writing – partly because it was boring, and partly because my English teachers were about as engaging as wet mud (hey look, a simile! nobody cares, Owen). Writing answers on StackExchange meant that I had to distill a topic down concisely and quickly in a way that almost anyone can understand. Practice makes perfect, and I was getting a lot of practice.

At the start of 2013 I had grown disenfranchised by development – day-in-day-out bugfixing on an ERP product comprised of five million lines of procedural Delphi takes its toll – and I decided to make the career move to infosec. Twitter was instrumental in this, ultimately landing me a successful interview within a couple of weeks, but I think that my StackExchange profile was a key way that I was able to display my technical knowledge and communications capabilities to employers.

I’ve since met a bunch of folks from Security StackExchange, and had the privilege of speaking at a few of the same conferences as them. In fact I think I still have a Sec.SE t-shirt somewhere.

These days I find myself posting much less than I used to. You know how it is – life gets in the way. But it’s still nice to come back now and again and answer some questions, and to give back to the site and community that helped me learn so much. In fact, while the 100k reputation is a nice milestone, I think my favourite statistic is this one:



Anti-debug with VirtualAlloc’s write watch

A lesser-known feature of the Windows memory manager is that it can maintain write watches on allocations for debugging and profiling purposes. Passing the MEM_WRITE_WATCH flag to VirtualAlloc “causes the system to track pages that are written to in the allocated region”. The GetWriteWatch and ResetWriteWatch APIs can be used to manage the watch counter. This can be (ab)used to catch out debuggers and hooks that modify memory outside the expected pattern.

There are four primary ways to exploit this feature.

The first is a simple buffer manipulation check. Allocate a buffer with write watching enabled, write to it once, get the write count, and see if it’s greater than 1.

The second is an API buffer manipulation check. Allocate a buffer with write watching enabled, pass it as a parameter to an API that expects a buffer, but pass invalid values to other parameters. If an API hook doesn’t check parameters properly, or manipulates parameters, it may write to the buffer. Check the number of writes to the buffer after the call, and if it’s nonzero then there’s a hook in place. Any API will do as long as it writes to some memory. A particularly good trick is to use an API where there’s some kind of count value passed as a reference – in the real API the value will likely not be set, thus producing no memory writes, but in a hook there’s a bigger likelihood that they’ll set some placeholder value regardless.

Third, we can use the buffer to store the result of some check we care about, e.g. IsDebuggerPresent. If the write count is one and the value in the buffer is FALSE then we can assume that there’s no debugger attached and nobody tampered with the result of the call (or skipped the call).

Finally, we can allocate some memory with RWX protection and write watching enabled, copy some anti-debug check there, call ResetWriteWatch to ensure the write counter is zeroed, execute our payload, then check the write count.

Obviously in all cases these checks themselves can be skipped over, but it’s not a well known trick and may be missed by novice reverse engineers.

I’ve contributed these tricks to al-khaser, a tool for testing VMs, debuggers, sandboxes, AV, etc. against many malware-like defences.

Talking about Windows drivers at 44CON 2015’s Community Evening

I’ll be speaking at 44CON this year, at the community evening on Wednesday 9th September. The community evening is free to attend – you just need to register to attend if you don’t have a conference ticket. My talk is currently scheduled at 19:45, and I’m speaking about writing Windows drivers, with the goal of leaving you a bit more informed about how they work, and how to get started.

In addition to my talk, Saumil Shah will be speaking about Stegosploit, and Michael Boman will be running a workshop on anti-analysis techniques used in malware. After the talks, there will be a showing of the 20th anniversary edition of Hackers, which is guaranteed to be fun.

As usual, there will be drinks and good conversation. Hope to see you all there! 🙂

Another year, another Securi-Tay, another talk… and this time we’re sponsoring the bar!

Another year has rolled by (damn, I really don’t update this blog much, do I?) and Securi-Tay IV is coming up. I’ll be speaking about security issues related to serialisation and deserialisation of data in modern programming languages, including PHP and C#.

My colleague FreakyClown will be talking about robbing banks for a living, which promises to be amusing at the very least (which reminds me – ask me about coathangers and server rooms when you see me).

Most importantly though: we (and by that I mean Portcullis) are sponsoring the bar this year! I hope to see you all there for plenty of drunken security rambling.

Pentesting Java EE web applications with LAPSE+

Just a quick tip for anyone doing a code review of a Java EE web application: LAPSE+ is a very useful tool to have in the arsenal, whether you’ve got the original source or just the JAR/WAR file.

In my case, the client provided me with a single .WAR file which contained the application. As it was a large application, I didn’t really fancy digging through everything manually with JD-GUI, although it is an excellent Java decompiler. I decided to take the opportunity to give LAPSE+ a try.

Here’s what  you’ll need:

You can also grab a PDF instruction manual for LAPSE from the same site. However, be aware that I found some of the information in there to be a bit misleading, e.g. needing a specific version of Eclipse. Also, don’t worry if your client provided you a project for a different IDE, such as IntelliJ IDEA – it doesn’t really matter.

First step is to get Eclipse set up. Drop the .jar file from the LAPSE+ archive into the plugins directory of Eclipse. (Re)start Eclipse, then go to Window -> View -> Other… and select the items relating to LAPSE+. A little toolbar should appear on the right with blue spherical buttons. These are your LAPSE+ windows.

Next step is to load your code into a project. This is split up into two parts, but if you’ve already got an Eclipse project for the site’s source code, you can skip the first part. Otherwise, you’ll need to extract the code from your archive and make a project for it. Start by loading the JAR (rename the .WAR to .JAR if needs be) into JD-GUI. It should decompile the archive and let you browse the code. Go to File -> Export all Sources, and save the resulting ZIP file somewhere. This archive now contains all your decompiled source code, split into directories based on the namespace hierarchy.

Now, go back to Eclipse and create an empty Java project, filling the wizard out with whatever values suit you. Once that’s created, go into the project explorer tree and find the src directory, then right click it and select Import. Select your newly exported ZIP file, and Eclipse will populate your project with your reverse-engineered source. Now right-click the project and select Build. In all likelihood, it’ll throw a whole load of errors due to imperfect decompilation – don’t worry, we don’t really care, because LAPSE+ can still function with a broken build.

Once you’ve got your project set up, go to the individual LAPSE+ windows and browse through what they found. You might need to manually refresh them to run through the checking process. In my case, I found about a 10:1 ratio of false positives, which isn’t actually too bad for code scanning. Within an hour or so of digging through the results I’d found a couple of concrete XSS bugs that I’d not spotted yet, plus a whole bunch of potential XSS bugs that I couldn’t immediately find vectors for, and a whole variety of other interesting stuff to dig through. It’s a really nice way to cut down a 400kLoC project into manageable target points.

Steam Code Execution – Privilege Escalation to SYSTEM (Part 2)

In my previous post I talked about a vulnerability in Steam which allows you to bypass UAC. I’m going to be totally transparent here: I fucked up. I wrote the draft post a few days back, then did some more work on the vulnerability. I discovered something much more serious in the process. I posted last night’s blog post at 1am, tired as hell, and in my sleep-deprived state I completely neglected to update it properly, and there are several mistakes and bits of missing information. The draft went out and confused a lot of people. So, for that, I apologise. I’m going to leave it there so people can see it, because it’ll remind me not to do that next time.

Now, onto the real impact of the vulnerability: I can leverage it to gain code execution as SYSTEM. How? Well, it turns out that Steam.exe gives itself one unusual privilege – the privilege to debug other processes. This is called SeDebugPrivilege and one of its features is that it allows the process to bypass access control lists (ACLs) on processes when you call OpenProcess, i.e. the process can open a handle to any process it likes, with any privilege it likes.

Here’s how you can elevate to SYSTEM when you have SeDebugPrivilege:

  1. Open a handle to a process that is running as SYSTEM, with PROCESS_ALL_ACCESS as the access flag.
  2. Use VirtualAllocEx to allocate a block of memory in the remote process, with the executable flag set.
  3. Use WriteProcessMemory to copy a block of shellcode into that memory buffer.
  4. Use CreateRemoteThread to create a new thread in the remote process, whose start address is the base address of the memory allocation.
  5. Bingo! You just got a privesc to SYSTEM.

In this case, once you’ve got code execution inside Steam, you can utilise this trick to escalate yourself to SYSTEM. There’s your privesc vuln.

Installing Dropbox? Prepare to lose ASLR.

Dropbox has become a daily part of my life. I rely on it to synchronise data between my growing set of devices. But how much of an impact does it have on the security of my system? I decided to find out by digging around in exactly what it does to my machine, or more specifically, the processes running on it.

The first thing I want to check out is what modules are loaded into various processes. Tools like Dropbox like to extend the functionality of other programs using shell extensions, which are nothing more than specially designed DLLs loaded into process memory. Let’s see what we’ve got…

Dropbox Files

Interesting! Looks like we’ve got two extension DLLs, one 32-bit and one 64-bit. These are likely used to add extra context menu options when right-clicking on files. Now let’s find out where they get injected. For this, we’ll use good ol’ trusty Process Explorer. By going to Find » Find Handle or DLL, we can search for the DLLs in running processes.

Dropbox DLL Injection

It looks like it’s being loaded into processes that have windows created, which implies it’s probably an AppInit DLL, but it turns out not to be the case – the registry key doesn’t contain that DLL. This implies that there’s something more active going on, and that Dropbox actively selects which processes to inject into. I may be mistaken here, I’m not sure. Either way, though, it’s a little odd that it chose to inject into Notepad++ and other innocuous processes.

(Update: thanks to zeha and 312c on Reddit for pointing out that it’s likely injected via the standard file browser shell, due to the Dropbox icon in the favourites list)

The biggest problem becomes clear when you take a look at the module in a running process. In this case, it’s Firefox:

Dropbox in Firefox

Notice that the Dropbox extension DLL doesn’t have the ASLR flag set. This means that any vulnerability in Firefox becomes a lot easier to exploit, since the Dropbox module provides an unrandomised anchor for a ROP chain. Ignore PowerHookMenu.dll here – I’m aware of that issue and have notified the developer, but it’s infrequently seen on people’s machines so it’s not so bad.

Let’s just quickly verify that the DLL isn’t ASLR enabled at all, by checking the DLL characteristics flags in the file…

ASLR disabled for DLL

Definitely not enabled.

Anyway, the take-away issue here is that Dropbox arbitrarily injects an ASLR-disabled DLL into various 32-bit and 64-bit processes, causing significant degradation in the efficacy of ASLR across the entire system. With no ASLR, an attacker could craft an exploit payload that utilises executable code within the injected DLL to product a ROP chain, leading to code execution. This is significantly problematic in high-risk programs like web browsers and torrent clients.

I notified Dropbox of this back when version was the latest version, but got not response. I’ve since tried again, but had no luck. I’m hoping that going public will give them the kick they need to get it fixed. In the meantime, a good mitigation is to install EMET and set a policy to enforce Mandatory ASLR. All of this was re-tested against Dropbox 2.0.22, with versions of both the 32-bit and 64-bit DLLs. The operating system used was Windows 7 x64 SP1.

Update: Brad “spender” Spengler (of grsec fame) has noted that the latest version of Dropbox has ASLR enabled for the 64-bit DLL, but still doesn’t on 32-bit.

Update 2: Dropbox responds: “Our engineers are aware of this issue and actively working on fixing it. Unfortunately, I can’t give you an exact timeline that a fix will become available. If you have any additional questions or concerns please let me know.”

Update 3: @_sinn3r has done some awesome work on the exploitability of these issues, over at Metasploit. Definitely worth a read.