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!

Electron is a browser based development platform for Desktop applications. It uses NodeJs in order to program the entire thing. As such, being able to execute JavaScript in the context of the application means arbitrary NodeJs code and not just JavaScript.

While looking for XSS and HTML Injection, he found it pretty quickly (just added bold tags). However, with a clean CSP (Content Security Policy) all of the XSS payloads were blocked.

The CSP had a single flaw though: it allowed JS from all S3 buckets via a wildcard subdomain. This meant that JS was trivial to include by adding it to an S3 bucket.

After using another trick (iFrame src doc attribute to execute JS) the payload still did not work. The developers had done some odd changing of require to allow Angular to work in this context. Once figuring this out, a small change to the payload made RCE via a bad message possible.

However, this gets worse! The application had an open redirect vulnerability, even within the custom URI handler. By combining the open redirect (with the custom URI scheme) it was possible to have a single click of a URL lead to RCE.

How this would work was the following:

1. User clicks on link to custom URI
2. User (on the native application) is redirected via the open redirect
3. The newly loaded page uses the XSS to get RCE

Now, RCE has been achieved by clicking on a single link!

As a final note, the debugging was interesting too. Electron has devtools installed on the application, making source code very nice to read. In this case, the devtools had custom shortcuts though.

There are two types of requests, from the browser perspective: simple and preflights. Old school frameworks used to use the difference between these as a mechanism for CSRF protections on state changing actions.

The Play Framework used a blacklist on Content-Type on cross-origin requests in order to determine if the request was allowed or not. However, sending a valid request from the browser that was an invalid HTTP request, resulted in None being returned from the request for the Content-Type!

Although this was a very simple CSRF check, it looked to be solid, but was eventually defeated. To protect against CSRF attacks, add CSRF tokens to requests and make cookies Same-Site when possible.

There is a pretty trivial command injection within an administrative feature of the VPN. It simply passes a command into system.

At this point, you think the game would be over. However, Pulse Secure hooks into the System function to strip certain characters in order to make exploits MUCH more difficult to make.

As demonstrated by Orange Tsi on previous attacks, they used error messages to execute Perl code in the context of the website.

However, it was NOT possible to actual run malicious shell commands from the System call. Instead they outputted the error message to a cache of another Perl file.

Once the cached version of a file was called, the Perl Code was executed, resulting in code execution :)

Simple bug but complex exploitation!

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 :)