Pulling the Plug to Avoid Attack

Kiteworks is a provider of secure file-transfer and data-sharing software. Its products are used by organizations to exchange sensitive information with employees, customers, and various other outside organizations. As we've seen in recent months, services sitting at the boundaries between organizations and outside parties are attractive targets for attackers seeking large amounts of data.

On September 25th, Kiteworks took a bit of an unusual approach and advised their customers to shut down their systems after receiving what was described as credible threat intelligence from federal authorities. The intelligence in question indicated that an unknown threat actor might attempt to breach customer systems over the weekend.

At the time, Kiteworks had no evidence that either its own systems or any customer environments had already been compromised. Thus, Kiteworks decided to actively sacrifice availability because of intelligence indicating an imminent attack and they could not rule out an unknown vulnerability.

Kiteworks claims that its current version (as of the time of this writing), 9.5.1, has already addressed all known vulnerabilities. The full advisement for customers was to take systems down for a precautionary nine-hour period for self-managed deployments, which include systems running on-premises or those running in cloud environments like AWS or Azure.

The shutdown recommendation from Kiteworks ended on September 27th. They continued to report that there had been no evidence of any successful compromise or exploitation. Interestingly, customers that were running self-hosted Advanced Forms, otherwise known as Secure Data Forms, were instructed to contact Kiteworks support before resuming normal operations.

Kiteworks appeared to work with federal authorities over the course of the shutdown and found a previously unknown vulnerability. Communication with customers seemed to indicate that a severe vulnerability had been found in the Advanced Forms product, which is a product that is enabled for less than 1% of the customer base.

The Advanced Forms product is intended to collect sensitive information through web forms and move the information into controlled enterprise workflows. This product is said to be used by approximately 50 customers. Thankfully, the vulnerability was confined to that product specifically and did not appear to affect any file collaboration or transfer services, or any APIs.

Kiteworks' footprint is worth keeping in mind since the Shadowserver Foundation has identified nearly 400 internet-accessible Kiteworks product instances. 234 of these instances reside in the United States. Of course, it's unclear how many of these instances would have been affected since Shadowserver's data did not indicate which instances were running Advanced Forms.

No details are known about this vulnerability currently, but Kiteworks has stated that they are working with industry partners to share information on any threats.

(Source: Bleepingcomputer / Shadowserver)

Kiteworks' products are in an interesting position in this case because they are specifically designed for exchanging confidential files and other info between organizations and outside parties. Due to the potential access to high value information, file sharing platforms are frequently targeted by threat groups for theft and/or extortion. Even Kiteworks has some relevant history. Under their previous name of Accellion, they had a file transfer application fall victim to compromise in December of 2020.

Of course, it's important to note here that the legacy Accellion product and modern Kiteworks products are not the same. During the investigation of the previous product, Mandiant noted that the product was nearly 20 years old and approaching the end of its life. Even so, we can take that incident as a bit of historical context for why even a warning involving a file transfer product might warrant attention.

Perhaps the most interesting aspect of this whole situation is the decision process of the response. Kiteworks' deliberate recommendation to take systems offline upset the balance of the application in the sense that they purposefully sacrificed availability to potentially protect confidentiality and integrity.

While it seems they did find a vulnerability over the course of the shutdown, but we cannot say whether this action prevented an incident, since there is no way of knowing what would have occurred if the shutdown didn't take place. Ultimately, this situation raises the question: how much evidence should an organization require before taking disruptive defensive action?

This article is shared at no charge for educational and informational purposes only.

Red Sky Alliance is a Cyber Threat Analysis and Intelligence Service organization. We provide indicators of compromise information (CTI) via a notification/Tier I analysis service (RedXray) or an analysis service (CTAC). For questions, comments or assistance, please contact the office directly at 1-844-492-7225 or feedback@redskyalliance.com