 All right, welcome everyone, have a good one day, let's see, good news, I, with any way that I could buy a Mootoo VM, I had them reboot in the single user mode so I could edit the EPC hazard file itself. Apparently the Mootoo default login manager does not allow you to login as root and so when I saw that my user ID had that ID zero, it caused it to not log to the login. So lesson learned, don't decide to start editing important system files in the middle of a class demo. That's all done, so let's keep going because I want to get through some more abilities today so we get to some of the meat of what we're talking about here with applications security. So, what was important about setUID? What is setUID? Yes, it's specifically correct. You think about what exactly is it, it is a bit on file permissions that says when somebody executes this program, execute this program with the permissions of the user who owns the file, not the user who's executing the file. How many setUIDs are there? There's a setUserID bit and a setGroupID bit, so there's two different types of bits there. What are the other permission bits on files? And how many within each user owner group? Three. Yeah, so three permissions, three write execute for user owner group. Right now we've only been talking about files, so these permissions are very straightforward. You can read the file, write to the file, or execute the file if you aren't either the owner of that file, the same as the group who owns that file, or you are anyone else. There's actually a hole where you can get into all the different complications of what these things mean for directories, but we're not going to go too much into that, or actually not at all. So the important thing for us, and so why do we care about setUID binaries? Yeah, so they're fundamentally executing, when we execute a setUID binary, it's executing as the user that owns that binary. So we saw the chroot binary is executing as user, sorry, executing as user root, which means that if we're able to exploit some vulnerability in that application, then we can get that program to execute and do things as if we were root, and therefore effectively elevating our privileges to become root. Is our only goal to ever take over the root account? Yeah, so it's a good goal, right? You're the administrator of the system. You can then look at every single file on that system from every single user. You can do anything that you want to that system. But maybe you don't need to do that, right? Maybe I'm just trying to steal your files in particular. So maybe there's a way I can try to break into your account, as opposed to try to just bring in the root account again and everywhere else. So it's always important to try to contextualize what are your goals, or what is the attacker's goals, what are they actually trying to accomplish. So digging in a little bit more into the setUID behavior. So there are a series of system calls that we're going to interact with this. One is the setUID system call, which sets the... the residual user ID, the effective user ID, and the saved user ID to the whatever is passed as the primer here. And this is only allowed if the effective user ID is zero, which means we're running a root, or if the user ID is equal to the effective user ID. So you can try to change your effective user ID to the user that you currently are. I'm actually going to... There's all kinds of ways to do it, especially set different ones versus different other ones. But fundamentally, the core key idea here is we want to be very careful about setUID binaries. And when we get into assignment three, you want to look at this and understand how setUID plays a role in what you're trying to do for that assignment. Okay, so now we're going to get into more of the specifics. Okay, how do we start to break applications? So what were some of the phases that we talked about? How would you go about breaking a system in general? Recon. Yeah, before you... Well, so you need access. If you can't access it, it's hard to break into it. Right? But we need to get... We need to perform through reconnaissance so that we can understand what the system does. So part of doing that with an application is trying to understand, okay, what does the code of this application actually do? Right? And remember, we talked about the programs likely written in, let's say, a high-level language like C or C++, which has been taken by a compiler compiled down to some x86 assembly code, which is then compiled down to a machine code that actually is xqd. So the idea is, hey, we don't want to just try to look at and analyze the ones and zeros of the program itself. Right? We want to look at some more semantic meaning behind the programs. So disassembly is this whole idea. You can think about it as the opposite of assembly. Right? Assembly takes... Wow. Remember the way you look at it. Assembly takes an assembly text file and outputs machine readable code, ones and zeros. A disassembler takes machine readable code and turns it into text-based assembly. So it's something for you to understand. The way they do things, there are different types of disassemblers. At a high level, some of them, like object dump, will just try to disassemble everything linearly. So why is this difficult? Why might this be difficult? What type of instructions that architecture is x86? It is 32 bit. For one, I mean the instructions are variable size, so that might affect your... Yeah, so the problem is we just have a series of bytes and we're trying to move backwards to see what are the corresponding assembly instructions for these bytes. Right? If you have a language like MIPS, which has fixed instructions that architecture, so every instruction, actually I don't know what it is, but every instruction is a certain number of bytes and there are only that many bytes. Right? With x86, you can have instructions that are one byte or instructions that are actually, I don't know what the limit is. I'm saying you can have five, six, seven, eight bytes. Right? So if I just give you a bunch of bytes and I say, turn this back into assembly code, what do you have to know to be able to do that? What's the instruction? And you need to know where to start, right? Because if you start at the very first byte, that may decode into an instruction that's two bytes long and that may decode into an instruction that's five bytes long, whereas if you start at the second byte, now you have completely different instructions. Right? And that would be unique disassembly for every single byte you can possibly start with. So this is why it's very important. So look at your disassemblers, start at the main entry of the function and just start disassembling. Recursive disassemblers try to be a little bit smarter so they will see, okay, start disassembling here. Oh, and this would jump to some other part or a call to a function. So now I know that's the start of some new codes that should start disassembling from there. Honestly, when you're just trying to disassemble a binary object dump is totally fine. You won't find any weird offset bytes. And so I pretty much always use object dump when I'm doing that or some other tools that we'll talk about. There are other tools that you can use for disassembly that can make working with the assembly language and try to understand the binary a little bit easier. Radoware is a cool program analysis tool. So it actually has a whole library that you can call from Python to do cool disassembly things of binaries. It has some reversing capabilities and some more ability analysis. It supports scripting, so maybe that's the coolest part. You can incorporate this as a student working on a project that involves analyzing the binary and trying to automatically draw what the stack usage was like using Radoware. So stepping through the program and looking at that. And it's free, which is always nice. Just like object dump is free. Ida Pro is on the complete other side of the spectrum. So Ida Pro is the industry standard state-of-the-art tool for binary reversing. You can get it here. It does not only binary disassembly, so it also shows you in this kind of nice view of branches. So each branch instruction you can see. So it's a little bit more of the graph of the program flow. It also, like a lot of these, you can put comments in your code to kind of add your going through it and see what's going on. It also supports decompilation. So decompilation is the opposite of compilation. So it takes an assembly file and tries to generate C code from that. And it actually has a lot of you can actually integrate it into debuggers. So you can see exactly what's going on in the memory as you're looking at the code with all your notifications. It is a commercial product that is incredibly expensive. And when I'm talking about incredibly expensive, I'm talking, I believe if I remember, one, so just, I didn't throw it itself, was I believe three or four thousand dollars. Is that right? And then, and that's for one, I don't know, that was I think X64. So that handled a lot of different computer architectures that you could analyze. But X-ray decompiler was I think on the order of four thousand dollars per language that you wanted to decompile so for instruction sets. So X-86 was four thousand. X-8664 was four thousand. ARM is more or two. And I think different versions of ARM. It's also, so they do have a limited reduced version that's available for free if you want to check it out. I will say it's also really pain to use. But it is, if you're looking for a nice user-friendly program, IDAPRO is not that program at all. There's even Chris Eagle at the Naval Post Graduate School wrote a book on how to use IDAPRO basically. It's the manual that IDAPRO does not have of how to actually use it correctly. So to be honest, I've used IDAPRO in the past. It's fine. I actually switched to about a year ago. I switched to this tool called Hopper. So I still use Hopper because it still works really well. I use Hopper. Hopper is nice. It's a disassembler that supports. That's a pretty cool analysis. I think if it's still the case you actually can access the Hopper website from ASU's network. And I've already been to this fact and they said well it's on a, the IP is actually blacklisted by ASU, apparently because it's posted on a shared hosting site. And so I knew I was the author of this and he was like well I can't move sites or anything so he's just leaving it. To be honest, this is at home. I don't think it will work on the ASU network. It actually has a decompiler. It is a commercial product as well but it costs $100 if you want the full version which compared to $10,000 this is a lot. Again, plus it has a free version that has I think a half hour restriction so you can use it up to a half an hour and then it'll shut down so that's also pretty good. And I believe it runs on Linux as Mac. I don't know if it runs on Windows maybe. It does or does not. It does not. Is it Mac only though? Well, pretty nice though. Okay, so these are kind of tools. Right, so these are tools you can use to try to understand what the program is trying to do. But there's no tool that's going to help you thinking for yourself. Even using the X-rays output. Has anybody looked at X-rays as the compilation of biaries? Yeah, some of you. It looks like a mess if you've never looked at this before because if you think about when you're looking at part three you're looking at the assembly code think about how much information is lost from that C code getting compiled down to the assembly code and now I'm trying to go backwards and trying to reconstruct the semantics of that original C program. It's actually a really difficult problem and it's actively being researched. So oftentimes because what are some of the things you lose when you compile? Names, variable names. Comments. Definitely comments. Not that the comments would probably help me on personalize them. That's not our version. The flow of the control like how it suits you. Yeah, so the control flow may be different, right? The compiler is totally free to invert branches if it thinks it'll be faster for compilation, right? Even loops look basically like go-tos, right? There's no wild statement in X86. It's just a branch back to itself and that's how you get, you know, the difference between for loop versus while loops versus do while and a decompile it and it's not only the if it's statically compiled, yeah, it's really difficult. So there's a whole other host of techniques on how to deal with that. Basically, you take the library itself you build up little signatures of what each library function is and you kind of match those to the binary. So you know, hey, this is this library function and it's not some other code. But yeah, when you get statically linked to binaries it's really difficult. What was that? Data structures and types in general, right? Everything is just essentially 32-bit integers that are using 32-bit integer addresses, right? Or bytes that are using byte addresses. Or data structures or structs or all that kind of information is lost essentially when you compile it. So even if you try to use one of these tools and you compile it, it still looks like gibberish and you don't compile it anyways. So there's a lot that you you still have to use your brain to understand what's going on here. And you may be relying on a broken tool, right? If you try to think and plan all of your exploits and understanding of the program based on this decomposition process if it made a mistake, right? Now you've made a mistake in your understanding whereas if you look at the assembly code that's what actually executes. So any mistakes that are made with understanding, not on some other tool that you base things on. So I want to they're very cool tools but they're not a substitute for thinking and understanding what's going on. They can help you be more effective as you get better at this. But fundamentally it's you understanding things and thinking about things. So now we're going to talk about what types of attacks we can try to or another thing about it classes of vulnerabilities are common to UNIX applications so we're going to scope down from kind of all applications we're talking about very broadly to specifically applications on UNIX systems. So we may want to try to attack a network service like we talked about. How would I know that a network service is running on a given machine? Try to do a port scan of that machine, right? And we saw different techniques that we just may even want to try to attack. That's just a service. It's a network service. Maybe well let's say we're outside the server. So when you attack a service what's underneath the service? OS, right? What if I can exploit the vulnerability in the operating system? I don't even need to worry about the service. We can even think about remote attacks against a browser. We can talk about local attacks versus set UIV binaries. So for local on the machine, we have local access we can try to exploit things that way. We can try local attacks against the operating system. So really the attacks that we're going to study you want to try to think about them in terms of these things, right? What capabilities does the attacker need? Where can the attacker be in order to launch these attacks? A remote attack against the operating system is one of the most powerful things you can have. Right? Because here you don't care what's running on the system all you know is you're going to send it and exploit it. So their operating system it will exploit some vulnerability probably in a TCP ID stack or something like that and take over the system that way. Or if we're going to think of a completely different example there was the stage fright vulnerability on Android phones where you sent somebody a specially crafted video and the video would automatically start to play on their phone as soon as you got it and there's a vulnerability in the rendering engine of the video encoder and so it would exploit a vulnerability in that to automatically get onto your phone from one single text message. Still a network, you know it's an application that's running there just different types of input to get in there. So most of the times of all those categories that we're thinking about are incredibly broad. Most of the time what we're looking for is a local vulnerability in a second ID root program. Right? And why do we think this is the case? Is there an intuition behind why this might be true? The remote operating system vulnerability is one of the best. Are they the most common? Shouldn't they be more common then because they have the most reward? So you think about it, right? All of the network traffic is going through the operating system layer. Every machine that's deploying the operating system is executing the same codes. This is why on one hand it's so powerful because if I find one remote code or remote vulnerability in, let's say the latest version of Windows now we can exploit anybody's computer that's running Windows. No matter what they have installed it doesn't matter anything. And so because of this reason operating system developers started to take security more seriously and Microsoft also did that in particular in the early 2000s, they completely changed the way they developed software. So think about over time, right? Researchers focus their attention to where all the vulnerabilities could be and are most impactful. So they study the Linux IP stack to try to find the vulnerabilities there. And so instead of like every day there's a new vulnerability, it's on the order of about once a year there will be like a really bad row of vulnerability. So then what makes these local SETUID programs different? General standard for testing it on the machines? So yeah, individual programs, right? So there's not one standard way to test that. It's difficult but you can fuzz like a fuzz the CH, the change shell program, right? CHSH. Why else? You know, there's theories or thoughts. But we have valid reasons for setting the privileges locally. So it's hard to say they're both the exploits of using these, you know, valid tools. Yes, you have these tools that you need as part of your system, right? But they're not really part of your core operating system, right? They're not the TCPIP stack of Linux, right? That's where you want to go to find the really impactful vulnerability, right? And so you think about all these individual system utilities across your operating, your computer, right? Any bug in any one of those programs could cause a problem. And they may be developed by completely different groups of people at different points in time. They have a set of programs on each system that could be different and distinct from that system, right? So testing all these things can be incredibly difficult. And so this is really the split on local, parallel-descalation vulnerabilities where most of the time you're going to try to exploit a root set UID program. Rarely are you actually going to find the vulnerability in the kernel itself if you do that super cool, though. So attacking any application, right? We always want to think about, what? What's the important thing? How do we actually try to control the program's execution? Go just wave our magic wand at the thing, arrange at the other level, or higher level? How do we get it? Our inputs, right? That's the only way we could possibly hope to influence this system, right? It has to take either some input from us, read from a file that we created, read from another program that we control, right? We somehow have to get our inputs into the system. If we can't do that, how are we going to attack it? You may have to become very creative in how you send input to the system, but fundamentally that input must come from you and must be controlled in some way, right? So we've seen that when the program starts up, we saw that RV comes from the attacker, right? Can come from a fan line parameter, which comes from us, the attacker, right? The same with the environment. We saw that ENV command prints out all the environment variables and you're exploring this in the bandit problems, right? You're setting environment variables, that's what you, the attacker, control those environment variables, right? So if the program, if a secondary program is reading from environment variables, hey, that's a way we can get input into this program. We may be able to change, so we've got this in like a startup phase of the program, right? When the program starts up with some parameters, mainline parameters, it maybe reads from some environment variables during execution it may use some dynamic linked objects, any kind of file input where it's reading from files or writing to files from the operating system, maybe we could mess with the file system to get it to trick it to do something it's not supposed to do. So we're going to open up a socket to maybe talk to another program that trusts, well hey, we can talk on a socket, so maybe we intercept that and try to talk on there. Some of the things, any kind of interaction with the environment, we can try to control, right? We can try to control file creation signals, we can send signals to a process at any time, right? This is one of the important things to realize is when you run a program in the BASH plan prompt, right in your terminal, and you type in control C, what's happening there? Yeah, who sends that signal where? I think I saw that I couldn't sense this among the mumble. So what is this signal? I think it's our same term, I think or int, sitting int. Yeah, that's right, sitting int. So who sends that? The user, the keyboard? BASH! Yes, BASH sends it, right? Remember, we talked about how does BASH exceed the program? Well, it does a fork and then it does an exact and so the parent is still listening to your input, so when you do a control C, BASH sees that and so it sends a signal to that process to try to terminate it, right? You can also register other kinds of, you can even use the probably an appropriately named kill command on Linux. You can use kill to send an arbitrary signal to another process. So you can send the sig int, you can send sig int to that process without typing in control C and the program will, the behavior will be as if you type in control C, right? So that's another important thing to remember, right? That's nothing special. The same as when you do control Z, what does that do? Yeah, it tells it to sleep. That's another signal. I don't know how to say sleep, but I would probably guess that that's what it is or something similar. Right? So these are just predefined ways that BASH and your terminal have decided to take your input and interpret it and send it to the program in different ways. But you do not need a keyboard to do that. You can do that to things that are executed in the background. You can send any signal at any time to a program. So maybe they haven't thought about it. What happens if you try to tell it to sleep while it's reading a file? Maybe there's somebody you can alter the behavior that way. And this can be a difficult problem, right? This is part of understanding what the application does helps you realize this is where I can try to control things. But these things start to blur, right? We have file systems and directories and file permissions and network sockets and interrupts, right? So you really have to understand what does that application do. And one of the things that that application is expecting to do and what permissions do I have as the attacker? What can I actually do? Right? So if you're telling me oh yes, breaking this into the system is easy. You just add a new entry to the EDC password file and then your new user on the system. Okay, well, but how do you do that? Why don't you sudo vim to like edit that file? Okay, but by doing that you're becoming root on the system in order to execute that, right? You as a user can't do that so there's no way that could possibly be used to exploit it. You have to deal with your user and your user's permissions. So very broadly kind of the classes of attacks we're going to have to look at are different ways that we can nest with applications when they access files. We can do very broadly command injection attacks. We can try memory corruption attacks, which are kind of the classic what we think of when we think of binary exploitation is some kind of stack corruption not for overflow. We'll talk about heaps, we'll talk about format shrinks. We'll see. The file access stuff is really cool because it's not normally something that you would think about. Like oh yeah, this is how you can break the security of an application. But we'll see that those can be just as powerful as any of the other ones. On here talk2 is really, really interesting. It actually comes up in a lot of places. Format string is really interesting because with a format string vulnerability you have to be incredibly precise in what you're doing. For some of these attacks we'll see there's differences here. For some of them it's like a sludge jammer. You don't have to be super precise. You can just throw a bunch of data in it and it'll work. But a format string you have to know exactly what you're doing to be very precise in order to do these things properly. So, from the beginning we'll first look at file access attacks. So, when your program tries to open a file like a file or try to well let's go with execute a file when you type in ls you know what happened. How does it know which ls to execute? Yeah, so there's a special environment variable Windows has exactly the same thing if you know Windows development. There's a call path. So, on Unix it's called path all uppercase and the different paths are separated by what? 7 colons. No, colons. So, path 1 colons, path 2, colons, path 3 and that will specify the order that will look for whatever program is called ls and it will find the first one in that list that it's able to find who controls the path environment variable. It's an environment variable and you're the user. So, this is another way you can potentially influence applications. So, there's many different things so there's a couple different things here. The other way to think about is when an application wants to open a file for reading and writing what do they pass in? Open function. How does it specify the location where the file is located? How do you get a file handler? How do you get a file handler? You pass in a string which is the path to the file that you want to open right? And then the operating system will look up that file in the virtual files system and it will try to find that file and it finds it, it will open it and it will give you then a file descriptor which that is how you will read and write the file. So, this is the operating system's way of saying when you open it, you give me the string but now I'm going to give you just this integer and whenever you want to redirect to that file you give me back the same integer and that's what we'll use. So, one way we may be able to try to hand work the application is what if we can partially control some of the string of the path that the application is going to open? What can you do? Change the directory that we get the file from? Change the directory where we can get the file from? So, what are the parameters there? So, let's say let's say it takes the parameter from us on the command line, then what can we do? An arbitrary path can be controlled. Given A91, we can send it to any file so let's say we have a super simple application that looks for a password file right? If it takes that command line from the user either through an environment variable or on the command line we can specify our own password file and now we can bypass the application by checking it and making that our password is whatever our password is looking for. What if it's opening something, so let's say we have different user profiles and it's opening let's say, slash user slash user input plus the password let's think about these two different scenarios as the dot-dot attack so, essentially even though it seems on first glance safe you're appending to the file that's going to be open slash usr so you should therefore, of course, be restricting the all access that should happen on that sub directory and slash user but the problem is the command line system allows you to traverse directories using this dot-dot notation and so that allows us to escape it's also known as a directory traversal attack because essentially we can arbitrary new directories. Now if a program allows you to do this does that mean there's a vulnerability in that program? Remember, it comes back to knowing the application, right? If there's no check, like VIM or Emacs, can you type in dot-dot slash dot-dot slash dot-dot slash foobar Yes, and you want it to open up a file in whatever the parent's parent's parent's directory is called foobar right? That's intended functionality that's what you want it to absolutely do but if an application is using this file in order to make some security decision then that's when you have a vulnerability. Any questions on this? So, how do you fix this then? Yeah Input sanitation? What does that mean? So basically you can scan where you're trying to send in dot-dot, you should get rid of it say invalid input Which one? Get rid of it or say invalid input? Invalid input is what I would do What if you did the opposite? So what if you said how to deal with this is actually what I use when I'm executing your applications on the testing infrastructure Yeah, so it changes the root directory for a process So essentially what I'm doing is I create a sub-directory on my server a unique and brand new sub-directory for every one of your submissions then before I execute a program I say actually execute the program as if this sub-directory was the root directory So now the operating system you can do dot-dot as much as you want as much as your little heart desires you still can't break out and go to an higher directory there because the operating system literally does not allow you to do that it takes the start of the root class system and isn't the sub-directory that you're in So you can do whatever you want in there and then I execute a program and then I delete that old directory and all traces of you are hopefully not from my system forever So that's the other way to deal with this problem Other types of attacks Other types of attacks we can manipulate the path environment variable and also the home environment variable So why is the home environment variable important in terms of files It is where our config files are at but how does whenever application know our config files are there? Where the user's files are located Why is it important in terms of file access? A lot of programs you're going to assume is a default place to start from from searching for a file? How do they specify that when they open a file? Yes, the tilde So yes, that So there's actually two different ways So tilde If you just do tilde by itself that means your directory so that would be your home directory And so if a program opens let's say tilde slash dot something.rc file We can actually change whatever file it's going to open So let's say it's a setUID program that's only looking for our files in our system but we can maybe trick it by setting our home to slash root and therefore it's going to open root's file system So once again the problem is dot in a similar way the dot dot doesn't specify a file name It specifies something relative to the current directory So if the tilde does not specify a specific file it says go to the current user's home directory and look that up by looking at the home environment variable substitute whatever is in there and then calculate the rest of the string that will want to open We saw in the top graph the path environment variable is important because it determines how the shell looks up commands that you execute So if the program is calling system and calling system to execute some other process for it and it says system ls what is the file system what is the the system library doing it's libc library So look in the path to find the first ls function and then if it's a setUID application what permissions is that process going to run live it doesn't setUID application exactly which in the case we're interested in is root So it's going to call out to satellite functionality it's running that as the root user and so what can we then do in that case how can we take advantage of that executable earlier in the path than the system ls we can change the path we can have the first thing in the path dot which we're checking the local directory and we can make an executable put it in our local directory call it ls and it can do whatever we want and now at that point we're executing code that adds root on the system so the functions exec these are some other ones to look out for so system would be one exec lp and exec vp use the shell variable use the path variable or to look up which command to execute the other ones that can be vulnerable it's also not just so even if we're focusing on pretty exclusively on Unix binaries these also let other operating systems that use these functionalities so the same thing can happen with a Python strict with kernel any of these things that are calling out to external programs to give any influence in this way so yeah so we talked about that so home directory, right so the idea by translating this this occurs using the home environment variable and so the attacker can completely control that so what should we do what should we do to fix these always give absolute paths so if you want to code securely you should always give the absolute path so does that guarantee that somebody can't mess with it yeah so we we can trust an absolute path if we know that our user controls every directory on that path if another user can't let's say delete a directory and put their own directory there well then now we're going to execute whatever they want so it really does depend on the path the very first step is always specify the absolute path there's a good practice to do whenever you're calling exact or calling out using system or something like that you should if you're running a standard ID application you should never use home relative paths because then there's no way to control this you can't know beforehand so for an absolute path you can know exactly where you want to put the file because you can say hey I'm the creative director for myself when this is installed this is how my application works and it modifies this file it expects this directory structure to be like this you don't know what user is going to be trying to edit their file so you don't want to include a template in any file name that you're opening now we have a super fun step talking about links so what are links in a file system they can be so what types of links are there symbolic links and hard links so what's the difference kind of so at a high level a symbolic link says hey the file that you're located is at another location it's like the princess is in another castle when you try to look at that file and that file is not ready to file it's a link to go to the other file and a hard link essentially on the file system points to the same physical I know that the other file points to so the operating system essentially the program sees it as two files and doesn't really know that they point to the same underlying file for a hard link or a symbolic link you can tell that you're accessing a symbolic link here so this is a really cool thing that we can do so we make some applications that they maybe read a file they will check to see that that file exists or check to see that it's in a certain directory so if they check to see that it's in a certain directory what does that mean we can't do change file access we can't use a change directory we can't use a .flash of that because they're checking to make sure that the file is only in this directory but if they don't check to see that it's in an actual file and not a symbolic link then we may be able to put a link outside that directory as some other file and this depends on if we can create files in that directory or we can create links in that directory but oftentimes they will allow that so a lot of that depends on the exact thing I was configuring and so this is also going to occur with temporary files so if the application creates some temporary files in that directory it may just think that it's creating this local file that's set up correctly but if you can actually point it a link to let's say EDC password or something you can try to get it to open that file for you and so there was an application that was shipped with an early precursor to the KDE desktop environments it created a directory with permissions 5.5.5 to create temporary files and so what it would do is it would try to look it for this bar-dt-app-config-app-manager Generic Display 0 and so by creating a symbolic link from this file to an actual file that you want to edit so it would use this Generic Display 0 and it would write to that file and it would do this by creating a symbolic link so the way to read links is you want the link to be I think of it like a copy almost so you're creating a link called bar-dt-app-config-app-manager Generic Display 0 and that link points to EDC shadow the point through relationship always seems backwards because you're putting the information first and then the source so if you think of you're kind of copying it's like the same as copying like you're copying quote quote EDC shadow to this thing and that's how I've come to the brush line in my head and I don't know what that helps and so then when you run this d-tap-gatherer function it would say that hey this file exists and if you look at EDC shadow it would call ch-mod 5.5.5 on that directory the permission is there so when the operating system does this it says ok 5.5.5 on this file is great it's a link that means I need to do 5.5.5 on this actual file and so using that you're able to change the permissions of any file on the system that root can control which is literally everything you don't get right permissions and you can't change anything on there so that's the EDC shadow file so we didn't talk about that the whole and separated list of all of the users on the system so it was the user's login name, the user ID the group ID the shell and there was a field that was an asterisk for all of them so what that means is that the actual user's password is stored in the EDC shadow file but it's not the actual password it's a hash on the password but the passwords of all the users in the EDC password file it almost seems like by the name that was what it was for and it was why is that a bad idea ok something goes wrong it's a very sought after target yeah so how do you well it's a very sought after target what are the permissions on the EDC password file owned by root and group but what are the permissions yeah readable by anyone which makes sense this is all the users on the system everybody needs to look at that to see who the users are and if the user exists there's a lot of good reasons to have that but now you're saying everyone on the system can see even the hash version of everyone's password that's probably not great and so that's why they separate out this functionality so the EDC shadow file by default is only readable from root it's not readable from anyone else so that way this is all the password checking is done using this EDC shadow file so what I can do is now that I can read this shadow file I can take it and there are programs like John the Ripper that you can run that will just try a bunch of password cracking on that file and I guarantee you somebody out there is a really crappy password so if you're using a if you're on a big multi-user system you're going to get some interesting stuff yeah we'll get through these assignments where we're going to use tools like that like you're just running a password cracker on it you're using somebody else's stuff you can make your own yeah you can do that too I think what's more interesting is finding this vulnerability in there first to me it's this first step the DTAP gatherer has some code that looks correct but it's actually wrong it's making this it's creating this but it's not checking if it's a file or not and then it's setting the permissions which allows you to then leverage that to do all this other crazy stuff I mean I think it's fun, I think you should spend some time downloading password matches and using the Ripper to crack them it's actually a whole interesting thing about how you guess good passwords or how you guess things so you're likely to get to a great password but I'm just going to focus on more codes so what so now what we need to do now what we need to keep in mind we use this we use the softlink right yes but what softlink does is just create a different link to the same file so why does operating system needs to change the permissions for the original file the permissions I believe that's part of the nature of a symbolic link so if you look at a symbolic link the permissions should be 777 everybody can see that but I don't know why it's writable so if we use hardlink then it's okay to go with this but if the component I know is different then what's the need to change the permissions for the original file what's the need to do it or why does the OS allow you to change the file permissions of a symbolic link I don't know so part of it is just the application's functionality so the application basically says hey try to create make this file and then make this directory and then chmod it 555 so it's doing that part that's in the code itself but it's not checking that that make directory failed and then not doing the chmod it's trying to make the directory that exists it goes great well chmod that 555 and so the operating system looks it up looks it up and then chmod is the thing that it links to so that's just the nature of the functionality of symbolic links in the operating system you could probably argue whether that's a good or bad thing if the OS should do that or not and I would agree but you kind of at this point you just have to deal with whatever's there and who thinks that yeah so we should check what type of file we're operating right so we can try to do that and we can try to look for symbolic links once another kind of so this was using what thought was a temporary file was the main random at all it was a constant it was a constant location so this is kind of a flip side of this example temporary files should not be predictable your application should not try to create its own temporary files for reuse by itself and if it does I mean it definitely shouldn't happen to be predictable so there's a function called make s temp and it actually is really annoying because there's a function called make temp what do you have an s stands for secure when they put such important word at one minor letter if you were to design these from a UI perspective you can call one make secure use this one and if you really want to be secure you just never actually have the other one and if you have to have it you call it make temp not secure don't use this that will maybe actually get people to do it yeah I was working for a big corporation and they had this tool that they used to put computers onto the domain and that tool would create a temporary file and inside of there would be the vb script that had the admin password and everything that it ran to quickly want it so when you realize it's there you can go in and change the permission so that the program can't delete the files that it makes in temp and then when you do that it fills up the question mark so then it's like okay we'll just prevent it from so it can create it but it can't modify it so then it created this file and left the admin username and password there which I could then use to put any computer on the network I wanted yes, which is very bad this is not like an abstract thing this happens in a lot of different scenarios and it's exactly this right so that's why this make s10 guarantees the operating system will find a directory or a file for you depending on which parameters you pass it will make sure that that file does not exist beforehand it will give it a unique name and it will guarantee that only your user can read and write that file and this way you don't have any of these problems that you can have here and we'll stop here before we get on to talk to you with accent