I work in a large organization and I have set up a number of jumpbox solutions within our secure intranet. In order to move forward to production, our IT security staff have run Foundstone scan reports.
The reports have identified a number of high, medium, and low vulnerabilities that touch on the Operating system, Apache, and the particular software (e.g. phpBB, Drupal, Gallery, etc). I was wondering if the Jumpbox staff have run similar scans to determine if any vulnerabilities appear prior to releaing various versions of a given product?
Foundstone Scan Vulnerabilities Identified
Hello,
I am not familiar with Foundstone and we do not run a tool on the JumpBoxes at this point though I think eventually we will. I think this breaks down into two areas of concern: the application and not the application.
First off, we build a new JumpBox every time an application is released and we do NOT modify the applications in any way. So, if a scan of this sort is sophisticated enough to detect problems with the applications themselves JumpBox wouldn't necessarily be the party to fix them. In those cases either you could report the issues to the application developers directly or you can report them to me and I will evaluate them and then report what seems appropriate to them.
If there are non application concerns I imagine they include things like:
If it reports application type problems on the admin portal on port 3000, I would be happy to know and evaluate those since that IS software we write.
Also, if this is free tool that I could run myself, I would be interested in trying it. I have googled it and came up with this giant list, are any of these what you are using? http://www.foundstone.com/us/resources-free-tools.asp
Thanks for contacting us, if you want to share the results you can email me directly at godber@jumpbox.com
Austin
Vulnerabilities
Austin -
Thanks for your quick reply. I will send you an email. For the benefit of anyone reading the forum thread, I will try to sanitize the results and post them.
Vulnerabilities continued
For those interested in this thread, I have set up Drupal, Gallery, phpBB, and MediaWiki on one box using VMWare bare metal. The Foundstone scans came back with 3 high level vulnerabilities, 4 medium level vulnerabilities and 7 low level vulnerabilities.
One vulnerability, rated high, is called the TLS / SSL Man-In-The-Middle Renegotiation Vulnerability. It was identified in VM set ups that I had
for Linux 2.6.x associated with phpBB, MediaWiki, Gallery, and Drupal6. Description: TLS 1.0 (and higher) and SSL 3.0 (and higher) are vulnerable to man-in-the-middle style attacks.
Observation:TLS 1.0 (and higher) and SSL 3.0 (and higher) are vulnerable to man-in-the-middle style attacks. The TLS protocol, and the SSL protocol 3.0 and possibly earlier, as used in Microsoft Internet Information Services (IIS) 7.0, mod_ssl
in the Apache HTTP Server 2.2.14 and earlier, OpenSSL before 0.9.8l, GnuTLS 2.8.5 and earlier, Mozilla Network Security Services (NSS) 3.12.4 and earlier, and other products, does not properly associate renegotiation handshakes with an existing connection, which allows man-in-the-middle attackers to insert data into HTTPS sessions, and possibly other types of sessions protected by TLS or SSL, by sending an unauthenticated request that is processed retroactively by a server in a post-renegotiation context, related to a "plaintext injection" attack, aka the "Project Mogul" issue.
Another high level vulnerability was the PHP exif_read_data() Function Denial Of Service Vulnerability. Again the affected Systems were the Linux 2.6.x assocaitged with the VM box for PHPBB, MediaWiki, Galley, and Drupal6.
Another high vulnerability existed in the exif_read_data() function in PHP which may allow for denial of service attacks.
Recommendation: The vendor has made an update available for remediation. More information can be obtained here: http://www.php.net/releases/5_2_10.php
Vulnerabilities continued
For the sake of those interested in this subject, I would like to provide some very good suggestions that were provided to me in e-mail correspondence from Austin who works at JumpBox. He was very responsive and provided a thorough explanation and suggestions - a good reflection on the quality of their product and service.
The important thing to understand about the security of a JumpBox or ANY system is that it must be kept up to date either by upgrading or by applying vendor patches. Specifically for a JumpBox, that means updating using their backup restore process. A current JumpBox has all of the Ubuntu patches applied along with the latest version of the application. This means that every vulnerability known to Ubuntu or the application developer has been either fixed or mitigated in some way.
The versions of services and libraries do not typically change (apache, php, and openssl) because the fixes applied by the vendor are back ported to the old version to maintain a consistent environment and still address the issue. So security tools that simply scan for a service, check its version, and look up known issues for that version are actually saying "This MAY have this vulnerability" and not "I have detected this vulnerability".
It is very possible that a security tool such as McAfree's Foundstone scan or other security tools would even report updated JumpBoxes as vulnerable due to the version matching red herring.
To directly address that, let us consider the three vulnerabilities marked "High":
* TLS / SSL Man-In-The-Middle Renegotiation Vulnerability
* PHP exif_read_data() Function Denial Of Service Vulnerability
* PHP Malformed URI Request Heap Overflow Code Execution
The security tool reports will often provide references or common vulnerabilities exposures web links (CVEs)which Ubuntu Security Notices (USN) address - see www.ubuntu.com/usn/. The USNs indicate the vulnerability and the packages, with versions, that were released to resolve those vulnerabilities. As far as JumpBox is concerned, they try to make note of the USN's that are covered in their base image releases. These are recorded in the "JumpBox Runtime Release" section of the README that is included with each JumpBox and also linked to from their wiki pages.
This only covers lower level packages like apache and SSL. It will probably not mention php or app specific fixes, though sometimes those will get mentioned in the release notes. The best indication as to whether a JumpBox (or Ubuntu/Debian server) has addressed a given vulnerability is to find the USN that corresponds to that vulnerability, get the package names and versions that were released to fix that vulnerability and then inspect the installed packages to determine if that package version, or newer, is installed.
An example would be to ssh into a JumpBox as the user 'admin' and run the following command:
dpkg -l | grep php5
ii libapache2-mod-php5 5.2.4-2ubuntu5.10
ii php5 5.2.4-2ubuntu5.10
ii php5-common 5.2.4-2ubuntu5.10
ii php5-mysql 5.2.4-2ubuntu5.10
You can see that the package php5 has the version 5.2.4-2ubuntu5.10.
This is the latest php5 package version for Ubuntu 8.04 (on which the JumpBoxes are based) and can be used for comparison sake
So, in an up to date JumpBox, you could run dpkg, see that the php version is greater than that listed in the USN and know that the package contains the vendors fix for the problem. Or you could update your JumpBoxes and assume they are doing their job and making sure they do not ship JumpBoxes with known vulnerabilities.
The above does not address issues surrounding SSLv2 or weak certificate encryption algorithms that scans may identify.