Tags

, , , , , , , , , ,

This is my first relatively major vulnerability discovery that I’ve been sitting on for two months, and almost forgot about until now. It was purely by chance, when I decided to look at an ‘encrypted’ document in a hex editor (for no good reason). I had set the encryption and a password was required to open the file in Kingsoft Writer, but I found a line of the plaintext was still readable. Here’s a screenshot of the hex dump:

test-crypt

Unsure of whether the encryption failed to work completely, I ran the same test again, this time with a larger file and using ‘Microsoft Enhanced RSA and AES Cryptographic Provider’:

Kingsoft-Crypto-Options

In the hex dump for this, portions of the plaintext were visible again, and most of it encrypted.
After further experimentation and mapping out the document’s file structure, I discovered that Kingsoft Writer doesn’t encrypt the file, but instead a section of the file that contains the main body, or the ‘payload’. However, if there are no line breaks in the text and the author didn’t alter the properties, the first 254 bytes of the plaintext is written to another section of the file structure before the payload is encrypted.

wps-file-structure

Under the right conditions, this could be enough to reveal the entire contents of a short message or memo to a third party loading that ‘encrypted’ document into an alternative application.

full-255

Evidently that’s a lot of information leakage for an encrypted document. As it turned out, the 254 bytes are replaced with whatever’s entered in the Property fields, so it should be possible for Kingsoft to modify the software so it replaces the contents of that file section without changing the file structure.

doc-properties

test-crypt-3

The username of the document’s creator also appears in the hexdump.

If I remember correctly, Sam Raincock also demonstrated something roughly like this back in 2011 with an older version of Microsoft Office and EnCase during her Somerset IET talk. Here I simply used a standard hex editor to get the information.

Disclosure and Reporting
Of course, it’s not the kind of vulnerability that involves complicated things like buffer overflows, privilege escalation and whatnot, but it obviously could impact anyone who relies on document encryption to protect sensitive information (which isn’t good practice anyway). It needed to be disclosed at some point, but when and how?
I’m a believer in what’s known as ‘responsible disclosure’, the idea being that a vendor is given sufficient time to resolve a vulnerability before it’s publicly disclosed, hence my waiting two months. It would have been unfair to give Kingsoft a bad rep for overlooking a flaw in an otherwise excellent product.

The first thing I did was bang off an email to Kingsoft, giving them a brief summary, then I reserved a CVE identifier from MITRE itself, taking advice from Brian Martin of the Open Source Vulnerability Database project. Then I decided to wait another 60+ days. Apparently the problem wasn’t considered important enough to warrant a reply from Kingsoft, so I’ve no idea whether they sorted it after.

I don’t know whether The Powers That Be would consider this disclosure worthy of publication, but I’m throwing it out there anyway.

UPDATE: The vulnerability advisory has been published on the OSVDB, and on a Chinese SecWiki.

Advertisements