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!

SSO's (single sign on) applications are used in order to give users access to an application while using another providers credentials. Alongside the SSO, certain permissions must be granted (by the user) to have at the third party site.

The issue was that if user deleted the account on the third party site or revoked access, the Gitlab SSO did NOT revoke access to the previous permissions.

Although this is a weird finding, permissions should be given and taken at will. This should be a normal test case going forward.

Brute force protections gone wrong! After 20 failed login attempts, an email attempts to be sent to the user/admin.

After 50 attempts, the password is cleared in order to indicate that the password should be reset. But, by sending a blank password, it will login the user!

This is a ridiculous auth bypass but is super interesting!

An LPE on a Linux machine? Who would have thought that! Linux OS's are typically secure. This privilege escalation ONLY exists within the Desktop version of Ubuntu & not the server version.

The first bug is a denial of service within the accountservice daemon. The user sets the file .pam_environment to be a symlink to /dev/null. This makes the file infinitely long when trying to read it.

When the daemon decides to read this file, it DROPS the privileges down to the same as the user in order to prevent privilege escalation. Because of this privilege drop, there we have the ability to send signals to this process! What signal should we send? How about SIGSTOP? This will pause the running process.

Now, he is the real kicker. You log out of the current user! Once at this screen, we wait until the user dialog box pops up to create a new user. Why does this happen?

When there are no users on the system, GNOME is instructed to create a new user. It knows how many users there are by talking to the accountservice daemon!

The bug is in when the accountservice daemon is unresponsive and a timeout occurs. With this code path, the field that matters if knowing if a account exists for a user is the field priv->have_existing_user_accounts. However, this defaults to false! So, if the timeout occurs when trying to talk to the service daemon, then the functionality acts like there are no users on the system!

In a nutshell, this stops the accountservice daemon by first putting it into an infinite loop to drop the privileges then stopping the service with a signal. Then, by logging out and trying to log back in, the unresponsiveness of this daemon allows for the attacker to restart the user initialization process.

I love this type of finding! When I see bugs like this I wonder "What could I do better in order to find this bug in the future?". The crux of this bug was that an insecure state was used in the initialization of a field that was relying on a time-delimited action to fill it out. In the future, look for bad/insecure initialization of values.

By the way, the author found this bug by accident and it took them some help in order to find the root cause of the issue. As I would say, you miss 100% of the shots you don't take! At least by trying this guy gave himself a chance to get lucky.

CSGOJackpot is a gambling website that allows players to bet & win Counter Strike skins or textures. Why is this a big deal? the average pot per hour is around $20,000 dollars! So, being able to swipe this money would be a big deal.

The game works as follows:

1. Start a new round with an empty pot.
2. A player puts in their skins (up to 10 at a time). These skins are calculated for a cent value and this is the value that the user put into the pot.
3. If less than 50 skins, go back to step 2.
4. The site generates a random number that determines who the winner is.
5. The player with the winning ticket wins the whole pot.

From reading the HTML on the website, the hacker noticed that the backend was likely a nodejs server. Additionally, because the 16 digits of the winner percentage were the same as the nodejs default output & published at the end of the round, it was assumed that this was just using Math.random().

Math.random is being used? So, what is the big deal? This function uses Multiply-with-Carry for the pseudo randomness. Can this be predicted?

Apparently, all you need for breaking the randomness in JavaScript is TWO consecutive outputs!? What, that is unbelievable to me. I then realized that the attacker just BRUTE FORCED the 32-bit space (which only took about 30 seconds) in order to figure out WHAT the next number would be. Not an elegant solution but it does work well!

For more work into breaking JavaScript random, try this and this. .

However, this attack was not perfect... the attacker simply could not predict the next value. So, he assumed some OTHER calls to random must be made (which was the case). However, the pattern was inconsistent for how many calls to random had to be made. So, a deadend :(

But, from the ashes of this, a new attack arrives! The site claims to be provably fair by doing the following calculation: md5(blinding + winning percentage) BEFOREhand & shows this to the user; this is called the commit. So, what's the issue?

The blinding is just two calls to Math.random (converted to hex) and the winning percentage is the value guessed by the user. By using the previous bug (output from random for the winning percentage) in tandem with the commit being shown (THREE RANDOM numbers in a row!) it is possible to KNOW where the randomness currently lies.

The hacker (wisely) did not attempt to exploit this to win money. Instead, they had a Twitch stream where they showed him guessing the percentages LIVE. The bug was also recently fixed.

What is the moral of the story? Use cryptographically secure random number generators! Additionally, be careful with WHICH numbers you show to a user. Showing too many may break the ecosystem.

Fault injection is super crazy! Instead of the standard voltage/clock glitching, they decided to use electromagnetic fault injection. In this video, they go over how they defeated encrypted secure boot via EM fault injection.

Their toolkit in order to perform this attack:

• UART communicator
• Electromagnetic fault injection probe
• XYZ stage to move the probe precisely onto the chip.
• FPGA for knowing WHEN to launch the attack

Besides launching the attack against a particular target, it is important to test to see if the technique has SOME affects on the device. Additionally, is the result predictable in some overall capacity. There's a happy medium where we can make changes, but not TOO many changes.

From running tests on the chip (with defined code that they wrote), they figured out the BEST location to glitch the code at. On the BPGA chip, there was a single point that corrupted a bunch of corruption.

Once the bootloader has been completely copied (can be noticed based upon data being sent from a particular location), this is when the fault injection should be sent out. With the glitch, they ONLY worry about the result, in terms of HOW much time it takes, not the amount of attempts.

The next question is how do we turn data transfer into code execution? They call it instruction corruption by altering HOW instructions just generally work.

TODO...

Why attack kernel drivers? They are the ONLY way to touch Ring 0, or the running kernel. Because of this, vulnerabilities in kernel drivers allow you to elevate to system with no issues. This post is about Windows Kernel Driver internals and how to go about attacking them. For Windows Kernel debugging, use the following post as a reference Getting Kernel Mode Driver Signed For Windows 10.

What does a driver look like? At a high level, a driver is a loadable kernel module that additionally has a user-mode application counterpart to communicate with it. Below are some more technical details on this process.

Device Objects is created by the driver itself for a communication channel. This can be done via the Windows CreateFile API with a symbolic link to a DEVICE_OBJECT.

In order to create the object, the main is called (DriverEntry). It accepts two parameters: DRIVER_OBJECT and RegistryPath. The DRIVER_OBJECT starts as an empty struct (from the kernel) and is initialized via the driver main function. The RegistryPath is a path where parameter keys are stored at for the driver.

The DRIVER_OBJECT structure has a lot of fields. The most important though, are the functions that the driver supports are added to this struct; they are in the MajorFunction member of this struct. In order to interface with the driver, these interfaces are made into DLLs that can be used in userland.

Under the hood, the flow looks like the following:

• User requests a handle in order to interface with the driver.
• The user uses the handle in order to send IRP (I/O Request Packer) to the driver. The important part of this request is the IOCTL code, which is just the ID for the kernel service routine to call.
• The driver executes the routine.
• The result is sent back to the user.

Easy starting points for finding bugs in Windows Kernel Drivers:

• Driver allows low-privileged user to interact with it.
• MmMapIoSpace or ZwMapViewOfSection are in the IAT table.
• Customized memmove or known unsafe function is used.

For reversing, the first thing to do is fine the main function dispatcher & the register path. The bulk of the reversing process relies on finding the IOCTLs.

The author used a REALLY simple fuzzer on all of the IOCTLs. This led to a buffer overflow that overwrote a function pointer! :) However, it is not as simple as calling system in Ring 0; there is still more work to be done!

On Windows 7, the exploitation involved writing some shellcode. However, the author could not find a way to restore execution back to its normal state (crashes in the kernel are VERY bad). Instead of trying to gain kernel code execution, the author decided to copy the SYSTEM token to an arbitrary process. Thenm to keep execution going, used this trick (JMP 0x0) in order to get execution of the kernel thread from crashing.

On Windows 10, there are quite a few kernel mitigations that make this significantly harder, including KMCS, SMEP, KASLR, KPP, CFG and VBS.

Supervisor Mode Execution Prevention (SMEP) can be bypassed by using ROP gadgets in order to change the value in the control register where this lives at. Now, we can trivially jump to our shellcode.

The Kernel Patch Protection (KPP) will bluescreen the computer if it detects the alteration of critical kernel structures being tampered with (including the CR4 register to bypass SMEP). However, this is done on a timed basis. So, a fast enough and well-timed payload can bypass this protection.

KASLR (Kernel address space layout randomization) can be bypassed quite trivially. KASLR is only meant to protect low-integrity processes, like browsers. However, med privileged users can use the EnumDeviceDrivers API to easily get the Kernel Address.

As an extra treat, the author dove into running this exploit on the most recent version of Windows. Because of a software patch for the infamous Meltdown vulnerability, Software based SMEP was added. So, all we have to do is add an additional step, which is to disable Software SMEP.

Typically, computers are 100% deterministic. Given the same inputs, it should always produce the same outputs. But, what if this wasn't the case? What if you COULD alter the flow of execution? This is where our friend comes into the game: fault injection.

Generally, fault injection is about purposely creating faults or issues in how something is running. This is commonly done for load balancer testing, to see how much a system can handle if a few servers go offline. In the context of security, it is just about trying to introduce faults into the running program.

Typically, fault injection is done in two ways: voltage glitching and clock glitching. With voltage glitching, the idea is to give the system an unexpected power amount (a ton or very little) to try to cause a fault. In practice, this can be used in order to skip/alter instructions, change the state of the processor or brick the thing entirely.

This article is all about glitching a SoC chip to bypass the BootROM verification. This article is not just the hand-wavy 'glitching' works kind of thing; this is a very in-depth article into how to launch a voltage glitching attack on an SoC.

First, even if we get a glitch what can we do? This particular eMMC chip has the following process:

• BootROM starts and is the immutable part of the Boot Process.
• The pre-loader is stored on the Boot0 eMMC partition and is mutable code. This code is put into RAM to be executed.
• Prior to executing, the BootROM validates that the signature of the pre-loader is valid.

What does this mean? In practically, we want to inject our OWN code into the pre-loader and glitch the signature check to return true, even though it was not signed properly.

To do the actual glitching, an FPGA was programmed for this exact purpose. The FPGA must be used because of the timings being SO exact. The FPGA is connected to the eMMC clock and data0 lines in order to KNOW when to trigger the glitch.

Here's the actual flow:

• The target board is in the middle of this, of course.
• The FPGA then reads the eMMC clock and DATA0.
• The FPGA outputs a flag to the ChipWhisperer in order to perform the glitch.
• The ChipWhisperer is connected to VCCK_PMU; it will drop the power to gnd for a very short period of time in order to cause the glitch.