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 testing the JWT functionality of a private program, they found lots of interesting functionality. One feature of the application is that you can invite users to a group and then change their account’s privileges/scopes.

As an regular user, you can set the permissions used in the scopes of the JWTs. Since there is a fine-grained permission model, this makes complete sense.

After reading a bunch of JavaScript on the page, they noticed that a few scopes were not in the edit user privileges functionality but still in the page! These were company:support and company:operations.

By simply sending the request to add users with these scopes, the new user could be added with the company JWT scope! When looking back to the JavaScript, there were several API calls for employees only. Using these with our new scope resulted in compromise of the application!

This issue existed in the API key creation and the invite users to group functionality. This is an awesome case of a good security concept but a lack of understanding of the use of it.

Side channels are extremely hard to stop. From timing to power differences, doing everything perfectly is incredibly hard to do. Even in modern browsers, there are still some issues lurking around that are exploitable.

The cornerstone of browser security is the Same Origin Policy (SOP). This provides isolation of resources between Web origins. However, the barrier between origins is not as tight as we think. In the land of side-channel attacks, working around the SOP to leak data across origins is known as cross-site leaks (XSLeaks). A cool wiki page with all of these techniques being documented exists as well. These range from cross-site search to counting the amount of frames in a page.

Recently, the paper Leaky Images: Targeted Privacy Attacks in the Web went after de-anonymising users across origins using shared resource functionality. This paper used the fact that a logged in user will be able to see a shared file while others users will be redirected somewhere else. By sharing with a user, an attacker can know that something visiting their site has had this resource shared with them.

The paper looked at cookie based auth viewing for images; they now have to be properly signed.

Since the top-level navigation was happening, this could only deal with a single request. However, we want to de-anonymize from a group with a reasonable time! The author needed to find a way to block the top-level navigation to make this feasible while still getting the information. GET-based HTML-form submission counts as a top-level navigation; as such, it carries cookies marked SameSite=Lax.

Additionally, they learned about the form-action Content-Security Policy (CSP) directive. On Chromium based browsers, the directive is even enforced on redirects. By using this, we can now handle the different options (redirect & top level navigation), where the redirect can be handled by the securitypolicyviolation event, multiple times.

This can be turned into a binary search, assuming that the user is in the workspace. For instance, we can have a unique collection of groups in Slack to check if they have access to a file or not. By adding users to specific groups this can be used as a fingerprinting technique to determine which user is on the page.

XS Leaks are really crazy in practice but SO hard to pull off. This is a great article and I'm excited to see more like this in the future.

Github is the most popular source control management system. Github has many great features and restrictions. One popular feature within Github is Github Actions, which is a CI/CD pipeline within Github. An interesting (and obvious) restriction that can be added is the ability to force reviews prior to a merge taking place.

So, what's the problem here? Github Actions is simply too powerful! When making a PR, push a workflow that approves the PR automatically upon a pull request event. Since the Workflow has write permissions to repo, the review process is completely bypassed.

This attack assumes that a developers account is compromised. The review process is put in place in order to prevent crappy/malicious code from making it into production. This is a perfect example of complexity simply circumventing a security protection.

What is the fix for this? The author does not mention how Github fixed this. I would imagine that the token for the Workflow was verified to see if the review had taken place prior to the merge operation happening. It should also be noted that Github Actions is enabled on all organizations by default, which makes this significantly worse.

During the week, a few people had their crypto wallets completely drained. This mainly happened on free gift schemes. As a result, some people decided to take a look into what was going on.

OpenSea allows anyone to create art and sell them on its market place, the art can be anything that ends with the following extensions: JPG, PNG, GIF, SVG, MP4, WEBM, MP3, WAV, OGG, GLB, GLTF. When you go to the page with the asset, this image is displayed on the website.

SVGs are much more powerful than they should. Hence, many sites do not host them, such as Flickr. SVGs can execute JavaScript, by design. Do you see where I'm going here?

By creating a malicious SVG to be stored on OpenSea, the website would render this for us! Since it used our SVG, this gives us JavaScript execution in the context of their website (XSS).

Since this website is supposed to interact with the Crypto wallet, you would have allowed this to happen on the browser plugin, such as Metamask. With code execution within the context of the page, we could call the MetaMask APIs to transfer funds!

Initially, the ethereum object was not in the page. But, by sending the SVG with an iFrame in the middle of it the ethereum object will be loaded. This now allows for the usage of the plugin APIs.

The user needs to approve the operation. However, since the operation is coming from OpenSea directly, they would likely accept the transfer. The request itself looks benign, a simple wallet signing request.

Users should note that OpenSea does not request wallet approval for viewing or clicking third party links. Such activity is highly suspicious and users should not interact with wallet approvals that are unrelated to OpenSea specific actions such as buying, making an offer, liking an image.

This is a fascinating attack that combined the crypto and web worlds. Good findings from Checkpoint!

The author of this post found integer calculations being mode on 32-bit numbers without overflow checks. As a result, this value could be overflowed to cause memory corruption.

A lot of the time, integer overflows turn into wildcopies that make exploitation difficult. To me, the author has great insight into how to exploit these.

The first part is turning this into a wildcopy in the first place, as opposed to a NULL dereference panic. After playing with the input values to trigger the vulnerability, they found a better code path that triggers the bug. At this point, the loop is MUCH too large and we are writing to non-mapped memory.

There are a few options for exploiting wildcopies:

• Relying on a race condition between threads. If you can alter something in another thread while the corruption is occurring, this may be possible.
• Stop the loop via some logic once we have corrupted what we wanted to.
• Overwrite a function pointer or a function being used by the function itself to cause memory corruption.

In this case, the author found some logic that could be used to stop the wildcopy. This was done via memory compare checks that could be triggered. At the end, they have a really good POC that was likely exploitable. Awesome!

Linux terminal devices, such as serial consoles, are represented via the struct tty_struct. This structure contains fields used for job control features of terminals.

The field pgrp points to the foreground process group of the terminal. The session field points to the session associated with the terminal. Both of these fields do not point to the process/task directly though, a pid represents the numeric value of the process.

The vulnerability is an issue with the locking in the tiocspgrp IOCTL. The member on the terminal side would get locked. However, this lock was taken on the tty. As a result, by making a call on both side of the pseudoterminal, a race can be made on the should be locked object.

Regardless, one of the objects (struct pid) is decremented by 1 too many. Anytime you can cause issues with the reference counting, you got a nice looking use after free!

To exploit this, they needed to get the object into a part of the heap that had interesting information in it. The object that was freed only had two other objects in it, which were not usable. By going some heap feng shui (mentioned in the article), it is possible to flush the page that the object is on to be used by a different kernel allocator.

With the UAF object back into a more controllable heap, we can allocate it over anything that we want! The author chose to overwrite a pagetable. This is useful because we can manually give ourselves access to the .text section of a setuid binary.

The best part of the UAF is using the get_pid function to increment the refcount of the object itself. Using this, we can add arbitrary amounts to the address. On the page tables, this can be used to add flags that should not be set. It should be noted this bypassed ASLR entirely because of the increment primitive.

The rest of the article talks about mitigations for protecting against these vulnerabilities. The first one is simply attack surface reduction. Simply, if an attacker cannot hit the code, it cannot be exploited.

The second recommendation is to implement compile-time locking validation. Clang has some thread safety checks that can be done but they do not seem to work for C very well(only C++). It would be awesome to find locking issues in the future via compilation flags but there is still a lot of work on this front.

The vulnerability is a use after free, which is incredibly powerful. Memory tagging is coming in the future and will make UAFs require a serious memory leak. It should be noted that CFI and ASLR did nothing to stop this single bug exploit.

There are a few other mitigations mentioned in the post. Smaller portions are important data being readonly, structure layout randomization and lack of heap memory reuse.

Thread safety is incredibly hard to do! Overall, good post about exploiting a locking bug and the future of memory corruption.

Matthew Alt (WrongBaud) started off soldering chips & reprogramming them at a car race track. He teaches a hardware hacking course that really focuses on reverse engineering. The introduction is long but eventually goes into a presentation for reverse engineering a street fighter two cabinet. NOTE: There is a workshop for this online now.

At the beginning, Matthew shows a Namco arcade board. Apparently, with the particular chipset, the SD Card slot can be repurposed for a JTAG interface. He has removed the SD Card slot and has attached wires to it. I had no idea this was a thing!

Matthew has a course on HackADay about reverse engineering embedded devices. According to him, breaking down the components piece by piece gives a good picture of it for how to attack it. Additionally, having a narrow goal that is well-defined instead of reverse engineering absolutely everything, which helps for a time frame. They even have a 5-day course where they send ALL of the targets to you to hack (VoidStarSec).

The Street Fighter 2 Championship Edition Arcade Cabinet is the target of this attack. The goal was to turn device into something will be run a custom program, such as Doom. To do this, the author lays out that we need to extract the non-votatile storage and analysis the firmware (operating system and application structure).

The first thing to do is to view ALL internal and external devices. Externally, the SFII cabinet has a USB port for charging and an audio jack. In the teardown, the author is looking for processors, non-volatile storage, debug interfaces, and any naming conventions on the board. The largest and central chip with the most traces going to it is likely the CPU.

While looking at the chip, there are a few headers that are silk-screened GND/TX. These may be debug headers that could be useful later on. Further onto the PCB, they found an SPI flash chip that likely has firmware on the device, since it is the only non-volatile chip on the board.

Remember the USB that was only used for charing? The USB port has a pin for data plus and data negative. As engineer with their thinking cap on, this must mean that it is used for something else! It turns out that this was also used for multi-player mode.

If nothing is named or labeled, using a logic analyzer is the best way to find how things are working. By tapping into the lines, we can learn quite a bit about the system. But, a lack of naming on the chips does make this significantly harder to do.

By connecting to the debug headers with a specific baud rate with UART, a large amount of information is outputted. From these output logs, the memory mapping is shown, the emulator being used is shown and a file path is disclosed. Now, the clues as a detective are starting to add up! However, no UART shell :(

By accessing the SPI chip directly, the firmware can be dumped. The author literally uses a raspberry pie with the flashroom tool. The connection to the SPI chip uses an alligator clip. Using binwalk and strings, they were able to reverse engineer how the device stores the files and how it works.

From looking about the storage of the data (file types mainly) and the chip being used, they found that Sunxi chips have an FEL loader. This is awesome but this is a debug interface that allows us to directly interact with the board. The FEL loader is a low-level subroutine contained in BootROM of all Allwinner devices. The USB connector has the data+ and data- pins, which now makes much more sense!

How do we trigger the FEL loader though? They reverse engineering the boot process and attempted to find a point that it could be interupted at. FEL mode can be triggered by holding certain IO lines on boot. They found out that by holding the volume down button, FEL mode was advertised over the USB interface. I assume they just tried different things to figure out the volume down.

The FEL interface allows for the flash to be rewritten and dumped. At this point, more software reverse engineering needs to be done in order to add our own ROMs to the board. Hurray! There's a whole slidedeck for this with more details at here.

By design, the IEEE Floating Point format has adjacent floats have adjacent integer representations. This seems obvious but is only possible because of the implied 1 in the mantissa and the ordering of the fields. Super cool that the integer representation is fairly similar to the float!

When you increment the mantissa, it increases the value of the float. When the mantissa wraps to zero, this increments the exponent. P

This awesome quirk does have its limitations though. The representation of positive zero is next to the smallest representable positive number, but the representation for negative zero is 2 billion-ish values away. This also means that tiny positive and negative numbers have integer representations which are about two billion apart.

The difference between two floats is at most 1.00000012 times larger than the number, which is a modest and predictable radio. This does not apply to number between FLT_MAX and infinity and FLT_MIN and zero.

Incrementing floats with INF, -INF and NaN causes very strange issues. Be careful with these values.

For what it's worth, on my system the values are around to the closest value in either direction. Unlike with Integers in C, where the value is imply truncated. For instance, 1e10 10000000000 is on one end while 10000001024 is the next number. If the number is 10000000001, then the value is sent backwards to 10000000000. If the value is 10000001023, then it is sent forwards.

The IEEE 754-1985 specifies the floating point format of 32-bit numbers, which is known as the float type in many languages. The format for a floating point number is much more complicated than the integer format because of the sheer volume of numbers it can represent.

A 32-bit float has three fields, in this order:

1. One-bit sign field.
2. Eight-bit exponent field.
3. Twenty-three bit mantissa field. This is where lesser significant bits are stored at.

The author says to play with the format some with the provided code, which was actually really helpful! Here are a few things that I learned:

• The exponent bit starts at 128 for a value of 1. Then, it moves backwards or forwards depending on the decimal point.
• The sign & magnitude scheme is used for this. As a result, all numbers (including 0) can be represented in the positive and negative forms.

The formula for decoding a float is quite simple besides these cases though: (1.0 + mantissa-field / 0x800000) * 2^(exponent-field-127) . From this, we use the sign bit to make this a positive or negative number. When decoding the format, there is an implied leading 1 in front of the mantissa field if the value is between -126 and 127. if the value is -126, then do not add the leading one.

There are a few special cases that are interesting to talk about. First, if the exponent field is 255 & the mantissa is zero, then the value is infinity. And if the exponent field is 255 & the mantissa is non-zero, then this is Not A Number (NaN).

Why the implicit 1 though? We know that the first bit of the binary pattern will be a 1. Otherwise, the exponent would be smaller. This saves a bit and allows for the usage of bigger numbers!

This is a huge chain of posts, that I am real excited to learn all about! Floats have caused issues for developers for many years; I am hyped to finally understand why. More on these articles will be coming!

ION is an allocator used by the Android kernel. It is an extensible memory management framework for DMA buffers. These buffers are represented with file descriptors that can be shared between user and kernel map.

The lowest function call is ion_buffer_kmap_get(), which increments a buffer's reference counter and calls a heap specific memory map function.

The file descriptors have many functions that can be performed on them. The IOCTL DMA_BUF_IOCTL_SYNC can arbitrary increment or decrement the reference counter for the shared buffer. This reference counting issue can lead to a malicious user triggering a use after free.

The exploitation of this bug would heavily depend on the usage of the allocator in the kernel. Interesting find regardless!