MKVToolNix not affected by FossHub breach
2016-08-08 — mosu
Last week FossHub was breached by attackers from the group PeggleCrew. As I’m using FossHub as the primary mean of distributing Windows and MacOS binaries for MKVToolNix, users have asked me whether MKVToolNix or my other servers have been compromised, too.
To the best of my knowledge the answer is: no.
I base this on several facts:
- Last week the FossHub administrators sent an quick announcement to the developers hosting their software on FossHub on the day the breach was discovered. In it the admins were very open and honest about how they’d been breached, what the attackers had had access to, and what had been modified. While they did have access to the MKVToolNix binaries, those binaries were not modified.
- Several reports about the incident that have been release since by various media do not list MKVToolNix either.
- The group’s Twitter account didn’t list MKVToolNix as a modified program.
- To date I haven’t received a single report by a user about a MKVToolNix binary that was acting suspiciously or that was detected by anti virus tools as dangerous.
Another thing the attackers did have access to was the account database used for the developer section of the site. That database includes the passwords, and they’ve allegedly not been salted. This, however, doesn’t pose a problem for me either:
- I’m using random, long passwords for such sites. Therefore it’s irrelevant whether or not the passwords have been salted as rainbow attacks (the use of pre-computed tables containing the cleartext passwords and their hashed checksums) aren’t effective against randomly generated passwords.
- Even more important is that I don’t re-use passwords on other sites. So even if someone was able to determine the cleartext version of my FossHub password, it wouldn’t do them any good as it cannot be used to gain entry to any other service I’m using.
There are two things Windows users can do to verify that the binaries they’ve downloaded from FossHub are clean. The first is to verify its SHA-1 and SHA-512 checksums. I provide both checksums on my own server, and they’re always linked to from the download page: SHA1 checksums for 9.3.1, SHA512 checksums. Checksums for other versions can be queried by replacing the version number 9.3.1 in the URL with the one you’re interested in.
The second thing is to check that the executables (both the installer’s executable as well as the ones for the actual tools) are signed by the right certificate. I’m using a certificate signed by StartSSL (StartCom) (“CN = StartCom Class 2 Object CA, OU = StartCom Certification Authority, O = StartCom Ltd., C = IL”). My current certificate’s serial number is 5a:d8:f8:75:9a:c3:46:ae:8b:ec:99:15:eb:b5:5d:04 and its SHA1 fingerprint is 48:13:1B:5D:41:63:12:07:D2:86:20:6C:28:F3:78:C8:06:6F:34:AA, though those two values are subject to change when the certificate will be renewed in 2018.