Disclosing stack data (stack frames, GS cookies etc.) from the default heap on Windows

In the previous blog post, I discussed a modest technique to “fix” the default process heap in order to prevent various Windows API functions from crashing, by replacing the corresponding field in PEB (Process Environment Block) with a freshly created heap. This of course assumes that the attacker has already achieved arbitrary code execution, or is at least able to use ROP and knows the base addresses of some vital system DLLs. It is likely the last exploitation technique one would use before gaining full control over the vulnerable application or system, and was indeed used by Gynvael and me while wrapping up the exploitation of the easier challenge during this year’s DEF CON CTF qualifiers which took place in May.

However, before we could even reach that stage, I had to overcome a few other significant obstacles, the hardest of which was converting the available primitives into a hijacked control flow. Following hours of trying to reproduce the same heap layout on the organizers’ and my own platform (exploiting the bugs was in fact the easiest part), I finally managed to achieve close to arbitrary memory read and write capabilities. By that point, I knew the location of the heap, the challenge image base and NTDLL.DLL image base, where I could freely read from and write to. On the other hand, the task itself did not make it easy to get controlled EIP even with such powerful primitives, as it didn’t store plain-text function pointers, virtual objects or any data directly controlling the execution flow on either the heap or in static memory. This meant that a generic technique had to be used instead.

Read moreDisclosing stack data (stack frames, GS cookies etc.) from the default heap on Windows

Windows user-mode exploitation trick – refreshing the main process heap

During the weekend of May 21-23 (directly after the CONFidence CTF that we organized with Dragon Sector), qualifications to the famous DEF CON CTF 2016 took place. We obviously participated in what is probably the most binary heavy, challenging and competitive CTF of the year, eventually ending up 9th on the final scoreboard, which was sufficient to get us qualified to the main event. :-)

While the competition featured a great number of tasks to solve, including multiple pwnables in the CGC (Cyber Grand Challenge) formula, I must admit that I spent nearly the entire CTF working on a single challenge: a vulnerable Windows x86 executable called easier, authored by Thing2. After two full days of hacking by myself, and developing a ROP chain together with Gynvael for the last few hours, we managed to get the flag just in time – roughly 25 minutes before the end of the CTF. Overall, the problem was the second with fewest successful solves (completed by a total of 5 teams – PPP, DEFKOR, 9447, Samurai and Dragon Sector), and considering that it was available since the start of the contest (contrary to secrfrevenge), it was probably the most difficult challenge of all.

The source code of the task is available on LegitBS’ github: here. If you are interested in reading a complete (but quite different than ours) solution of the 9447 team, check out the following article: Def Con Quals 2016 – Easier [Pwnable].

Read moreWindows user-mode exploitation trick – refreshing the main process heap