The majority of the security engagements I participate in are technical assessments and penetration tests against the infrastructure or applications owned by the client. Every so often, maybe one in 20, there is a requirement to assess the security of a third-party system that the client maintains partial interest in (but has no direct control over). Typical systems include financial report distribution services, online personalized training resources, and specialist recruitment companies. These systems are often branded as belonging to the client.
In my client’s eyes, there are two reasons for conducting this type of work. First, as a branded site, it would affect their image if the system was defaced. Second, if the system was to be hacked, an attacker might be able to gain access to confidential material or customer information.
Organizations that initiate regular testing of their third-party managed and owned systems are more security savvy than most. They are well aware of their threat exposure and understand the risks associated with the systems in use. They have realistic expectations and require more than a rubber-stamping exercise. Dealing with such knowledgeable clients is always a privilege.
The same cannot always be said of the third-parties that are the recipients of the security assessment. In my encounters with them, third-party providers are unlikely to have had an external consultant review the security of their systems in the past. They often adopt a confrontational stance, seeing me as the bringer of bad news or as someone who will verify that everything is comprehensively secure. Either way, it is common to discover that third-party providers have little understanding of the significance of the vulnerabilities that are discovered during an assessment.
The most common findings are cross-site scripting and SQL injection attacks (vulnerabilities indicative of poor user submission content-checking routines and back-end system hardening), and it is sometimes difficult to explain how these vulnerabilities can adversely affect the client.
Even after illustrating the steps an attacker might take to compromise back-end data systems, many find it hard to grasp the impact or likelihood of such an attack. They underestimate the threat and fail to understand the issues presented to them in the context of improving their overall security.
When these security assessments focus on websites that are essentially virtual hosts on a shared infrastructure, these vulnerabilities affect more than just the paying client. Any client of the third-party hosting provider is vulnerable (and, similarly, my paying client is exposed to the vulnerabilities in the other virtual hosts).
For instance, in a recent security assessment the hosting provider felt the presence of other virtual hosts on the shared system would not be an issue. Since they did not offer reverse resolution on the IP address of the host, nobody would know what other sites were hosted on that same infrastructure except for themselves. Security through obscurity strikes again.
It only took a couple of minutes to use Netcraft’s free and available search engine (Netcraft monitors the uptime and version history of web servers around the world) to identify more than a dozen other hosts that resolved to the IP address under study.
With the underlying shared application platform riddled with SQL injection vulnerabilities, all virtual hosts were defenseless to an attacker gaining access to the back-end data systems and the information they contained. While the client was not pleased with the findings, it felt that its initial review and decision to limit the personal data contained on the system to a login name and independent password would not represent a major security issue. Unfortunately, it is unlikely that other organizations using the application platform would have also restricted the amount of confidential personal information.
Typical of a three-way assessment closure conference call with the client and the third-party hosting provider, we (the consultant) shared the findings and their significance. The hosting provider did not understand how these issues could affect its other customers that make use of the same system. With responses like “We’re in the process of taking on someone who knows about security and will fix that,” and “No one would attack us straightaway, we believe that we have several weeks to fix the issues after we go live,” I could see that I was not going to have any further affect on their security.
It is a pity it is unethical to approach other customers of the hosting provider that shared the application platform and inform them of the vulnerabilities. Then again, if security was important to them, they would already have performed a similar assessment.