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!

HTTPS is becoming more and more standard with IoT devices. So, how do we modify/intercept traffic if we do not control the device itself? This is what the article is about.

This article goes through three tricks for intercepting traffic without having control on the device.

The first one: It Just Works. Simply put, just send the connection through a proxy that is controllable. This works because the library on the IoT device is not performing ANY validation on the certificate. This has worked 30% of the time, according to the article.

The second one: the look-alike attack. Essentially, this is abusing issues with validating the Root CA in a certificate chain. The attack works as the following:

1. Create a self-signed root certificate. Set certificate to be identical to Root CAs besides the self-signed aspect.
2. Insert this as the Root CA for the Proxy
3. Generate a new certificate from the Root CA and us this from the connection.

If the device does not validate the chain of trust properly, then this will work for interception. This works about 20% of the time. Luckily, Bishop Fox has a tool for setting up this attack for you (linked in the article).

The final one: the incorrect name attack. This one is also branded as the Ol' Switheroo. This works by generating a legitimate and valid certificate for something site. Then, simply using the valid certificate, just for the wrong domain.

To make the chances of the last attack better, it could be useful to get something similar to the device that you are attacking. For example, if the site is domain.com having the site domain.com.mydomain.com could bypass the validation. This attack only works about 10% of the time.

UBoot (in the non-secure version) is known to drop into a shell if the boot process does not work.

Normally, the boot process works fine. However, by shorting out the data line at boot time, this can cause the bootloader to become confused and drop into a shell.

What is particularly interesting about the attack in the article is that the chip is a mounted via a BGA (ball grid array). BGA has tiny little pieces of solder underneath it. Honestly, before reading this article, I did not think that this particular glitch attack was viable with BGA mounted chips.

Once we have a shell in UBoot, the job is easy! Secrets are sometimes stored within UBoot variables. Additionally, we can add scripts to run on the host OS from UBoot. By altering these scripts, we now have a shell on the device OS itself (not just UBoot).

Deral Heiland is one of the best IoT Hackers out there. He helps at IoT Village, works at Rapid7 and has done many, many talks/posts throughout the years. In this instance, he gives us a live demo of how he does things.

UBoot is the main boot mechanism used on embedded devices. So, finding vulnerabilities in a device that allow you to boot in this way are fairly significant!

UBoot is a unique compilation for each device it is on. So, features and things are majorly differ depending on the company using it.

He shares a few tricks throughout this presentation. To start with, there may be a button to press in order to interrupt the boot process (such as CTRL+C). Pressing this may work, but differs per compilation.

Another trick he shows (for getting into the UBoot console) is shorting out the data line for the kernel being read from external memory. By doing this, UBoot just drops into a shell because the loading of the OS failed.

Finally, he goes over the UBoot interface itself and how it can be used in order to get data/control the device.

This video goes step-by-step (with a camera on the device) on how to do all of the stuff described above. Super awesome talk with many demos included from a legend in the field.

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.