[BreachExchange] The Pains Of Vulnerability Coordination – And What To Learn From It

[Destry Winant]

https://www.riskbasedsecurity.com/2019/06/the-pains-of-vulnerability-coordination-and-what-to-learn-from-it/

Some of the members of our Risk Based Security 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 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. Have at least one team member proficient in English
The very first hurdle was the language barrier, although we did manage
to get by in English. PSIRT teams, 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. Be responsive and provide clear status updates on a regular basis
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 the researcher’s 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 and was up until recently distributing the vulnerable
ActiveX controls from an INITECH owned website.

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.