Click here for free TV! Chaining bugs to takeover Wind Vision account

hi everyone my name is leo and today we're going to talk about wind vision or how an attacker could change a series of bugs to take over your account this talk is split in four rough sections we'll start with a few introductions then we'll take a deep dive into the vulnerabilities then we'll go with its closer process and finally we'll close with a few tips for both developers and security researchers if you watch about myself my name is leonardo sauces and i work at ssu consulting which you might remember as mwr infosecurity i have a bit over five years of experience in the industry earning a couple of certifications along the way most of this time i've been a mobile

security enthusiast but lately turned it to netsec directory and reptony stuff this is actually my first ever talk as a presenter i would normally include my hobbies here as well but the pandemic changeover for those who aren't familiar with the name wind is the second largest telecommunication provider in greece and with vision is a digital television service allowing for live and on-demand streaming of sports greek tv channels movies series and so on it comes with a dedicated set-top box running android tv or you can just download the mobile application available for android and ios devices log in and watch tv on the go from your smartphone it's also worth introducing software software is an iptv infrastructure

vendor and their solutions are used by telecommunication providers of multiple countries around the world the findings we'll talk about actually affect software's solution called nex4 as this is what wind vision is using behind the scenes something that was observed during this research right so let's jump into the technical analysis i'll try not to focus a lot on the details as it's all out there to read through at your own pace okay so before going forward it was taking a glimpse of the future to see how it all looks like from a higher level before we get deep into the tech talk so here's what the final attack chain looks like don't worry it's too complicated for now

the gist of it is that a malicious application could exploit certain vulnerabilities in the wind vision application and chain them to steal the user's session and what is known as an account takeover attack but let's get back to the beginning let's see where they all start from and how we got to them so this is literally the first screen you see when you launch the android application it all starts from this transition so in order to log in you navigate from the app to webview powered by chrome as can be seen by the url bar then back into the native app this last step is tricky though as you need to declare a url scheme to pass

any tokens retrieved in the browser back to the app this is called linking and it's a typical form of android inter-process communication or ipc and it's implemented using an intent filter specifying a data element an example url which the app can then handle is the following which carries the code parameter value as we can see however this is not the most secure way to do this as this deep linking method evident from the bare intent filter which does not perform any further verification presents a problem and has thus been replaced with slightly different scheme turned uplinks where uplinks better than tip links you might ask so when multiple apps declare the same url scheme such as https chronos last

aw.youtube.com through deep links the user will be prompted with a dialog box to select the handler application a right click there could lead to the wrong app receiving sensitive data that was intended for the legitimate application this is known as url hijacking and the malicious application could not only declare arbitrary schemes to hide access to urls but also trick users into setting it as their preferred handler disabling all future prompts the solution the developer could instead use an uplink by specifying an additional element in the intent filter but we'll tell the system hey these are my urls and i can prove it by hosting an asset link adjacent file essentially on that domain which then skips the handler all

together and opens the intended app no questions asked and this is what the json file would look like essentially it's just a list of applications that can register this url this file is checked by the system our install time okay so that's indeed an issue but only in this configuration so far as we'll see this is a pivotal one though for the overall attack as it will allow us to cross the application boundary for now though we can only just make a note and revolve the checklist the next question to ask is where did that code come from to answer that we need to dig deeper into the authentication flow and to that we just follow standard

mobsec methodology that means we root the device choosing the disk we proxy traffic using burp and pin the tls certificate using freeda and then we looked at the last http request capture after the authentication so one trick i typically use to figure out what credential an application needs is to start from the end look at an actual authenticated api request progressively stream parameters and headers repeating it to the server until it starts complaining to figure out what the absolute minimum requirements are and then look back in the http history trying to see where each of these required values were obtained and how in our case all that was needed is these two headers the credential or key passed in the

authorization header and the device id let's start with this authorization key and let's look at the overall authentication flow as we said before when the app starts it spawns a webview which immediately reaches the slash authorized endpoint of an identity provider server and gets redirects to the login page the user is then prompted for the windvision credentials and username and password once the webview posts to the login form and gets another redirect back to a url which the app has registered for allowing for this code parameter to be passed back to the native code now back in the app the code is exchanged for a token which the idp sends back in this third step

to make one final step in the authentication process this time exchanging the token to an aws server for a key which is then attached to all api requests through the authorization header indicating an authenticated session so here that's an example api request the key along with the device id header which is probably a hardware identifier is sent to wins graphql api server and that fetches user data such as the user's favorite channel etc so this is it this is what a normal authentication flow would look like end to end but if you remember in the third step where the code is passed between the app and the webview we found that the url hijack is possible

in which a malicious application could steal these codes from the webvision app and exchange it for a road token and then a rogue session key which can be used to reach the graphql apis and get all user data why is that even possible is it a vulnerability in the authentication protocol and what is this protocol we've just seen anyway after doing some research they stand out to be an openid connect flow in short oidc with an authorization code grant so oidc is related to war ii and it has had its fair share of troubles in the past as mozilla explains oidc abuses auth2 to perform authentication as oauth2 in itself is an authorization protocol and while this is not necessarily a

problem if used in the wrong circumstances it can lead to vulnerabilities and this is a very common mistake with such vulnerabilities reported all the way back to 2012 this is why a security extension to the protocol was eventually standardized called pixi or pkce to mitigate the threat of authorization called interception and this is a threat prevalent to mobile labs such as wind vision where the authenticity of the initiating clients cannot be guaranteed to do so pixi describes the creation of two additional parameters state and the verification token which work as a csrf token of sorts it's initially sent to the idp server as part of the authorization request then we sent at the later stage when requesting a

token and this essentially allows the idp to check if both requests came from the same client and that no codes have been intercepted so back to our case since there's no pix implemented a bad app can hijack a code exchange it for a roll token and even get a row key can we use that key to appear authenticated to the api server thus achieving a full takeover the answer is no as we still have this device id header which the server needs so we're stuck there's still a missing piece to find out what this is we once again went back into traffic analysis and eventually figured out that the graphql server only accepted requests with a valid

device id header that is one that has been previously uploaded after a registration process so we as a malicious application can therefore either create and register our own new device id using our rogue session key simulating the registration of a new device which could unfortunately replace an existing device as wind only allows up to four smartphones to be registered for streaming something the user would probably notice or we could just guess an existing a previously registered device id and use that in our rogue requests so after decompiling the application and examining the relevant code this is how the responsible function looked like and this is how it actually looks like in a form that makes a bit more sense

we can see that it all boils down to a media drm object instantiation which only accepts a constant uuid value and then the get property array method of this object is called which is again also past constant value so as we can see there's no real uniqueness there's no randomness involved this is a function we can just copy into a bad application execute on the same device as the windvision app and always get the same value which means we can essentially regenerate the device id for the victim's device on demand okay so it looks like we've got all the bugs we need so let's take a step back and see how we can put it all

together first we'll hijack the url and steal the authorization codes then we'll abuse the insecure oauth2 flow chosen to get a road api token we'll reproduce the device id for our victim device to attach in all subsequent api requests and finally just demonstrate our account take over chain with a scary toast notification showing some personal data or whatever so we need such an example api request for demonstration purposes one that fetches something small not too sensitive but still personal to make a good poc a good proof concept this means we're back into birth so while looking in the web log for a juicy api request to perform for demonstration purposes uh we see this one this was literally

the first one after authenticating can you see anything funny so at this point i was wondering what this master pin code was but if you remember from previous slides wind vision has this maximum number of devices restriction and the user should be able to change these four active ones from somewhere within the upright that was indeed the case the user can manage the devices from the application settings choosing devices class accounts type there these master pin codes and then go to device management where they could just remove rename etc via active devices so while not necessary for the account recovery chain as i ended up using the names of the registered devices for the demonstration

this handling of the master pin codes is bad practice and doesn't really offer any sort of security to the solution in any case time to write this bad boy so this is what the project looked like of the magnificent application we coded on the left we can see the url hijacking functionality using the intent filter to declare the same url scheme as windvision and steal the code in the bottom right segment we can see the functions that executed the api requests needed to go from a code to a token and the actual function that reproduces the device id and in the top right we can see some covertness to essentially call the real application windvision

in case anything goes wrong which is how real malware will behave the calls for this proof of concept malicious application can be found online on fcq's github repositories to play around with the app is now patched and the update enforcement mechanism in place might stop you from using an older version but you might be able to bypass that so we found the vulnerabilities demonstrated how they can be exploded coded an example malware application and all but how possible actually is all that one could argue that this isn't realistic as they would have to have a targeted malicious application installed on their device which should have survived play stores defenses in first place and that they would never fall for that

wrong choice in the handler if prompted to answer the first question we should keep in mind that we as users are very unlikely to scrutinize all the features of each application we install and even if we would we've seen reputable apps turn to bad ones whether intentionally or through a security bits so there's realistically no way to be 100 sure as for the second condition there are hundreds of cases in the news every year of malicious hops spotted and removed from play store despite the security team's efforts and all the robust defenses in place purely due to the volume of apps playstore was actually recently found to be the main distribution vector for malware so all in all relying solely on play

store wouldn't prevent this attack but what about our own defenses this is what the poc application looked like on the handler and as we can see the attacker has control over the icon the title the subtitle making it very easy to match the victim up if you're wondering which is the correct option i could give you a spoiler and tell you it's the loud one it should now be more obvious why uplinks were invented and that is to keep users safe free of such dilemmas actually just to give an example of how this performs in real life every time i found an issue like this in a client engagements i make a similar poc malware app for

demonstration and i go around the office and try it with colleagues to see which one they would pick and it turns out 90 of the times they pick the wrong option and these are experienced security consultants okay so let's now describe the disclosure process and what came with it so i put my wad hat on made a formal report describing all the issues that i found a full poc video provided detailed limited actions and sent all that to both software and went and then i waited and waited some more as is the case with the situations it eventually took almost five months to go from initial contact to a patched application being released i was mostly interfacing with software

and throughout these correspondence i eventually found out that the vulnerabilities only affected wind vision and not all next four implementations as i initially thought although i had gone through screenshots of their respective iptv solutions for all the other telcos to confirm some sort of webview based login was used but that was not the case i was also curious to see how many of the issues disclosed were actually fixed after all this time i'm gonna leave this as an exercise for the reader to find out spoiler not many and the release notes were also rather low profile that's a question i was asked a lot the answer is no i was not shoot by either winged norse

upward they were actually very respectful and professional so no drama it's worth mentioning though that i was prepared as everyone should be when digging into commercial products i kept a copy of the terms and conditions of the app before submitting live reports it didn't mention anything about reverse engineering and i didn't actually exploit any accounts so no foul play but better safe than sorry also apparently i got my 50 seconds of fame as there was at least one news page that caught wind of it fun fact i only found this when making the presentation which leads us to the final section of this talk so before closing off i'd like to summarize with a few quick tips for

mobile developers among the audience first auth is hard and so are all of its variations which means that implementation bugs will always exist just make sure to pick the best methods for the occasion and implement the protocol according to the standard do pay attention to your ipc endpoints this is where the code crosses the app boundary do make a use of https if using a custom url scheme like wind vision did so that you could leverage secure uplinks that keep the users safe and free of confusing prompts when generating ids employ some randomness so that no one can recalculate them and finally keep application level authentication credentials local if possible such as pin codes don't send them to the server don't get

them from the server and use secure apis like the android keystore to store and check them locally for researchers watching this i'd like to encourage you to give it a shot do think with the apps you use every day you might find interesting stuff if you do find something don't stop there cover as much of the attack surface as you can looking at the whole picture which could allow you to combine findings of low significance to come up with something of greater effect and finally i'd like to thank a few secure fellows for their contributions first of all oli who took the unattractive role of reviewing my initial blog post which initially was very bad it is

i think a bit more okay now and that's thanks to him rihanna for really helping me go public with the research and just constantly telling people about this afterwards so that i didn't have to jameson robert for a few valuable tips on the cfp submission ken from the us office he knows why and finally my father who provided the actual windvision accounts that i use for testing the ids and tokens of weights you saw on all slides and by the way these all still work months after the requests were initially captured so i had to reduce them all and this is it just in time thanks for watching and enjoy the rest of the event