D-Link authentication.cgi bof

Hey Metasploit guys,

 I have tried to create some exploits out of the advisory by Roberto Paleari (http://roberto.greyhats.it/advisories/20130801-dlink-dir645.txt). This is the first Metasploit module for the vulnerability in authentication.cgi. The module for hedwig.cgi is also in the pipe. The vulnerability in post_login.xml looks for me that it is not directly exploitable from remote.

This device is a typical embedded router of dlink with some interesting constellations. ;)

First of all we have a quite big set of bad characters including \x0d which is part of the decoder stub. So I have played a bit with different registers and with the included code it is now possible to create a shellcode with the whole bad character set. The default settings do not change anything from the decoder ... 
But it does not really matter because the encoders are not working in combination with this devices. For me it looks like that we run into troubles with cache coherency and probably the system call for the context switch is not working correctly -> but this is just a guess ...

I have tried different payloads and encoder combinations. Also if I generate the payload manually and drop it as a binary to the target device, the payload crashes directly after the decoding stuff. The shellcode is correctly decoded but crashes on execution.

For getting the code execution to something useful I have modified the bind payload for MIPS-LE so that we have no bad characters in it. The new bind shell payload is included as shell_bind_tcp_mod.rb. The only modification was to change register t5 to t4:

    port.pack("C2") + "\x0c\x24" +  #     li      t4,0xFFFF (port)   ; t4: 0x5c11 (0x115c == 4444 (default LPORT))
    "\x04\x60\xcc\x01" + #     sllv    t4,t4,t6                      ; t4: 0x5c110000
    "\xfd\xff\x0e\x24" + #     li      t6,-3                         ; t6: -3
    "\x27\x70\xc0\x01" + #     nor     t6,t6,zero                    ; t6: 0x2
    "\x25\x60\x8e\x01" + #     or      t4,t4,t6                      ; t4: 0x5c110002
    "\xe0\xff\xac\xaf" + #     sw      t4,-32(sp)

Probably we are able to do some check for the encoder setting and the bad chars and can modify it on the fly?

The next thing is the exec shellcode that gets handled directly within the module. We have to remove the ending \x00 bytes and then it works good. The shellcode is directly embedded within a bunch of \x00 bytes. With this the command string gets terminated in a correct way. If we can include the changes in the bind shellcode we could probably remove this stuff completely.

Let me know what you think about it ... 

Thanks
Mike