BSidesSF 2018 - Caught My WebApp Cheating on Me! (Pedro Fortuna)

[Music]

hello all right it's working so thanks for being here my name is Peter Fortuna and basically I'm here because I caught my web app cheating on me yeah so ever happened to you raise your hand no oh one guy at the top yeah sure did you are just too embarrassed to confess anyway a little bit about me so I I'm a security guy I always loved security I work in security for the past 15 years give or take first I started working mostly around network and system security then I moved to JavaScript based stuff and started doing things like browser reconnaissance device fingerprinting all of that - mostly to detect BOTS but then I I saw

the opportunity to do something like to make JavaScript more resilient and that basically was the beginning of a scrambler where I work and I'm the founder and CTO so today we'll mostly cover application integrity hopefully I'll provide wider view on the topic raise awareness I briefly covered client-side integrity threat landscapes then I'll move on to application real-time monitoring which is the new approach that we are working on followed by a demo and Q&A so I thought of putting a kitty photo to win you over from the start it didn't occur to me to me that it would be displayed in am imax which makes it even more exciting anyway so everyone that has ever developed a

web application they just assume or believe that whatever leads the server is exactly what gets executed on the client-side right actually wrong the reality is a little bit more Gortex grotesque there are lots of things that can impact and mess with the integrity of the webpage like tampering and client-side injections so here you can see John it's transferring 1,000 euros to his body Steve but in reality a hacker was able to change the amount to one hundred thousand euros and the destination account number to its own so this attack is called man-in-the-browser and it's just one of the many types of attacks that can impact the user experience and commit fraud in late 2015 the drive act strain which is a banking

Trojan and many in the browser Trojan was able to steal 50 at least 50 million dollars and what is worse is that this all happened like the first initial two masses no one noticed so it was able to freely tamper with transactions and steal the money and this is just one example I mean we have lots of other examples we don't have time to cover them all today this is a different type of attack clickjacking also known as you are redress in this attack they they are able to stack an invisible iframe on top of the of a website so here the user thinks that he is just about to start playing the best game ever but in

reality they are clicking heels clicking the invisible iframe on top of it and things are aligned so that he in this case the targeted website is Twitter and the play button is aligned with the delete my account but so he is about to delete his Twitter account we should totally use this one on a few people so roughly four years ago I don't know if you guys heard about this one but it's pretty scary so jQuery see the end was hacked for a few hours and so it means that everyone every website that was loading the jQuery from their CDN directly they end up serving a reek exploit get to every user of those websites so we are talking about

millions of users being served an exploit kids so it's instant and massive dissemination of malware and obviously this is very appealing to attackers a more recent one last February browser allowed which is a vendor that basically allows you to to read out loud the text in the website their server was breached again and coin hacks library was injected into their library so around a little bit over 4,000 web sites were affected by this and all of their users were mining crypto for the attackers including UK's ICO which is the institution that protects UK individuals privacy which is ironic so before moving forward let me take a step a step back and say what we mean by application

integrity so you have application integrity when the application is executed the way it was designed to be its services and data is only accessed by authorized users and in strict compliance with its software license so what sort of problems can you have around application integrity so on the server the server can be breached your website defaced your code can be modified data can be leaked but it's more or less easy to defend compared with other attacks because you control the environment right to you especially if you don't have application vulnerabilities then your application can be modified in flight using a man-in-the-middle attack again it's easier to defend especially if you don't screw things up our new zero-day SSL

presents itself but it's on the client side that things start to get messy so you have I'm going to talk about four different categories of attacks that can compromise your integrity of your application starting with common vulnerabilities this one is kind of obvious so if you have an XSS in your application that can be leveraged to execute arbitrary JavaScript in your application and and they can change everything about it like the Dom existing code etc also click jacketing that I already refer to and to prevent this you can you can do your own pain testing you can run but bounties and and you can use content security policy to reduce the risk of being accessed

obviously pen testing can leave some vulnerabilities out so you are not 100% sure you are catching everything and for clickjacking can use the extra options header which is now being deprecated in favor of the frame ancestors directive in the CSP header but there's a problem with this because they rely in security in HTTP headers and that those headers can be removed by malicious extensions or by many in the browser Trojans so you can have malicious third-party lips which is a challenge to track an audit everything that you use so you can not be 100% sure that you are getting everything especially today because our web applications have so many dependencies so you really have to

check for the reputation of those modules chances are that if the modules are being used by many people they are probably they were scrutinized and and you are more or less saved and you should stay away from for four modules from modules that have bad reputation or no reputation whatsoever you can also have compromised third-party lives especially if you are not hosting the lips yourself to prevent that or to reduce that risk you can use sub resource integrity which allows you to add ash attributes to script tags and when loading the scripts it's going to match if the if the ash is right if not it's not loading the script at all you can also use CSP you should use either

nouns or hash based CSP plus strict dynamic and I know there's going to be a talk on this later on that I look forward to but the main problem is at CSP there's nothing against browser extensions which is my next category so malicious browser extensions it's for me it's one of the nastiest threats out there right now so they can tamper with your Dom they can tamper with your JavaScript they can add remove or tamper with with headers which means bypassing CSP and other Heather base types of mechanisms and browser store screening right now is completely broken so it's very easy very trivial to get malicious code in any and a browser extension and basically you

end up relying on the end user not to install those malicious browser extensions and we all know how that usually ends up when in the browser already talked briefly about this type of attack so it carries basically the same risks as browser extensions and then some because they are able to do what rejects they are able to do keylogging remote desktop and viruses are obviously not doing a good job stopping this type of attacks and again we need to rely on end users not to get infected in the first place so now that we more or less covered a few attacks against the integrity what do you think do you see a problem here you see a

pattern anyone know so basically we are relying too much on third parties so we are we we need phoner ability tracking tools to be good and to quickly catch up problems in other modules we need to serve third parties not to serve as malicious java scripts if that's asking too much browser extension stores need to do a better job anti viruses are not efficient maybe we cannot ask for more here and end users which we don't control easily get infected and all the solutions that I've talked about also have their own limitations so vulnerability assessments may not catch everything SSRI attributes can be removed by many in the browser Trojans and CSP headers as I told you can be

removed by either of malicious extensions or many the browser Trojans and this has motivated our work a new approach that we call application real-time monitoring in which basically we assume that stamp rings will occur for sure so some will will be through all of those differences and and it consists in monitoring the webpage continuously for any tampering to the Dom any modification of the event handlers like form on submits handlers and any poisoning to native API functions when we do detect anything we send out real-time alerts to a back-end web hook and and that gets sent to the application back in which if they want the web application owner they can set policies on how to react to those

threats and this our real time threat so they can sometimes react and and some sort they can mitigate the problem by reacting to the problem not stopping the problem but reacting and mitigating later on we follow a whitelisting approach which means that we we can see all the differences but we do have different levels of sensitivity so if if someone tampers a login form will be more sensitive than compared with any tampering on any non important part of the website plus we also check for for like malicious indications in the tampering itself we do have false positives that we tackle with machine learning and we also support signatures when we are looking for something specific another

thing that we implemented is client-side countermeasures so when in some times when we find a problem if it if it's a signature something that we previously identified we can launch countermeasures like Dom healing like if we we can remove the injection from the webpage we can do page redirects can delete cookies effectively kicking the user out of the session if we need - and executing custom callbacks but there's an important caveat we used a JavaScript agent difference on the client side and in order to beast to be effective the Java the agency stuff must not be targeted successfully by tampering incidents so it needs code protection so in our case we use polymorphic Java Script office keishon

developed in-house obviously that changes the code continuously so that it isn't predictable for any attacker and the goal here is to prevent attack automation against that code so if the target keeps changing it will be more difficult to do to be able to successfully tamper with that code so it is also tamper resistant so it tries to detect one when it is actually modified and and reacts to that by breaking the code it has debugger detection capabilities and optionally this agent it's code can be mixed with the application own code making it a little bit harder to like to cut out our agent from the rest of the code in in the page all right this is the our architecture

so on the right you can see that our real-time monitoring agents is loaded jointly with the web page and it monitors the codes continuously the deep web page continuously using several things mutation observers integrity checksums and it detects poisoning to JavaScript native functions when threats are detected this information is sent out to detection and reaction API services it run runs in the server and so we do further processing there and then we passed this information and it's metadata to the actual application where we can have additional policies to react time for our demo and for the demo I will be using a fictional virtual banking environment this is it so this application is running in a

compromised browser profile and something is already going wrong with it and and to show you that let me load the same website in a clean profile right now you can do it side-by-side comparison and like the difference is obvious the the infected profile has a banner a huge banner and the one in the right doesn't have the banner so let's take a look at the banner again so it's inviting the user to download a mobile application which in this case is malicious and has a button let me click on the button usually it shouldn't do this but this is the demo and I can do it so we take us to something that resembles sorry

it took us nowhere actually okay if I look at it goes away alright so this is a Google Play similar to Google Play it's not actually Google Play and it's easy to spot that it's running from Play Doh goggle not Google and actually has a and secure SSL certificate which the attacker could also get rid of if he gets a valid certificate for this domain but there's one additional problem with this page can anyone spot it yep in the EHR sorry

right that could be one there's another different one which is this button here which says download so usually you don't download a mobile application this button is usually installed ok but if the user being attacked is running this in his mobile phone he can be tricked you can download the mobile apk and if you ever configured his mobile phone to to be able to install individual apks out of the App Store he may end up installing this fake mobile application and then not only the desktop might have been compromised but also the mobile device which is good for the attacker right so so this is one problem and now let me show you the actual real-time

application monitoring solution so this is the the dashboard is completely blank right now and I will enable the solution by adding the JavaScript agent to the web page template alright

okay so now I will load the virtual bank application again please pay attention to what happens to the banner so it was removed automatically and in the dashboard you can see that one thread came up let's see what's happening and it says blacklisted fake mobile app enter signature removed so this is something that we already knew about so we have a signature for it and we can launch a counter measure which was removing the banner at the same time the same information was sent to the application back-end so further reactions from from the application can be happening at the same time and this are the details and this is really very cool because we can actually show you

everything that the user was actually running in its website including all the gory details like the links to play goggle and this is really useful for security engineers who further investigate what's happening and how people are trying to to compromise integrity of the the application and how they are trying to commit fraud so let's continue a little bit more and logging in into the website and I haven't even locked in yet I'm already receiving new threats in the monitoring dashboard and now we have a code poisoning so the unsubmitted poisoning in the form instance and let's look at the details so this is the form and we can see that the there's a new function for the

onsubmit of that form that is basically collecting the user credentials and accelerating that to an attacker control server so he this is a zero-day so we haven't we don't have a signature for this but at the same time the application is already aware that this is happening and can prevent the user from logging in or they can let the user login but disable certain parts of the website so he cannot do transactions or whatever makes sense for the application owner let me login anyway and now let me do a new transaction okay so the transaction form is usually a target and we are seeing new threads coming in it's the same type of attack called poisoning and again the

form the on submit was replaced by an attacker controlled function so here the code is collecting the original name and destination account number for the transaction is storing everything in session storage later on the attacker will need it and is replacing the destination bank account with its own and this all happens when we click Submit not before so let's let's do a transaction and let's pay the rent six hundred and seventy dollars definitely not San Francisco rent so okay we submit this and we are seeing new threats to remember the previous threat tampering where the attacker is changing the destination account number so that information is actually what the bank receives and when showing the

transaction validation screen if the attacker didn't do anything the user could see a different destination account number and that could be a trigger for him to suspect that something is going wrong so what the attacker is doing now is the he keeps tampering with information that's being displayed so this is he changed text elements so you change the destination account number for the destination account number that the user is expecting along with the account name so this is a user controlled flow and the temperance just change like the very minimum they need in order to do the Frog so let me confirm the transaction and there you go your transaction is concluded and again the

same information is modified again like the destination account number and in the name and we see new threats coming on okay finally I just wanted to show you a little bit of our code protection just a quick feature so if I open the debugger this is immediately detected so I haven't set any breakpoints happens on its own and we are in this weird state in the application and if I want to do a step by step inspection of the code I'm prevented to do that so but let me try to resume the execution and I'm I become stuck in this loop let me do it again and again and the call stack keeps growing but I'm in the same spot so he

finds this long enough I will eventually exhaust the browser memory and the browser will crash the only thing I can do here is close a debugger and everything resumes normally obviously there's much more to it than this but it's not the purpose of this talk today all right let me go back to the presentation so that the main takeaways of this demo is that it's very easy to tamper with with information in the page with code there's I've showed you a few ways of doing that obviously temporary removal that the countermeasure is very powerful because it's it immediately removes anything that can treat the user or anything that can steal information but but also the temper detection and

notification to the application server is also very powerful because it provides early detection and even with zero days so it's important to be aware that the things are happening and and sometimes the the attacker is only like doing experimental tampering and you can know from that moments that someone is trying to build something against your your forms or whatever also real-time alerts is a trend so within the context of the w3c we are seeing new standards like CSP or HP TP having reports capabilities which is I think it's very cool but the problem is you shouldn't probably the developers aren't like the best guys to determine what what needs to be reported back so I

think it's more useful if you can somehow get the applications to that by you like in a fully automated fashion and and and and keep the developers concentrated in the actual web application features so obviously like I said it's essential for you to protect the integrity of any kind of defense that is running on the client side including this application real-time monitoring so I told you that I cut my web up cheating on me and I'm here to deliver that so obviously we caught many things using this approach but most of its we cannot we cannot disclose unfortunately but I brought to you one that was caught in our own web application so some time ago we were

reuse Braintree for collecting credit card payments in our website and we back then we were using like the first version of their of their API as SDK and when we turned on the web application real-time monitoring we cut this so when when the at the certain point the Braintree is is sending out a JSONP request to their API and you know in order to do that it's printing this script tag in our Dom so we were able so right now you are seeing everything crossed out but we actually see everything and we were able to collect all the credit card information from our own customers that we shouldn't be doing so we only did that accidentally obviously and but

what's worse is that if by any chance anything else was targeting our website and ended up like finding ways to inject code in into our web application Dom or something they would be able to collect and exoteric this information too so it's really dangerous after that we upgrade it to their next version but but the thing is we weren't even looking for this so this is something that just was caught up by using the application real-time monitoring and that's what I meant with I caught my web app cheating all right conclusions so the main takeaways are there are simply too many ways for for to mess with the application code with with its integrity and data as well you should totally use

defense in that like want ability tracking tools s RI CSP whatever makes sense for you another word of caution Heather base defenses are weak which is kind of weird because it's it's being like the main way for standards to to to to have like a foot in the browser and execute before any other code and and we have maybe we are getting like a false sense of security out of that because we think that if they're using header safe but actually both extensions and many the browser Trojans they are able to remove those those extensions in CSP specifically you can also use meta tags in in the body but then again many the browser can also temper with the Dom so

it's useless we talked about getting real-time monitoring it's good to catch things early even things that you were considering looking for it allows you to use custom reaction policies and its overall Risk Reduction for you obviously anything that runs on the client side can be hacked can be it isn't bulletproof it will never be but it's about raising the bar about making much more complicated for attacks to succeed especially if the their targets so our encode keeps changing in an unpredictable way this is all I have thank you and we'll take a few questions

yep well so the question was I've talked about machine learning and how we use it to reduce the number of false positives so basically we need to figure out automatically what's usual what usual changes mutations in the page are expected should be expected because the web page is a live thing so it keeps being modified by your web developers and we need to distinguish that from things that are actual attacks and tampering so there's the potential for having false positives there and we needed to do like an actual learning of what is normal and combine that with other heuristics where we classify the tampering like does it have like something that looks malicious can can someone like axle traits

information using this so first we do that all of that like all the basic filtering and then what what is left behind is what we use the machine learning for and if we see new code being used by many people obviously we will probably whitelist dirt and weeds just see like a code being used by a few people or a lower percentage probably we should take another look at that and so the gist of your question is how do we make sure that the code that our JavaScript agent is not like tampered with or the script tag is not removed actually including the script tag it's just one of the many ways you can include the

code in the web page it was generally easier for me to do that today as a demo that you can mix the agent code with the page from from the actual with the code from the web page so obviously there is no 100% way of assuring that the code is being tampered so if that's the assurances that you look for there's none whatsoever here and I don't think that there ever be what we do in order to reduce that risk is we use polymorphism like JavaScript because we rewrite the JavaScript and obviously everything that we do in transforming the code needs to have a great deal of diversity in such a way that it will be

very hard for an automated attack against that code to really predict what will be the shape of the code of the agent code at that moment in time because he will only have like a split second to like to tamper with the code otherwise he it will be tripping our own like wires for detecting other code like offensive code in the web page so yeah so it's really a complex matter we would need to like to talk about JavaScript obfuscation and beyond and we can talk more about that later if you want okay can we have another round of applause for Pedro and on behalf of these sides and Toby we'd like to thank you thank

you