April « 2014 « IT Security Geeks

For the last couple of weeks all the IT security news headlines have revolved around the OpenSSL Heartbleed vulnerability (CVE-2014-0160), so we’ve decided to write about something completely different to keep things interesting.

For years now, we have been advising clients that it is good practice to have secure laptop, desktop and server builds across their estates. This allows for a baseline of each Operating System that gets deployed and also means that your network and system administrators have a high level of control as to what software is installed across the estate. This does mean that more time will need to be spent upfront making sure that these Operating System builds are both functional and secure for the end users, but the rewards for doing this considerably decrease the overall risk to your organization. When using an Active Directory domain, it is also highly recommended to lock down the Operating System builds even further by using Group Policy Objects (GPO’s.)

Our team were recently asked to conduct a penetration test for one of our clients, with the scope being a web based problem ticketing system. We were issued a corporate laptop to allow us to familiarize ourselves with the application, to read internal documentation and the relevant processes and procedures around it. This was to allow the team to perform a complete end-to-end security review for the client. The laptop was also configured with VPN access, allowing the team to work remotely from our offices.

The laptop was running Windows 7 and had been locked down, preventing us from installing any standard programs onto it (such as various penetration testing tools.) The laptop also did not come with Local Administrative rights configured (thankfully,) and we were only given standard user privileges. To add to the layers of protection around the client’s internal infrastructure, all connections to the Internet had to go through the internal corporate proxy server.

One thing that our team discovered is that the corporate laptop included Java within the build. The internal corporate proxy server was configured to block downloads of Windows executable files and installers (.exe’s and .msi’s,) however, downloading of Java applications (.jar files) was allowed. Thanks to this, the team were able to run a web application proxy on this laptop. This in turn lead to our team being able to perform the full penetration test of the application, all from the client’s corporate laptop.

During the penetration test, the team discovered that the application was vulnerable to numerous high-risk web application vulnerabilities, however, this really is the least of our client’s worries at this point. We never increased the scope of the penetration test to perform this testing and never violated the client’s security policy either, as we didn’t install anything on the laptop, we just downloaded and ran software. Technically, Java ran the application, we just downloaded it.

There are no security controls in place to stop internal users from performing the same steps that we did to run BurpSuite, or any other Java applications on these corporate builds. This poses a huge risk to this client, their internal applications and ultimately, their overall reputation. Yes, there is monitoring software and anti-virus software installed on these PC’s and attacks could be traced back to IP addresses and user names, however, host monitoring logs would only be reviewed after the attack and would be a responsive counter measure, not an active protection measure.

Our team were tasked with performing a penetration test of just one of the internal corporate web applications, but just like other large corporate clients, there are a lot more internal web applications in use within this organization. This means that an internal attacker could easily target any one of the client’s numerous other web applications, all from their own corporate PC. When you have over 100 internal users, this exponentially increases the risk to all internal web applications, and to the organization as a whole.

This vulnerability would also allow internal users to download these tools and to attack other external applications not within the client’s infrastructure or realm of control. If an internal user were to compromise (or attempt to compromise) a web application hosted by the client’s competition, this attack would be seen as coming from the client’s network. This, in turn, could lead to all sorts of legalities and difficult conversations.

We highly recommend that all corporate Operating System builds be penetration tested before being deployed so that vulnerabilities such as this can be mitigated before the builds are issued to internal users. At ITSG we take the security of our clients’ networks very seriously and this is why we always aim to point out as many vulnerabilities as possible during all our penetration testing engagements.

If you currently have a corporate Operating System build that hasn’t been through a thorough penetration test, then please consider doing this as a matter of urgency. ITSG will gladly assist you with developing secure Operating System builds or performing penetration testing of these builds if you already have them in place. Please contact us for more information.

Follow us on Twitter and/or Facebook to see more updates.