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!

The main target was Instagram. But, instead of targeting Instagram itself, they went after an Open Source library called Mozjpeg or Mozilla JPEG encoder.

Checkpoint setup an awesome fuzzing lab, just using the standard AFL (American Fuzzy Loop) to do the job. From one day of fuzzing on 30 CPUs, they found 400 'unique' bugs.

The first CVE, is a pretty simple integer overflow in the dimension parsing. When finding the amount of dynamic memory to allocate, the following is called malloc(width*height*output_component), where output_component is just a bunch of values depending on the type of image encoding. Both the width, weight and output_component are alterable by the use.

Because both width and height are 32 bit integers, the call writes only 32 bits into a register for the size! This means that we can cause an integer overflow and allocate very little data, while still being able to write a substantial amount of data! Wow, what a great bug :)

The data, from the image, is then copied in line by line (width*output_component with height as the maximum index). However, how do we exploit this? This LARGE copy is known as a WildCopy bug and can be hard to exploit, as there is an immense amount of data being written.

There are three questions mentioned for exploiting WildCopy Bugs:

• Can we control (even partially) the content of the data we are corrupting with?
• Can we control the length of the data we are corrupting with?
• Can we control the size of the allocated chunk we overflow?

In this case, the data was straight from the image (controllable), the height is used as an iterator for width * output_component and we control the size COMPLETELY.

How do we exploit this though? There are a few ways to go about this large editing:

• Race condition on heap allocations to other threads
• A STOP condition, prior to hitting unmapped memory
• Overwrite function pointer that is used on each iteration of the loop

In this situation, this was using one thread and they couldn't find a stopping condition. But, they did find a function pointer (on the heap) being called on each iteration: jpeg_read_scanlines.

The function jpeg_read_scanlines calls process_data_simple_main, which then ALSO has two function calls to virtual function pointers within it. The cinfo struct ALSO holds many, many function pointers. From one of these pointers, we can override a function pointer to get code execution.

After this, are some details on how memory is managed in both jemalloc and Mozjpeg. All in all, fancy heap grooming is done in order to put our cinfo struct directly after our integer overflowed pointer.

In the end, they mention ACTUALLY putting this into use. Different file format have slightly different quirks and things... Dealing with the customization from Instagram was a hurdle they were not able to climb. Although, this appears to be exploitable, with some more effort.

Some takeaways/thoughts:

• Wild Copy integer overflows are exploitable, you just need some very special circumstances to line up in order to make it possible.
• Good explanation of the heap grooming; definitely a good thing to read on your own.
• Simple bugs live in the most important things. Just find a target and attack :) Don't be shy!

Server Side Request Forgery (SSRF) is where an attacker can force a request made on the internal network. The most exploitable case is when you can get the data to be returned, including stealing AWS metadata, mapping the network or anything else.

Blind SSRF is when you cannot actually see the data, but the request is being made. Additionally, there are some other limitations, such as the request type being made (PUT, for instance won't work as well), the content type being returned and so on. This attack is a complete compromise via a single HTTPS call.

In the past, protocols such as gopher have been exploited. Additionally, platform specific parsing bugs are sometimes used (SNI injection) to smuggle arbitrary bytes (Orange Tsai).

Abusing TLS renegotiation or key reuse, we can coerce newline based protocols (running locally) to do whatever we want. The TLS data, such as session keys and things, can be used to smuggle data in later. The session caching looks for the hostname, scheme and port (generally), not the IP address.

The second time this request is made, the DNS server (we control) changes the DNS IP address! This attack is known as DNS rebinding. Because the DNS server has changed its IP address AND the TLS session has been saved, we can interact with local services by setting this to something like localhost.

Several fields, of the TLS connection, allow us to smuggle calls to other services, such as memcache, hazelcast, SMTP, FTP, Syslog and some other services. Some others, such as Redis and SQL, were not to be exploitable. The craziest part, is that this attack is also possible from the browser with IMG tags!

When can this technique be used? First, you need a SSRF vulnerability. Secondly, the client needs to cache TLS sessions (Java, Google Chrome, WebKit, Curl, iOS, Android and Axios all cache these connections, while Python Requests and Firefox do not). Thirdly, a target must be known and attackable on the local network. Fourth, output TLS connections must be allowed (essentially, firewall does not block them).

There is more work to be done! Different attacks, such as NAT pinning, internal HTTP servers and DoS's, which all were not discussed here.

Interapp communication is extremely powerful but dangerous. If XPC calls are not handled properly, then major security issues can occur.

The XPC daemon needs to verify a multitude of things in order to confirm that the correct client is sending the data.

To start with, the requests made to the XPC daemon are cryptographically signed. However, there are GOOD and BAD ways to do this check, with many of them being bypassable.

Secondly, verifying a request, based upon the PID, is NOT secure. The PID space is really small; by forking the same process a crazy amount of times, it may be possible to switch the process in the queue.

The final (XPC bypass) is injecting code into processes that are NOT expected to be there. This can be done by loading libraries with the DYLD_INSERT_LIBRARIES.

Ian Beer also has an article on XPC exploitation which discusses the improper checking of types on XPC messages. Like JavaScript exploitation, there are quite a bit of type confusion bugs.

Web caches sit between the user and the application server, where they save and serve copies of certain responses. This is used in order to make load times faster for users.

Caching the right material is complex to do properly because you cannot simply cache byte for byte. This is caused by the fact that little items, such as the User Agent, do no matter for caching but change the request. This is why particular cache keys are put in place in order to know WHAT to cache if something changes.

The basis of this attack is to find a value that is unkeyed; therefore, this will be cached and sent to other users. This is known as a cache poisoning attack. Luckily, for finding these unkeyed inputs, a Burp Suite tool was made called Param Miner.

Now, this sounds great, from an attackers perspective, but how can this actually be leveraged? Luckily for us, Portswigger only posts articles with real world implications!

Most of examples used the X-Forwarded-Host as an injection point. In particular, setting this header could be used for cache poisoned XSS, DoS, or redirects. The first example essentially created an XSS by injecting data into the metadata tag. In another situation, the X-Forwarded-Host header was being set into loaded JSON (that was put into the page), eventually allowing for a DOM based XSS.

An additional example, of the X-Forwarded-Host protocol, was the ability to do an arbitrary redirect on Facebook links via OpenGraph. By setting the X-Forwarded-Host header (on the cache) it was possible to poison links to go back to an arbitrary address.

After abusing the one header, he wanted to see what other headers were used to change the way an application behaves that were not keyed. So, he downloaded all headers from the top 20,000 PHP websites on Github to get a list. From this, the author obtained many non-standard headers that caused strange effects.

First, he found the X-Original-URL and X-Rewrite-URL, which allowed for MANY PHP sites to change the location of the page being outputted! On Unity, this allowed for cache poisoning to send users to arbitrary pages.

On Pinterest (Drupal bug), an unkeyed parameter (in the URL) was changing the location for which a user was sent to in the X-Rewrite-URL header. Then, with an arbitrary redirect vulnerability in Drupal, it was possible to poison all redirects! By poisoning all redirects, this allowed for the compromising of a JS file, that was loaded via redirect!

As a heads up (in a follow up article), the X-Forwared-Host was actually made useless when attempting to perform this attack on Cloudflare.

SSRF (server side request forgery) can be used in order to make a request on the clients internal network. This link is an awesome cheatsheet with MANY bypasses for SSRF protections and how to go about attacking with SSRF. Below, are a few interesting things that I personally picked out.

There are MANY different ways to represent IP addresses besides the normal 4 sets that we normally see (127.0.0.1). For example, IPv6 (0:0:0:0:0:0:0:1), decimal (2130706433), octal (17700000001), binary (1111111000000000000000000000001), no ending zeros are required... so many ways to encode IPs!

Besides just HTTP, it can be used for protocol smuggling within the internal network. For instance, Gopher, LDAP, Nginx and other services have internal connections running internally that can lead to RCE, if you are not careful.

When does this vulnerability occur? Processing URLs in any capacity, is where you tend to see. In particular, format processing (Word Docs, XML, etc.), URL request with library parsing, direct socket access and etc.

Using redirections (setup your domain, then redirect to internal domain), can be extremely useful because this happens after verification steps!

What damage can actually be caused?

• Data exfiltration (non-blind)
• Calling internal, non-authenticated web services to change the state of something
• RCE via protocol smuggling
• On AWS, use call to steal role keys

Still a lot more, but these were my personal interesting takeaways from this.

NAT (Network Address Translation) is essentially trying to make the internet feel larger, while we are running out of IPv4 spaces. Instead of giving all devices on the internet an IP address, we use NAT to use a single IP address that acts for the rest of the local network.

One great feature of routers essentially act as a Firewall, not allowing incoming connections to devices on the internal network (unless port forwarding or something else is setup).

Additionally, when a website attempts to make a connection (FTP, for example) the website says connect to me on 'X' port to connect to. However, with the protections of the router discussed above, this became impossible to do. So, the router notices that a particular port, on a particular computer is being asked for, the router allows this. This is called the application level gateway (alg).

10 years ago, Samy (yes, the MySpace worm guy) introduced a bypass for this protection by simply navigating to a malicious website, which opened a specific port on the router into the LAN. This is the 2.0 version.

This bypass worked by making a request directly to something on the internal network. But, web browsers are smart! They limited the usage of specific port, except that Samy found an integer overflow that allowed this port check to be bypassed. With this bypass at hand, it was possible to open an arbitrary TCP port on the router! For more information on this, view his original research at samy.pl. For more fun, look into what LiveConnect is!

Armed with the previous research (bugs were fixed), Samy wanted to see if he could find another bypass. He made a spreadsheet of Chrome restricted ports (to connect to) and a list of services (that were had connection port callbacks) to find a target. The most interesting one was SIP, or Sound over IP.

In order to launch this attack, the internal IP address must be known. The method for discovering this was an implicit timing attack. If a computer does not exist on the LAN, then it takes a significant amount of time to return and no data is sent back. Then, if there IS a computer with the IP with NO service running, then the connection is immediately refused. Using this timing attack, the LAN can be easily enumerated for local IPs.

To top this off, to find the computer that the current user is using, we can use another timing attack! Which computer on the LAN will respond the fastest? The one currently in the browser! Now, we know the local IP of the current user.

Now (back to the NAT pinning) we need to do some type of packet injection in order to trick the router to using an ALG when it should not.

Samy discovered that UDP stun can control the USERNAME of the packet at the very front of the request with unlimited length! With IP packet fragmentation (splitting of packets based upon the IP stack), we can do arbitrary UDP packet injection on the second packet. Whooo!

This time, he used simple form data and set the Maximum Segment Size to control the location of the boundary. As with the UDP attack, the splitting of packets (via fragmentation) allowed for the ability to control the header of any request! Because he controlled the starting portion of any header, he could trick the ALG to open arbitrary ports via a fake SIP call.

What can happen with the ability to access arbitrary ports? Well, instead of the services (on your computer) being local to yourself and the LAN, the malicious actor could now connect to the services!

A couple of wise words from Samy:

• Reads RFC when attempting to learn about a protocol
• Looks at Chrome flags, upcoming features and protocols that are supported by Chrome.
• When attempting to break the parsing, Samy bolded all inputs that he controlled to see how he could attack.

Fun fact: the last question asked in this video was me (totally forgot until I rewatched this video).

EDIT: Samy posted an article AND a proof of concept online for this about a year after the talk.

Active Directory (AD) is a service that authenticates and authorizes all users and computers in a Windows domain type network.

The NetLogin Protocol (from the good ol' WindowsNT days) uses an RPC interface with a custom crypto scheme in order to authenticate a user to the system. To authenticate to the domain controller, the following is done to check to see if they both know the shared secret:

1. Client Challege
2. Server Challenge - at this point, the session key is known to the client.
3. Client Credential Encryption
4. Server Credential Encryption
5. Signed + Sealed with the session key

The author mentions that one tiny blunder (with cryptography) can lead to the entire system being compromised... and that is exactly what happened here.

In particular, the DC uses AES with CFB8 block cipher mode. The main vulnerability lies into a bad implementation of a block cipher mode with AES. The block cipher mode has a fixed IV of all zero bytes!

Using a choosen plaintext attack, the following was discovered: for 1 in 256 keys, applying AES- CFB8 encryption to an all-zero plaintext will result in all-zero ciphertext. Why is this bad though? There are multiple ways to exploit this.

First, recall step 3 from the authentication process. The security relies on the fact that the encrypting of the secret will be secure because of a unknown session key to malicious actors. However, because WE control the challenge (step 1) we can set the challenge to all 0's. From the previous vulnerability (discussed), we can then FORCE the ciphertext to ALSO be all 0's (1 out of 256 tries, or about 3 seconds).

Secondly, recall that step 5 from the auth process is Signed + Sealed. This is simply encrypting all traffic with the session key. With the vunlerability, we DON'T know the session key, but are authentication. Luckily, by setting a flag (on the client request) to NOT use the encryption, we can communicate with the DC still.

The next step is that all non-encrypted calls must contain a value called ClientStoredCredential + Timestamp. However, from the previous challenge used, we know this is 0.

Fourthly, we can change the password of any user on the domain. Most of the time, the password hash needs to be encrypted with the session key in order to use the NetrServerPasswordSet2 RPC call. However, it is possible to set a BLANK password by specifying a zero length password on the request!

Finally, it is time to become the domain admin. Because the domain controller's password is BLANK, we can authenticate as the domain admin and scrape all user hashes (from the network) including the krbtgt to create golden tickets. Game over!

This is a devastating finding for Microsoft AD, allowing for an unauthenticated user to become the domain admin on the network is terrifying. We will be hearing about this vulnerability for a while!

The Linux BSD Kernel has a classic time of check vs. time of use(TOCTOU) vulnerability. The size of a buffer (in userland) is checked prior to heap allocation in the kernel space. However, this size can be alter from the point of allocation AND the check.

The TOCTOU bug, described above, creating a linear heap based buffer overflow in the kernel.

Although the race condition has been found, we need to know when race has been won. But how? Hopefully, something deterministic instead of guessing.

The copyin syscall is used for transferring userland memory into kernel memory. To prevent a kernel panic when a bad userland pointer is passed in, the function can gracefully handle memory errors.

Because we can control the amount of memory being copied, we can force an unmapped section of memory to be just after these bytes (that we are sending to the kernel). If the copyin access fails, we know that the race condition occurred because the page no belongs to the kernel space. (not sure about this explanation but am trying...)

The kernel buffer that is overflowed is a mbuf. Mbufs, when freed, call upon a field called ext_free. Having access to a function pointer to overwrite is very useful to the purposes of exploitation.

Actually freeing the mbufs takes quite a bit of freeing and playing around though! Just keep doing actions that free mbufs and hope it is the right one.

With the ability to jump anywhere, what is next? It is not as simple as a ROP chain, as the data we control is very limited. This actually took some creativity to come to!

First, the current register context is saved in order to restore the kernel execution later.

Secondly, set the userland page tables to be executable. From the context of the kernel, the userland is NOT executable.

Thirdly, turn off Supervisor Mode Execution Protection (SMEP) and other kernel protections. This protection disallows userland to access certain pages.

Finally, jump back to the userland shellcode in order to escalate the privileges. What does the shellcode do? The shellcode patches the threads UID to be 0. Now, a call to setuid will make us root!

The BootROM is the only part of the iOS system that is not patchable. So, finding a vulnerability in the BootROM means that it will last forever on the phones that it exists on.

When Malloc runs out of memory, NULL or 0x0 is sent back to the user. In order to prevent bad accesses on 0x0, a check is made, similar to the following:

if (pointer == NULL) {
	// handle error
} else {
	// pointer is valid, continue
}

The vulnerability comes from an issue with the Malloc implementation. Older versions of Malloc improperly return 0x8 instead of 0x0 when the heap allocator has ran out of memory. Hence, because 0x8 is returned, it is viewed as a valid pointer!

Where does 0x8 point to? On ARM processors the exception vector table starts at 0x0. This is used for handling bad actions, such as OOB reads and such. By overwriting entries in the table, we can control the flow of execution upon particular error messages!

To fill up the heap, a large plethora of images are sent to the system. Once they are freed, the pointer (at 0x8) will cause an invalid memory exception and execute the code from the exception table. Now, it is game on!

Super simple bug that caused the complete downfall of the system. I wonder how many more simple bugs like this are out in the wild, just waiting to be found :)

Black magic timing attack against reused Diffie Hellman (DH) keys in TLS. NOTE: This affects all implementations, as this is a vulnerability against the specification itself.

The math in the article is beyond my knowledge. So, read the article to understand it yourself. But, I will try to provide an overview of the attack (with NO math) below.

The essence of the attack is that DH keys do have all leading zeros stripped. Although, figuring out if the start of a key with 'X' number of 0's does not sound very useful, it is a start.

From there, a well-positioned attacker could view a ClientKeyExchange message which contains g^a. With this, an attacker can construct values LIKE g^a.

Why is this useful? This can now be created to setup equations for the Hidden Number Problem (HNP).

What's the impact? People reusing DH(E) keys (about 3% of the internet) are vulnerable to this attack. However, it requires an attacker to be in a VERY well-positioned location for this to work.

Additionally, the bug with stripping zero bytes in the key affects different libraries in different ways. For whatever reason, a F5 product is vulnerable to this while NOT requiring timing measurements.

Overall, cryptography is VERY hard to do right! Even if everything algorithmically seems secure, a side channel can come back and steal your trash (Raccoon).