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!

Joe Grand is an OG hacker from the days of the L0pt. He runs hardware hacking trainings all over the world. In this instance, somebody had a crypto wallet with 2 million of a cryptography, but forgot the password. Joe is trying to free the coins off of the wallet with hardware hacking black magic.

The wallet is a piece of hardware that stores the private key of the crypto wallet. By getting this information from the wallet, an attacker can get the bitcoin. In this case, the wallet has a pin on it that will give the private key if the pin is correct. Luckily for them, the source code for this product is open source.

Joe Grand (King Pin) thought that fault injection would be a good avenue to attack this from. Fault injection is the act of forcing the computer into a bad/unexpected state. If a fault is created, such as with clock or voltage glitches, instructions could be skipped, ran twice or values changed altogether. This is done by physically modifying the hardware of the computer, which he practiced on other wallets prior to this one.

The Micro Controller for the wallet has a protection that makes it impossible to read the contents of the memory. The goal is to glitch this check to allow for the reading of the memory by putting it into a DEBUG mode. Since the key is copied into RAM via a memcpy, this allows for the secret information to be recovered.

Practically, setting up the glitch is complicated though; even the teardown is hard! The author first removes all of the protection gunk of the chip to be able to connect to the proper headers on the PCB. After this, they remove the capacitors that are explicitly there to protect against voltage fluctuations. If these were still on there, then the glitching would be less consistent and harder to do.

To set this up properly, the authors used a Chip Whisperer. This was done by externally providing power to the chip via this tool then activating the glitch programmatically through the tool. If the attack worked, then a JTAG debugging menu should appear; the author has a JLink setup to communicate with the chip in the event that the attack works.

The Chip Whisperer has an amazing software interface. Using this, the author tries many different glitch timings. On every run, they see if the interface is open to connect. Otherwise, they try again. What is amazing about this, is that the process is completely automated. At this point, they simply have to wait!

After the glitch succeeds, Joe Grand used a Python program to dump the memory contents via JTAG. After running strings on the memory dump, a pin appears to unlock the device! At this point, they can recover the key from the device to get the money.

Hardware hacking requires lots of failures, patience and knowledge. This was an amazing article on how the hardware hacking was done to get the key off of the wallet. Trezor, the maker of the wallet, has a list of security vulnerabilities on their website as well.

In Wordpress, the post slug is the title put into a URL. However, the slug can be manually set by an author.

The function sanitize_title() governs how the title to slug transformation is done. When this is done, it converts all characters into ASCII, numbers, underscores and dashes. This sounds restricting but looking at the source code unearths some hidden functionality: the sanitization preserves URL-encoded octets, and, indeed, slugs can contain URL-encoded characters. What can a URL encoded string do for anything though?

Within post.php, the slug will eventually be URL decoded. If the slug does contain any URL-encoded characters, it gets encoded once again. Here is where the problem occurs: utf8_uri_encode only encodes Unicode characters. Crazily enough, utf8_uri_encode('<script>alert(1)</script>', 200) will output <script>alert(1)</script>. So, the URL encoding does not work as expected on the way back!

This functionality exists within the call to __truncate_post_slug(). The only time this gets called is when Wordpress is saving a post that has the same slug already. Since the post slug should be safe, but can now have arbitrary input, the character expectations have been violated. Pretty quickly the authors found an easy place that XSS was triggered on the page.

The fix for the vulnerability was to properly URL encode the data after the modification. According to the authors, extra care needs to be taken when modifying a value once it has been sanitized. Overall, this is a super interesting vulnerability that would only be possible to find through source code review and confirming assumptions about the code path.

There is a CTF challenge where an attacker can upload and emulate an arbitrary executable inside a sandbox using Qiling version 1.4.1 (the latest version at the time of writing). As such, we need to figure out how to escape the sandbox and ultimately achieve arbitrary code execution. The code for the program is simply a sandbox and the job is to escape it in some way.

Qiling is a binary emulation framework. Under the hood, it uses Unicorn for CPU emulation. However, everything else related to the OS is handled by Qiling. All of the binaries must be compiled statically in order to work within the sandboxed environment. Qiling has implemented most syscalls; this is where the authors of the post decided to look at.

The file system handling is done by concatenating the rootfs name (such as /tmp/mysandbox) to the file inside the sandbox (/tmp/mysandbox/my_file.txt. The application does path normalization to make directory traversal not trivially possible. However, they did not consider that directory traversal could be done within a symbolic link. Hence, the file to access is concatenated with the path from the symbolic link, giving us access to the host file system.

Sadly, the symbolic link syscall was not implemented in the sandbox fully. Back to the drawing board! The syscall openat is similar to open except it has the additional parameter dirfd with it. According to the man page: "If pathname is absolute, then dirfd is ignored." Since the sandbox will pass in the FD and the path, the sandbox can be trivially escaped using an absolute path in the openat syscall.

With the ability to read and write arbitrary files via the mishandling of the openat call, how do we get code execution? To do this, the authors decided to modify the running sandbox process via /proc/mem, which is a virtual file for the processes memory. To do this, they alter LibC with a large NOP sled and some executable code to spawn a shell. With this, there is code execution in the context of the sandbox! The flag is rwctf{s0-many-vu1n_but-only-few-exploitable}, which makes sense from the bug described above.

Pwnable challenges are not always memory corruption; sometimes, they come down to logic bugs. In this case, the path parsing was messed up from a misunderstanding of the openat syscall and the lack of validation done on the symbolic link handling. Great write up for a very interesting bug!

Adobe Reader is a feature rich PDF reader. Rader supports Embedded JavaScript to allow for interactive PDFs. JavaScript allows manipulation of form fields, annotations and other page content in a PDF document.

When adding an annotation to a page, the following below can be used. The gestures are an array of X,Y coordinates.

document.addAnnot({page:0, type: "Ink", point: [1,1,1,1],popupOpen : " ",gestures : arrayOfArrayOfCoordinates});

When the array of coordinates is passed into the annotations API, it appears to take an object and an index for the object as the key. Reader will take an argument of -1 to be the signed integer of '0xFFFFFFFF' returned from atoi. However, there is validation to make sure that value is not bigger than 0x55555. All seems good, right?

When the validation occurs, it adds 1 to the value. This is done because the index is 0-indexed but the length starts at 1. Hence, when the +1 is added to 0xFFFFFFFF, an integer overflow occurs on the validation, leading to the value becoming 0. When this becomes 0, it bypasses the validation, even though 0xFFFFFFFF is way too large of a value the array being accessed.

This integer overflow leads to the accessing of data outside of the buffer. Since the buffer is a group of pointers, it can be used to dereference arbitrary objects in memory. Additionally, with JavaScript, this can be used to form the heap so that the dereferenced object is something that we control. Eventually, this could be taken to code execution.

Zoom became a sponsor of the Pwn2Own 2021 edition. From this, two vulnerabilities appeared that resulted in a Zero-Click exploit to compromise Zoom. This article is an analysis on two vulnerabilities and the exploit method, as from the perspective of the prestigious Project Zero research team.

First, Natalie thought about the attack surface of Zoom. People can join Zoom via different platform clients, a browser link, phone and many others. Additionally, audio, video, screenshare and many other inputs can be used as attack vectors. They wanted to see zero-click attack surfaces. From looking at the output of strings and IDA, they noticed that the server communication is done over XMPP via a library called Gloox.

To more deeply reverse the application, they hooked the SSL_write function with Frida. The output of this contains many XMPP messages and other network traffic. Even though this was helpful, she still had issues reversing it. So, her co-worker Ned noticed that very old versions of the Android application had symbols, which made it easier to reverse.

From there, she dove into the RTP (Real-time transport Protocol) and packet processing of Zoom. They fuzzed the RTP entrypoint on Linux to find a few bugs, locally. On the server, these bugs were not reproducible and she ran into many hurdles while trying to fuzz this. While learning more about the system, the author noticed that the library libssb_sdk.so did a fair amount of other traffic. They decided to focus on this functionality for a little bit.

While reviewing the disassembled code in IDA, they noticed some code smells. One length was being used to create the buffer (dynamically) and the other was being used to actually write the data into it. As a result, this resulted in a linear buffer overflow vulnerability. To test this out, they ran the code but hooked Frida to manipulate the data being sent to the function.

While looking around the same code, they noticed that all deserialized objects contain an optional type field called dyna_para_table_t. The implementation looked prone to type confusion bugs because of dynamic typing. For instance, the length specifies whether the data is an array or just the length. If the value is NOT 0, then it is assumed to be an array. Any time there is dynamic typing like this, the developers are asking for trouble!

They attempted to find bad type confusion bugs but the Zoom MMR client did rigorous type checks, making this impossible. They went down a path for integers, controlled by the user, being used as pointers, but could not find anything here either. Finally, they noticed that data, of type string, was not always validating if the string had a null terminator.

The idea is that a string type, without a null terminator (\0) being in the string, the string could be next to adjacent memory. When this would be interpreted, all the data after the copy would be considered part of the string, until a null byte was found. By using this technique on a Zoom user name, pointers could be returned from the user, resulting in a information disclosure.

Natalie attempted to exploit these two bugs but stopped because of time constraints. When attacking real world application with so many allocations and timing problems, it is hard to create a stable exploit and bypass all mitigations. The author notes that having more products be open source would have made this much easier to audit, instead of spending all of the time reverse engineering.

To me, this article shows the pains of security research and exploit development really well. All of the bad paths were month-long attempts, if not more. Sometimes, the task is too time consuming and not worth the effort so we move on. I appreciated the honesty in this post :) Overall, great article with good insights into the world of a security researcher.

A terminal emulator is a computer program that mimics a video terminal with access to the local or remote host. The emulator allows for seeing the output from the program or running commands on the box. Obviously, if you can trick the parsing of the program, you can execute arbitrary commands on the machine. Interesting attack vector!

ANSI escape sequences are a standard for in-band signaling to control cursor location, color, font styling, and other options on video text terminals. Normally, it starts with an escape character, such as ESC (0x1B in hex) followed by a set of arguments. From reading CVEs from 2003, they noticed that modifying the title via the escape sequence could be executed later since the .bashrc file loads the title every time you press enter.

From these previous CVEs, the author learned a bunch. In CVE-2015-8971, a newline was not filtered in Terminology 0.7.0 when changing the window title. As a result, it allowed an attacker to modify the window title and then re-insert it into the terminal’s input buffer, resulting in arbitrary terminal input (which is code execution).

After trying to find new bugs in the terminals, the author wrote a quick bash script into the terminal: perl -e 'while(1){print "\e]0;pwn\a"};'. This constantly set the name of the title, which caused the computer to crash. They reproduced this on browsers, terminals and many other things. Apparently, setting the title of a terminal can lead to a DoS!

The Kubernetes and Openshift name does not escape ANSI escape characters. Since this is the case, an attacker could add ANSI escape characters that will change the terminal window title, paint the terminal with whatever colors I choose, delete that display and so on. This does not allow for arbitrary code execution but the showing or removal of text is fascinating!

Most terminals have bracket paste mode. This is to protect against commands copied directly from the internet being ran automatically. To prevent these calls from happening, the beginning code has ESC [ 200 ~ appended to it and the ending has ESC [ 201 ~ added to the end. To bypass this feature, the author starts their copied text with ESC [ 201 ~. Now, when the actual escape occurs, we will end the escape to run our own code. Neat!

The authors found that MinTTY, XShell and ZOC were all affected by the vulnerability mentioned above. This post was a good introduction into ANSI escape characters and the damage they can cause if not handled properly.

Uniview is a popular security camera. There is a proprietary protocol listening on UDP port 7788.

The vulnerability is a buffer overflow in string parsing from using sscanf without validating that the size of the buffer is big enough. This allows for stack smashing to run a ROP chain to pop a shell.

The shell is restricted though. Good job on the part of the development team for doing this! Even though it is restricted to writing to the /tmp directory, the script killwatchdog.sh can be overwritten. Then, upon rebooting the device, the script gets executed, escalating the privileges of the user.

Two simple bugs lead to a compromise of the system. Defense-in-depth is crucial!

The CentOS Admin Panel (CWP) is a popular software for web hosting management software. This software is used by over 200K severs, making it a good target for attackers. The authors of this post decided to only look for unauthenticated endpoints.

When looking at the unauthenticated pages, they noticed a couple of interesting pages. In particular, index.php had an interesting file inclusion protection. This protection

If the parameter script contains "..", then the application would not parse it. This was done via the call stristr for the literal text "..". stristr tries to find a substring within a string but without dealing with case.

The author had a few interesting ideas to try! The first one was trying to find characters that would be interpreted as dots in the unicode dataset when normalizing. However, this was a dead end.

The second idea was abusing the case-sensitivity from normal to upper/lower case when the comparison was being done. The authors fuzzed this by passing in weird Unicode characters to see if something would be converted to a period (".") when lowercased. Although this was a cool idea, nothing panned out.

Since the LITERAL text ".." was being searched for, can we achieve the directory traversal without this exact string? Between the two periods, the authors noticed that the functions 'require' and 'include' in PHP remove nullbytes in the path when finding the script! As a result, .%00. would bypass the validation but since the '%00' was removed, the path would resolve properly.

Now that the require can call arbitrary scripts, we can call scripts outside of the expected directory. It can even include parameters on the requests for PHP files. In order to exploit this bug, the authors created an API key via a PHP script. To finish it off, they found an authenticated file write, where they could add PHP to the file. Using the vulnerability mentioned above, this could be called, resulting in code execution.

The difference between validation and usage will always be an issue in the world of security. In the case of denylists, the bypasses become even more impactful. Good bug discovery and attack surface analysis.

Slack has a feature known as Blocked Previews. This is where workspace owners and admin can specify a list of URLs for which no link should have a preview occur.

Parsing URLs is crazy complicated though. There are so many different ways for a URL to be rendered. Simply doing an denylist without normalization would likely cause issues.

The author of this post found a few ways to bypass it. With domain names, we separate them with a period to represent a different section of it. A TLD, such as .com actually is not the highest part of it. The highest TLD is a period, but it normally left out.

For instance, https://jub0bs.com./posts/2021-01-29-great-samesite-confusion/ has an extra period after the .com.. The second bypass was using a directory traversal in the URL to break the path parsing.

URL parsing is really hard! Lead it to the professionals :) I enjoyed this bug since it went through the denylist by using alternative URL parsing methods. Good bug find!

Moodle is an open source eLearning platform built in PHP. Moodle has an authentication plugin for the Shibboleth protocol; this is another SSO solution.

For every logout request on Shibboleth, the function logout_db_session() is invoked. The function iterates over all available sessions then decodes it with the session_decode function. This will decode the serialized session data AND put it into the super global $_SESSION. This second side affect is a big deal.

While iterating over all sessions with the session_decode function, the logging out user logged in as every user for a very small time window. Additionally, the LAST user is never unloaded, meaning that the session remains populated with the last user. An attacker can do this, clear the session and try again until the last user is an administrator.

The solution to this vulnerability is to decode the session by hand instead of using the PHP built-in function. To me, this is a bug by the developer but more blame goes to PHP. There should be a way to decode a session without becoming that user. In the future, I'll have to check for calls to session_decode to see if a similar issue exists. Good find!