The Pains of Vulnerability Coordination—And What to Learn From It

Some members of Flashpoint’s Vulnerability Research Team have been discovering and coordinating vulnerabilities for almost 20 years. Coordinating vulnerabilities can be painful at times, even if things overall have improved, especially when coordinating vulnerabilities with companies from the USA and most parts of the EU. These difficulties can be compounded when the discovered vulnerabilities are in products from vendors from other parts of the world, even when reporting them through a government agency specifically set up to handle them.

Two weeks ago, we disclosed 40 critical vulnerabilities in ActiveX controls from South Korea. Most of these could easily have been exploited in zero-day (0-day) attacks similar to many of those historically attributed to North Korea in past years. Since the vulnerabilities were in ActiveX controls from many different vendors, we coordinated our findings through KrCERT/CC, part of the Korea Internet & Security Agency (KISA).

We wanted to share some of the difficulties we recently ran into, and some key learnings for companies and government entities dealing with vulnerability researchers.

1. Vulnerability researchers proficient in English

The very first hurdle was the language barrier, although we did manage to get by in English. Product Security Incident Response Teams (PSIRT), and those in similar roles, who are the contact point for vulnerability researchers, should always be proficient in English regardless of where they’re located in the world. The vast majority of vulnerability researchers will be contacting you in English.

2. Being responsive and provide clear status updates

Overall KISA was pretty fast at responding, but we did get the impression that they were not used to dealing with vulnerability researchers from abroad. We had to ask for status updates and be very specific about the information we needed from them. Otherwise we received only vague responses that required us to ask follow-up questions.

The key lesson here is to always be responsive. Aim to reply to the researcher within 48 hours, even if only to acknowledge receiving their email and to let them know approximately when you’ll get back to them. Some researchers quickly get impatient and may publicly disclose their findings otherwise.

When a disclosure process is likely to take a significant time (in our case the vulnerabilities were reported in February and published late May), align with the researcher on status update expectations. Provide these updates regularly and in a clear and detailed fashion to eliminate too much back-and-forth emailing. The more details you share with the researcher, the happier they’ll be.

3. Make it clear when you plan to release new versions and security advisories

In our case, KISA is not a vendor and was not responsible for fixing the discovered vulnerabilities or releasing new versions. However, they did confirm that they were responsible for ensuring that the kill-bits were set for the vulnerable ActiveX controls and publishing advisories. At no point during the coordination process did KISA clearly state when they expected to do so.

Eventually, we informed them early May that our plan was to release our advisories by the end of the month. At that time, they’d had four months to coordinate the vulnerabilities. We did ask when they expected to release their advisories but were told that they were “cooperating with vendor[sic]” and that we did not “need to be on [their] announcement schedule.” As such, we went ahead with our disclosure.

Most of the ActiveX controls were quickly removed from the affected vendors’ websites, but the kill-bits are still not set. Similarly, KISA has seemingly not released any security advisories to warn the people of South Korea. Just removing the download links to the ActiveX controls does not address the vulnerabilities. The ActiveX controls are still installed on users’ systems and can still be instantiated in the browser until kill-bitted. The lack of alerts from KISA means that South Korean users may unknowingly have vulnerable ActiveX controls on their system that could lead to a system compromise.The key lesson here is to always strive to coordinate your disclosure with the researcher.

Clearly communicate when you plan to release fixed versions and your security advisories. If you are a vendor, do not just release your fixes and advisories without giving the researcher a heads-up. Researchers won’t always take kindly to that and may refrain from coordinating with you in the future. Similarly, once a researcher releases their advisory, you need to quickly publish your own. Even if your fixes aren’t ready yet. This also applies to government entities like KISA, who are responsible for handling coordination.

If a researcher publishes their report, your main responsibility is not to the vendors but to the users. Get your own advisories out as quickly as possible. In an ideal scenario, the researcher, vendor, and coordinating government entity all release at the same time. When that’s not the case, the government entity should not wait for the vendor. That’s doing a disservice to the impacted users.

4. If you can’t reproduce research findings, tell them about it

One media outlet that covered our findings was boannews.com in South Korea. We later noticed that they had updated their article with two statements from KISA. The first, roughly translated, states that KISA had failed to reproduce the vulnerability reported in the ActiveX control from Samsung Securities and thus the conclusion was that the report was fake.

This was surprising as KISA at no point during the 4 month coordination period informed us that they had problems reproducing the issue. We have a working exploit for this vulnerability and also provided this to KISA. The exploit relies on downloading and executing a malicious file from a web server, which they were required to set up themselves, so we suspect KISA failed to do so correctly. Reproducing vulnerabilities reported by researchers may not always be straight-forward and require tweaks to the provided PoC or exploit code.

The key lesson here is that if you can’t confirm the researcher’s findings, let them know about it. In most cases, the researcher will happily provide additional information to assist you in reproducing it.
Don’t just disregard the report as fake. That way you not only fail to address a valid vulnerability but may also end up looking silly when telling a journalist that the report is fake while the researcher is sitting on a working exploit. Many researchers will quickly react to such incorrect statements by publishing the exploit code and that won’t do you or your customers any good.

5. You’re responsible for code developed by companies you bought

In KISA’s second statement in the news article, they indicate that the vulnerability reported in the ActiveX control attributed to INITECH was not actually related to that company. This statement was less of a surprise than the first (though equally wrong). INITECH also reached out to us and claimed zero responsibility for the code, stating that it was developed by BankTown. While BankTown did indeed develop the ActiveX control, they were merged with INITECH back in 2008, which the email from INITECH even acknowledged.

On top of this, the vulnerable ActiveX control was, until recently, distributed from http://mywallet.banktown.com/PSB/PsbMyb.cab. This domain is clearly owned by INITECH, which is evident when, for example, accessing www.banktown.com:

1. The web page has an INITECH logo up top
2. The bottom of the web page has a copyright for INITECH
3. The certificate for the site is incorrectly issued for www.initech.com. Based on the above, for all intents and purposes the vulnerable ActiveX control is owned by INITECH regardless of having been created by another company. INITECH now owns that company and thus any code developed by it is owned by INITECH, and is responsible for distributing vulnerable ActiveX controls. The key lesson here is that you cannot reject responsibility for code that was developed by another company that your company purchased. You’re responsible for deprecating the vulnerable software or updating it. Especially if you’ve been distributing it after the merger.

There are many other key lessons that we could share, but these will have to do for now. If you’re curious about learning more about how to coordinate and disclose vulnerabilities as a vendor or coordinating government entity, we recommend you consult ISO Standard 29147 (the first edition is freely available). Otherwise, if you have a publicly listed security contact, are approachable, and communicate clearly and in a timely manner with researchers, you should have the foundation for a good vulnerability coordination process and experience.