What do you choose as a pentester, when your work ethics are in conflict with your dedication to the security community. To disclose vulnerabilities you’ve found or not to disclose?

As a penetration tester, during an engagement you are often asked to assess a product that is widely used in the market, and may or may not have been customized by the client. Even in cases of widely used products by well-known companies, organizations with high security requirements have to accredit their systems through a third party penetration test. Thus, even though the software is thought to be tested from both the software company and the community, a penetration tester must be extremely conscientious on his methodology. Most of the times, expecting to find nothing besides misconfiguration issues, caused by the administrators’ carelessness. Nevertheless, more often than these companies would care to admit, this is not the case.

As an example, let’s say that you are hired by an organisation to perform a penetration test towards an intranet web application, which uses a customized version of widely (by “widely”, we mean “a lot”) used CMS. First thing you do as a pentester,  is to search online and in your private stash for vulnerabilities already identified for the current version. Regardless of whether you find anything or not, you must continue with the your own tests. So, you fire your automated and semi-automated tools and then proceed into manual testing. And that is when you find an SQL injection vulnerability! The holy grail of a web application pentest! And, just to put a cherry on top, the SQLi allows you to read and write to database.

So, what do you do? You submit a report to your client, including the specific vulnerability with recommendations on how to fix it. The client contacts the vendor to request a fix for this vulnerability. The response of the vendor is that it’s very hard to fix the issue it in a timely manner; It will take some time and it will be probably fixed in the next major release.
The organization comes back and requires your assistance in implementing mitigating controls for the issue, until the next major release of the CMS is launched. So, you sit down with the in-house development team and together you apply a fix for their installation.
Thus, you perform the retest and the vulnerability is no longer exploitable – for that specific instance. However, the version used by so many other companies and individuals is still at large. They are still vulnerable and they will continue to be until the next major version of the software is released.

Finally, you get yourself in the position of an ethical and legal dilemma; Do you publicly disclose the vulnerability identified in order to let the other users of this application know of the Risk that they are exposed to?

On one hand, as part of the ICT and more specifically the security community, you have the responsibility to inform your colleagues of a potential hole that they have in their infrastructure. By not disclosing the vulnerability, it doesn’t mean that someone else will not (or has already) discovered it.

On the other hand, you have discovered the vulnerability during your engagement as a penetration tester. As far as work ethics go, whatever you do/discover while hired as a consultant, is the intellectual property of your employer. In essence, the discovery of the vulnerability is not yours to keep secret or shout in the public.

Add to the latter, the factor that your client organisation may not be able to mitigate the vulnerability, until the vendor issues a patch and the situation becomes even trickier.

What if the client hasn’t fixed it yet?


P.S. For those of you wandering why it would be so difficult for the vendor to fix an SQLi vulnerability, let’s say that even though this article is based on real life experience, the specifics of the software and the vulnerability have been altered – but, just a bit!

Share This

Share this post with your friends!