|Third-party or third rate? : SC Magazine : Blog : Home|
Third-party or Third-rate?
First Published: SC Magazine
The majority of the security engagements I participate in are technical assessments and penetration tests against the infrastructure or applications directly owned by the client. Every so often, maybe one in twenty, there is a requirement to assess the security of a third-party system that the client maintains partial interest in – but have no direct control of. Typical systems include financial report distribution services, online personalised training resources and specialist recruitment companies. In many cases, these systems are branded as belonging to the client themselves.
In my clients eyes, there are two key reasons for conducting this type of work. Firstly, as a branded site, should the system be defaced it would likely affect their customer image. Secondly, if the system were to be successfully hacked, an attacker may be able to gain access to client confidential material or personal customer information.
Organisations that initiate regular testing of their third-party managed and owned systems are typically more security savvy than average. They are often well aware of their threat exposure and really do understand the risks associated with the systems in use – having realistic expectations and requiring more than an artificial rubber stamping exercise. Dealing with this type of knowledgeable client is always a privilege.
Unfortunately the same cannot always be said of the third-parties that constitute the recipients of the security assessment. In my initial encounters with them, third-party providers are unlikely to have had an external consultancy review the security of their systems in the past. They often adopt a confrontational stance, seeing me as the harbinger of bad news, or as someone who is going to be able to verify that everything is incredibly secure. Either way, it is not uncommon to discover that the third-party providers have very little understanding of the significance of the vulnerabilities that get discovered during an assessment.
With the most common findings being cross-site scripting and SQL injection attacks (vulnerabilities that are indicative of poor user submission content checking routines and back-end system hardening), it is sometimes a difficult process to explain how these vulnerabilities can adversely affect the client. Even after illustrating the steps an attacker would need to undertake to compromise back-end data systems, many of them find it hard to grasp the impact or likelihood of such an attack. They constantly underestimate the threat and fail to understand the issues presented before them in the context of improving their over all security.
When these security assessments focus upon web sites that are essentially virtual hosts on a shared infrastructure, these vulnerabilities will affect more than just the paying client. Any other client of the third-party hosting provider is potentially 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 that 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 actually 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 the freely available search engine of Netcraft (an organisation that automatically 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 vulnerable to an attacker gaining access to the backend data systems and the confidential information they contained. While the client was not pleased about the findings, they felt that their preliminary review and decision to limit the personal data contained on the system to just a login name and independent password would not represent a major security issue. Unfortunately, it is unlikely that the other organisations using the application platform would have similarly restricted the amount of confidential personal information.
Typical of a three-way assessment closure conference call between the client and the third-party hosting provider, we talked through the findings and their significance. The hosting provider did not understand how these issues could affect their 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 straight away, we believe that we have several weeks to fix the issues after we go live” – I could see that I wasn’t going to have any further affect on their security.
It is a pity that it would be unethical to approach the other customers of the hosting provider that shared the application platform and inform them of the vulnerabilities that they are exposed to. But then again, if security was as important to them they would have already carried out a similar assessment themselves before using the service surely?
Top Tips for using third-party hosted applications