While performing an internal security assessment for a client, I discovered an OS command injection vulnerability in an Infoblox NetMRI appliance. This was totally by accident, just going about our regular testing of web applications. I stumbled across the following page and used a proxy to submit values to the “Username” and “Password” fields of the application.
Infoblox Login Page
Part of our testing includes that for blind command injection, in which the ‘ping -n 20 127.0.0.1’ command is sent in place of every GET or POST variable, as well as some HTTP headers.
Injecting a command to ping localhost 20 times
When command injection is present, the HTTP response to the above will be delayed while 20 pings are sent to localhost. In this case the response took 22 seconds. The next command injected the same ping, but substituted with my internal IP address.
Injecting command to ping my attack workstationI then started a tcpdump session to listen for pings from the target IP address. When we received them it proved that the command injection was genuine.
Ordinarily, I would have spent the next bit of time interrogating the target, determining what user I was running as, group membership, etc. But, in this particular instance, I tried adding a user, and setting a password. If the web server was running as any user other than root this would fail.
Injecting a “useradd” command
Setting a Password
I then attempted to connect via SSH with my newly created username and password, to my surprise I was given a shell.
My next step was adding my user to the wheel group, so I could use sudo. I simply injected a usermod command to accomplish that.
Adding the user account to the “wheel” group.
After my user was a member of the wheel group, I used sudo to get a root shell.
root shell.
After getting a root shell, I went poking around discovering that the underlying OS is Fedora Core. But I also discovered a local mysql database instance. I was able to connect to this with the username “root” and a password of “root” And that weak set of credentials represents CVE-2014-3419, however this is only possible if you have a shell on the appliance already.
After getting this far, in less than 24 hours I had a crash course in ruby and wrote a metasploit module. The module was tested against NetMRI 6.8.2.11.
https://github.com/depthsecurity/NetMRI-2014-3418
Infoblox immediately released a hotfix on 5/16/2014 to remediate this vulnerability on existing installations, (v6.X-NETMRI-20710.gpg).
The flaw was corrected in the 6.8.5 release (created expressly for dealing with this issue), and that release has been put into manufacturing for new appliances.