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!

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! :)

postMessage is a way to send data from site to site on the client side. In particular, it tends to be used with between iFrames, such as with the Youtube player. Since postMessage is normally considered trusted input, many XSS and information disclosure bugs have appeared from this in recent years. To find bugs in this, the author uses the tool PostMessage-tracker.

When using postMessage, it is important that the website checks the origin of the request. If this is not done, then the page can be iFramed and communicated with from another domain.

At this point, it is incredibly important to see how the data is actually be used. In this case, the event data could be used to change some window settings. When reviewing how this was done, it was loading a domain from Cloudfront and a subdomain that was controllable by the user. From there, it would grab the JavaScript to run it via an eval. Was this code secure?

The goal is to make the domain match a malicious server instead of the expected domain. By messing with the parsing of the region, a region of .my.website/malicious.php?_bad would work to add our domain in the front. This code is shown below:

  var region = window.settingsSync.region;
  var subdomain = region.split("_")[1]+'-'+region.split("_")[0]
  domain = 'https://'+subdomain+'.settingsSync.com'

At this point, an attacker could load arbitrary JavaScript within the context of this iFrame! By specifying their own attacker server to host the JavaScript, an alert box could be popped. But, this was JavaScript execution within the iFrame; can we go back to the original page?

The main page had its own postMessage handler for grabbing credentials! The iFrame, that we have JavaScript execution in, is an allowed origin in the communication to the main iFrame. Now, by running JavaScript in the context of the iFrame, we can make a request for credentials for the site. Damn, that's really cool!

The second bug started while looking at the OAuth confirm page page of a website. The URL for the request would dynamically create GET request based upon the client id in the confirmation page request. While messing with the response of the request, one of the fields was being inserted into the page without any sanitization. If the response of this request could be controlled, then the site would be vulnerable to XSS.

The query parameter domain allowed for the controlling of the URL. However, setting this to an arbitrary domain was not possible because of Content-Security-Policy (CSP) reasons. When making HTTP requests, they adhere to the connect-src CSP rule. Since the actual directive was not specified, it uses the default, which contained *.companyb.com and *.amazonaws.com. Since we can easily host a page on *.amazonaws.com, we can easily bypass this restriction to load in arbitrary content.

Again, the CSP caused problems. The only acceptable locations for scripts (defined by the script-srcself and *.companyb.com. From previous work on this website, the author tried finding an open redirect on the company website to allow us to load data from an arbitrary location, bypassing the CSP.

The open redirect had a restriction for the domain though: the string had to end with companyb.com in the URL. By providing a URL encoded newline (%0A), the domain validation could be bypassed. Then, when the browser parsed for the website, it would assume that the newline was the end of the domain! As a result, the open redirect could be used to achieve XSS through the filter bypass.

Both of these bugs are amazing finds when many steps along the way! Most applications are built with a secure inner wall. But, once you penetrate that inner wall, assumptions breaks down and security is not as good. By abusing several features of the website with tiny bugs, two major compromises eventually occurred.

The device is a Baby Monitor that can be accessed remotely.

The camera uses the MQTT is a protocol commonly used by IoT services. Typically, there is a global service that the device reaches out to. In this instance, the server does not require any authentication to subscribe to, leaking device and user ids.

Real Time Streaming Protocol (RTSPS) is a protocol used for live streaming of data. To use this service, the application will request access to a specific camera feed. With this request, a destination is given back which will have the real time data.

Even though this happens via an HTTPs request, the MQTT service offers the same functionality. Since the MQTT service does not require any authentication, this call can be made to arbitrary cameras. Since we control the destination of the call, the data can be loaded to an attackers server.

The URL (destination) must be parsed by the device once it has been received from the MQTT server. However, the parsing has a fairly straight forward vulnerability: the URL is copied into a static buffer without a bounds check.

This appears to be an ARM device without very good randomization. So, to exploit this, a ret2libc attack is performed by corrupting the EIP on the stack. Since the value of r11 is controlled by the attacker, we can use the pointer to this as the string to execution in the attack.

The camera has a REST API to obtain AWS credentials used to store the recordings in the cloud; these credentials are unique per device. However, the credentials are not generated securely! By knowing the user id and device id, we can craft this authentication token ourselves.

To make matters worse, the credentials for accessing the S3 bucket are not scoped properly! By using these credentials, all data in the bucket is accessible. By simply using the S3 CLI it is possible to see all recordings for all cameras! Damn, that's real bad.

Overall, this was a really good report with many different vulnerability classes. From lack of authentication, poor password generation to memory corruption, this was an interesting write up to go through!