Events Add an event Speakers Talks Collections
 
Duration 40:01
16+
Play
Video

How I Hacked Your Website and You Didn’t Even Know

Siddhesh Yawalkar
Director Of Engineering at Tala security
  • Video
  • Table of contents
  • Video
RSAC 2021
May 20, 2021, Online, USA
RSAC 2021
Request Q&A
RSAC 2021
From the conference
RSAC 2021
Request Q&A
Video
How I Hacked Your Website and You Didn’t Even Know
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Add to favorites
67
I like 0
I dislike 0
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
  • Description
  • Transcript
  • Discussion

About speaker

Siddhesh Yawalkar
Director Of Engineering at Tala security

Siddhesh Yawalkar is the Director of Engineering at Tala Security, where his key focus areas include application security, threat analysis, and data privacy. Yawalkar has experience in delivering enterprise-level security software to Fortune 100 companies and has previously held roles at Cisco Systems and the Indian Institute of Science. He has a master’s degree from Georgia Institute of Technology, where he worked as a Graduate Research Assistant on HDD firmware security and virtual threat attribution.

View the profile

About the talk

Siddhesh Yawalkar, Director of Engineering, Tala Security With website attacks on the rise and the spotlight on Solarwinds-style supply chain hacks, the session will provide a view from the attacker. How do attackers exploit weaknesses in the modern web architecture and external javascripts, to steal sensitive information from a customer? We will walk you through a Magecart-style attack & leave you with actionable steps to protect against these attacks.

Share

Hello, I'm sabesh. I'm a part of the technical team at the Olympics charity. Through this session. I'd like to help you better understand client-side threats. The relative ease at which web applications are being compromised, and some actionable. Next steps on what you can do in the near-term to safeguard against this new-age threat. In this session, I'll go through an introduction of the problem and then we'll spend around 10 15 minutes going over alive attack demo. And then, lastly, we're going to finish off with some of the

defenses that you can apply to help your organization. No, prior knowledge is required to understand this session. And this presentation is for anybody that use the website or is responsible for web security. By the end of the session will hopefully have an understanding of how vulnerable web applications are on the client side and increasing need to implement client-side security. Let's get started. I'm sure everyone has heard of the recent solarwinds breach in the large impact that it had on several Enterprises. The part that I

would like to focus on his house software Supply chains are being exploited and how these attacks are gaining relevant everywhere today. What is break down the solar winds attack and look into some of the reasons why it was so devastating. First of all, solar winds was a trusted fast, vendor Enterprises trusted the company and the software that they deliver. It was widely adopted and a single compromise led to over 18,000 breeches. And from an attacker's point of view, these

types of attacks are especially attractive because they give the attackers remote control access to their and servers Italy. So this is how the solar winds hacked went down, and I'm sure you're thinking, how does some it management software affect web application and web security. Let me explain by quickly going over how web architecture is the bald over the past 10 years. What architecture for the past decade following a trend where the applications were server heavy and Enterprise data centers handle the bulk of the processing? The web browser during this time

was more of a graphical interface only. And as we look in the past few years, the today, for many reasons, including optimizations that enterprises want in terms of speed, as well as increased Computing capacity on the Klein devices. That is your PC and your mobile devices. Today's website integrate dozens of third-party vendors. All the way from your user and Anna takes marketing tanks edn, open source libraries in Solon. This is like the third-party vendors and libraries

loading their content directly onto your browsers. And this means that on average around 70% of what loads on end-users browser. Doesn't come from first party servers at all. And the prices are designing client, heavy applications, as a result that I run through JavaScript on the browser. And these browsers are acting as the modern-day OS. So, this is how a typical web application and website loads their content today. And as you can see, the diagram shows the different third parties and their multiple locations and data

centers across the globe. Hopefully, the sort of explains why the internet is called the web. So in this, your JavaScript loads third-party JavaScript, which in turn May load fourth and fifth party JavaScript. This is called the piggybacking of JavaScript, and this creates a trust between you, your third-party, your fourth party and so on. And as a result of this trust model, it only takes one of these libraries or dependencies or even one server to be infected in

order to compromise your website. A list of the main principle, that is leading to website breaches on the client side. As you will notice your data center or any of your service. They were not impacted. They were not breach or attacked in any way. But still, your friend users. They got infected with this malicious JavaScript. Google researchers. At work on Chrome. They say that. If an attacker is able to inject any JavaScript in end-users browsers. It is practically

game over. So now, if we combine the principles of the solar wind style supply chain attacks, and a web sites are using a large number of third-party dependencies. The modern web has become The Perfect Storm. Here's the breakdown. We already have JavaScript as the one common language and framework the power, the entire web today. One JavaScript can load another JavaScript in suwon through the implicit trust model that we that we just saw at present in the

web today. Finally many popular JavaScript libraries and apply to over thousands of websites. In fact, a recent study that I conducted analyzing over 1,000 website, the Alexa 1K highlighted the startling number of third-party services and average website uses, and that number is 34. What was more concerning through this study or the lack of security control? The top thousand websites in the world have against such types of vulnerabilities and third-party purchase. It seems a little scary, right? So in the next section, I'm going to be showing you

a light actonel. But before we switch gears, there's one situation that I'd like you to think about. Imagine if one of your third parties told you that they have been breached. What is protecting your web application from being compromised today? So now we're going to switch mode to an attackers point of view. I'm going to act as an attacker now and I'm going to share my thoughts while we're going through an attack together. So, as an attacker, I'm going to try and exploit the weakest part of armor that

the web application has. I know that your whack only protect your servers. The content that is served from outside your wife, that's less protective. There's a growing saying in the industrial the past few years that goes like if you're only having a laugh. An attacker is having a laugh. So with that in mind, I'm going to try and Target the servers that outside your data center. All the servers that are on the right hand side of this diagram. These are much easier targets. Let me show you how a typical website attack takes place in this case.

First of all, the style of attacks recalled made card and match card is also the name of the most infamous group that carries out these hacks. And without going off on a tangent, too much. Let me present analogy from the physical world. I'm sure you've heard of a credit card skimming attacks, that sometimes take place at gas stations. They go something like this, where you swipe your credit card at the pump. And some attackers or some. Somebody has put in a small little Hardware that steals your credit card number

and store this number. Your transaction of the pump, it goes through. Okay, and you cannot detect. Anything is wrong at that time. However, after a few weeks when you check your credit card statement, there are some mysterious charges that have applied that have been applied. But you were not made. So similar to this physical credit card, skimming attacks, we have web-based JavaScript scanning attacks. And that innocence is the main Scott attack is and what the major

group does. Just take a look at the typical steps in a mage cart attack. Step one to try and find out what goes into your weather application. That means listing out all your third and fourth party dependency. Once the attacker has identified a suitable Target. They'll use all appropriate means to breach into the third-party servers. This can be achieved using any of the standard attacking and hacking tools all the way from credential theft SQL, injection. RDP attacks, rainbow tables,

whatever you can think of. And that has been known or unknown, the attacker was try and use that to gain control of the third-party Surfer. Now, once the attack in is controllable, the third-party server. They were going to try and insert their own little JavaScript in there. This code is designed to avoid detection and it will maintain a low profile. Tires are doing this in a few slides. Now when the end user navigate to this website, their browser load the third-party dependency and you

have been infected by the attackers JavaScript. By inserting one JavaScript onto your browser can do a lot of nasty things. They can be faced. Your website. Injector own ads, do Bitcoin mining, but over the past few years at actors of realize that the best way for them to monetize on this is to try and steal and user data. That generally means your credit card numbers your username and password. That's what attackers were Johnny Gill behind. And this

actually what happened, a few years ago on a ticketing website in the UK. Attackers, must have thought. Hey, look. A lot of people are going to book their tickets on this website, through their credit card, and the Tramp steal it. Or they could have booked their tickets to their favorite concert something like a Justin Bieber concert and got pissed and decided to hack this website. It's something like that. But at the end of the day, they decided to try and Target. One of the ticketing website, third parties

that is in Benta. And injected their own JavaScript after hacking into inventor servers. No, it and users went on to the ticketing website to book their concert tickets and so on. That credit card information was being stolen. And as a result of this type of attack that the major group did, they were able to steal over 60,000 credit card numbers on this ticketing website alone. For my attack demo. I'm going to perform a similar set of steps in order to show the attack.

Chromatic demo, I want to use a well-known public website to show you how we can attack it and have something to eat. Hack funds but thanks for the legal team. I have to settle for a demo website that I created and own. I'm not hacked or done anything illegal against any other website, or server. And this demo is just an example. So, for this demo, this is the Target website that I'm going to use. And for the first step, I would want an alliance the Target website

to understand its supply chain and look for any possible weaknesses. But its purpose, I'm going to use that attack proxy also known as that. And this is a great open source tools for attacking a web application. What this tool does has it crawls of an application and understands all the resources that are loaded. It's an option. They also run attacks or pentas against some of these resources. So please get permission before running zap against a website.

This is the start page of Zap and I'm going to run a scan against my Target website. I said the options in that already so that it will try and explore all links possible and look for all the resources that that are present on this website. So let's hear of attack to start the process. This website is quite small. It'll only take a few seconds for zap to trace all the dependency. Do the third parties that are present on this site. As you can see, there are quite a few first-party resources that are loaded and also some third parties that you can see are

getting loaded here. Let me show you a graph for better understanding. As you can see the Target website, it loads quite a few third parties and I did my research on them all. I found out that you and Alex. The one which is on the normal side of the diagram that is factual open source in Alex Library. This is great news for me. Why? Because for the past few months. I have been contributing to the open source Community quite a lot. I've gained their trust in this timeframe

and just last week, I put in a bug fixed and I also slid in another dependency. To fetch one, small JavaScript from my servers. so now when you load the Target website, Your browser is going to fetch, an infected view in Arabic script. Which brings us? The next step of the attack. The attack payload are Justice five lines, and these five lines is all that it takes to perform a data. Exfiltration attack that I would be demoing. In this case, the attacks to use the username and password. Let me walk you through this at a very high level. And no programming knowledge is

required to understand this. The first two lines, say, let's read the username and password values. When they're typed in by the end-user. That's how easy it is for one, JavaScript, or any, JavaScript to read anything, from a web page. On the next three lines. Say, hey, let's send this data out too bad server.com. That's all there is to data exfiltration in JavaScript. Okay, let's go to Target website to see the actual attack. This is regular Chrome and on the right hand side. I have opened up developer tools on the side so that I can explain the attack better.

I would be able to explain what's happening under the hood side by side to the website in this manner. Let's go to website. So as soon as the website clothes under the hood, I can see that the attackers already loaded in their attack script through view Analytics. On the left hand side. Nothing seems to be a mess. The website loads properly, and everything seems good. Let me try and login. There we go. The login went and successfully and I didn't realize anything's amiss Cedric Gordon, can go about doing his usual business

after logging in. But what's happening on the back? Is that a copy of the username and password it sent back to the attacker servers in this case. It's my attack service.com., As you can see here, the username and the password that was sent back to these servers. in this case, The attacker is only printing the logs, just for this demo. And that's how easy it is for credit card, numbers and username and password to be, so to be stolen. And then later sold the darknet. This is steady income for any attacker in one Us. Credit card

can go for around $7 on the dark Market. So, for such attacks, some of you may think that these attacks are easy to stop or detect. Well, not really, but I just have a few tricks up their sleeves to ensure. These attacks are not easy to detect and don't go to Texas for a very long time. The average Mage Cod infection is 46 days. Yes, some of the reasons why these attackers are so successful. And why do the facts are so hard to detect. The attackers were first of all, use the standard techniques opposite, the code and ensure that no static analysis, tool is able to

detect that malicious behavior. Here for the attack. Here's where the attackers get a bit more creative. The malicious JavaScript that they put in. It will not perform. Anything malicious, if it realizes that your death tools are open. They quite smart about this and they do not want to get detected by some security engineer, keeping their devtools open and trying to understand this Behavior. And I'm sure some security engineer would be smiling and saying, I'm going to try and use Wireshark

to trace all the network connection that go from the browser. What time do you work? Because these attacks groups, they only load from 1 to 4 a.m. And that too uncertain randomize days on certain geographies. And even during that time, the malicious behavior only occurs for around, 20% of the time. By that, I mean to say 80% of traffic at 1 a.m. To 4 a.m. Is still completely clean. And you don't even realize there's an attack taking place to the other 20%. Last week, I wanted to add to the network request to fix the attacks, which is exactly identical

to the other hundred hundred fifty Network request that the browser make in those two seconds. How are you going to distinguish the good and the bad? It's like finding a needle in a haystack, in my opinion. And that explains why these attacks mostly go undetected. In fact, a few years ago, when semantic analyzer over thousand form jacking attempts, in just a three-day. They found that over 57 website, got hit with major car. The websites that got infected range from a Fashion retail in Australia to

Fitness reseller in Italy. And Regulators have started taking notice and imposing very large fines on the main website directly. Not just on the third parties, are the main website. These attacks are causing significant financial damage, not just in terms of these fines, but also class action lawsuit, as well as a loss of customer loyalty and Trust in the brand. So now that you've seen, how these attacks have transpired and how they're gaining momentum. Let's talk about what you can do to protect yourself. And at this time, I'm just going to try and say that

you have to use the basic security principles of Defense in layers. In other words using r c conferences, theme for this year, Bill resilience into your security. Create layers of Defense around your web application to increase security and redundancy. so, You cannot protect against threats that you did not know about on the first step. For the first layer of defense is to understand all the third parties that in that integrate with your application.

Next. Let's try and minimize the number of third parties that are loaded on your web application. List three adds an active protection to our web application so that it's protected, even if it's third-party has been breached or attacked. And lastly, you should be the constant lookout for any signs of potential breaches from your third parties. Let's double click on each of these layers to understand these defenses a bit better. So, as I see, you cannot protect against threats that you do not

know about. The first step is to identify all third parties that your application loads. And more importantly, all the third and fourth parties downloaded by your third parties. That is the fourth and fifth party JavaScript that I've been piggyback on through your third party. It also helps to prioritize certain pages that are sensitive user inputs such as login, pages, and payment pages and try and classify third parties, based on how severe of a breach would be to your with application, if the third-party got compromised. When it comes to

security, like many things, I say, learn from the best, and Google is definitely one of the good champions in web security. What you're seeing here is a typical login form that you've seen a hundred times. I'm sure why log into Google on the right hand side. I have a developer tools open which has been set to filter out only third-party resources. As you can see that list is empty. That is Google doesn't have a single third-party JavaScript on this critical sensitive page. That's definitely an easy route that you can take to

protect your weather. Application minimize or reviews, the number of JavaScript downloaded from external sources. So this is not feasible everywhere. And sometimes there is an essential JavaScript, which you require, which is a third-party JavaScript. You can consider yourself hosting it and that will make the third-party JavaScript a first-party JavaScript since you are serving it directly. The active protection there in my opinion is the most important layer of Defense addresses. The worst-case situation actual

third-party is breached. These are two production methods. Allow your web application to successfully defend itself against these malicious third-party libraries in real time. These protections are for weather applications through w3c and HTML5 standards. They're deployed through HTTP headers or in the Paint Body. So here's all the typical workflow takes place. When a browser request the weather application. It comes with these protections that the browser then enforces.

These standards are enforced by the browser. So when your weather application makes a request to fetch any, third-party resource, the browser ensure that these resources that are loaded are secure and trustworthy. You're basically telling the browser to be responsible for your web application security. Now. The best part is 94% of all internet. Traffic today uses a browser that supports the standards. And these standards are free to use. Thanks a w3c

working groups. Let's take a look at the three most important security standards on the client site and how big would have protected your website from the attack that I just demoed. The first one is content, security policy. Through this header, you can control what comes in and what goes out. For example, you can list all the third-party domains that allowed to bring resources into about application and all the domains that data can be sent out to Content, security policy would have prevented the attack that I demoed

by not allowing the script from my server to load in the first place. My militia server to load in the first place. And further it would have also blocked. The outflow of data. That is the data exfiltration because the attack was sending the data to a new server. The second one is sub resource integrity and this standard verifies the hash of a third-party script in run time and it blocks the script from running if the hash doesn't match. If I thought I

was protecting the view and attic script from the earlier, demo in the browser would not have liked my malicious modification of the script. The hospital changed on the browser would not have permitted the script to execute at all. And a third powerful standard is the ice cream. Stand boxing. This is the future of modern browsers that allows third-party script, three fully isolated from the main website. What is this was deployed during the attack demo. The attack script could not have read the username and password values. This is

because the browser would have made the attack script run in a completely isolated contact as compared to the main website, which have the login form. WCCO news channel, 5 standards in control, over a hundred different browser, behaviors that range from security to privacy and compliance. How's the standard and enforcing Security on the browser? That is the client side? That's why they called client-side security standards. I would definitely recommend that you spend some time getting to know this.

It's a bit better and also the set up some standards for your website. I generally don't like to explain a joke or a meme. So I hope you get the irony when there is a third-party service JavaScript that claims that it can protect against other third-party JavaScript. The main security downside of using one defense JavaScript against attack JavaScript. The same privilege is that this is not good for secure. You want your defense JavaScript to get a higher privilege when the attack, And when that

does not happen like for JavaScript base Solutions, wear the same privilege, the attack, JavaScript can simply get rid of your defense JavaScript. You always wanted your defense to be at a higher privilege. And the w3c standards from the previous light. Didn't publicly scrutinize not recommended by the security industry as a whole rather. They were even created by the security industry, actually. Jobs for Bay Solutions. They're also not free to use like the browser standard which

we mentioned earlier. So now that you got it insufficient defense to your application. What's next? You going to stay ahead of your anniversary and build a layer that can keep track of all the third parties and preemptively, take action. When you feel there's something going wrong with one of your third parties. Now that we have understood the defenses in theory. Let's take a look at a sample web application that is implemented these defenses. In this case. I'm going to act as the web website owner and walk you through that. First of all, I know, all the resources and

third parties that are in this website and web page that examine the mall and reduce the number of third parties that are loaded. The one essential strip that was really required for my application. I have protected it through a sub Resort Integrity hash so that no one can tamper with it. Plus, I'm also using a strong content-security-policy to ensure that no extra scripts are loaded. And no other data can leave my web application. Last week and Purity checking all my third-party, scripts and vendors to

ensure that they have not been tampered or breached in any way. I'm not coming to a close of the session. I hope that you have a better understanding of climate science threats and the ways in which you can Safeguard against this new age of sex. The next steps are recommended in the coming weeks. You try and perform a resource in ventre of your website. The next few months get a c s p. Use an SRA and be ready for the worst case in case of third-party is breached. And lastly pass on this message

to other Security Professionals in your network. And in your company said, they too can protect their websites and web assets. And if you're interested in knowing more, security has been working in this field of eliminating client-side attacks for the past five years, and we published a few white papers on this topic. You can access them through the Q R code. There's also a link to our website which has a lot of free resources to help you. Get started and secure your website. You can also feel free

to reach out to me on my email address or connect with me on LinkedIn. Thank you and have a Q & A session that is coming up next.

Cackle comments for the website

Buy this talk

Access to the talk “How I Hacked Your Website and You Didn’t Even Know”
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free

Ticket

Get access to all videos “RSAC 2021”
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Ticket

Similar talks

Christiaan Brand
Product Manager: Identity and Security at Google
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Heather Mahalik
Director of Forensics Engineering at ManTech
+ 3 speakers
Katie Nickels
ATT&CK Threat Intelligence Lead at MITRE
+ 3 speakers
Alan Paller
President at SANS Technology Institute
+ 3 speakers
Ed Skoudis
Instructor at SANS Institute
+ 3 speakers
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Zack Allen
Senior Director at ZeroFox
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free

Buy this video

Video

Access to the talk “How I Hacked Your Website and You Didn’t Even Know”
Available
In cart
Free
Free
Free
Free
Free
Free
Free
Free

Conference Cast

With ConferenceCast.tv, you get access to our library of the world's best conference talks.

Conference Cast
816 conferences
32658 speakers
12329 hours of content