PACKET HACKING VILLAGE - Protecting Crypto Exchanges from a New Wave of Man-in-the-Browser Attacks
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Alternativer Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 322 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/39929 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
00:00
BrowserKryptologieWellenlehreAuthentifikationHill-DifferentialgleichungBrowserWelleBitMetropolitan area networkWeb-SeiteComputersicherheitKartesische KoordinatenEchtzeitsystemGamecontrollerInjektivitätReflektor <Informatik>Trojanisches Pferd <Informatik>Web SiteCodeE-MailMaßerweiterungTypentheorieSoftwareAuthentifikationKryptologieElektronischer FingerabdruckRoboterPhishingComputeranimation
02:15
BrowserWärmeübergangBenutzerbeteiligungPerspektiveBrowserWeb SiteTransaktionClientMultiplikationsoperatorServerComputeranimation
03:19
Trojanisches Pferd <Informatik>Hill-DifferentialgleichungVirtuelle MaschineTrojanisches Pferd <Informatik>QuellcodeZahlenbereichBenutzerbeteiligungVersionsverwaltungMinimumInjektivitätBildschirmmaskeTabelleDatenfeldPersönliche IdentifikationsnummerATMURLGarbentheorieDifferenteComputeranimation
04:24
Hill-DifferentialgleichungTrojanisches Pferd <Informatik>Trojanisches Pferd <Informatik>MenütechnikInjektivitätBildschirmmaskeBenutzerbeteiligungBrowserE-MailSchlüsselverwaltungRPCBeobachtungsstudieComputeranimation
05:13
EinfügungsdämpfungTrojanisches Pferd <Informatik>MalwareMultiplikationsoperatorFlächentheorieWellenpaketWort <Informatik>DifferenteComputeranimation
05:59
KryptologieTaskMathematikZahlenbereichWeb-SeiteSondierungComputeranimation
06:38
StichprobenumfangThumbnailVerschlingungSchnittmengeGoogolSchlussregelEinsWeb SiteSelbstrepräsentationSpezifisches VolumenHypermediaRankingComputeranimation
07:31
ICC-GruppeAuthentifikationApp <Programm>SchlüsselverwaltungCaptchaPasswortHardwareComputersicherheitSchnittmengeMathematikSensitivitätsanalyseLoginPhysikalismus
08:19
Dienst <Informatik>CaptchaMotion CapturingSchnittmengeE-MailZweiPasswortAuthentifikationBildgebendes VerfahrenGefrierenCASE <Informatik>Registrierung <Bildverarbeitung>MultiplikationsoperatorTypentheorieRoboterKonfiguration <Informatik>GruppenoperationDifferenteLoginNetzadresseEinflussgrößeÜberlagerung <Mathematik>Web SiteZahlenbereichInformationEntscheidungstheorieRechter WinkelHybridrechnerForcingComputeranimation
12:20
MenütechnikAuthentifikationKryptologieTouchscreenPasswortBildgebendes VerfahrenLokales MinimumMultiplikationsoperatorTransaktionInstantiierungAdressraumWärmeübergangGleitendes MittelKategorie <Mathematik>NetzadresseToken-RingComputeranimation
14:49
Inhalt <Mathematik>ComputersicherheitDomain <Netzwerk>E-MailKonfigurationsraumDigital Rights ManagementSchlüsselverwaltungGreen-FunktionPhishingDatensatzLeistungsbewertungData MiningTabelleMinkowski-MetrikComputeranimation
17:23
WellenlehreWeb SiteNegative ZahlOrtsoperatorRahmenproblemBrowserComputersicherheitMomentenproblemCross-site scriptingTabelleQuick-SortKonfiguration <Informatik>CASE <Informatik>GruppenoperationMultiplikationsoperatorAuthentifikationDomain <Netzwerk>Computeranimation
19:10
Wechselseitige InformationCASE <Informatik>Eigentliche AbbildungCaptchaAuthentifikationComputersicherheitRahmenproblemGüte der AnpassungBildgebendes VerfahrenEntscheidungstheorieQuick-SortWeb SiteRoboterGruppenoperationBenutzerfreundlichkeitMultiplikationsoperatorGefrierenFreewareWeg <Topologie>Wort <Informatik>BeweistheorieComputeranimation
21:08
WelleKryptologieE-MailMIDI <Musikelektronik>BrowserInformationComputersicherheitPhysikalischer EffektMalwareComputeranimation
22:04
MAPBenutzerbeteiligungDivisionSkriptspracheElement <Gruppentheorie>InjektivitätWurm <Informatik>CASE <Informatik>MomentenproblemInnerer PunktDifferenteMultiplikationsoperatorWeb SitePunktMereologieBrowserVersionsverwaltungWeb-SeiteMetropolitan area networkMenütechnikComputeranimation
23:20
DatenreplikationClientServerAuthentifikationComputersicherheitWurm <Informatik>RahmenproblemWeb-SeiteLoginWeb SiteBenutzerbeteiligungFehlermeldungBildschirmfensterIndexberechnungSchnittmengeKryptologieGeradeBrowserProxy ServerMultiplikationsoperatorURLStrategisches SpielBitrateSystem FBitfehlerhäufigkeitBildschirmmaskeKonfiguration <Informatik>E-MailTrojanisches Pferd <Informatik>InjektivitätOrdnung <Mathematik>TypentheorieMAPEndliche ModelltheorieTransaktionComputeranimation
28:48
SystemaufrufRegulärer GraphBildschirmfensterDivisionKontrollstrukturProxy ServerSichtenkonzeptElektronische PublikationMenütechnikIndexberechnungRahmenproblemE-MailDemo <Programm>Konfiguration <Informatik>Digital Rights ManagementBenutzerbeteiligungComputersicherheitDesign by ContractInjektivitätFeuchteleitungOffice-PaketComputeranimation
29:40
Elektronische PublikationSampler <Musikinstrument>BildschirmfensterSichtenkonzeptLesezeichen <Internet>InformationsmanagementBildschirmfensterSchreib-Lese-KopfComputeranimation
30:19
MarketinginformationssystemVorzeichen <Mathematik>DigitalsignalLesezeichen <Internet>SichtenkonzeptHilfesystemDämon <Informatik>CompilerCodeProgrammverifikationLoginRechter WinkelWeb-SeiteMobiles InternetAuthentifikationComputeranimation
31:08
Lesezeichen <Internet>Elektronische PublikationIdentitätsverwaltungE-MailAdressraumBildschirmfensterSichtenkonzeptSerielle SchnittstellePERM <Computer>RechenwerkTUNIS <Programm>Web-SeiteEndliche ModelltheorieURLComputersicherheitSchnittmengeComputeranimation
31:53
ComputerElektronische PublikationSoftwareInnerer PunktHilfesystemSichtenkonzeptLesezeichen <Internet>Web-SeiteAuthentifikationCASE <Informatik>SchnittmengeComputeranimation
32:36
BewegungsunschärfeSichtenkonzeptLesezeichen <Internet>Baum <Mathematik>HilfesystemVorzeichen <Mathematik>BildschirmfensterKondensation <Mathematik>Elektronische PublikationCOMBrowserFehlermeldungProxy ServerComputeranimation
33:18
SichtenkonzeptBaum <Mathematik>FeuchtigkeitCOMProgrammverifikationHilfesystemCodeBildschirmfensterLesezeichen <Internet>Elektronische PublikationWellenlehreWeb-SeiteMenütechnikE-MailFormation <Mathematik>SchnittmengeAuthentifikationComputersicherheitBrowserCASE <Informatik>Computeranimation
34:14
Elektronische PublikationVorzeichen <Mathematik>BildschirmfensterCOMDemo <Programm>Befehl <Informatik>Web SiteURLLesezeichen <Internet>ZustandsmaschineComputersicherheitFunktionalKryptologieAuthentifikationInjektivitätBenutzerfreundlichkeitAggregatzustandSkriptspracheCodeBenutzerbeteiligungVektorraumVorzeichen <Mathematik>CASE <Informatik>RahmenproblemWeb-SeiteAppletMereologieWurm <Informatik>MenütechnikBrowserFeuchteleitungComputeranimation
37:13
ServerClientReelle ZahlKartesische KoordinatenStreaming <Kommunikationstechnik>ServerFront-End <Software>InjektivitätMultiplikationsoperatorEchtzeitsystemWeb-SeiteOrdnung <Mathematik>RückkopplungClientSkriptspracheMereologieBenutzerbeteiligungEreignishorizontHook <Programmierung>Zusammenhängender GraphComputeranimation
39:19
Reelle ZahlCodeMAPZusammenhängender GraphInjektivitätMereologieClientVirtuelle MaschineBenutzerbeteiligungWeb-SeiteSensitivitätsanalyseModifikation <Mathematik>Elektronische UnterschriftDifferenteOrtsoperatorKartesische KoordinatenCASE <Informatik>Computeranimation
40:37
Reelle ZahlDemo <Programm>Elektronische PublikationBildschirmfensterInformationsmanagementNominalskaliertes MerkmalBildschirmfensterMultiplikationsoperatorOrdnung <Mathematik>Kartesische KoordinatenEchtzeitsystemDemo <Programm>BitProxy ServerWeb-SeiteMereologieComputeranimation
41:20
BildschirmfensterSichtenkonzeptLesezeichen <Internet>Baum <Mathematik>Sampler <Musikinstrument>SkriptspracheTLSBitFormation <Mathematik>Computeranimation
42:01
HochdruckHilfesystemMarketinginformationssystemElektronische PublikationVorzeichen <Mathematik>BildschirmfensterLesezeichen <Internet>Kerr-LösungBaum <Mathematik>SichtenkonzeptPROMSchlussregelURLEreignishorizontInformationsmanagementCodeComputeranimation
42:49
Vorzeichen <Mathematik>Lesezeichen <Internet>BildschirmfensterInklusion <Mathematik>ProgrammverifikationVerschlingungElektronische PublikationSichtenkonzeptAuthentifikationPersönliche IdentifikationsnummerRegulärer GraphAuthentifikationArithmetische FolgeCodeMultiplikationsoperatorComputeranimation
43:36
RechenwerkBildschirmfensterAuthentifikationElektronische PublikationSichtenkonzeptLesezeichen <Internet>SkriptsprachePi <Zahl>MultiplikationsoperatorBenutzerbeteiligungInjektivitätMAPWeb-SeiteSpeicherabzugGüte der AnpassungGamecontrollerBrowserComputeranimation
45:09
Elektronische PublikationSichtenkonzeptBildschirmfensterTUNIS <Programm>Einfacher RingService providerRechenwerkWärmeübergangWeb-SeiteLesezeichen <Internet>Dynamisches RAMGamecontrollerSchlussregelEreignishorizontKette <Mathematik>ZweiMultiplikationsoperatorBildschirmmaskeAuthentifikationInformationBildschirmsymbolEndliche ModelltheorieBildgebendes VerfahrenWeb-SeiteInjektivitätVollständigkeitComputeranimation
46:31
BildschirmfensterLesezeichen <Internet>SichtenkonzeptZeiger <Informatik>SchlussregelZahlenbereichSampler <Musikinstrument>AuthentifikationComputersicherheitWeb-SeiteICC-GruppeElektronische PublikationInnerer PunktBenutzerprofilBildschirmsymbolAuthentifikationComputersicherheitSchnittmengeBrowserLastComputeranimation
47:11
Lesezeichen <Internet>MenütechnikKlasse <Mathematik>SichtenkonzeptBildschirmfensterEin-AusgabeEindringerkennungComputerspielGamecontrollerComputersicherheitWeb-SeiteSchnittmengeFehlermeldungVektorraumKryptologieTrojanisches Pferd <Informatik>ZustandsmaschineEchtzeitsystemBenutzerbeteiligungInjektivitätGefrierenLokales MinimumSoftware Development KitBrowserVersionsverwaltungVektorpotenzialFrequenzInformationAuthentifikationBenutzerfreundlichkeitKartesische KoordinatenWeb SiteComputeranimation
51:10
Computeranimation
Transkript: Englisch(automatisch erzeugt)
00:00
It is my pleasure to introduce you to Pedro Fortuna. Thank you all. Um, welcome. Um, thank you for being here. Uh, today I'll be talking about protecting crypto exchanges from a new wave of man in the browser attacks. Starting with a bit, a
00:24
little bit about me. Um, so I've worked in security for the last 15 years. Um, the, the last seven or eight have been mostly focused in JavaScript code protection. Uh, but before I started working in the network security side of
00:42
things, then I started building things like bot detection, device fingerprinting. And in the, in the last few years, I've also paid a lot of attention to man in the browser attacks and, uh, malicious extensions. So today's talk will be mostly
01:00
about man in the browser and crypto exchanges. Um, but I'll start off by, by, uh, a brief, um, overview of the man in the browser, uh, history. Then followed by, um, I'll cover, uh, the most common security, application security features that, uh, we have found in crypto exchanges. Then we'll get
01:23
deep into, uh, the attacks that we have, uh, seen in last March. And, uh, at the end, I will talk about application real-time monitoring, which is, uh, kind of a new approach that we have been, uh, working on that can help in this type of attacks. So for those who are not familiar with man in the
01:43
browser, it all starts with, uh, a device getting affected usually through, uh, email phishing. Uh, it's the most common way of doing it. And, and, and then the, the Trojan gains control of the browser and just waves off for
02:00
the user to go to a certain targeted website and it, then it makes malicious injections into the page and tampers 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
02:21
just wait for you to access the website and then they, they change like a transaction or just to collect your credentials. So it's, uh, it's, um, they do the very minimum to accomplish what they want to do in the website. And they
02:41
can be very subtle, uh, not all the time they will produce something that's visible, like it gets rendered differently. So it's very hard. So in this, in this example that you see what's happening is, uh, the web inject is modifying the, the transfer amount and destination account. Uh, but apart from that, that's not,
03:03
the, the, the, 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, uh, really an attack focused on the client side and it's hard to spot. So it
03:22
all started with Zeus, not the slot machine, but the version. Uh, it first appeared in 2007, um, and he was able to, to do web injects and also to form, to, to do form grabbing. And at the bottom you can see how
03:42
a web inject looks like. So it has three sections, uh, the target URL, uh, a reference where to inject and the injection itself. So in this example, uh, the web inject is adding, um, a field to a form that's
04:01
requesting an ATM pin from the user. So the source code for Zeus was released or leaked, uh, back in 2011 and this really opened the door for, uh, the number of attacks growing. We have seen a lot of, uh, different, uh, forks and, uh, uh, variants of Zeus
04:22
and they are still out there. In this table you can see, uh, the most common features that you can find in the main, 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
04:41
access, or, 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, uh, the most prevalent, uh, many of the browser Trojans were
05:02
still Zeus, which is surprising. After 10 years, it's, uh, the most prevalent one and followed by a couple of variants, NeverQuest and Gozi. Um, but you can see here that, uh, the attacks have been going on, uh, in the last 10 or 12 years. Um, and
05:23
really we are just scratching the surface. So there's so many attacks that go unnoticed, uh, but we don't have time to cover all of this today, so I'll just mention one. Back in 2015, uh, a drive X train was able to steal, uh, around 50 million dollars. And
05:43
what were, was worse is that it took two whole months for anyone, I mean, and, 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
06:03
exchanges? Um, are they up to the task? Uh, what kind of features they have that can mitigate or prevent this? This is what the question that we had. So we went for, um, a few exchanges to find out what they were doing. But there's too many
06:23
changes, um, I think the, the numbers I saw was roughly over 200 crypto exchanges right now, and so it's too many to, to make a survey. So we had to start somewhere and we decided to choose a
06:40
representative set, um, and, and the rule of thumb was, uh, let's select exchanges that are likely to be selected by, uh, users. So we went for the, the most popular, but not only the most popular, but the ones that have also interesting features that we know about. So trading volume
07:01
is interesting, ranking on Google search, uh, links and relevant sites and social media, and also known user base. So in the end we selected this six, Binance, Bitfinex, Bittrex, Coinbase, Wobi, and Kraken. So other exchanges could be, could
07:23
have been selected of course, um, but I believe the, the main conclusions wouldn't be different. So getting into the features, um, by now everyone knows what two-factor authentication is, it's, uh, can be used to frustrate attacks that only
07:42
compromise a single channel, so you have a second one. Uh, you can use SMS, you can use, uh, mobile applications like Google Authenticator or even physical, uh, hardware like Fido. Uh, all exchanges that we, we saw use, uh, two-factor authentication, uh, but they differ, uh, when
08:02
they force the use of two-factor authentication. So in general they can use this, uh, to confirm logins, withdrawals, password changes, API key creation, changing security settings, or changing other sensitive, uh, settings. Captchas are also
08:22
very common. Um, they are used to determine if the navigation is being done by a human or by a bot. And you have, uh, many different types of captchas. Uh, the early day captchas were all based in text, as you can see in the, in the right,
08:41
the top image. Uh, then the image-based captchas, uh, came along and become very prevalent. And, uh, in, in the last few years we are seeing more risk-based, uh, hybrid or dynamic-based, uh, captchas that's, uh, basically collect behavior information of the
09:00
navigation and decide whether they should allow you in or just serve you an image-based captcha if they are suspicious that you are, you may be a bot. So typically they are used in authentication and registration. And, uh, most of the, the exchanges that we analyze, uh, are
09:20
already using, uh, reCAPTCHA, which is the, the latter type of, uh, CAPTCHA, risk-based. But what you have to, to keep in mind is that, um, there's a, a, a high threat, which is the use of sweatshops to solve CAPTCHAs. So, especially if you are using image-based CAPTCHAs or even
09:42
text-, with text-based CAPTCHAs you don't even need, uh, sweatshops. But if you are using image-based, uh, CAPTCHAs, uh, 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
10:02
can scale that up and you can abuse, uh, 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, uh, starting with
10:20
two-factor authentication, of course. Um, but they are only forced by a couple. So only Binance and Bitfinex really force you to use two-factor authentication. So in, in the other cases, you can disable this option so it becomes a viable, um, road for an attacker to disable those options
10:42
and try to attack. So another thing is that they send an email, uh, on every successful login. So this is useful because if you receive an email and you haven't logged in, maybe you should take measures, right? Um, if you reset your password or two-factor authentication, some of those will
11:00
require you to, to confirm that action through an email they sent you. And in a few cases, that will all 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. Uh, and this is good.
11:22
You can also, uh, have, um, a whitelist of IP addresses and devices. Um, so you always have to confirm, uh, new devices. So not, not all exchanges have offered this. And, and in some situations, you have to approve as well, uh, through email. Um,
11:43
some ca- in some cases, there's also the possibility of freezing your accounts directly, uh, using the emails that you received, which is good because if you receive an email telling you about some action, uh, you can quickly disable your accounts and hopefully in time for stopping the funds
12:02
from being exfiltrated from your account. And all exchanges in general, they collect, um, they lock, uh, your, the actions that you do, and they make this information available to you so you can spot if, uh, where things have been done with your account. Withdrawal protections are
12:23
probably the category that, uh, I found more interesting, uh, because some of the features can really be helpful to protecting exchanges. For instance, uh, if you reset your passwords or two-factor authentication, like I said, uh, your account can be frozen for a certain amount of
12:42
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, the exchange
13:01
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 not, you don't wish to trade at all. And you also have a withdrawal address whitelist, so you need to specify, um, the, the, the crypto
13:22
wallet exchange, uh, addresses that you intend to do transfers to, and if you need to add a new address that can cause your, your account to be frozen during, for instance, five days, and, um, but the problem is some exchanges, they let
13:42
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, uh, lets you, uh, withdrawal for new IPs on new devices, but only if they were previously approved, and
14:03
you have a minimum of, uh, 24 hours, um, commonly, that you need to wait before they are really approved and, and cleared out to use. Uh, also, uh, as you can see in the, in the screen at the right, the image, some exchanges
14:20
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, uh, forging, uh, transactions or tricking you and, and diverting the funds to other accounts. So if you don't find your secret phrase
14:42
there, maybe it's an automated tampering attack and you need to watch out for those. Uh, there's also some anti-phishing, more anti-phishing, uh, techniques. Um, you can set secret phrase that's sent in every email that you receive to prevent
15:01
email phishing, and you can also configure, I think in, in a couple of exchanges, uh, uh, PGP keys to, to be able to, to receive the encrypted emails. So this is useful as well. Uh, pretty much all of them use HTTPS by now, and, uh, I think, uh,
15:21
only Binance, no, a couple of them, uh, they, they show you, uh, warnings, uh, 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, uh, to make sure that you pay attention to those things. Last but not least,
15:42
content security policy. Um, so after going through all the six exchanges, um, I'm kind of disappointed because, um, what I saw is most of the exchanges are not using, are either not using CSP at all or they are using it, uh, very
16:03
wrongly. So as, as, um, as a couple of friends of mine, Michele and, uh, Lucas from Google said, and they speak about CSP a lot, um, over 94% of all CSPs based in whitelists are bypassable.
16:21
So we shouldn't use them at all. Oh, oops. Um, and, uh, and what I saw is that, um, at least more than half of these, uh, exchanges, they are using whitelisted domains in CSP, which they shouldn't do at all. And plus they use unsafe
16:43
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 know, I think they
17:03
should, uh, fix this. Uh, CSP should be used, but it should be used right. And I really can't recommend enough the use of CSP evaluator, which is a tool from Google, uh, that can warn you off if you are doing, like, obvious mistakes in your
17:21
CSP configuration. So in this table, you can see a summary of most of what we already talked about. Um, also I included, um, the X-frame options that we have found in these exchanges. And the general overview is that most of them
17:42
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 moments is, uh, denying iframing from within their website. Uh, other things that you can see, the two-factor
18:00
authentication, uh, in the case of Binance and Bitfinex, they are being forced in a lot of, a lot of the actions that you can do. In the, in the remaining four, uh, you can disable two-factor authentication. And, uh, and this is bad because, uh, many of the browser can
18:20
exploit this by disabling the, the, the requesting two-factor authentication. And, and, uh, so it becomes a, uh, useless, uh, uh, security feature. And this is the same table, um, with, uh, the positive, positive things and negative things. And I believe this table should be way
18:42
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
19:02
scripting, um, disabling framing from within their, their websites. So, no one gets out easily from, from this. So, the main takeaways is that improvements can be made. CSP is not being used properly. Um, in one case, I didn't point out that
19:21
Bitfinex is using text-based CAPTCHAs, which are very used to overcome if using OCR or whatever. Uh, you should ban framing from the, from, of the website from within, uh, which is also useful to mitigate, uh, attacks like click-checking, uh, so you
19:41
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 whitelists can help.
20:01
They, they should be used, but they should be forcefully used with freeze time, like, freeze time. And, uh, the anti-phishing, tamper-proof images are also good to, to, to fight bots. But some of the stuff were down by the exchanges, so they
20:21
all use HTML. Uh, they, they all factor one, two, okay? So, factor authentication, they all, they all log, or history. Wait a second. But, um, but
20:45
if you look at what's being done, we are using a lot of two-factor authentication, CAPTCHAs, countries, whitelists, this and that. And the overall usability is being heard. So, what we want
21:01
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, um, I heard in the news that, uh, Coinbase and, uh, um, blockchain.info
21:24
were being targeted by many of the browser attacks. And it all started by the work of, uh, a couple of malware researchers, uh, Dowin, Kosovan, and Kathleen Valerio Lita from Security Scorecard. So, they did a whitepaper on
21:40
this, and basically, uh, what they found is, uh, this was an attack caused by Zeus Panda, which is a variant of Zeus. And they were targeting, um, so, what, what stood out from this is that among 50 targets, we found two crypto exchanges. And this
22:02
really caught my attention. So, I've, I've read the whitepaper 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, uh, it has a div element on, in the top, and
22:20
then you have an inline script. Hello, use of CSP, please. And here you can see the obfuscated, uh, 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, uh,
22:43
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 web, the menu browser out there is, uh,
23:03
injecting when people visit the websites. But then, at, at that moment, they will dynamically load a second stage JavaScript payload, and that can evolve. It can, can do different things through, through time. So, in this case, it's only doing that, and we, we didn't have, we didn't have all the details.
23:23
So, with, with the white paper, you didn't have access to all the second stage payload. So, and we wanted more, more details on this. So, we reached out to Doena and Cataline, and we were able to discuss the, the attack with them, and they were kind enough to share the,
23:42
the, the stage two payload with us. And based on that, we implemented for coinbase.com, uh, a C2 capable of interacting with the JavaScript payload, and we are doing the injections, uh, in the browser, uh, using burp proxy. So, this is
24:03
what we know. So, initially, the user visits coinbase. Uh, at any given page, the web inject is always injected, no matter what inner URL you are visiting. And, uh, when you access
24:21
the login form, uh, they overlay, they, they, they put a button over the real button, and they disable the enter key, so that you cannot use that, because that will, would trigger the, the bottom real button, and they force you to click their own button. So, it's
24:41
kind of a, uh, easy trick they can do. Uh, so when you log in, they will extract your credentials, but they will also, uh, put forward the normal login. So, after log, you log in, uh, at the dashboard, they will
25:03
present you with, uh, this model window that says that, uh, they detected unusual sign-in activity. You're probably trying to log from a new location or device, and, uh, so it seems pretty generic, so it could potentially warn you off.
25:22
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, the
25:41
two-factor authentication, uh, credentials. So, let's imagine that you enter it, and, uh, when you do that, they will basically use that credential, that two-factor authentication, to load the security settings page in an iframe, so
26:01
that's why we don't, we shouldn't allow, uh, your website from being iframed from your own websites. Um, so they load the security settings, and they set the requesting two-factor authentications to none, to never. So, uh, basically, you are just downgrading security in
26:21
the website. So, one thing, 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,
26:43
um, if you try to go to the security settings page, you are presented with a, uh, one-line error saying you, that something went wrong, please try again later. And this is presently what it, uh, what it does. What it could do, it could initiate,
27:01
uh, a transaction for an, uh, 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
27:20
be done immediately. All your funds are lost. And this is far too appealing, because, uh, you cannot undo this, and the money is untraceable. So, why shouldn't many of the browser trojans target, uh, crypto exchanges? They should. It's easier than targeting, uh, uh, a conventional bank, in my
27:42
opinion. So, this is how we implemented the attack. So, we deployed the burp proxy, and the burp proxy is doing, is, uh, applying the web injects, but it's also stripping the CSP and the x-frame options headers. And why we are doing this? Because
28:02
we believe that after the attack, Coinbase, uh, disabled the, uh, framing within their website, and this attack, in particular, is using the iFrame, as I told you. So, in order to replicate how it, how it works, we are stripping the
28:20
headers. Uh, and by the way, Coinbase, like I said, is the only exchange that, that is presently doing this. Uh, all the others are still vulnerable to this type of, of, uh, iFraming. So, obviously, we configured, uh, a browser to use the proxy, and the JavaScript
28:43
payloads is communicating with, uh, C2 that we have implemented. So, now it's time for the demo. So, here in burp, you can see that we are, um, removing the, um, removing, replace
29:04
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 couldn't see very
29:26
well, but this is the same as I've shown you before. It's, uh, obfuscated, but, uh, it's obfuscation is really simple. So, in five minutes or so, you can, you can reverse this. Not really a good barrier. Okay, so, we are
29:42
already, um, running our C2. So, let's head to, so, the window is, is not very big, so I'll try to do this the best I can. Okay. So, let's go to
30:13
Coinbase. This is not, it thinks it's in a mobile
30:26
device because it's, uh, really short. Okay, login. So, right now, it's already tampering with
30:48
the webpage. So, this sign-in button will exfiltrate the credentials. So, I need to use the two-factor authentication running in my
31:02
mobile device and verify it. So, here is the model that's injecting into the webpage. They're probably trying to log in from a new location.
31:22
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
31:57
authentication tokens again. So, this is fake, of
32:00
course. Let me just use my mobile device. 215. In
32:21
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. And now, if you go to the settings, you see this
32:42
error. So, something 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
33:03
using the burr proxy, we can confirm. Okay. So,
33:37
we can confirm that, right now, the security settings, the two-factor authentication is
33:42
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
34:00
immediately. Okay. Okay. So, what have we
34:31
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
34:43
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. The attack
35:01
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
35:22
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
35:42
visible iframe. 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
36:03
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
36:22
tricked because it's so confusing when and when not two factor authentication is used or is used or should be used or why it's used. So, it's, you can easily be tricked with this. And, we assume that in this case, Coinbase has since disabled the iframing from within their
36:44
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
37:05
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.
37:34
Okay. So, this is what we came with, application real-time monitoring. And, this is more or less how
37:43
it works. So, it has two components, the clients and the 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
38:01
injections, and for modified haven't 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.
38:21
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
38:40
webhook. So, this webhook 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, you can blacklist the user, automatically freeze the
39:02
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, more things to the clients as a feedback loop. And, this can be really helpful. So, it follows a white-latusing
39:22
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
39:41
injections, in which case, it can launch counter measures. So, it can remove injections that we already knew about. But, it can also redirect a page to a certain URL, delete cookies, or execute a custom callback in the client side. So, this is, is very flexible. Of course, all of
40:03
this is done by using code protection because the, 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,
40:21
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
40:43
application real-time monitoring. So, I'll, 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 bird proxy. So, this, this
41:01
part is adding the agent to every web page dynamically because we, we couldn't get Coinbase to install it in time for this talk. Sorry. And, and let's go here again and let me open the, the
41:25
dashboard here. Okay. So, I, I want you to be able to at least see a, a portion of this, uh, graphic in the back. So, I'm, I will try to position things so that you can see a little bit to see
41:42
what happens. Okay. So, I have to, I have to restart C2. Okay. We're done. Let's go. So, we
42:16
are already seeing things in the back. Just a
42:20
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.
42:46
Let's proceed. This is the regular two-factor authentication that's Coinbase requests. So, here
43:13
you can see the iframe. So, sometimes the code
43:21
isn't, 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
43:41
the time they are adding the web injects to, 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, if you do a dump at
44:02
a 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
44:24
course. Sure. So, yeah, good question. So, BERP is replacing me having my device infected. So, if I,
44:42
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, the, yes, I know, I know. We, we have shown you before. I, I can, I can show you in the end if that's alright.
45:02
Okay. I can show you again. So, let me try this again. Alright. Seems to only work at the second
45:27
time. Shit. Okay, so you've seen this before. Let's
45:42
see what we have here. We have quite a few injections in the page. Let me try to show you, uh, and to understand what, what kind of information we can supply. So, here you can see this is a
46:00
form and it's actually the two-factor, uh, authentication, uh, thingy where it's request, like the model, complete model having the, the form to request the two-factor authentication and let's see another. Okay. So, this one is in the dashboard
46:24
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
46:41
don't know if you remember, but this is the kind of thing that you can collect as well. Alright. So, let us go to the security settings. Oh, I'm in the browser. Okay. Load the security settings. Something
47:09
went wrong. Please try again later. Okay. So, four new threats. This is all live and we can see
47:20
that a bunch of DOM has just been removed from the security settings page and this is the actual, uh, control security controls that you usually see in the page. They have been removed and the attacker has placed the error message. Okay. So, so in
47:44
conclusion, uh, if there's anything I'd like you to take away from this talk is that, uh, crypto exchanges are being targeted by many of the browser and they should beware of, of this attack vector. Uh, of course, every other vector should be
48:02
in their, uh, horizontal as well. Um, 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, uh, really difficult to, to find out who, who stole the,
48:21
the money. So, I, I think this, this, uh, attacks against Coinbase and blockchain info, uh, can be seen as warnings, uh, because the, the work, after all, was, uh, incomplete. We don't know if there were consequences. Um, we know that the credentials could have been stolen during this
48:41
period. So, we, we don't know if someone is using, using them in any way. Uh, but we know that at least this version of the Trojan is not yet stealing money. Um, and other conclusion is that two-factor authentication, uh, is not enough for this attack vector. So, definitely,
49:02
exchanges can improve their defenses, things like temporary freezing the account when you change anything about the security of your account and, and I don't mind paying with usability, but at least do it right and don't, don't provide
49:20
workarounds for people to just go and disable two-factor authentication, uh, because this can also, uh, be a tool for, uh, web injects and for Trojans to, to be able to, to perform their attack. So, I think attacks will most likely get more creative and, um, and they can
49:41
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 add stuff to the DOM, removes others and implements a state machine to control
50:00
how you are doing that. So, it's not really sophisticated. It's really simple and due to the potential returns, uh, I think we are definitely seeing more stuff. I think for this attack vector application, real-time monitoring is, is really, uh, can be effective. Uh, we just
50:21
assume that injections will occur. We cannot prevent that and try to detect them in real-time when they do. Uh, 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. Uh, and, uh, as you know, if attacks
50:41
keep failing, uh, 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, uh, like Ming said, uh, because I shouldn't, uh,
51:03
unless you pay me a beer afterwards, uh, then I can consider that. So, this is all I have. Thank you.