 It's Wednesday, first summer assignment, we're hitting the ground running here. This is, really the point of this assignment is to lay the groundwork for the rest of the assignments so that you can be, let's see, hello, okay, okay, so this assignment should be laying groundwork for future assignments. So the first one should be super easy, this is something that literally everyone can do, sign up for the course mailing list, super easy. Some of you have already done this, look at you, you're already ahead. Second part is Bandit, so I'm going to talk about this mic. The second part is Bandit, so for Bandit, the idea is for this course you'll be very comfortable with using the command line and being able to access and use a Linux machine. So Bandit is a war game on this place called Over the Wire. They have a series of challenges and go here and look at them and essentially they, to pass these challenges, they require you to investigate the environment and learn things about it. It's not supposed to be very difficult, it's supposed to be just making sure that you're aware and familiar with the command line because it's going to help you a lot when you are dropped onto one of my servers and you have to do things. So the instructions are all here, it's pretty easy to go through, yeah you can see I've already kind of looked at all of these. You need to, there are a series of levels, levels here, level one, level two, level three. And then the way we're going to track you on this is pretty cool, there's a site called Leech Hall that actually keeps track of your progress on multiple of these war games. So the Bandit channel is being one, there's actually a ton of sites. So it's actually a great way, the reason why I'm having you do this is, hey, you need to track you and be so that you can see these lists of resources to go and explore and further your security knowledge. So everything's here, it's pretty straightforward, keep tracking your readme, so when your readme is the thing that you'll submit, it'll have your Leech Hall name and it will have how you broke each level, so keep track as you're going so that we can see that yes, you did this and you didn't just copy everything from your friend. Any questions on this? Cool, this is fun, this should be pretty straightforward, the goal is not to be super difficult. If it's super difficult because you don't know how to use the CRAN line, then you should spend time to study so it becomes easy. Alright, the third part, backdoor web server written in C. So the idea behind this, the idea here is two parts, A, to get used to writing C code because you're going to be looking at a lot of C code in this course and also to get you working with sockets and socket programming, so if you haven't done any network programming, this will be a good introduction to that. The idea is you're going to create a minimal HTTP 1.1 server based on the RFC, so the third goal of this project is so that you can actually learn how to read RFCs and understand them about what they do and what it means and what the protocol, what you actually have to implement as part of the client. So this is another cool part that I really like and you can't use any libraries except for the C standard library, so everything's in C, there's no any other garbage, just straight C. So the idea is you're going to create this backdoor program that's called a normal web server, it's going to run, listen on a given port, basically most requests, it'll just give a 404, it uses your response code, how do you know what a 404 is? It uses your response code means, you read the RFC and see exactly what that means and that should tell you what you need to do. Let's see, oh, and the backdoor is if somebody makes a request to a URL slash exec slash any command, then what your backdoor web server will do is we'll take that command, pass it to the system libc function, which the argument you can read about there, and we'll return the output from that. So the idea here is you can think of this like, let's say you pack into and break into somebody's server, you want to give yourself a persistent backdoor, you install a web server there that looks like it's benign, it accepts port 80 requests, but actually it has this backdoor functionality to give you access back to this machine whenever you want. So there's some examples here, yeah, pretty, the important part here is it's got to work on Ubuntu 16.04, so this is going to be our standard platform for all assignments and everything throughout this course. So it's got to work on Ubuntu 16.04, if you have, you'll need to set up a 64 bit, so you may need to set up a virtual machine to get this so that you can do your development there. Any, I don't know, random excuses of, oh, but it works on my Windows machine, that's not a good excuse, right? So it's got to work, it's like, yeah, it's like the works on my machine, like designation of, right, the developer says like, oh yeah, it definitely works on my machine, but it's actually broken on the server and protection, so really it's broken, right? So you've got to actually fix it. The best way to do that is to make sure the environment you're running locally that you're developing on is the same as the remote environment. There's some resources here, feel free to share each other, resources about good tutorials or whatever about how to do network programming and C. For this, you'll submit your source code along with a make file, do I have, I'll add more stuff about a make file here in a readme, and there'll be a submission server that's not quite up yet, but I don't think any of you is going to finish in two days, so I will, in the next two days, I'll have these submission server up and running, and you'll be able to submit your code and get immediate feedback on your score, what test cases you didn't pass, all that jazz. Questions? Don't forget your password to the site, although maybe I'll have one of the TAs add some functionality for that, so I don't have to do it by hand. Yes, in the back. What was that? No, no, no, individual assignments. Yeah, gotta do this stuff by yourself, yeah. Yes, I don't know how many yet, we'll see. I keep it usually, because I don't want you to use the site as an oracle, it shouldn't be like a change one letter and then resubmit and then see that it fails and then change another thing and then resubmit, right? The point is to allow you to check on yourself as you're going along, but I've never, I've never had people like scrambling for problems, but it also does take some resources to process all these. So when all these start submitting, it gets kind of married. So yes, there will be a limit, if it's anything else, we'll deal with that. It's never a problem, so don't worry about it. What do you think is the reasonable timeline that's just starting to work in tonight? That depends. I mean, a reasonable timeline to finish. So should you start working tonight? Yes, so it's due, I guess I didn't say, due the 23rd. So what's that, like slightly less than two weeks? I learned this trick in the past. If I did it in two weeks, no, we would come to the class in two weeks because you all be at home doing the assignment instead of coming to class. So yes, so right before two weeks, you should definitely start now. Especially getting started on bandit is important just so you can feel the flavor of the levels and the challenges, solve a few. And then you can see, oh, dad, you go back and do like a half hour a day and this will be done in, I don't know, three days or something. This, the back door really depends on you more than anything. If you start today, I think you can finish this in a week or something. So, but I want to give, there's, I think you can still add courses and stuff. So I want to give enough time at least people have that. So, yes, question. Yes. I've already done bandit. Good. Then that's fine. Then. Send an email to the communication list. We can talk about that offline. Anything else? Is it a submission or everything needs to be submitted at once? Like each part is individual. So you can submit each part on its own. Yes. The group is a link right here on the course, the course mailing list. It's on the syllabus and it's on the main webpage. So what's the main page? Oh, it's my website. You can just go to my website at adb2pay.com and then you go to teaching and find the classes from there. Or there's now, I just added it before class. There's a link to the syllabus on the, my ASU. And so you should be able to get everything and find everything from here. All right. Well, just talk about ethics. Does this actually make a difference? No, I don't think so. Does it? Hello? Testing, testing. It's going to do it there. Testing, testing. No. Oh, it's off. That helps. Testing. Yeah, that works. Okay, I'm going to use this thing. Okay. So that's probably not what you want to see. I don't think it's going to work. See it's showing me the regular slideshow. It's showing you guys the presenter view. Unless I changed the wrong one. Sweet. Thanks. See, look at that. All right. All right. So ethics. Well, ethics. So we've talked about famous hacking incidents and the people who perpetrated them on Monday and seen that it often does not end well for our nefarious hackers. They frequently find themselves in jail. So while ethics itself is a huge, you know, philosophical thing that we can talk about, mainly what I'm concerned about is because I do not want any of you to end up in jail, especially because of me or things that I teach you. Because, like Adam said, it's okay is not a good defense. This is definitely this is something so avoid jail. We want to, and what this really means is we want to make sure that we are ethical in our testing of security vulnerabilities. We want to make sure we don't accidentally do it accidentally or purposely do anything illegal. So it's actually kind of easy. Just don't do anything that's against the law, right? Don't get me into the law. You won't go to jail. What's the, what does this actually mean in a hacking context? Are there any lawyers in here first? How about last year? That was fun. Yeah. Donut. So don't, how do you know if you're authorized? So don't hack a system if you're not authorized. How do you know if you're authorized or not? Yeah. Most of the time, you would not see that they want to be constrained. And then if you find any bugs, so there's a bug on the program, on the website, or other websites like AcroRank. And so if there is any bug one, so we are free to do penetration testing. And yeah, if you get any bug, so you would get paid. Otherwise, you're going to jail. Yeah. So the question is like, so it's all about authorized, right? So if I can basically hack and try to break into my own laptop, right? I own a laptop. I own the software that's running on there. I can try to find and exploit security vulnerabilities against my laptop. Let's say I find some remote codec execution vulnerability against MacBooks. And now when I launch that at your, you and your computer, that computer, right? That's when then that's illegal because I'm getting unauthorized access. If I tell you about this and you say, hey, that's super cool. Run that against my machine. Now you've actually authorized me to do that, right? So this is really the main thing is don't hack into a system that you do not have permission. And fundamentally, I think the other way to think about this is don't even attempt to find vulnerabilities in systems that you don't have permission. So it is incredibly tempting. I know once, especially when you first get your first taste of security knowledge to want to then go out and hack everything and find bugs everywhere. And bugs are everywhere. Absolutely. So there's bugs out there. You can go out and find them today. But if you don't have permission to do that, absolutely 100% do not do that. As one of the students already mentioned, as we'll talk about, there's a number of bug bounty programs and companies that actually give you access and allow you, authorize you, hey, feel free to hack, find vulnerabilities against our system. And from there, you can go to town on those as long as you follow their terms of service. So some of the things that you can do, you can always download source code from onto a system or server that you control, assuming it's open source. If you stole the source code in the first place, then you have problems. But if you download source code that you control, you could look at that source code, run it locally, find bugs in those programs running on your system. That's 100% fine. And we definitely need to practice. I mean, this is one of those things like you get good at security by doing it over and over again. So you want to practice your vulnerability analysis, your exploit development skills, download stuff. Bug bounty programs are a great way. So there's a number of websites and resources out there. You can go, and a lot of actually companies themselves have bug bounty programs where they say, hey, you find that if we give you permission to pen test our systems, if you find something, tell us and we'll give you money, which is kind of awesome. The third way is actually really fun. The one way I like is become an academic. So this is kind of the third way to be able to test systems. And the idea is so oftentimes in our research, we want to answer a question like how common are, let's say to cite a recent thing, how common are email header injection vulnerabilities on the web? That's an interesting question because it's, well, is it a huge problem? Is it not a big problem? What's the implications there? And so to answer that research question, we developed a system that went out and crawled and scanned the web looking for email header ejections and actually triggered and tried to get some email sense. And so we have to balance the scientific benefit versus the ethical benefit. And the nice thing is we have the backing of the university and the lawyers of the university to go to bat for us if anybody ever has a problem with that. But it definitely is something that we really consider the ethical considerations here before we do this. So that was actually a super fun study. We do kind of studies like this all the time of searching for vulnerable stuff for scientific purposes. So that's kind of the third part. So bug bounty programs, there's actually a lot of them. Some, actually I guess I should. Some will give you money or most, but some will just give you fame, which is still pretty cool. The key is understanding that yes, you have permission and understanding what is in scope. So that's actually, so just because I have told you here that Facebook has a bug bounty program, that doesn't mean you have free reign. You go do whatever you want to do on Facebook. You have to actually go to the bug bounty program, read, understand the terms of service there so you can make sure you're doing it ethically. And this actually is a really good incident here. So a security researcher found a vulnerability in Facebook that allowed them to post on anybody's wall. Is that a vulnerability? Why? So it came close to not making any information about somebody else? Yeah, so normally, so it's all about what is, what's the normal functionality of Facebook, right? The normal functionality of Facebook, you have to be friends to be able to post on somebody's wall. So this security researcher found this out that they could post on anybody's wall. And they actually reported it to the Facebook security team. Unfortunately, there was a bit of a communication breakdown. The researcher was Turkish, didn't speak English very well, and the vulnerability description wasn't well described. I think it just said something like you can post on people's walls. So it wasn't really clear what the problem was. On Facebook's side, it's a double edged sword. So Facebook's side, they really didn't follow up on it and were kind of dismissive and were saying it's not a problem. And so this researcher to actually get the attention of them to fix the problem, posted it on Mark Zuckerberg's wall and writing about, hey, I found this vulnerability that it didn't post on anybody's wall. And you can imagine that that got fixed within like two hours, that bug. And so the researcher then went, hey, well, I reported this bug to you guys. I should get my bounty. And Facebook was like, well, but our policy specifically says so they actually, Facebook is super cool. They give you access to a completely different test network than the normal Facebook network. Not in terms of network, but in terms of social network. So you can create as many fake accounts as you want, friend them with each other. So you can have your own little playground to play in so you don't actually demonstrate vulnerabilities on the real website. And they specifically say in there, do not, you know, if it's possible to do it in our test set in our playground, then do it there and show us. Don't do it on the actual Facebook website, otherwise you're violating the terms of our bug bounty programs. They actually didn't, they said that this researcher was ineligible for the bounty. So now this is, you know, an instance where the researcher from a good place wants to get the problem fixed, so escalates it, but in the process it's actually exploiting it to raise awareness here. So it's kind of a tricky situation. So yeah, here's the, you can see the post here, this screenshot is from this researcher, Dear Mark Zuckerberg. First, sorry for breaking your privacy and post your wall. I had no other choice to make after all the reports I sent to Facebook team, and then it's like a whole, I guess it wasn't a trick or treat, yeah. And just to say, you're learning the bounty, all you do is put it on his resume. That is true, yes. So yeah, I don't know what would happen to this person if anybody wants to go do a history report and do a study and figure out what they did afterwards, but yeah, that would be a pretty good, pretty good resume booster for sure. Oh yeah, you can see the whole thing here so you can see like it was a big, you know, it caused a big problem. So, let's kind of put yourself maybe in this person's shoes or some other person's shoes. You spent all that time looking at, let's say, a piece of software or something or a website. You find a vulnerability. What do you do after that point? So is it? I would say file a bug on it. File a bug on it? To with who? The service in which you're, if they happen to fail. With the service, so maybe file a bug on it, what else were some other options? That's it, you're only after it. Yeah. Tell the world about it. So like in what way? Just stand outside chatting about it? If you want to be told a piece of it. Yeah, you can write a blog post about it and post a blog post about it. Yeah. I said evaluate the implications of vulnerability first. Yeah. I mean, if it's something that's related to fashion security, then you need to take a different approach. It was just like a process. If you're a daddy, you can do something website admin. Right. So that's an interesting case, right? Like being able to post on somebody's wall versus, let's say, kind of bugging some new reactor software or something like that, right? So that's interesting. So understanding the context of the vulnerability itself. What else? Yeah. Even though we have good intentions to understand the complications of that, but it can in turn be hacking or just if it is something, but an international security, and if you go into the bug and find and explore what it is, you get to know some information and that might be violating someone's privacy. Yes, but let's say you shouldn't have done that in the first place. So let's say we found the bug completely ethically. So we didn't violate any privacy. We did it. So we had 100% rights to find it. Yeah, we can report to the information security officer of the company. Right. So we can report it maybe. So we can find a bug report, try to find the security contact of the company. What else? You guys are all too nice. What else could you do? What was that? Wait, just like, sell it to who? To me? I'm not mine. To the competitors. That's a good way of thinking. Actually, you can maybe sell this bug to the competitors or try to at least. What else? Who would else with five vulnerabilities? Yeah. FBI, maybe, I've seen them buying zero exploits on Apple phones. Yeah, so you may sell it to either directly to a government agency or to a security company that is known to then sell them to government agencies. You could go even worse than that. So if you find something in a nuclear reactor, you could sell it on the black market to whoever wants to pay you a bitcoin and you don't know who they are. Maybe they're a malicious state actor or terrorist organization or whatever, but you don't know they're just like an anonymous person who wants to buy your friend. Yeah. So this is all what you could do versus what you should do, right? Yes. Yes, we're just talking about what you could do. I'm just going to first have possibilities and then we'll talk about pros and cons. Yeah. Write a white paper. This is... Yeah, that's the academic approach. You write a paper. Actually, the way you do it is you really find one vulnerability, you write a tool that can find more of those, then you run that, find more, and then you write a paper about it. So that's how that goes. What else? What about doing nothing? You could do nothing, right? Inaction is an action. It's an option. You just wait. Maybe... Look at the market. It's not right. Maybe you're not going to get any money. Maybe you may need it in the future. Maybe you pull it out. So okay, so these are any other possibilities of what you could do? Yeah. You can use it to, in the future, change this vulnerability to other vulnerabilities, to gain more access, and so we can get more popularity. Mmm. In a setup, just getting access to just one computer, maybe, for example, two years later, somebody finds something like SSR vulnerability, so you can scan the internal network and get access to others. Yeah, so it could be... It kind of depends... It depends on exactly what it is, but if you were a... Let's say you're trying to make an end-to-end exploit, let's say from a browser that lets you pop out of the browser and exploit the browser and get the sandbox and get access to the system, you may need multiple vulnerabilities together, so you actually may save it for later, in that sense, with the intention to combine it with other things later. Cool. All right, that's pretty good. So what should you do, or what... So I guess that's, I think, a loaded question. So what are some of the pros and cons? Let's think about some scenarios. So let's say the total world approach. So let's write a blog post about it. So what are the pros and cons there? What was that? Fame. Fame? So is that a pro or a con? It's a pro. What was a pro? A pro? Fame in terms of yourself? Personal? Yeah. Yeah. And professional? Personal and professional? Yeah, that could be a pro. Possible legal problems. Possible legal problems? Depending on how you maybe found out about that vulnerability, depending on if you had access. I think you could be reasonably certain if you, let's say, found something in an open source piece of software that you have on your system. You would be... I'm not aware of any cases where that would have legal ramifications. I might not have the same intentions like you and someone who read that. You can go and destroy that. Yeah, so on a con side, right? Not only, so telling the world means you're telling literally everyone, right? You're not just telling the good guys or the good people you're telling also the bad people. What do you think it's fixed? What was that? Depends on your pay drink. Depends on your pay drink? Let's say it's actually like a big deal. It ends up being a pretty big deal. What do you think? Probably it's fixed pretty quickly if you just blurt it out because then they know that it's, anybody's vulnerable, able to pick it up. Because now good people know that the bad people also know about this. So they know that they have to act quickly before the bad people take this and start using it for various purposes, right? So, yeah. So compare that to telling the company. So let's say we contact the company. Let's say we're actually talking to a good company or organization that has a security email address and a way to contact them and a very nice page that's easy to search. This is not always the case, which is part of the problem, but let's say that exists. What are the pros and cons there? The pros are that you probably are, if it was a bug bounty, you're probably knowledgeable to get it. But soon you went through the crackways getting it. Yep. The company probably wants you to do it that way because then it hasn't disclosed it to everyone else. Yeah. So the benefit there would be, you'd be on the bug bounties. The company may appreciate that more because they don't have the pressure of bad people using it. The other thing is a little bit because maybe sometimes the company is not appreciating all of the hard works and why you're just telling them and then you patch and we don't tell you anything at all. Yeah, we actually have the con there of you may not even get, the company may not credit you for doing that. They may say, hey, thanks. We really appreciate that information. They go and fix it. Their software is now better. Their users are safe. So you did have a good impact, right? But you may not get the visibility necessarily that you would get in a tell the world case. They might give you a job. What was that? They might give you a job. They might give you a job. Yeah, I mean, yeah. It's possible. You don't have as long to, I mean, if you do it for me, if that's your first week, you don't have a company, you no longer have as long to exploit or explore that vulnerability because that vulnerability could lead to, say, their ties to the 10 other companies and I think those companies are vulnerable. But now you... Yeah, so let's think about it. So what about time to fix? Like, what's the difference in the two cases you just talked about? So usually for a part of a company, they might sit on it for a while because they know that they have people who know about it as well as some people. So maybe they might not be that many of them. Let's think about that for a second. So yes, I totally agree. So oftentimes the companies for legitimate reasons often, so especially let's say you report a bug in Windows, right? Has anybody worked at Microsoft? Yeah. I have, I know I have. I'm just trying to get some validation to the verification of the audience so I can just think of making stuff up. Maybe I have, but, you know, you'll never know. So if you think about that testing matrix, so anybody done testing, so you think about testing matrix is like all the different possible combinations you need to test in your software. So whenever they make any patch or change the Windows, they have to ensure that every single, it runs on every chip, every hardware combination, I mean, insane amounts of testing going to testing Windows changes. And so, you know, they may say, hey, because you as a researcher you want it to get fixed as soon as possible. The company also wants to make sure that change doesn't affect and break people's software, right? So you have this tension between the company and the researcher. Although I guess the other thing is, so the other thing you said is because, I think I'm going to paraphrase it because I don't remember exactly. I wanted to seal it, but I couldn't talk to you. You said that the company doesn't know. Oh, there's not this pressure that the bad guys know about it. But is that true? Not true. Because they may know it and we don't know it, right? So yeah, this is actually one of the, I think one of the really important things to think about when you're a security person is that you're probably not, you know, you find something cool, that's super cool. You're probably not that special where you're the only person on earth who's ever going to find this. And so this bug could actually have already been exploited by people, right? So this is actually one drives a lot of security researchers and your goal is to live it harm and try to improve the security of people. Then you want that fixed as soon as possible, right? Because you found it. That means it's likely somebody else had found it in the past and they may already be using it maliciously. If you don't have any evidence of that, then you have a problem, right? So that's why there's this big, big kind of discussion in terms of disclosure about what to do. So the Tell the World is usually called Full Disclosure. Tell the company or group or organization responsible has a really good marketing name called Responsible Disclosure. So this is actually a good case of PR coming up with a good, because like a lack where you're not responsible in disclosing things. And so other things that we said, so no disclosure, you sell the information to either, there's a couple different ways you can go. Some are more ethically gray than others. So for some, so there's a, ZDI is the company that, by HP, they will buy like exploits for not a ton of money, but a good amount of money. And then what they do is then they use that in their antivirus systems that are running in corporate networks to say, hey, we're actually defending you in zero days, completely unknown attacks. And then once you sell it to them, they'll push that out to all their customers and then they'll work with the vendors to get it fixed. But now they can say that they've guaranteed that their customers are not going to be attacked by this in the meantime. So you can do that, or another way is I mean, you can sell it to governments, malicious governments, I mean Paris organizations, you can sell it for whatever kind of money with the understanding that it's, and mainly what they're buying is not only the exploit, but also you're guaranteed that you're not going to sell this, you're not going to release the details, right? So they're kind of paying for your silence. And that's what they want there. What do you think is the, I don't know, what do you guys think is, personally what do you think is the right thing to do? This won't be the time. Does this have a word responsible in it, if I took that out? Would it be different? So I think the important thing is that it's, actually I believe well, I think it's really a personal decision. I definitely, like I would say black market would definitely, for me personally, ethically not okay with. I understand that that's how some people in some organizations make money, and I guess you just have to be fine with that, but you're, I don't know, it kind of goes back a little bit to the fame or at least credit or whatever. It's like you spent all this time to find this, and now you just want to sell it to the highest bidder or tell people how cool you are and fix the world and the process. But I think there are important differences between full disclosure and responsible disclosure. So those two, I definitely feel that that's a little personal decision of what you are comfortable with. Like there are really good reasons to do full disclosure sometimes. I kind of want you to think about this. It's like this is a very murky area and it's very, it's still being debated by security people. There's not a, this is the one way to go. And so personally, I kind of believe, like responsible disclosure in the sense that you first work with the company, but with the understanding and the expectations set up front that you will release this at some point. This information will become public because you want to make sure more people know about it. So the other thing that people do is they'll do like a responsible disclosure with the deadline and say, hey, I'm reporting this to you on this date, 90 days from now, I am going to release the details about this vulnerability. And that's what I'm going to do. And if your patch isn't ready, then I'm sorry, but I've given you 90 days and there could be people already affected by this. So it's kind of a personal decision. So would you hire a hacker? So we talked about that a little bit. So let's think of the malicious ones. Think about the people that we talked about a little bit on Monday. So like the, you know, really black hat malicious hackers who were breaking into computer systems, they caught, they go to jail for five years, then they get out. Would you hire them? Depends. Depends? Depends on what? Because of our stories, we don't have VIPs. We don't always hire them. We don't hire them. We don't always hire them. Okay, well let's say you were the FBI or CIA. Would you hire them? Well, because if they do, they'd love to know what it did. They may be able to help you prevent it. Okay. They're like, are their skills still relevant to the current state? That's a good one. I've never heard that one, but that's really good. Let's say it's less. They weren't in jail for five years. That's actually a long time. We don't have computer access. Yeah, we don't have computer access and all that stuff. Yeah, so let's say they're still super relevant. That's a good one. For example, when that guy posted to Mark Zuckerberg's wall, there was some chatter about is this guy going to be prosecuted? Mm-hmm. And they may have had that within their legal domain to do so. He didn't follow the policies, but in that instance, it's definitely hired again. I guess the key question is we didn't talk about it as hiring, so it depends. I definitely agree. It also depends on for what job. We're talking about flipping burgers. I don't care if they're a hacker. What do they do? But it's, let's say, to defend your company, right? To be the CISO, like the Chief Information Security Officer, whose job it is to come up with the policies to defend the organization. Or even lower, kind of like a blue team or an incident's response. So would you hire a person for a defensive position if they were a... So we have some people say, yes, they definitely know the area. They know what the bad guys know. They're one of the... I'd say they're some of the best hackers in the world, but they got caught. So like, how big could they be? Yeah. So why do you need to trust them? Because you're not sure if they're doing the right thing that you've been doing. Yeah. So you're literally letting them into your organization have access to everything in your organization. You're giving them the keys to their kingdom. Are they going to be there forever? What happens if something happens and you have to fire them? Are they going to go quietly or are they going to release sewage all over the place? Right? Yeah. Do you want to get a super monitor and they'll check them? Watch the monitor. It does depend on the role. You can think of like a pen testing or a red team, more of an attack oriented side. These people could be perfect for that. So I think that this is a good discussion and it really is like an open problem and like we said, it really depends on a lot of variables. It depends on the person. And I think that was a good point it boils down to trust really is you want somebody who can find problems that are motivated but the downside is you don't want to hire an arsonist as the fire chief. Right? So, especially some of the people of the examples here and maybe it's an overgeneralization but definitely some of them have horrible personalities and are really terrible people to work with so that could be bad. Yeah, you really have to take as the hiring manager you have to take kind of a general assessment but hackers are hired all the time so it does, you know, like we said the pros often times outweigh and like we said, the main problem is how do you fire these people? Right? Very difficult because this person here is just like stealing credit card numbers and like okay. So, what we're going to be looking at mainly here is what we're talking about is penetration testing. Well penetration testing is very broad and this is actually so we're going to be looking mainly at vulnerability analysis so how to identify vulnerabilities in a system we'll also look at exploits of writing and exploits for that. Penetration testing more generally is when a company will usually hire somebody outside the company and say, okay we want you to act like a hacker and try to break into our systems digitally usually although there are cases of physical where physical pentests occur and so and so the idea is so what's the use here? Why would a company do this? Like do you ever I'm trying to think of like a personal example do you ever hire somebody to try to break into your house to see how good your security system is do you hire people to chase you out of here? You don't have as much to protect as they do You don't have as much to protect as they do? That's probably true and you probably don't have as much money to protect also as they do Yeah, maybe rich people do that Yeah Because these are the people you actually pay them to find the resources but hackers whereas they don't have the same intentions as these do so they can when they find like when they find the same model they might exploit it with these people to report do you want you can change it to vulnerability so you get rid of all this disclosure discussion you say I'm hiring you take two weeks, pound on my website find all the vulnerabilities you can show me what you can get and then tell me about all those cool Yeah so the idea is it's usually black box in the sense that you have the same capabilities as an attacker would and we're not going to focus a ton on the whole security life cycle here we're really focusing very specifically on vulnerability analysis and so is penetration testing useful so you get like you are in charge of securing organizations, you hire a company you give them $200,000 they get three weeks they come back with a report is that useful it has some programs for penetration testing not just one penetration testing it should be a regular process you know because developers all the time are trying to develop new codes and also there are new vulnerabilities that will define this time so they should analyze all of them regularly and so as you can think of it as like a pen test is kind of like a snapshot of time of hey this is what we can find on this date but systems, organizations are constantly in motion patches are being deployed systems are being upgraded hopefully they're fixing all of these things that you found but who's to say they actually did so often times that's why you so when you do a pen test usually you'll do one and maybe a follow up after a few months when they claim they fixed that just to verify that they've actually fixed those problems so yeah it's a downside in the sense that it's a one shot deal and it's only what those people can find at that one time and who knows what happens a month or two months ago was it useful? I mean how much money you have to pay versus how what's your threat of attack what's your you know like if you have the resources to do it and and you can you know you have a team to to move forward from the results that could be useful if it's I don't have the money to do it then yeah so that's so it's interesting so some things like for PCI compliance which is the organization that regulates it's like a self-regulated industry of credit card people so if you want to process credit cards you have to get certified as PCI compliance one of the steps is to have an annual pen test and to fix the problems in those pen tests so I've done a few pen tests in gigs back in my PhD they're super fun because you always find stuff like you get free reign to do whatever you want yeah you always find we always were able to find stuff and find different bugs and so that's it's always really fun and then you have to actually develop the exploit to show them right you don't just want to say hey I think there's a bug here so for instance this was a credit card processing company we found out they had one of these classic problems where you would get your monthly report and we had a fake company so we'd log in get our monthly report the monthly report was some number got PDF and we were like that maybe looks like an auto incrementing ID so we tried various numbers in reign plus minus 100 and we started getting other PDFs from other companies but at that point we were like oh we need to show them how bad this is so we wrote a crawler to download every single thing we possibly could and so we had all the credit card processing of all the companies that they had so this was you know super sensitive information that we were able to steal and to demonstrate to them hey look this is how this is what an attacker could do yeah question we are talking about ticks and so I have been in a situation during the penetration listing we need to reporting all the stuff that we found but the problem is that if we consider for example working on a twist of authentication system and this system is implemented in the core of a banking system or an eventful communication system and using that you can get authentication password of a lot of users and so we can change their passwords and so the problem is in that component which is a third party component and okay in this situation when we are just reporting that company we just have all of this information and consider confidential information and don't disclose that what should we do with this piece yeah I mean I think that's up to your probably your pen testing agreement with the company so you probably want to cover yourself in advance by having a clause saying like hey if we find any bugs and any third party components will release those separately a month or two months from now or do responsible disclosure with that company if you don't have that in place then it's really all about your relationship with that company because I mean I don't know exactly how I'm not a lawyer again but I think like it's kind of like it is a consulting group right they're paying you to perform a service and so they kind of own all the stuff that you found during that thing so at the first stage you should be responsive to the component director until and only before I would work with the person that hired you first that's who I've talked to to say hey we found this thing in the third party component because you have to be very careful so we actually found that one of their credit card processing machines had like a IPMP which is like this server config protocol open with a default username password so I could have completely like installed my own kernel on that machine and like but as soon as I found that sectional awesome like I started like thinking about all the crazy things I could do but then I called down and talked to people and they were like don't do that don't do that just tell us what you found we're totally fine we believe you so yeah you know it's all about like was mentioned managing risk and balancing risk so cool so in summary proceed ethically so this is what I'm not only expecting a mandating of all of you in this course only attempt to find vulnerabilities in web applications or other applications that either you control or have permission jail is a possibility and it's also against the ASU computer misused policy so I think the bullets went the wrong window do you think the being ASU policy first to jail second well maybe you could self-finish your degree if you're in jail you could break the I'm not advising I don't know how that works I mean you could do remote classes so we're going to start out so we're going to start out on network security so we're going to look specifically at always break various network protocols and it's actually incredibly important because many applications don't just process our input directly from our terminal or our console or our GUI nowadays many applications talk over the network meant a lot of protocols when you talk about the web you can't really talk about and understand the web if you don't understand TCP IP all that kind of stuff so we are going to go through networking and so it's going to seem like a networking course for a couple weeks but that's because the native ground works we're all on the same page for all the networking protocols how they all work and then we're going to talk about how we can break them because this is actually a really one of the things we do this part of pen testing is you go to an organization and you plug into their wall and see what you can do can you get so if a backer came in and just plugged into the ethernet connection can they get access to the database can they snip on developer traffic can they steal emails and so if you don't know how to do all of this we're only teaching you a very limited part of insecurity here so the IP suite so the networking stack basically we're going to be looking at TCP IP the idea is so we've all everyone heard of the OSI network models how many so seven what are they seven good that's the test what are they starting from the bottom physical physical same thing same thing wash out transport transport it's fine it doesn't matter we have physical links internet transport application I like to think about the 5 model so here's our nice stack we have the physical layer which is the actual how things to transmit over wires, I'm not an electrical engineer or anything like that. I just assume it's magic that works. The link layer, as we'll talk about, this is where now we get hardware components talking to each other. We have the IP layer, the transport layer, and then applications on top of it. So I like more of a simplified model like this because it maps very closely to the protocols we're gonna talk about. So we'll talk about it. So basically, the way we're gonna go about this is, so remember when I said security is all about breaking down abstraction layers and understanding exactly how things work. And that's what we're gonna do here is understand basically from the physical layer up about hardware interfaces, IP, ICMP, TCP, UDP, and then we'll talk about probably some protocols at a later point. Cool, so IP addresses. The way to think about IP addresses, if you've never been networking, IP addresses are like an address. So the idea is you have some machines on a network. We have two nodes on our network. These nodes need to talk to each other, but they need to know who to talk to. And in this course, we're gonna be focused on IP version four because it's still one of the most popular, I mean, still is the default standard protocol. Hopefully I should be able to give you enough background and insight into IPv4 if you can then go learn, read the specs on IPv6 and you can become an expert on your own time. So the whole idea with IPv4 is it's a 32, so your address is a 32-bit integer. Wait, yeah, 32-bit number. And you'll mainly see these in terms of this decimal dotted notation. So this is basically, so you think 32 bits means four bytes. So the first byte is zero to 255, zero to 255, zero to 255, zero to 255. So this is the standard, kind of when you look at a raw IP address, this is mainly what we look at. The classes are not very important. I'm gonna skip these. They used to be you had certain fixed class sizes where like a class A network could have, I don't know if that's 16 million hosts on it, but they realized, hey, that's a terrible idea because one organization doesn't necessarily need 16 million addresses. And so they invented a way called CIDR, classes inter-domain routing. The idea is we need more, so basically you can put the, because the idea is with the internet, you need to know basically, not only the IP address, you need to know what network, like where does this, where in the large scheme of things is this host located? So here, we'll look at this, it'll be very clear. So the idea is your address will be able to place the host ID and the network ID boundary with this. We'll see in a second, it's pretty easy. So IP is basically how we can get a piece of information from one machine on the network to another. And it's actually pretty terrible when you think about it. It is connectionless, unreliable, best effort. It has no delivery integrity, ordering, notification, or bandwidth guarantees. It guarantees you almost nothing, except that I will try a real hard to get this packet to that IP address. And yet everything still works. But actually this is a really good point. And when you think about the design of networks, what's nice is now you're, when you think about that layers, we just looked at, right? If the IP layer doesn't guarantee all this, then other layers above that can, and not everybody needs all of these guarantees. So it actually, what it seems like kind of a whore, it's like, why would you build your network on quicksand? You don't know, you wanna talk to somebody, you send them a message, the letter could go away and it could happen. But it actually is pretty nice. So basic idea, if you have IP addresses on a network, you should be able to send ID data grams or packets from one node on that network to the other. Okay, great. So, so this is, so again, we're talking about RFCs. So this is the RFC, you can read exactly what every single bit inside of an IP packet means. We'll talk about kind of some of the more important ones. So the way to read this, so the idea is, so just like if you're sending a letter to somebody, right? What do you have to do if you wanna send a letter? Do you just write a letter and then just throw it in the mailbox? What do you have to do? You have to write the address. You have to write the address, you have to usually put in an envelope, right? A, so that the mailman or mail lady can't just see it. But also so that you can write where it's going to, right, where is this letter, where is the address that this is going to? You also write where did this address come from? So you put your address on there as well. And what else do you put on there? Yeah. You gotta pay for it, right? So yeah, so you gotta think about this as like, so these are gonna be some headers of an IP packet that tell all the switches along the way, hey, this is how, this is where it came from, this is where it's going, this is any other metadata. You can't put stamps on here yet, but maybe in the future. So first thing, so the first four bits, so these are bits, so bits zero through 31. I'm just gonna go through this and talk about some interesting ones. Okay, cool. So, so we first have, we have versions, which would be four, right, so this is important because if you wanna upgrade version number at any point, this way immediately somebody that's parsing this packet can know that this is version four versus version six. The length, so the length is important so that we know how many bytes or how many bits to expect. Identifiers, we'll talk about in a second, fragment offset, a time to live, so this is an important value, as we'll see. We don't want packets to just float around forever among networks, so if there's ever a networking loop where A sends a B, B sends a C, C sends to A, that packet would just keep looping there forever, so the IPA is just time to live field gets decremented by every packet along the way so that that way when it drops to zero, they stop sending that packet. So it's just super important and it actually will come up really handy in what we're gonna do in some security stuff. Protocols, this is kinda interesting now. It's actually not that interesting. Okay, other important things, sorry. Source IP address, destination IP address, right? So this makes 100% sense when we talked about an IP address is a 32-bit integer. Here are where the 32 bits are located inside the packet header, right? You have bits zero through 31 and the destination IP address, so this is essentially, like on our letter, the destination address and our source address where we came from. Cool, so all of this, there's a bunch of optional fields that can exist and then there'll be the actual data. So this is what you can think of as in that letter. So this data is everything that's inside that envelope. That was the word. Great. Okay, so this is more details about this. I'm gonna skip over this because you can, an important thing here is the max size. So it's actually interesting if you, that's the wrong thing. It's actually interesting if you've never thought about why this is. So the total length, so here we have 16 bits here to describe the length of an IP datagram and that means that the maximum length of an IP packet can be 65,000 bytes. So directly follows from 16 bits to describe the number of bytes. Cool, ID, so ID is important. It's going to uniquely identify this specific datagram packet that we're sending. Various flags that are used at IP flags. The main one is used for fragmentation, which we'll talk about in a second. The time to live. The protocol, okay, it is interesting because it actually tells you about what protocol is at the other layer. So it's kind of a weird abstraction breaking thing because why would IP packets care about what kind of data it could be? Check some, so check some is important because you want to make sure that no bits were flipped or changed in your transmission. So this is 16 bits that allows the switch to calculate and say yes, everything looks like it's correct addresses. Okay, options, yeah, crazy. So what's really interesting when you read these specs is you can see all these weird options that they had historically. So security bits in there, so actually kind of similar to what we talked about with maybe paying a stance or something, it's like a bit that says this packet is secure so that the switches could decide not to send that out anywhere. A really interesting one was recording the route. So each router would record its IP address in the packet when the packet went along, which seems ridiculous, but why would you want something like that? There's no way to do it. Yeah, so you know it should have been there. So you can debug the network because they had to add these things back when stuff didn't work. So you just send a packet on a reliable, no guarantee network and it doesn't get to the other side of what happened. Timestamps, so you can put timestamps on there. Interesting one was source routes. So the source machine could actually specify what route should these packets take, which is kind of crazy. And there's a lot of other options. They're pretty fun. Maybe one of these, that'd probably make a good homework assignment is like go through and document all these crazy options. Okay, but an IP packet, right? So the IP packet was packed towards the bottom middle of the layers. But to even send out that packet, it actually needs to get encapsulated inside of a lower level packet, which is going to be our link layer packet for an ethernet frame. Mainly the way we think about that. And so it's just like envelopes, right? So what was, so the frame data with the frame data contains the IP header plus the IP data. And the same thing will actually happen up is the first part of the IP data will be the TCP layer headers and then the TCP data. Okay, so there's two main situations we need to deal with. One is, is this machine on our network? So is node A and node B, so we're node A. We wanna talk to node B. We're on the same network. I'm gonna throw it out there. Hope that somebody gets it. Yeah, it has to go, well, definitely has to go through a switch. So how do we know that? Okay, so let's go back to, so here we're gonna use a different example, the subnet, so there's two ways of writing it. You can either write out explicit to the subnet here for saying 111, 10.20 is the subnet. That's the same thing as the slash 24. So there's just different ways of writing that. So we're A, we're gonna be 20.121. This is going to be our MAC address. So this is our link layer address. So this is hardware addresses that we're probably all used to seeing.14. So the idea is when I wanna send this packet, so my IP, I know, so what do I know from host A? Oh, right before I send this packet, what do I know? Preferred. Seeing there. What, what, say it again? Same thing, same subnet. I know it's the same subnet, but how do I know that? Because what do I know? I know my IP address, what else do I know? Oh, the destination address. Yes, and the destination address, I already said it here. So I know my address, I know my subnet, and I know the destination address, right? I also know my hardware address, right? So I can use all that information to easily say, is this packet destined for my local address? Yes, we've got the subnet of my subnet versus the destination IP address. If that's good, then that's good. But in order to send that packet, I can't just send out an IP packet. I've gotta encapsulate it in the lower levels, right? So eventually we'll see the process. I will need to basically encapsulate a link layer packet from my hardware address, 0945FA072223 to B's hardware address. And I'm going to have to encapsulate that packet in there. Now, and we'll get to exactly how we go about that because we have to, as we said, we need to discover and figure out what that hardware address is. So an Ethernet frame is much simpler. Ethernet frame is as the destination source, and these are going to be bytes. That's the only thing that makes sense. Yeah, that's right, six bytes. Six bytes destination, six bytes source, a type of two bytes. And then depending on what that type is, we'll say what's here. So type of this is an IP datagram, a type of hex 806 is going to be an ARP packet and a reverse ARP packet, which we'll see in a second. So yeah, we'll be, okay. So interesting thing here. So the maximum size of an Ethernet frame is 1500 bytes, how does this compare with IP? How, what was the max size of an IP datagram? Yeah, 65,000 bytes, but Ethernet can only set 1500 bytes, seems like a problem, right? So there needs to be some kind of mechanism to deal with that. So ARP, ARP is a super important protocol, one of, because this actually comes up just being a lot of security, and the really important protocols are the ones that communicate between abstraction layers. So the idea is we're host A, we know our IP address, we know our hardware address, we know our MAC address, we know the destination's IP address, so we don't know the destination's MAC address, right? So there needs to be some protocol, some way for us to translate from the IP address to the MAC address. And so that's what ARP is, you can think of ARP as a protocol that maps an IP address to a physical, a link layer address, so that we can actually use it in direct delivery. So before, which is actually kind of crazy when you think about it, right? Before we can even send out that packet even to a machine on our local network, we need to do some kind of protocol and some kind of communication to figure out who has this IP address on our network. We'll turn this class over. I knew I couldn't ask you, I couldn't ask you. All right, we can do this. So the idea is, right? We just talked about directly in a phase where we can't deliver a packet to a host because we don't know its hardware address, right? So the solution is actually pretty nice. You just shout to everyone on your network, who has this IP address? And if that person's listening, they will respond, hey, I'm this IP address and I am this hardware address. So basically it's gonna broadcast to everyone and then host B will answer and say, aha, I am this IP address on this and this is my hardware address. A, caches that response for a while so it doesn't have to keep doing this ARP protocol. And actually what most people do is it will send essentially its information. So instead of just shouting, who has IP address B? It says I'm IP address A at hardware address A. Who has IP address B? That way everyone else can actually cache their responses and so that way we can minimize all this communication. So an ARP message is essentially just an ethernet level message and we will, all right, so we'll go over this real quick and then we'll stop. So basically, so on Linux you can run this, it's kind of fun to do this. You can run the ARP command, ARP dash A shows you the ARP table of all the machines that your machine knows about. You can also use the ARP command to figure out to clear your ARP cache so that you now know nobody. So you can see that there's nobody here. We can ping from 100 to 10 and we can see this ARP. So this is a TCP dump output of the network traffic. So this, so you can see this hardware address at A is sending the broadcast addresses all ones. So F-F-F-F-F-F-F-F-F. An ARP who has 192.168.1.10 tell 192.168.1.1.100 the switch knows that this is a broadcast MAC So it sends up every single port that it had access to. And so that packet will go to host C and host B. C ignores it because it is not that IP address. B then gets this request and will send a reply back that says, hey, I'm 192.168.1.10, and I'm at this hardware address. And then after that, then we can see that A is pinging B. So 192.168.1.100 is pinging 192.168.1.10 With an ICMP echo request, then it gets a reply back. And if you run R-A on both machines, you'll see that they actually have each other's entries in their caches. So, and this is, and literally, we'll plug, ah, we don't need Monday doing. It's that day. It's a holiday. I mean, you can count on that while we're here. I don't know if it was open, but we'll talk about how this leads to local area network fax in a week.