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!

During an interview, the author of the post once got the question: "What is the most common security vulnerability?" To Lenin's surprise, it was system misconfiguration.

With people flocking from Twitter to Mastodon, the author of the post decided to take a look at the security of the infosec Mastodon. While on it, they were curious how the user content was stored. The content appeared to be an AWS S3 XML response. On top of this, it was from minio (Multi-Cloud Object Storage).

The hacker made some observations:

• User content is uploaded to minio buckets.
• If this is coming directly from a browser request then there must be anonymous read access on the resources.

Using the minio client, which is similar to S3, they were able to list the contents of the Mastodon S3 bucket. Additionally, there were other folders in this bucket that were NOT meant to be public.

If we can read, can we write? The author attempted to upload something and it worked! They made a tiny modification to the Infosec Mastodon logo just to prove a point. What's the security issue? The S3 bucket policy allows for s3:*. They noticed this problem on other Mastodon servers as well.

Overall, a great commentary on the most common security vulnerability of them all - misconfigurations.

AWS Appsync is a GraphQL endpoint as a service. There are several different underlying data storage, such Lambda, DynamoDB, RDS and many others. There is also a custom option for this, which allows for the creating of developer written resolvers.

To authorize the actions that AppSync will perform, a role ARN is passed in. The role has two components: a trust policy for who can assume the role and the IAM permissions this provides. In this case, the trusted entity for assuming is AppSync and the permissions are S3.

Here's a good question: what stops a user from passing in an IAM role from a different account? The service has permission to assume the role, since they are allowed in the policy, but not for this user. This is known as the Confused Deputy Problem - "where a less-privileged entity (the attacker) convinces a more-privileged entity or service (AppSync) to perform some action on its behalf."

AWS safeguards against these types of attacks quite well - with validation usually being done on the account the role is owned by. This wasn't an exception to the rule! There is validation being done. However, changing the casing of the parameter in the URL skips validation and gets the role to be used anyway.

For instance, passing in httpConfig as the parameter with a cross account role wouldn't work. However, HTTPCONFIG would bypass the validation! This allows for the role being assumed into another account.

In terms of exploitation, an attacker could pass in the bad role and write there own resolver API to query the information that the role has access to. From S3 buckets to DynamoDB, the custom resolver would have some serious impact here. To remediate the problem slightly, an attacker needs to know the role ARN, the role ARN must have allowlisted AppSync and all of the resources in the account will have to be guessed by the attacker.

Case sensitivity problems are not new! The difference between two interpreters - verification and use, caused a major problem here. Overall, pretty neat bug!

Back in the day, there was a device called the TV Guardian. The idea was that captions and spoken word with foul language could be removed from a stream in real time using this device. How does this actually work? Ben Eater takes apart the device to find out!

They reverse engineer the board to get a good idea of what each chip does. From there, the author removes an EEPROM chip from the board by removing a large amount of the solder then using a hot air gun to pull off the chip. Dead bug debugging time!

They find the documentation for this specific chip and begin trying to understand how it works. While reading the docs, the author is unsure what addressing mode it is using. However, by looking at the traces on the PCB where the chip was at, pins 5-7 are all connected! This tells us that the 8-bit memory organization is set and the the program enable pin is disabled.

The author puts the chip onto a breadboard and hooks up the pins. First, they connect GND and power to the proper locations. After that, they connect the Memory Organization Pin and Program Enable Pin to ground, just as it was on the actual board. Finally, they hook up the reminder SPI interface pins to GPIO pins on an Arduino.

Ben writes up an implementation of the protocol in an Arduino sketch, but this could also be done via a standard EEPROM reader too. This is done by reading the documentation and putting the GPIO pins high and low at specific times to emulate the SPI interface. For a read command, the opcode 10 is sent, followed by an 11 bit address. Following this, the chip will send back 8 bits of data.

Simply writing to the GPIO lines with the protocol implemented will simulate the SPI interface. In order to make this work, we have to make sure the Serial timing is correct. Luckily for us, since we are now the controller, we control the clock rate and how fast data is sent out.

After running this and using a hexdump, a bunch of words appear! In particular, most of them are obscene words that children shouldn't be hearing. After the bad words was a list of good words, likely used for the replacements.

However, the format was a little weird. Each word was followed by a small value (0, 1 or 2) then a larger byte. The author throws all of the data into a spreadsheet then analyzes what the bytes actually mean. Excel has some pretty powerful functions for quickly testing stuff!

In the list of words, some of the phrases are explicitly allowed. The author noticed that all words with a 1 in the 6th most significant bit were allowed. Secondly, there are exactly 32 replacement words - which can be represented in 5 bits. The final 5 bits of the strange byte are an index for the replacement words. For instance, ass goes to tail.

The most significant bit is always set. The 2nd most significant bit determines if the word is ONLY restricted in strict mode or not, such as religious things or butt. There are still some things that Ben doesn't understand about the format though.

Overall, awesome post showing off the capabilities of an Arduino, dumping memory and pattern matching. Thanks for all of the work Ben!

Recently, the author of this post received an Arcade cabinet as a gift. Different cabinets have emulators for different older consoles, such as NES, Atari and many others.

The physical device had already been torn down, allowing other ROMs being played. The author was curious what the actual ROM looked for the games looked like. So, they started reviewing the board for the different components.

On the board, next to the chip with the emulator on it, is a Winbond 25Q16VNIQ SPI FLASH chip. This is a super standard chip with a standard SPI FLASH interface, off the shelf tools can be used to communicate with this chip.

First, they hooked up an Arduino. They wrote a super simple SPI implementation to send read commands via the GPIO pins. However, this took a ton of time and had many faults in it.

The second go was using the swiss army knife tool Bus Pirate. There is an open source tool called FlashROM that can be used to extract EEPROM memory. The SPI flash interface is universal as well.

The author hooked up a SOIC clip onto the SPI flash chip. Then, they mapped the pins from the clip onto the bus pirate for SPI. From there, simply using the flashroom interface with the bus pirate configuration dumps the memory!

At the very end, they open up the blob in a hex editor to view the dump of the Rampage NES rom. They compare it to the actual Rampage NES rom. The ROM is included twice on the chip for a backup method. Overall, good post from a solid hardware hacker.

The PHP info page is used for displaying information about the current installation. Normally, this is considered a low information disclosure finding.

A mitigation for Cross Site Scripting (XSS) is using the HTTPOnly flag on cookies. This prevents the cookie from being used in JavaScript directly. Since session information is commonly stored in cookies, this prevents the stealing of the cookie.

The PHP Info page outputs a ton of information about the environment. The weird one to me is that the HTTP_COOKIE field can contain HTTPOnly only cookies!

Now, an XSS bug can make a request to the PHP info page in order to get the cookies reflected in the request. This allows for the stealing of HTTPOnly cookies, which is a huge deal in the context of web exploitation. In particular, the PHP session cookie PHPSESSID can be stolen.

Overall, a context dependent HTTPOnly bypass within PHP by chaining a normal low severity issue.

Here's the problem statement: "Retrieve an article from Wikipedia without revealing which article was fetched." Although this seems impossible, the article demonstrates how to do this using homomorphic encryption.

I don't understand all of the math and things here. Storing in my notes to read about later if a solution for a client is required.

The Renesas R7F701381 is a microcontroller for safety critical applications. It contains a second core with a lockstep core (runs instructions in parallel) to check the first core. Additionally, the instruction cache and RAM has ECC as well. Even though the chip has read out protection, the author wants to bypass this on the chip.

Renesas chip supports a two wire protocol that can be hooked up with a 5V USB-TTL cable. In order to enable debug mode, a pin needs to be pulled high. However, there was an external watchdog to prevent this was happening. The watchdog would pull the reset line low in order to reset the chip whenever the debug mode was entered. So, the author of the post added a 100 ohm resistor to the 5V line to overpower the watchdog.

While in the debug mode, the author tried to connect via the flash programmer for the chip put got an error message from the flasher. Instead of moving on, they decided to analyze the protocol and see if it was the tool deciding it was done or if a custom implementation of the protocol could bypass the protections. The hooked up a logic analyzer and read through documentation of other chips to see what was going on.

The documentation of a different chip gave the author a good insight: the command waiting phase is the only location where the device checks if the programmer is allowed. If this stage could be skipped then we would be allowed to use the programmer. Since there was no direct vulnerability in the implementation, the author turned to fault injection.

Fault injection is the act of causing the CPU to behave strangely by forcing it outside the normal ranges of operation. For instance, changing the operating voltage, clock frequency or adding in electromagnetic signals. The authors choice was to perform a voltage glitch on the power circuit of the device to modify the course of the program. In particular, they decided to glitch the portion where the synchronize command was being received and checking if debugging was enabled.

The datasheet shows a block diagram of the power supply circuit. Inside of the CPU core, there an internal 1.25 voltage regular. To stabilize this, an external pin is attached to a capacitor (VCL). This pin is where the author decided to put the glitch at, since the stability would be affected.

Since the RH850 is used for safety critical operations there is a second core being used. As a result, there is a VCL pin for each core! So, the idea was to remove the capacitors for each of these pins to prevent the smoothing out and glitch these cores at the same moment! By doing this, the cores won't go out of sync.

The author hooked up an N-FET switch for each of the cores, along with a Raspberry Pi Pico to actually perform the glitching. The Pi would drop the voltage for very small time intervals on the GPIO, which was super controllable. Additionally, the author had reimplemented the protocol with a Python script. Upon each glitch, they would check to see if the debug protocol was returning successfully. After a day of finding the proper parameters, they had a successful debug mode! Each attempt after this only takes 5 to 30 minutes, since we know the parameters now.

With this memory can be read out to dump the entire firmware! This was a complete bypass of the functionality in place. Afterwards, they attempted the glitch on ONLY one of the pins. For whatever reason, only glitching the main core works as well, which doesn't make sense to the author. Overall, great post on fault injection which really gets into the interesting details of it.

Transparency, Consent and Control (TCC) is a feature for privacy protection in Apple products. A user has to explicitly allow access to particular folder and files via authentication in order to prevent arbitrary applications from accessing sensitive data.

The directory ~/Library/Application Support/MobileSync/Backup is protected by TCC since backups contain photos, contacts and other things. However, using the built in utility AppleMobileBackup to make a backup at a custom location completely bypass the TCC check. The service has Full Disk Access rights, apparently, which allows it to write/read to this location without consideration.

The bypass was initially fixed by removing the --root flag from the utility in order to prevent the custom mounting of a directory for the backup. This came with some problems though.

The stupid bypass is copying the binary from Monterey and rerunning it. Since it still has the flag and is likely signed, it works fine. Second, the utility DeviceLink has the capability of setting the root directory, allowing for the choosing of the mount point still. The author didn't verify these were fixed properly though.

The author completely forgot their SIM pin on their phone. Since they were tired, they forgot the PIN 3 times and had to use the PUK code to unlock the device in order to get it to work again. They used this, set a new PIN code and all was good. Or was it?

Upon the fresh boot the fingerprint icon was showing instead of a lock screen PIN or a password to decrypt the device. Is this real life? After coming across this anomaly as a hacker, they decided they had to replicate this issue. They played around with variations of what they had done. Turn off the phone, change SIM... until they found something that was consistent.

The attack goes as follows:

1. Force the phone to require a SIM card PIN code.
2. Replace the SIM card in the phone toin order to know the SIM code.
3. Use phone SIM code incorrectly 3 times.
4. Enter in the SIM code.
5. Lock screen is bypassed!

The bug had already been reported to Google but couldn't be reproduced. After showing this to a Google engineer at a bug bounty conference, they decided to reward this engineer with the bounty since the issue was now reproducible. How does a bug come across like this? Surprisingly, this was a very complicated fix.

When a security screen (password entry screen, SIM PIN, etc.) is rendered, it is essentially put onto a stack of devices on top of each other. When a security screen was done, it would call the dismiss() function to get rid of the current screen. But, this was vulnerable to a race condition. Something in the background was changing current screen state to the original, while the dismiss() call would remove the new current screen!

By entering in only the one PIN code for the SIM, it would sometimes bypass the lock screen PIN as well. A pretty crazy bug! In order to fix this, the calls to dismiss() are now targeted at a particular screen and not generic. For instance, you would dismiss the SIM PUK screen instead of the screen in general.

Overall, great write up with a fun story to tell! To me, takeaways are be observant and look into weird things that happen. Second, be persistent, as you may get the bounty if you provide more service than the other hacker.

Mark of the Web (MOTW) is used on Windows to say if something was downloaded from the internet. For executables, zip files and other things, this is an important thing to mitigate many attack vectors. In practice, browsers will add an Alternate Data Stream (ADS) named Zone Identifier.

The author noticed a video on Twitter demonstrating a vulnerability where a downloaded zip file was not getting the MOTW flag. One of these was tricky using other file extensions that use zip under the hood (APK, ISO, etc.) and the other was simply a zip file. Microsoft had let the 90 day deadline pass so the video was posted. The author of this post wondered - can I replicate this?

From the video, the extraction bug ONLY occurs when explorer.exe is doing the handling. Additionally, from the video, the zip file itself has the MOTW but the extracted files do not. By looking at hooks and functions being executed, the author found the function ExtractFromZipToFile() within the DLL zipfldr.dll.

To find out what function was responsible for the MOTW functionality, they reverse engineered things and NOPed out a few function calls. From doing this, they noticed that if the function CheckUnZippedFile was skipped then the MOTW flag wouldn't be added to the files. So, how do we skip this function or bypass the flag adding?

The author attempts to trigger errors via weird characters, long file names and other things in order to bypass the flag adding to the files. Since none of these worked, the author found a live sample of this bypass and reverse engineered the sample.

Reverse engineering the sample led them down a rabbit hole of different functions. Eventually, when they found Alice, they came out of it with an interesting note: the files that were not getting flagged were marked as Read Only. Since the flag is technically writing to the file, the flag writing would occur with an access denied error.

The bug turned out to be very simple but required a good understanding of zip and Windows Internals. Overall, a good writeup with some good Windows reverse engineering tips.