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!

Many iPods were jailbroken back in the day. However, many of them survived the craze without being touched. To the author, this is unacceptable! So, they went down the rabbit hole of Jailbreaking the iPod nano 5G+.

The iPod Nano tech stack is different other devices. Instead of running iOS/XNU, it uses an embedded RTOS that is based around the RTXC kernel. This is not a security based kernel but has literally zero research into it. The early devices use a PortalPlayer SoC but the 3G+ use a Samsung S5L87xx SoC.

The boot flow is as follows:

1. BootROM: The on-die boot to get the system going. It performs just enough operations in order to load the second stage bootloader.
2. Second Stage Bootloader: Loading from either NAND/NOR depending on the device. Brings up other peripherals like the LCD screen, DMA and DRAM. Once it's loaded these, it loads the main firmware.
3. OS/Disk/Diags: There are several modes that can be used. First, the main OS can be booted. This uses the Image1 format, which was used by early iPod systems. Second, there is a disk mode (unsure what this is) and a diagnostic mode.

When booting into system recovery, the BootROM goes into USB DFU mode called WTF. The WTF system verifies the image then boots. This means that the USB stack can be attacked! The author didn't have access to the BootROM of these devices though; they were the first to look at them! From prior hacks, they did have good notes from previous hackers, BootROM from 2G, 3G and 4G and decrypted firmware from these devices. This was a good starting point for looking for new bugs.

The previous jailbreak was down via X509 parsing - Pwnage 2.0. They didn't see any obvious new bugs here though. While looking through the USB stack, they would an extremely straight forward buffer overflow. A crafted USB setup packet with a large index is used fora write into the usb handlers without any boundary checks! This means we have a an out of bounds access of USB handlers. What can we do?

Effectively, we can treat some of the fields after usbHandlers in State as a code pointer to jump to. These are offsets 0x64 + (0x1c * n) and 0x68 + (0x1c * n) for N in 0..255. From experimentation, they learned that wIndex to 3 with a class request will treat the uint at 0ffset 184 in the State as a code pointer and execute it. In that location, there's a counter called ep0_txbuff_offs that can be used.

The device can send over what's in the buffer and receive data for the buffer as well. Using this, we can use a value between 0x0-0x600 as the address to jump to. At address 0x3b0 is the ARM instruction blx r0, which will jump to the address at r0 which is an argument in the USB::HandlePendingSetup call. This means that the USB setup packet will run as ARM code! The DFU buffer is 136 bytes, which is more than enough instructions to get stable code execution.

With the 4G tackled, with a known attack, we can now go after the 5G. Luckily enough, using the same code as before will cause a crash but the code execution doesn't work. They created an oracle to try to find the gadget from before. If they made the code jump to 0x000, then a reset would occur. Otherwise, something else would have happened. They jumped to the DFU buffer and executed the same shellcode as before.

With the stable exploit, they were able to boot their custom firmware over USB. With this, the BootROM can be dumped and Linux can be booted from. Overall, an interesting blog post on reverse engineering and blind exploitation.

EarningFarm is a set of smart contracts that manage crypto assets. It has a native token, EF, that is used to demonstrate the amount of funds put into the protocol.

The amount of EF token is passed to the withdraw() function to determines the amount of Ether that can be withdrawn. Prior to performing the withdraw, the contract may not have the funds to perform it with the proper token. So, it may take out a flashloan from balancer in order to do this.

The amount of the flashloan and withdrawal depends on the balance of the EF token held by the user. The callback for the flashloan does a sanity check to see if it's coming from balancer or not.

A user can manually invoke the flashloan via balancer and use ENF as the recipient. This completely bypasses the withdrawal limits. This means that a large sum of ETH was believed to be OWNED by the contract. The attacker could withdraw a small sum of funds but withdraw() always sends the full amount, since the difference is extremely large.

In essence, bad input validation wins the day again. Here, the authors didn't consider that somebody else could invoke the call for receiveFlashLoan.

Treasure DAO was the largest NFT marketplace Arbritrum. Recently, it was hacked. But how?

The function buyItem() can be used to purchase existing listings to be bought for no fee on the NFT platform. The function signature is buyItem(nftAddress, tokenId, owner, quantity).

There is no validation that the quantity parameter is NOT zero. When multiplying the per-item price with the quantity, providing a zero would result in a cost of zero.

From reading the source code of the application right before the bug fix at here, it appears that the NFT transfer was a full NFT. The quantity was NOT use on ERC721 but only used on ERC1155. The quantity item feels a little weird in this context.

Overall, interesting input validation finding!

Microsoft Remote Procedure Call (MSRPC) is a prevalent communication mechanism that provides an extensible framework for defining server/client interfaces. The author wrote a tool called RpcInvestigator for advanced discovery and analysis of RPC endpoints.

The tool can automatically generate client code, sniff interactions for RPC and enumerate services. A pretty neat tool for Windows service auditing!

Edge Side Include (ESI)is a small set of XML tags in HTTP solutions, like caching or a reverse proxy, to fetch more information about a page for which a template is cached. For instance, a caching server has a page that is mostly static but with a single piece of dynamic content. ESI would allow the developers to replace the dynamic portion of a page when it is processed.

If an attacker can reflect ESI tags in the response or part of the static page, then ESI injection occurs. This can lead to SSRF via specifying a request to make for the data, XSS, HTTPOnly cookie bypass and many other bad issues. The article above has a list of software that supports it, including NodeJS ESI, squid3, fasly, Akamai and many others. The specification for ESI is not always fully implemented though.

The author was looking through the page source and noticed an ESI tag (why would this be in the source of JS though?). The WAF in front blocked the attempted ESI include payloads but didn't block <esi:>, which produced 500 errors. Additionally, the Burp Suite scanner found that it was possible since the comments were being removed but everything else was kept.

The author of the post decided to collaborate with a friend on the bug. Their friend found XSS within a half hour of trying. A tweet is mentioned using <!--esi .... --> within a payload to bypass the parsing and still get the ESI parsed. I don't know HOW this get parsed but the comment seems to simply be removed. Now, the WAF doesn't stop it and the payload works.

Some ESI implementations are SUPER powerful. The original payload is um6k<!--esi $(QUERY_STRING{countryCode}) --><!--esx-->ekdi&countryCode="}};prompt.call(null,origin);//US. The idea is to use the comment to make the WAF not block it then reference the countryCode parameter in the URL with the QUERY_STRING code to get XSS. Since ESI is so powerful, we can concatenate strings and do lots of things.

To make matters worse, this implementation supported the usage of cookies in the check. So, the ESI injection could be used to reference an HTTPOnly protected cookie! If a user clicked on a malicious link, this would lead to complete compromise. To exfiltrate the data, they used XSS and the concatenated session cookie to get the data.

While browsing another subdomain of the company, they found another ESI injection bug. They noticed that the HTTP_COOKIE could not be referenced because of weird transformations. So, they used the function url_decode within ESI. Akamai doesn't see this as an issue and does no transformations on it. They used the SSRF to their own site with the cookie to exfiltrate it.

They found ANOTHER endpoint that was vulnerable as well but with different blocking rules. The ESI injection was in a application/json endpoint, meaning the XSS approach wouldn't work. So, they simply changed the content type using ESI (lolz) using the add_header function. They even found a few of these until the company told them to stop looking for ESI injection bugs!

Overall, an interesting masterclass on ESI injection bugs! In the future, I'm curious to see how popular ESI really is.

AWS Admins use CloudTrail to monitor API activity within their accounts. This allows suspicious activity to be discovered quickly. So, what would happen if we could bypass this? An admin could miss a ton of malicious activity!

While reviewing the network traffic, the author noticed several requests to an aws service with iamadmin in the name. This is different than the standard iamv2/api/iam API. Besides the name change, the functionality was completely different as well; the service name was AWSIdentityManagementAdminService instead of AWSIdentityManagementV20100508.

The methods in this other set of APIs were similar to the regular API calls but NOT the same. For instance, ListMFADevicesForMultipleUsers vs. iam:ListMFADevices. The authors SigV4 signed the request and it worked as expected. But what didn't work? CloudTrail!

Using the ListMFADevicesForMultipleUsers endpoint did not log in CloudTrail at all. They expanded this concept to many of the APIs on the same service as well. The functionality was only possible on the nonmutable functions though. This undocumented API allowed them to make calls not logged. Time to avoid detection!

Overall, a pretty neat finding! With this complicated of an eco-system, small things like this are likely to slip through the cracks.

Oracle CDE (Common Data Environment) is a tool to collect all project information into a single platform. This is done via cloud syncing, I presume. The authors of this post had recently found vulnerabilities in the application but decided to hunt for issues in dtprintinfo since it had a track record of bad bugs.

They spent a few days looking for bugs in it manually to no avail. So, they wrote a sophisticated fuzzer. Whoops, sorry. They wrote cat /dev/urandom > ~/.printers as their fuzzer! By doing, they immediately found a bunch of crashes. So, what happened?

Setting fake printers via the configuration file for dtprintinfo caused a bunch of problems. By manipulating the contents with fake printers, it was possible to read heap memory of the setuid root binary. Additionally, being able to pass in printers is NOT something that should be possible as a lower privileged user and opens up a new attack surface.

The authors decided to target the parsing of printer icons in the XPM format. They wrote a simple mutation based fuzzer and found some bugs in the libXm library used by the application. The app was opened in Ghidra with the script Rhabdomancer to find known bad code syncs. They found a trivial buffer overflow via strcat that was triggering a crash.

The exploit code for the Solaris OS is very well commented and nice to look at! A few interesting notes:

• The shellcode is put into a environment variable. This indicates a lack of Nx on the binary.
• The location of the shellcode is dynamically calculated. This is done because of environment variable padding. It appears there is no other leak to break ASLR though.
• Contains a bunch of file manipulation. Since the input for exploitation is within a file, this makes sense.
• They have code for checking for bad characters, such as nullbytes, HT and space. This is to make the exploit more consistent.

The article shows a GIF of a POC as well. Pretty neat to see everything come together, even if modern binary protections aren't enabled. Overall, a fun article on finding a bug, finding more bugs then exploiting the bugs!

The author of this post is the developer of GameFinder: a .NET library for finding games installed via different stores. Recently, EA deprecated Origins and moved to EA Desktop. While trying to add support, the author learned that EA had added some level of encryption. This post is about breaking that encryption.

The author found a IS file and through it into hexdump. The beginning of it appears to be a hash and the rest of it looks like junk. They through the rest of the file into CyberChef with Shannon Entropy turned on in order to determine if the file was encrypted. Since the randomness is high, the file is likely encrypted.

How is this encrypted? The author noticed that the files changed during the stopping and starting of downloads. So, they prepared a HUGE download of Apex legends and slowed down the speed to 512kb/s. At this point, they started using Process Monitor with a file on the file of interest to see what was accessing it.

The only executable that turned up was EABackgroundService.exe. Even cooler, Process Monitor will show the stack at the time of execution. This allows for decrypted data to be seen and for us to identify the region of code that executes these steps. Pretty neat!

From following paths in x64dbg and Ghidra, they were able to identify the functions that processed the data - hurray for debug strings! In particular, the error message "AES256 CBC encryption failed" failed was helpful. There is a function call to EVP_aes_256_cbc(), which is from the OpenSSL library. Nice! Now we know how these operations are being performed.

By stepping in x64dbg around here, they could find the aes key and IV that was being used. The key appears to be hardcoded while the IV is not. They include a CyberChef setup with the encrypted data, key, IV and everything in here as well. Pretty neat reproduction steps that people can follow along with!

How are is the key and IV generated? Right before the encryption function, which takes in the key and IV, the author found another function that handles this. The IV is ALWAYS constant - why even use CBC the!? SHA3_256("allUsersGenericId" + "IS") was the code used to generate the IV.

The key generation is much more involved. The code "allUsersGenericId" + "IS" + "a2a0ad25aa3556c035b34ea63863794e54ad5b53" was the string used for hashing. The first two are constants but the final string looks weird. Since this is 160, it must be a SHA-1 hash. Looking into the code for the function evp_SHA1 turns up a single function. While in this function, it appears to be taking a SHA1 hash of the hardware information.

Quite a bit of data was used to generate the hash: baseboard manufactuerer, serial number, bios serial number, processor ID and several more bits of information. To access this information, the author used the WMI API. With this, they could decrypt the file on any machine.

The author makes a bunch of complaints about this being useless encryption. If you have control of the machine and the data has to be decrypted for use, then EVERY encryption is made; it's more about obfuscation then anything else. It took this man 4 days to figure out, which most people would just stop at.

Adobe ColdFusion is an IDE by Adobe Systems. It used to develop Colfusion Markup Language apps. The administrator has all server databases stored in a single location, which is where the bug exists at.

A user can configure data sources via an ODBC Socket. The ODBC agent listens on port 20009/tcp for the application. It uses the eneral Inter-ORB Protocol (GIOP) protocol to do this. The handles of these packets, which can be done remotely, is where the bug exists at.

A request message to the clients will invoke an operation on the server. While parsing opcodes 8 there is a heap based buffer overflow when the OpcodeDataSize is lager than 38. In opcode 7, the same issue occurs in a call to memmove on the same parameter for a size larger than 22 to the stack.

The article claims that the second bug (stack overflow), a remote unauthenticated attacker can exploit this to get code execution in the context of SYSTEM. Since we're in 2023 now, I would expect stack canaries, ASLR and other protections to be in place though. Overall, a really bad (and simple) bug on a remotely exposed service. Sometimes, it's about finding the new attack surface than finding crazy bugs.

The Issuer on a Certificate is completely useless. Many of them are defunct companies or were bought out by another Certificate company. Since certs can last a long time or the purchasing company wants to keep the brand, it will remain the same.

Since this is annoying as hell, the author of this post wrote a tool to find the TRUE owner of a certificate: sslmate. Seems like a useful tool when you need to know more about your certificate issuer.