I've been fuzzing ALOT of FTP servers lately. I found a PASS buffer overflow in the Golden FTP 4.70 server and recently had it published to exploit-db.
At first I thought this was just a DOS but then a collegue of mine, Gerardo Iglesias Galvan took a closer look and saw that EIP was being overwritten as well as ESI and ECX. We noticed strange behavior when different buffer lengths were used. By adding some NOPS + shellcode + extrapadding NOPS + EIP, we could control execution flow. We're utilizing a JMP ESI for the EIP address.
Here is where it got confusing. Our exploit was unreliable. My collegue was testing the one I developed his test environment and it wasn't working. I tested his exploit and it would not work on my network. We also had the offsec guys try but they couldn't reproduce it either. If I was a reverse engineer, I probably could have just figured out why this was happening, but I am not :) I noticed that if the subnet the FTP server was running on changed, the exploit would fail. It seems the offsets were changing with different subnets. I went through and manually figured out the offset for 4 different subnets. They were all just slightly different. I'm still not sure why the app does this, maybe someone can let me know?
Also, for this exploit to work, the option "show new connections" HAS to be set in the application. You can find this under the Options button in Golden FTP. It should also be noted that failed exploit attempts usually DOS the service. I didn't test if this works with the paid version or not, all my testing was done on the free version.
@bannedit ported our exploit to Metasploit yesterday. His version is certainly much more elegant than the one we did. He managed to figure out how to make it reliable with this little piece of code here:
if datastore['RHOST'].length < 15
pad = make_nops(1) * (15 - datastore['RHOST'].length)
The IP address is 15 bytes long, including the dots. IE 192.168.100.1 = 13 bytes so 15 -13 = 2 more nops. We did all the work for him but failed to see the pattern! Oh well, at least it is in the framework now!