Hello and welcome to this course in which we're talking about Python for privilege escalation. In this video, we're going to be talking about process injection and how we can use Python and process injection to achieve privilege escalation on a system. Most applications that are developed, no matter what type of application they are, are not designed to be a completely standalone, most applications are reliant on some form of third-party code, whether that's third-party libraries, DLLs, other applications, etc. The reason for this is that third-party code can be a useful tool for development. If you're writing an application and there's a library that does exactly what you want it to, it's much easier to implement certain functionality using that library than it is to write your own version of the code. Also, there's a good chance that third-party code will be a better implementation of certain functionality, again, depending on the source of the code. If you're looking at some of the core libraries for different programming languages, etc, then those libraries have probably undergone peer review, they're optimized and so they're probably just better than something that could be written by someone who wasn't an expert in what that particular library is designed to do and so using this third-party code or third-party applications within a program makes perfect sense. However, that reliance on external codes starts to create vulnerabilities and potential risks for a system. It could be that there's a vulnerability in those third-party libraries that an attacker can exploit that could also leave the applications dependent on it, vulnerable to exploitation. This is one of the most common considerations for security of third-party code or of a supply chain security perspective. However, we're going to be focusing on a different risk associated with third-party code namely process injection and how process injection can be used for privilege escalation. When you're using an application on a Windows computer and on a Linux computer as well, you're not probably going to specify the complete path to a particular file or application that you want to access or use, typically you'll say something like, "I want to run notepad dot exe", and notepad magically opens despite the fact that you haven't said, "Well, here's where you find it." Reason for this is that Windows or Linux will have a process for identifying a copy of that executable, or in this case, a copy of an external dependency used by an application. They'll find it on the file system and then they'll load it in or execute it for you as desired, which means that we don't have to provide the complete path. However, this becomes problematic if an attacker can exploit this search process. Both Windows and Linux have a list of places that they look for a particular dependency, executable, etc, when they try to load it into the system and the higher you are up on that list, the higher the probability that you're going to be the one selected. This becomes problematic for a process or library injection because the top priority place that a program, or that the operating system will look for a dependency for a program is in the folder where that program is located. In some cases, if a program is placed in a non-privileged location, this means that if it's trying to use a library that's maybe built into a particular language, so say Python libraries, that if you can insert a file or Python dependency with the same name into that same folder as the application, or anywhere else higher on the search path than the legitimate version of the dependency, then the Python code is going to import and execute that malicious version rather than the real one. This ties in the privilege escalation because it may require different levels of privilege to add a file to that folder than it is to run the process with the privilege level that the Python program, for example, is running with. For example, you might need to run a particular program as a root to gain access to required functionality, maybe something like binding sockets. However, it could be that all of those files in that directory are owned by a lower-level user account and so someone with access to that user account could insert the malicious library, but then have it run with root-level permissions once that vulnerable executable of Python program is executed and imports that library. We're going to be discussing Python library injection and how it can be used for privilege escalation in the next video. Thank you.
