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!

Most exploits that we talk about assume that an attacker does not have complete control of the computer. But, what if they did? This article, which heavily references the new Rootkits and Bootkits book, provides an insight into what can happen when an attacker goes after the boot process. In particular, it talks about rootkits (kernel modules injected for persistence) and bootkits (modifying the boot process itself).

BIOS (Basic Input Output System) prepares the system for higher level operating systems to be used. Prior to getting to this step, quite a bit has to happen though! The steps for the BIOS are listed below:

1. ROM BIOS Initialization - The initial boot process.
2. Use MBR (Master Boot Record) to find all of the hard drive partitions and boot code. Once the drive has been choose, the 0x1BE sized boot code loads the next step.
3. VBR (Volume Boot Record) finds an active partition within the drive to use. This steps loads the Initial Program Loader (IPL).
4. The IPL parses the file system and starts to get things ready. The IPL is quite small and is used to load the bootmgr.
5. The bootmgr reads the configuration data of the kernel and starts to the the kernel.
6. Kernel modules are loaded.
7. Finally, the first user mode process.

The boot process has some protections. In particular, Windows Vista implemented kernel module signing. Additionally, the ELAM (Early Launch Anti-Malware) allows for anti-virus to hook into the early boot process. However, because an attacker could hook into the boot process itself, these could be circumvented easily. Because of this lack of security on the beginning of the boot, something new was created!

The Universal Extensible Firmware Interface (UEFI) was the overhaul that the BIOS needed in order to get to a Secure Boot. The order in which things happen is a little different and centralized. Instead of steps 2-5 being in separate stages, they are all in one single UEFI boot stage.

1. UEFI boot initialization. Loads the platform modules and gets UEFI ready to go.
2. UEFI boot manager. This initializes buses, loads device drivers and loads the boot application.
3. Kernel modules are loaded.
4. Finally, the first user mode process.

Step 2 has quite a bit going on inside it though. This stage has 4 main steps outlined by the UEFI specification.

• SEC - Security boot: finds the loader for PEI and runs from SPI Flash.
• PEI - Pre-EFI Initialization: configures memory, does basic hardware things, runs in tmp memory then transitions to permanent memory.
• DXE - Driver Execution Environment: Initializes System Management Mode (also called ring -2) and DXE service executables. It also provides boot and runtime services.
• BDS - Boot Drive Selection: discovers the HW device from which the OS will be loaded using the GPT.

Instead of using the MBA and VBA, has the GPT (GUID partition table). This table is used to reference the drive and partition to use in order to boot the system. Additionally, configuration settings for UEFI are stored on the motherboard and are called NVRAM (nonvolatile random access memory) variables. The amount of things that can go wrong has shrunk significantly; sometimes, centralized security is a good thing.

This changed the game: it is no longer simple to modify the bootloader process, as everything is validated from the ground up. But, some mistakes can still be made. In poorly configured environments, it may be possible to modify the UEFI ROM, modify any of the mutable drivers, add secondary bootloader, insert signed kernel code... there are still quite a bit of things that can go wrong. A lot of the security relies on the SPI write protection on the BIOS working and the cryptography for verification being secure.

The Secure Boot process of UEFI proved to not be enough though. Because the verification steps were happening late in step 2 (DXE), previous sections could be compromised. As implementations got stronger, the root of trust got moved to lower and lower stages, even to hardware at times.

From here, there are some platform specific boot processes that have been added. For instance, ARM has TrustZone, Intel has Boot Guard. However, these are left for an exercise for the reader (and myself) to do a different day.

In order to test for these types of misconfigurations, there is an amazing tool that will automate a large amount of this stuff for you: chipsec. So, strap this in and see what you find!

Power Apps are part of the wider Microsoft Power Bi Platform. Power has a feature that allows to launch small applications as a tab in any team they are part of. These applications help automate Office 365 workflow and do many other things.

These tabs work by loading an iFrame on the domain specified by the applications. This iFrame is loaded via a parameter from a different URL. The author wondered if they could load an arbitrary URL into here, which initially failed. After a while, they discovered when it would load: uses Teams JS SDK and the URL must start with https://make.powerapps.com.

In order to add our malicious URL, we simply made a PUT request to update the application. The parsing did not consider this URL being a subdomain, as it was not parsing this as a URL. It was only validating that the beginning of the string matched! So, https://make.powerapps.com.fakecorp.ca/ was a valid domain, controlled by an attacker! If this domain is loaded in an iFrame, what's the big deal though?

The loaded application communicates via a postMessage to the powerapps.com URL. Then, this endpoint communicates to the top window of teams.microsoft.com. Considering the postMessage interface is quite expansive and was built with the idea that only trusted code was being ran, this creates an issue. It turned out, that an Access Token was being sent (without any other auth) to the iFrame, giving access to a bunch of information!

Although some people would stop at getting the Access Token, the author of this article wanted to see how much damage they could do. This exploitation involved setting up an automation flow that would steal teams messages then sending this to an attacker controlled email. Besides stealing this information, it could be used to alter the account in some other ways as well.

The boundaries of trust were not well-defined in this case. An extremely simple bug allowed for an entry point. Once the attacker was in the house, no one questioned their access attempts. I would be curious to see if Microsoft added defense-in-depth measures for this attacks in the future.

An additional consideration is that the complicated (and awesome) functionality really hurt Microsoft here. Although the automate functionality works well, an attacker was able to register something that stole all Teams message then removes everything they just did. This is an amazing avenue for an attacker, as they may never get caught.

88mph is a fixed rate lending protocol on the Blockchain. Security vulnerabilities on the blockchain are extremely serious, as they can result in millions of dollars in lost funds.

Smart contracts can have constructors that are used to initialize the contract. This is a special function that is only called at the initialization of the contract. What if somebody used a regular function for the initialization step? If this was not locked down, it would be a major issue.

The vulnerability is that the smart contract does not use a constructor to initialize and does not lock down the other initialization functions. Because of this, the owner of a contract could be changed via the initialization contract. Once somebody was the owner, they gained access to privileged functionality, such as the ability to burn or mint coins.

Once this was discovered, the team had to fix the protocol. They set up a warm room in order to handle this. They bricked the current contract, burned all of the coin then reminted it, giving it back to the original users. It should be noted they sent the money to Taichi in order to avoid frontrunning attacks.

SIP (Session Initiation protocol) is commonly used for real time communication, such as instant messaging and voice communication. The product under test is VOIP monitor, which is a listening software for VOIP messages.

Where ever there is user input being handled or controlled, XSS may be possible! On the main VOIP listener message, there is an XSS bug in the User-Agent header. By sending VOIP messages with an XSS payload in the User-Agent header, the administrative account can be forced to perform arbitrary actions.

The author takes this from XSS to control over the application. Using custom SQL queries (which for some reason is allowed from the admin-side), another administrative user can be created on the application, a keylogger can be added... With XSS on the admin page, it is essentially game over.

Where ever there is user input being displayed, XSS may be possible! Sanitizing all inputs is crucial from preventing this types of bugs.

Polkit is a system service installed by default on most Linux distributions. It's used when determining if a user has access to something, requires a password or something else. Besides graphical sections, pkexec can be used as an alternate to sudo.

The dbus-send command can also be used to trigger polkit. This tool can manually be used to simulate D-Bus messages that the graphical interface would use to send.

The architecture uses a daemon to communicate with the privilege side of things. This daemon takes requests from the Authentication Agent and dbus-send, which properly forward them to accounts-daemon and polkit. The dbus-daemon enables all four processes to communicate securely, making it a key part to the puzzle.

When creating a new user, the flow is shown below:

1. dbus-send sends a request to the account-daemon. This is funneled through the dbus-daemon first. This includes a special bus id from the sender.
2. The accounts daemon asks polkit if the connection id is authorized for the create user action.
3. polkit asks dbus-daemon for the UID of the connection. The daemon sends back a list of admins who can perform the action or a 0 if the user is root.
4. The agent asks for a username/password to see if the action is allowed. This is sent from the authentication agent to polkit.
5. If polkit approves this, the action is performed.

With the flow above, there is a bug when killing the debus-send process. In step 3 (from above), polkit asks the debus-daemon about a particular UID. But, if the process is deleted, then UID does not exist. Although this should return an error message, this gets handled in the worst way possible!

In step 3, if the UID is 0 (signalling root), then no other checks for authentication are performed. When the UID does not exist, 0 is also returned! This means that the killed process is the same as root!

Besides racing the kill the process before the lookup, there are also multiple checks on the UID. So, the proper code path needs to be hit, which takes a few tries when racing it.

The vulnerable code path sets an error flag and returns a TRUE/FALSE value. The bug is that TRUE is returned instead of FALSE, but sets the error flag. The developers fixed the code by returning FALSE instead of TRUE.

In order to a Linux distro to be vulnerable, the error flag needs to be ignored. This was the case in Ubuntu, Debian and Red Hat Linux.

The bug was not some crazy memory corruption bug. Instead, it was a logic bug that had existed within the code for 7 years. This is a fascinating example that security bugs will not never go away, even when memory corruption bugs are long gone.

Oculus is a headset used for virtual reality that is owned by Facebook. Single Sign On (SSO) is a way for a single sign on application to allow for the authentication on other locations besides the primary provider. An example of this is Sign In With Facebook.

When going through the SSO flow, the login site has to redirect back to the main site. For instance, when using Sign In With Facebook to login into Instagram. The callback URL, or place to be redirected to, must be done securely. Otherwise, the authorization token could be stolen.

When using the Oculus SSO and redirecting back to the site, the redirect_uri is not properly restricted. Although the domain exact path must be matched, it is a fuzzy match.

By using a directory traversal, (../) an attacker can move up the directory until they find something suitable for an arbitrary redirect. When the arbitrary redirect on the main site occurs, the token will be redirected to the attackers site.

The interesting thing about this bug bounty report is that there was no actual exploitable site that was using Oculus SSO. However, it was an issue with Oculus itself! Because of this, the POC has a filler for the arbitrary redirect functionality that was labeled, instead of an actual vulnerability.

The Furbo is a dog camera. It connects to the phone via BLUE and connects over the local WiFi network as well. The device uses RTSP on port 554 to stream video and audio.

By fuzzing the RTSP service, a crash was caused by sending a corrupted packet. In particular, the username was quite long. So, we've got a crash on an IoT device: it is time to open it up!

The Ambarella SoC was the primary target: as a highly-capable ARM Cortex-A9 SoC running Linux (compared to the fairly limited PIC16 and wireless chips), it performs all the important functions of the Furbo. With the datasheet easily accessible online, they found UART test points on the board, which were easy to connect to.

The terminal is protected by login credentials. However, the Das U-Boot can be interrupted! By changing the boot-time parameters, a shell can be popped on the device. At this point, a user can be added to /etc/passwd to get persistent access to the device.

On the device was a single script that turned everything on. By manually running the script and causing the crash, lots of nice information about the process was printed out. At this point, they added statically compiled versions of ssh and gdb to make debugging significantly easier.

GDB showed that the segfault occurred because the address of the stack address was set to 0x41414141 or a bunch of A's from fuzzing. The system has ASLR enabled, NX enabled on the binary but the binary is not compiled with PIE.

The address of the binary (when not compiled with PIE) had leading nullbytes, which made this exploit not possible. As a quick POC, they disabled ASLR on the system and found a group of 3 gadgets within LibC to get code execution. But, we still need a memory leak!

Instead of looking for a memory leak, they attempted to brute force the space. The address of LibC was always loaded at 0x76CXX000 where XX varied. Additionally, C would sometimes be D. Brute forcing this is a 1/4096 chance or 12 bits of entropy.

If the program would crash, the watchdog script would turn the program right back on. By abusing the lack of randomness flaw, this would take anywhere from 2 minutes to 4 hours.

SharePoint is a web-based collaborative platform that integrates with Microsoft Office. Launched in 2001, SharePoint is primarily sold as a document management and storage system for teams.

The vulnerability occurs because is insufficient input validation. The EditingPageParser uses an allowlist for specific control options while creating a site. The safe controls must be defined in the web.config file in order to be used.

When parsing to see if one of the directives is allowed, it creates a hashmap of all the valid server controls. If the type cannot be resolved, then it simply ignores the verification and does not check it against the allowlist. Under normal circumstances, this optimization makes sense.

Here is where the vulnerability comes into play: there is an inconsistency between the validation and parser. The validation does NOT trim a space at the end while the parser does. Because of this, something like Namespace="System.Web.UI.WebControls " (note the trailing space), will not be resolved in the validation stage but will be found in the execution stage.

By calling an abusable function, arbitrary code can be ran on the server. An example would be to call the System.Web.UI.WebControls.XmlDataSource function. In the POC, several small things had to be done in order to get code execution on the server, but it's not the most important thing to go through because the security is in the allowlist, which has been bypassed.

Validation vs. usage bugs are a fascinating class of vulnerabilities that have plagued the world for a long time. As we move to safer languages (away from C and C++), these types of logic bugs will become more and more common.

Joomla is a popular CMS that is similar to Wordpress. Finding vulnerabilities in a CMS usually ends up being extremely impactful because of the amount of sites that are affected by the issue.

The first vulnerability is a host header injection on the password reset link. When the password reset link is sent out to the user, it uses the host header for the URL to send to. However, because an attacker can control this, they can send the user to their own website, if the link is clicked on, to steal the reset token.

The password reset functionality does not work on the super admin user just for situations like this. So, we need to reset an admin user then find another vulnerability to escalate the privileges.

The second vulnerability was XSS but it is not a standard one. As an administrator, files can be uploaded to the server. The Joomla team has restrictions on what files can be uploaded by allows for .html files. When the file content gets rendered on the admin portal, it creates XSS.

Once the attacker became the Super Admin, RCE could be achieved by uploading a custom plugin. These vulnerabilities are quite simple! It is surprising that these stayed within Joomla for so many years.

The author decided to fuzz the AWS APIs. Because of the large amount of functionality, this was no easy feat! Valid resources had to be used for the APIs as well in.

While fuzzing the inputs, they found an error message in Elastic Beanstalk in the Change History functionality. Simply put, the error message broke the UI of the console because of a NULL error. I personally would have brushed this off as an error in the console and nothing else. But, the story continues on!

When looking at what caused the error in the Chrome dev tools, the author found out that there was a missing field from Cloudtrail. When looking at what this null was, it was trying to append a string/object directly into the DOM.

By adding in HTML tags to the Cloudtrail input that was set to null, there was an HTML injection vulnerability! However, the security of the CSP made it impossible to load in JavaScript directly. +1 for defense in depth! But, the CSP allowed frames to be loaded from anything that starts with S3.

The website was not using Angular; it was using AngularJS, which has a bad history of client-side template injection. The basic payload for this is {{6*6}}, which turns into 36 after it has been executed.

Using AngularJS, JavaScript can be injected via directives(research by Gareth Heyes). Using the directives, we can be used to bypass the CSP! This leads to a devastating to a truly impactful XSS.

To me, a few things should be noted here:

• Defense-in-depth is incredibly important. The CSP nearly made this attack impossible.
• Fuzzing can be used to find unexpected bugs, even in web applicatons. Make sure to fuzz the planet with a good list!
• Cross-service bugs are hard to detect. The penetration test for each of these services individually was unlikely to find this bug.