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!

Franklin Bookman devices were early eBook readers. Early on, these used ROM cards then a licensing model with memory cards. Eventually they landed on a connectivity kit with a serial/USB transfer cable, a memory card and a CD-ROM with the Bookman Desktop Manager Software. This talk is about cracking the CD-ROM with this on it.

To install the Bookman Desktop Manager (BDM), the user must enter a valid CD key. This key was used to generate a Peripheral Identifier (PID) number that was bound to a consumer around. As a result, a user could buy and download the data from the DRM servers to ensure only a single user could write the content of the eBook to their eBook. This is the process documented in the post.

The main goal was to reverse engineer the BDM application for this logic. The BDM program was installing using InstallShield. Using a tool such as unshield, they were able to see the raw application DLLs. Within the DLLs was the file installbm3.dll, which contained the logic for the PID and CD-key logic. By owning this up in Ghidra, there are two valid shared libraries. Luckily for the author, the error messages are quite verbose, making it easy to identify what function performs each action.

Since we know that CD-keys should always contain a dash between 4 digits and 4 rear digits, the string error message with this indicates that this is where the CD-key information must be processed at. Now, there is a cryptic looking function with many steps to decode all everything. This is done as following from a C string which has the code:

1. Apply a function to each character in the string (excluding the dash).
2. Generate a check digit from the inputted values.
3. Validate that the check digit matches the input keys check digit from the data in step 1.
4. Bitwise OR operations on the

From reading the source code, it appears that there is a checksum check derived from the actual values. The first 7 characters were the actual value while the final (8th) character was the checksum. In order to defeat the DRM, all we have to do is be able to generate checksums are arbitrary values!

While trying to recreate the checksum in JavaScript, they were having some troubles. Then the author noticed something strange: they were using integer overflows as a feature! Since JavaScript did not have the same functionality, this was causing a problem. By adding in this functionality manually into JavaScript via the js-cuint package they were able to replicate the code.

Overall, this was a fun post on beating DRM. Even though this was definitely insecure by today's standards, it probably stood up well at the time. Good article!

The previous article walks through how they got access to the binaries for reverse engineering. This article goes into the actual reverse engineering, vulnerability discovery and exploitation of a printer.

The Printer Job Language (PJL) is used for switching printer information at the job level and sharing information about a job to the host machine. PRET is an open source tool for interacting with PJL but excludes many of the vendor specific options. Since this tends to be an externally facing protocol, attackers love to hit this.

While reversing, they wanted to find a list of PJL functions; they found these in the hydra binary. When auditing the different functions (no symbols but lots of useful strings and error messages), they found an undocumented function called LDLWELCOMESCREEN.

This command allowed for an arbitrary file to be written with arbitrary content, since it suffers from a directory traversal vulnerability. From an exploitability perspective, they had a few problems though. First, the file is only a tmp file, meaning that it gets deleted after its purpose has been served. Secondly, the file cannot already exist.

To get around the first issue, we can write more than 0x400 to the PJL. At 0x400 bytes, the buffer is flushed by writing it to the file. If we keep this stream open after the flush, then the file will not be deleted until after the stream has closed.

The second issue is pretty stumping though: how do we overwrite something for code execution if it cannot already exist? While auditing the file system they noticed a set of crash handlers called ABRT. According to the documentation, ABRT can have custom hooks that are executed in a directory when some event occurs. This happens for ALL files in a directory; this is perfect since we can add a file to get executed!

To add insult to injury, the post-event handler runs with root permissions. At this point, there is a way to get code execution (via the crash handler) but how do we trigger a crash? Since the device has several really old binaries, they found they could trigger a remote crash in Apache via a bug in awk. However, there are likely many other ways to trigger a crash.

For the final payload, they had to use bash commands to disable the firewall, configure SSH to work without authentication and a few other things. After writing the file and triggering the crash, SSH was started, allowing the researchers to authenticate!

During Pwn2Own, the exploit failed due to an SSH error they had not seen during testing. As a result, they used a backup script that used netcat to connect instead. Having a backup plan was a wonderful idea to make this work! Overall, amazing research to turn small bugs into game over!

A group of engineers from NCC Group decided to enter Pwn2Own for a printer. With Pwn2Own, an unauthenicated and remote user must be able to compromise a device or application to become root in its default setting. While starting the hacking on this product, they could not find any. Hence, they bought a very similar model (from the same company) for the time being.

Once they got their hands on the printer , they wanted to reverse engineer the device. Sadly for them, there was a big road block: the device firmware was encrypted online. Time to enter the world of hardware hacking!

First, they identified a serial connector on the device labeled JRIP1 (J is for Jumper). Although they were hoping for an easy shell into UBoot or the Linux OS, it only a log showed up and RX (Receive) appeared to be disabled. This may be been done via e-fuses on the SoC or z zero-ohm resistor; if the resistor approach was taken, it may have been possible to re-enable it. But, they had other means to get the firmware.

Early on, they identified a NAND flash that likely had the firmware of the device. They removed the flash chip using a hot air rework station. Once there, they used a programmer with an adapter for their programmer to read the contents of the flash. Once done, they used the rework station to add the NAND flash once again, demonstrating a successful move. They claimed this only took an hour, which is absolutely wild to me!

With the firmware in hand, it was time to analyze it! First, they remove the OOB data, which is used for error correction codes and flags for the blocks. Once this is removed, they can see the TIM (Trusted Image Module) header in the first hundred bytes of the binary. Within this image are 4 images then the firmware of the chip directly after this in the form of UBI volumes.

By using the ubi_reader tool to extract the 7 images that it detects. The volumes represent partitions used by the device, some of which are file systems. To interact with this file system the author used a NAND flash simulator kernel module, which uses RAM to imitate a physical flash device. After mounting this partition with a few more kernel modules, we are good to go! We can now interact with the file system in a Read Only fashion.

The format of the image after all of the reverse engineering was discovered to be as follows:

• TIMH – Trusted Image Module header, Marvell-specific
• OBMI – first bootloader, written by Marvell
• OSLO – second bootloader (U-Boot)
• TRDX – Linux kernel and device tree
• Base - SquashFs filesystem with binaries.
• Copyright – raw data
• Engine – squashfs filesystem contains some kernel modules for motors, belt, fan, etc.
• InternalStorage – UBI FS image for user data (writable)
• Kernel – compressed Linux kernel
• ManBlock – raw data, empty partititon
• MBR – Master Boot Record, contains information about partitions: Base, Copyright, Engine, InternalStorage and Kernel

Overall, I really appreciated them going through the whole process of taking control of the device. Most of the time, the details of getting access to the binaries and getting a good debugging environment are left out. It was shocking to me how much work it was to load the partition once it was there to the Linux kernel! I'm super happy to see this process documented though.

EarnHub is another blockchain based product. They were attempting to do some asset holding project. The more money and the longer the money was in, the more money you would get back.

The smart contracts used an interface with two main functions. This interface had a function called makeHop to allow the transferring of their shares between different pools. To move the money to a new pool, you specify the address of the contact to use. When this happens, the function receiveHop from the new contract is called.

The function makeHop has an error in its handling. When it calls the approve function for the pool, it allows transfer for the total supply of the pool. When, in reality, it should only be the amount that is accessible from the pool itself. A malicious user can call makeHop to a malicious pool they control to drain all of the funds rather than just the user shares.

The attack goes as allows:

1. The attacker creates two contracts: earner and leecher.
2. On the earner contract they buy EarnHub and stake it.
3. The earner contract hops to the leecher contract.
4. The leecher contract drains all of the funds from the staking contract by calling transferFrom many times.

Although cryptocurrency hacks are interesting, there are incredibly painful and sad to see. On the EarnHub website is the chilling text "EarnHub has been exploited. Most funds have been stolen. The project is canceled. Yikes!

When calling other contracts, you need to be very careful the data that can be accessed and the powers that they contain.

Wordpress is a Content Management Service (CMS) that powers 43% of websites on the internet. Since it is written in PHP and has the ability to add extensions, once you are an admin, it is simply game over. By adding an extension, you have code execution on the box.

To prevent XSS on the admin user turning into code execution, there are hardening guide. In this guide, the admin user is put into a sandbox, not allowing for the adding of extensions. This means that code execution is no longer possible.

Wordpress has a hundreds of options for configuring a site. In the source code for options, they are added via update_option($key, $value) and retrieved via get_option($key). An admin user is able to modify any and all options in this database.

These options can take objects, arrays, integers and all datatypes that can be serialized. To ensure that no deserialization attacks can be performed, there is a check to make sure that if the string is already serialized, then it is double serialized via the maybe_serialize($data) function and deserialized via maybe_unserialize($data).

In a database update script within Wordpress core, there is a situation where the function unserialize is used directly on a value instead of maybe_unserialize. Although this seems like an obvious vulnerability, we still have a problem: the data is double serialized.

The function maybe_unserialize checks for the start of the object to have specific characters. These characters are directly correlated with the types that can be deserialized from the unserialize function. Can we find an issue with this identification function?

It turned out that the serialization type "Object with custom deserialization function" was NOT accounted for. This means that the data could be serialized but NOT be double serialized! To me, this feels like a classic verification vs. usage problem!

To actually exploit this, an attacker needs to insert a PHP serialized string carrying a gadget in the database with the type that will result in the data not being double serialized. Once the payload is in the database, trigger the vulnerable code by changing the database version option. When the upgrade script calls unserialize, it triggers the pop chain to get code execution on the server.

Overall, this is a very deep yet interesting bug! A nice writeup with a clear explanation.

On boot and every 300 seconds, the ConnectivityService binary verifies a few things about connections. When doing this, it tries to reach the REST server ping the local gateway and tries to reach the remote cloud.

While making this request, it uses wget from system in C. The output of the call is put into a text file, this is then checked for a response. This response code is then used for a logging call via another call to system. Damn, system has to be vulnerable, right?

If a malicious HTTP status is returned, then there is a command injection vulnerability. Something like HTTP/1.0 200 `touch /tmp/pwn2own` would result in a command injection on the device. How do we get a malicious response from this though? ARP spoofing!

ARP (Address Resolution Protocol) i messages are sent over the local area network (LAN) to link a MAC address with an IP address. If an attacker sends out bad ARP messages, then they can link the attackers MAC address with an IP address of something on the network. Since the MAC address of the attacker computer is linked with an actual IP, the attacker will receive the network traffic instead.

To control the response, they ARP spoof the device by sending ARP responses to the device for the LAN gateway so that all outgoing traffic from that target device is headed the attackers way. Once this is done, they use scapy to sniff for ICMP and some other DNS traffic to respond accordingly. Finally, the ConnectivityService will contact our malicious HTTP server, where we can send our command injection payload. Neat!

While running the exploit at Pwn2Own Mobile, they made a critical mistake. They had hardcoded an IP address for their local network in their test environment. While they did notice this problem and fix it on the fly, their time ran out since no more DNS requests were being made. Sad :(

Overall, this is an awesome chain! To me, I enjoyed how they turned an obvious command injection with an impossible situation into something that could be controlled via ARP spoofing. A simple solution for this would be to use TLS!

Twitter has a setting to make it impossible to find people by phone number or email. This is a privacy feature meant to prevent mass scrapping or targeted attacks.

While trying to create a new user on the Android client, there is an account duplication check for both emails and phone numbers. If the email or phone number is duplicated, then the id of the user is returned. Since the id is public and can be directly correlated to a handle (@dooflin), this becomes a problem.

An attacker could guess a bunch of emails or phone number to correlate them with user accounts. Not only does this bypass the privacy setting but this is an unauthenticated endpoint which could be used for anonymous scrapping of data. In particular, a database of phone or email to username connections.

This bug was really interesting to me since it bypassed the security feature entirely. This feels like a sidedoor of a building; the information is usable here but no one considered it. Secondly, enumeration bugs are common on these types of endpoints but it is odd that the id of the current user was returned. Overall, great find!

Grafana allows you to query, visualize, alert on and understand your metrics no matter where they are stored. Create, explore, and share beautiful dashboards with your team and foster a data driven culture. Grafana ONLY uses cookie flags for CSRF protection. This article is about abusing this.

In Grafana, cookies have been marked SameSite=lax on the session cookie since version 6.0. This theoretically prevents cross-site request forgery attacks against the website. What does the SameSite=lax actually entail though? The cookie will only be sent in two cases: top-level navigation (GET request) or a same-site request.

The top-level navigation on the application did not have any state changing actions. The same-site request seems like a tall order, but can be abused in some situations. First off, same-site does not mean same-origin. Same origin is defined as a domain being on the public suffix list. This means that all subdomains on a given domain (x.maxwelldulin.com and y.maxwelldulin.com) would both send the cookie. This is a subtle difference but is super important in the land of exploitation.

Since Grafana can have embedded pages inside of the website, an attackers embedded web page could launch CSRF attacks with the authorization cookie attached. Additionally, if another site was on the same domain, then an attacker could perform the CSRF attacks as well since it would be on the same site. Not good!

Within the application, it is also possible to turn off the SameSite cookie flag. Since Safari and Chrome (for 2 minutes) default to None for the setting, this makes the application vulnerable to CSRF attacks.

Grafana does use json though, which triggers a pre-flight request. From my understanding, only 3 MIME types for POST requests do not trigger a pre-flight request. However, there is more than what meets the eye here! According to the fetch standard, the essence of the MIME type specified must contain one of these three values.

This means that multiple entries in the header will NOT trigger the pre-flight request as long as a simple one (such as text/plain) is in the header. Damn, that is super interesting! The standard 'My JSON request is safe' from CSRF' should not be a given then. If the Content-Type validation is weak, then this could lead to a serious CSRF attack!

By launching this attack on the website, it worked! According to the code, the Content-Type must contain JSON instead of being JSON. This slight difference makes the CSRF attack possible since a pre-flight request does not occur and the Content-Type is not properly validated.

Overall, I enjoyed the article with a novel (at least, to me) CSRF protection bypass for pre-flight requests. The Same-Site cookie flag is not a solution for all of the problems; it should be considered defense in depth.

Mobile networks use several different technologies including GSM, CDMA, TDMA, 4G, LTE, 5G and many others. Using special hardware and software, law enforcement can eavesdrop and track people. This is called an IMSI catcher or International Mobile Subscriber Identity catcher.

Currently, IMSI catchers, which are also referred to as Stingray, normally cost 50K to 200K. The goal of this post is to take the price down to something that is reasonable to regular consumers. With this, the author hopes they will be made illegal with no cheap they could be made.

The article focuses on 2G and 3G, which use GSM. The major security issue with GSM is the lack of mutual authentication. This means that handset (phone) does not authenticate the base station prior to accessing the network. By abusing this functionality, we can sniff and acquire the IMSI of the phone.

The IMSI number is within the SIM card. With this information, the person sniffing this traffic can identify and locate the phone user at a minimum and potentially intercept and spoof the user's traffic.

The author then goes through step by step to sniff GSM traffic. First, he walks through installing Kali Linux and gr-gsm for GNU radio, which is an open source radio project. After this, the program kal is used to find the base station and the frequency being used in the area.

Using kal -s to scan for frequencies, the author finds 889 and 890 being used. Now, we can try to sniff the base station traffic. Using the grgsm_livemon utility, we can tune the frequency to the GSM base station.

Now, simply using IMSI-catcher utility, we can capture IMSI traffic for 2G and 3G phones. Using this program, there is a picture with several pieces of captured data, including the cell ID , operator and other things.

The craziest part of all this: the author uses an RDL-SDR! This is limits which GSM frequencies can be used but this brings the bar down to $25. Using more sophisticated (and expensive) equipment, the author will demonstrate in the future how to intercept mobile communications.

This is the final in a four part series of breaking the secure boot of a Zynq FPGA device. The Zynq family of boot images all contain a set of Register Initialization Lists; this is used prior to the heavily lifting of the bootrom. The RIL's are for hardware initialization including clocks, muxes. power and several other things.

What are the security protections on this? As one would expect, these are covered by secure boot cryptographic signatures. Additionally, there is an allowlist of addresses that can be used. These restrictions include no DMA destination/sources, which were implemented because of pre-release exploits abusing this feature. The signature does have a flaw though: it is only checked after they are parsed and used, creating the potential for security flaws.

To test out these addresses, the author wrote a script to emulate the ROM using Unicorn. To test the allowlisting functionality from above, they directly called the function do_register_init_lists to see what was accessible. In modern systems, there are multiple DMA sections. From testing out all of the addresses, they noticed that the SDIO (Secure Digital In/Out, which is communication to an SD card) controller was NOT blocked for writing.

What does this mean? Boot via SDIO is fair game at this point in the secure boot process. Since this is the case, the author thought "Can I set my own DMA block size into registers?" Sadly, this did not work out, since the ROM resets all of the SDIO config registers with each command. However, it does NOT clear out the DMA base address register. Since this is the case, the pointer to this object will in the 512 byte page buffer.

Since the DMA base address register was never cleared, we can write to the location that this points to in the ROM. The author points out that 0x7068c contains a pointer to the boot function operation to use. Overwriting this with an address of our choice would lead to a compromise. Hurray!

The author ran into a caching issue (along with many other things) since caching at this level is weird; working around this appears to be a complicated problem. To built the full image to compromise secure boot, the author has a script on their Github as well. Overall, this is a really cool post on compromising the secure boot process. Check your signatures early on! :)