==Below is the original, partially-redacted report== --------- Hi, The core issue here are two things: 1. The too wide crossdomain.xml located at: ``` https://payment.unibet.com/crossdomain.xml https://se.unibet.com/crossdomain.xml https://www.unibet.com/crossdomain.xml ``` 2. Issues with not-in-scope subdomains. As you see, the crossdomain loads in a lot of sites in it, and due to this, all these domains are allowed to make requests as the victim completely without any validation or interaction what so ever. This is bad in itself when having some external sites and really old non-taken-care-of websites (travnet.se and menmo.se are two good example of that), but I wanted to also show that even subdomains of *.unibet.* can be bad. In my case, there's a SWF-file located on l.unibet.fr: ``` https://l.unibet.fr/unibet/video/PerformLivePlayer.swf ``` This domain is obviously not in your current scope. But it doesn't really matter since it currently allows full control over the domains in scope. This specific file is an AkamaiPlayer, what's interesting with it, is that it has a parameter you can send to it called `akamaiMonitorSWF`. This is used for an analytics SWF. However, since you can change it, the SWF being loaded gets full access to the current SWF, making it possible to act as the parent SWF. And since the crossdomain.xml on `se.unibet.com` looks like this: ```

``` We can now fully control the current user with this injection of our own SWF. I have made a pretty broad and extensive PoC for this, basically fetching out all messages, info about the customer as well as changing the email-address of the current user. This is because I want to show how bad this really is. ### PoC My PoC does the following: 1. Fetches all messages to the current user 2. Fetches email+phone+sessionId for the current user 3. Fetches the current address for the user 4. Changes the email of the current user to `frans.rosen+unibet[RANDOMNUMBER]@gmail.com`. There is a rate limit of changing the email, but it's just 30 minutes and the email only needs to be changed once anyway. You might need to change the `se.unibet.com` to any other locale you're currently using. You can also change the email differently if you like of course: ```html

``` Result: ██████ The account shows the changed email on the account settings page: █████ The new email we changed to gets a "email changed"-email, the old email does not get anything: ██████████ PoC-movie: █████ As you see, I'm able to command the SWF at l.unibet.fr using my injected SWF into it to make certain calls, which in this case is a bunch of GETs and a POST. I did not see any CSRF-tokens that was needed either, but it wouldn't have matter in this case since I would be able to claim them anyway. The PoC is also hosted here for now: ``` https://detectify-labs.s3.amazonaws.com/test.unibet.ato.html ``` If you're signed in into `se.unibet.com` you should be able to just access that file and the email would then change to my account. ### Mitigation You need to urgently modify the crossdomain.xml of payment.unibet.com and *.unibet.com, this is my best way to explain this. Removing the SWF on l.unibet.fr will only prevent that specific file from abusing this, there are most likely more of them on the amount of domains you're using. Also, you're allowing external companies (like iesnare.com) with a wildcard, which basically leaves it up to them if you would be vulnerable in the future or not. Please consider this when cleaning up. Regards, Frans ## Impact Having the ability to completely takeover an account by just visiting a link is extremely dangerous, the concept of the crossdomain.xml allows so many domains as wildcards. Also if you fix this, remember that `*.unibet.fr` might seem like a wise choice, since you own that complete domain. But as I showed in my example, even `l.unibet.fr` is just as dangerous.