BSides DC 2018 - Caught my WebApp cheating on me!

besides DC would like to thank all of our sponsors and a special thank you to all of our speakers volunteers and organizers for making 2018 a success thank you for being here my name is Bella Fortuna actually this is my third of four besides talks this year and it's my first time at besides DC I'm very excited thank you for being here I'll give you a couple of seconds to read that

so we see this every day on the internet and social media and most of the time it gets our attention for humans we are drawn upon things that went very bad or stories the hit the fan and there's nothing that we can do about it so if you think about it it's a bit like when you see IT security related is right and that's precisely the first part of our talk today we're looking into client side integrity or stories then we'll see a couple of recent attacks of malicious injections on the client side then we'll move to the main theme of this talk which is application real-time monitoring a new approach that we have been working on in the last few years

and then I'll do a live demo and conclusions now at the end I will tell you whether or not I caught my web app cheering this is our talk cliffhanger a little bit about me so I'm a co-founder and CTO at J scrambler I mostly work with client-side application security and mostly focused in JavaScript code protection but before I've worked a lot with bot detection behavior analysis on the browser side and anything that's related to many in the browser or malicious extensions basically gets my attention in late 2014 jQuery CDN was breached and for a number of hours any website that was loading jQuery directly from their CDN was basically serving and exploits the the reek exploit kits to every user

that was visiting those web sites so this meant a massive dissemination of malware to everyone and probably a lot of people got compromised that day so this only lasted a few hours but it was probably the first incident I can remember that it was so bad and back then I mentioned that probably are going to see more and more of this attacks because they are far too appealing in 2015 drydek strain I mainly the browser trojan managed to or work was targeting hundreds of different banking websites and basically it managed to the attackers managed to get out with 50 million u.s. dollars and the worst thing is that it lasted two months before anyone took notice so even though

many of the browser trojans exist since 2007 2008 in 2015 most of these banks are not ready yet so they are not targeting this type of threat last year we have a server bridge - - a dependency and some companies like Equifax TransUnion they were serving and I quote a carousel of madness to all the users so they were serving a survey to collect sensitive user data they were serving a fake flash plugin to everyone and they were using that to basically infect the end users device and from their own just collect sensitive data credit card data and and so on this year in February a library a JavaScript library called browsealoud which is basically a library as the name

suggests is used by websites to read out loud the text in the website so it was compromised and more than four thousand websites that were using this library at the time they got infected with this extra code that was coin Heinz library for those who are familiar it's a cryptocurrency library that was using the end users computers to mine Manero for for the attackers so one of the websites so this gotten into the news it was kind of controversial because one of the websites is UK's ICO which is an institution that is meant to protect the individuals privacy so and they they got their users to be crypto mining for the attackers this year in I

think in March there was a man in the browser attack I think it was Zeus Panda strain and it was like always targeting a lot of financial institutions but what caught our attention is that it was targeting coinbase and blockchain dot info as well so probably it wasn't the first time that many of the browser trojan is targeting crypto exchange but probably it was the first time that really caught my attention and we have been seeing this for a while so it was discovered by a couple of researchers from security scorecard a research company and we we we got ahold of their contacts and we collaborated and one of the outcomes of that collaboration was a

talk that we did at Wallace ship at Def Con this year where we showed basically how the attack works and all the very little detail so a month ago roughly an extension mega and Z is a quite popular so the attackers managed to get developer credentials and to just commit a modified version of the extension so if you know how it works its kind of automatically is rolled out to every user so you don't have to explicitly approve the the update of the extension and and it was basically collecting credentials from websites like Gmail or Yahoo and also collecting private keys from crypto exchanges so he only lasted a few hours but this extension has 1.7

million users so if you do the math even if it only lasted for a few hours it was enough to compromise a lot of users and a lot of credentials got captured and this keeps going on and on every day more recently in the last three or four weeks we have seen a rise in the attacks against ticketing companies and e-commerce companies from a group called mage cards so they basically they in fact they breach servers they modify codes and they were they were able to steal around 40,000 reddit card information a Ticketmaster and at British airlines it was even worse they got away with 380,000 user details and credit card data so we are certainly

seeing an increase in this type of incidents and we have been paying a lot of attention to all of this so last year we developed what we call the next-generation man-in-the-browser Trojan where we showed people that using an extension any extension and the normal capabilities that you get with an extension you are able to fully capture any information from the user you can take screenshots you can accelerate all the information so it's very easy and there's a double standard in regards to browser code basically all the code in the browser is thoroughly screened by a lot of researchers is considered to be quite secure even though we discover a few vulnerabilities now and then but if

you think about it the extensions aren't most of the time they are not screened at all no one checks the code in these extensions and the users just like almost finally install these extensions and provide them a great power to to capture user information what it's worse is that extensions can remove security headers so if you are relying in CSP or things that use security headers extensions can remove them as well so here you can see a summary of things that compromised client-side integrity so first you have malicious or compromised third-party libraries you can use vulnerability tracking to check whether you or not you are using something that has known vulnerabilities but has you know that can fail we are

not sure we are catching everything you can use sub resource integrity where you can add attributes to your script tags or to other tags that enforced tell the browser to enforce a checksum before loading a certain resource but keep in mind that many in the browser Trojans can remove this they can basically alter anything any part even headers of the website before the browser gets to load them you can use CSP and you should it's it's well developed and has evolved a lot but keep in mind that both men in the browser and malicious extensions can remove them malicious browser extensions you can eat you can you can and you should rely in browsers towards screening and

blacklisting but that doesn't work very well and usually is reactive so it gives usually some some hours or days to the attackers to do what they are in wanting to do you can rely on the antivirus but most of the time it fails to detect malicious code on the client side and basically you end up only relying in the end user not to basically do the wrong thing and install something that is malicious but as we all know most of the time that fails to because users are not security savvy and be let's be honest even security guys get infected once in a while so it's it's hard unless you are checking all the code from every website

that you're loading you cannot be sure to be 100% that the website has not been tampered with and there's no malicious code running in there so then you have the men in the browser web injects well there's really not a good solution yet for this I always say that you better assume that some of your users will be compromised will will have their browsers compromised and that the codes that he is seeing might might be temporary then you have things like server breaches or exploitation of common vulnerabilities I exercise quick tracking well you should do the whole array of things like vulnerability scanning pen testing run your boning programs roll out your security headers and you should do all of that in a

defense in depth strategy but that doesn't assure you that you are just filling all the holes in your web application so what's the main takeaway here first we are relying too much on third parties so we are relying on vulnerability tracking to do its job to discover very fast whether or not the dependencies have problems we are relying in third parties from which we load third party JavaScript not to infect us obviously they are not doing it on purpose but they they get breach as well and and most of the time it's easier to breach a third party than to breach like a very large company with lots of InfoSec people working on it we

are trusting browser extension stores to filter out any malicious extension and we quickly catch those that are tempered maliciously we are trusting antivirus to be efficient but they are not even even they say that they are only efficient 40 percent of the time which which is probably even lower and we are trusting end-users not to get infected and as you know that doesn't work so all the solutions I've mentioned they have limitations I encourage you to use them but they have their flaws and limitations for instance sub resource integrity as I mentioned before can be removed security headers can be stripped and any vulnerability assessments can let a few vulnerabilities slide through so the last idea and is that this this

type of attacks they are far too appealing I mean you can always like we always say that you shouldn't store things in the clear on on the server side like credit card data and all of that of course and even if you store sensitive data you should use strong encryption and all of that but you have to understand that some of these attacks they don't even target the end web sites they only target like and third parties so they don't have access to even if they breach the server it's not going to be the server of the end website it's only like the middle third party library and even if they manage to get into the server of the end

website if they use strong encryption they cannot have access to the information but by tampering with the client side they are seeing information flowing as the user inserts that so certainly is not encrypted at that point and they can exit rate that very easily because it's hard for the server side guys to have a reach into the client side and just stop that from happening so basically a few years ago like a couple or three years ago we were thinking about this problem and thinking how to solve this and basically we just for a while we just quit we just let's well injections will occur tampering will occur so how can we solve this problem

maybe we can detect the problems and and deal with that later so when when thinking about how can we detect this we kind of were like bouncing off ideas and at first we thought where should we detect the tampering should we do it at the network level or at the Dom level so at the the network wouldn't work because some tampering only only are done later when the page is loading so definitely we need to do it at the Dom level then we must do it in real time because after the injection occurs maybe we have this short window the time where we can react to what is happening maybe we are if we trigger

some reaction on our side we can do something it must be transparent so it mustn't must not require an end-user installation of any plug-in or any and user software and it must be scalable because we are talking about screening and monitoring the Dom of thousands of millions of sessions across many websites and it must be precise it must not be too noisy because as if you are if you have developed a web application recently you know that once the page loads there's lots of things happening on the on the client side that the Dom keeps shifting and shaping as things occur so the new approach basically checks for Dom modifications as they occur it checks for any

tampering to event handlers code like when you submit the form it checks if the code running is the code that it's supposed to be there and it protects native API functions from poisoning like XML HTTP requests and when things are detected it sends out real-time alerts to a back-end component and from there to a web hook on the web application I will explain in more detail in a second and this allows the application to trigger automated reactions or preset policies so this is the architecture so on the client side we have real-time monitoring agent this is playing JavaScript that you need to embed into the web application and it keeps monitoring the Dom for the things

that I've mentioned and for that you use this mutation of servers if you are not familiar it's a browser API where you listen to modifications to the Dom like new elements coming in elements being removed we also use checksums for certain parts of the website that are not expected to change that often like login forms and we are using just plain old techniques for detecting poisoning of JavaScript native functions so when things are detected information gets sent out to server components real-time monitoring back end where things are processed and we basically need to know if it's a false positive if it's normal if it's not we use machine learning and then if we decide this is an alert you get sent

to the backend of the application using a web hook so based on that information flow that the application can decide if adjustments need to be done for instance should we kick the user out of the session should we present a message to the user saying that probably his device is infected or should we just send a notification to our fraud Department for them to check this out anything is possible and it's up to the web application to decide what to do in each situation so it follows an whitelisting approach so any previously unseen injection can be detected using this approach has different levels of the sensitivity meaning that if it's something very minor that happened some

UI modification probably were just going to dismiss that off we're not doing anything about it use machine learning to distinguish between things that are normal and not normal and things that are probably dangerous or not and it also supports signatures so we can we can this is totally optional but we can add signatures for a better recognition of specific threats like men in the browser injection we want to know which which men in the browsers frame this is this is just an example the client-side countermeasures that we can do and we can do Dom healing so if a certain block is injected we can remove it but it requires the signature for that and we

can also do things like redirect to a certain URL delete cookies or executed custom JavaScript callback on the client so the real-time alerts other examples that we could be talking about actually I already mentioned those so I'm skipping so as a caveat to be effective the the real-time embedded agent running on the browser side it needs to be delivered with protection otherwise it can be a target of the injections can be removed can be modified so in in our case we are using polymorphic JavaScript confiscation which means that we have the capability of every hour or even every request can have a completely different agents in the in the page which means it will not be easy to tell

which names we are using how is it working and to make it harder to automate something against the agent its tamper resistant meaning that if some poisoning is attempted the code will react to that will break the code and has debugger detection and to make it harder to tell what what's the agent code it can be mixed together with the code of the existing website so using recompilation of the javascript so now time for our demo sorry and for the demo I'm running a website a dummy website from my own laptop okay don't worry if you are not reading that it's not important okay and now let me load the website so here this is the

virtual bank application and things are already going wrong with this application and to prove you that let me load the same application in a blank profile so if you compare both you can see that the banner in the middle is not present on the right-side version so we're talking about two different profiles the the right one is not infected the left one is infected so what's going on here is this banner that's in inviting the user to download mobile application which is fake has this Google Play buttons we can click on those and we are taking to a copycat of Google Play Store but if you look closer you can see that's actually played Google not Google all right this is kind

of stupid because actually it would be easier easy for the attacker just to get certificates and and avoid the not secure alert here so it could be even stealthier than this and this version contrary to the normal version doesn't have an install button but rather a download button so if we are running this application from our mobile phone and if we have installing from unknown sources probably if you click that you will get an APK and if you click on that you will install the malicious application on your device and from this moment after your mobile device is compromised so this is the story and now I'm basically redoing the same thing but now enabling the application real-time

monitoring because this is the demo this is very simple so it's just a script tag in the webpage that I am uncommenting so I'm going to enable the agent manually so usually it's not installed like this all right so this is the dashboard usually this is only available to the owner of the web application not to the end-user of course and now I'm going to load the virtual bank application again and please pay attention to the banner so after a second it's removed from the web page and as you can see in real time we get an alert here if you look closer it's a blacklisted fake mobile half an hour signature that has been removed so

like I mentioned a while ago we can only remove things that have been injected if we have a signature so in this case we did have a signature that's why the description is so complete let's see what what sort of information we can check so we can check the client's IP we can check the URL the user agent and this is the most interesting part where you can see the actual markup that the user was seeing so everything from this point to this point was the injection so this whole diff element was injected and we can see all the dirty details so you can see that there's a link to play that goggle we have data URI we can see

everything right and now usually from a back-end perspective from the InfoSec team perspective if you want we cannot see anything so you just assume that whatever leaves the server is what the user is seeing but but we know that does that doesn't happen all the time so how can we see what the user has saw we depend upon the user to report this and usually it only happens like a month later when he checks the credit card balance and maybe he will recall the something was off about his session in online bank but most of the time it doesn't need to there's no visual indicators that something is different about that website we'll see the rest of

the examples so let's proceed just keep in mind that at this point the the application knows that this session is probably tainted or compromised so he could the application could be already reacting and actually preventing me from logging in into the application that's not the case in this demo but it would be possible and easy to do so I'm just logging in and even before our login I'm seeing new threads coming in and this one is a little bit more generic so this is a well you can call it a zero day if you want it's not actually a vulnerability so I'm not totally it's it's not really a zero day in that sense so the in this case is called poisoning

on submit poisoning on the form instance let's check this out and here you can see that the login form in this case the the form wasn't modified but the attacker modified the on submits codes that gets executed when you click the login so this is a very simple code all it's doing is just exfiltrating the users credentials after a HELOC it logs in so we are not doing anything at this moment let me just proceed knowing that my credentials were captured and now let me do a transaction so here I have few accounts okay new things are happening here another code poisoning actually this is very similar to the previous one because the on submit function has been replaced but

in this case it has more details so you can see that the attacker is collecting the original name the original destination bank accounts that his storing everything in session storage probably because he needs to use this information later and we'll see and his pending his own destination account which is probably a mule so the the transaction will be actually done to his mule account and then it's like regular online banking fraud alright so again we are not doing anything at this moment just to show you what happens in a normal attack that's that's successful so here we can see that more things are happening in our text poisoning if we go to the details we can see that this is

actually the destination bank accounts that the user intends to transfer to so what's happening is that the MIL account was sent to the bank and the bank just serves normal transaction validation pay where you would see the mill account the number but to prevent the user from suspecting anything the attacker is fetching what he stored in session storage and just poisoning the text elements in order for the user not to suspect and this is it basically okay and this is the final summary and again the attacker needed to tamper with this so he has a summary what sort of attack vectors because we just saw one use case what sort of attack vectors are we

catching with this approach we are catching man-in-the-browser injections of course malicious and compromised extensions malicious and compromised third party lives or CBN's XSS require requests that are made out to third parties that weren't supposed to be made like exfiltration of data and user base tampering so if the user just like poking around just opening the debugger and changing things we can detect that as well so there's footnotes provided that these injections manifest themselves in the Dom so the Dom needs to be changed in any way native library needs to be modified or poisoned otherwise if we don't see anything we cannot catch the this type of attacks and what sorts or things are these attacks doing really so they are

treating the user into like doing something that against his one own interests like requesting a two-factor authentication token actually remember the coinbase man-in-the-browser attack that i mentioned before what they were doing is like serving an a fake message to the user saying that hey we detected and recognized an array and recognized device using this session so pleased to confirm that everything is okay just provide me a two-factor authentication token so this two-factor authentication token was never requested from the website and what the script does is uses that two-factor authentication token to downgrade the security settings in coin basis settings so after doing that they can initiate transactions from the user account without actually the need to

give a two-factor authentication so in summary to factory education doesn't protect you from this type of attacks they are serving exploit kids they are collecting an actual trading credentials keys they are doing form jacking data exfiltration you are doing customer journey I jacking which is things like and in ecommerce website they might put an ad next to a product saying that hey you can get this product cheaper in a different website just click here and and that drives the way the users supply chain attacks this is what we call when a third party library is compromised or a third party server is breached and the code is modified usually it's easier because they they have fewer InfoSec

resources they do less to protect themselves then actually the the companies that use their their library they are injecting ads injecting forms and doing crypto jacking and this is the cliffhanger so if you are still interests so did we really cut our web app cheating and the answer is yes so when we started using application real time monitoring we just use this on our own website and we use Braintree to collect credit card payments and back then we were using their version one of the API and because it was based in JSONP it was basically when when purchased a plan in the website it basically prints this script tag for a split second into the DOM and for that

split second you can see all the credit card details and this is available to us that shouldn't be looking at this that's why we use a third party to collect this kind of information and it's also available to any third party that we are using in our own website so if you use a third party is a good rule of thumb is just put it put that third party in an iframe in the sandbox iframe if you can you should do that but still this is bad and this is something that we only caught by using application real time monitoring and of course we detected many other things but this is very compelling example because you can see

the the credit card details of our clients so in conclusion the client side is the danger zone danger zone it's too many ways that someone can tamper and modify the application which which you should use defense in death use all that you can't owner ability tracking tools sr ICSP etc security headers but Heather based defenses are weak are still weak and if you look at everything that's being done in the w3c institution we are mostly relying in security headers to enforce things in the browser but unless we solve the malicious extensions or extensions they have too much power than they can tamper with with with the security headers unless we have a good solution to solve the men in the browser

this is not going to hold application real-time monitoring just assumes that injections will occur and tries to do something with it it tries to notify the application in real time and even though it cannot stop the modification or the injection it's the the best next thing because you can kick the user out of the session and stop things before real problems occur like transactions going out but sometimes that may not be enough if sensitive user data is exit rated but at least you know about it immediately not two months is later when it gets in the news right so you can it's also useful for security professionals because you can see what the user is seeing you can investigate

you can see what sort of JavaScript was being run you can see if they try to exit rate to a third party server you can try to follow the lid and and see what you can do about it and like everything in security if you put in enough barrier probably the attackers unless they are really motivated unless their only target is you probably they will just move to the next target because it's easier and attackers are usually lazy and this is all I have for today I think

thank you I think we have around nine minutes for questions

yeah this is a commercial solution my interest here was not to pitch it but rather to talk about how it works and the benefits because you if you want you can roll out your own solution yeah

sorry maybe you can speak a bit louder

now the signatures are for the malicious things so it does really it does follow a whitelisting approach so it detects any modification so you're not required to have signatures but if you have like if you want to just add more detailed information on the threat if it's a known threat you can use signatures