PACKET HACKING VILLAGE - Protecting Crypto Exchanges from a New Wave of Man-in-the-Browser Attacks
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Fortuna, Pedro
In the last year or so, we have seen a massive increase in the value of cryptocurrencies and the emergence of hundreds of new coins and ICOs, getting millions of people into an investment frenzy. A lot of them being non-technical regular consumers that rushed to create new accounts in the most popular crypto exchanges like Coinbase or Bitstamp. Crypto exchanges are naturally appealing for attackers and have been targeted since as long as we can remember. However, since last year, they are also being targeted by Man-in-the-Browser (MITB) attacks. Malware families such as Zeus Panda, Ramnit and Trickbot are already aiming at websites such as Coinbase.com or Blockchain.info. In this talk, we will detail how these attacks work, from account takeover to moving out the coins to attacker-controlled wallets. We'll discuss current defenses e.g. multi-factor authentication or strong SSL encryption and why they are failing to mitigate this type of attacks.
 It is my pleasure to introduce to you 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 7 or 8 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 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 erosion 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 like a transaction or just to collect your credentials. So it's, 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 and destination account. But apart from that, that's not, through the perspective of the server, that's, 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, to do form grabbing. And at the bottom you can see how a web inject looks like. So it has three sections. The target URL, a 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 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, or 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, many of 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 dry deck strain was able to steal around $50 million. And what was worse is that it took two whole months for anyone, I mean 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 exchanges. I think the numbers I 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 website. 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 used 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 they 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 re-capture, which is the letter type of captcha, risk-based. But what you have to keep in mind is that there is a high threat, which is the use of sweatshops to solve captchas. So especially if you are using image-based captchas or even text-based captchas, you don't even need sweatshops. But if you are using image-based captchas, there is 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. This is also layout 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 receive 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 account 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. In some cases, there's also the possibility of freezing your account 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. Adderall 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. But 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 techniques. You can set a secret phrase that's sent in every email that you receive to prevent email phishing. And you can also configure, I think in a couple of exchanges, PGP keys to be able to receive 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 on 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. 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 e-vowel, 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't 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 I-framing 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 I-framing 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 is 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 take-aways 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 captures which are very used to overcome 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 is no reason why you shouldn't use CSP and every important action 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 free time. And the anti-fishing, tamper proof images are also good to fight bots. But some of the stuff were down by the exchanges so they all use H... Yeah. They all factor... One, two, okay. So they all 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 the... 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, Deweyne 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 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. It 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 you 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 would 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 login they will extra trade your credentials but they will also put forward the normal login. So after you login 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. So it seems pretty generic so it could potentially warn you off. But at the same time who knows when 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 requesting two factor authentication 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 trojans 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 the Burb proxy and the Burb proxy is doing is applying the web injects but it's also stripping the CSP and the X frame options headers. Why we are doing this? Because we believe that after the attack coinbase disables 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 Burb you can see that we are removing the, we replace with nothing the X frame options headers and the policy and we are also adding the web inject. 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 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 situ. So let's have 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. So here we are. So we are running our system. This is not, it thinks it's a mobile device because it's a really short login. So right now it's already running. So this sign in button will exfiltrate the credentials. So I need to use the two factor authentication running in my mobile device. I'm verified. So here is the model that's injecting into the web page. They'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. So here is the login. So here is the login. 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. 4, 2, 1, 5. So here is the login. So here is the login. So this is the login. So here is the login. So here is the login. So 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 are seeing an iframe. Now if you go to the settings, you see this thing went wrong, please try again later. Okay. 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 Burr proxy, we can confirm. We can confirm that the money is in the browser. 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. 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 he will use. So he doesn't want to lose an opportunity to tamper in other pages of the website. 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 to 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. Right? 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 is one, two. Okay. So this is one, two, three, four, five, six, seven, eight, seven, nine, ten. 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, the client and the server. And the client components, the real time monitoring agent is continuously monitoring the page and the DOM. And it checks for DOM injections, for JavaScript, script injections and for modified heaven handlers. And it does that by leveraging mutation of servers to receive a stream of things that have been changed in the DOM in real time. It also combines that with the checksums for certain parts of the DOM. And it does poisoning. 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, 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 white releasing 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 supports 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 component 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 of location. It is tamper resistant and can be mixed with the code of the application. Making it 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 Burr 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 the stock. 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. Okay. So I have to restart C2. And I have to restart C2. So I have to restart C2. So we are already seeing things in the back. Just a second. Already seeing things. So we have four new threads. 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. And here you can see the iframe. And here you can see the iframe. So sometimes the code isn't really reliable. So as I said, it's working 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 inject. And as you go to Coinbase, it's automatically for external vårgements. And now thank you, guys. Thank you to you, 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. No, 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. Okay. So in conclusion, if there's anything I'd like 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 horizon 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 intracable 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 temporarily 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 web page 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 are 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. Thank you.
 It is my pleasure to introduce to you 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 7 or 8 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 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  erosion 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 like a  transaction or just to collect your credentials. So it's, 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 and destination account. But apart from that, that's not, through the  perspective of the server, that's, 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, to do form grabbing.  And at the bottom you can see how a web inject looks like. So it has three sections. The  target URL, a 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 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, or 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, many of  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 dry deck  strain was able to steal around $50 million. And what was worse is that it took two whole  months for anyone, I mean 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 exchanges. I think the  numbers I 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  website. 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 used 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  they 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 re-capture,  which is the letter type of captcha, risk-based. But what you have to keep in mind is that  there is a high threat, which is the use of sweatshops to solve captchas. So especially  if you are using image-based captchas or even text-based captchas, you don't even need sweatshops.  But if you are using image-based captchas, there is 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.  This is also layout 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 receive 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 account 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. In some cases, there's also the possibility of freezing  your account 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.  Adderall 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. But  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 techniques. You can set a secret phrase that's sent in every email  that you receive to prevent email phishing. And you can also configure, I think in a couple  of exchanges, PGP keys to be able to receive 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  on 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. 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 e-vowel, 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't 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 I-framing 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 I-framing  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 is 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 take-aways 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 captures which are very used to overcome 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 is no reason why you shouldn't use  CSP and every important action 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 free time. And the anti-fishing, tamper proof images  are also good to fight bots. But some of the stuff were down by the exchanges so they all  use H... Yeah. They all factor... One, two, okay. So they all 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 the... 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, Deweyne 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 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. It 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 you 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 would 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 login they will extra trade your credentials but they will also put  forward the normal login. So after you login 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. So it seems pretty generic so it could potentially  warn you off. But at the same time who knows when 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 requesting  two factor authentication 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 trojans 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 the Burb proxy and the Burb proxy is doing is applying the web injects but it's also  stripping the CSP and the X frame options headers. Why we are doing this? Because we believe that  after the attack coinbase disables 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 Burb you can see that we are removing the, we replace with  nothing the X frame options headers and the policy and we are also adding the web inject. 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 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 situ. So let's have 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. So here we are. So we are  running our  system. This is not, it thinks it's a mobile device because it's a really short login. So right now it's already  running. So this sign in button will exfiltrate the credentials. So I need to use the two factor  authentication running in my mobile device. I'm verified. So here is the model that's injecting into the  web page. They'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. So here is the login. So here is the  login. 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. 4, 2, 1, 5. So here is the login. So here is the  login. So this is the login. So here is the login. So here is the login. So 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 are seeing an iframe. Now if you go to the settings, you see this  thing went wrong, please try again later. Okay. 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 Burr proxy, we can confirm. We can confirm that the money is  in the browser. 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. 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 he will use. So he doesn't  want to lose an opportunity to tamper in other pages of the website. 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 to 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.  Right? 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 is one, two. Okay. So this is one, two, three, four, five, six, seven, eight, seven,  nine, ten. 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, the client and the server. And the client  components, the real time monitoring agent is continuously monitoring the page and the DOM.  And it checks for DOM injections, for JavaScript, script injections and for modified heaven  handlers. And it does that by leveraging mutation of servers to receive a stream of things that  have been changed in the DOM in real time. It also combines that with the checksums for  certain parts of the DOM. And it does poisoning. 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, 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 white  releasing 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 supports 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 component 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 of location. It is tamper resistant and can be mixed with the code of the application.  Making it 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 Burr 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 the  stock. 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. Okay. So I have to restart C2. And I have to restart C2. So I have to restart C2.  So we are already seeing things in the back. Just a second. Already seeing things. So we  have four new threads. 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. And here you can see the iframe. And here you  can see the iframe. So sometimes the code isn't really reliable. So as I said, it's  working 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 inject. And as you go to Coinbase,  it's automatically for external vårgements. And now thank you, guys. Thank you to you,  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. No, 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. Okay. So in conclusion, if there's anything I'd like 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  horizon 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 intracable 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 temporarily 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  web page 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 are 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.  Thank you.
DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_0_5027.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_5028_5171.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_5172_7823.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_7824_8975.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_8976_9335.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_9336_9527.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_9528_9947.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_9948_24539.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_24540_43955.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_43956_44027.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_44028_44495.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_44496_44663.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_44664_45407.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_45408_45479.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_45480_45575.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_45576_45659.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_45660_45767.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_45768_46031.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_46032_46079.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_46080_46703.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_46704_46751.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_46752_46931.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_46932_47267.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_47268_47555.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_47556_47663.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_47664_48383.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_48384_48455.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_48456_48539.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_48540_49487.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_49488_49643.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_49644_49835.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_49836_50387.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_50388_51167.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_51168_51695.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_51696_62123.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_62124_62411.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_62412_62639.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_62640_62915.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_62916_63083.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_63084_63131.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_63132_63203.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_63204_63371.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_63372_63467.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_63468_63575.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_63576_64223.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_64224_64307.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_64308_64547.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_64548_64727.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_64728_65411.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_65412_65507.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_65508_65591.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_65592_65843.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_65844_66263.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_66264_67619.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_67620_67859.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_67860_68087.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_68088_68267.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_68268_68351.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_68352_68543.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_68544_69767.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_69768_69827.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_69828_70055.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_70056_70211.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_70212_70523.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_70524_70763.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_70764_70811.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_70812_71531.png DEF_CON_26_PACKET_HACKING_VILLAGE_-_Pedro_Fortuna_-_Protecting_Crypto_Exchanges_Fro_71532_76923.png