search

transmission / transmission

Official Transmission BitTorrent client repository
https://transmissionbt.com
Other
11.98k stars 1.2k forks source link

Old .msi installs AutoKMS and then Windows 10 Pro remote access is granted to attackers. #6227

Closed Malumen closed 8 months ago

Malumen commented 10 months ago

What is the issue?

Currently using Transmission 4.0.4 but I always keep a few versions in case something breaks. I happened to notice the other day that my work laptop was waking up from sleep and "available for streaming" (thank you Steam). This tipped me off. After some searching, I discovered an old .msi installer for transmission-4.0.0-beta.2+rbceb368f1b-x64.msi sitting in my downloads folder was autorunning some things, and a lot of things.

Please see the attached image. Sandboxing the installer file and putting it on a different machine also causes it to attempt the same actions.

My windows OS on that system was updated to Windows 10 Pro (which is definitely not what it should be). Remote access was granted and registry keys were changed and created...

Mind you, this version (transmission-4.0.0-beta.2+rbceb368f1b-x64.msi) had been installed and was working just fine, and only after updating to future revisions and after some time had passed did the file begin to activate and do all this on its own.

screenshot

So...

Which application of Transmission?

Qt app on Windows

Which version of Transmission?

4.0.4

tearfur commented 10 months ago

I'm no IT security expert. My guess is that you caught a worm somewhere and it infected the installer?

I downloaded the installer from GitHub releases and computed its SHA256 sum, which is 7c5dffae356230aee7e2828b79bf39460725a67a4eff72a4bfa01809742d10fa. Does your installer file have this checksum?

Reubend commented 10 months ago

I'm also affected! I was tipped off that I might have a virus by the fact that "Transmission Qt Client" showed up in the Recently Added section of my Start Menu, but I did not recently install it. Afterwards, Windows Defender quarantined the file C:\Program Files\Transmission\transmission-qt.exe and declared that it was a virus of the type HackTool:Win32/AutoKMS!pz. Based on your report that it changed the version of your Windows install to "Pro", I am guessing that Windows Defender detected it using their heuristic for hacking tools, not their heuristic for viruses (which seems more appropriate for this case as it seems to be a full on virus). image

Regarding whether I installed Transmission, or whether some virus installed it without my knowledge, I honestly can't remember. Windows shows Transmission 4.0.1 (e1c6e1be43) (x64) as being installed on 3/3/23, so it's possible that the version of Transmission back then already had compromised installers, and that the virus just hasn't been active until today. On the other hand, it's possible we picked up the virus somewhere else and that it can fake the install date, meaning that I can't assume Transmission itself was ever compromised. image

ioReid commented 10 months ago

I'm also seeing Transmission 4.0.1 (e1c6e1be43) (x64) getting blocked/quarantined by Windows Defender as HackTool:Win32/AutoKMS!pz. Both transmission-qt.exe and transmission-daemon.exe. Quarantine1 Quarantine2

In Event Viewer I see the following: Windows installed the following update Security Intelligence Update for Microsoft Defender Antivirus - KB2267602 (Version 1.399.1549.0) - Current Channel (Broad) and then not even a minute later I see an error "The Transmission Daemon service terminated unexpectedly. It has done this 1 time(s)."

Not sure if it's a legitimate threat or a false positive, but it looks like that update is what caused it to get flagged for me.

ckerr commented 10 months ago

CC @mikedld

Reubend commented 10 months ago

I used a VM to confirm that some official releases are getting detected as a virus, and to analyze the files inside a bit. The 4.0.1 release of Transmission contains the following installer + files (amongst others):

File Name SHA256 Behavioral Analysis
transmission-4.0.1-qt5-x64.msi 33cf595bfca9eb2b08bf9585e9af0e08476ea175acdceed991113ff8e6518acbCell Link
transmission-daemon.exe 638acd2f1dbd69ba11582fc978ab0a3a2ff45ebcf3883b1ff25cf220df71b5ed Link
transmission-qt.exe 9f89b613767f1d84874091ae52b97ff54b582743c412e1aedfcbdd55c656684b Link

The behavioral analysis does seem suspicious:

Maybe someone who's more experienced than me in terms of reverse engineering can confirm whether these files are malicious?

mikedld commented 10 months ago

Most probably a false-positive after recent Defender definitions update, please contact Microsoft.

Reubend commented 10 months ago

Most probably a false-positive after recent Defender definitions update, please contact Microsoft.

Hey Mike, thanks for looking. Can you share why you think this is most likely a false positive? As I wrote above, there's some weird behavior going on in the software like changing registry keys related to safe boot options, detecting if the software is running inside a VM, logging keystrokes, etc. That's all from the official release.

Maybe all of that behavior is legitimate? I'd love to understand better if that's the case.

ckerr commented 10 months ago

like changing registry keys related to safe boot options

I don't believe we do that and also don't see anything about changing safe boot registry options in any of the pages you linked.

detecting if the software is running inside a VM

There's nothing in our code that does that. Do you have more information on what specifically this means and how I could try and reproduce the behavior?

logging keystrokes, etc.

We don't log keystrokes. The GUI app does respond to keystrokes, of course, but that's it.Maybe libevent's polling mechanism is giving a false positive here as logging keystrokes? Again, do you have more information on what specifically this means s.t. I could try to reproduce it?

Reubend commented 10 months ago

detecting if the software is running inside a VM

There's nothing in our code that does that. Do you have more information on what specifically this means and how I could try and reproduce the behavior?

Sure, this is specifically referencing the fact that transmission-daemon.exe triggers this CAPA rule which scans for VM detection capabilities. Basically it scans for simple strings like SOFTWARE\\Oracle\\VirtualBox Guest Additions and if it find them, it assumes the program is trying to detect whether or not it's running inside a VM.

We don't log keystrokes. The GUI app does respond to keystrokes, of course, but that's it.Maybe libevent's polling mechanism is giving a false positive here as logging keystrokes? Again, do you have more information on what specifically this means s.t. I could try to reproduce it?

The detection rule for logging keystrokes via polling is here, and it's scanning for Win32 API calls like GetKeyboardState. This could be totally legitimate, since these API calls aren't that weird. But it does strike me that polling the keyboard state manually is something you're more likely to find in a keylogger or something than a GUI app like Transmission, where parsing messages like WM_KEYDOWN is more common as far as I know (I could be wrong here, please set me straight if that doesn't make sense).

like changing registry keys related to safe boot options

I don't believe we do that and also don't see anything about changing safe boot registry options in any of the pages you linked.

Sorry, I made a mistake here, it looks like that registry key is read from but not written to. So I was incorrect to say that it was "changing" the safe boot settings, it was actually just reading them. Still a bit strange to me. This is from the analysis of transmission-qt.exe. image While I'm digging through the registry keys, it's also weird to me that it changes registry keys related to certificates 🤔 image Again, I'm not an expert on any of this stuff so maybe that's standard behavior for a signed installer on Windows? But while checking the registry keys for certificates makes sense, writing to them doesn't strike me as necessary.

ckerr commented 10 months ago

To repeat:

none of that stuff. It literally doesn't even have any code to look at registry keys. It literally doesn't have any code to look at virtualbox. etc. etc. It's not there. Go to the top of this page and use the search window to see for yourself.

Both Transmission's source code, and the scripts used to build the installers, are publicly readable in github. Anyone can check them out & reproduce the build from scratch. Anyone who wants to find out where in the toolchain these things are coming from, e.g. from Qt or libcurl or openssl or libevent or wherever, is welcome to do that.

Some of these claims are just crazy ("installs Windows 10 Pro"). Some of these claims are potentially true, e.g. since libcurl handles https connections, it's plausible that it does something related to certificates, it's plausible that there's some mechanism in all signed apps that looks at keys, etc.) If anyone wants to do that spelunking and finds something actionable to remove some of these red flags, that would be great. I would love it. PLEASE DO THAT AND OPEN TICKETS.

But I'm not going to play whack-a-mole where one claim is made ("it's modifying registry keys!") and when I answer ("no it's not, and not even the reports say so") the response is to shrug it off and add another claim ("even reading the keys is still weird, but also, what about this authroot certificate?") -- It's not in Transmission's code, nor the build scripts.

ckerr commented 10 months ago

To add one more thing... this passage showcases what's kind of frustrating about this thread:

it's scanning for Win32 API calls like GetKeyboardState. This could be totally legitimate, since these API calls aren't that weird. But it does strike me that polling the keyboard state manually is something you're more likely to find in a keylogger or something than a GUI app like Transmission, where parsing messages like WM_KEYDOWN is more common as far as I know (I could be wrong here, please set me straight if that doesn't make sense).

So I'm being asked "please set me straight", why is Transmission using X instead of Y? -- when it's not using either. Search for yourself, it's not in there.

ckerr commented 10 months ago

OK I keep coming back to this ticket because OT1H I want to be clear:

OTOH, even when wanting to take security seriously, a lot of the claims in this ticket are just madness:

And when maintainer @tearfur tried to track down the first claims by asking for a sha256 checksum of the file involved, nobody bothered to answer but instead added on more claims about keylogging, modifying registry keys, etc.

FWIW here is the report for the latest stable release, 4.0.4:

https://www.virustotal.com/gui/file/9f89b613767f1d84874091ae52b97ff54b582743c412e1aedfcbdd55c656684b

ckerr commented 10 months ago

The daemon has anti-VM string references, and also has XOR'd data stored inside of it

No, this is misinformation. The report does not say that the daemon has XOR'd data stored in it. To quote it directly, the " Obfuscated Files or Information" section of the report says Transmission does these things:

Encode data using XOR Encrypt data using RC4 PRGA Encrypt data using RC4 KSA Reference Base64 string

Transmission, like most BitTorrent clients, supports Bittorrent Protocol Encryption which uses RC4. And as you can see from the RC4 algorithm, it does use XOR. This happens here in Transmission's code. Base64 is used for handling RFC 7617 HTTP auths of the RPC server in lines 456-467 here.

ioReid commented 10 months ago

Just to follow up, I went ahead and submitted the 4.0.1 qt exe and daemon exe as "incorrectly detected as malware/malicious" through the Microsoft Security Intelligence File Submission page just as a home customer. We might want someone to submit it as a software developer though so it has higher priority.

Reubend commented 10 months ago

Hi @ckerr , I think you may have misunderstood me. I never implied that Transmission's code secretly contains a keylogger, or that any of the maintainers intentionally added malicious code to the repo. However, there remains in my mind a possibility that official builds of Transmission were compromised somehow, without the intent of the maintainers.

Myself and others were infected with malware that's identifying itself as Transmission, so there's basically two possibilities:

I haven't yet seen enough evidence to eliminate either of those possibilities, but the reason I was asking about stuff like the VM detection is precisely because it seems unlikely that Transmission would have that in the source code.

To repeat:

  • Transmission isn't keylogging
  • isn't modifying registry keys
  • doesn't install Windows 10 Pro (WTF?)
  • doesn't check for virtualbox
  • all the other crazy claims in this ticket...

none of that stuff. It literally doesn't even have any code to look at registry keys. It literally doesn't have any code to look at virtualbox. etc. etc. It's not there. Go to the top of this page and use the search window to see for yourself.

Right, that's exactly why I'm suspicious! I searched for anti-VM code, registry modifications, etc inside the source code and didn't find anything. Of course, I wanted to ask here since maybe it's already known that dependencies are adding that code.

Both Transmission's source code, and the scripts used to build the installers, are publicly readable in github. Anyone can check them out & reproduce the build from scratch. Anyone who wants to find out where in the toolchain these things are coming from, e.g. from Qt or libcurl or openssl or libevent or wherever, is welcome to do that.

If I have some time, I definitely will try to investigate further, to find where those behaviors are coming from.

So I'm being asked "please set me straight", why is Transmission using X instead of Y? -- when it's not using either. Search for yourself, it's not in there.

Again, I think you misunderstood; the fact that Transmission is "not using either" is exactly why I'm suspicious here! Maybe a dependency added this behavior for legitimate reasons, but me saying "set me straight" is just a polite way to say that I'm open to being proven wrong if polling keyboard state is a normal behavior. As of right now, I don't think it is.

And when maintainer @tearfur tried to track down the first claims by asking for a sha256 checksum of the file involved, nobody bothered to answer but instead added on more claims about keylogging, modifying registry keys, etc.

Well I'm not the OP, so I can't post the file from his/her computer. But I totally agree with you that if OP can post the SHA256, it would be really helpful. Even more helpful would be to confirm if that version is signed or not. Because if it's signed, that would probably confirm the second possibility, and vice-versa, if it's not signed then it's likely just malware pretending to be Transmission.

To address why I didn't post a sample, I wiped my drive pretty much as soon as I confirmed I was infected, which is why I did my analysis above on the official 4.0.1 build inside of a VM.

OTOH, even when wanting to take security seriously, a lot of the claims in this ticket are just madness:

  • Transmission installed itself without being asked
  • Transmission installs Windows 10 Pro on users' systems
  • Just having the Transmission .msi file in the Downloads directory makes a Windows system autorun a lot of things

I think you're misrepresenting some of his/her claims, so I just want to clarify:

None of these claims are madness. In fact, this is all pretty standard stuff. I understand that it's frustrating to hear about this since it's an annoying problem that is taking time to investigate, and it might turn out that the official builds are safe after all! But nothing that the OP or I said was crazy.

The daemon has anti-VM string references, and also has XOR'd data stored inside of it

No, this is misinformation. The report does not say that the daemon has XOR'd data stored in it. To quote it directly, the " Obfuscated Files or Information" section of the report says Transmission does these things:

My apologies, you're correct about this.

Just to follow up, I went ahead and submitted the 4.0.1 qt exe and daemon exe as "incorrectly detected as malware/malicious" through the Microsoft Security Intelligence File Submission page just as a home customer. We might want someone to submit it as a software developer though so it has higher priority.

I'd like to keep investigating this, and I'm personally not convinced that it's a false positive yet. FYI, a 2nd anti-virus program now detects it as malware, so it's not just Windows Defender anymore.

ckerr commented 10 months ago

I think you're misrepresenting some of his/her claims, so I just want to clarify: Users who installed Transmission noticed that a new version has been installed without their knowledge

No, I think my description is accurate: OP literally says, and I quote, "transmission 4.0.0-beta.2+rbceb368f1b-x64.msi installs Windows 10 Pro." and yeah that sounds crazy to me. I would need to see some proof to take that seriously.

I'd like to keep investigating this,

Sounds good to me. If you find anything actionable, e.g. along the lines of what I was talked about here, or any legit security vulnerabilities in the code, scripts, or tools, please do report them! Regardless of anything else, I think we do all want Transmission to be as safe as possible.

and I'm personally not convinced that it's a false positive yet. FYI, a 2nd anti-virus program now detects it as malware, so it's not just Windows Defender anymore.

After your multiple false claims about hidden xor data and modified registry keys, I don't really care what you're personally convinced of.

But I care very much about any vulnerabilities that can be tested and proven and fixed. If you've got any of those, please share.

Malumen commented 10 months ago

Hey everyone.

Submitted device to work for review/inspection. We use this app to share our big database/development base.

Confirmed by coworkers on some of their (Windows) systems. V0.0.beta2 and 4.0.1 seem to do it.

Sorry @tearfur @Reubend @ioReid I don't have the device to make a SHA, very dumb of me not to check. I've only done it a handful fo times in my life, sorry for forgetting ;/

We also have readouts from defender about registry keys same as other users in here. Screenshots looked like same reg keys etc.

@ckerr and @mikedld my bad I didn't go to school for any of this. I'm out of my depth in opening, coding, compiling your open source software. Hoever, from a another standpoint y'all are sussy bakas as the kids would say.

Point 1: no, downloading and installing transmission does not then cause a cascade of robots to burst into my house, put in a USB with Windows 10 Pro, call Microsoft, and acquire a new key for Windows 10 Pro. That's hilarious and ridiculous.

Instead: app loads (eventually) AutoKMS. You all should know what that is, it's also used in enterprise zones for Win10/11 licenses. You should know way better than me how it works, but we don't use any form of enterprise registration here. Point is: it does, tells the system it is Win10Pro so it can get new featureset, and then after a few reboots and doing an upgrade of windows, it grants access to remote login, keylogging, etc.. Maybe the AutoKMS is to steal and resell license keys, I don't know. I'm just reporting this scary and awful scenario...

Point 2: All the concerns raised in here, your response is just "lol we are open source, check it yourself" and does not address claims at all. The software could have been compromised upon upload to github (installers, not compile binaries). It could have been swapped without your knowledge, or any other manner of behaviour on a website that you do not own. In fact, if we get the software again and it does all the nastiness, your retort is just "look at the code yourself it doesn't keylog you I swear".

We're not saying this is your fault, we are saying the installer and app is doing some strange things...

Point 3: Then you get defensive and lock the thread. You don't test, you don't take down or revise these problematic versions just in case. Strange, suspicious behaviour from devs. And then in the end, you can just say "oh well, if you think its unsafe then don't use it bro" which still leaves it open to "I'm not saying we did anything to steal account info, but I am not not saying we didn't either".

I dunno how hard it is to download a bunch of these versions. Install into systems (hard/virtual), roll time forward/backward to trip the attack... But the absolute "nah bro" attitude. Screenshots, logs, doesn't matter. Ew, you guys are gross.

tearfur commented 10 months ago

I don't have the device to make a SHA

@Malumen On any Windows machine, you can open Command Prompt to type a command to generate the SHA256 checksum for a file. At least we can confirm whether your file has been tampered with after you downloaded it.

> certutil -hashfile "transmission-4.0.0-beta.2+rbceb368f1b-x64.msi" SHA256
ckerr commented 10 months ago

I've probably contributed as much to this mini-flamewar as anyone else. And as much as these wild claims piss me off, I'm going to try and de-escalate and bring it back to the need for actionable information rather than unsourced allegations.

I dunno how hard it is to download a bunch of these versions. Install into systems (hard/virtual), roll time forward/backward to trip the attack... But the absolute "nah bro" attitude. Screenshots, logs, doesn't matter. Ew, you guys are gross.

It's ironic that you call us "gross" for not jumping to spend hours/days on an ill-defined task but aren't willing to even provide a sha256 checksum ... but, OK. I was spicy above, so I shouldn't be surprised when someone else is spicy too. Moving past that.

If I load up an old version into a VM, I don't really know what I'm looking for to trigger the result. But if you and your co-workers have both confirmed the problem, then y'all have useful information that would reduce the guesswork:

If you have actionable information, I'm here for it.

Reubend commented 10 months ago

Hey everyone, I am continuing to investigate and (optimistically) help provide some more info. Since I'm not familiar with any of this codebase, and since I am not an expert in reverse engineering malware, I expect my progress to be slow.

I've probably contributed as much to this mini-flamewar as anyone else. And as much as these wild claims piss me off, I'm going to try and de-escalate and bring it back to the need for actionable information rather than unsourced allegations.

Thanks for this @ckerr , I appreciate you trying to de-escalate and I think your request for more actionable/specific info is reasonable. FWIW, I'm trying my best to find a "smoking gun" which proves whether the malware is merely pretending to be Transmission, or if it's actually from the official builds. This is unfortunately difficult without access to an infected computer, for reasons I'll explain below.

I want to quickly address a few things, starting with the comments above that discuss how to trigger the malicious behavior.

  • What needs to happen to trip the attack that you're seeing?

I dunno how hard it is to download a bunch of these versions. Install into systems (hard/virtual), roll time forward/backward to trip the attack...

Analyzing malware can be tricky, since it's common for that software to evade detection if it detects that it's running in a VM, or with a debugger, or if the host system isn't a legitimate. And while it can be the case that it triggers at a certain date, it could also be the case that it received some activation signal from a C2 server. So merely running it inside of a VM and rolling back the date might not be sufficient to reproduce anything.

I've personally run the official 4.0.1 build in a VM, and I didn't find it behaving the way that it did on my real computer. However, that doesn't mean much one way or the other. I didn't try changing the dates yet.

Malumen, your original report literally said "transmission 4.0.0-beta.2 installs windows 10 pro" and " My windows OS on that system was updated to Windows 10 pro (which is definitely not what it should be)." If you meant this as "Transmission pretends to be running on Windows 10 Pro" then I apologize for misunderstanding your point.

What @Malumen meant was that on an existing Windows system, the malware changes the license information for Windows itself. It "upgrades" the license to a Windows Pro license, even if the user was only running a lower tier of the software previously. That's consistent with the fact that some AV software is labelling is as AutoKMS, which is a family of malware that infects users after they run software to illegally unlock Windows without a valid license. KMS is this case stands for Key Management Services, and it's mainly used to handle license keys for the OS.

You might be wondering why malware would want to do that - we can only speculate here without a really detailed analysis. Malumen's suggestion that it might steal license keys seems plausible, or it could be taking advantage of the Pro version's virtualization support to run part of itself in a hidden VM, where AV software wouldn't find it.

Your concern about the official release being replaced with a corrupt one by some 3rd party is a valid concern. This is why we've been hosted on GitHub for several years now: in order for downloads from https://github.com/transmission/transmission/releases or https://transmissionbt.com/ to be compromised, and for them to still match the sha256sums publicly listed on transmissionbt.com, an attacker would need write access to both transmission/transmission and transmission/transmission.github.io repos. I am not sure how this could be done without pwning GitHub itself.

The most obvious way that builds could be compromised would be through a supply chain attack. One of your dependencies could have a security issue. Or, one of the maintainers could be unknowingly infected with malware. I don't think it's likely that anyone directly accessed the website, or the GitHub, without permission - but it's totally plausible that the builds are unknowingly infected.

I do see some build automation inside of your "sanity" workflow in GitHub Actions. Do you use the artifacts from there as your releases? Or do the maintainers manually upload releases built on their own computers?

  • What OS are you all running?

I'm running Windows 10, and it seems from the original post that Malumen is too.

  • In fact, since you and your co-workers have been able to repro this several times, would you be willing to test this out on a clean system and record your steps so that I can follow them?

I'd suggest that rather than infecting a clean system, it would be better to access any of the infected computers and upload a sample of the malware (ideally the installer). Just knowing if it's signed or not will be enough to answer part of the puzzle here (although I guess there will still be plenty of questions left).

nevack commented 10 months ago
/offtop > The most obvious way that builds could be compromised would be through a supply chain attack. One of your dependencies could have a security issue. If this is true, it's not Transmission is infected with malware. It's some already present malware takes advantage of some newly installed programs. > Or, one of the maintainers could be unknowingly infected with malware. I don't think it's likely that anyone directly accessed the website, or the GitHub, without permission - but it's totally plausible that the builds are unknowingly infected. > I do see some build automation inside of your "sanity" workflow in GitHub Actions. Do you use the artifacts from there as your releases? Or do the maintainers manually upload releases built on their own computers? It doesn't really matter, to be honest. All builds are reproducible. You can fetch source code for specific release and build it. You cannot change a bit of code without hash sum being changed and digital signing being voided. > I'd suggest that rather than infecting a clean system, it would be better to access any of the infected computers and upload a sample of the malware (ideally the installer). Installing official release of specific version on a clean system proves Transmission is not what "infects" windows systems. All I see is you trying to accuse maintainers of being dishonest without any real proofs. Charles on the other hand wants to prove the opposite by following concise steps. It's not fair to ask for complete sec audit of some heavily used system to try to prove something. I can assure you there's no any VM or anti-debugger detection, wind it up and try it yourself, app is as debuggable as any other sane software would be. P.S. Anti virus software can label it whatever it wants, just having "KMS"/"AutoKMS" in it's detection rule name tells nothing about what software really does on user systems. Part about "giving remote access to some third party" is vague speculation mostly based on the name of `transmission-remote.exe`, isn't it? This whole thread makes me very ~~angry~~frustrated. This is very serious accusation with no willingness to help. I don't like this attitude of you, so I put my humble opinion under spoiler to not disrupt already ongoing conversation.
ckerr commented 10 months ago

Hey @Reubend thanks for the good-faith response.

Analyzing malware can be tricky, since it's common for that software to evade detection if it detects that it's running in a VM, or with a debugger, or if the host system isn't a legitimate. And while it can be the case that it triggers at a certain date, it could also be the case that it received some activation signal from a C2 server. So merely running it inside of a VM and rolling back the date might not be sufficient to reproduce anything.

Thank you, I agree. This is why I wasn't eager to jump down that rabbit-hole without some more concrete steps and was a little annoyed at being called "gross" for not jumping into that task. Best yet, if I poked around for hours/days and found nothing, someone here could still say I was just covering things up. IMO a more productive route for everyone involved is to have tangible claims, tangible evidence, and step-by-step plans to test.

I'm encouraged by @Malumen's comment saying it's "Confirmed by coworkers on some of their (Windows) systems" -- if this is happening to multiple people there, with multiple versions of Transmission, then hopefully they have some information on where they got their copies of Transmission, how to trigger the behavior, and what to look for.

I'd suggest that rather than infecting a clean system, it would be better to access any of the infected computers and upload a sample of the malware (ideally the installer). Just knowing if it's signed or not will be enough to answer part of the puzzle here (although I guess there will still be plenty of questions left).

I agree with your bigger point that people who have access to infected computers do have some power to act here.

TBH, though, I feel like if someone wanted to troll the project they could just re-upload an official release here and say the burden of proof is on the maintainers to prove it's not infected. So again, I'm hopeful that @Malumen and his co-workers have reproducible steps that other people can use to repeat their process.

ckerr commented 10 months ago

The most obvious way that builds could be compromised would be through a supply chain attack. One of your dependencies could have a security issue. Or, one of the maintainers could be unknowingly infected with malware. I don't think it's likely that anyone directly accessed the website, or the GitHub, without permission - but it's totally plausible that the builds are unknowingly infected.

Any claim of compromise is a pretty severe claim that requires evidence, but I do agree about the relative odds of the attack vectors you're discussing here.

FWIW my point wasn't to dismiss the toolchain question; it was to respond directly to @Malumen's comment that "the software could have been compromised upon upload to github. It could have been swapped without your knowledge" -- these are reasonable concerns and is why the project changed transmissionbt.com to be a statically-generated site hosted by GitHub. In order for a third party to replace our GitHub-hosted releases & checksums, they would need to gain write access to two different GitHub repositories.

ckerr commented 10 months ago

To circle back to a previous claim:

282213229-473a16e5-2406-40b5-9e5c-15f1c5b1cb89

So I was incorrect to say that it was "changing" the safe boot settings, it was actually just reading them. Still a bit strange to me.

I just downloaded the 4.0.1 qt6 installer, ran 7z x on it, and made sha256 checksums of everything in there. The fun stuff:

8cce99b9bb84c8960fe5a6d5a84cac63dd62feca29476d3997c10fcddadee1d4  libcrypto_3_x64.dll
19ac371375d46c645a321fecf57d3c04e4f2f918cf5d52659cbba2b3c3ff023e  libcurl.dll
18fa31adf22d65d52615dff3bdce103be6fcedba7f5fffcdb04e517e12168200  libssl_3_x64.dll
48fe98f185264cdabdea44dced7509ea4c9e9a421e232fce3c07e261db124af1  qgif.dll
49a29514256aa87b8dbc4cfd730bedabd08a672254ee09fa4e062eb53da2fc5e  qico.dll
91a51b7c78e867a9629c4ec10c6f7194b0f127c6fe0d3854f2115d7ca4a46a24  qjpeg.dll
d1cdcafea7e37e81d3e094699541ff92ac927d57795e496b57f85e43e7041f21  qopensslbackend.dll
9ff95be98c990894b49e3fe2e842dbc186e33a69d4f505953d889a96ca904dad  qsvg.dll
db2ef989fbcceab4a076e82cd31848ebc542240eaa2c367236898fa4e473b00b  Qt6Core.dll
165284b2496b4e85ea2449394e337665c6b210c166ec6bd25a644764cf71d606  Qt6DBus.dll
710de5d7326706f47a686f432970c855da2aeac46d2d50f52a7dd74778c1b936  Qt6Gui.dll
939820239b18457a4398b38d1a1469b1c1849961f379f8d3cd43dc7c710131e3  Qt6Network.dll
a9f8dc148aa768c418f56326750dce1b4b82b4c458733701aa071b5733dbc297  Qt6Svg.dll
177b19942ac20d3997bccb1304beec6f319a8a3d3723e4d3f7bb634d56effa57  Qt6Widgets.dll
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  qt.conf
0e75511bc2aba38bd97e65403901c6da15e6059dd13830abeecb410ac4743040  qwindows.dll
f19b495f7f750691ea6e7f5ac411cc3f1f6e47d2e1c7bd2b17d251511f4e9f25  qwindowsvistastyle.dll
b34d815be8bf34653b158220d6be33b368973c6cd502303fad8c79a25ca0761e  transmission-4.0.1-x64.msi
aac594637aa1abe334dab51276c66349936d2f0b73eba3830ee89f794040b9aa  transmission_create.exe
27f82d0a86f86506acf1c15c6f81c9eec6e2194fde1ba22fcf92bedd353e0ee8  transmission_daemon.exe
b19b4e60783501c19034f214870583b653dcf56710e03285e60d3f63aeda3a5c  transmission_edit.exe
726d1b9e7437192fd2c9290442b491d327fd154557731de89dc7a8081cf927f4  transmission_remote.exe
fc386d2ab22bc11e00c394f3a345b60d5cf74c205828a203abb9129ca15a4392  transmission_show.exe
845fff87743cd2db62c7dd4683dfc901ba91597dcfb3b2d282fff747195deaf6  zlib.dll

Then I started plugging those checksums into virustotal.

Other checksums in that list that touch that registry key:

So, for whatever reason, it seems this is a common key that gets opened by some well-known, well-maintained projects. Unless they are all compromised, the Occam's Razor answer is that there is an innocent explanation, e.g. maybe calling CreateProcessW() checks to make sure Windows is in a mode that allows processes to be spawned.

If you feel that touching the SafeBoot\Option registry key is a red flag, please take that issue upstream to those projects and/or ask Zenbox for more information.

Reubend commented 9 months ago

FWIW my point wasn't to dismiss the toolchain question; it was to respond directly to @Malumen's comment that "the software could have been compromised upon upload to github. It could have been swapped without your knowledge" -- these are reasonable concerns and is why the project changed transmissionbt.com to be a statically-generated site hosted by GitHub. In order for a third party to replace our GitHub-hosted releases & checksums, they would need to gain write access to two different GitHub repositories.

Got it, that makes sense.

If you feel that touching the SafeBoot\Option registry key is a red flag, please take that issue upstream to those projects and/or ask Zenbox for more information.

No, I think your point here is convincing. The SafeBoot\Option registry key must be pretty common if all those projects open it.

I also want to circle back on a behavior that I pointed out earlier. I noted that the executable contains strings referencing Zen and VirtualBox, which got flagged by the AVs as "VM detection". I did a lot of analysis on the binary, and I found out that the reason for these strings is that Transmission identifies files with a hardcoded list of MIME types / file types. In this code, it establishes some types for Virtual Box files. So Transmission doesn't detect whether it's inside a VM, it just "detects" files that are pertaining to VMs like Virtual Box, Zen, etc.

There's nothing malicious about the usage of VM strings in this context, so I'll consider this avenue of research (the VM detection) closed. Transmission identifies VM-related files for legitimate reasons, so even a clean binary would trigger this detection rule, and we can't use that a signal that any particular build is infected.

Reubend commented 9 months ago
Here's a reply to @nevack which I'm collapsing by default to keep the thread on-topic.

> > The most obvious way that builds could be compromised would be through a supply chain attack. One of your dependencies could have a security issue. > > If this is true, it's not Transmission is infected with malware. It's some already present malware takes advantage of some newly installed programs. No, you're misunderstanding how a [supply chain attack](https://en.wikipedia.org/wiki/Supply_chain_attack) would work in this context. If a dependency was infected, then the official builds could be infected even though there was never malicious code in the Transmission repo itself. Then, when a user installed it, it would infect their system. This has nothing to do with taking "advantage of some newly installed programs", but rather the possibility that Transmission itself contained malware. > It doesn't really matter, to be honest. > All builds are reproducible. You can fetch source code for specific release and build it. > You cannot change a bit of code without hash sum being changed and digital signing being voided. I looked through the Windows build instructions, and didn't see any instructions for signing. Since the official builds are signed, wouldn't my build have a different hash? Or is that automated as part of the build process somehow? I searched through the codebase and I didn't find anything that lets users do this. > Installing official release of specific version on a clean system proves Transmission is not what "infects" windows systems. As I shared above, malware analysis isn't that easy. You can't always just install it on a clean system and watch it immediately trigger all of its behavior. You can read more [here ](https://www.oic-cert.org/en/download/Anti-Analysis%20techniques%20(OIC%20Talk).pdf) if you're interested. > All I see is you trying to accuse maintainers of being dishonest without any real proofs. > Charles on the other hand wants to prove the opposite by following concise steps. > It's not fair to ask for complete sec audit of some heavily used system to try to prove something. I didn't accuse the maintainers of anything. If you read my posts above in this thread, it's clear that I am not saying any of the maintainers intentionally put malicious code in. Charles' request for specific/actionable steps is reasonable, as I said above. I never asked for a complete security audit. However, since 4 different anti-virus programs now identify the 4.0.1 version as a virus, and since there are user reports of a virus identifying itself as Transmission 4.0.1, and since the rbceb368f1b beta version is being occasionally flagged as well... Don't you think that justifies some investigation? > P.S. Anti virus software can label it whatever it wants, just having "KMS"/"AutoKMS" in it's detection rule name tells nothing about what software really does on user systems. > Part about "giving remote access to some third party" is vague speculation mostly based on the name of transmission-remote.exe, isn't it? The name is relevant because it confirms that the malware _does_ change Windows licensing info. That's one of the "symptoms" of the malware, and it's useful to know all of the possible symptoms when you're trying reproduce the malicious behavior. Regarding remote access, I don't think that Malumen's claim was based on that - at least he/she never mentioned `transmission-remote.exe` as the reason for the claim. It's extremely common for malware to open the computer to remote access, and in fact it would strike me as strange if it changed the licensing info without opening the system to some kind of remote access. > This whole thread makes me very ~angry~frustrated. This is very serious accusation with no willingness to help. I don't like this attitude of you, so I put my humble opinion under spoiler to not disrupt already ongoing conversation. I am helping, and I'm doing my best to investigate more despite being unfamiliar with this codebase and despite not being an expert on reverse engineering malware. If you read my past posts carefully, I already said that there's a possibility that this is malware pretending to be Transmission, rather than Transmission itself. But for now, both possibilities are still plausible. I respect your decision to put the post under a spoiler, so I'll do the same for my reply.

mikedld commented 9 months ago

FWIW there might be an action point (or two!) here.

Despite every release build being prepared in a clean environment provided by Microsoft itself (i.e. AppVeyor), part of each build is spent on building the 3rd-party libraries (slow) or using the prebuilt 3rd-party libraries if those exist (fast). The latter is only possible through the former (i.e. if there's no prebuilt 3rd-party library to use, it gets built and uploaded to AWS S3 bucket, so that it can be quickly downloaded later) so we're still the ones building those libraries, not someone else. Nonetheless, when prebuilt libraries are being retrieved from the AWS S3 bucket, their checksums aren't being validated, so potentially a malicious actor could influence the build by gaining access to the AWS S3 bucket (the secret for which, mind you, is only stored in AppVeyor, which would mean very bad news for either Microsoft of Amazon). By storing the checksums in AppVeyor's private cache (which can't be influenced except by gaining access to AppVeyor infrastructure, or to GitHub repositories that describe the build process; both certainly possible but I won't guess the odds) we could validate that what we uploaded before is unchanged.

Don't take the above as a proof/declaration of Transmission release pipeline being easily compromized even in its current form, at least not its Windows part we're talking about here. I'm NOT saying any of release Windows builds currently in existence and matching those published on GitHub (and matching checksums published on our website, for the most recent release) are in any way affected. Just a thought for improving things going forward, to add to everyone's piece of mind.

Sidenotes:

P.S. Release pipeline security is a valid concern, but is probably better discussed in a separate thread, far from this one that's supposedly caused by Defender definitions update (I can't even force myself call it irresponsible or bad as obviously testing such things is a big hurdle, that's why reporting it to Microsoft (or another vendor) is a good idea; this reminds me of #5200, and the VirusTotal link there now shows 3 issues with the MSI package while it was one at the time the issue was reported and I clearly remember it going down to zero after a short while :shrug:).

Reubend commented 9 months ago

Thanks for this info Mike. I think for now, we can just rule out the scenario where the build process itself is compromised. It's possible that someone got access to AppVeyor, but that seems unlikely to me. Your description of the build process sounds pretty secure, and I can't think of any particularly notable flaws. I'm assuming here that AppVeyor uploads the finished releases directly to GitHub as an automated step?

On a somewhat related note: is @nevack correct that I can reproduce the exact build with the same hash? I didn't find any signing steps skimming through the build instructions + codebase, so I'm guessing that my builds won't match the hash of the official ones since they're not signed. But maybe there's a pre-image signature or a fancy cert injection step that I'm not noticing?

mikedld commented 9 months ago

Signing happens at the end of the tagged build on AppVeyor, which may not be obvious by just looking at it (see docs): https://github.com/transmission/transmission/blob/4be0dca5ac9b57f246050efaf32ae8a9fbcf8800/appveyor.yml#L115-L121

Every signing request must be approved manually (for open-source projects, which we are) so it doesn't happen w/o our knowledge.

Uploads from SignPath to GitHub release were automated but this isn't working for the last couple of releases (due to changes on AWS side) and I'm uploading the files manually. Still, there're checksums in SignPath that I'm verifying for every release, and of course I plan on fixing that automated upload (via webhook mentioned in the docs linked above).

ckerr commented 9 months ago

OK one more question answered: qwindows.dll also sets off the keylogging warning.

https://www.virustotal.com/gui/file/0e75511bc2aba38bd97e65403901c6da15e6059dd13830abeecb410ac4743040/behavior

The detection rule for logging keystrokes via polling is here, and it's scanning for Win32 API calls like GetKeyboardState.

Here is Qt using GetKeyboardState() and also GetAsyncKeyState(), which both trigger the warning:

https://github.com/search?q=org%3Aqt+GetKeyboardState&type=code

https://github.com/search?q=org%3Aqt%20GetAsyncKeyState&type=code

ckerr commented 9 months ago

Transmission 4.0.1 sets registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Certificates\AuthRoot\Cerfiticates\B7AB3308D1EA4477BA1480125A6FBDA936490CBB\Blob reported by @Reubend here. Status: Not yet investigated.

OK I took a look into this.

Owner: CN=SSL.com Root Certification Authority RSA,O=SSL Corporation,L=Houston,ST=Texas,C=US Valid Dates: 02-12-2016 to 02-12-2041 Serial No: 8875640296558310041 Thumbprints: MD5:86:69:12:C0:70:F1:EC:AC:AC:C2:D5:BC:A5:5B:A1:29: SHA1:B7:AB:33:08:D1:EA:44:77:BA:14:80:12:5A:6F:BD:A9:36:49:0C:BB: Signature Algorithm: SHA256WITHRSA Version: 3

So both the key & value appear to be legitimate & innocent. And it's easy enough to guess why an installer for a signed app might fetch + cache some ssl.com checksums.

But I'm not the primary on the msi installer, so maybe @mikedld has an opinion

ckerr commented 9 months ago

Summary of issues / claims made so far in this ticket:

Unresolved

Resolved

mikedld commented 9 months ago

SignPath certificate is issued by SSL.com (see below). We're obviously not doing anything about the certificates ourselves, but can't stop Microsoft loading/caching/etc. them when the installation package is opened.

Explorer -> .msi file properties -> Digital Signatures tab -> Details -> General tab -> View Certificate:

image image

Reubend commented 9 months ago

Hey all, I wanted to add some updates here. First of all, I can share that running the 4.0.1 build in a VM with the time set forward or backward (as Malumen suggested) doesn't trigger anything weird. So if the official build was compromised (again, note the "if") then the most likely triggering mechanism would be a remote signal, and there's no way for me to easily repro that.

I did notice that the beta version referenced in the issue includes a DLL named qopensslbackend.dll which gets detected by the Chinese AV software Jiangmin as being a trojan that's designed to steal passwords from the user's computer. This would match with the possibility that dependencies of the project could be compromised. However, I believe this is probably a false positive. The reason why is that Jiangmin often detects this file as clean during re-runs, and when run using different settings (i.e. inside of a different meta-AV engine that configures it differently) it usually does not flag that file. In addition, I'm guessing there are tons of other OSS projects using that same dependency, which lowers the likelihood that we're the first to discover anything novel there. Since I'm not knowledgeable enough to reverse engineer the DLL directly and poke around, I'm concluding that this is just a false positive. However, if anyone else wants to follow up, the SHA256 of that file is 31b1fba1603acb12b3f4150340e07a4532f33b26e3f56ab924f85265cdb774b5

All of the concerns I posted about here with the official build (anti-VM strings, key state polling, setting cert registry keys) have been completely addressed, and there are legitimate explanations for all of those specific behaviors. I appreciate everyone's help here in investigating them.

I also noticed that some of the AV detections which were present last week disappeared this week, so I thought it might be helpful to share a summary of those:

AV Software Detected Malware Classification Notes
MS Defender HackTool:Win32/AutoKMS!pz No longer occurring on 11/18/23
Rising Hacktool.AutoKMS!8.CB6
McAfee AA7ACEEBF036
Cylance Unsafe software
Ikarus Potentially unwanted app No longer occurring on 11/18/23
Skyhigh Potentially unwanted app
DeepInstinct Malicious software No longer occurring on 11/18/23

On a personal note, this week I fell extremely ill. I'm infected with both Covid and the flu at the same time according to my test results, and so I'm not feeling well enough to continue researching this situation. My apologies for not being able to contribute further. Yes, I do realize how ironic it is that I got real life physical viruses in addition to the computer virus. My parting message here is that by far the most helpful thing going forward would be a confirmed sample of the malware.

mraonea commented 9 months ago

This is a bunch of nonsense with all this conjecture until the OP comes forward with something tangible.

PUA = Torrent software

The rest are just heuristic signatures and some noname "AV" that dont even bother with any labeling.

This is not a virus signature either: https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?Name=HackTool:Win32/AutoKMS!pz

ckerr commented 9 months ago

On a personal note, this week I fell extremely ill. I'm infected with both Covid and the flu at the same time according to my test results

Oof, that's rough. Thanks for the update and get well soon @Reubend

NovHak-Linux commented 8 months ago

This is very possibly done on purpose by Microsoft. Yet another of those to serve you better things that are really aimed at serving someone else’s interests.

In the old days of ED2K, Emule was the most widely used client, and there was this mod called Ketamine, a “leecher mod” as they said, which would permit to bypass some leeching restrictions while at the same time severely impairing seeding. The goal was clearly to kill the P2P network, but fortunately it didn’t work well in the end. I’m not sure any formal proof has been found, but there was a strong suspicion that majors such as Sony or Universal (just given here as an example) were behind the creation of this mod.

I doubt that majors and other right holders view BT any better nowadays than they did ED2K back then, and despite the P2P network being neutral by nature, would very much like to prevent it to exist as much as possible. Hence I’m seeing what’s mentioned in this thread as a consequence of such a policy.

ckerr commented 8 months ago

Summary of claims/accusations and their resolution @ https://github.com/transmission/transmission/issues/6227#issuecomment-1811822833.

The only remaining issue is the one originally reported by @Malumen, who has not responded to requests for more information over the last two months.

I'm closing this ticket due to lack of information, but am leaving the ticket unlocked. If any new information comes to light, please share it so that it can be investigated.

ckerr commented 6 months ago

Noting that it's been 100 days since OP last responded in this ticket to call the maintainers "gross" and "sussy bakas" but has not yet found the time to tell the maintainers how to reproduce the security issue, even though they claim that they and their co-workers were able to reproduce it.

romeomihalovics commented 4 months ago

My defender also alerted me about this, just a few days before, as I had to reinstall the program with the latest version image image the installer: transmission-4.0.5-x64.msi