I was waiting for you to show up on this one esp how you called out Linode, etc. I figured you'd point out in detail just how behind the security curve they were. Haha.
I think calling softpedia "press" is an insult to every real journalist.
The fact that they're calling the bot "tsunami" just proves their incompetence. The bot isn't called tsunami, it's called kaiten and it's been open source for more than a decade.
Doesn't look like they just added a new function called tsunami to me.
>Selling the forum's database for a meager $85 is a sign of their lack of vision. The group seems to have mishandled the entire hack, opting to distribute a silly IRC DDoS bot instead of more dangerous and lucrative malware like Bitcoin miners or banking trojans.
Stupid speculation by writer.
Linux Mint remains compromised despite the current events, it's rather unlikely that kaiten is used as a DDoS bot instead of just a stager to execute shell commands on the affected computers. The presence of DoS commands is meaningless, the only reason kaiten is still used today is because it runs everywhere so it seems fair to assume that that'd be why the attacker opted to just use it instead of writing their own. (No real benefit to that here)
Also, bitcoin mining stopped being lucrative ages ago.
edit:
>One person seems to have bought the hackers' files and dumped the forum's config file on Hacker News discussions thread.
Lmao. Slam dunk. Except for insult to journalism: mainstream press has been quantity over quality for some time now. It's all shit minus the rare few that still practice the real thing.
If they used the same password on the forums and blog then they still have a problem. They need to be notified of this and change the password to a more secure one.
The config.php file should not be readable by an anonymous user, that is a security risk.
Indeed. Instead of `cat`, OP could've used `sha256sum` on the config.php to prove the authenticity of your report without exposing the site to even more attacks.
But that wasn't the point, the point was to expose the level of stupidity at play here.
I strongly believe the users deserve to know just how incompetent these guys are, because next time it won't be some idiot swapping the iso links. It'll be someone slightly more competent that pushes a backdoored commit or gets into the apt repos, and then _every_ _single_ user will be affected...
Also, at the time of the posting the site was down. And it remains so.
I was trying to download Linux securely a month or so ago. It's actually embarrassingly difficult to do. The only two distros that did it right (that I could find) are Debian and Alpine Linux. The rest (including Mint and Ubuntu) had hashes (usually MD5) or GPG keys served over HTTP.
I noticed last year that ubuntu.com - despite being the source from which most people download Ubuntu .isos - has no HTTPS capability and doesn't offer any checksums or gpg signatures on their download page. I believe you can find gpg signatures if you scratch around on their ftp server, but it is ridiculous to assume users will do this (especially when Ubuntu is trying to be a user-friendly distro).
Anyway, as a result I ended up emailing their webmaster asking why Ubuntu.com has no SSL cert. and I haven't heard anything back yet. I think it is pretty poor that a company like Canonical can have such a flagrant disregard for basic security practices, especially when it likes to market Ubuntu as a 'secure' OS.
If you are running Ubuntu then you already have signing key (run apt-key list), otherwise you can compare the full fingerprint with the one printed in terminal output in the guide that's hosted on https.
If you can think of any improvements Debian could make, please do suggest them via bug reports or on the mailing list. If you would like to work on fixing some of our issues, here are the ones we know about:
Debian is already outstanding in this regard (and others)!
One minor suggestion would be to provide ISO hashes over HTTPS. It's just as secure as using GPG with fingerprints sent over HTTPS, and it's a lot easier.
What I don't get about publishing the hashes, etc... if they are serving up tampered .iso files, why wouldn't they also change the website to serve the appropriate hashes for the hacked isos? For the verification to work I would think it needs to be PGP-signed and you should have the public key in advance.
Because someone can do a man-in-the-middle attack and intercept the right hash and replace it with another one. And how do you verify that the public key is trusted for the first time?
GPG has no central CAs, but relies on a "web of trust" situation. In reality, there's no one central that everyone trusts, so unless the keys are signed by some individual you personally trust, you're down to being reliant on getting valid keys.
I am pretty sad they're posting MD5 sums of the correct images: It's pretty trivial to collide MD5 -- and when you've got an active attacker, this is something you should worry about.
SHA1/2 at least, but preferably a gpg signature would be much better.
I think I understand you, but I think you could be a bit more explicit in your assertion.
I think you're saying MD5 is still a decent checksum for non-cryptographic purposes. Without a cryptographic signature or other authenticated integrity-checked distribution channel, there's very little advantage of using a cryptographic checksum.
The relevant thing here is that the main weakness in MD5 requires both the "good" and "evil" versions of the message (or file) to be produced by the same party. It doesn't allow J. Random Attacker to swoop in and alter things that already exist. However, it would allow a hypothetical Evil Maintainer to pre-cook "good" and "evil" versions and swap between them without changing the MD5.
"The TCP checksum uses the same mathematical function as is used by other Internet protocols (UDP, ICMP, etc.). For large data transfers, there is some concern that this checksum is not really strong enough [SP00], so careful applications should apply their own error protection methods (e.g., stronger checksums or CRCs) or use a middleware layer to achieve the same result (e.g., see [RFC5044])."
While possible, it's really really unlikely for this to happen without some fairly serious network issues between you and whoever you're downloading from.
It's somewhat disappointing that this blog article is served over HTTP, and it's impossible to access it via HTTPS. How do we know that these new MD5s are to be trusted?
Linux Mint doesn't seem to prioritize security in general. No TLS for ISOs, no easily spottable signatures for ISOs, marking security updates untrusted by default...
They also ignore (at least they used to) DNS servers from DHCP and use Google's public DNS servers completely oblivious of why users might not want this.
Well that is scary. I personally don't check ISO checksums and signatures very often. Probably the only time I do is when I sometimes get install errors and wonder if I got all the bits and if anything got corrupted.
I've grown obsessive about it. When you're conscious about that it's amazing (to put mildly) how many prominent projects don't bother with any authentication.
If they managed to hack the site to point to the new iso, they probably also changed any checksums. Signatures help, if you have a way to verify that you are using the right key.
But what would I know.