Beans to Breaches: Getting Started with Application Security Testing

Unknown: So up next we have Lou Vega, from beans to

Lou Vega: breaches. Awesome. Thank you. TJ, so yeah, this, the title of this talk is from beans to breaches. What a coffee maker can teach us about getting started in application security testing. My name is Lou. I've been breaking software since the dark ages of home computing and making a living doing it since about 2014 I once hacked an ATM at the B sides Charleston event, and there is my favorite high score screen ever. When I got the ATM and it was completely under my control. At that point, I'd gotten in, locked everybody else out, shut down all other access to it so and then changed all the passwords so that I could be the only one to play with it the rest of the day.

Maybe not the most fair game, but it worked, and it was a lot of fun.

Unknown: So the big question is, how can this help teach about application security processing? And what we want to talk about is it's about the mindset that you approach your application security testing with, not necessarily the tooling or anything like that. So anybody in here, Lifelong skateboarder, all right, so we got one person back there, if you're a skater, and you look at this, you see a lot of possibilities. There's a lot of stuff you can do, tricks, board, slide down the handrail, ollie off the stairs, wall ride. If you're a pedestrian, you look at it, you're like, meh, it's a boring loading dock because you don't have the skater's mindset. The skater looks at it through

that lens of a skateboarder, and they see all kinds of possibilities. But if you're not a skateboarder, you just don't see those same possibilities. Similarly, when we look at a web application, if you're not an application pen tester, you might not see a whole lot of possibility there. It looks like a boring login screen, right? A lot of people might see this and say, What can I even do with this? I can't really hack an application if all I have access to is the login screen, where do I begin? So that brings us back to the coffee maker. You know what the coffee maker does, but did you ever stop and think about how it does it? Okay? So the coffee maker, you know, we

push a button, set a timer, put some water in. A few minutes later, we get a hot cup of coffee. But if you start to take a look at how it does that under the hood, and break it into the distinct parts, you get a little bit of the mindset of what you might need to do for a web application or any kind of type of application when you're trying to pen test it. So you might look at the coffee maker and think, Well, you're going to put some kind of input with power. There's going to be some kind of thermal regulator in there to monitor the temperature, some kind of timing device that's got to wait till a

certain time, and then it starts putting the water in over the brew. There's a whole lot of small moving parts that you don't pay attention to, because it just works. And that's what you need it to do, is just work. And same thing with people in organizations and businesses, when they're developing web applications, they're not often thinking about the security and what's going on underneath it. They just need it to work for their users, and so as the attacker, the pen tester, you're trying to break that up and to think about how it works and how it might be exploited to keep other people from exploiting it. So let's look at another application example. This one's

got a lot more going on in it. For this, you might already have a login to an application, so you can see, there's profiles in here. There's sales, apparent sales tracking information, lots of buttons to click, lots of items to on the sidebar there for deals, home screen, mail, activities, settings, and again, you look at it from the perspective of a user looking at it for the first time and trying to think, how am I going to exploit this? It may become overwhelming, because there's just so much going on there. So what we want to do is break it down into a much simpler process to start with. Now start with a disclaimer. These are not the only three things that you focus

on within an application, but these are going to get you a lot of stuff. We start looking at it. We can break it into three main parts. You got input, processing and storage for almost any application that's out there. Input is your chance, as the attacker, to control the logic of that application. You're controlling what happens next based on the input you type in. So for example, we look at that login form, we're supposed to put in a username and password. What are you thinking about that goes under the hood with that is it's going to take that username and password that you put in, it's going to look up in a database table. Probably does this username exist? Yes,

it exists. Okay, now we're going to take the password value that you put in, and we're either going to directly compare it to what's stored in the database, which is not a good idea, because you've stored plain text passwords at that point on the database, or you're going to hash that password value that they put with whatever hash you're using and then compare that hash, and if it works and everything's lined up, you let the user in. If you think about that from an attacker's perspective, you now have the ability, through that login form to potentially control the execution of their database queries that are happening. So that's where things like SQL injection come into play. Somebody that instead puts

instead puts, instead of a username and password in that login form, they put in a database command, and then that database command is blindly trusted, and you end up with a win for the attacker. Processing as an attacker, we only have to get the attack right once, and it's kind of game over for the defender. The people who are developing this software have to get it right every single time, and that makes it hard. It's hard to develop good software, secure software, and then finally, we've got storage. So if we get data into the application, there's the opportunity to have it stored. So if you're updating records of some sort, or processing data that has to get stored somewhere to be used later, whether it's a

database, maybe a local database, cloud based, it could even be flat files on the server. Who knows what they're doing. But that storage then also becomes another opportunity for input, because that storage later is going to be read from that where it's stored and consumed in the application somehow. So you get kind of a circle back to an input type issue, and then one of my favorite things, if the application is doing any kind of file parsing, so you're supposed to upload an XML file, or you're supposed to upload a video file, a photograph, a sound file, whatever, if it's got to do any kind of processing of that data that you upload, you have an

opportunity to combine basically input validation and the processing, because it's got to make sure that that's a valid type of file. So if you gave it a video file, for example, are you uploading a valid video file, or are you just uploading junk? And there's a chance to make some assumptions as an attacker about what the developer is doing with that data that you're putting in and trying to exploit it. So that brings us to a nice little cycle here where we repeat until breach. We craft input, shove it into this black box, which is the application that we're attacking, and we're observing the output, and then based on the observation, we're making adjustments, tuning to our input and continuing on until we get

something that gives us a starting point to launch an attack. I was a software developer for a long time before I got into application pen testing, and I loved it when I got a new error message when I was debugging software, because that means I solved the immediate problem that I just had, but now I got a new problem with applications. I also love getting error messages, but for a completely different reason, the error messages often tell me what the developer's assumptions were if I get some kind of complex, verbose database error message, I know now that they're expecting, for example, certain data type for me to put in. So maybe I'm trying SQL injection

in some kind of input field, and I've put in a text value, but the database error message that I get back says it's expecting numeric values. Okay, now I know I've got to make sure that my values, my attack strings, are numeric based instead of text based. So the verbose error messages, it doesn't seem like a whole lot at first, and as an end user, it might even be frustrating for you to see an error message on a screen. You're like, what do I even do with this? But as an attacker, those kind of things are gold. It helps you craft, refine that input that you're putting in and get the application to behave differently. You Yeah. So with all that said, we can look at

this login form a little bit differently. Now we start to wonder, can I put malicious info in the email and password fields? Am I going to put in, like, for example, a SQL injection, or any kind of injection, command injection, whatever. Don't just put what it expects you to put, put something else. You look at that little remember me check box A lot of times that ends up storing a cookie value on your computer. Well, guess what? Cookie is another avenue of input for the application, because the application is going to do something with that value that it put there, and chances are the developer isn't thinking about checking that for validity before doing something with it. So you may have where it says,

Remember me, and just says, Remember me, equals true, but you might be able to put something else in there, just as an example. A couple weeks ago, I was testing an application, and they had a time zone that you could set in the application. And I noticed that when you set the time zone, it set it as a cookie value. I thought, Well, okay, it's actually reflecting that in the application. So I went and made the time zone Lou. And sure enough, in the application, instead of, you know, Eastern Standard Time, it just said Lou. And I was like, that's nice. Now I know I've got a potential to inject stuff in that, and, better yet, that was on a public

facing page that you didn't have to have authentication for. So it gives me a little bit better of an idea of stuff that I can do. Not only that, but it tells me a little bit more about the mindset of the developer that you know, if they weren't being careful with values on that, there's other stuff that they're not probably being careful with as well. And to really pay attention to some of those input fields, one of the things I hear too from people that get started in application pen test, and they're like, well, this login form is kind of boring, though. It's just just that it's login form. One of the things to remember with this is that it is available to every user on the

internet they haven't authenticated to the app yet, so anybody who can stumble across this domain, this URL, has a chance to attack this good or bad. And you know from that you can try account enumeration. So you've got the thing there where it says, sign up for an account, you might get one error message if you've got a value user that's already there, and a different error message if it's somebody who doesn't exist already you've got the forgot password. I actually did an exploit on another customer, their forgot password thing, actually that you concatenate email addresses in the you know, the Forgot Password field. So you click forgot password, it says, Enter your email address to get the password reset link.

And so you put in the email address it comes to you. Well, what I found out also is I could put in my victim's email address the administrator of that application, a comma, and then my email address. Now he'll see in the email that the email went out to him and to me. But that application should not do that, because now I've got his password reset link. Chances are he's not paying attention to email, and I can now become that administrator just because they weren't validating inputs. And again, what I like about those things is because it's, it's on the public page, it's, you don't have to have an account. You can just, you know, dig in. I uh,

looking at another application, you know, all of these different things that somebody might click on. If they click on Ray Miller with $3,000 in the bottom there with the green, it might bring up a URL that'll be like slash account, slash 123, and that might be the ID number for Ray Miller, but you might be able to change that 123, to 124, or 126, whatever, and get somebody else's account. The key there is to look. Are you allowed to see? Are you supposed to be able to see that other account, or is it just letting you see it because you got the right number. Okay, the other thing you can do to try to get the application to

behave differently, put in a negative number, you know, does the application handle it or does it give you an error message? And again, if that error message is verbose and not just a generic, you know, sorry, an error has occurred. That's the best thing for the developers to do is just throw up a generic message, sorry, an error has occurred. You know, click here to go to the home page or whatever. The worst thing they can do is those detailed error messages like we're expecting, you know, to put a text value here. And I actually used that against a client in a attack last year they had, they were using GraphQL as their back end for

APIs. And GraphQL has this feature where, if you specify the query for the GraphQL and you have it wrong, it'll suggest corrections to it based on the data model that it's that's behind it. Um, so like, similar to, like, you know, did you mean to type this instead? And I was like, well, that's really interesting. I didn't mean to type that, but now that you're suggesting it, I'm going to type that and see what else I get. And I was able to use a series of those error messages that were suggesting additional things to find out that I could return other objects from that main object that I wasn't supposed to, but the model let me, and it helped me to discover

that path. So I ended up writing an exploit to basically pull the password reset link, in this case, for any user object in the account in the system, and so I could become any user of that system. They were pretty happy to find that, but they were also floored, because they hadn't thought of it, and they didn't think that their software could be misused against them in that way. I Yeah. So besides the mindset, what else helps? Because obviously, application security testing isn't just super easy. You have this one mindset or one cool tool, and then you're good to go. Definitely having a background in some kind of programming helps with application security testing. I'm not saying that you have to be an expert programmer,

and I'm not saying you have to know every single language that's out there, but if you're familiar with at least one language, I'll give you a pro tip as a software developer for over 10 years, most of the rest is just syntax. Okay, if you understand the core programming concepts and you understand how to program in your choice. You know, whether it's Python, C, sharp, go, JavaScript, or whatever it is, if you're good in one thing, chances are you can look at the code from another language and at least kind of figure out what's going on. You may not be able to sit down and pound out code for that language, but you can figure out what's going on, not only that,

but having that mindset or having that background can help you get into the mind of how the developer might have been thinking when they were putting this application together, and that's very helpful as well. Another thing is, never stop learning. I had a guy a couple of years ago. If you're in the Charleston area, I help run the Charleston InfoSec meetup, and we meet up and talk InfoSec and have beers and a good time. And there was a guy that came to me and he's like, how do you do it? He's like, I just switched from accounting to it a couple of years ago, but I feel like I'm drinking from a fire hose all the time. There's so much changing every day in

information security and technology. I just, I have a hard time keeping up. I don't think I like this anymore. I told him, it's good to determine that before you've spent, like, 10 years in the the industry. He eventually went back to accounting, because he's just like, I don't want to do this anymore. You know, numbers don't change. The math doesn't change. I'm tired of drinking from a fire hose. You will continually learn in this industry, they're changing technologies, programming stacks, all that stuff is a constant shift. So you gotta definitely want to do that. The other thing is to brush up on written and spoken communications. You're not paid to be a hacker. You're paid for the report. And the other thing

that goes along with that, everybody wants to be a hacker until it's time to write the report. So you can't discount, you know, things like your what your English teacher was telling you in college or high school about, you know, your well written papers and stuff, because the business people are going to want that couple other things that help learn the basics of networking protocols. You know, how they how things work on the wire, so to speak. You know, if you're looking at data packets, you know, know the differences between like TCP and UDP type stuff. Know some of the use cases for some of those common programming or common networking protocols so that you

can understand what you're looking at and help you. It kind of helps you take apart those applications a little bit better. Sometimes too, just even, like with web applications, knowing you know how HTTP works on the wire versus just what you see at the application layer, can sometimes help you with that. Some other things to be familiar with, definitely, if you're getting started in web app pen testing, or application pen testing, look up what the OWASP Top 10 is. Okay, there's a list from the Open Web Application Security group that has a list of the 10 most common web application vulnerabilities, and it changes over time, but by and large, that's where you're going to find. A lot of your

vulnerabilities in web applications are going to fall into one of those categories. In addition to the OWASP Top 10, you also have the CWE top 25 and that's another resource as well. And get a lot of practice in different environments as well. If you're looking at web application pen testing, Port swiger has an excellent web security Academy. They've got stuff set up for almost all of those vulnerabilities so that you can see what it looks like when that vulnerability is exploited, and then you have a better understanding when you're actually testing in the wild, because sometimes you may never have seen a particular vulnerability before, but if you have a chance to practice it, then when you actually see it in

the wild, it goes a little bit better. That's all I've got for now. Thank you for attending this quick overview, and I'll be available for questions here or after the talk. You