 All right, success. Look at us, 10.30. We're ready to rock and roll. Both projectors blazing. Good to go. I'll take like a minute for any questions. So I've created assignment two. It will be released on Friday. So I'll have to create the test cases, make them edvious, and get my TAs to review them so they're not too edvious. We'll see that. So yeah, it'll be released on Friday. It'll be two week assignment, just like before. We can talk about it Friday. Any other questions, class related things? I'll decide on them in turn time soon. And I will post it on the mailing list and on the class website. Any questions on networking? Anything we've covered so far? Let's get started. So now that we've moved on from, we're talking about networks, right? We've seen all the different ways that networks can be insecure, and how as an attacker, we can influence, using our low level knowledge of networking protocols, right? We can influence the delivery of packets. We can spoof and send data or information as if it came from somebody else, right? We can sniff the packets, try to sniff data. We can hijack things. So now we're going to move on to the things that are actually generating the traffic, right? So it's not, you know, networks don't exist in an isolation, right? They exist because applications want to use them to communicate with each other. Applications at a high level? So applications, so they can provide services, right? Thinking about applications very abstractly. So what kind of, like, how could can applications provide services? Think about all that different applications you're running right now on your computer. All notate apps, I assume. Where's the next apps that you run? Applications. Interface with, hey, where's my examples? I'm not a trick question, yeah. Is it user interface on the back end? Yeah, it could be like a user interface, right? I could show you something. It could be something running locally on your machine, right? Which means that it's, you know, word processing or you're the finder on the Mac or explorer on Windows, right? Something to manage files, all kinds of stuff, right? These are all applications that are running locally, right, on your device or system itself, right? So it would be the opposite of local applications. Remote applications, right? Something that's on somebody else's server. So what are some examples here of things that you interact with constantly? SSH constantly, it's not like that. Facebook, maybe for the rest of us, right? That Facebook application, right, does not, the database of all, whatever, how many billions of friends, right, is not resting on your computer, right? That's on some Facebook server and you access that remotely over the network using port 80 or 443, right, to do HTTPS. But either way, the application is really running on their server, right? What are some other types of applications? Remote applications. What was it? Web services, yeah, a whole host of web services, right? Your phone even, the applications on your phone, right? A lot of them actually use a backend website that they communicate to, right? What else? Games, yeah, games, right? You have the client running on your local machine and you have a server running somewhere else if it's a multiplayer game. It could be it's not a server and you're actually peer-to-peer connected with everybody else in the game and you're trying to decide what's going on. We're at like DNS, right? You don't actually have a DNS square, you make a request to a DNS server. Right now, it's connected to ASU network, that'll be one run by ASU. And then that job of that server is to serve your request and to go out and find the DNS entry and then give your response back. Okay, so, right, so we think about applications, right? So I, right here, we're taking the mind frame. Eventually we're trying to break applications, right? We want to break applications just like we broke the network, right? We tried to do things in the networks that we weren't supposed to be able to do. Listen to packets that weren't meant for us. Inject data into a string that wasn't between us, right? So what the influence is, the behavior of an application. So I like to think about like an application as kind of this, yeah, it's a very high little thing. So what are all of the possible inputs that influence the behavior and the execution of that application? What's the big one? The user input is one, but few before that. I think that application know what to do. Operating system is another one. The code. Code, yeah, that application is code, right? It's nothing without the code, right? So it has some code. You, the user can give user input. It's running on a certain operating system that provides services. What are some other things? Is it just the code itself, the code of the app? What was that? Data. Data, right? Yeah, so the application, it could be data in the form of stored photos for a photo browser, whatever application, or it could be configuration files, right? So the app can behave completely differently depending on what configuration files are there. You've actually seen how SSH can change, right? Depending on the configuration of the authorized key file and the known host file, right? You can actually, I hope, part of the reason why you looked at the authorized key file that you saw, but it's actually really complicated and you can do a lot of crazy things. There's a lot of options you can do there besides just give this person access. Right, so yeah, kind of generally, we can broadly think about this, like, okay, the behavior of the application depends on the code, right? The data that's being processed in the input and the environment that the application is being run in, right? So these type of things can all influence the application. So if we want to try to attack an application, what types of things there, I think there are, I really hope we did talk about this, I'm pretty sure we did. What are the three things that we want to try and compromise when we talk about secure security? Yeah. Confidentiality? Confidentiality, just one, okay. Confidentiality, integrity, availability, yeah. So how can we do that though? Generally, right, what are our options? Right, in a sense, we're trying to influence the behavior of this application, right? To violate one of these three principles. So we're trying to either trick the application or force the application to somehow execute some behaviors that make it violate either confidentiality, integrity, or availability. Right, these are the core things that we wanted to. So if we think about a model of the application, right? So this is what I like to think about, like, okay, so we have an application, right? And it's just kind of this nebulous blob of things, right, behaviors, right? But that's kind of contained within an environment, right? So there's some environment here. So what does that application typically run on top of? Are applications just executing on a processor just willy-nilly? Yeah, the OS, right? So the OS provides a lot of abstraction to the application so that it doesn't need to know, hey, this is actually an SSD you're writing to instead of a standard hard drive. So this means you need to do ware leveling and all this stuff, right? So the operating system provides this abstraction layer. And then if our application wants to talk to, you know, other machines, what else is it going to mean? Which we saw, we looked at the network, right? So it's got a talk somewhere. What are some key abstractions or features that operating systems provide? I can't talk about one file system, right, or some others. Hardware drivers. What was it? Hardware drivers. Hardware drivers, yeah. So it extracts the hardware. What's the other stuff? IO drivers. IO drivers, yeah. All kinds of drivers. Video card drivers. It's all I'm doing, driving. RAM? Yeah, so it can be a little more specific. It's a little more abstract, but yeah. Okay, generally, right, so yeah, so not just operating system doesn't just provide us with the memory of the RAM, right, but it segments it so that each process sees a different part of memory, right? So that way, we're not all in the same address space and just can overwrite each other. So it provides some way that I can think of, like, separating processes, right? So that, you know, the whole idea here is, hey, it doesn't matter what crappy application you're running, if my application's well written, you shouldn't be able to crash my app. Is this always the case? Unfortunately not. You can actually break an Android phone very easily with a simple fork bump, like a C program that just forks and you can run that and it will just take up all the process on your phone and break your phone and you have to, like, hard to get it back to normal. Okay, and then so, but then, so where do we fit into this picture? So we're remote, where are we kind of in this picture? Is that on the network? Yeah, through the network, we're off the left somewhere, right? Our packets are coming in over IP, GCP, UDP, one of those, right, coming in. We've seen how all of that works. What if we're local? How does our input get to the application? Having the access of the system, except on... What kind of access? The login access and off being the same subnet. So we're gonna ignore, so we'll think about local just as the first one, right? So on the same subnet, we'd still consider that to be network access, right? So yeah, there's some way we're gonna abstract it here is the terminal, right? So you're at the terminal, if you're SSH, SSH gives you a way to remote in, essentially, and get the terminal, right? Or you're physically at the machine, right? And you can interact with the process. Terminal here, we're using kind of very vague, it could be a GUI, it could be whatever, I mean, that really doesn't matter. As long as you're able to get input to the program, that's an important thing. So your input is mediated through the operating system. So the operating system, whenever you, you're at the keyboard, every time you type something, a hardware interrupt happens, and the operating system gets signaled and then it sends that command. It tries to figure out which process to just go to, and then it sends that command up there so we know how input's being read. So what are all the things that the operating system, the application can touch, and what does it go through? I should say, wait, first, before we talk about that, is this all the layers? What are some that are missing? I don't see hardware there. Hardware? The kernel is in the OS layer. Yeah. Right, so yeah, the OS has, so there's the kernel and then there's a bunch of different drivers to do all these different things, and the OS itself is split up into a bunch of layers. Right, so yeah, the very low layer of the hardware, right, the hardware's not in here. Permissions? Is that in the case? Yeah. User interface, we'll throw user interface under terminal, just say that it's all input. We'll say permissions are kind of in the OS. Is there anything below between the OS and the hardware? Really good. What was it? Really good. Again, you get to say it louder. Really good. Middleware. Yeah, there could be some kind of middleware, usually not between the OS and the hardware, but maybe between us and the OS, there could be libraries we're using or other services. Absolutely. And we could share that with other processes. Or hypervisors, right? Our OS, there's nothing to guarantee is that the operating system is actually executing on the bare metal, right? We could be running on Zen, and Zen is managing multiple operating systems that are all executing on one hardware, right? But anyways, we're just gonna keep this at this abstract level, because to the application, all the application sees is the operating system, right? What the operating system sees is the hardware. Whether there's other stuff in between there, who knows? This could actually be an application that's written. I mean, you get kind of crazy where the application is a Windows application that thinks it's talking to a Windows operating system, but really there's a compatibility in the middleware or layer in here like line, which is translating between Windows system calls to Linux system calls. Actually, the application's running on a Linux machine, but all it sees is Windows. Anyways, okay. So the picture's not complete, but we're kind of okay with that, right? So then where are all the places that data can be in this, like what can our app communicate with in this diagram? Where can data, so we talk generally, right? An application is influenced by its code, which is gonna be inside this blue circle, right? And it's gonna be influenced by the environment, which we're just saying is kind of outside of that. Where's the data live? Let's go over here. Stack. Say that again? Stack. Stack. Little, so yeah, inside the application, there will be data. Yeah, what about in the diagram? So yes? Yeah, the file system, right? It could be reading files from our file system. What else? The network, yeah, it could go make requests, right? If it tries to resolve any DNS entries, it's gonna make a network request. If it makes any web requests, HTTP requests. What else? Anything else? Could be from us, the user, right? We're kind of seeing that we can get data into the system. Yeah. Memory and the registers. Memory and the registers, yeah, those I'd say are all in the blue circle, the applications environment in some way. But where did that come from for you to get there, right? That's kind of the trick. What about that other completely disconnected circle from the diagram? So most OSs have a way to do inter-process communication, so it actually could be memory mapping, so maybe that, right? You could map the same memory region so that way one process writes to it, the other process can read from it. But in essence, that happens through the operating system, right? So the operating system is mediating all communication between processes. So, why is this important from a security perspective to know this, right? It seems pretty simple and easy, right? I mean, I hope I'm not blowing your minds here with the architecture of an application, right? So why are we talking about it? Let's go back to our goal, right? We want to make the application do something it's not supposed to do. So what influence is what the application does? The code, the data, and what else? The environment, right? So those are the three ways we could potentially attack the application. So if we'll actually look at exactly how the code is written and done, right? If we can arbitrarily change the code of the application, then we can kind of do whatever we want. If we can modify this environment circle, right? Then we could maybe get the application to do something it's not supposed to do. But this data, right? Getting data into the program, it's really important to really understand what are all possible ways that data can get into this program. And what do I, as an attacker, have the capabilities to modify, transmit, or influence, right? Because if I can change that data to get the application to do something that it's not supposed to, then that's a security vulnerability, right? So this is why we look at all these things to see, maybe the application's great, maybe it's 100% bulletproof, but maybe it relies on data from this process. And what if I can control that process? Now I can control that data that goes into the system, right? Or what if we talked about networking attacks, right? Can I inject some data into this networking stream? Is it trusting an IP from another host, right? That I can impersonate? These are all kinds of things. And the file system, right? It's reading from files from the file system. Now we talked about permissions. What are the permissions of those files? Can I mess with those files to get it to do something like that? So it all comes, so the high level we're talking about here is basically application and vulnerability analysis. So we're trying to understand how do we identify vulnerabilities in an application? And so this is kind of an important clause there at the end, right? As deployed in a specific operational environment, right? So what? So kind of, let's try to talk about it and think about it. Like abstractly, what kinds of ways can there be problems in an application? At a very high level, before any code is written, can there be a vulnerability? Compatibility. What was that? Compatibility with the environment. Compatibility with the environment? Yes, we're gonna get to that. It's a little bit more low level, but yeah. Design of the environment. What was that? And the design could be vulnerable, right? It could, the design just like, oh we saw for instance in the Morris worm, right? So I remember what it used, the SMTP vulnerability that it used. It was a debug option that automatically executed the given command on the machine. This is the back door that you wrote. You wrote a back door that does this. This was intended functionality in the SMTP client. This is design level problem, right? That's not an implementation problem. This is straight up, that design was broken from the start. It doesn't matter where you deploy that or how you do it, that's just a straight wrong, right? And you can tell that before any code is even written. You're like, oh you want anybody to execute commands in your computer? Probably not a great idea. Right, so then what about, okay, let's say the design is good. Does that mean the system is secure and no vulnerabilities? No, so what could be a problem then? Oh, yeah, cool, yeah. Yeah, right, so implementation, right? So how did they make a mistake, right? Maybe the design says, hey, only administrators should be able to execute these commands from a remote location. But it turns out because of the way they coded it, right? That anybody can do that, right? So that's not really design level, that's more implementation level. Well, let's get into this, we're talking about compatibility, right? So what is, so if we go lower let's say the design's perfect, implementation's beautiful, is it still secure? The OS itself could have vulnerabilities that can let someone in and take control of your process. Ooh, okay, that's tricky. Say we're not gonna include that in this model, but it is definitely something to think of in general, right? So that's actually kind of why that layer diagram is great, because not only could they compromise your operating system, what if they compromise your hypervisor, what if they compromise your hardware all the way to the very bottom, what if they compromise the firmware that's running your hardware, right? There's all these different layers below you, because yeah, as an application, you just trust the operating system. The operating system has full control, absolutely. So let's say the OS is secure, all the bottom layers are secure, design's fine, the implementation's fine. Bad data? Bad data, boundary conditions, no, the implementation's fine though. Boundary conditions, I've solved, I've fixed all boundary conditions. I handle all that data. What was that? Yeah, maybe, right? What about the environment that this perfect application is executing in, right? What if I, so for instance, PHP has this really famous configuration option called magic quotes, which whenever any data is in your PHP application, if there's any double quotes or single quotes, it automatically puts a slash in. Anyways, we'll get to it eventually, but it prevents the SQL injection vulnerabilities. Only if your application is running on a PHP host that supports this application, that supports this setting, they change that in one of the PHP versions. So you could take an application that's 100% secure, right, take it from one operating system or one server, put it on another one, and because of the configurations of PHP, your application is now vulnerable, right? Or what about if you deploy a super secure application and you have an administrator account whose password is what would be the first thing you would guess? One, two, three, one, wait. Admin, admin would be the first one, password would be up there, right? And the admin, admin account is active, right? Is that secure? No, and it's an employment problem, right? Because nobody changed that default password. So design vulnerabilities are actually very tricky to find. They're kind of the next frontier of automated vulnerability analysis, because the idea is these are flaws in the logic of the application, right? It's like the logic is wrong, but the code is correctly implementing the wrong logic, right, so how do you tell what is the wrong logic when the code is doing stuff that is? The code says it's supposed to do, but by design, it shouldn't be doing that from a security perspective, right? So these are very difficult because it depends on the exact functionality of the application, right? This could be things like lack of authentication or authorization checks. It could be erroneous trust assumptions, right? Like maybe when we saw being able to log in to a computer from an arbitrary IP address is probably not the best idea in the world. Because anybody on that subnet could impersonate that machine and log in. What would be some other ones? What are some other design flaws that maybe you've heard about or can think about in any application? Very big, very broad. Microsoft Windows, like you have- All of Microsoft Windows is a design flaw? Yeah, that is a huge- They just work for Microsoft. Okay, but that is a huge, you know, once I saw it in that video that there is an option for disabled people to, you know, use these sticky keys, right? So if you replace a sticky keys file with a command prompt in the system32 folder by pressing the sticky keys outside your login page, you can access command prompt and log into it. That's tricky. Yeah, so that'd be like using an, like a feature in a way that it's unintended, right? So yeah, it's probably the design there is a problem. They should be checking maybe the format of the sexy games, like, frankly. Yeah, so it's actually a lot of instances of this. Yeah, just flaws in the overall design. So they're incredibly difficult to identify automatically because you need to not only identify what the app does, but you also have to try to infer what should the app do, which is very difficult. And it's completely specific to every application. So for instance, one of the things that I like to, one of the ideas I like to convey is to try to get people to understand that behavior is not necessarily vulnerability by itself, right? So if I said in a web app, dare use this, maybe you can stop me. In a web application, you can, anybody can change the content of a page. Is that a vulnerability? So the answer is it depends, right? It depends. Is it cnn.com? That anybody can change the content of that page? Right, that's a clear security vulnerability, right? The security requirements for cnn.com say that only editors and journalists can change the content of that page. It can't be any arbitrary people, right? But then what about Wikipedia? This is the functionality of Wikipedia. Literally anybody can change at any page on Wikipedia. You can go now, you can change any page. It's not a security vulnerability, it's intended functionality. So how are you gonna automatically check for this type of security flaw? It's hard to tell. In both cases, there's not checks, right? The code could be identical, but in one case it's intended, in the other case it's not. Okay, there's also a whole class of problems called the confused deputy problem, which is in essence when a malicious application can be tricked into doing something on your behalf. So for instance, have this super beautifully separated firewall application, like I'm running this application, let's say it's gonna be malicious, and but I say, hey application, you can't make any HTTP requests. I'm locking you off, you can't make any HTTP requests. But I have a process on my system that accepts inter-processed communication requests and will go make an HTTP request and return the response. So now, this application that I wanted to never make an HTTP request, it never makes one. It just makes an inter-processed communication to me and then I make that request. It's actually a really big problem in Android, because the Android system works on intents, so you can send an intent to any other app, right? And so maybe you don't have the permission to do something, but if that's your phone, okay. I remember that being louder, maybe I'm getting it now. Yeah, so the idea with these Android apps, right? It's like, okay, maybe I as my app, I don't have the permission to read all your photos, right? But does there exist an app on your system that when it accepts an intent, will get a photo and return it back to that service, right? It's actually very tricky to do this 100% correctly. So in this case, I have this confused deputy problem. Well, it's a test, don't worry, a test. Okay, so design vulnerabilities are kind of at the high level, right? They're problems with the design. And then below that, right, we have these implementation level vulnerabilities. So this is when we say, okay, so is the application coded correctly, right? What does it do on these boundary cases or these bad inputs that we said, right? So is it, I was gonna ask which one's more likely. I'm not sure that's an easy question to answer. Do we have, still have implementation vulnerabilities? Yes, why? Yeah, we're humans, right? We make mistakes. We still haven't figured out exactly how to write bug-free code. Can't write bug-free code. We'll never be able to write vulnerability-free code, right? And so we're humans and we code things and they're not able to correctly handle unexpected events, test, you all perform badly, right? So what kind of, what could these unexpected events be in the context of what we're talking about with the three, with the three ways we can influence an application's behavior? We talked about something, you could reuse those answers. What are these unexpected events? Super big term. Somebody's phone ringing and doing a test emergency and it causes vulnerability. Yeah, but what makes it, what can make it crash? An unexpected condition or something. Yeah, so maybe the input is weird. Some unexpected input, that wasn't very good. Exactly. Any kind of unexpected input? Different environment, it's being deployed to maybe? Yeah, it could be the environment that does it. It could be that it got an exception that it wasn't planning on getting, right? If you have an exception at the wrong part of your code, maybe that changes the state of your application and now your application is in an insecure state, right? Maybe you're trying to check if this username password is valid and right before you go to set the flag that yes, or that it's invalid, right? Right before that there's an exception that occurs and so you never set the flag that this user is not a valid user. Are all applications, single threaded applications that always execute one instruction after the other? No, right? Even though that example we had for the fact that applications is incredibly simple, there's still a ton of complexity there, right? We can make network requests, right? We can read from the file system. We can talk to other processes. We can have multiple threads in our application. So really, what if for most executions the order of events are safe? But there's some unexpected way that these events can be ordered such that it causes security vulnerability. Very difficult to detect. Yes. Could be that the output of our program is unfiltered and causes problems, right? It could be that the output of our program is the input to another program, right? Which could then be used in the output of another program which eventually causes a crash or some kind of problem. Right? It's actually kind of a hard one, but it comes up in the context of cross-site scripting. All kinds of these, these are all kinds of things, these unexpected events where the programmer didn't think about this case or they didn't anticipate something. Yeah. That locks in the database throughout the actions. What about it, is that again? That locks. Ah, yeah, so exactly. So that could be like an availability attack, right? So, yeah, and that kind of could be this unexpected interleaving of events, right? So it's like the database, the database deadbox or maybe your application deadbox because it's not handling its locks properly. Yeah, all these kinds of things can trigger a vulnerability if you're able to get it to somehow compromise the availability integrity or confidentiality. The tool or technology that you're using for implementation might have an inherent vulnerability by itself. Yes. Exactly, so let's think about that. Yes and no, it all kind of depends. It depends on kind of where you define application, right? That bubble. If it's, for instance, like there's this recent vulnerability in the DNS resolver in libc that causes a buffer overflow, it affects SSH and all these other protocols. So it's this core library but it's used by so many applications. So if you think about like the attack service of your application, the attack service of your application, which is I think about as like, what are all the places that people can attack you, right? You have just the code that you wrote, but then there's any code that your code depends on, then any libraries that you use, right? And it grows and grows. And then you gotta think about operating system if you want to be really secure, all that kind of stuff. So yeah, I forgot what the question was but I hope that answered it, kind of. It's like I was gonna circle back around, reference it, my camera over talking about it. It's good though. Okay. So then design implementation, then we talked about, so there's also deployment vulnerabilities, right? So a completely secure app, put in an insecure environment or misconfigured way can compromise the security, right? So for instance, let's say your app is meant and tested to be installed as a normal user on Windows, right? So that's the environment supposed to be run in, but it gets installed as an administrator privileges, which it wasn't expecting. It shouldn't be installed that way, but for whatever reason it is, right? So now because of that it's insecure. It could be, yeah, it could be that the application is installed and it's supposed to be that a certain file is read-only, right? But it turns out for operating system misconfigurations and that file is actually writable. I'll tell a kind of personal story. Like one of the first servers, like actual servers, I was renting, I think it was one of those five dollar a month servers. I couldn't SSH to the machines, my website was down. So I wrote this like, you know, ticket. I was like, I don't understand. I can ping it. It seems up, but I can't SSH to the machine. Can you help me figure out what's going on? And they reply back with, oh, okay, yeah, your machine is up, but it seems that the permissions on your authorized key file and in certain SSH directories were 777, which means readable, writable, and executable by everyone on the system. And so if SSH detects this insecure configuration, it won't allow you to enter the system. And I was like, oh yeah, there was that time that I couldn't get things to work. So I just did a CH mod 777 on everything. And it worked. I've learned sense, but I was very new. And I was like, ah, it doesn't work. Just make everything readable and writable. That'll solve all the problems. Which is how you can have security problems, right? Is, especially if you have maybe development and operations separated, right? So the app developers just pass the app to deployment and they're supposed to deploy it on the server. Maybe they don't realize that this file has to be re-old and otherwise the entire security of the application can be compromised. Yeah, we talked about easy to guess default credentials, right, admin and admin. All these kinds of stuff. And the host more. So the idea is, the way you can kind of tell, right, is if the application was deployed successfully, it would not have this vulnerability, right? Whereas an implementation, doesn't matter how you deploy it, it's still gonna have that vulnerability. Modulo and deployment kind of mitigation, exploit mitigation techniques, but that's a whole other issue. And the design, right? Design is just, it's always gonna be bad. It doesn't matter how perfectly you code. So let's talk about the difference between a remote and a local attacker, right? So what are the differences from our diagram? Think about that diagram, right? The app terminal with the local user and the network. I mean, the size one is local and one is remote, right? Those are the inherent differences. What does it mean for vulnerabilities, for security? Direct injection of the attack and indirect injection of the attack. What's the difference? Yeah, so the big difference, right, is exactly that. So if we wanna do a remote attack, any, the only way from that diagram to get data into and influence the application, right, is through the network, right? You can't influence the application in any other way, right, except for that network error. But if we're local, then we have a lot more options, right? Can we mess with the file system that it's reading data from? Can we mess with the process itself, fault in memory? Can we mess with any other processes that it relies on? Can we mess with any temporary files it creates, right? We have a much greater view as a local attacker. But what's the downside? Can you do this at every machine? You need to have either physical or, you know, either physical access or SSH access to the machine, right? You need to be somehow executing on that machine arbitrary code in some sense, right? So you need to either have an account or compromise another application to get control there, right? And the idea is once you're on there, right, well, you can already execute code on the server, right? You're there typing commands in, you have an account, you can type stuff in, right? You can run things. So really what you're looking for is to get more privileges, right? Like you wanna take over my account or you wanna take over the administrator's accounts, you have full control over the system. So usually what you're looking for as a local attack is a privilege escalation to try to get to a higher privilege level. In general, they're easier to perform. Why would that be? Other knowledge of the environment? Yes, okay, what else? How you can, you're on the machine, you can see things, you can maybe look at the processes. You actually know the entire environment, right? So you know exactly, is it 64 or 32-bit system, right? What library I live to see is installed? What version of boots are they running, right? What's the kernel version number? All those things you have access to and can understand, whereas if you're remote, all you're doing is talking to that machine on that port, right? So often local attacks can be easier. So remote attacks, right? So you can have unauthenticated remote attacks, right? So unauthenticated just means that the application doesn't know who I am. And remote means I'm coming from somewhere else. So, I don't know, is that better or more severe? What was that? More severe. In what sense, why? Because you can write these things up, but you don't need to go up. Is this terrifying? So they can just send information to your process, right? You have no idea who they are, they don't have an account in your system, and then they're able to remotely exploit that to, let's say, get an account where they establish themselves, like completely control that process, right? And unauthenticated, which means they don't have to use any password in your system. Literally anybody who can talk to that application on that port can take over that process, right? Where as a local attack, you need to have local access to the system, right? So in some sense, these things can be staged. And the idea is, I'm not trying to, I mean, I am trying to escalate my privileges, usually from somebody who's remote on the machine to now something local. So I want to try to get the privileges of that vulnerable application, right? If I can do that, then I can do a lot of cool stuff. So in general, these are compared to local attacks, they're more difficult to perform because you don't know what's the operating system, what's the security mechanisms, what's the version of C, all this kind of stuff. You may not even know the architecture, armor x86 or MIPS, right? Could be, it's just a network application, you don't know. So this is why we looked at things like OS fingerprinting from the network level, right? You can tell, now you have information that can help you in successfully launching a remote attack. Cool, so let's talk about the high level, the life of an application, right? So you want to write an application, what do you do first? Very high level. Design, design, design it, get some requirements, write it, write it in ones and zeros, sure. Sure, it would be fun. Okay, no, you first write it in like a higher level language, right, so you write it in like, I don't know, even C, C++, Java, Python, whatever, you write it in the language. The application is translated or compiled right to some kind of executable form saved into a file. It may be that it could be, what's the difference between interpretation and compilation? Interpretation is line by line in what sense? Whenever there's an edge in stores. Yes, but what it's also doing is it's going, what is it doing is it's going through line by line. That's the question. What is it doing? Checking, checking. Trying to check errors, it is doing all those things, it's also doing something else, and that's the key difference between interpretation and compilation, right? When you compile something, you're also going through the whole program, right, line by line, looking for syntax errors. Yes, and what is interpretation doing? Yes, executes, yeah, that's the key difference, right? Interpretation goes through the program as executing the behavior of that program, right? Whereas compilation takes the program and translates it into some other form, right? Machine code, whatever, that it can later be executed. Yeah, so those are the key differences. And these differences can be muddled, right? So like a Java program is a Java application. So do you interpret a Java file? No, right? Yeah, you compile it to a class file, which is specific Java byte code. That Java byte code can't run on the machine directly. So you use an interpreter that interprets that Java byte code and then performs the actual executions, right? Whereas when you run a C program, you compile it to, we'll see in a second, an ELF file that the operating system knows how to load it to memory and actually start executing. So once you've written it, it's compiled, translated, saved to a file somewhere, right? You load it into memory, you execute it, and then the application terminates. So at a high level, we're going to, we're kind of going to ignore a little bit the interpretation compilation question in some sense. I mean, we'll look at interpretation, right, for a little bit, but we're going to focus on compilation and the idea is, well, every interpreter, like somewhere, some binary code's got to be executing, right? So like Java, the Java virtual machine is written in C or C++, right? And it's running actual machine code, and it's even dynamically translating the Java byte code to machine code on the fly, right? So we just talked about this, right? The program's passed to an interpreter, it may be translated into some intermediate representation. For instance, like Python will do an interpretation, but it'll also create a PYC file, right, that has Python byte code, so that next time it doesn't have to do the whole interpretation process, it can just do that byte code. And the important thing is each instruction is parsed and executed as it's going through this file, right? So it's executing it as a interpreter. And what this allows, this allows actually a lot of flexibility, a lot of really cool features from interpreted language. So what does this mean generate and execute code dynamically? Once it's done, then put up the first line, it can change, and the execution can act up. Can you do that with the regular program, too? Okay, once it is compiled, then it's like, all you need to do is like, as in running the string. Yeah, so you can actually take a string, right, and interpret data, some string, and interpret that as code, right, and just start executing it, right? Because you have an interpreter, right? So a lot of these interpreted languages allow the programmer to say, hey, evaluate this string, take this string, interpret it as if it was a line of code in this program right here, and execute it, right away. So Python, batches, JavaScript. This is fully and terribly evil. We'll look at why later, right? At a high level, you're thinking about, okay, I wanna have this program execute arbitrary code. If I control this string, I can literally make the program execute whatever code I want. All right, which is exactly what we want. All right, we'll stop here, and then we'll look at compilation, and we'll get into the nitty gritty of what objects and binaries look like on x86.