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!

While looking at the cookies for the PHP site, the author noticed that one of them was in a standard PHP serialized format. This looks like an interesting start!

PHP serialization is an easy way to turn a string into an actual PHP variable. The main issue with this is that constructors can be called once the PHP variable is started!

So, if arbitrary data can be deserialized (which was in the cookie) it may be possible to create an object (with a constructor/destructor) that does malicious actions.

PHPGGC can be used to find gadgets (for deserialization) within code. One of the gadgets allowed for an arbitrary write of a JSON file to an arbitrary location. By adding this to a public location (with some PHP code), RCE was possible.

There was an issue though: strip_tags() was being ran on the file name, which removes HTML tags and nullbytes. However, the author had an interesting way around this!

Deserialization has multiple formats for strings, luckily. By converting the string to another format, it was possible to use strings again.

Overall, good find and super impressive exploitation!

The web share feature of Safari allowed for local files to be used via the file:// URI.

Although it did require user interaction and a user visiting the site, if the user went with the site then local files could be sent to the malicious user!

When absolute links (including the URI type) are used it is fairly common for other URIs to cause havoc. In the future, look out for this!

Apple made special IPods for the department of energy that allowed for special recording software to run on the IPod.

This is the story, from the perspective of the Apple engineer, who worked with the DOE people who were doing the modifications. This is a super interesting article that is well worth the read!

Secure boot is the baseline for a secure system. If the boot process can be compromised, then it is essentially game over from the beginning.

Symbolic links are a way to link someone to a different location on the file system, without having to change each reference to the spot on the OS. This can be useful compatibility reasons.

Embedded devices commonly have a cryptographically signed section of the Secure Boot process and a partition that stores logs and other data, which is not digitally signed. So, what is the big deal? Why does this matter?

A symbolic link can be used in order to reference files within the secure boot process itself. Because the system applications attempting to access files and directories on the non-volatile storage partition can be redirected to the root file system, the Secure Boot process can be defeated.

Where are potential attacks lying in this? From the non-verified partition, web hosting, log files, boot scripts and several other things are prime targets for this attack. These attacks go from leaking sensitive information to compromising the device upon loading the firmware itself.

From there, the whitepaper goes into several attack scenarios and how to exploit the bug.

How do developers prevent link attacks? Extend cryptographic protections across all partitions. Additionally, using file permissions to prevent the writing of important files is a big aspect of this too.

Typo squatting is the art of sitting down on a bunch of different names that come from 'typos' of something legitimate , hoping that someone will make the mistake.

In this case, it was in the context of Python Packages. With Python, we use the central repository (pypi) in order to download the packages.

The author made a typo squatting package for the 10,000 most downloaded Python projects by removing underscores (_) and dashes (-) from the names of libraries.

After two years of squatting, 530,950 installs were done for improper packages! That's an astounding amount of downloaded just from a single type of typo.

Why is this a bad deal? This type of attack is known as the supply chain attack. By poisoning the packages that a user downloads, it creates a compromised environment from the beginning.

In terms of an actual attack, persistence on the system (via install scripts) or the stealing of sensitive data, such as SSH keys, can occur.

Overall, this is a really effective long term attack for an attacker. Honestly, I remember seeing this banner come up on multiple occasions.

The DEFCON talk starts with a good background on how printers are used, how to communicate with printers and a lot of good knowledge about printer interaction on the computer. In Windows, Printer Spooler Service.

Why attack the Printer Spooler service? It has System level privileges, has networking tasks and loads many third-party libraries. Additionally, it is 25 years old and has not been really touched in years. These are all great reasons to attack the Printer!

The attack that the talks goes with into is asks the following question: can a malicious printer take control of a computer? A CVE published in 2016 essentially allowed for this printer drivers were automatically being added without user consent. The fix simply adds a user consent check, which pops up a screen to click yes or no on.

The mechanism used to download printer drivers is set by the printer itself! This large set of attributes is sent over prior to deciding what to do with the printer on Windows. Can this be abused?

The CVE from 2016 can be bypassed by setting some of the attributes to particular values! The code hits a different path that just circumvents the dialog check entirely.

Once the consent check was removed, they discovered that .cab files are used for the sending over of printer drivers (which is just a Windows archiving format). Upon reverse engineering the cabinet APIs, a directory traversal was discovered via the Copying API. The API checks for '..\' but NOT '../'.

With the directory traversal, the attacker can write to any location with root privileges. This leads to code execution with ease.

Microsoft Edge also has a sandbox for which processes can access it. The printer is one them. So, the printer service could actually alter the sandbox for Edge because of this.

Game Engines are the base software that video games are based upon. If you are not a huge gaming studio, you are likely going to use an off-the-shelf game engine, such as Unity or Unreal Engine 4 (open source).

In the multiplayer gaming world, we are trying to increase the performance and move most information to the client side, in order to prevent hacking, such as speed hacks and things. Most of the multiplayer gaming systems having RPC (remote procedure calls) to call functionality on owned objects and are very distributed.

Most multiplayer protocol run over UDP because of performance issues of TCP.

Bug #1 (Unreal): In Unreal, there is a custom URL scheme that is used for accessing specific resources. However, it can be abused to access any local file on the system (but you cannot see it).

By using a UNC Universal Naming Conventions in the URL, it can be used to access a remote SMB share. This typically tends authentication information and can be used to start other attacks.

Bug #2 (Unet Unity): RPC calls have a length and a payload. The length is blindly trusted, allowing for EXTRA memory to be accessed on the server. In order to exfiltrate the memory (heartbleed style), you can use RPC types such as messages, player locations and object spawning to see the data.

Bug #3 (Universal UE4 Speed Hack): UE4 calculates the speed by checking the current timestamp to the previous timestamp to calculate the location, as well as the direction vector (speed). Additionally, this has several validations to ensure that now speed hacks are occurring.

NaN stands for Not A Number. Any math being done with NaN also will output NaN. NaN with all booleans will always output False. The bug occurs in a validation function of the timestamp that will only exit if something returns true. By setting a value to NaN, all operations will return False, resulting in the check to pass!

However, it is not this simple... there is an affirmative action that MUST be true in order to work. So, we must continue on the bug hunt. This NaN value (timestamp) corrupts several values, eventually removing all speed limit hacks in the game! To exploit this bug, send a small timestamp then an extremely large timestamp.

Bug #4: UNET is over UDP, meaning that lots of built-in security mechanisms have to be manually added. Connections have two important fields: Host ID, Packet ID and Session ID. The Host ID is not meant to secret and is sequential. The Session ID is a 16 bit integer (65535) but is always odd, taking down the amount of possible values to 32768 possible IDs with no punishment of brute forcing.

Now, we can brute force the session ID and act as another user! With this, we can trivially end a users session. The next thing we need to do is figure out a valid Packet ID. The documentation says that a too new or too old packet will be discarded, giving you a 7% chance. However, in practice, all old packets are valid (well, there's a rolling packet count though). So, there is a 50% chance that you would be able to hijack somebody's session.

What can we learn from this?

1. NaN bugs are a security thing!
2. Documentation constantly lies to us; do not trust it, try it out yourself.
3. Small amount of possible ID's + no brute force protections = pwn
4. There are a lot of simple bugs out there; all you have to do is look hard :)

Who doesn't want to get all of the money off of an ATM!? Clearly, this is the hackers dream.

The most impressive part of this talk was the reverse engineering of the ATM and just getting the thing to work!

The first step to reversing is figuring out what is on the device. Originally, they desoldered the chip on the ATM but eventually broke it. However, they found out the firmware was publicly exposed and ready for download. Additionally, the device had an exposed JTAG interface which worked quite well. Moral of the story: try the easy stuff first!

Now that they know how the device works (after reversing the firmware) they wanted to be able to run their own custom code on it. So, they decided to alter the kernel DLL's so that the signature validation just returned true.

However, the ATM still did not work :( . They realized that the payment processor was not hooked up to the ATM. In order to get the ATM to work, they had to reverse engineer the Triton and write their own server to interpret to communicate.

What else can we do? They created a custom OS to put on the ATM and several things running, including their CTF and DOOM (of course).

The first thing an attacker should probably do is see what external services are exposed on it. They noticed a Remote Management Service (RMS).

They decided to fuzz this (via Boo Fuzz) and found a buffer overflow because of a static buffer. How did they know what had happened? They could see crashes occurring over the JTAG interface.

With NO ASLR or NX bit on Windows CE, it was easy to write shellcode to take control of the device over the RMS interface.

From reviewing the register keys, they found what the some of the other open ports actually did. They found an XFS (extensions for financial services) interface. They smelled money and decided to take on this interface!

In order to interface the communication (would be easy with Wireshark but NO Wireshark on Windows CE). So, they had to use JTAG to hook into the socket information in order to sniff the traffic. However, the traffic was not easy to see.

Good thing, it is trivial to replay packets! They eventually reversed the XFS interface and wrote Python scripts to communicate over XFS. You can run any XFS command on the device! :) This means you can dump out all of the money and the ATM!

Overall, amazing research and reverse engineering of the ATM. It was a crazy amount of effort to just get the thing working!

Vulnerability #1 lies within Authd, which is part of an open source framework that handles authorization, authentication and privileged process spawning. While looking through the source code, a funny function group of code was noticed that copies the security entitlements. This code just copies the entitles without doing a signature check!

This means that arbitrary entitlements can be created and sent to Authd to give those permissions away. Although this entitlements should be used all the time, several Apple specific frameworks ignore them and just require a password.

There are a list of privileges that the author found to be usable without the password check from other frameworks. The important one (that actually worked) was system.install.* rights. This only allows for Apple signed packages to be installed at arbitrary locations :( So, we will need another bug.

Several Apple signed packages exist online that are sort of weird! Eventually, after scouring the internet, a package was found that had a command injection as parameter 3 of a bash script, which could allow us to escalate up to a root.

Now, on to the final vulnerability... SIP (System Integrity Protection) is used to ensure that only Apple signed binaries are run and do not alter important parts of the Kernel, such as the OS. The kextutil is what is used to load Kernel extensions.

When kextutil loads a kernel extension it does the following:

1. Copies the kernel extension to a non-modifiable directory, which is SIP protected.
2. Verifies the signature of the extension.
3. Reopens the extension to load and start it.

So what's the issue here?

There are TWO points here where the file is opened: it is opened to verify and opened to run! So, there is a classic time of check-time of use (TOCTOU) bug here! If the file is altered after the signature check, then a non-verified file will be ran! Because we have root permissions from the first two vulnerabilities, we can alter the file prior to it loading :)

But this is not deterministic, is it? We are training to win a race here. Well, there is an awesome trick that the author used to always win the race! The kextutil function has a built-in interactive mode for loading kernel drivers. While loading the driver with the interactive mode, the signature is verified. Now, all you have to do is alter the driver to be whatever we want, load it in the interactive shell and we have kernel code execution! This interactive nature makes it trivial to hit the window for altering the file.

Privilege escalation in OS's does not always have to be memory corruption! Sometimes, it is just poorly written logic in multiple places that allows for this to happen.

Live Overflow interviews the finder of a XSS in Google sheets and some Google Engineers on why this existed. Super interesting to hear this from both sides!

The researcher found this bug several years ago in the Google Visualizer. The JavaScript library is closed source but the researcher reversed the obfuscated JavaScript! This proves, to me, that reversing difficult things provides much fruit.

The bug involved an arbitrary object constructor that was found in JavaScript. It turns out that passing a function to this also executes the function! This has then created an XSS gadget.

This bug was originally fixed but removes the worst gadget (executeFromURL) and forcing an allowlist on the allowed parameters in it. However, this vulnerability discusses a place where this regressed to remove the allowlist.

By specifying a particular type for a chart, it was possible to register a postMessage listener via the arbitrary constructor bug. The postMessage function is used for cross-domain requests between pages.

This postMessage handler took a URL and placed the code into a script tag! This allows for an arbitrary script to be injected into google docs!

Wow.. simply an amazing find. Watch the whole video if you want to hear from the researcher himself and the Google Engineers.