This is the second and final post in our series about zero-day vulnerabilities we discovered in NfSen and AlienVault OSSIM. If you missed the first post, please click here to read about how our discovery of one zero-day vulnerability led to another three being discovered. As part of our responsible disclosure policy we contacted the vendors and assisted them with the process of developing patches.
In this post, we go into detail about the nature of the vulnerabilities from a more in-depth and technical perspective.
During an external penetration test for one of our clients, we encountered a Heartbleed vulnerability on an HTTPS server. The site was protected using HTTP Digest Authentication, and we successfully exploited Heartbleed to pull digest authentication details from memory.
We then converted the digest into a hash which could be cracked using a brute-force attack. The brute-force attack was a success, which resulted in discovery of the password.
Once we had obtained the password we were able to log into the website, which initially appeared to be empty, but further intelligence gathered using Heartbleed revealed requests to a hidden sub directory. Browsing to the hidden directory revealed an NfSen installation.
Once the Nfsen installation had been discovered, we mapped its code-paths and proceeded to test them all for security vulnerabilities. It was during this process that we noticed that characters submitted in the customfmt parameter to nfsen.php were echoed back to the browser window as part of what appeared to be command line parameters to an executable on the server.
This is known as a command injection vulnerability, because it is possible to take advantage of the functionality to inject arbitrary commands which are then executed on the system. As nfsen is known to run on Linux, we tried a simple "sleep" command which, if the command injection worked, would cause the server to delay by the specified number of seconds before providing a response.
The injection '; sleep 2 # was supplied, and indeed the server paused for a couple of seconds before responding.
Foregenix then leveraged this shell injection vulnerability to run commands such as "whoami" which caused the web browser to echo the name of the user that the injected commands are being executed as. The commands appeared to be being executed as the www-data user, rather than root, which should limit the level of compromise possible from this vulnerability.
We also injected the "cat /etc/passwd" command to get some insight into what other user accounts were present.
By this point it was very clear that we had discovered a zero-day command injection vulnerability in NfSen. We now needed to learn what risk it imposed on a system, in other words would we be able to elevate our level of access from the www-data user to a more privileged one.
With any vulnerability which can theoretically provide the potential for shell access it is usually desirable to find a way of making this happen, as it provides the most convenient way of further investigation and compromise. However, there are a number of pre-requisites required to achieve this. For example, a suitable command or tool must be accessible to the underlying operating system which can provide the shell functionality. Firewall rules must permit a third-party to connect to the shell, or the shell to connect to the third-party.
With this in mind, the first thing Foregenix checked was whether the NfSen web server had netcat installed. This tool provides one of the easiest ways of achieving a reverse shell, and a quick test showed that not only was it installed on the web server, but the "dangerous" features helpful to an attacker were available.
The presence of netcat was a helpful surprise, and we used it to trigger a reverse shell to our testing platform.
However, the biggest surprise came when the reverse shell connected to the Foregenix penetration testing platform, as it was a root shell!
This did not make sense after we had already determined that our commands were not being executed as root. We needed to determine the reason why this was happening in case it was due to another vulnerability.
The initial reverse shell that came back was root, however there was a slight complication as can be seen in the following screenshot. The reverse shell shown in the upper half of the image was spawned using sh as the shell, which appeared to be running as www-data. The reverse shell shown in the lower half the imagine was spawned using bash as the shell (also the case with the previous screenshot).
We initially wondered whether for some reason the bash binary was setuid root, but this was not the case. We then remembered that bash doesn’t use the same behaviour as many other linux commands (including sh) when it comes to your user id. Instead of simply using your effective user id like other commands do, bash will work with your actual user id. You can override this behaviour of bash and make is run like sh by using the -p switch.
So as setuid bash was not the cause, Foregenix conducted further investigation, including a partial code review of NfSen. The investigation showed that some NfSen Perl code failed to drop privileges correctly, meaning that one of the NfSen processes was running with an effective user id of www-data, whilst retaining an actual process id of root, allowing Foregenix to easily escalate privileges from www-data to root.
As part of this code review, Foregenix also discovered an additional command injection vulnerability which could be exploited either locally via a UNIX socket, or remotely using the same customfmt attack vector but with a slightly different payload. See the exploits on exploitdb for precise details of these.
NfSen is included in AlienVault’s OSSIM/USM product. The initial command injection vulnerability did not affect AlienVault OSSIM/USM, however all of the vulnerabilities arising from the code review did affect the AlienVault products, and Foregenix was able to gain root access on AlienVault systems from a remote authenticated attacker perspective.
Remote code execution. The “www-data” response masks the fact that the actual user is root
Foregenix number one priority is protecting our clients, which was a challenge in this case due to the lack of available fixes for these vulnerabilities. As such, Foregenix contacted the vendors as part of our responsible disclosure policy.
Foregenix then liaised with the developers, provided the required information and assistance to help them reproduce the issue and develop the necessary patches. Going the extra mile, our team also assisted in testing the patches. Testing was a success, and as a result, we were able to notify our client with the fix before the patches were publicly available. Subsequently, Foregenix released the CVE details so that other organisations could learn about the vulnerabilities and protect themselves.
We offer a range of penetration testing services to ensure your environment is as protected as it can be. Any exploits or vulnerabilities that we find in your security architecture are reported to you so that they can be addressed.
The associated CVE numbers and other references are as follows:
CVEs: CVE-2017-6970, CVE-2017-6971, CVE-2017-6972, CVE-2017-7175,
Exploit-DB:
https://www.exploit-db.com/exploits/42314 (CVE-2017-6972, CVE-2017-7175)
https://www.exploit-db.com/exploits/42305 (CVE-2017-6970)
https://www.exploit-db.com/exploits/42306 (CVE-2017-6971)
Vendor references:
https://sourceforge.net/p/nfsen/news/2017/01/nfsen-138-released---security-fix/
https://www.alienvault.com/forums/discussion/8698
https://www.alienvault.com/forums/discussion/8325