Protecting Against Hacks Myths & Security Measures

Speaker 1: Good morning, good afternoon and good evening to everyone. We’re going to start this in a couple of minutes, since it is still quite, almost just a little bit past the top of the hour here. So we’ll take a few minutes. If anybody wants to engage in the chat and let me know where you’re from, that would be great. Bar and I are always interested in knowing where our participants are from.

00:00:29
Speaker 2: 100% if you want even, send us your country flag emoji.

00:00:34
Speaker 1: Yeah. Thanks, Bar. So let’s just give it a couple more minutes. I haven’t seen anybody in the chat yet though. Have you Bar?

00:00:52
Speaker 2: No one in the chat. I think people are shy, but they will warm up. Right, guys? Um, I see we have more than a few people already joined. I think let’s give everyone a few more moments to join up before we begin. And again everyone feel free to write us in the chat. Say hi, where are you from, send us a little flag emoji. Whatever. Oh.

00:01:23
Speaker 1: Arizona, there you go.

00:01:25
Speaker 1: Right next door. Kevin, I’m in California and San Diego, actually.

00:01:33
Speaker 1: Maryland. Great.

00:01:45
Speaker 2: And it seems everyone is from the US. Ah, Brazil, Nov8.

00:01:57
Speaker 1: Thank you for  attending from Brazil. 

00:02:06
Speaker 2: That’s cool. I think we’ll give it one more minute and then we’ll start.

00:02:10
Speaker 1: That’s a great idea, Bar. Thank you for that. Well, let’s go ahead and get started, shall we? So today. So today a couple of things we’re going to talk about protecting against hacks and some security measures you can take. And so Bar is an expert and he’s going to talk about that in detail. But because Bar is located in Tel Aviv and there’s a conflict zone there, we’re going to make this presentation go a little bit faster today than the one hour we had scheduled. So I’m going to give you back some time today. So I’m going to go ahead and let Bar introduce himself. But I’m a Senior Product marketing manager here at Bright Security and Bar, go ahead and please introduce yourself.

00:02:59
Speaker 2: So nice to see everyone here. My name is bar CTO and co-founder of Bright Security. Um, my background is basically offensive security, application security. I did everything in regards to cyber, AppSec, even was a CISO for a time. But again, my true passion is, you know, offensive. And that’s what we’re going to talk about today. Right. Um, yeah. So thanks everyone for joining.

00:03:31
Speaker 1: Right. So Bar’s underselling himself. He is an expert at offensive security. And so he’s going to, we’re very thrilled to have his time today. I’m a senior product marketing manager here at Bright Security. And prior to that I’ve worked at a number of different companies in cyber security. I got my start 15 years ago at a security information event management company, and since then I’ve worked in cyber security for Cisco, Infoblox and Qualys. That’s enough about me. Let’s go ahead and get started with the actual content here. Bar, what the hell is, pardon my language, what the heck is this? Bug bounties continue to grow. Where did this list come from and why is it so important?

00:04:10
Speaker 2: So that’s a good question. We brought this list from the hacker one top, yeah, top bug bounties payments. And I think it’s very very interesting. So basically if we look at this table which I would also love. Oh here it is. The chat was on it. What we can actually see are very interesting things. So we can see the year over year growth in how much payment or how much bounty bug hunters were given per year for those kinds of vulnerabilities. Now, you know, we’re talking about the XSS vulnerability that was here for, I would say, at least 20 years, maybe 50 years, something like that. And even now, right, so much time after where you would start to…

00:05:08
Speaker 1: Were going to dive right into XSS right after this slide bar. So thank you for that.

00:05:09
Speaker 2: Okay, go for it, I don’t want to…

00:05:15
Speaker 1: Continue.

00:05:16
Speaker 1: But continue talking about these bug bounties I mean so where does this, this comes from the hacker one, And who actually does, how does it all work? How do people get compensated for this?

00:05:26
Speaker 2: Right, so there are a bunch of people, basically what we call white hat hackers, which collect bounties for security issues that they find. So they have those portals or they just reach out to the company directly. They get information about the scope, basically what parts are attackable, what are you allowed to do? And then they will try to find vulnerabilities and report them to you. And you as the company getting this service will pay out based on findings. So here we can actually see how much money companies paid for each type of vulnerability. We can see XSS at $4 million, which is a lot right, for one single vulnerability type. We can see improper access control at $4 million as well. 

00:06:19
Speaker 1: And we will talk about that, yep. 

00:06:20
Speaker 2: Yeah. And I think the most interesting part here is the growth. So it’s still growing. It means there are actually more and more vulnerabilities, not less. There are more and more vulnerabilities. And people are getting paid more and more to find them.

00:06:37
Speaker 1: Wow. So we’re going to talk about five of these vulnerabilities, specifically. XSS as you were wanting to get into, we’re about to get into. SQLi right, SQL injection, access control vulnerabilities, which as you can see, is right up there at number two. Code injection, which is different than SQL injection but very very similar. And then finally server side request forgery. So with that let’s talk about the top five categories here. Let’s start with cross-site scripting. That’s a type of web application vulnerability that allows attackers to inject malicious code into web pages that are going to be viewed by others. And obviously this allows attackers to steal sensitive data. So Bar, you were just dying to talk about XSS.

00:07:26
Speaker 2: I think that XSS is very special. Um, the reason it’s special is because it is very hard to protect from and it just keeps persisting. Whatever new web technologies we have, you know, we get react and we get angular and we get whatever new frontend framework is coming out there. In the end, even though everyone promises they’re going to have user input sanitation and Dom based filtering, in the end, XSS just persists. Um, so yeah, it’s one of the most I say it’s the number one, right?

00:08:10
Speaker 1: It is the number 1, yeah. 

00:08:12
Speaker 2: Number one, most paid, uh, bug bounty vulnerability. And there is a good reason. It’s very, very, very common. Um, and the impact might be very severe. Um. You want me to get into it or you want to go through the…

00:08:30
Speaker 1: No, continue on. 

00:08:31
Speaker 2: No worries. So basically, what is XSS? XSS is a type of vulnerability where you’re injecting JavaScript into the response from the server. It’s what we call the reflection attack. There are a few types of XSS. There’s DOM XSS, persistent XSS, but in the end they both kind of work around the same logic of changing the client side code. Um, to the user. This can do everything from just, you know, simple defacement. You know, say instead of seeing Microsoft’s website, you will see “Microsoft sucks, use Linux”, right? Um, or it can actually be something much more malicious, like password stealer, keylogger. It can even at times, depending on browser versions and vulnerabilities, actually be used for full browser sandbox breakout and executing code on the user’s machine. So this can be escalated to something very, very, very severe.

00:09:45
Speaker 1: Wowl. So talk a little bit about prevention here. What are the things that people can do to prevent XSS vulnerabilities.

00:09:53
Speaker 2: So the first one is obviously input validation right. Yeah you know that’s the basics right. Don’t let user give you information you’re not supposed to get. So for example I have my application. It has um I don’t know phone number. Don’t allow Ascii, don’t allow them to input you know ABC, don’t allow them to put special characters. Just block it directly. Don’t don’t even handle that. Just say, you know what? In this field you’re only allowed numbers. And in the backend of course also validate that and only allow um, numbers. Now there are some other cases where, for example user comments, user comments should allow right textual information, maybe even links. Um, and in those cases it’s very important to have two things. One, sanitation. So go through the input and make sure that even though you’re allowing certain stuff, don’t allow everything. And when you re-render this data, you’re giving it back to the user to view it. Um, always escape it. Don’t allow it to execute in the browser, so don’t make it part of the HTML response that you’re giving to the user. That’s the first and most basic. So that’s input validation and output encoding and escaping. There is also content security policy which basically tells our browser, um, what sources should it allow and from where, in high level. One example is using script tags, um, in an XSS injection. And then you’re saying, you know what, I don’t allow scripts to be executed from anywhere which isn’t this website, and then you’re basically saving yourself from a lot of those kinds of attacks. It also has other CSP headers that are very, very, very thorough. So there’s a lot of configuration. There are a lot of things that you can do to improve your defense status. Um, so yeah, that’s what it’s used for.

00:12:12
Speaker 1: Bar can talk about XSS all day long. Are you familiar with this XSS example at eBay, Bar?

00:12:18
Speaker 2: Uh, yeah. You know, it was one, I guess, of the most known situations, but tell us about it.

00:12:25
Speaker 1: Well, this breach exposed the PII of 145 million users. And as I recall, eBay had to send out an email asking everyone to change their passwords.

00:12:41
Speaker 1: Uh. So this was, the attacker embedded malicious JavaScript within an eBay product listing page. And then I think we talked about redirection. They sent everyone to a fake login page. Is this something that’s common with XSS attacks Bar?

00:12:52
Speaker 2: Yeah, so once you have the ability to inject JavaScript, you’re basically coding whatever you want in the customer, in the target website. So you can do re-direct, you can change the page, you can even put a fake login that will just grab the username and password.

00:13:09
Speaker 1: That’s exactly what happened in this attack, thanks Bar. Let’s move on to SQL injection or SQLi. This is again one of these oldest and most prevalent vulnerabilities out there. And this is where, you know, attackers will inject code into SQL queries in input fields. And one of the examples of course is where or 1=1 to get back an entire list from a query. So Bar, talk a little bit about SQLi, SQL injection attacks.

00:13:41
Speaker 2: Sure. So SQL injection I’m pretty sure is even older than cross-site scripting. You can’t say PHP without thinking about SQL injection. Um, the main idea here is that in the end, most web applications and applications in general talk with some kind of database, right? You have your users information, you store your password, you store state, you store the information that the user upload or just enter into the application. And when you do that. So for example you have a search field that allows you to search different products. Um, if you take this field and you put there, usually, let’s say SOAP. So you go to your, you take this user input, you go to the database, you insert it into some kind of query, like select all products that have SOAP in their name. And then you show back the render back to the user, all of the products that have SOAP. Now, if the user is able to change the query instead of writing SOAP, he will just end the query and do that drop table products. Then the application goes kaput.

00:15:00
Speaker 2: Yeah. And then, you know, boom, no more database. 

00:15:03
Speaker 2: Um, so there are also other cases, and I think one of…there are two interesting cases when we were talking about SQL injection. One is obviously most people won’t draw the database because they don’t care about just harming. They will read the whole database, they will get the information and then get exposed to information that you don’t want them exposed. Right? They can see all the usernames, all the secrets that you have there. And in some cases, there’s also the possibility to execute operating system commands via SQL injection on the server that is running the SQL database.

00:15:47
Speaker 1: Wow. In the interest of time, let’s move to access…this is number two on the bug bounty list Bar, access control, where attacks seek to exploit weaknesses in access controls and do things like privilege escalation, authorization bypass, role impersonation. And then, of course, the tried and true credential cracking or credential stuffing, right. So some different types of access control weaknesses. So Bar, talk a little bit more about these.

00:16:17
Speaker 2: Alright so access control in general we’re talking about something that we all know. I have an application I want to make sure no one can enter without putting a username and password to see certain information that they have access to. Access control based attacks means bypassing this mechanism. Either by, let’s say I’m a standard user that doesn’t have a lot of access to stuff, and I find a way to escalate my privileges to become an admin on the system, or there is a way to actually see information without getting authorization, because I know that the direct link or I have a longer URL that I can use, and the application doesn’t validate that in this specific URL the user is authenticated. Um, obviously brute force login credentials, stuffing, you know, cracking the login, um, or just stealing it from somewhere. And role impersonation is very similar to privilege escalation, but I’ll say it’s a bit more on the modern side of things. So for example, if you have JWT tokens and inside the JWT token, you have a role section, you can add admin and then get admin access and similar stuff.

00:17:38
Speaker 1: Interesting. So talk a little bit about prevention here. What can people do to prevent this type of attack?

00:17:46
Speaker 1: I think the most important thing about those kinds of vulnerabilities is never hook your own authentication logic. Never do that. A lot of people think, you know, a lot of developers think that, you know what, I don’t want to use this library. It’s so robust. It’s so large. I’ll just use, you know, something simple. I’ll just handle it myself. That’s where everything starts. There is a reason those libraries and those mechanisms for authentication are so complex, because they need to take care of a lot of those kinds of edge cases. So obviously don’t roll your own. Now that’s number one. And obviously misconfiguration. Make sure that authentication is not just there on the application layer. It’s also there on the infrastructure layer. So the server that actually holds your application won’t allow the user to do all kinds of funny stuff, like the directory listing and seeing all of the files without having authentication, um, two factor authentication, multi factor authentication, SSO, all of those things, always think about them. Um, that’s very, very important. And of course, um, stuff that have, you know, known vulnerabilities if you do, uh, create use something else. Make sure it’s up to date.

00:19:15
Speaker 1: Bar, are you familiar with this Marriott Access Control attack that happened back in September of 2018, that had been going on for four years, that made it one of the most prolonged breaches in history?

00:19:26
Speaker 2: Ooh, sounds interesting. 

00:19:29
Speaker 1: The PII of 500 million guests was exfiltrated, and once inside, attackers were able to move, you know, laterally. They maintain persistence for four years and they exfiltrated data for this entire time. Just another example of poor access control. Uh, winding it down. We just have a couple more of these to go Bar, because I know we’re trying to get this done a little quicker today because of the situation. Code injection. Code injection attacks exploit vulnerabilities. This is just like SQL injection Bar, right?

00:20:01
Speaker 2: It’s like SQL injection because it’s an injection type. So it’s the OWASP A1. Um, but there is a very different logic here. Instead of attacking the SQL, you are attacking the actual operating system. Um, it was very common in, um, older systems like PHP based systems and also in router frameworks and router pages, or a firewall where you actually have a way to execute commands from the web on the machine that actually holds that. But there are also a lot of situations where you have all kinds of hacks that developers do, where they take data from the user and do something in the shell. Let’s say they’re running a grip OS command with some information the user did, or they’re running a curl command behind the scenes to execute some requests to somewhere else. Um, this opens the door, um, for the user to change the input. And if there isn’t input validation, they can execute, um, operating system commands on your server. This is the holy grail of, uh, of breaches, right? They have direct control of the server. They can just execute whatever command they want. They can restart the server, they can install software in it. They can grab, I don’t know, some remote desktop client and just take full control over the server. So this is very risky.

00:21:44
Speaker 1: We’ll take a quick example here of Equifax. Here’s, this is probably one of, Bar would you say this is one of the top top ten hacks of all time is the Equifax incident affecting almost 150 million people. What happened? They found a vulnerability in Apache Struts. And then they performed some sort of remote command execution. Talk about that if you can. 

00:22:08
Speaker 2: So, Apache Strut has had this CVE which was known, it was communicated and patched. Um, but they took their sweet time, um, about fixing it and I think three months, if maybe more I need to check. But I think at least three months after this critical high severity vulnerability was out, they still didn’t fix it, which allowed the attackers to just execute OS commands on the target, gain a foothold into the internal systems and just go into the whole organization from there. And it was one of the biggest, um, settlements. They got sued and their…

00:22:59
Speaker 1: Yeah, hundreds of millions of dollars Bar. Yes, definitely.

00:23:02
Speaker 2: Also, their value dropped by something like 30% overnight.

00:23:10
Speaker 1: Oh wow, I didn’t know that. Thank you for pointing that out. These incidents have many different effects on organizations. Uh, let’s finish it up here with server side request forgery. This is definitely on the list. It’s a vector that allows attackers to abuse functionality on the server, right, to read or update internal resources. So talk a little bit about this one Bar.

00:23:35
Speaker 2: Um, SSRF is very interesting. Um, it looks like in some cases it’s very similar to OS injection, but in this case it’s not really OS injection. It’s more about abusing the application’s logic against itself. So for example, um, you have an application that allows you to put a URL of a news site and it will go to the news site and fetch a highlight of ten Interesting, um, I don’t know, news items from that site. I just invented a new app. Now you take this functionality and instead of putting the URL of the news site, you’re actually, um, putting a URL that has an internal address. So, for example, you all know 127.. 1 or 10 .0.0. something and you just use, um, the target’s, the server’s ability to execute web queries or just HTTP queries to, um, start sniffing around on the internal network and sometimes even rich APIs and endpoints that you’re, that you are not supposed to get. This becomes even more critical when the system sits on an, um, a cloud provider, because in that case, you can reach certain APIs that the cloud provider only exposes to the machine from the internal network that can give you information about the account itself, like the cloud account itself. Stuff like AMI internal IP address, configurations, all sorts of stuff that you should 100% not have access to. Um, also in some cases it allows you to um, also reach targets with different protocols than Http. So like FTP, SMB, everything that can actually be used go for everything that can be used, um, from an Http like URL.

00:25:48
Speaker 1: Wow, so here’s an example. And again here’s another, you know top ten hacks of all time, this Capital One attack. And this was done with server side request forgery. It’s probably one of the most notable ones. It was from a misconfigured web application firewall. Bar, are you familiar with this attack?

00:26:06
Speaker 2: Yeah. So this one is very interesting. And I guess it exactly points out the risk of SSRF, especially when you’re getting hosted on a cloud provider. Um, what they actually did here was to get metadata from the AWS instance that Capital One was using, right? By just reaching those internal API endpoints, and then they were able to find all kinds of internal assets like S3 buckets, etc., which has PII of all of the customers that this system was hosting. Uh, very interesting hack and a very, very dire consequence.

00:26:54
Speaker 1: Thank you for that. So we’ve gone through the top five, the top bug bounty categories Bar. Thank you for that. We did an abbreviated version of this presentation. We were scheduled to go for an hour, but because Bar is in a conflict zone, we wanted to be respectful of his time and shorten it down to 30 minutes. So with that bar, I think we’re going to finish up and open it up to audience Q&A and any other commentary you might want to add in closing. If anyone has any questions, feel free to type them into the chat at this time. Bar, do you have any other comments on this presentation today?

00:27:38
Speaker 2: Um, I think one of the interesting things to point out while people are figuring out their questions, um, is that as we see in the first slide, those issues  just keep getting more and more frequent and are getting more and more common. And the more, uh, bug bounties being paid for for them means that they’re open, they’re exposed to the internet. People that maybe don’t have a lot of skill can find them, and that means that the risks are getting higher and higher. And this is exactly, I guess, where things like automated security solutions and CI/CD flows with security embedded in should be thought of because you just need to move quicker. And if you need to move quicker, you need to bring security closer to the developer flow, etcetera. So thank you. Yeah.

00:28:46
Speaker 1: Uh. Here’s a question. Where can one get practical concerning the discussed vulnerability? I’m not sure what that question means.

00:28:57
Speaker 2: I guess you mean where you can get more information, more technical information about it? About those kinds of…

00:29:05
Speaker 2: Yeah, I think that might be the question Bar, so feel free to suggest some sites.

 

00:29:11
Speaker 2: Um, yeah. Okay. So first of all, those vulnerabilities are well known, which means that even if you go to Google and put “What is XSS? How can I protect myself from XSS?” You will find a good answer. I would also suggest um OWASP, the OWASP organization which is the Open Web Application Security Project. It is vendor agnostic and will allow you to go through all of those with a lot of additional information. Also, we have our own vulnerability guide, which, um, if you maybe, maybe I’ll try and find or maybe  Amanda, if you’re still here and you can put into the chat, um, our internal docs about the vulnerability guides, all of those kind of attacks are there with explanation of how they look like and how best can you protect yourself from them.

00:30:15
Speaker 1: Thanks, Bar. Here’s a question that Bar is right in your wheelhouse. Do you think the new generation of AI influences hackers?

00:30:27
Speaker 2: Yes. It’s a good question and a very easy answer. Yes. Um, there are already, um, both extensions, add ons, two links that use ChatGPT and other LLM like helpers to basically help you with hacking. Um, one of the, uh, thank you, Amanda. So we can see that in the chat now if you want, there is the vulnerability guide that has a lot of information about those different vulnerabilities and also how to take care of them. Um, there is a lot of tooling that leverages LLMs in general to help attackers with automation, with identifying those kinds of vulnerabilities and exploiting them to the most severe way. Remember that ChatGPT from OpenAI or Bard from Google are sanitized and are very, um, strongly filtered. But there are open source models that you can control exactly what they can or can’t say to you. And usually those are used with malicious intent.

00:31:45
Speaker 1: Interesting. The guardrails are things like ChatGPT and Bard but not necessarily open source is what you’re saying?

00:31:53
Speaker 2: Yeah, So basically so you can guard everything, but open source is open source. 

00:32:04
Speaker 1: Thank you, Bar. I don’t see any more questions here. I see no open questions in either the chat or the discussion. So with that, I’m going to wrap it up and thank everyone for attending this abbreviated version of our presentation today, and want to thank Bar for his contribution here, because without him, and he’s in a conflict area, we could not make this happen. So thank you, Bar. And thank you to everyone for attending.

00:32:32
Speaker 1: Thank you everyone.

00:32:34
Speaker 2: Have a great rest of your day everyone.