socat is a general-purpose networking tool that allows the creation of two bidirectional streams. It has a large amount of support for different protocols and data sources, including OPENSSL, SOCKS4, TCP, UDP, TAP, SCTP and more. When performing a penetration test this tool can be leveraged to bypass basic firewall restrictions and transfer files across the network.
Statically compiled socat
There is a cool project called static-toolbox which provides statically compiled networking and debugging tools. This project includes a statically compiled versions of socat for x86/x86_64 and allows the tool to have a lot more portability between differing Linux distributions and major library versions for a small cost of ~2MB.
Simple Listening Shell
On the client run:
On the attacker machine run
This shell works great, but there are two obvious problems:
We can get around this by using the outbound technique that I will show later.
Simple File Transfer
There are two methods of doing file transfers:
Overall, the better of these two methods is when a client connects to a listening port to download a file, as this is less likely to be blocked by firewalls. To do this you need to run these two commands.
On the attacker:
On the client:
Encrypted Listening Shell
We can generate an encrypted reverse shell with client and server keys to allow only our chosen attacker machine to connect to the server.
socat reverse shell
Sometimes the network will be configured in such a way that only certain ports will be able to host a listening service, such as 80 and 443 on a web host for example. In this case, unless we have sudo privileges, establishing a listening shell with socat is not possible. To mitigate this we can instead forward a shell or service through an outbound connection. We can also establish a PTY shell in a similar fashion
On the attacker machine run:
On the client run:
Forwarding a service through an outbound connection Sometimes we want to be able to access a local service on the machine, for example if we want to access the SSH service running on our host we need to be able to use the ssh command or to be able to use our browser to interact with a local web server. We can achieve this by instead creating a second listening port on the attacker machine that will allows our different programs to connect and interact with the client's service. On the attacker machine we create two listening ports, it will wait for a connection from our client on port 80 and then wait for a suitable
On the client run:
This will allow you to connect to the service (In this case SSH) by connecting to local port 10023.
socat encrypted reverse shell
On the attacker machine we create a listening port, it will wait for a connection from our client on port 80 and then allow us to interact with it from stdin.
On the client machine we need to run:
Forwarding a service through an encrypted outbound connection
After following the key generation steps listed in the encrypted reverse shell section we can wrap our outbound reverse shell in openssl using the following commands.
On the attacker machine we need to run:
On the client machine we need to run:
Finally, we can create a connection by running the final connect command on the attacker machine.
Forwarding packets through a web proxy with socat
Sometimes a service or program will not allow the user to set a HTTP proxy. For example, if you wanted to inspect the HTTP connections a browser is making but the proxy settings are broken. The command to do so follows the general form:
In your browser you would point to
Recently Clément Labro released a blog post about an arbitrary file move vulnerability he discovered. This was CVE-2020-0668 which involved abusing Service Tracing to cause an arbitrary file move with the help of symlinks.
I confirmed the vulnerability using the Google Project Zero symboliclink-testing-tools but wanted to create a standalone executable, that could be easily shipped to a target machine to exploit the CVE. C# seemed like an appropriate language as I could leverage the NtApiDotNet package which had done all the hard work for me.
Writing the code was as simple as following the instructions in the blog post and making sure I understand the mount point and symbolic link trickery. Luckily this has been described by James Forshare in a number of blog posts, and implemented in his API methods NtFile.CreateMountPoint and NtSymbolicLink.Create. The complete proof of concept code can be found on GitHub here.
This post explores how an ASP.NET project incorrectly disclosing its web.config containing static keys allows for remote code execution. The common cases for exploiting this vulnerability would be if the web application has published it’s static machine keys to GitHub, such as with the example project for this post (https://github.com/ozajay0207/EGVC) or if the application has a local file inclusion vulnerability that allows the attacker to obtain a copy of the static keys from the web.config file.
In order to keep track of different sessions, ASP.NET applications use a ViewState that contains serialized application defined data. Due to the nature of serialization, if the user can control and create a valid ViewState, then they can use a deserialization attack to achieve remote code execution on the host.
In order to mitigate this potential attack ASP.NET applications can perform HMAC signing of the ViewState to verify the authenticity of the object. Another option is using encryption with a secret key to prevent reading or modification of its contents. Keeping these keys secret is paramount in preventing ViewState deserialization attacks and remote code execution.
These mitigations rely on each application utilising uniquely generated validation and decryption keys, which is not always the case. Recently, CVE-2020-688 exposed Microsoft for including static validation and decryption keys in the Microsoft Exchange Server’s control panel. The same keys were generated once and shared among every exchange installation allowing anyone with a copy of the server to recover and misuse these key values.
To demonstrate this attack, a proof of concept will be performed for a public GitHub project that contained this vulnerability. Figure 1 is the web.config from the chosen project and contains two security issues. Firstly, the validation and decryption key are hard coded and secondly, the ViewState encryption mode has been disabled.
A successful attack requires not only the validation key, but also a page on the website that uses a ViewState. In this case the website has a registration page that includes various text entries and controls; a perfect candidate for using ViewState. In the registration page’s source code there are two hidden elements that include the page’s ViewState and ViewState Generator.
Now that the three required pieces of information have been recovered, a payload can be generated using ysoserial.net. The malicious payload will execute an arbitrary command, in this case a simple PowerShell web request to a controlled endpoint, is used so that the code execution can be verified.
The tool ysoserial.net creates a payload that is base64 encoded but supplying this directly to the server in a request will cause parsing errors. This occurs because the base64 standard includes some symbols, such as the equals sign, that will be misinterpreted in a HTTP request. To remedy this the payload must be URL encoded. With this encoding the necessary symbols will be correctly interpreted by the ASP application.
To perform the attack the default packet HTTP POST from the registration form was captured into BurpSuite, and the __VIEWSTATE variable was replaced with the malicious ViewState generated by ysoserial.net. Once the request is sent to the server the PowerShell command is executed, and a corresponding GET request is made to our controlled endpoint.
From here it is straightforward for an attacker to modify the command to download and execute a malicious PowerShell script and create a reverse shell.