RedTeam

When RedTeam finds vulnerabilities in some generally available software, we go the usual way of writing advisories. These findings usually occur during pentests. We of course do not immediately release whatever we found to the public, but go through a process I want to describe in a little bit more detail here. I’m doing this to make it more transparent on how we decide when, to what detail and where we release information about new vulnerabilities, since sometimes, it does not seem clear why we do so.

The first step we take is of course to ask our clients if it is ok to write security advisories about the vulnerabilities and publish them. This is due to the fact that if we discover something during a pentest, the clients paid for these findings and have a right to decide what to do with them. We always recommend releasing stuff to the public if it’s something generic, as we of course also benefit from people releasing new security advisories, as do our clients.

The next step is to write preliminary advisories with all the details and then notify the vendors. We want to give them a chance to patch the vulnerabilities before we release the advisory. We therefore work closely with them on the issue and coordinate the public announcement.

Before finally releasing, we notify our clients about the patch so they can deploy it. The vendors hopefully also notify their clients, if we’re talking about commercial software. As soon as the vendors publicly announce the new version of their software or that a patch is available, we release the advisories on our homepage and through the usual channels (Bugtraq, Full Disclosure etc.).

I think this is a pretty normal procedure for releasing new advisories and is the usual “responsible disclosure” type of thing. I guess there’s only two points we may need to explain further:

1. We release our advisories as soon as the vendors publish their security alerts / patches / new versions. The latter is the most important. Sometimes, the vendors silently correct security holes or just tell you that “some security issues” were fixed. When we release our advisory with detailed information, sometimes people complain (not only to us, others do the same and get those complaints, too) about not having enough time to deploy the new version before everyone knows what the vulnerability is.

   The problem is that every sufficiently advanced attacker is able to use a diffing tool to check what changed in the code and then knows what the problem is. This is of course made difficult if there’s not only a security fix, but also other fixes which get included in the release, but it’s still only a matter of patience and time. People do it all the time with Microsoft’s patches (Alexander Sotirov is one of the good guys btw., don’t get me wrong), for example. So we rather release our advisory and tell you what’s wrong, than to publish an advisory with only insufficient information. Which leads us directly to

2. We always give detailed information about the vulnerabilies in our advisories. This is another controversy going on for some time, should advisories contain detailed instructions on how to exploit the vulnerability (and even contain PoC exploit code)? Many argue that this only makes it easier for malicious attackers and worse for administrators. The thing is that without the details, you make it actually harder for administrators to estimate the risk of a vulnerability and if or when they should patch / upgrade. Also, as mentioned above, any serious attackers will get the details themselves in no time. It is of course a problem if you release without a patch or new version being available – which brings us back to responsible disclosure.