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!
Four Bytes of Power: exploiting CVE-2021-26708 in the Linux kernel
Alexander Popov - Positive Technologies Reference →Posted 4 Years Ago- While fuzzing the Linux kernel with syskaller, the author of this post got a suspicious kernel crash within some socket handling code. Unable to reproduce the crash, the author read some source code until they found a strange code pattern.
- The consistent pattern was an issue with locking. Prior to a socket lock a heap pointer was dereferenced and put into a variable. The code is shown below:
struct sock *sk; struct vsock_sock *vsk; const struct vsock_transport *transport; /* ... */ sk = sock->sk; vsk = vsock_sk(sk); transport = vsk->transport; lock_sock(sk); - Notice that the
transportvariable is dereferenced fromvskthen the lock occurs on this. If the value oftransportwere to change prior to the lock, then we have a race condition! - To trigger the race condition two threads are required. First, one thread (thread #1) should try to set socket options. The second thread (thread #2) needs to connect with a virtual socket. When thread #1 attempts to access the virtual socket, thread #2 has already taken the lock. However, the
transport - Now that thread #2 has the lock, it can force the altering of the
transportstruct. The transport constructor can be called, which frees the object and creates a UAF. This UAF is a 4 byte user controlled write at offset 40. Does not seem that deadly but itself! - This same pattern for the handling of sockets was found in a total of 5 places. Although the bugs were not there to begin with, they were created by misunderstanding the original intention of the code.
- With a 4 byte UAF, the next step is to fill this freed memory with something important to corrupt. Finding a candidate object to fill required a significant amount of effort. Eventually, this led the author to corrupting an SELinux security pointer to allow for an arbitrary free primitive.
- When the initial race condition succeeds, it creates a warning message because of a value being NULL that is unexpected. This error message is dumped to
/dev/kmsgwhich leaks kernel memory. So, now, we know if the race was won and have a memory leak! - With the arbitrary free and the memory leak, the next step is to create an arbitrary read primitive. This was done by altering the
msg_msgstruct in order to map to kernel data to be read. This required some crazy feng shui for this code to not crash however. All of the necessary pointers are not acquired! - The arbitrary write is done by altering a network related buffer called
sk_buff. First, hit the arbitrary free on thesk_buffkernel address. Then, when a user controlled object slips into there a function pointer is overwritten! - With code execution, one would think this would be easy... but, the author could not find a proper pivoting gadget for the system. So, they created a single WRITE that would overwrite the location of uid and guid to be 0s. With this, privileges of the current process are escalated to root!
- The author adds some tips for how this cold have been mitigated:
- SLAB_QUARANTINE would have made this impossible to get the same piece of memory back from the race condition. Hence, the UAF is not possible to exploit.
- The Dmesg having a stricter log would have prevented the kernel leak.
- MODHarden by grsecurity prevent kernel module autoloading by lower privileged users.
- Binary protections: Control Flow Integrity (CFI) would have prevented the the ROP gadget. Then, Memory Tagging would have prevented the UAF altogether.
- I'm not too deep into the Linux kernel exploitation scene. However, this article has several tricks (and references to others) that could be used in future exploits. I personally enjoyed the bug explanation and the general plan of exploitation a lot.
Allow arbitrary URLs, expect arbitrary code execution
Positive Security - Fabian Braunlein & Lukas Euler Reference →Posted 4 Years Ago- URLs are a magically way to reference a resource or an application. The most common type of URL that we seen is the https URL. However, what if these could be used in a malicious way? This article demonstrates how a link that does not validate the schema of a URL could lead to code execution.
- OSes commonly handle links for us. With different URI handlers, they can do different things on the computer for us. Desktop application like to go to the specified links for us. On Windows, this is commonly done via the
ShellExecute; on Linux, this is done withxdg-open. If these do not sanitize the input, code execution may result. - The author goes into how to exploit these issues per platform. However, instead of discussing each of the OSes, we'll talk about the individual issues that were being exploited.
- The NextCloud Desktop client was using
openURLfor the native OS in order to open up the proper data. However, because the URLs were not sanitized at all, this left open the possibility for exploitation. How would one go about this? - On Windows and Linux, using the
sftp(secure ftp) URI, an attacker could embed a proxy telnet command which would run on the users machine when clicked on. Additionally, usingSMBto load arbitrary jar files could also work. On the Telegram Desktop client, a similar issue as the one above was found that allowed for the same exploitation path. - On VLC, if a user loads a malicious playlist on their local machine, clicking on the links can be a security issue. When a
jar(compiled Java code) is loaded on Windows, this leads to RCE. By specifying a remote file (with two leading slashes - \\) or a file URI path, this runs user code. On Linux, the lack of an auto mount feature makes this not possible for remote exploitation. - On Libre Office, clicking on a link could be abused on both Windows and multiple versions of Linux in order to execute arbitrary commands. As before, this auto-mounts a file to the local machine then executes the jar file.
- The last several findings are all the same. Click on a malicious link and pop a shell within the client. The last few are in A similar issue exists with Mumble, Bitcoin/Dodgecoin wallet and Wireshark.
- The bonus vulnerability is an issue with WinSCP though. By creating a specially crafted
winscpURL, it will pop a shell! WinSCP decided that this was a security issue and fixed it. - A couple things should be noted about this article. First, in order to exploit these issues specific software sometimes needs to be installed (such as WinSCP). Secondly, these does require some user interaction in most cases.
- Overall, awesome article diving into the world of bad URL links. In the future, I'll be on the look out for this!
- Cockpit is a headless CMS that takes an API-first approach. Think of Wordpress but API driven and not as popular.
- The first vulnerability is a NoSQL injection in the
/auth/checkAPI. A parameter is taken in directly without any type check. So, by adding an array or other options, NoSQL conditionals and things can be used. This is a blind injection, as no data is directly returned. - The author discusses an error driven approach to steal users and other data from the table. Additionally, using a not-so well-known MongoDB function
$funccan be used to return data, such as avar_dump. - Two other NoSQL injections were found in the
/auth/resetpasswordand/auth/newpasswordAPIs. By using thevar_dumpfrom the previous step, we can dump all data from this table. Because this contains active password reset tokens, this is game over. - To compromise the account, we will combine the previous steps. First, use the first NoSQL injection to leak all of the users. Then, reset one of these users passwords. From there, use the auth endpoints NoSQL to get the token parameter for resetting passwords. Now, we have access to the hashed password, API key for the user or can reset their account password.
- With the auth bypass, we want to pop a shell. As with a lot of PHP-based CMS platforms, simply uploading a WebShell via a file uploader can be done.
- An additionally RCE bug exists that happens when concatenating strings for custom PHP code being executed. Don't do this!
- This is an interesting article on exploiting NoSQL injection in the wild. Although this is a possibility, it is rarely discussed as an actual finding. Good to see actual exploitation and tricks for this.
Royal Flush: Privilege Escalation Vulnerability in Azure Functions
Intezer - Paul Litvak Reference →Posted 4 Years Ago- Azure functions are a way to run arbitrary code within the context of Azure. Another example of this is Llambda functions.
- The Azure functions run within a Docker container with the
--privileged flagto allow extra permissions. For the purposes of this article, this causes device files (/dev) be be shared between the host and the guest. - All of the file systems in the
/devdirectory had the permissions set to rw as the guest user. This means that any user (including the Docker user) could edit these file systems. - To escape the container, the obvious choice was to edit the file system. Using the
debugfsutility, we can commit changes to the underlying disk. Being able to write to disk is a HUGE deal, as we could overwrite all files on the OS, such as /etc/passwd. - There was one issue that they had to get around though: caching. The Linux kernel hosts a read cache for pages that had been recently loaded into memory instead of reading the raw disk every time. This resulted in raw disk writes not being noticed.
- In order to get around this, they used the
posix_fadviseto tell the kernel to discard the cache. Now, when the /etc/passwd was read again, it would be the proper one! - Although this container escape is pretty awesome, Azure functions run in a HyperV guest and a Docker container. Being able to escape one of them is not enough to compromise the Azure functions infrastructure, sadly. Defense-in-depth!
- DuckDuckGo is a privacy oriented search engine. Because of this, security bugs are a big deal.
- A researcher accidentally found an HTML injection bug while looking at search results for Urban Dictionary. The content of a header was being injected into the page as raw HTML.
- This is a dead-simple XSS; the payload is even extremely simple. However, the interesting part is WHERE the payload came from. Sometimes, the avenue of the attack is the most important part.
- Keeping track of the time is a complicated task. This is why Domain time II was created, which is the target of this blog post.
- Man-in-the-Middle (MitM) is an attacker where can attacker can inspect and control the communication flow. In a variant of the attack, known as Man-on-the-Side (MotS), an attacker can inspect traffic (not control) and can respond to the traffic they can see. This is a much easier position to get than MitM.
- The Desktop application has an automatic upgrade feature. To know where it needs to update or not, it reaches out with a UDP request over plaintext. Then, if the response to this contains a URL then a diagram will open instructing a user to download the new software.
- The issue is that UDP is stateless. So, if an attacker can see this request happening, they can respond with their own message. Within this message, they can have their own URL that will then be used for an upgrade.
- The normal use-case for this application is to be running on a Domain Controller. With a privileged network position, this could be a devastating attack.
- I am assuming that the product is not signed? Because, if the product was not signed, then the fake application would not work on the automatic installation. In the demonstration, the user must run an executable.
- Overall, the MotS is not something that I have ever considered before! Even in 2021, we need to remember that encryption is mandatory in order to prevent these types of attacks.
Remote exploitation of a man-in-the-disk vulnerability in WhatsApp (CVE-2021-24027)
Chariton Karamitas Reference →Posted 4 Years Ago- WhatsApp is a common messaging application used across the world. Because everyone stores data on their phones, compromising the content of a phone is massively impactful. This particular discusses a round-about-way to compromise WhatsApp.
- In Android, Content Providers are an IPC mechanism to share resources with other applications. For instance, this is can WhatsApp load a picture from Google Drive. Modern Android devices have Content Providers for SMS, MMS and many other pieces of information.
- The
sdcardis a special Content Provider that is accessible by any application at any time. It is used by ALL applications and considered an insecure place to put data. Thecontent://URI is a way to access the content provider data via a URL. This is supported within the chrome browser even! - The Same Origin Policy (SOP) dictates that content that JavaScript can access. If the protocol, domain or port is different, then it is consider a With local files, SOP is more restrictive; each path is considered its own origin.
- On Android for Chrome, this protection is NOT implemented though. So, data loaded from one page can be used to access any data under
/sdcard/Android. With devices NOT running scoped storage per app, this is a serious vulnerability. - Although this is a Chrome vulnerability, it has direct impact on WhatsApp; just click a link in WhatsApp! WhatsApp stores TLS session information within the
/sdcarddirectory. By using the Chrome vulnerability, an attacker can steal the Pre Shared Key (PSK) for TLS 1.3 and steal the Master Secret on TLS 1.2. By stealing these secrets, WhatsApp can be MitM'ed even when the application believes it is being done securely. - This scoping issue is NOT just possible to exploit from Chrome via the
contentURI. Another application could have done this in order to snoop on the E2E traffic. With a MitM position (assumed throughout this article) and the TLS secrets leaked, the next step is to get code execution. - When a user gets a photo filter or doodle emoji on WhatsApp, the content is delivered through a zip file with a specific name. When the zip file is being extracted, it does not sanitize the name for directory traversal bugs. So, if this process can be hijacked, we have an arbitrary file write vulnerability.
- The WhatsApp client stores its DSO (dynamic shared objects) libraries within the
datadirectory. So, simply overwriting one of these libraries (such asSoLoader) is sufficient. With control over a library, this is game over. - An additional vulnerability was found though. WhatsApp uses end-to-end encryption (E2E) by using the Noise protocol. Being able to steal the Noise protocol keys would allow for the complete compromise of the communication via a MitM.
- When WhatsApp encounters an
OutOfMemoryErrorwithin the first few days of a release, the entire application heap is sent to a WhatsApp server for debugging. Guess what is in this heap!? Noise keys! - By purposely inducing a MemoryError by sending a VERY large response to a request, this data is sent over the network... leaking the keys!
- The WhatsApp issues appear to be unexploitable because the data is normally controlled by the server. However, the MitM breaks this assumption it makes the directory traversal possible.
- Additionally, the addition of the defense-in-depth measure of isolated
sdcarddirectories make this vulnerability much less impactful. So, good job Android!
- The power meters at our houses are not simple technology. In fact, they create an extremely large mesh network that eventually communicates with power company routers. This project is all about reverse engineering these power meters and understanding how they work. I'll include my personal notes for this technology in this thread.
- The protocol can be seen at Recessim. The meter data includes the packet types, WAN address, counter, LAN address, date/time, checksum and other information. This is constantly being sent out from our power meters. This is an amazing resource for understanding how the protocol works.
- Some other researchers built a GnuRadio build for this as well. This allows for the reading of the data in a nice readable format! If you wanted, you can probably send these out as well but this is likely illegal.
- The wiki page has pictures of several different meters as well. There is a chain of videos about the smart meters. From hardware modifications to reduce the power to protocol analysis. Overall, lots of great resource for protocol reverse engineering, hardware hacking and SDR.
- To reduce the power of the meter, the author in the video gets the datasheet to understand what is going on. By grounding one of the wires on the main RF module, the power amplifier is turned off. This took a few tries to do properly but the hacker did not give up! This strategy works but a more powerful Faraday would have worked as well.
- The power company can remotely turn off the power of your house. Once this has been triggered, a hardware switch is triggered that opens up the connection to prevent the power from coming in. It may be possible to just break this switch and prevent the ability to remotely turn off the power.
Cisco RV34X Series – Authentication Bypass and Remote Command Execution
IoT Inspector Reference →Posted 4 Years Ago- This router used to have NO authentication on the file upload functionality on
upload.cgi. So, upon fixing this, everything appeared to be okay... - However, the Nginx configuration literally just checks that the authorization header is not NULL. So, passes in any authorization header works just fine. Now, there is an authorization bypass in the file upload functionality. Sometimes, bugs are that easy!
- The cookies field has a command injection when making a call to cURL. So, crafting a malicious cookie (without semi-colons) combined with the authentication bypass above allows for remote compromise of the device. Easy!
- Windows 10 added support for application containerization. It is quite similar to how containerization is done on Linux but wild different. While Docker on Windows works quite well, the implementation details for containers are abstracted away and not well-documented (besides onMSDN. This article is an overview of Windows containerization primitives and four bugs found along the way.
- The goal of containers is to hide the real OS from the application. On Windows, the Server Silo is allows the redirection of resources such as the object manager, registry and networking. This is a special type of Job object.
- There are two types of containers on Windows: Windows Server Containers and Hyper-V Isolated Containers. The difference is that the Hyper-V version runs in a lightweight VM under the hypervisor. The current specs say that only the Hyper-V container type has security promises, even though they are both containers.
- The author wanted to crate their own container and understand what was going on. Luckily, Microsoft has a simple Go client and Windows Docker images are existing as well. After setting up a nice testing environment, it was time to find some vulns!
- As the ContainerUser, the author wanted to see the permissions of this user. Although the groups did not seem interesting, the user had the SeImpersonatePrivilege! This permission allows this user to become any other user, including admin. This is a good (even bad?) start to the research.
- The second bug was a registry key issue. By using relative opens for registries, it was ignoring the registry overlays. So, a non-administrative user could access user keys on the host if the user can pass the access key check.
- Another issue was found with the registry keys and symbolic links. When accessing a symbolic link in a hive (grouping of registry keys), a kernel component should reject using the symbolic link or verify the ownership of the location. However, the function
PsIsCurrentThreadInServerSilowill essentially always return TRUE. This appears to be something done in the testing phase that was never fixed. - Using the above bug, an attacker can use a kernel component to write to an arbitrary registry key. This could be used to escalate permissions within the container to cause major damage.
- The final bug results from a discrepancy between application and server silos. With Linux, the syscall
chrootcan change the root directory for a user. In Windows land, a similar concept can be used to isolate an object manager namespace for users. - When attempting to find the right silo for the container, it does NOT validate which type of silo it is. Because an application silo can be created by any user, this is really bad. In order to perform this attack, simple create an application silo and assign this silo to a process. Now, the silo manager will use this malicious silo as if it was on the host machine.
- Because the namespace has been put onto the actual root location, data can be accessed on the host through the object manager. Damn, such a simple mistake led to such a horrible outcome!
- Putting all of these bugs together, it is possible to write content to the root of the hosts system drive. In particular, James uses the impersonation bug with the namespace bug to write to the host OS.
