In this article we are going to try to analyse the functionality of this framework (fuzzbunch) and we're going to look at a little vulnerability inside the framework.
We are going to use a couple different debugging tools in order to trace the execution and analyse it's important parts in the code itself.
Debugging the Launcher
Fuzzbunch is the mini-framework written in python, Basically, this framework launches different types of binary modules. Examples include payloads such as DoublePulsar or exploits such as EternalBlue.
For Fuzzbunch, we will use the pdb module that will let us get an interactive console up and running. With this we will be able to consult the state of the variables and/or modify them. The line for that is:
when the line is finally executed, the Pdb interactive console will start running. Some of the most used commands are:
- list: shows in which line of code we are currently executing
- next and step: to run the line we are on with the difference being that next stops on the following line. step stops inside a called function.
- continue: to continue the execution normally
We can also put in python code to inspect the variable. An example (image below) is the normal flow was interrupted in the "main" of fuzzbunch:
The variables marked in yellow correspond to different directories in fuzzbunch. The method, setup_and_run creates an instance of the object FuzzBunch that is an object inherited from Cmd used to create interactives consoles (similar in style to gdb or metasploit).
Looking at the builder we can see that a xml configuration file is being used to upload the startup environment:
a bit lower it evaluates one of the fields of the xml file to save a boolean value:
As a default it sets the True value, so when we do the evaluation, we are able to access the enablecolor variable: Instead of true/false value, it's possible to inject python code so that it delivers us a reverse shell.
When we run framework, the previous line is evaluated and and it delivers a console with the same privileges of the attacker that is running the modules:
It's pretty strange that eval is used from a configuration file to set variable. When you look at it, you can tell that they were thinking more about ease of development without paying a huge amount of attention to the security aspect.
This should get everyone pretty excited if they are trying to find errors in these tools!
Debugging the Module
fuzzbunch runs the binary and waits a maximum of 45 seconds so that the binary establishes communication through an IPC. In case you reach the timeout, the framework throws up a message error in the IPC channel.
CONNECT_TIMEOUT_SECS is defined a couple lines above
To analyze this, we have to modify the binary with a loop in the EntryPoint and we need to increase the seconds for the Timeout to a value that lets us look at it with the environment running.
The EntryPoint is overwritten with an infinite loop, allowing us to sleep the process allowing us to attach ourselves.
Now we only need to run the module, attach the process with a debugger such as OllyDBG o x32dbg and we are able to restore the original bytes of the process
Keep in mind that fuzzbunch runs the process two times. The first time to verify that everything works correctly with the parameter --ValidateOnly and the second runs the exploit
If your goal is find crucial parts of the program, such as the state of the backdoor or the delivery of the exploit, we are able to stop it from running in TcLog that is a function that prints all the texts that are on the screen.
We can also see in send and recv that the use of these functions is to deliver packets.
All the tips we mentioned should work with any module that has the framework.
Ping to the Backdoor
One of the verifications that the module does before triggering the vulnerability is to see if the machine was compromised. To do this it sends a SMB packet and in the base to response recognized if it is or isn't infected. Additionally, it lets you send the status of the backdoor DoublePulsar
This information comes inside one of the packets that were sent. The important field is 51h that is marked in the picture:
the options are:
- 00h means that the machine isn't compromised (yet)
- 51h means the agent is already installed and operating
- 61h 71h 81h y 91h are messages of the state, such as, ''Bad transaction" or "Invalid transaction Param"
It's important to mention that there are already modules in different tools such as nmap or metasploit to check to see if a machine was compromised.
Javier Aguinaga, German Riera y Ezequiel Tavella
(Infobyte Security Research Team)
(Infobyte Security )