A look at cloud gaming app security through Amazon Luna.
Hello! This week I am writing a post about the need for cloud gaming security. The ecosystem for playing videogames through CSP’s is expanding at an incredible rate thanks to platforms like Microsoft’s Project X Cloud & Game Pass Ultimate, Sony’s Playstation now, Google’s Stadia and Nvidia’s Geforce now. Even gaming with online multiplayer through means such as Parsec and HP Omen are proving to be quite popular to the eSports niche.
A bit of background to start. Some time ago I did a bit of tinkering with work with some Nintendo switch homebrew. Nothing earth shatteringly new, just a bit of android-booted streaming in-home to play PC games around the house. Switch consoles with early revision firmware have an exploit which allows loading custom firmware, so adding a native boot loader was the de facto way to get homebrew getting on your console. I also showed off a way to get the game Genshin Impact running on the system. I posted a few pieces on it through Reddit. I did so through cloud, android emulation and native android methods, so if you’re interested do take a look. This will likely be the only way to play this and other PC-centric games on switch until the port is complete.
My attention was drawn to the new Amazon Luna service. I ended up taking a look at that what this product offers. it’s another service kind a like GeForce Now or Project X Cloud where users can take a look at games that they can stream from the floor from their home consuls to their other devices as Amazon response to that they’re offering sure about on par with a GeForce now. I decided to take a look at the service while it was still in beta and test out hardware, software and network interactions utilized.
https://www.amazon.com/luna/landing-page
I wanted to primarily investigate the Amazon Luna controllers, yes they have a controller and funny enough it’s an Internet of things device. If you read XKCD, you’ll know that having a billion nanomachines connected to the internet might be the only thing that can stop a skynet gone rogue.
These devices promise to make our lives easier, but does connecting one to the internet guarantee a user’s security? As of April in 2021, it does not. So did Amazon nail that aspect of it, or does their implementation leave gaps for would-be attackers to leverage?
One thing you should know if that I’m outlining the process of how to do so, but now how to leverage what someone finds during these investigations. This guide is for demonstration purposes only.
This breakdown covers all the tools used to take a look at each resource. A quick summary is below:
iPhone SE1 running iOS 14.2.1 – Used to connect to the luna controller, issue commands and interpret communications.
Wireshark – Run on a Microsoft Wi-Fi direct channel with the controller and luna streaming device of choice
Process Explorer – A windows program swiss army knife made by sysinternals. Can view strings, file permissions, startup scripts, inbound and outbound network connections, process threads and inherited permissions, all in one effective GUI.
Nmap – Local network scanning.
7zip – Archive explorer to view executable components and DLL’s at rest.
Notepad++ - General .EXE disassembly for at rest components
Burpsuite – Used for network communication interception. Ran on its own server with certificate pinning on iPhone SE.
Amazon API page – Leveraged by the software to issue commands on logged in accounts.
Actual power tools. - An attempt was made to open the device unsuccessfully.
fcc.io – Hardware internals and schematics.
After being accepted into the closed beta for amazon luna, I dedicated about 6 days into looking at the service. Here’s a breakdown of what happened day by day.
Day 1:
Tools: Vmware player, Windows PC, 7zip.
This area is the most foggy to me. I think I noted that the installer did not pull from the cloud like most services. Once the software booted, I decided to test a typical keyboard shortcut for a dev console. A typical keyboard command for this is Ctrl+Shift+I. Low and behold, up pops a familiar chrome based web console.
Chrome embedded framework has incredible application in modern tech from Github Desktop to Postman to Discord to everything in between. Often, these tools can also be accessed with remote debugging by manipulating the windows shortcut with commands. Such attacks require local device access and are highly unlikely to occur, but there is potential to cause harm if exploits are chained into leveraging this type of tool. Some dev consoles even support live page viewing and updating, letting someone write self-XSS into the program. Again, these process’ aren’t exploits unless leveraged through the internet. This is a key piece to keep in mind when testing a web based platform though, so this was a good find to start off.
I also ordered a controller. Internet of things has ways of being handled both securely and insecurely over the web. If this service is handled in an insecure manner, such as leaving ports open, then there would be a big issue on amazon’s hands. I’d find out this was the opposite and that amazon had some tricks up their sleeve for this.
Could improve:(In hindsight running regshot for this step would have also proved useful.)
Day 2:
Controller would get here saturday which means I can spend a good deal of time on testing it early, huzzah!
Tools: Notepad++ and ProcExplorer
Found some lingering development leftovers, a token and some odd strings in the code.
The token I found out from asking around was a standard windows UUID/GUID identifier. Every piece of software that runs may be assigned this as a unique hex-based identifier. Occasionally these are use as database access keys, but this is very uncommon. One thing to note is that there are insecure versions of UUID and GUID that can be reverse engineered, most notably UUID 1. The 3rd and 4th octets contain the version and number generation schema respectively. The most common at this point in time is UUID 4, which is generated at pure random.
Having put most of my day into learning about this, I couldn’t find anything else but a couple of listed directories used by internal development to store the project’s files. While this might be useful for enumerating the inside of the network, getting this info from a file as opposed to a shell is tedious, slow and might not be up to date. Still, it’s much less noisy than having a shell run inside a network and is a useful way to think outside the box.
Areas for improvement: (I wish I had the reverse engineering skills and ram viewing tools for this step, though most of those require a ton of mapping and extra work. Such tools may be able to spot ram weakness’ and opportunities for buffer overflows.)
Day 3:
Tools: Burpsuite
The controller arrives in the mail. This is where the bulk of work with Burpsuite took place. Did I find anything? Well in a way yes.
Before that, I noticed a hackerone challenge recently with a related AWS subject. I saw it during the challenge’s final hour. I had already crafted the ideal exploit in theory thanks to my work with the controller. * This would be:
CSRF to capture the outgoing resource request on the challenge page>determine the AWS request token from a packet reflected through another site>check for permissions using the amazon API tool> clone the token with a longer TTL>access to the backend system through the API console.
I did not have time to test this as I did not own a web domain to reflect to*.
*(Yet. Stay tuned for more updates on that area .)
Anyway, I needed to rewrite this whole section a couple times to make it as clear as possible. There’s a lot of connections utilized by the Amazon Luna controller. You need a controller to smartphone connection, device to network, device to internet, device to encryption key, device to API, smarphone to API, and device to remote AWS software. In all that complexity introduces a plethora of opportunities for security misconfigurations or failures.
The most shocking finding I felt was a lack of something called “Principal of least privilege” That’s when a user is granted access to a tool that’s much more powerful for a job than it needs to be. You don’t need a chainsaw to make a campfire, so why waste the resources supplying one, especially if that same chainsaw could fall into this guy’s hands.
Okay okay jokes aside, the controller uses a temporary token that potentially gives access to personal user info on amazon’s API. Is this necessary for a gaming device? I feel it really isn’t. It also looks like the device is constantly searching for the same token to grab from a logged in amazon account. Once it finds the user is logged into luna, then it can access the services.
There's a ton of caveats that prevent this from being bugbounty worthy. Device access, what’s on the networtk, etc. If an attack can be chained off of this, surely this may yield some genuine concern.
Things to improve:(Knowing how to leverage API calls, API interactions and test each and every identifier variable for privilege level. Graphql, postman, newrelic, and similar services escape me. I only learned about a month ago how to make valid Microsoft Graph queries from API’s with its 3 key system.)
Day 4:
Tools: Wireshark, NMAP
Another look at the controller, this time through Wireshark. I created a network through Windows Wifi-Direct and put both devices on that port.
There were some interesting phone home protocols and checks used for the wifi network ID and for the device itself. Other than that, it’s TLS encrypted from start to end, even during gameplay. Amazon sure does have their work cut out for them. Without the key used, it’s anybody’s guess what the data in there could be. A potential attacker would be better off tapping into devices on the network with a connection to amazon’s servers to determine credentials.
Also, an NMAP port scan revealed that every single port on the device was closed. Checked the range from 1-65535 and still no luck. It does use some unencrypted traffic to check if the service is online, if it can connect to amazon’s backend and to do the TLS exchange. Beyond that, it’s secure. I have no idea how to approach this connection at this time.
Things to improve: (One thing I want to do here is try and understand the TLS key trade without having the private key, if possible. I would like to test Fire OS connectivity to this device, and just need the right resources to do so.)
Day 5:
Hardware dissection day!
Tools: Power tools and hardware.
The following day I decided to attempt opening up the controller. If youtube is any indication, modern video game controllers are notoriously difficult to disassemble. Not like the tinkering I used to do with my gamecube controller when I was a college Melee-head.
Despite that, some easy prying around the front and back plates were easy to remove, 6 keyed screws weren’t much trouble as well as I had the right bit. The problem comes in with the clips holding this thing together, it’s nearly air-gapped and inaccessible. Attempts at prying broke the screwdriver I was using. My next goal was to procure a dremel to further my disassembly of the device. A user or two on reddit were counting on my work at that point.
Day 6:
Other projects started to divert my attention, but I decided to end my connection to this one by following up with chaps on Reddit.
I remembered researching RFID for video games led me down a rabbit hold to a site called fcc.io. Part 15 regulations require documentation of radio communications devices before they are sold to the general public. I plopped down the controller’s FCC ID and look at the results. The device in prototype form was on display, but chips weren’t labeled on the internals. There were also no obvious test pins I could determine without knowing the chips and their purposes. Oh well, at least I know how this thing is constructed now.
Areas to improve: (Taking the controller apart for one, perhaps the chips are inside this thing are viewable with labels. Having more time to hardware reverse engineer.)
Conclusions and next steps:
I have a lot of directions to go with this research. I’ve got regshot and some snapshot tools at the ready for the next investigation, memory viewing tools seem extreme but prove useful nevertheless. I’ll have to try an amazon fire OS device with the Luna, as well as some API gathering tools. Some seem to be higher priority than others, but the device shows promise aside from a couple minor hiccups. I hope I can be of help improving Amazon’s Luna service once they open the platform up to bug bounty.
That would wrap up my analysis. I think I put about 16 hours into this plus 4 for the blog post, but also had work and such holding me back. I’ll likely revisit this controller as it continues to develop. In the meantime I’m working on my certifications. Busy weeks ahead, plenty to talk about next month as well. Thanks for reading, stay safe!
