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!

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!

Ads are dynamically loaded onto a website by some sort of ad network. Since the ads want to understand the website it is loaded on, the URL of the hosting page is added into the ad source.

When adding the domain of the page to the website, there is no validation done on this logic. As a result, XSS can occur. For instance, within pwt.js, the function displayCreative will execute to display the ad. This is done by calling document.write directly to write the ad int the page of Urban Dictionary. Since the document.write does not escape the single quote, the string can be escaped, leading to JavaScript execution.

The author claims that this vulnerability effected many different ads on the website. That is fascinating that so many places were vulnerable to the same attack; I wonder if they used the same template or something? Even though Urban Dictionary did not do much wrong, the host of the ad messed it up.

Zenly is a live map of friends and family. It is a part of Snap Inc.

During the authentication flow, an SMS message is sent to the user to validate the session. The flow is as follows:

1. SessionCreate is called with the mobile phone number of a user.
2. A session for the user is created with a session token being returned. Not operations are allowed until the verification on the SMS message is complete.
3. SMS message is sent with the verification code.
4. Call SessionVerify with the session token and the verification code. Now, the session token of the user becomes valid and they can login as normal.

When calling SessionCreate, the same session token is returned now matter how many times this is called. Although this sounds like a reasonable feature for storage reasons, this has catastrophic consequences.

An attacker can call SessionCreate with the users phone number. Then, wait for the legitimate user to validate the SMS message. Once the user has validated the SMS message, the session token is valid. Since the session token was the same between the two users, the attacker now has unrestricted access to the users account.

To fix this issue, the token should be unique from SessionCreate and each call should generate an SMS code. Since the code is different between two calls, this attack no longer works. Overall, I really enjoyed the vulnerability since it requires a deep knowledge of how the system works.