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!

This article dives into the Schneider Electric Modicon Programmable Logic Controller (PLC).

Modbus is the standard for controlling PLCs in SCADA systems/ Modbus was designed in 1979, prior to people caring about security. The most widely used version of Modbus goes over IP (Modbus/TCP standard). Modicon chose to extend the Modbus implementation under a reserved Modbus function code with the UMAS.

UMAS reimplements the Modbus protocol but adds essential functionality for modern tech. In particular, binary data transfer, authentication, firmware updates and several other things were added. UMAS has several commands that require chains of proper commands; this is done with a reservation.

The reservation mechanism was created to synchronize modifications of the PLC’s program; this is a form of global locking over the entire system. Once a station had reserved something, a one-byte token was used to perform further modifications, but only if the PLC is modified.

The reservation had an issue though: this reservation used a hardcoded secret between software for the challenge-response method. As a result, enhanced reservation was created. The new version used an authentication method with a challenge-response way with a dynamically set password. Wow, that's a lot of background!

The first vulnerability is an authentication bypass. From reversing the firmware, they found a plethora of undocumented commands. One of these commands allowed for reading any address in physical memory with no auth. As a result, the hash of the application password could be stolen. This device can even be used to crash the device with bad address reads.

The authors of the article decided to understand the flow of the auth process. When an incorrect password was typed the software rejected the password without generating any traffic with the PLC. But how is this possible?

Prior to the reservations, a call to read the password hash from memory was done! Then, this hash is validated locally with the entered password. This is an obvious flaw with the authentication flow; an attacker can brute force the hash offline. So, this attack was successful TWICE.

The command WritePhysicalAddress allows for writing to any physical memory. Using this, they could get code execution by altering many different places in memory.

The command PrivateMessage allows for the calling of internal functions on the PLC by accessing C++ objects. This can be exploited by writing to somewhere in memory with the BlockWrite command. Then, referencing this object makes it easy to control the PC to pop a shell.

This article has nice pictures on what the modbus and UMAS protocols look like and great docs on the exploitation of this. The bugs for this were unique and worth the read. Great research!

A list of all things Linux kernel hacking. The list of items is pretty lit!

• Techniques and protection bypasses
• Vulnerabilities. They are divided into info leaks, local privilege escalation and RCE.
• Finding bugs in the Linux kernel.
• Defensive actions in the Linux kernel.
• Exploits
• Tooling
• CTF/workshops

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.