Beware of hacked ISOs if you downloaded Linux Mint on February 20th(blog.linuxmint.com)
blog.linuxmint.com
Beware of hacked ISOs if you downloaded Linux Mint on February 20th
http://blog.linuxmint.com/?p=2994
61 comments
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.
Yo ryanlol, you made the press again except the pricks didn't mention your name:
http://news.softpedia.com/news/linux-mint-website-hack-a-tim...
http://news.softpedia.com/news/linux-mint-website-hack-a-tim...
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.
https://packetstormsecurity.com/files/25575/kaiten.c.html
They also managed to confuse FTP and HTTP
>the hackers have only altered the man.cy [https://gist.github.com/Oweoqi/31239851e5b84dbba894] file, where they've added a new function called tsunami.
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.
I neither bought nor sold the data.
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.
https://packetstormsecurity.com/files/25575/kaiten.c.html
They also managed to confuse FTP and HTTP
>the hackers have only altered the man.cy [https://gist.github.com/Oweoqi/31239851e5b84dbba894] file, where they've added a new function called tsunami.
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.
I neither bought nor sold the data.
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.
>I neither bought nor sold the data.
Considering you're still on probation or whatever (I think?), is that really wise to say?
Considering you're still on probation or whatever (I think?), is that really wise to say?
Might not hurt to post this in the comments section of the Mint blog.
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.
The config.php file should not be readable by an anonymous user, that is a security risk.
>The config.php file should not be readable by an anonymous user, that is a security risk.
Yes usually unauthorized people having access to your server results in various security risks.
Yes usually unauthorized people having access to your server results in various security risks.
I took the liberty of posting the link to that comment in Linux Mint blog comments. Hopefully they review that soon.
You have an excellent point, but there's no reason to help attackers by giving them the credentials.
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 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.
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.
It's a bit convoluted. Follow this guide - https://help.ubuntu.com/community/VerifyIsoHowto
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 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.
It's on HTTPS, but it's also a Wiki that anyone can edit. This is the most recent change: https://help.ubuntu.com/community/VerifyIsoHowto?action=diff...
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:
https://wiki.debian.org/Hardening/RepoAndImages
https://wiki.debian.org/Hardening/RepoAndImages
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.
The fingerprints (https://www.debian.org/CD/verify) could also be made more prominent (perhaps put on the main download page).
Thanks again!
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.
The fingerprints (https://www.debian.org/CD/verify) could also be made more prominent (perhaps put on the main download page).
Thanks again!
Maybe in a GPG-signed release email add magnet URLs for the official torrents.
This is kind of in 'No magnet: links for bittorrent downloads on SSL'
This is kind of in 'No magnet: links for bittorrent downloads on SSL'
Fedora publishes GPG signed SHA256's of the iso's. eg. https://dl.fedoraproject.org/pub/fedora/linux/releases/23/Wo...
Thanks! Fedora was one I didn't try (to install; I use it all the time). However there's still no way to use RPMFusion: http://rpmfusion.org/keys
Maybe there's something I'm missing?
Maybe there's something I'm missing?
Arch Linux has PGP signatures and is over https, as well as torrents which should be pretty reliable https://www.archlinux.org/download/
RPMFusion isn't considered part of Fedora. Yes, it would be nice if RPMFusion served hashes securely.
Arch Linux has HTTPS mirrors and provide their GPG signature on HTTPS site.
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.
Are torrents more secure? I usually use the torrents option.
Yes they are. No risk of man-in-the-middle with torrents.
Why is that a problem? If the hash is signed and the public key is trusted shouldn't that be secure?
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?
I was under the impression that you can have your key signed by a generally trusted CA.
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.
SHA1/2 at least, but preferably a gpg signature would be much better.
In the comments section...
"You can find them at http://ftp.heanet.ie/pub/linuxmint.com/stable/17.3/ also along with signed sha256sums."
"You can find them at http://ftp.heanet.ie/pub/linuxmint.com/stable/17.3/ also along with signed sha256sums."
Yes, but why mention MD5 by default? Most machines that have md5sum installed also have sha1sum/sha256sum.
>It's pretty trivial to collide MD5
... collisions=/=second-preimage attacks
>SHA1/2 at least, but preferably a gpg signature would be much better.
SHA1/2 isn't any better, you're never going to get hit by file corruption that magically also is a md5 collision.
... collisions=/=second-preimage attacks
>SHA1/2 at least, but preferably a gpg signature would be much better.
SHA1/2 isn't any better, you're never going to get hit by file corruption that magically also is a md5 collision.
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.
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.
How do you get hit by file corruption when downloading via TCP in 2016? I don't recall this ever happening to me.
"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])."
-- TCP/IP Illustrated
-- TCP/IP Illustrated
TCP checksums are not reliable
Use a Canadian ISP.
When talking about specific files the attacker used in the past, MD5 is good enough to show it's not those.
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.
> don't check ISO checksums
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.
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.
What other ways are there to download, apart from http and torrents?
torrents cant get compromised so you are safe if downloaded via torrents.
FTP?
maybe IRC and NNTP too.
I mean "what other ways do they have to download this?" All I saw is HTTP and Torrent, so I'm curious as to what exactly got compromised.
Looks like something is going on again. Their website is down currently. [21-Feb 02:55 UTC]
"Edit by Clem: We shut down the server until we find the source of the second intrusion (probably something left by the first)."
http://blog.linuxmint.com/?p=2994
http://blog.linuxmint.com/?p=2994
Now you tell me.
Perhaps the insanely secure db credentials had something to do with the breach?
But what would I know.