Hi, within this lecture we're going to see SUID permissions one more time. And actually this is again an advanced way of exploitation in order to escalate our privileges. So, we are in the Task 15 over here, File Permissions SUID Binary. So, we're going to see how it works. And we're going to work with environment variables over here or path, and you're going to see what it is in a minute. Now, I'm going to run the find thing that we have been running so far, okay? I'm going to search for the 'type -f' I'm going to find the permissions over here and just run LS and just put the output in 'dev/null' but for some reason it hasn't been executed or yep, here you go. I have to say '-type' and f like this with -type, okay? So, here we have seen the suid-so, over here but also we have the suid-env. So, suid-env. This is another binary that we have seen before but we haven't looked into it. So, right now I'm just going to focus on this, okay? In our case, in our scenario we found an SUID permission over here and we are trying to understand what it does. Once we run that, it says starting web server apache2httpd. And it says already running. So, most probably this suid or this binary starts apache server, okay? And in order to confirm this, we can try multiple things like we can run strace as we have seen before. We can try strings, which is another way of seeing that. So, let me just try this with strace, okay? And run this. So, here you go. What can we see with the strace? Let's see. So, it says that... Again we have no such file or directory is over here, but we have already covered that. Maybe there is a way to actually do this one more time within this binary as well, but we already covered that in the previous lecture. So, we see operation not permitted over here with set reuse ID or RESGID over here. So, we have this apache2 permission denied for some reason, okay? So, it's definitely trying to start the apache2. We already seen it in the logs and we already seen it over here as well. So, there's something going on with the apache, okay? It says permission denied. I don't know why it's saying that because in my opinion, it gives us the services already running thing, so it should have been executed. So, I'm going to run this with strings. So, if you run something with strings, you can see the strings that you can find, it doesn't always give you the best result because this is a binary, we cannot get the whole source code or something like that. But if the source code or if it does something with the comments with a string like this, for example, running 'service apache2 start' in this case, we can actually see it, okay? So, running strings may not give you the best output, but we can see some kind of clues like this. So, in this case, we know that this SUID binary is trying to run 'service apache2 start.' So, we already knew that, but we didn't know how it ran that. So, it actually ran that with a command, like this, 'service apache2 start'. So, let me show you something. What does service do? If we're on service, it actually runs a binary to actually runs an executable, right? And it gives us how we can use it. So, it's the same thing with Python actually, but we don't have Python over here. So, let me show you my own Kali. If I run Python, I go into the Python shell and I can just run Python codes like this. So, let me exit out of this one, and I believe I have to write it like this. So, the question is how does Linux understand when I run service or when I run python or when I run something else? So, there must be a logic, and the logic behind it is the environment variables or the path that we're going to see in this lecture. So, it's the same in the Linux, it's same in Windows and it's same in the Mac as well. So, we define some variables in the environment and when we run this, the operating system will know where to look at it. So, in this case, it's looking at some folders and if it finds the service binary, it runs it, it executes it. If it finds the Python, then it executes it, okay? If it doesn't find, if we don't give that information to the operating system, it cannot find it. So, maybe in our server Python is installed but it doesn't know where it's located. So, if you run 'print $PATH' like this, you can see your own path. So, in this case, we get some no such further or directory over here, but also we see the user bin. So, whatever resides under usr/local/bin folder, for example, it will be found and it will be executed once I write something over here. For example, Python should be under the usr/local/bin. So, if we go to usr/local/bin like this, okay? Or user/bin, it really doesn't matter. Just go to usr-usr/bin. You will see a lot of folders or a lot of executables over here, like zip, zipcloak, something like this, okay? So, there are a lot of executable, and this is how actually my Linux knows when I write something. For example, if I write 'zip' over here within any folder, okay? Not in the usr/bin, it knows to look it in usr/bin because it's defined in the path, okay? So, if I run 'zipcloak' for example, I don't even know what zipcloak is. It will find it under usr/bin and it will execute it like this, because it's defined in the path. Once I write this, it finds it, it tries to find it in the usr/local/bin and every other folder that is defined in path. So, what I mean is, if I can change the service for example, rather than it finds the original service in the path. Maybe it can find my own version of service or something called service, like an executable that will lead me to an escalated privilege. Then I can become root, right? So, it's hard to do. We don't know whether we can change the path in a way that we want. But it's worth a shot because there is an SUID binary that runs this command and we are certain of that. We can see it in the strings. So, why not we try this. That's what we're going to do within the next lecture.