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!

While looking at old bugs in the Linux kernel, the author of this post decided to simply grep for sketchy looking calls to memcpy or memset. This led the author to a call that had broken logic on the size of the buffer.

When IPT_SO_SET_REPLACE is called in compatibility mode and needs to convert the data from 32bit to 64bit in order to be processed by the native functions. Converting data is complicated and tends to be error prone!

In the function xt_compat_target_from_user the call to memset is called with an offset that is not accounted for during the allocation. This leads us to an out of bounds write with a few bytes. The size of the overwrite is not directly controllable by the user; but, choosing different structs carefully allows to make the overwrite as big as 0x4C bytes long.

The primitive is small though: an out of bounds write with only 4 zeros. In the current structure, we can write up to 0x4C bytes passed the buffer or slightly before. Because of the lack of the control on the bytes being written, we must turn this into another primitive first.

Is there anything help we can overwrite? The author mentions reference counters, free list pointers in the heap allocators and a pointer in a struct. In the end, he choose the msg_msg struct to gain a use after free (UAF). This is a good object to spray as well because they are controllable and easy to create.

The msg_msg object contains a linked list to the next message in the list at the beginning of the object. The goal of the spraying is to create an insane amount of these messages, overwrite one of the pointer with our vulnerability to point to another one of the messages. Eventually, we will have two pointers pointing to the same message. This is all done by 00ing out a small of the pointer!

How do we know which message is the corrupted one though? They tag every message with the index of the message in the queue. If the two tags are different, then we know that the corruption occurred on this chunk.

With two pointers pointing to the same message, we can free one of them. Now, we have a use after free on the other object with the forced free that happened. How do we turn this use after free, with controlled values, into something useful?

First, we need an information disclosure, such as a heap leak. Using Unix sockets, the author sprayed messages of size 1024 and imitated the struct msg_msg header. By replacing the msg_msg->m_ts value with something large from the socket code, we can leak a substantial amount of information struct with an OOB read.

The next pointer in the block above is what we are trying to read. By reading this, we can gather where we are located on the heap. With this heap leak, the double linked list (next and prev from before), can now be re-created. With the pointer fixed, we can free this again when the sk_buff struct is allocated over the top to create a more powerful UAF.

The sk_buff buff is better for the uAF because we can use it to free any kind of object in the heap slab. This gives us an even better use after free primitive. They choose the pipe_buffer object because it contains function pointers. A struct within this structure also contains pointers to the .data sections, which is needed for bypassing the code randomization. Reading this is trivial with the current setup.

With heap randomization partially broken and the code randomization broken, we can move onto creating a JOP/ROP chain. We overwrite the function pointer within the pipe_buffer object in order to start the chain.

The chain calls commit_creds(prepare_kernel_cred(NULL)) to install kernel credentials and switch_task_namespaces(find_task_by_vpid(1), init_nsproxy) to switch namespaces of process 1 to the init process. Now, back in userland, we have root permissions to change process namespaces for Kubernetes.

This exploit turns a restricted value write with a limited length into code execution with clever targets and spraying techniques. Wonderful write up!

Aruba Instant is firmware for routers manufactured by Aruba Networks. The routers running this firmware are mainly bought by the enterprise industry (such as airports, hospitals, universities, conferences).

On the WiFi access point page (captive portal), there was functionality for adding a new logo. This functionality was done via a jailed console over SSH/Telnet. The binary takes in a URL, passes it to wget and does a download. Wisely, they sanitized their input from malicious shell characters to prevent command injection.

Does a space ( ) seem scary to you? With powerful binaries comes amazing primitives! Because the space had not been added to the filter for the URL, it was possible to escape the URL and pass in arbitrary arguments. Using --post-file=FILE, arbitrary files can be read; using --output-document=FILE let's us write arbitrary files to the server. But, this is only LPE at this point.

While trying to exploit the bug above, a patch appeared that fixed the space character. However, we can still use a TAB (\t) to do the same attack in a surprisingly effective way.

The next bug allowed for an arbitrary file write to any location via the HTTP server with one restriction: the name ended with .log. While using snprintf with the proper size will prevent buffer overflows, the truncation can be abused to write with an arbitrary file ending! Damn, that is so clever.

All of the previous bugs required some form of authentication. How about we change that? The authors found a race condition in one of the binaries responsible for sending PAPI data. PAPI sends a message then awaits for a response. By sending a fake PAPI message prior to the response, it will instruct the service to read from a file that it shouldn't; something like /etc/passwd.

At this point, it is gameover with an unauthenticated way to trigger the original set of LPEs. Besides these, the authors found an additional argument injection into wget again. Additionally, they found an XSS bug on the captive portal as well.

The steps to exploitation were long and complicated simply because the service is this way! They chained semi-intended features into an amazing set of bugs to own the device. Good work!

cdnjs is a JavaScript/CSS library CDN that is owned by Cloudflare, which is used by 12.7% of all websites on the internet as of 15 July 2021. So, an extremely popular library. The author of this post was interested in cdnjs/bot-ansible and cdnjs/tools because the library automates the update process.

The autoupdate command works by downloading the user-managed Git repository and copying the files from it. When downloading the NPM version of the repository (for updating globally), it downloads a tgz compressed file. With library unzipping, there is the potential for directory traversal (../)!

Most CLI programs unpack things securely. However, the library functions to do the same thing in multiple languages are years behind in this. As a result, adding a crafted name would download the repo and extract the files to whenever we wanted on the server. By overwriting a bash script, library or something else, this could be used to get code execution quickly.

The above vulnerability was in the npm functionality. When playing around with the git repo functionality, the author of post noticed that symbolic links were NOT being handled. By using the symbolic links, an arbitrary file read primitive could be gained. They used this to read Github automation secrets and many other things on the server.

This is a really crazy find! When publishing arbitrary files to Cloudflare, they did not sanitize the input files in properly. If this was exploited, it could have resulted in the compromise of a significant amount of websites on the internet. Symlinks and directory traversal are just attacks that never get old :)

EVLink is an electric car charging station provided by Schneider Electric.

The first vulnerability is an authentication bypass. When using the admin web interface, there is a hardcoded HTTP cookie value. From reviewing the source code, this indicates that this authentication method is intended for local authentication by the "evse" service on the device. The hardcoded token is b35fcdc1ea1221e6dd126e172a0131c5a with username admin.

Once an attacker has bypassed the authentication, they can do lots of things. The device does NOT have a secure update mechanism. By uploading a malicious image, it is trivial to control the device. The reason for the insecure method is that a hardcoded key can be found on the device that is used for the "signing" (hashing) process.

Overall, a set of simple bugs that lead to the compromise of the device. A hardcoded password and improper use of cryptography led to the end of this device.

According to Microsoft, "empowers teamwork with dynamic and productive team sites for every project team". Regardless, Sharepoint is an important aspect of many companies and access to the material on the server is a big deal.

By default, authenticated SharePoint users can create sites/subsites and will have all necessary permissions. In order to prevent malicious things from happening on the server with this permission, the web.config has many different permissions that are dnied for being unsafe and are not allowed.

The security issue exists due to an age old problem: inconsistency between verification and processing. In fact, there is only a ONE line difference between the two: text4 = HttpUtility.HtmlDecode(text4);. If the verification step does not match the run time exactly, it may be possible to bypass the security controls.

There is parsing done to ensure that only allowlisted tags can be used with the runat="server" is used. However, by HTML encoding this attribute, we can bypass the verification step entirely. This works because the verification does NOT HTML decode but the runtime does.

To exploit this vulnerability to the fullest extent is abuse known denylisted functions. For instance, calling System.Web.UI.WebControls.Xml to exfiltrate the machineKey from the web.config.

The full exploit exfiltrates the machine key, which allows for the crafting of a bad ViewState. When this gets deserialized by the server, we get easy code execution. A shell has been popped on Sharepoint, but does require SPBasePermissions.ManageLists permission in order to do.

Kaseya VSA is a monitoring and management software used by large corporations. As a result, compromising this product leads to complete control over a system. Security flaws used in this product were used for a massive ransomware campaign in the previous weeks.

The first vulnerability was an authentication bypass in the application. When logging in users, the default is set to true. So, when not providing a password (but a username), the application sends back true. The username is a long guid though; nobody is sure how the threat actors got a hold of this.

CSRF protections were not checked properly. Simply having a string of the proper length and format was enough to pass it off as legit. This was crucial when the attackers were uploading files to the server to execute later. Although there was a type check, the contents of the file were not being validated.

The final bug is an arbitrary file execution bug. When processing parsing the contents of a file, it is passed directory to eval in ASP.net for some reason. The idea was to interpret the value of the arguments from the file as literal code.

Gitpod is a service from Gitlab that allows for spinning up fresh, automated dev environments for each task in the cloud. You can login to Gitpod with your GitLab, GitHub, or Bitbucket account and then use a pretty full-blown, web-based development environment to work on your code, run tests, or even spin up services and expose them from your Gitpod instance to the internet.

Gitpod holds an OAuth token with full API access to all of the major Git hosting providers. Because of this, the author decided to take a look at the platform.

The product spins up a random workspace name. Once it has booted, all ports of tasks happen from exposed ports to many other things. The web-based IDE uses websockets to communicate with gitpod.io. Using a Cross-Origin WebSocket attack, it is possible to call the API on behalf of the other user. They made the call from another custom domain, which is why it's cross origin instead of cross site.