Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

There are several integer under/overflows that can be triggered while sending mail to Qmail. These were discovered in 2005; but, because they were thought to be unexploitable, they were never fixed.

Qualys decided to go back and exploit this mail client. The main thought process behind their integer overflow was to corrupt a chunk that was close to LibC. Because large allocations are mmapped directly below LibC, ASLR has already been defeated by relative offsets.

They use the overwrite of the large mmaped chunk to munmap to include a portion of libc!. Now, this section of memory is back at the system, not being used. Later on (prior to this section of LibC being used) they mmap another large chunk, which takes the place of the section removed from LibC.

The important section that they removed from LibC was .dynsym, which associates a symbol relative to the random position of the binary. By overwriting symbol locations (that had not been resolved yet) from the PLT/GOT table, they could control the location in which the pointer gets resolved to. The obvious choice here is to set the pointer to system.

I had came across the mmap allocations myself (prior to reading munmap madness) and had come up with some similar techniques as to the chunk overlapping. However, I never did get the munmap to do anything interesting with other system libraries. So, this was really interesting to see in action!

This legend has been trying to find widely accessible vulnerabilities in the PS2 for years! This time, he decided to target the DVD player of the PS2 and got awesome results.

Why is the DVD player a good target? That's quite a bit of untrusted data being interpreted! Anytime there's a ton of data being interpreted (that we control) it is likely a very good attack surface.

First off, he gets the DVD firmware from memory (from a previous exploit). From there, he reverse engineers the DVD player using Ghidra .

After reversing it, he tries to find a call to a particular function where the size is dynamic but the buffer is static size is static. There is a particular function that meets this criteria: getDiscData. The authors of the code assumed that the largest possible buffer was from the specification.

This overflow ends up being a very large section of memory! Now, we need to find some juicy to corrupt. However, there are no easy pointers to corrupt. Instead, the author of the exploit altering an index value to alter the jump location of a switch table later on.

By corrupting the jump table entry, it is possible jump part way into a switch statements code. This misaligns the stack because several pop's and push's won't be executed. By perfectly misaligning this, we can jump into a section of memory that we control!

This memory that we control was a cache however. Why is this a big deal? Cache comes and goes quite a bit. So, getting stable code here was difficult. But, in the end, it just required writing extra data to make it stay longer.

Interestingly, this is not the end... in pwn articles from CTF's you get code execution and are done. However, with PS2 hacks, the goal is to load homebrew. Loading homebrew required writing an ELF to memory then running this. Honestly, reading this part of the article is unique and interesting; I recommend just reading it yourself, as I cannot cover the beautiful details of this.

One final note: when the exploit was originally not working, the author changed the language of the console in order for different values to show up within the overflow path. When writing exploits, view all possible configurations that you control, as only one of these may be exploitation.

The first half of the article explains how to trigger the bug. At first glace, this appears to be a very simple heap overflow. However, triggering the code in the HTTP routing to actually hit this was very complex (with many conditions having to be met).

The overflow relied on the value of the Content-Length header coming out of a proxy. This proxy actually recalculates the length of the request incorrectly. This, paired, with an unsafe memcpy, creates a heap overflow, in the HTTP routing of file upload requests.

Exploiting the bug was also fairly interesting! First, they write out the considerations for the exploit. Being able to understand the landscape of the attack surface is crucial for exploit dev.

• Heap overflow can write arbitrary length data with arbitrary characters (including NULL bytes)
• ASLR is not in use
• uClibc is used, which is a minimal version of C
• malloc calls: 0x60 and 0x1000 from calls to fopen. These are freed afterwards in the same order as allocation

The classic attack here, to gain easy primitives, is to use the fastbin dup attack. The fastbin dup overwrites an fd pointer while in the fastbin. This overwrite allows us to control an arbitrary address to be returned from malloc, creating an easy write-what-where primitive.

There is a final interesting issue to this though: fastbins are only used with small allocations; allocations that are larger than 0x1000 trigger a call to malloc_consolidate, which puts all fastbin chunks into the unsorted_bin.

In order to still have the ability to use the fastbin dup technique, the author overwrites the value of max_fast within malloc_state by creating a chunk of size 0x8. Now, when the check for the max_fast is done to check for consolidation, the consolidation will no longer be triggered!

To actually complete the exploit, a author chooses the GOT table entry of free for the fastbin dup attack. With control over the free function pointer, the address of system is replaced. When a call for free is made, if the beginning of the chunk is set to a string (/bin/sh) then the code is executed.

Naturally, when viewing the exploit code, there is a significant amount of heap grooming that is taking place in order for everything to line up exactly as we wanted. The important allocations and aspects are described above.

Envoy is a proxy used at Google. Envoy is typically very secure, as it is written in C++, has fuzzing architecture put in place, has 97% test coverage and has Address Sanitization in place.

This vulnerability was first discovered via their fuzzing setup with ClusterFuzz. This appears to be a pretty straight forward buffer overflow on the heap. The bug itself was in the proxying of HTTP/2 to a HTTP/1 backend.

Envoy uses tcmalloc for the purposes of heap allocation. While heap grooming, they discovered a way to use the overflow to overwrite vtable pointers (perfect!). However, HTTP/2 only allows for print ASCII characters, removing the possibility of pointer rewriting.

Because of the issue explained above, they had a new plan for the proxy: edit the ending location of the request after validation. With proper heap grooming, this could be used for a proxy bypass.

At the end of the article, they mention some mitigations for these types of bugs in general:

• Using Scudo for a heap allocation because it has additional heap overflow protections
• Remove all uses of memcpy in the code base

Overall, it was a wonderful article that helped me move away from the 5 option C program in pwn challenges.

Cross-Site Request Forgery (CSRF) is a vulnerability that allows for a legitimate request to be made from another website (attacker) to the actual website, causing a state changing action.

CSRF is typically mitigated with very long and random values called CSRF Tokens , making CSRF impossible because this value is known to the attacker.

However, so many things can go wrong with these tokens. Here's a list from the article to check for:

• Remove Anti-CSRF Token
• Spoof Anti-CSRF Token by Changing a few bits
• Using Same Anti-CSRF Token (from other account)
• Weak Cryptography to generate Anti-CSRF Token
• Stealing Token with other attacks such as XSS.
• Converting POST Request to GET Request to bypass the CSRF Token Check.

This this article, the attacker just changes the request from a POST to a GET. The endpoint simply works still! Now, the CSRF check has been bypassed entirely!

Now, for the account takeover... to change a password, you must know your current password. However, simple removing this field from the request allows still works. Pair the CSRF and this bug and you have a CSRF account takeover.

Everyone knows what copy and paste is...there is a risk to it though! Browsers can directly modify your copy queue without you knowing. What kind of attack surface does this create?

Well, if you can copy and paste HTML into a form, does this allow for this code to be executed? Yes and no. Most browsers have built in protection for this type of thing. Additionally, there are text editors that take in styled content too. This is where the research went.

With 9 bugs (4 in browser and 5 in rich text editors), the same story comes up over and over again: mutations. When attempting to fix some payloads (to make them not malicious) the mutations themselves actually created issues!

These were all about understanding how the processing and mutations were done. Once this was understood, the author just played around until they had a working payload.

Additionally, complex engines (such as interpreting HTML and CSS) have lots of lesser known features. Because of this, the more common features are better tested and likely to be fine. Going after some of the more obscure features can be fruitless when attacking, as it is not as well tested.

Some of the bugs are from simply not understanding all the features in a browser. In 2 of the rich text editors, it was as simple as ending a comment with --!> instead of --> to end a comment.

Overall, this is an attack vector that is not really thought about for attacking. Even though it requires very specific actions to do, (visit website A then website B to paste something) this is a very promising item to look at in website exploitation.

GLibC Heap Exploitation is crazy and has lots of interesting techniques. Recently, I was interested in mmap requests within malloc. After doing some preliminary research and finding interesting things, I found that somebody had already done it!

Mmap allocations are used in the following circumstances:

• Allocation that is served via mmap by ptmalloc
• Library Load via dlopen
• Non-library Mmap Call
• Thread starts

Now, why is this useful? In the ptmalloc case, when a chunk is freed, there are very few sanity checks in place for this to work. So, we could corrupt the heap metadata of an mmapped chunk and use it to munmap an already mmapped chunk!

There are a few ways this could be abused:

• .text section (not usable as mmap allocation is not executable)
• Top of the brk heap
• .got/.data/.bss of a library
• Chunks mmaped by ptmalloc
• Thread Stacks

The bottom 4 are all feasible attacks but would require immense precision to setup. To me, the most interesting is the chunks mmapped by ptmalloc. This is because we can likely create a use after free condition (with restrictions) on this.

The final observation that is made is about the the main thread’s stack. If a page fault happens within the main thread stack, the kernel automatically remmaps it a page full of zeros! Although this seems interesting, this would break many things, such as stack canaries, and cause null pointer dereferences.

Most chips have a debug mode for testing. When the device with this chip is put into a production, the debug mode is turned off. It is turned off by a mechanism called Access Port Protection by Nordic.

APPROTECT guarantees that no readouts on the port can happen unless the RAM and Flash are completely erased.

The author then gets a development kit in order to test out the APPROTECT feature himself. From testing, he discovered that a Power On Reset resets the entire chip, including the Debug port.

Because the Boot process is entirely in hardware (no BootROM), this value had to be set in some way!

How does this get pwned? The answer is always going to be voltage glitching! After analyzing the voltage of particular areas of the SoC, he noticed a particular pattern that looked to be the Debug Port value being set.

From there, he glitches at this exact moment that the value was being set. After the glitch, the debug port is now turned on. This allows for easy connections via GDB with full debugging capabilities (also known as game over).

I found the article interesting because the author discusses the chip itself, the entire process for exploitation and the glitching setup. A really good article if you are looking to get into hardware hacking research.

This is just a HUGE collection of exploits on iOS. Within each exploit is the following:

• A description of the vulnerability
• A strategy overview for the exploitation of the vulnerability
• Mitigations because of the vulnerability or further notes on the exploit
• Links and references to blog posts about the bug, POC and more.

The main goal was to do a survey of iOS kernel exploits. Having all of these in one place will be useful to have as an iOS exploit developer.

The beginning of the article discusses Windows Internals (which is even the blog name) about the printer service.

The bug is actually pretty simple... but first, some background! A printer has a specified port that which is where the file being printed gets published to. But, did you know that the printer port can also be a file!? Yes, it can.

Another piece of background is needed: because printer jobs can error part way through the printing job, there is a level of persistence that it has to have.

Now, back the bugs... In the case of a crash (of the printer service) the privileges can jumped back into as System. Now, we can write anywhere as system (that the service allows). This is where the second bypass occurs.

We could just specify the port to be an important Windows file and gain access (like some DLL). Well, this was thought of: there is a check to see if the user has permissions over this file. But, in actuality, the check was ONLY client side! So, by evoking the same functionality via Powershell.

It's now possible to go from a regular user to System via using the printing service in a particular way!

Items to note:

1. Client-side checks even happen in Native services.
2. Undefined situations in the source code can lead to security vulnerabilities. Think outside of the box of how a service can be used :)