T2 07 “The Browser Within”, Local exploitation of internal browsers in software, Alexandros Zacharis

Hello everyone. Today I am going to present you some of the interesting findings that I had. What we are going to talk about is how you can identify browsers, internal browsers, being used in modern software, and how you can exploit them locally in order to, of course, do some malicious activity. So I am going to focus both on the part where devs fail to protect a software while using an internal browser, and I will give you a concrete example of how you can actually do an attack, using as a paradigm an attack against Skype, which is a known tool that you probably have all used and known. Before I continue with my presentation, I will just tell you a few things about me. So I usually, this is not my main thing, I usually do trainings and cyber exercises. I work for ENISA, and I don't know how many of you know this internal organization, here in Greece.

And this is the side project that we are doing as part of our lab activity. So I will present you this lab part. So a disclaimer, and the agenda of today. So I am going to present you a little bit about why, as I said before, developers choose to use internal browsers in their software. The architecture, the usual architecture that we identified, a few params that usually need to be set in order for you to protect your software when using an internal browser. Of course the risks, some exploitation techniques, and an example as promised before. So for the internal browsers, they are part of the modern software ecosystem and they are used usually, from what I have identified through a test that I did, mostly for authentication and web navigation of software which is installed in your computer. It's a bridge between stand-alone clients and web cloud implementation.

So usually you have part of the software which is in your machine and then you have some infrastructure which is hosted usually in the cloud. In order to bridge this gap, instead of creating their custom browser, developers choose to use stand-alone DLLs or executables from known browsers and implement them in their own architecture and use these instead. So this is where the problem begins because they don't protect these, let's say, apps, these DLLs, these modules in a way where an attacker would not be able to use them for his own, let me say, malicious purposes. Internal browsers, example of internal browsers usage. Where can we find internal browsers? This is an example, a screenshot that we will see in detail later. Skype for example, if you choose to authenticate yourself using Facebook, for example, it has itself an internal browser, it's using an internal browser to navigate into the Facebook login screen where you provide your Facebook credentials, you authenticate yourself, the token goes back to the app, the Skype app, and you are authenticated for using Skype via Facebook.

So they are using the browser to authenticate. Except Skype, which is a chatting app, there are other softwares that are using this technique, let me say, this methodology. They are antivirus solutions, cloud storage clients, password safe solutions. I will not name them but you can go back and do your own research. Why are they using internal browsers? For user authentication, to connect with web resources not present on the client-side because they don't want to load all these let's say resources on your machine, but you can access them over the cloud. Connection with cloud storage, which is the only way you can connect actually there, and maybe sometimes they also use it in order to throw some promotional material on your face while you are using the app.

Now the usual architecture can be two different things. It can either be an internal browser inside the process that you are actually running. So Skype in our case is the first architecture, the example of the first architecture. You cannot see a different executable, it's just a different DLL which is loaded inside the process of Skype, and it accesses web resources which supposedly are protected, so you can only access the Facebook domain, but no other domains and you use that in order to authenticate yourself. There are other cases where it's a separate executable. So the separate executable does this connection, it's a separate executable which is the browser. It's not actually internal but another executable, but it's part of the installation of the tool that you are using, for example an antivirus that you are using. Again it accesses external resources over the internet.

Now, this is a nested architecture and supposedly the developers what they do is they try to contain the calls of their portable browser, the executable or the DLL, in a way where you cannot tamper the browser and do whatever you like. So what they are supposed to do is they should sometimes they fixed for the window size, fixed size for the window, DLL or executable, they hide all the navigation bars of the browser so you cannot use shortcuts or force the browser to go wherever you like. They deactivate the right-click, they deactivate different plugins that you can install in the internal browser, shortcuts as I said, deactivation of command-line input. Lots of browsers have command-line CLI and you can directly send commands to the CLI. Deactivate this also. And of course they limit the domains where the browser can be redirected.

So all these are important limitations. So the internal browser that you are using in your architecture, the attacker cannot exploit them in order to navigate this internal browser, so the process that you have installed in your machine, wherever he like. Now the risks, of course things can go wrong if you do not protect the internal browser properly. So the first risk. An attacker knows that you are using the internal browser and doing his magic can navigate the browser outside the scope of the process or the normal legit domains that supposedly the process allows. So you can navigate to anything. Navigate to anything means that I can render any content I like, web content, inside the context of the process that I'm abusing. For example I can render anything inside the process of Skype.

So what you can do there is parse content of a rogue website in the context of the app. You can later use that in order to abuse vulnerabilities in the internal browser and then maybe elevate yourself if this is the case and the process that you are running is elevated. You can of course cause a denial of service of the service. You can use the service, the app, and of course pop up there a phishing page, your own phishing page, since you are controlling the rogue website and the user would then give his credentials. And of course you can use it to exfiltrate some data using again the process, which is also a very interesting attack.

Now, other risks. In order to do all these attacks and to abuse it properly, what we have to do first is fingerprint what the browser, the internal browser is. So usually all these tools that have internal browsers, you don't see the logo, you don't see the technology, you just see that they navigate to a web page. So you have first to identify which browser is used, is it a custom browser, is it a known browser like Firefox, Chrome, Internet Explorer, what's the technology behind, in order to identify of course the right exploits to later use against this technology. Is it outdated, is it up-to-date. So there are different ways you can do that. You can navigate anywhere and you can navigate to a known online tool that does fingerprinting for you. You can try setting your own JavaScript code and it would do the job for you. There are some tools that I have identified that do this for you if you want.

And of course another risk, as I said, is you can convert the Skype app to a phishing app. So this is my phishing app, this is the normal login Skype page. Of course I did it on purpose to look like it's very fishy. You can make it exactly the same, you can use CSS, JavaScript, you can bring sources from different domains and you can render everything, but you will see later this thing. And the question here is, okay phishing is one thing, what if in the context of another process, for example an antivirus, I pop up here that your antivirus needs an update. I don't have the permissions to credentials to let's say I'm not root to the machine, so I cannot install something I cannot bypass the UAC, but I can social-engineer a user with higher privileges. I can go up here that your antivirus needs an update and the user will do the update for himself, but it will be an update from a rogue website.

And one interesting thing that I found during my research is that whenever you install a software that has an internal browser, it does not mean that the internal browser that is brought in your machine is up-to-date. So you install for example a product like Skype, Skype was not the case by the way, but you install a product like Skype, Skype is up-to-date, but the browser that brought with it was Internet Explorer 5. Which means that you can exploit, you can use all exploits known for that browser and you can do whatever you like afterwards. So locally you can do some attacks. So important for developers, you all have a process for updating your product, but you should have a process for updating the internal browser in parallel. Because this is lacking in many cases from what I identify. So again you can do these types of attacks. How often is it triggered? That's a question. So when did you actually update your internal process? What happens if an unknown exploit is found? And that updates should not be separate from the rest of the updates that you are bringing.

Half of the tools that I have tested had this vulnerability. I mean they were bringing outdated browsers. So the risk pillar is this one, navigate anything, execute code, and outdated browser is the highest risk that can be abused in an attack. Now, on the exploitation part. As I said before, this was the case of Skype, you could explore and use the authentication process with Skype. So you have the normal login page where you put your credentials, but it gives you this alternative option to login with Facebook. So this is where the problem started. This is actually a Skype process, inside it is a browser, an internal browser, and it gives you this alternative option. But it does poor users user interaction checks, so an attacker can use this option and through specific steps can disorient the login process and navigate actually to an external website where you can run your JavaScript code or other code and actually do some attacks that I am going to present.

Another attack is the broken redirection. Actually this is also an interesting type of attack. In general, when you are inside a context of an internal browser, whenever you click on links that link to something outside the scope of the process, what you should do is you should pop up a different browser if you want to navigate for some reason to something external. If you navigate in there to something which is external, for example in the case of Skype outside Microsoft and outside Facebook, then it should not be rendered inside there. If for some reason you want to give promotional material for example and there is a banner here with an ad and I click on the ad, it should not be rendered inside here, it should pop up the default browser that you are using that is up-to-date and you can see there of course the promotional material. Now this is not the case. Sometimes, for some reason, and you can actually automate this process, you can have a process where you click on a specific hyperlink which supposedly takes you outside the scope of the program, it's rendered inside the process. This is wrong.

And the final thing, which was also interesting, is never forget to shut down the command-line option, because lots of browsers that you stand-alone browser that this software are using have this option where you can actually directly give a specific command and it would be directly parsed inside the internal browser. So if you don't let's say block this feature, you are bound to pass on random websites. Now I have seen two interesting things here. There was one case where they were allowing on purpose through a stand-alone executable that was the browser this command, but they were doing a check to see if the domain is the correct domain. So you could do this command, it will be parsed inside the internal browser, the website that you provide as a parameter there, but they would check the domain name. But they were only checking the first part of the domain name. So actually they were only checking if the name of the company was in the URL that was checked, so you could take any domain and just provide the string which was the name for the company and everything would go wrong.

Here are some examples for Microsoft Explorer, you can used this command and check for other browsers the exact same thing. So again check for the authentication process, this is very common, lots of software use nowadays various ways to authenticate yourself and this can be Google, Facebook, LinkedIn and then authenticating back in the process. Broken redirection where you click links inside an internal process and you navigate. Real-life example. I would present only one example with Skype, and I did let's say two things: identifying what the browser was and then try to exploit. The browser was exploited in three different ways. The vulnerable client was that person, that was using Facebook as a secondary way of authentication. In order to achieve the attack, you had to have local access to the login screen of the Skype process. That's the only thing you had to do.

I will explain why this is useful. And I verified with the Windows client was affected. Why it is interesting that you can abuse a machine only by the login process and only by the login screen. There are cases where Skype is used as a way to communicate and local access is mmore than what I did. Because here you can see in an airport they are using Skype, and it's the only process that you can actually run, and you cannot do anything else in the underlying OS. But this is enough in order to launch a phishing attack or to crash the process. Another thing where you can actually attack Skype is Skype used also in smart TVs as a way of communication and this setup can be found in meeting rooms where where you can directly have access only to that thing and nothing else and of course you can launch an attack on that thing only. So what the attacker will probably do, he will first fingerprint what the browser that is running. In our case it was an internet explorer which was not outdated, which is a good thing and you could execute code in the context of the Skype processes.

So forensically-wise you could see the Skype process calling various let's say resources but that was it actually. I could for example send voice during my phishing attack, so I could record stuff using JavaScript and send them outside. And it would look like Skype is sending voice data somewhere, which is normal. We could also phishing credentials and you could cover your communication traces. So the airports, railway stations, smart TVs are particularly interesting for this type of attack. Exposing the browser, how to? Okay this is a complex process. I will show you two videos. First about the crashing. So first I do a check for the Skype version. Then I try to login with random credentials to reach the problematic point. For some reason Skype chose to allow you to create a new account. I click there and I'm navigated to Facebook. Which means I can login to Facebook. I'm actually now using Skype as a normal browser.

So my thing now was how can I get out of Facebook, run my own JavaScript code and attack Skype. I found the way: you can go to developers' page, you login with your fake credentials as a developer in Facebook, and there is this JavaScript tests console. And then what I do here I can execute JavaScript inside the internal browser within Skype. And now I will paste the code, a known JavaScript code that will actually crash Skype. It will crash the internal browser and the process. And that's it. Now for the phishing, same again, I will not go through the whole thing. Here is just when I'm going to send keystrokes on an IP outside. And I will create a phishing form. Rendered inside the process. See, I created inside Skype my own phishing form which everything right back there will be sent somewhere else. I can leave it like this inside an airport and wait for someone to write credentials there and take them back in my server. Okay so that's another attack you can do.

So what was very interesting is what you can see here after stolen credentials, you are getting this default error of Skype saying that your credentials were not the correct ones. So okay you will re-try and you go back to the normal form and login, as fine as expected. From the perspective of what you get actually you can see that Skype is communicating with this IP that you saw in the video, actually stealing your credentials. And as a final food for thought I have a final video and then you can ask me questions. I don't know how many of you have heard the Weeping Angel attack. Actually it's an attack where you convert smart TVs into listening devices. So it works only for Samsung TVs. It needs also a local access in order to do this attack. But what you can actually do is you convert any Samsung TV into a listening device. Now what I can do is turn any TV runninng Skype into a listening device, send voice and keystrokes remotely. So that's it, thank you very much and please if you have any questions.