Team Research blog
Mirror is an open-source multiplayer game framework for Unity. The history of Mirror is pretty interesting, I’d encourage anyone interested to give it a read on their site. Long story short, it was built as a replacement for UNET (which was provided by Unity but had a number of issues and was ultimately deprecated). Mirror … Read more
In my last post I talked about a way I found to execute arbitrary code in Unity using no custom scripts, only built-in components. This allowed potential attacks against Unity games that load AssetBundles from untrusted sources since, although AssetBundles can’t include custom scripts, they can include GameObjects containing these built-in components. The attack I outlined in that blog used UnityEvents, which are primarily exposed via Unity’s built-in UI elements, but the attack required user interaction to trigger.
In this post I am going to discuss a zero-click method of triggering UnityEvents, along with some additional things I’ve learned on this topic. I will also introduce a new exploit that does not use UnityEvents and removes one of the limitations of the UnityEvent-based attack (while adding limitations of its own). Finally, I will give some updated remediation thoughts.
This post discusses the process of searching top GitHub projects for mass assignment vulnerabilities. This led to a fun finding in the #1 most starred GitHub project, freeCodeCamp, where I was able to acquire every coding certification – supposedly representing over 6000 hours of study – in a single request. Searching GitHub For Vulnerabilities With … Read more
The Unity game engine provides various means for getting external assets into a game, such as AssetBundles, for adding assets at runtime and the Asset Store, for purchasing third-party assets.
It’s possible for a GameObject to execute arbitrary code using no custom scripts, only components that are available by default in Unity. If the game uses Bolt or another visual scripting system, there are even more paths to code execution. In this blog I will cover how a malicious GameObject might get into a game, two specific methods I’m aware of for the GameObject to execute code, and possible ways to mitigate the risk.
The Unity game engine has a package manager which allows packaged code and assets to be imported into a game, with dependencies automatically handled. Originally this was used only for Unity-produced packages, such as the GUI system. Later Unity began allowing private registries so that game studios can maintain their own internal packages. The IncludeSec research team found that the previous advice to Unity game developers to stand up their own package manager left them vulnerable to dependency confusion by default.