Malware when installing Unity Hub & Editor?

Something strange (and kinda scary) just happened to me when installing Unity Hub and 2020.3.30f1. On a freshly installed MacOS 12.3. Not much else installed, only managed to install XCode, Sublime Text, MS Office 365 apps, Teams and Affinity. Nothing dodgy or questionable. Had the same set installed for years on all my macs.

I'm not sure when precisely, likely when installing the Hub or when starting 2020.3.30f1 + Visual Studio install via the Unity Hub, but an empty text file appeared on Mac desktop called "WITH-LOVE-FROM-AMERICA.txt".

Which doesn't sound very good and sort of scary...

Anyone else with this experience?

 

yeah I got the same thing, it is being discussed here too:
https://www.reddit.com/r/technology...lovefromamericatxt_appearing_on_your_desktop/

 

Oh crap. So this is some sort of anti-war protest thing? I'm still biting nails. Almost settled on clean wiping the mac just to stay safe.

Anyone form Unity team on here to confirm it is indeed harmless?

What on earth Unity has to do with Node packages anyways? While I completely support any reasonable anti-war activities I think this one is a bit over the top TBH

I'm generally super paranoid about what I run. Only a small set of trusted s/w from well known established sources yet here we go. Showing just how vulnerable we are. A random Node package developer being able to do whatever he wants on everyone's computer. And I don't even have Node installed nor the packages! At least not as a standalone manual install anyways.

 

I was seriously considering the same thing. Just how much productivity and money will be lost as a consequence of people wiping their systems, thinking they've been hacked?

The person who did this may have had the best of intents, but I don't think they realize how people and companies will react to such an intrusion.

Poorly thought out.

 

Phew, no need to wipe the system! Having already wasted half a day to clean install everything just this morning...

Thank you Richard!

 

Scary, especially since I just got a warning from videocopilot about installers on their site having been corrupted with malware, so it does seem like infecting installers of well trusted sites is an attack vector that is actively being used right now:

 

Holy S***, I sorted my desktop icons and it's really there. Scary stuff.

 

Hah.

It is "peacenotwar" module.

Basically in past three weeks there were several nodeJs libraries which attempted to do something regarding current situation, by printing political messages or worse.

I'm aware of two of those.

The first one was es5-ext.
https://github.com/medikoo/es5-ext/...f01e4ce7c74e9a356b2af2#commitcomment-68471721
That was printing stuff on terminal.

The second one was here:
https://github.com/vuejs/vue-cli/issues/7054
That one was more malicious, as it was supposedly attempting to wipe your files if it thought you're from Russia or Belarus.

The situation is similar to faker js and colors js situation from february.

The one you got is the one that was supposed to try wiping the files.

Would be a good time to reconsider using nodeJs in any project, in all honesty.

 

Or host the nodes yourself and use one or two hours of manpower per week to check whether to update the mirrored nodes.
That should be reasonable for projects of the size like the Unity hub.

 

Last time I dealt with an npm project, it has pulled something like 1800 dependencies. I do not think it is on the level where you can reliably check it all, and additionally javascript is a language that has "eval". Meaning it can transform data into executable code and the data can be pulled from anywhere. In the linked example, the coder used base64 encoding to obfuscate some of the data.

In all honesty, Unity Hub to begin with is not a project where it makes a lot of sense to use nodeJs.

Also two manhours per week is a lot.

 

Wow, I thought this was going to be a dumb or joke post, but nope.
It’s quite scary to learn that the hub is using code that Unity hadn’t audited and apparently never had any auditing in place prior. This would seem to be a huge lack of judgement and Unity may have just got lucky this time it wasn’t more serious.

what troubles me more is the lacklustre response from Unity to both informing their customers and users about this issue or providing very clear steps in terms of how they can win back trust in using the hub. Simply saying you’re audit. Stuff now is NOT good enough. I want to see a commitment from Unity that they will make the results of such an audit public, or even get a third party to come in and do the code audit. I need to know that the hub and all past versions are safe for use. I would expect at minimum to see this as a blog entry and supported with announcements in the forum and on social media.

from what I’ve read of the issues around some of nodes, Unity may have been luckily it just dumped a text file onto people’s. PC’s and didn’t simply rewrite all the files with heart emoji’s! Honestly I can’t remember a worse security breach that a company could have exposed their users hardware to.


Edit:
The further I look into this, the more worrying it becomes.

Whilst I can only speculate based on what I've read it would seem that the node in question was the one that originally would over-write all your files if your IP was deemed to be Russian ( approx 8 days ago ). It was later retroactively changed to just dumping a file on your desktop. So it seems Unity was super F***ing lucky that there automatic update of the dependency on this node managed to miss the first version, otherwise they could be looking at having been responsible for wiping goodness knows how many customer/users harddrives!

Of course this is speculation, because in typical Unity fashion they have refused to be open about this issue. They have not named the 'third party' software that was at fault. They have also only acknowledged that the was a 'inconvenient' issue in a couple of posts discussing the issue and AKAIK made no effort to raise awareness of the problem to user base - frankly that pisses me off.

As I said above, this incident has shown how vulnerable we are to security threats via the Hub ( what about the editor? ) but I see little coming from Unity to provide any reassurance that there are not hidden/unknown dangers yet to be found. By which I mean I would expect a sticky post that provides frequent or at least day by day updates to the auditing of the Hub and any other third party software that might provide an attack vector.

Its not as if this is new we had the log4j issue and specifically with npm the Colors Attack

 

@Noisecrime Fear you are exaggerating a little bit. NodeJS is a very common system out there used and trusted by many thousands of applications. Normally there is not as much of danger because the packages are going through public reviews.
It does become a problem only once devs themselves go rogue...

Still the Hub is not a cutting edge software that'll need the brand newest packages all the time, so self hosting and updating occasionally could still be an easy solution.

@neginfinity I wasn't saying they should review the code, but just to check whether any known issues (like this one) occured and not update if that's the case.
How are 2h a week much for a crucial part of the companys product? I'm definitely spending hours at work with way more neglible things.

Of course you do not achieve absolute safety. That's never possible.

 

Yes. As someone mentioned "this S*** would seriously overwrite your filesystem with heart symbols"

And that seems to be a problem, because apparrently the language itself is not very secure and neither is the central repository.

I think the situation actually indicates that it would be a good idea to have something more secure that is either heavily sandboxed or can be restricted to a subset of safe API. For example, if the module in question was never allowed to access file system, or was never allowed to write in any area beyond a single specified zone, this situation wouldn't occur.

GPG signing is used for similar purpose, but it is again, placing trust into someone. Would be nice to have a system where malicious code cannot act even if it makes through the safeguards.

 

Thanks Leonhard.
This is much improved over the initial statement, being far more open and informative. Its also good to see it get its own thread in announcements and not just a reply buried in a thread. Though to be honest I don't recall ever visiting announcements forum directly, so maybe it could be boosted a bit.

I still feel that Unity ( and many other companies ) will need to be more proactive regarding the flaw this has exposed in using third party code and would very much like to see ongoing efforts such as a blog post on it in the future to provide the reassurance that such an attack vector could never be exploited.

We've already seen how serious an issue like this can be with regard to log4j and had a previous wake-up-call with regard to nodejs ( Color Attack) now I feel Unity got super lucky with node-ipc, but this has to be the last warning sign. I hope that Unity will take the time to evaluate the safety of using such third party code as well as audit any such code that is also in the editor.

 

Not sure it is an exaggeration since it has happened and this isn't even the first time to open source software.

Sure we didn't get the full on scorched earth result this time, but it must surely only be a matter of time now, especially as this time its not simply a rogue/disgruntled developer, but based around a political/social statement that effectively weaponised open source software ( which I think is new within this context ). Reading through some of the posts on github is scary the level of support for the both versions of the code got from a small subset of users, due to it being 'for a good cause' or other reasons.

Honestly if I were a company like Unity ( and probably much smaller companies ) I would be seriously looking to remove all dependencies on such open source code use. Its clear now that it will be weaponised again in the future, just a matter of when not if and I'm not sure relying on crowd-source validation or in house auditing is enough.

I do agree that no software can be 100% safe ( unless you write it yourself ), even if Unity didn't use any third party code a disgruntled employee could still slip in something malicious, but in terms of being pro-active to protect ones company I do think things will have to change with regards to open-source, or at least how its used.

 

https://github.com/RIAEvangelist/peacenotwar/issues/45
https://github.com/RIAEvangelist/node-ipc/issues/308
https://snippet.host/kvcb
https://security.snyk.io/vuln/SNYK-JS-NODEIPC-2426370 (Risk assessment value of 9.8/10!)
https://security.snyk.io/vuln/SNYK-JS-PEACENOTWAR-2426724
https://github.com/RIAEvangelist/node-ipc/issues/233#issuecomment-1072163549 (more versions with comments available)

From what I'm seeing it does indeed seem like Unity got lucky to not have pulled (one of?) the even more malicious version(s) which would LITERALLY replace the content of every single file on your computer with a "♥" symbol if you happened to be in russia or belarus or nearby or simply using a VPN, if the IP-address check still put you in that region!

It has happened, see first 2-3 links.

@superpig / @LeonhardP I think this should be escalated even more, warranting sending an email to every single registered user to inform them of the situation for visibility! (Even if there is currently no active threat coming from the Unity Hub, developers might be using other tools which were/are affected (e.g. Vue.js). Heck, I even only found out about this because I randomly stumbled over a post on an image board!)

 

Also lucky that it was obvious, and not something that quietly did something malicious on hundreds of thousands of their customers' machines.

Plus, now there's a clear and present opportunity to get their house together in regards to this. Microsoft warned people about this early last year (official paper) after a security researcher published an article about breaching a whole bunch of organisations with a fundamentally similar attack.

Edit: I'm glad to hear that Unity is auditing this stuff, and didn't just fix that as a one-off.

 

Yikes, thanks for the link to that Microsoft paper, it is really interesting and highlights just how easy it was to penetrate a whole bunch of corporations that the public use on a daily basis. Granted not exactly the same type of attack as here but still using package managers as the weak link.


Which brings me round to our own Unity Package Manager. Its something I've been using more of recently, mostly for my own packages as its a nice clean way to architect code, but whilst I only use a few sources outside of Unity ( assuming Unity's packages are completely secure here - and yeah that's maybe not the best assumption ) I think this latest attack shows just how easy it would be for a developer to go rogue and totally screw up a lot of developers.

In fact I've realized just how trustful I've become within the Unity eco-system, from asset-store packages to external scoped registries, and that will have to change as although these things have different levels of security concerns, it is clear to me now just how exposed we've all become on both a personal level and potentially as a vector delivering software to our own clients/users etc.

 

Again, let's not have a few bad apples spoil the bunch please.
The answer to such risk cannot be to retract in our shells and waste effort on re-inventing the wheel by developing everything in-house etc.

@Noisecrime
On Unitypackages however, do you update always when a new version comes out?
Since few assets are large scale projects that have the resources to ensure backwards compatibility in all details (what requires elaborate testing) it's everything but rare that an update would break my project, so I look in detail whether the new functionality is actually something I need.

That's what other industries do with packages aka "libraries" too. A dilemma arises when those libraries somehow have connectivity to the outer world and thus can be misused by hackers. In that case you usually want the newest version because otherwise run risk having publicly known security holes.
What happens if many do not update immediately is something we witnessed with the Log4J vulnerability.
That is also the reason why js node has gone the way of updating by default. Similar how you regularly run "sudo apt-get update" on a Linux system (Consumer builds of Ubuntu run it regularly in the background by default too).

 

Only where the code is being used blindly. Those vulnerabilities weren't about general use of 3rd party code, they're cases where either updated code is used automatically, or where internal sources could be replaced with external ones due to poor configuration.

Unity's Package Manager doesn't update official stuff on its own, as far as I know, you need to tell it to grab a new version of a package. Assuming you're paying attention and test your stuff that cuts the risk dramatically.

(I can't remember how it handles 3rd party sources, though.)

That is not the suggestion.

Choosing to use 3rd party stuff is fine and often necessary. The problem is when you lose or abandon control of your code base, especially when it's hooked up to a continuous deployment system. Don't do that.

 

Why not? Frankly its the only way to guarantee your company does not expose itself to such threats and personally if I was running Unity I would be looking to minimise any dependency on such systems for something like the Hub rather than solely rely on auditing.

So yeah I don't think anyone is saying we need to completely ditch third party code, but relying on package portals is clearly a huge risk now ( nice list of threats and risk events ) . So ultimately the answer is to develop methods to mitigate risk as much as possible, from removing dependencies to extensive auditing to manual updates.

Unfortunately I'm rather sceptical about auditing as it requires having developers with expert level knowledge of the field and code to do it properly, and that's before you get into things like obfuscation ( the initial node-ipc code that overwrote all your files was obfuscated ) both deliberate and accidental ( ie. bad coding styles ).

Not a simple question to answer, especially as Unity Package can mean packages or asset-store packages.

While I don't necessarily update packages whenever a new version comes out I do update every time I start a new project ( say average of 6 per year for clients, and dozens of research projects for potential clients ) and frequently when open a project especially if waiting for bugfixes or new features to be added.

The same is true for Asset-store packages, I tend to update them for new projects or when updating an existing project.

But i'm not sure the point to this is? It seems to me you are trying to claim safety via 'herd' or 'safety of numbers', where by if you aren't the first to update to a new package you wont be the one to get hit by any malicious code. However the folley of such a claim should be obvious and its not a solution.

As for automatic updates, that's what got us into this problem in the first place, and Unity was damn lucky they didn't release Hub 3.1.0 a week earlier as there is a good chance they could have got the node-ipc version that wiped your hard drive if you were unfortunate enough to be considered using an IP address that originated in Russia.

 

Yes unfortunately Unity has 'conditioned' me to pretty much manually update all packages, both through necessity as so much stuff is buggy or missing features as well as through UI design - I want all my packages to have that nice green tick next to them

However I think the issue goes deeper - for example I believe that updating a package will automatically reload scripts and domain and thus can effectively run any code in that package before you get a chance to audit it! That to me seems to be a serious issue that probably needs addressing.

Anyway I feel the whole Package/Package Manager is a different discussion, one that i'm working on a new thread to discuss in and I feel any discussion should probably happen there.

Phew - well i've made the post in the Package Manager forum here. I think I've covered everything I wanted to, but its taken a few hours to write and layout and I keep thinking of new things. That's why I wanted to make a thread about the subject as I don't think any single person can cover everything and its important to get other view points and ideas.