Hacking ActFax RAW Server

On February 6, 2013 Craig Freyman aka @cd1zz posted a blog entry regarding a bug he had discovered in ActFax Server. It makes for an interesting read and I highly recommend checking it out if you have not already done so.

I wanted to recreate the bug in my own environment, but for some reason I was not able to trigger a crash using the "@F506" command. I was however able to use the "@F000" command. I took a slightly different approach to get execution and thought I would share it with you. Keep in mind that Craig has already done all the heavy lifting. As mentioned in his post the bug has already been fixed so I had to search the interwebs for a previous version.

For this tutorial I am using windows XP SP3 and a vulnerable version of ActFax Server. I also configured the RAW Server to use port 5555. We start our journey by firing up Immunity and opening the ActFax application. Having already determined the command that would trigger a crash, I used the following script to send a string containing 2500 characters. This pattern was created using mona.py as shown:

Sending that string produced a crash that resulted in our registers looking like this:

We can see that we have two registers that contain parts of our buffer. That's good. We are now only a few steps away from world domination. Our next step is to figure out which bytes overwrite EIP. For this we again turn to mona.py and use the pattern_offset command as shown:

Of course if you wanted to, you could also use the pattern_create and pattern_offset scripts from the metasploit framework. The scripts are located in the tools directory.

To ensure that we have identified the correct bytes, we modify our script and resend our buffer. When we generate the crash we should see EIP being overwritten with four B's(HEX \x42). And that is indeed what we see. Life is good!!!

At this stage our registers look like this:

Our next step is to get to one of the registers under our control. In this case we will access ESP. As Craig mentioned, there are a lot of bad chars to contend with. After a bit of searching I used the JMP ESP command  in the WINMM.dll at memory address 76B43ADC.

This jump will take us into our C's. However we only have approx. 440 bytes to place our shellcode. This is not enough space to place anything meaningful. We will therefore use this limited space as a jump off point to get to a larger space i.e. our A's.

We can do this by using a technique developed by Aaron Adams and published in the Phrack magazine article 7. The script I used can be found here. Aaron essentially uses some floating point calculations to determine the position of EIP and then copies it into ECX. Once that is done we can decrease/increase ECX as required in order to achieve our goals. On a side note I hope to be as good this guy one day. Now back to our regular programming. The jump took me back approx. 1000+ bytes which is more than enough space for our payload.

But wait there is a problem and that problem is bad chars.  To get around this restriction we need to encode our script. I took the following steps to accomplish that :

1. Save the script to a file with a .bin extension. I called it stackjmp.bin
2. Compile with nasm using: nasm stackjmp.bin -o stackjmp
3. Use msfencode to encode stackjmp. Remember we need to filter bad chars.  msfencode -i stackjmp -e x86/alpha_mixed -b "\x40"

At this point you should have something resembling this:

If you look carefully you will see that the highlighted section is the start of our decoded shellcode. At this point we are pretty much done. We simply generate our payload, in this case I used a bind shell. Again, remember we need to encode our payload. 

And we have our shell:

The final code can be found here.

As mentioned at the start most if not all the heavy lifting was done by Craig Freyman. He figured out the protocol in use and fuzzed the application etc. I just wanted to see if I could get shell.........