action: defines the in-game action (sending a message, demolishing a building, attacking someone, etc). Thus the game has a messaging system which allows you to either contact your friends or all the people in your alliance, or even people who are not yet your contact (enemies, possible allies, etc).I decided to fuzz this messaging system to find vulnerabilities.Usually I would use the Burp Suite but this game did not present many protection techniques like encrypting or obscuring sensitive data of the petitions so I quickly took a glance with Firefox Inspector and network monitor:Firstly I sent a simple message saying “Hello” to some person and analysed the petition:"actionRequest": "310725177c5713e52f6c217c09f7ac86", The business model is based on micro-transactions and a special “premium” resource.One of the peculiarities of the game once you advance is your growing-rate, which increases if you join an alliance, or make friends. Later, with the rise in popularity of smartphones, the developer created iOS and Android versions of the game.On this game you control an Island and your aim is to achieve growth by managing the different resources available. Here transporter is present resources.This is a writeup for a serious vulnerability I found on the popular web and mobile game Ikariam Game Analysis □Ikariam is a purely web-based game and was released in 2009, when browser games were at a peak of popularity.The most obvious target would be the content field, which contains the message body.Before that, one could believe we must obtain the new actionRequest token. Let’s get down to business! Persistent Cross Site Scripting □Having a stable and comfortable way of messing with the messaging system I proceeded to search vulnerabilities. Usually we would use two accounts under our control, but I rapidly found that, by changing the receiverId value to my own userId I could send messages to my own account and test further without alerting any other user!In fact the game is confused and thinks Ikariam? has sent me the message. actionRequest: unique per-session per-action tokenThe other values are not really important.After this I proceed to manually tamper the different values.In addition, the injected payload is totally invisible to the user, which can still receive a legit-looking message. Secondly: It also works without modifications in the mobile version!The code will be executed any time the user opens the message list or the message itself. Firstly: the XSS is executed before the message is opened, just by opening the message list (as the web pre-loads the content of the first 10 messages or so in the page). For some reason, it is not in the messaging requests! I can reuse the same actionRequest for sending messages and it won’t be refreshed unless another different kind of request is done (exiting the messages window, changing the map, attacking someone.) so that measure is completely broken here.I tried the simplest XSS payload of them all to see if there was some sort of sanitizing in place:After analysing the behaviour of the page I found the vulnerability is even more serious than it seems.
Ikariam Scripts Password For TheAfter reversing for some hours the mobile version of the game I found, among other things, that it uses a different API endpoint with sightly different requests, this is going to be important later.But for now, to launch attacks and send payload we need a user account on the server where our “victim” is, thus we need a pair of user:password for the tool to work with. Interacting with the victim’s game session and gaining in-game advantage of the exploit.To do so, I built my own tool to weaponize the vulnerability and make the process fast and automatic. Therefore I decided to explore a different aftermath. Inject further scripts (adverts, crypto miners,…)The first three kind of post attacks are well known and there are hundreds of examples of payloads on the web.![]() Once your code is executing on the target device, it must first detect wether it is running on WebView or in a PC browser, and use the corresponding endpoint accordingly, as the session from one endpoint cannot be used in the other.There are examples available in the repository which show how to differentiate between the webview and other browsers and extract the so called requestAction unique token. This is why the API endpoint is important. DarkRagweed does this automatically.In addition, if the target is the mobile WebView version, the context is different and you will need to adapt payloads. For example, as I mentioned before every time you perform a request you need to provide a unique value which changes, thus it is necessary to scrap the website after each request to gather the new value and build the new requests. There are some technical details I won’t get much into. It requires the requests and BeautifulSoup Python modules.After being logged in, you can search for users, send them messages with payloads, etc. Auto clicker emulator for macIn the Ikariam case, this exploit allows you to obtain massive advantage over other users, as just by sending them a message you can force them to send you all their precious resources, force them to demolish their own city, leave their alliance, and almost whatever you can imagine. This is, by the way, a nice trick for bug bounties, as the bounty can be higher if you show that the vulnerability can be used to take advantage over other users. It can be easy to find errors and vulnerabilities in systems, but not everyone can do the post-research to further investigate the application or system and develop customized, targeted exploits. More importantly, how this vulnerability was customized and exploited in a particular case. ConclusionsOn this writeup you have been able to see how I found a serious persistent cross site scripting vulnerability. The exploit is still unpatched.
0 Comments
Leave a Reply. |
AuthorKyle ArchivesCategories |