Free Download Manager backdoored – a possible supply chain attack on Linux
securelist.com
securelist.com
How is this a supply chain attack? My official debian repository have never been breached so far.
This is no different from downloading an .exe off a shady website and blindly running the .exe.
Also: https://packages.debian.org/search?keywords=download+manager... lists:
• uget: https://sourceforge.net/projects/urlget/
• kget: https://apps.kde.org/en-gb/kget/
• persepolis: https://persepolisdm.github.io/
why use "Free Download Manager" when high quality ones are already officially packaged by debian? Is this targeting new-comers from windows?
How is this possible? Aren't the packages signed like on ArchLinux so that you can use any mirrorlist?
If you do it from the command line, by editing files, you will have to add the key manually.
But most inexperienced users will just copy/paste and run the "curl | sudo apt-key add" command from the shady repository website, because they want to run the software.
This is not much different from downloading an .exe from an untrusted website, and ignoring the warning from windows when running the .exe.
More here: https://medium.com/@glegoux/ubuntu-22-04-jammy-jellyfish-apt...
maybe you intend to deeply explore the behavior of "the most inexperienced" as if it is Typical of Desktop Linux admins?
Worst is I've seen CD/CI systems which just pull unsigned unverified binaries off the internet and build software from github, random APT and YUM repos, all sorts of shit. This is then all thrown together and pushed into production systems.
Of course a lot of what we built wasn’t public facing or exposed to the internet at all, so addressing the latest vulnerabilities in record time wasn’t quite as important as known-good builds.
I’ve worked in one or two places recently (big bank) that are large enough to have their own internal repo systems and teams of security/compliance reviewers. Their versions of things can be a bit behind but are at least under control of the same org. Everywhere else, well, it feels a bit like cowboy country…
(edit - the other trade-off was of course that you wrote a lot more of everything yourself, rather than pulling in whatever you felt like. This slows down the development cycle significantly but it does mean people had a greater understanding of everything in their stack, and products were often more lean as a result.)
``` curl -sfL https://get.k3s.io | sh - ```
- Not everyone is proficient in bash.
- Some install scripts can easily go on for thousands of lines, especially if they are designed to work with multiple distro or architecture, or both.
- Said install script might be integrated deep down into someone else's build pipeline.
- ... that's assuming they aren't the type that would blindly download and run random exe from the web in the first place
Pretty common, I would say.
IME most of the randomly-downloaded software I've used does what it says on the tin. But there is a whole screening process: where did it come from? Does the originating site look legit? What are the possible motivations for the creator?
Besides there is no signing mechanism for your random install.sh. Maybe you check the SHA256 but if an attacker alters the script why not alter the website with the hashes too?
Obviously I can make some basic heuristics, but I can’t reasonably evaluate all of the components of trust for every library, package, container, framework, repo even at a regular interval, let alone fast enough to just maintain patch levels (nevermind being reasonably productive).
I actually considered first steps in making a business out of this idea, but I’m convinced that every developer overestimates their ability to identify untrustworthy repos/packages and companies aren’t willing to pay the actual cost (with either subscription dollars or in the friction it would add to reject almost all 3rd party code because it doesn’t meet high standards of quality and security in a transparent and verifiable way).
Related: have you tried throwing a file (or a hash) at VirusTotal lately? If it's executable, they'll run it in a sandbox and give you a forensic report of everything it touched and did.
I'm so suspicious of software I can't at least review the source code of that originates outside of trusted channels that I probably wouldn't run anything meeting that description that I couldn't compile myself if it weren't for that (and similar) tools.
Eg. How do I know with any certainty that a library passes all OWASP best practices? Or is well documented? Or is maintained? Or is responsive to security reports? [… and dozens of other similar properties]
Appreciate sf.net isn't as shady now, but ironic it should be listed as that used to spread malware. https://www.howtogeek.com/218764/warning-dont-download-softw...
It's a supply-chain attack because the article has a section about how the official website for "Free Download Manager" was serving malware to a percentage of people.
> While checking videos on Free Download Manager that are hosted on YouTube, we identified several tutorials demonstrating how to install this software on Linux machines. We observed the following actions that happen in all these videos:
> - The video makers opened the legitimate website of Free Download Manager (freedownloadmanager[.]org) in the browser;
> - They afterwards clicked on the Download button for the Linux version of the software;
> - They were redirected to the malicious https://deb.fdmpkg[.]org/freedownloadmanager.deb URL that hosts the infected version of Free Download Manager.
In the article they show a video which shows the user downloading FDM from the official website, and the file coming from that repo.
I wanted to make sure whatever server that was had regular backups, so I asked for the server name.
He looked at the URL bar and gave me the server's IP address: 127.0.0.1
The point here is it’s actually really hard to identify scammy software by name. It only seems that way with extensive domain knowledge. As adoption of Linux continues to grow more people will be duped.
(Obviously joking, nothing but love for OpenBSD.)
Proving trust is hard.
(Clumsy because, firstly, source code comments is a very strange place to write “Glory to Ukraine”, and secondly, because the whole section is written in Russian, except for the word “thanks”)
Knowing how the country actually functions since the invasion, I wouldn't rule this out at all.
I'm more amused what it was in the malware code at all. Reminds me something..
I’m surprised that people installed them on Linux. Stop believing OSS is automatically clean and safe.
Not disagreeing but Free Download Manager stopped being OSS in version 3.9.7, that was 2017 and this article's infected package was released in 2020.
"Free Download Manager backdoored – a possible supply chain attack on Linux machines"
> glory to Ukraine!
> rel 20200126 15:15
> rel 20200126 15:46 added ubuntu 19.10 【thanks russkis】
> rel 20200127 02:46 removed upx, crashes often, unpacked version only now
- read .ssh directory
- write to .ssh directory
- read motherboard serial number
And so on. Accessing the keychain should require confirmation if one program wants to read other program's secrets. If it wants only its own secrets, then no prompt needed.
Debian packagers have a mutual trust process which you need to gain. Only trusted Debian packagers can approve packages to be included. Also some Debian maintainers will just randomly check packages from time to time. (e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792580 )
> "All we require from you is your willingness and ability to receive the funds in question"
not to mention libraries like libxslt that is used by like half the packages
even kernel.org was hacked, and git saved us, and luckily it was before the sha1 collision attacks were viable
https://www.reddit.com/r/linux/comments/k0mco/kernelorg_comp... https://crypto.stackexchange.com/questions/99767/how-easy-is...
bribes are probably quicker and easier.
I'm not trying to minimize all the hard work Debian (or any other distro) packagers do, but "only use official repositories" is not sufficient as a malware-avoidance strategy. Yes, it's better than installing random binaries from random websites, but let's not give ourselves a false sense of security.
The suggestion upthread to run everything in a sandbox is a good one. I wish that was more common and that there was a better UX when doing so.
Eh, don't expect too much from this. It's just the packager downloading a .tar.gz from the website or cloning the version control, maybe checking if it looks alright for a bit at most, maybe check signatures if they're available (or maybe not), and that's usually it. Especially for updates don't expect a "vetting process" of any meaning.
The main "defence" is time, not any vetting: usually people find out any problems before packagers have time to update the package or before a package becomes "known enough" to be added to Debian (or any other package repo): there will be GitHub issues, Reddit drama, HN threads, news articles, what-have-you.
Things like Chromium has a bunch of eyes, but that's the exception and very much not the rule.
No one does think it can not happen, because that is a silly thing to even say. "can not happen" does not exist anywhere, there is only likelihood of happening, based on both history and motivation.
How often HAS it happened in any reputable distros official repos? They have all got decades of history by now so a good sea of data to generate solid statistics on frequency and distribution.
https://security.stackexchange.com/questions/243455/was-ther...
however, cpan, npm, ports, homebrew, gems etc there are examples: https://docs.brew.sh/Acceptable-Casks#apps-that-bundle-malwa...
but i was hinting more at the: there are so many packages, and so many that are used rarely, that there is no way we know.
i think just running weekly modified files report and running things in sandboxes also dont give internet to all apps is good enough for me, and of course be critical of the sources you install from, reputable repos are better than non reputable ones, but are not immune.
https://www.debian.org/security/2008/dsa-1571
I would just like to remind everyone to be cautious, in general. This bug was in the openssl package, and as a consequence was creating incredibly weak keys, for around 2 years before being discovered in what is arguably one of the most critical pieces of software for the OS.
A sandbox wouldn't keep you safe if you have to keep those vectors open.
> and you will open the files it wrote.
Open in a sandbox? Why not.
This wasn't packaged on any distro, so this isn't even a meaningful attack: Users had to go out of their way to install it from a foreign source. This is no different than if you downloaded a random .exe and ran it on Windows with admin access.
Its not a supply chain attack, its a PEBKAC attack.
> FDM can boost all your downloads up to 10 times, process media files of various popular formats, drag&drop URLs right from a web browser as well as simultaneously download multiple files!
No, I still don't a clue what it actually does that the OS and existing tools can't. It sounds like those scam "RAM doubler" programs from the 90s. Run this executable to boost your system's chakras.
Submitters: "Please submit the original source. If a post reports on something found on another site, submit the latter." - https://news.ycombinator.com/newsguidelines.html
Here is the second update regarding the issue: We have prepared a bash script that you can use to check the presence of malware in your system.
Launch Instructions:
Download the linux_malware_check.sh script and give it execute permissions.
You can do this by running: chmod +x linux_malware_check.sh.
Execute the script by running: ./linux_malware_check.sh. Please note that this script only identifies whether the mentioned potential threats are present on your computer, it does not remove them. If malware is detected, it is highly recommended to reinstall the system.
We once again sincerely apologize for any inconvenience that might have been caused.
I mean if I found something called free download manager on a technologically challenged family member's PC I would just assume its malware to start with.
Logitech did similar hijinks for a long time. I can't remember whether it was mandatory, but it sure was difficult to avoid.
Couple that with the fact that it works out well Most Of The Time[0] and you've got a pretty likely scenario even if it affects a relatively small number of people.
[0] I mean in general when downloading software as well as in the context of this particular story[1].
[1] > Starting in 2020, the same domain at times redirected users to the domain deb.fdmpkg[.]org, which served a malicious version of the app.
Hacker News is one of the last holdouts in the low bandwidth friendly website game.
But I suppose you're probably talking about devices that only know about internet protocols before 1991....
I'm saying this as a shell-user.
It could give rise to a supply chain attack.
The more bandwidth you have (and use), the less adequate the little "downloads" pane in your browser is.
- bypassing antiquated per connection throttles on otherwise fast servers by downloading chunks in parallel
- downloading files such as videos from sites that don't really want you to download the file
I have never heard of the program in the article, but this one still sees many active users on windows for the above reasons: https://jdownloader.org/
There's even a little community still making and maintaining plugins for extracting files from uncooperative websites. Really does feel like the kind of program you only ever want to be running in a sandbox though!