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!

MonkeyType.com is a popular open source type testing application with over 100K unique daily users. As a result, vulnerabilities on this are quite impactful!

The first vulnerability was stored XSS in the chat functionality. Both the message and name parameters do not sanitize input on the backend; they only sanitize it on the frontend prior to sending it back to the backend. As a result, XSS is fairly trivial to perform and can be used to steal auth tokens and take over the account.

The second vulnerability is a user spoofing issue. While sending messages to other users in the web sockets, the user is a controllable parameter. Hence, this value can be controlled to change the display name of the user, which should not be possible.

The final vulnerability is an authorization issue on the leaderboards. When somebody obtains a high score, they should be able to submit this to the leaderboards. However, the requests to change the leaderboard are done via the client-side. As a result, we can arbitrarily set high scores with usernames on the leaderboard. Clearly, this is a problem.

The final two findings are cases of the client not considering the content being sent and the dangers of this functionality. These are the intended features but are just being abused to impersonate other users and alter the scoreboard. Overall, good findings!

Browser security is not all about memory corruption vulnerabilities. In fact, there are a lot of bugs around the thin line of web page and access to everything on your computer. Since Opera is built onto of Chromium, the author took a look at the new features. One of these was the Pinboard.

The Pinboard API accepted an HREF when something was added. By setting the link to a JavaScript URI, we had stored XSS. In particular, the payload was javascript:’@opera.com/’;alert(1), to pop an alert box. Since this was opened within the opera URI, it has special permissions that other web pages do not.

Since the attribute target=_blank was set, the XSS would only execute on the page if a middle click on control click was done. This is still a one click XSS though! What damage can be caused within the opera URI? This is similar to the firefox or chrome URI.

The Opera scheme has the ability to view other pages, bypass the same origin policy (SOP) request files and many other things. However, there are some restrictions in place to make an XSS in the browser not a complete game over. The author made an exploit that opened a new tab with /etc/passwd inside of it. Next, they take a screenshot of this page to see the information. Finally, they base64 encode the password and send it to themselves.

Overall, good post with an interesting exploitation method.

The check spelling Github Actions workflow is a spell checker on Github commits. This functionality happens whenever a PR is made on a repository. Afterwards, with advice on how to fix the mistake in updated in another PR.

When using the check spelling workflow, there is a file called advice.md that holds information about how to handle mistakes and on symlinked files themselves being spellchecked. Instead of having this be a regular file, the author made this into a symbolic link. By placing this symbolic link to /proc/self/environ, we can leak a secret and gain write privileges to the repository.

The GITHUB_TOKEN can be used to write to the repository silently. However, the token is invalidated as soon as the workflow finishes executing. But, this can be raced! By constantly pulling the comments of a PR that we have made programmatically, we can reliability get the token and make a request before anything has happened.

To fix this vulnerability, the symlinks will NOT be followed when anything goes into .git. The author of the bugs also mentions the scoping of the tokens being as small as possible.

Overall, interesting finding with a large amount of background and interesting scripts for the research. Symlinks are an awesome attack vector that is often overlooked.

The Iceland govenrment wanted to create e-licenses but was unsure on how to do so. The government decided to use the Apple Wallet API. The wallets (licenses) were distributed as PKPass files once they were done, which is just a wrapper around a signed ZIP file.

This file contained a few photos and some other interesting files. The pass.json contained a complete description of the license, such as the serial number and personal details. The manifest.json included a hash of all of the files and a signature uses for the manifest file. This is done by obtaining a key from Apple to be used on the wallet.

The idea behind the signature is that it should not be modifiable and the content safe. But, in practice, this is just not the case. Anybody can request a developer certificate from Apple and sign it with this. Additionally, the author found that NONE of the Android apps actually validated the signature. Crypto is good: just know how to use it!

Originally, a scanner for the wallets was discussed. But, this scanner for validation never came to be. As a result, forgery, to trick the naked eye of a human, is trivial. The simple look & feel is the only thing being validated for authenticity.

An easy attack would be simply taking a screenshot and modifying it with photoshop or something like this. The author shows an image that was modified in Snapchat that looks quite real with Donald Trumps picture. But, this is NOT in the wallet app, making it look suspicious.

Going a bit further though, there are multiple services on the Internet, and even mobile apps, allow you to design your own pass for Apple wallets. Using this, it would be trivial to make a replica of the license that we wanted statically or even programmatically via the provided APIs for the service.

Because of the many shortcoming of the license handling, teenagers and many others were found abusing this. As a result, a scanner was officially announced to be in the works.

Overall, the writeup is an interesting story of how a government attempted an e-license system and failed. It is really hard to write secure software!

The bug is in the memcached GET command of the MySQL plugin. The command supports multiple key-value pairs in a single query.

When using the GET command with the form @@containers.name then a few operations happen. First, the table_name is copied into a buffer. Before doing this operation, a validation is done to ensure that there is enough space. This is where the mistake is at.

An assert does the validation. Since assert is a macro that produces code only in debug builds but not in release builds, this leads to a buffer overflow that can be reached when running a release build. Boom!

The overflow and the values in the overflow are completely controllable by an attacker. A trigger for this can be seen below: get @@aaa @@aaa @@aaa ....

Each @@aaa is replaced with the table name during this operation. This bug is likely exploitable by itself but would require a memory leak in order to exploit. The patch simply removes the assert clauses and adds legit code to validate the size prior to the copy.

Validating bugs properly but messing up the error handling is not terribly uncommon. For instance, Boothole did the same thing. In the future, validating the error handling and the usage of asserts in C code is something I'm going to be looking for in the future!

The Wii Mini is a version of the Wii that is completely stripped down of the SD card, internet capabilities, GameCube functionality... it is only usable for Wii games offline. The author wanted to root the Wii Mini but with the little attack surface it was hard! After looking at the camera library, various games and a few other things, they landed on the bluetooth stack.

The Broadcom Bluetooth stack was open sourced years ago because it is used in a myriad of Android devices. The stack originally went by the name Bluedroid but goes by Floride now.

Part of the bluetooth stack includes the l2cap layer. This is similar to a TCP packet in the web stack, as it provides packet segmentation/reassembly, retransmission and a port-like interface called channels. When a connection is made, a channel is allocated for that service.

When passing back information about the channels in the l2cap packets, there is a bug. The channel structure (Channel Control Block - CCB) has a helper function for locating a CCB given a channel ID. The helper function validates that reserved IDs are not used. However, it does NOT have an upper bounds check! This leads to an out of bounds access on the CCB.

In order to exploit this, we needed to create a fake CCB structure. Luckily for us, this sits in the .bss section (which is static)! After doing manual code review, the author found a small buffer that handles the SDP client. This buffer is an array of 0x15 elements of type uint32_t. Even though our structure is much larger than this, the only things needed to make this structure work are in the beginning of the struct!

To make this exploitable though, it becomes much harder to actually do. Many of the final elements would have been nice to have control of, such as a function pointer. The author saw the channel state, a doubly linked list pointer and id fields.

Using the doubly linked list, we can create an arbitrary write primitive when unlinking the element! This does write in both directions but we can definitely make this work. To avoid crashing, we can set specific settings to hit only code that we want to hit. After some investigating, this was possible to do.

The author uses the arbitrary write with the doubly linked list to overwrite a function pointer with address to shellcode. Because the Wii has no ASLR or DEP, code execution from this point is trivial. Since the SDP client provides another big 1000 byte buffer in the bss section that is controllable, we send execution here. This is a secondary loader that fixes the state of the program and loads a USB loader as a secondary part of the exploit. Wii compromised!

Microsoft Exchange is used all over the place in big organizations and is extremely complex. As a result, this is starting to become a goldmind for bug hunters.

Microsoft Exchange creates two sites in IIS. The first site is for web access (OWA) and is known as the frontend. The frontend website is mostly a proxy to the backend. For all post-authentication requests, the front end’s main role is to repackage the requests and proxy them to corresponding endpoints on the Exchange backend site. The other site is known as the backend and handles the bulk of the actual interactions.

Exchange supports a feature called Delegated Authentication supporting cross-forest topologies. Because the frontend cannot perform the authentication in this situation, the request is forwarded to the backend. But, the backend only authenticates the request if the DelegatedAuthModule is loaded.

If the DelegatedAuthModule is not loaded then we have a problem. The frontend forwards the request to the backend for authentication. However, the backend has no idea that it needs to do auth on the SecurityToken header. What does this mean? A complete auth bypass!

This small authentication bypass can be used to change the configuration actions on an Exchange site for an arbitrary user. As a result, a copy of all emails can be seen by the attacker, almost undetected. Boom!

Location based security is really hard to do! Do you send the exact coordinates? Partial? City? All of this is particular to the application and is really easy to get wrong. This is a case where this was done wrong in Bumble.

Originally, Tinder showed distances of where people were located at (in terms of closeness) to them. The exact distance away was being sent to the other person then rounded down. Using triangulation, it was possible to find the exact location of where somebody was located. This was fixed by calculating the distance on the server within a mile.

To find the exact distance, you can use triangulation. This strategy involves moving at various points in the city to get different distances. Then, using three different distances you can calculate the exact location. A good picture is shown in the article about this.

On Bumble, the distance away from taken then rounded down to the nearest mile. Can this be abused? Considering that the location is technically an input to the system (if you spoof it) then we can!

In the Tinder exploit, we knew the exact distance; here, we do not have this same information. By finding a point where the location goes from one mile marker (3) to another (4) we can find the exact distance away again.

Using the strategy mentioned in the previous bullet point, an attacker can get multiple exact distances. As a result, we can use the previous method (triangulation) to find the exact location!

The article includes some interesting information about making this attack feasible. Most importantly, it was about automating the API requests from Bumble, which have signature validation on them.

Overall, great article with a fun story. Location based services are hard to implement! Whenever you come across sensitive information that is relative, it may be possible to find the original.

While playing laser tag, the author decided they were tired of the pay to win model. A group of college students were absolutely dominating because of this and something had to change! The author starts with that laser tag is not meant to be secure by design; this is just them reversing and figuring out how everything works.

The lasers of laser tag are just infrared lights transmitting the signal. The shot in laser tag is simply the signal being turned on. The technology is very similar to a TV remote! The red light coming out of the gun is an added feature; infrared light is not visible to the human eye. Normally, people wear vests. These vests, with the shiny lights, have multiple receivers. In comparison with the TV example, the vest is the TV and the gun is the remote.

There is a backend that sends data back to the gaming server. Who shot the gun? Is this a respond? Did somebody get hit? This may be bluetooth, Zigbee or something well.

The same code is constantly being used. As a result, a replay attack is possible to pwn this. Can we do better though? This could definitely be codified to kill everyone in sight and make an unstoppable player! The design considering are interesting for the context: small/concealable, high power, a UI to customize and data logging to see what was going on. Take it to the limit!

The author bought an infrared light that had 1 amp pulses. Additionally, shine is shaped in a 20 degree cone, which grows quickly. While using a 5 degree overlap, it created a ridiculous 70 degree location that just hit over and over again. To make this setup work with 5 LED at precise angles, the author 3D printed a case.

One of the important things to the author was having all commands run in the background and it was controllable via the phone. To connect to the device, the author created a hotspot and has a web server running on this. The physical commands were sent over pins with pigpio to the buck converter (voltage downgrader) and this went to the LEDs. It should be noted that IRRpy for sending infrared signals.

The flow for this working is interesting! First, shot a gun at the device and record it. Then, repeat again to validate we have got the right signal. Once we sure this is the signal, we can replay this when we want! Of course, this can be done multiple times for other fancier parts of the game, such as bombs or re-spawn points.

How did it work!? The normal gun can get about 2 shots off per second. The fake gun can get 20+ shots off per second. In practice, this absolutely killed everyone playing laser tag at the arena. To make matters worse, they realized they could clone the healing frequency as well; this would allow the team to be unstoppable and never die!

Interesting project and what happens when no one thinks about security. Although the tools take time to make, anything that is insecure will eventually be broken by somebody.

Everyone knows what a kindle is! Luckily for us, it has a wonderful attack vector: e-books. E-books are parsed in a multitude of file types with different parsers depending on the file type.

The architecture of the Kindle is tiered (wonderful diagram here). Of note, is the LIPC, which is an IPC library that links all of the Kindle components together. For instance, a HTML application (webkit) can use LIPC to interact with the native applications running.

The parsing starts with the Java functionality but gets passed on to native C libraries. As a result, the authors decided to focus on these libraries to hunt for memory corruption. How does Java interact with the library though?

The library functions have to be called somehow! By reversing the entry points in the Java file, they were apply to find the callable functions. In particular, openPDFDocumentFromLibrary, getCurrentPage and renderpageFromLibrary were used. These make excellent hooks for fuzzing!

The fuzzing setup for this did not pan out anything though. So, they decided to fuzz a specific object or stream filter or codecs from FoxIt technologies. They setup AFL in QEMU mode for the blackbox fuzzing the different stream types. Eventually, they found a bug.

The authors found an integer overflow on a oversized rectangle. When trying to expand the image to its new dimensions, there is no check that an overflow occurs. For example a result, an allocation of 0x100 is made when the actual size is 0x400000100.

The actual vulnerability occurs in the expand function, which is part of the refine functionality. By using the overflow to corrupt the refine data outside of our expected buffer for an arbitrary write primitive but only with XORed specific bits of memory.

The data and heap segments are RWX and ASLR is set to 1 on Linux; this means that the heap is not randomized! No further details are made on how a shell is popped within the process besides that it is trivial from here.

The next stage is to find a local privilege escalation bug to go from a user to root. After analyzing all of the permissions for this user, they found a flaw in the permissions. The database /var/local/appreg.db stores application registry information and it writable (without restrictions) to our user.

As a result, we can write an SQL query to change one of the command properties to a shell script that we own to become the root user. Game over :)

Defense in depth is important, even on modern day binaries. These protections need to be taken seriously in case of something like this. ASLR being set to 2 and PIE for the binary would have made this exploit much harder, if not impossible. Permissions are also important to check, even if they do not seem critical at the time.