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 feature in test is IOSurfaceAcceleratorClient::user_get_histogram. The reason to go after this function was that the AppleM2ScalerCSCDrive IOService is one of the few user clients can be called within the app sandbox.

When being created, the histogramBuffer is allocated but never initialized. Additionally, IOMalloc does not 0 out the previous data. After making a call to this (without directly setting the values), a bunch of garbage was displayed; which is good sign for uninitialized memory leakage.

In order to exploit this, wanted memory (addresses) need to be on the heap. Although this could be leveraged in multiple ways (KASLR bypass or Mach Port finding), all that matters is doing some grooming to put the proper data at this location (to leak).

For a POC, the author leaked a Mach Port by sending OOL port arrays (importantly, the same size as the histogram object) then freed them. Now, use the histogram feature and the leak is there! :)

Bhyve is a hypervisor that can be used on Intel and AMD chips in order to run virtual machines. It is exclusive to BSD.

Even though I am not familiar with how virtualization works, the bug is pretty simple! The AMD (and likely Intel, but not directly mentioned) chips have a number of instructions that act directly on the VM host physical addresses. These instructions should be trapped (intercepted) but are not.

The instructions VMLOAD, VMSAVE and SKINIT are the ones that are not being intercepted. This can allow for a write-what-where primitive on the Host of the VM (with some restrictions).

The author puts a teaser for a super easy way to get code exec, but does not actual put it. But, there is a little more information on twitter.

WhatsApp uses a native library called libpl_droidsonroids_gif.so in order to do previews. This is the main target for the attack.

When doing previews, some reallocation's are done for different buffers. When a frame is of size 0 the rasterBits is freed. What happens if we have 2 frames of size 0? Well, this frees this buffer twice, causing a double free vulnerability!

On the application, the Double Free vulnerability will result in the same buffer being added twice into the heap allocator. This means that two consecutive allocations would result in the same buffer twice! It should be mentioned that each GIF is parsed twice, for whatever reason.

With the double free bug, what actually happens? The GFInfo struct is what contains rasterBits. Because we can control the size of the allocations, we can make GFInfo the same size as rasterBits! With both of the allocation as the same size, BOTH GFInfo AND rasterBits will point to the same spot in memory! Woah!

GFInfo has TWO function pointers that we can overwrite, making it a great target for compromise. From here, gaining code execution is pretty trivial... call system and find a gadget that allows for the first parameter to be set.

One thing that is not covered, is an Info leak. To exploit this, the base address of libc.so and libhwui.so. To me, it is really interesting that this RCE is such a big deal, when there is NO leak with it... this makes the vulnerability unexploitable and targeted, as a custom file must be made for each user you attack, depending on the locations of the above libraries.

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!