 It is my pleasure to introduce you to Pedro Fortuna. Thank you all. Welcome. Thank you for being here. Today I'll be talking about protecting crypto exchanges from a new wave of man in the browser attacks, starting with a little bit about me. So I've worked in security for the last 15 years. The last seven or eight have been mostly focused in JavaScript code protection. But before I started working in the network security side of things, then I started building things like bot detection, device fingerprinting. And in the last few years, I've also paid a lot of attention to man in the browser attacks and malicious extensions. So today's talk will be mostly about man in the browser and crypto exchanges. But I'll start off by a brief overview of the man in the browser history. Then followed by, I'll cover the most common security, application security features that we have found in crypto exchanges. Then we'll get deep into the attacks that we have seen in last March. And at the end, I will talk about application real time monitoring, which is kind of a new approach that we have been working on that can help in this type of attacks. So for those who are not familiar with man in the browser, it all starts with a device getting affected, usually through email phishing. It's the most common way of doing it. And then the trojan gains control of the browser and just waves off for the user to go to a certain targeted website. And then it makes malicious injections into the page and tempers with the page. And this happens regardless of other authentication factors that may be in use. So man in the browser can be subtle. So they can be patient. They will just wait for you to access the website. And then they may wait for the very last minutes to change a transaction or just to collect your credentials. So they do the very minimum to accomplish what they want to do in the website. And they can be very subtle. Not all the time they will produce something that's visible, like it gets rendered differently. So it's very hard. So in this example that you see what's happening is the web inject is modifying the transfer amount in destination account. But apart from that, that's not, through the perspective of the server, that you have nothing else to look and that can tell you that this is happening. So it's really an attack focused on the client side and it's hard to spot. So it all started with Zeus. Not the slot machine, but the trojan. It first appeared in 2007. And he was able to do web injects and also to form grabbing. And at the bottom, you can see how a web inject looks like. So it has three sections. The target URL reference, where to inject and the injection itself. So in this example, the web inject is adding a field to a form that's requesting an ATM pin from the user. So the source code for Zeus was released or leaked back in 2011. And this really opened the door for the number of attacks growing. We have seen a lot of different forks and variants of Zeus and they are still out there. In this table, you can see the most common features that you can find in the man in the browser trojan. So most of them have form grabbing and web injection. Of course, those are practically mandatory, but they can do other things like key logging, remote access, and a few of them are even able to remove HTTP headers which can be really dangerous. So back in 2016, according to a study by IBM, the most prevalent man in the browser trojans were still Zeus, which is surprising. After 10 years, it's the most prevalent one and followed by a couple of variants, Neverquest and Gozi. But you can see here that the attacks have been going on in the last 10 or 12 years. And really, we are just scratching the surface. So there's so many attacks that go unnoticed, but we don't have time to cover all of this today. So I'll just mention one. Back in 2015, a drydex train was able to steal around $50 million. And what was worse is that it took two whole months for anyone. I mean, and we're talking about hundreds of different financial institutions for anyone to notice that this was happening. So this is a real problem. The question is, how secure are crypto exchanges? Are they up to the task? What kind of features they have that can mitigate or prevent this? This is the question that we had. So we went for a few exchanges to find out what they were doing. But there's too many changes. I think the numbers I've saw was roughly over 200 crypto exchanges right now. And so it's too many to make a survey. So we had to start somewhere and we decided to choose a representative set. And the rule of thumb was let's select exchanges that are likely to be selected by users. So we went for the most popular, but not only the most popular, but the ones that have also interesting features that we know about. So trading volume is interesting, ranking on Google search, links and relevant sites in social media, and also known user base. So in the end, we selected the six Binance, Bitfinex, Bitrex, Coinbase, Wobby, and Kraken. So other exchanges could have been selected, of course, but I believe the main conclusions wouldn't be different. So getting into the features, by now everyone knows what two factor authentication is. It can be used to frustrate attacks that only compromise a single channel. So you have a second one. You can use SMS, you can use mobile applications like Google Authenticator, or even physical hardware like Fido. All exchanges that we saw use two factor authentication, but they differ when they force the use of two factor authentication. So in general, they can use this to confirm logins, withdrawals, password changes, API key creation, changing security settings, or changing other sensitive settings. Captchas are also very common. They are used to determine if the navigation is being done by a human or by a bot. And you have many different types of captchas. The early day captchas were all based in text, as you can see in the right, the top image. Then the image based captchas came along and become very prevalent. And in the last few years, we are seeing more risk based and hybrid or dynamic based captchas that basically collect behavior information of the navigation and decide whether they should allow you in or just serve you an image based captcha if there are suspicious that you may be a bot. So typically they are used in authentication and registration. And most of the exchanges that we analyze are already using reCaptcha, which is the latter type of captcha, risk based. But what you have to keep in mind is that there's a high threat, which is the use of sweat chops to solve captchas. So especially if you are using image based captchas or even text, with text based captchas you don't even need sweat chops. But if you're using image based captchas, there's a whole set of services that you can easily integrate with your automation tools to attack that can get you solved any captcha in just a few seconds. And you can scale that up and you can abuse many websites that are only protected by image based captchas. So you have to watch out for those. Exchanges also lay out a number of different account takeover defenses, starting with two factor authentication, of course, but they are only forced by a couple. So only Binance and Bitfinex really force you to use two factor authentication. So in the other cases, you can disable this option. So it becomes a viable road for an attacker to disable those options and try to attack. So another thing is they send an email on every successful login. So this is useful because if you received an email and you haven't logged in, maybe it should take measures, right? If you reset your password or two factor authentication, some of those will require you to confirm that action through an email they sent you. And in a few cases, that will also cause your accounts to be frozen for a certain amount of time. So you cannot deal with roles if you just reset your password or two factor authentication. And this is good. You can also have a white list of IP addresses and devices. So you always have to confirm your devices. So not all exchanges offer this. And in some situations, you have to approve as well through email. Some, in some cases, there's also the possibility of freezing your accounts directly using the emails that you received, which is good because if you receive an email telling you about some action, you can quickly disable your account and hopefully in time for stopping the funds from being exfiltrated from your account. And all exchanges in general, they collect, they lock the actions that you do and they make this information available to you so you can spot if weird things have been done with your account. Withdrawal protections are probably the category that I found more interesting because some of the features can really be helpful to protecting exchanges. For instance, if you reset your passwords or two factor authentication, like I said, your account can be frozen for a certain amount of time and that amount of time can go from 24 hours to 15 days, which is really aggressive but gives enough time for people to understand if someone is messing with your password or with your two factor authentication. And this amount of time in certain situations depends on the exchange and the amount of funds that you wish to transfer. You can also lock or disable withdrawals for crypto coins that you are not using and you don't wish to trade at all and you also have a withdrawal address whitelist. So you need to specify the crypto wallet addresses that you intend to do transfers to and if you need to add a new address that can cause your account to be frozen during, for instance, five days. And the problem is some exchanges, they let you disable this feature and they let you disable without requesting a two factor authentication token. So this is a weak spot for sure. Also, the IP device whitelist lets you withdraw for new IPs and new devices, but only if they were previously approved and you have a minimum of 24 hours commonly that you need to wait before they are really approved and cleared out to use. Also, as you can see in the screen at the right, the image, some exchanges also present this image with the transaction details, but also with the secret phrase that you can set and this is done to prevent things like phishing attacks or tampering attacks that are forging transactions or tricking you and diverting the funds to other accounts. So if you don't find your secret phrase there, maybe it's an automated tampering attack and you need to watch out for those. There's also some anti phishing, more anti phishing techniques. You can set a secret phrase that's sent in every email that you received to prevent email phishing and you can also configure, I think in a couple of exchanges, PGP keys to be able to receive the encrypted emails. So this is useful as well. Pretty much all of them use HTTPS by now and I think only Binance, no, a couple of them, they show you warnings or requests for you to check and double check if you are running in the HTTPS and if you get the green lock and everything to make sure that you pay attention to those things. Last but not least, content security policy. So after going through all the six exchanges, I'm kind of disappointed because what I saw is most of the exchanges are either not using CSP at all or they are using it very wrongly. So as a couple of friends of mine, Michele and Lucas from Google said and they speak about CSP a lot. Over 94% of all CSPs based in wireless are bypassable so we shouldn't use them at all. Oh, oops. And what I saw is that at least more than half of these exchanges, they are using white listed domains in CSP which they shouldn't do at all and plus they use unsafe eval, they use unsafe inline and they don't use base URI none and like I said, some don't even use CSP at all. So they practically do all the mistakes that you can do with CSP. I don't know the reasons but I think they should fix this. CSP should be used but should be used right and I really can recommend enough the use of CSP evaluator which is a tool from Google that can warn you off if you are doing like obvious mistakes in your CSP configuration. So in this table you can see a summary of most of what we already talked about. Also I include the X-Frame options that we have found in these exchanges and the general overview is that most of them are allowing iframing of their website from their own domain and as we are going to see this is a problem. So only kind of moment is denying iframing from within their website. Other things that you can see the two factor authentication in the case of Binance and Bitfinex they are being forced in a lot of the actions that you can do in the remaining four. You can disable two factor authentication and this is bad because many of the browser can exploit this by disabling the requesting two factor authentication and so it becomes a useless security feature. And this is the same table with the positive things and negative things and I believe this table should be way greener than actually it is. And there's no single exchange that can get away because let's say Bitfinex is way greener than the others but at the same time they are not using CSP so they should be blocking all sorts of cross-site scripting, disabling framing from within their websites so no one gets out easily from this. So the main takeaways is that improvements can be made. CSP is not being used properly. In one case I didn't point out that Bitfinex is using text-based catchers which are very used to overcome if using OCR or whatever. You should ban framing of the website from within which is also useful to mitigate attacks like click-checking so you get that as a bonus. So there's no reason why you shouldn't use CSP and every important actions should trigger two factor authentication and that can't be disabled so you can't let the user decide whether two factor authentication should be used or not. So all sorts of whitelist can help. They should be used but they should be forcefully used with freeze time, like freeze time. And the anti-fishing, tamper proof images are also good to fight bots. But some of the stuff were nailed down by the exchanges so they all use HGF. They all factor one, two, okay. So factor authentication, they all log history. Wait a second, but if you look at what's being done we are using a lot of two factor authentication, captures, countries, whitelists, this and that. And the overall usability is being hurt. So what we want to know is whether we are getting more security in return by doing all of this. So now I will show you, I will talk about the attacks. So roughly five months ago I heard in the news that Coinbase and blockchain.info were being targeted by many of the browser attacks. And it all started by the work of a couple of malware researchers, Deweyna Kosovan and Kathleen Valerio-Lita from Security Scorecard. So they did a white paper on this and basically what they found is this was an attack caused by Zeus Panda, which is a variant of Zeus. And they were targeting, so what stood out from this is that among 50 targets, we found two crypto exchanges. And this really caught my attention. So I've read the white paper carefully and this is what you can see there. So this is the first stage web inject. I don't know, maybe you cannot read this, but it has a div element in the top and then you have an inline script. Hello, use of CSP, please. And here you can see the obfuscated version of the same script. It's not really complete, but you can see the different parts. But basically what it's doing is just waiting out for the page to complete loading and then afterwards it's just dumping an inline script that will load a second stage JavaScript payload from the website. So this means that the attacker can change the attack at any given point. So the only thing that's static is the web inject. So you put the main browser out there is injecting when people visit the websites, but then at that moment they will dynamically load a second stage JavaScript payload and that can evolve. They can do different things through time. So in this case it's only doing that and we didn't have all the details. So with the white paper it didn't have access to all the second stage payload. So, and we wanted more details on this. So we reached out to DeWina and Kathleen and we were able to discuss the attack with them and they were kind enough to share the stage two payload with us and based on that we implemented for Coinbase.com a C2 capable of interacting with the JavaScript payload and we are doing the injections in the browser using Burr proxy. So this is what we know. So initially the user visits Coinbase. At any given page the web inject is always injected no matter what inner URL you are visiting. And when you access the login form they overlay, they put a button over the real button and they disable the enter key so that you cannot use that because that will trigger the bottom real button and they force you to click their own button. So it's kind of an easy trick they can do. So when you log in they will extract your credentials but they will also put forward the normal login. So after you log in at the dashboard they will present you with this model window that says that they detected an usual sign-in activity. You're probably trying to log from a new location or device and so it seems pretty generic so it could potentially warn you off but at the same time who knows when the crypto exchanges are requesting two-factor authentication. It's really complex and it's dynamic too so we never know what's their strategy for serving and requesting two-factor authentication. So at the same time this can easily trick people into entering the two-factor authentication credentials. So let's imagine that you enter it and when you do that they will basically use that credential that two-factor authentication to load the security settings page in an iFrame so that's why we shouldn't allow your website from being iFrame from your own websites. So they load the security settings and they set the requesting two-factor authentications to none, to never. So basically you are just downgrading security in the website. So one thing that was weird is that this iFrame was not invisible which is one of the indications that we have that the attack wasn't complete so they were probably still working on the attack they were debugging and seeing how it goes. So after this, if you try to go to the security settings page you are presented with a one line error saying you that something went wrong, please try again later. And this is presently what it does. What it could do, it could initiate a transaction for a wallet controlled by the attacker and it would be easy because after disabling two-factor authentication there was nothing there to stop the attacker from doing this and the account wasn't frozen so it could be done immediately. All your funds are lost and this is far too appealing because you cannot undo this and the money is untraceable. So why shouldn't many of the browser torsions target crypto exchanges? They should. It's easier than targeting a conventional bank in my opinion. So this is how we implemented the attack. So we deployed a Burp proxy and the Burp proxy is applying the web injects but it's also stripping the CSP and the X-Frame options headers. And why we are doing this? Because we believe that after the attack Coinbase disabled the framing within their website and this attack in particular is using the iframe as I told you. So in order to replicate how it worked we are stripping the headers. And by the way Coinbase, like I said is the only exchange that is presently doing this. All the others are still vulnerable to this type of iframing. So obviously we configured a browser to use the proxy and the JavaScript payloads is communicating with a situ that we have implemented. So now it's time for the demo. So here in Burp you can see that we are removing the removing, replace with nothing the X-Frame options headers and contract security policy and we are also adding the web injects. So let me try to show you that. So before you can see very well but this is the same as I've shown you before. It's obfuscated but it's obfuscation is really simple. So in five minutes or so you can reverse this. Not really a good barrier. Okay so we are already running our C2. So let's add to, so the window is not very big so I'll try to do this the best I can. Okay. So let's go to Coinbase. This is not, it thinks it's in the mobile device because it's a really short login. So right now it's already tampering with the webpage. So this sign in button will exfiltrate the credentials. So I need to use a two factor authentication running in my mobile device and verify it. So here is the model that's injecting into the webpage. You're probably trying to log in from a new location and if we go to the security settings, so sorry, something went wrong. Let me just try again. Okay. So it's now requesting my two factor authentication tokens again so this is fake, of course. Let me just use my mobile device 215. In the original attack it would show the iframe. So in this case we have disabled it because it wouldn't be like, it's hard to understand what's going on if you're seeing an iframe. And now if you go to the settings, you see this error. So something went wrong, please try again later. So this is the attack and what they aren't doing is transferring the funds out but they could easily do that. If we go, if we log in using another browser which is not using the burp proxy, we can confirm. Okay, so we can confirm that right now the security settings, the two factor authentication is disabled. So we can see this because we are not using the infected browser but if we try to use Firefox in this case, we are not allowed to see the settings or even change them. Let's, because we are at DEF CON, we should fix this immediately. All right, okay. Okay, so what have we learned by doing this? So first, the first conclusion is that this attack is very noisy. So it basically injects the web inject in every endpoint of the website. So if they were trying to be quiet, they shouldn't do that. They should target like two or three very specific URLs and only drop the web inject in those endpoints. But we can speculate because the attack was still being designed. Maybe the guy doesn't know yet which endpoints that he will use. So he doesn't want to lose an opportunity to tamper in other pages and maybe Coinbase can change the endpoints as well. So he wants to retain the ability of just tamper with any inner URL. It also uses a state machine to control how it works. But it seems very experimental, very poorly written JavaScript. I believe it's uncompleted work and we have different signs that this is true, like the visible eye frame. Also there's a part in the payload where they are doing the transferring out the funds, but you have a return statement just at the top of that function. So it's an unconditional return statement. So it means that they are disabling that part and we also saw that some automata states are missing from the code, seem to be missing. So two factor authentication or SMS confirmation, it's not a real barrier for this attack vector and I believe that even security professionals can be tricked because it's so confusing when and when not two factor authentication is used or should be used or why it's used. So you can easily be tricked with this and we assume that in this case, Coinbase has since disabled the eye framing from within the website. So obviously you can follow the usual many of the browser recommendations like using a live distro to go to your favorite banking website or crypto exchanges, but I mean that's hurting the usability even more. So the question is what if we could be able to detect the injections and do something about it? And this is the question that we have been trying to, we have been working on lately. So this, one, two. Okay, so this is what we came with application real time monitoring and this is more or less how it works. So it has two components, a client and a server and the client components, the real time monitoring agents is continuously monitoring the page and the DOM and it checks for DOM injections, for JavaScript, script injections and for modified Heaven Tundlers. And it does that by leveraging mutation of servers to receive a stream of things that are being changed in the DOM in real time. It also combines that with the checksums for certain parts of the DOM and it does poisoning injection. So when the injections are detected, we send that out to the real time monitoring backend which validates if this is a real threat and then it sends out to the backend application using a special web hook. So this web hook is receiving a stream of events of things that are being injected into the application and this is done in real time and you can set policies on your application backend on how to react to this. So you can blacklist the user, so automatically freeze the account, you can do a lot of things and it can be done in timely fashion in order to stop funds from being exfiltrated from the account. So you can send more, you can ship more things to the clients as a feedback loop and this can be really helpful. So it follows a widely seen approach means that it detects any unseen injections. It has different levels of sensitivity according to what's being injected and where and it uses machine learning to tackle the false positives. Also support signatures for known injections in which case it can launch counter measures. So it can remove injections that we already knew about but it can also redirect the page to a certain URL, delete cookies or execute a custom callback in the client side. So this is very flexible. Of course all of this is done by using code protection because the client side components is JavaScript can also be tampered with so it needs to be resilient to any kind of manipulation from the web inject. So it uses polymorphic JavaScript obfuscation. It is tamper resistant and can optionally be mixed with the code of the application making it very hard to distinguish which part is the agent and which part is the regular code of the application. So let's redo the demo but this time using the application real-time monitoring. So I'll struggle a little bit with the size of the windows but I'll try to do my best. In order to add the agent I'm also using burp proxy so this part is adding the agent to every web page dynamically because we couldn't get Coinbase to install it in time for this talk. Sorry. And let's go here again and let me open the dashboard here. Okay so I want you to be able to at least see a portion of this graphic in the back so I will try to position things so that you can see a little bit to see what happens. Okay? So I have to restart C2. Okay, we're done. Let's go. So we are already seeing things in the back. Just a second. Already seeing things. So we have four new threats so things are getting, are landing in the, so we can see the button here and you can see the overlaid button code here. So you could already be doing something about this. Let's proceed. This is the regular two factor authentication that's Coinbase requests. So here you can see the iframe. So sometimes the code isn't really reliable so as I said it's a work in progress and may take a long time to just move over. Okay, and we have new stuff. All the time they are adding the web inject to the page and deciding whether they should do something or just quit. When they decide to do nothing they also remove the injection from the web page. So if you do a dump at the later stage of the dump you won't find the injection there. Okay, so this seems to be stuck. Let me try again. Bear with me please. Of course. Sure. So yeah, good question. So Burp is replacing me having my device infected. So if I had my device infected my browser would be in control of the web injects and as you go to Coinbase it's automatically injects the. Yes, I know we have shown you before. I can show you in the end if that's all right. Okay, I can show you again. So let me try this again. All right. Seems to only work at the second time. Shit. Okay, so you've seen this before. Let's see what we have here. We have quite a few injections in the page. Let me try to show you a couple that might be interesting for you to see and to understand what kind of information we can supply. So here you can see this is a form and it's actually the two factor authentication thingy where it's requested like the model, complete model having the form to request the two factor authentication and let's see another. Okay, so this one is in the dashboard and it presents an image. Let me see what kind of image this is it. So this is the icon that shows just next to the two factor authentication. I don't know if you remember but this is the kind of thing that you can collect as well. All right. So let us go to the security settings. Oh, I'm in the wrong browser. Okay, load the security settings. Something went wrong, please try again later. Okay, so four knee threats. This is all live and we can see that a bunch of DOM has just been removed from the security settings page and this is the actual security controls that you usually see in the page. They have been removed and the attacker has placed the error message. So in conclusion, if there's anything I like you to take away from this talk is that crypto exchanges are being targeted by many of the browser and they should be aware of this attack vector. Of course, every other vector should be in their horizontal as well. But I believe we are seeing more of this because it's far too appealing for an attacker because it's anonymous, it's untraceable and if they get out, it's really difficult to find out who stole the money. So I think this attacks against Coinbase and Blockchain Info can be seen as warnings because the work after all was incomplete. We don't know if there were consequences. We know that the credentials could have been stolen during this period, so we don't know if someone is using them in any way. But we know that at least this version of the Trojan is not yet stealing money. And other conclusion is that two factor authentication is not enough for this attack vector. So definitely exchanges can improve their defenses, things like temporary freezing the account when you change anything about the security of your account and I don't mind paying with usability but at least do it right and don't provide workarounds for people to just go and disable two factor authentication because this can also be a tool for web injects and for Trojans to be able to perform their attack. So I think attacks will most likely get more creative and they can be executed by anyone because you can acquire a Trojan kit in the black market. You don't need to really understand how it works. You just need to write some JavaScript that goes into a webpage and adds stuff to the DOM, removes others and implement a state machine to control how you are doing that. So it's not really sophisticated, it's really simple and due to the potential returns, I think we are definitely seeing more stuff. I think for this attack vector application real time monitoring is really can be effective. We just assume that injections will occur, we cannot prevent that and try to detect them in real time when they do. You can set custom policies, you can adapt what you're doing in real time and you can mitigate the attacks before they are successful. And as you know, if attacks keep failing, probably the attackers will move to the next side because they always look for the least amount of effort and the maximum profits they can have. So I cannot tell you exactly how to earn money using this talk like Ming said, because I shouldn't unless you pay me a beer afterwards. Then I can consider that. So this is all I have, thank you.