Malicious Entity Injection (MEI) to do a Laughing Man style attack on X Reality
I thought what I’d do was I’d pretend I was one of those deaf mutes, or should I?
“What I thought was fifty years away, was only ten years away. And what I thought was ten years away… it was already here. I just wasn’t aware of it yet.” — Bruce Sterling
A note about terms: X Reality is the spectrum of reality, virtual reality, augmented reality, and mixed reality. When I’m using the term XR or X Reality, I mean anything from VR, AR, MR, holographic displays, or future tech I’m not aware of that fits in the spectrum. Yes, this does include augmented reality overlays in cybernetic eyes. An HMD is a Head Mounted Display or an XR headset.
XR is necessarily intimate to the user & their psychology. It provides the ability to manipulate the user in the real world. What if I told you that game engines don’t verify the content they load for XR applications?
What is MEI?
I’ve theorized an attack surface for XR and related applications that I’m referring to as MEI — Malicious Entity Injection, the name taken from Mei, my favorite character from Blizzard Entertainment’s Overwatch First Person Shooter. Hypothetically, MEI could be used to gain credentials from a user, or perhaps convince them to run code that could result in a shell, however the implications of this attack vector are a little bit further reaching than that. What if you could alter a Mixed Reality app used with an XR headset to overlay a logo over a face to conceal someone’s identity? Sort of like The Laughing Man from the popular cyberpunk anime Ghost in the Shell? What if you can insert a malicious object that could cause a person driving a car with XR hardware and applications running to become so distracted, it leads to a car crash? What if you caused something offensive to be displayed to a foreign diplomat, in the midst of diplomatic talks that immediately soured the situation? It sounds far-fetched, but as XR continues its steady march of progress, the possibilities are seemingly endless.
In this example, due to lack of content validation of what’s being loaded in Unity3D it is possible to use a specially crafted asset bundle to inject an entity to attack the user of an X-Reality device. While in the past this would have been minor due to either being on a computer screen or a lack of the ability to inject behavior, with the rise of XR HMDs combined with the rise of visual scripting that can be attached to entities and saved/loaded in unverified content this leads to the potential of code execution that can be used to manipulate a user with real world consequences. When combined with the ability of certain visual scripting systems to use .Net DLL reflection to load every function from all DLLs loaded you get access to a lot of functionality including rendering, GPS data, and web requests. Choose your weapon, time to play. This becomes a military fashion show.
So what are some real world effects this could have when XR is more widely adopted? Think of this as a weapon of war. This can be used to do anything that can be done by manipulating a user’s training or perception of the world around them. I would classify this as useful for anything from a prank to starting a global thermonuclear war (would you like to play a game?). Humans are the target and although it can be used to target the device and tech as well, that’s standard out of the box stuff compared to this and there’s nothing new about that.
Mixed Reality is coming, and we are all about to get blindsided. Game devs for years have considered security to mean “anti-cheat” more than “anti-shell”. #infosec on the other hand for a long time has treated game engines and games as more of a hobby than what it really is, the baseline of the next generation of computing interfaces and work. Businesses see it as “oh that’s cool experimental tech, but it’s only experimental” and while vendors are researching it a lot of the security R&D is focused where contract work is, and this is too niche at the moment. Realistically, web interfaces can be made with game engines and when more 3D displays become standard anything XR, from game engines to things like A-Frame and React VR will be the default app creation tools. Mid to long term as we have augmented eyes and XR glasses used in the operation of machinery and widely used in positions like Air Traffic Control and tank commanders (both of which are currently a thing) we could see XR glasses get hacked and have the content swapped around to do real world harm.
How plausible is this to be exploited? Luckily in the short term it’s not a major threat to consumers, but could potentially be used to target industrial and government sectors. Mid to long term could get very interesting as the technology becomes more widespread which is why I’m doing this now, so hopefully it gets fixed before it becomes an actual plausible thing to target the masses.
It’s easy to see augmented eyes hacked to social engineer someone to their death or in to pulling a gun on someone causing an incident that could potentially be fatal. With 2D the stakes are kinda low. So someone swaps a gun model in Counter Strike? Who gives a fuck? What happens when real world counter terror units are running around waving guns around with XR headsets or full body cyborgs with augmented eyes with XR overlays built in are running around? What happens if someone pisses off the wrong person. It’s not like this has ever gotten way out of hand in the past.
So what’s the story, how did I come up with this?
On the side, I’ve been working on figuring out how to get a project I’ve been prototyping to work well; this involved a lot of learning software architecture. Part of this was researching asset bundles for Unity3D as a means for supporting customization. In the process of researching Unity’s documentation on asset bundles I initially looked at a deprecated function and found that the asset bundles in the old method were loaded in with a function, and then the function also had an MD5 hash passed to it. That’s a broken crypto algorithm but and shouldn’t be used. At least they didn’t go down the roll your own hashing or crypto algorithm route (if they had I’d scream). I then realized that the function was deprecated for another function. The new function pulled from HTTP, but had absolutely zero validation involved (wow, the new functionality is less secure than the old one by design, what the actual fuck). It blindly trusted the asset bundle downloaded. Admittedly some of the functions had CRC32 as optional verification, however let’s be real, CRC32 has no security value at all.
At first, I thought, meh, so what? Then I realized *what could possibly go wrong*. Beyond specially crafted asset bundles designed to exploit the application through normal means what if I could load a script in the asset bundle? What if this could lead to code execution? At this point, I started reading. I found out that Unity3D doesn’t support including scripts in asset bundles. No scripts in asset bundles, OK, so we’re somewhat good, right? You can’t load scripts, so you fuck with a model, so what? Yeah it could cause some issues in some situations, but… I walked away from it for a while thinking “well, it looks like Unity designed this somewhat decent at least, not a huge problem after all”.
After a short break, I came back to the asset bundle stuff and realized something: “wait, what if I used visual scripting assets, do those count, would those get blocked out as scripts?”. At that point I was thinking “OK, I have local, but if you have shell, they’re already fucked.” Then I realized you can load assetbundles from the web and stream them from memory. At this point, I needed to test, so I pulled up the editor and tried it and oh shit, it worked. I also had the realization that just swapping models and assets could get someone hurt. I won’t go in to the disclosure process, primarily out of not trying to shame or be salty but I will say it was less than productive and this is something where this does need to be addressed. In the process I was rejected from speaking on this topic by four cons and it was a big waste of time — months), however I feel not fixing this is a mistake as I feel this attack could put lives in danger if not fixed early. I am releasing this anyway because if this can get fixed, it might save lives.
So enough talk, time to show what can actually be done. In the spirit of Pastor Manul Laphroaig; POC||GTFO.
Phase 0: Why does this work?
Before I demonstrate the actual process to create and exploit the malicious payload and the vulnerable way of loading the content, I’d like to point out how and why this works. It works because Unity3D loads asset bundles raw without verifying content as long as it has the right “interfaces”, or more accurately the right entities in the right named asset bundle. Anything nested in those entities is also loaded. With this you could either nest malicious functionality in what should be loaded and appears to be a legitimate asset or you can replace it. Unity3D and game engines in general only look for the name/path and if that checks out it loads without verification of actual integrity of the content itself.
Phase 1: the content creation
For this I’m going to use the basic asset bundle loading example from Unity3D while loading from the web as a target. The code for the app is available at https://github.com/peter-clemenko/mei-pubrelease so I won’t go over that, instead I’m going to focus on creating the valid and malicious content itself.
Here we create the default content, a standard asset bundle with code right out of Unity3D tutorials. The only difference is using Nodify as a tool to enable a flow to be attached on the entity. This is what allows code execution.
Note the point where it asks what the name of the content in the asset bundle and the name of the asset bundle are. That’s all it looks for in loading and this is exactly what we are exploiting. If it matches the entity name and the asset bundle file name it pulls a honey badger and loads it. Note that in order to find the vulnerable entry point all you have to do is pull up the assembly in the Unity app in production in dotnetpeek to reverse engineer and start looking for assetbundle handlers in there.
At this point, I’m going to create the malicious attacking file.
Once the malicious entity is set up, just package it up.
Phase 2: Exploitation
Start bettercap and run a MITM. In this case, the data is sent over HTTP, so you need to use the HTTP module for bettercap. That being said, this also works locally as well, see the bonus example for that. Now let’s see this in action.
DEAF MUTE BONUS: Let’s make this interesting
It would be fail of me not to do this, but what happens when you throw face recognition in the mix? Let’s say you’re taking a nano tech / cybernetics corporation CEO hostage because he’s involved in a cover up of a cure for cyberbrain sclerosis, a disease that affects augmented humans and their cyber brains. You hold him at gunpoint on the news and want to conceal your identity while trying to get him to admit the truth about the cover up on live TV and make your get away.
So in this hypothetical, a Snapchat style app is installed on the AR device that uses OpenCV to do facial recognition and already has the ability to overlay objects on the face (the ability to overlay objects on a face, or for that matter transform a plane (or other object) in front of a face could be done through visual scripting or with basic OpenCV primitives. I’m not going that far with this and realistically AR applications may well have this functionality already). In this example there is a paid asset I can’t include in the open release. But with them you can reproduce this easily. Facial recognition and masking is not far fetched for anything using Augmented or Mixed Reality, and actual detection of individuals is plausible as well (although out of scope for this example). This uses the OpenCV asset off the Unity3D asset store, so re-implementation is pretty simple. Regardless, I’ll show the actual flow in Bolt (another paid asset I can’t include) to show how this works. This is not restricted to that system, and to my knowledge any Unity3D visual scripting system could be used.
Now let’s see it in action.
I should note that this is currently based off a webcam. AR headsets really use a webcam to gather video to do their magic, the only thing changing is the projection method which is easy to swap between apps and HMDs. With minimal modifications this could go from a 2D example to a Meta 2, Hololens, BT-300, or in theory a Magic Leap (Magic Leap is still very sparse on documentation available, but in theory it should work). This is hardware agnostic and is game engine and app based, not targeting the hardware itself. Further applications could gather data such as credentials or GPS and send it through REST or GraphQL to an attacker as an example.
Wat Do? How Defend? Build Ice Wall?
So how does one defend against this? It’s not like we could just build an ice wall and make the hackers pay for it (get out of here Sombra). The fix for MEI is content validation. Hashes, encryption, and content signing are the way to go; throw in some heuristics/machine learning if you want to be a Fancy Bear. Luckily, this particular PoC can be averted by simply using HTTPS and hash checking but this is really the lowest hanging fruit over the wire PoC I could do.
So is this the big one, will it cause a Spectre of Meltdown? Probably not, at least at the moment. This is going to be a bigger problem down the road. For now it’s somewhat mundane and it’s not a major threat to most people because the technology is still very new and not wide spread which is actually the reason why this is exactly the time to fix it — prevention. The main area I can see this being a threat in current terms is targeting medical, military, or industrial XR applications. I strongly suspect nation states have had this in their arsenals for a while and with the amount of resources they have I’d be shocked if they didn’t, especially given the use of XR in the military sector. In 1–5 years though, let alone 5–10 as hardware and XR adoption catches up this is going to be a major issue on the consumer end. It’s better to solve it now before it becomes an entrenched issue and we have to back patch security issues after the software has been out there for a while and enterprises have gotten rooted in their ways; prevention is the priority.
What game engines are affected?
The main one tested was Unity3D, but to my knowledge, no game engines actually check for content integrity of what they load, so I would venture to say (damn near) all of them. Unity was just the one with the widest hardware support and easiest to test on. Throw in things like A-Frame and React VR, ohhh my.
I have [device], does this affect me?
The hardware is irrelevant, this is a software implementation level issue in game engines. The attack is honeybadger toward the hardware. It doesn’t give a shit what hardware you have.
Does this have a logo?
No; if someone wants to donate one though...
Really? Game engines? Virtual Reality? Augmented Reality? Hacking that of all things instead X?
I like to take the Feynman approach.
“Study hard what interests you the most in the most undisciplined, irreverent and original manner possible.” — Richard Feynman
Also, the Dual Core approach:
You said you Mei-n Mei in Overwatch, was the name intentional?
Abso-goddamn-loutely. I came up with the acronym and then invented the attack for the acrynom. If you believe that I have a bridge to sell you for 9001 bitcoin.
Isn’t this just a Man in the Middle attack?
This was one of the big things I wrestled with before dropping this. For this demo, yes. That being said, the core fundamental here isn’t about MITM as that can be substituted with others, but about fucking with the user’s sense of reality around them. This isn’t an attack on the software, but an attack on the wetware through the software. This is social engineering the target through injecting the entities, so while the actual attack seems “meh” on a technical level, the actual implications go much further and are separated from only being technical.
Fuck if I know. I will say that 2018 is going to be *very Ghost in the Shell* when it comes to XR infosec. I do have a few more things in the works in the XR security space, each more Ghost in the Shell than the last. In 2012 I set out to make Ghost in the Shell tech real (which was a big part of why I went full infosec/XR instead of gamedev) and I’m still on that path. 2017 was the year cyberpunk really started becoming a bit too real in the plain view of the normies (it always was cyberpunk for those paying attention) and for better or worse, 2018 will be Cyberpunk As Fuck.
How can I help?
Depends, if you mean help the cause, hunt more vulns in XR apps and devices. Help seek out new vulns and new pwnage, to boldly pwn where no hacker has pwned before. It’s better to pwn it now so it gets fixed now, than to let it become a problem later. Drink all the booze, HACK ALL THE THINGS!
If you mean help me, I’ve been unemployed since February 2017 and I could use a job or contract work to keep the lights on. Also, if you’re a XR hardware manufacturer I could use hardware to work with as well, more gear is always welcome and opens new doors. Money’s dwindling and gear is expensive. I am working on another project as well, a tool called NAVRIE but I’m not going to rush it and I want to get it right. XR still needs time to evolve and bad content will taint the medium in the public eye; shovelware will kill my favorite medium and I can’t contribute to that happening. I might release a 2D version in the meantime. A quote sums up how I feel about that project: “A delayed game is eventually good, a bad game is bad forever.” ~ Shigeru Miamoto
Is there more coming?
This is only the beginning. I still have a lot of work to do. Besides, given everything considered there’s a quote I think is more appropriate than normal… “Our world is worth fighting for” ~ Mei-Ling Zhou — Overwatch
A little bit of clarification as to why this took months to drop, and why I sat on this for so long. Besides waiting on con talk CFP status for this (all four cons rejected the talk), a bug bounty that got rejected, and hardware; the biggest factor was uncertainty. When I was developing this attack, I thought it was awesome, I finally created the Laughing Man attack from Ghost in the Shell. The problem is, this was so niche, so hard to describe, so weird, so odd, so esoteric, and so edge case and specific in scenarios that I thought this would be invalid. The more I looked at it though, in current software and hardware, this is very edge case and not realistic but in the coming years this will be standard affair. As for the name, I kept doubting the injection aspect of the name, as it felt more like side-loading or swapping an asset instead of actually injecting anything. The more I thought about it though this felt similar to another vector commonly used in malware, DLL Injection. This is just DLL Injection with game engine content instead of a DLL, and yes it can lead to RCE in some situations. The other thing I kept thinking was this was literally just using the stuff that’s already on the app, is that really an RCE? Well, if you look at pretty much anything involving modern red teaming, the favorite tactic is to live off the land and use the existing software on the system to do your dirty work. For a long time I held back because I was unsure, I felt like a phony and captain obvious for bringing this up. The more I think about this though, this is what a red team would do to attack XR. I can’t help but think that in a way this is just that god damn obvious. After Meltdown and Spectre I made the final call though, the reason why is because those things went unfixed for so long that damn near every modern system is vulnerable to those two attacks. If I can help get this fixed across the board early so it never becomes a major threat, that’s what I want. What I don’t want is this going under the radar and people get hacked in critical moments that could potentially get people killed. My concern here really isn’t data, it’s the wetware using the XR device. I want this fixed at the root cause to save those lives.