FEATURE REQUEST: Check Path Variable Folder Access

[itm4n]

FEATURE REQUEST: Check Path Variable Folder Access

[itm4n]

1. What's the point in checking the current user's PATH since you can add whatever you want to this environment variable?
2. The script already checks the system's PATH. This is one of the very first checks that was implemented as it's kind of basic LPE stuff on Windows.
3. PrivescCheck reports PATH directories that are writable or that can be created by a low priv user.
4. PrivescCheck also reports "ghost DLLs" that can be hijacked thanks to a vulnerable PATH directory based on the OS version.

[ghost-ng]

I guess the discussion is more "how intuitive do you want to make it" and "do you want to only display potential vulnerabilities"

When you use the -extended parameter, it should netstat out (TCUP/UDP endpoints and the script refers to it). I see the PATH variable expansion being the same thing. I grabbed the latest script and did not see any output (-extended and normal) which show the PATH variable. I dont remember the last time that the "Environment Variables" section actually outputted anything, maybe a bug then? I've been playing a few htb and PG boxes and all of them have had this section emtpy.

[itm4n]

OK, I see. I think there are two misconceptions here.

First of all, in your initial message, you explicitly requested an "additional check for write permissions in folders in the current user's environment PATH variable". In your second message, you refer to it simply as the PATH. The problem is that you have to be precise on that point because each user has its own PATH. What's the most important for local privilege escalation is the "default" PATH, which is stored in HKLM and is used by SYSTEM. Other user accounts inherit this value and may also add custom entries to it in their own PATH (which is stored in HKCU). Therefore, if you check the current user's PATH, you will check the default PATH but also some additional entries that were potentially added within the current user's context, and find false positives. This is why you should check the system's PATH rather than the current user's.

The second point is about the script's output. Basically, PrivescCheck has two types of checks: "Info" and "Vuln". The purpose of "Info" checks is to collect information that could be useful for exploiting a vulnerability or for the post-exploitation phase. For example, it reports whether the "LSA protection" is enabled or not, so that you know what you will have to deal with if you want to dump LSASS. Like you said, it also reports listening TCP/UDP endpoints. This information is not immediately useful but it might help you identify exploitable services, such as a local web application for example. Regarding the "Vuln" checks, the philosophy is completely different. The idea here is to minimize the output by reporting only actual vulnerabilities. Therefore, in the case of the system's PATH, only directories that can be modified or created by the current user will be reported. If no such directory is found, nothing is reporting and the output simply shows the message "Not vulnerable". The reason for this is that, if a vulnerability is present, I want to be able to immediately spot it, rather than having to manually check all the output. In some rare cases, it is interesting to output all the information ("Info" check) and check for a vulnerability ("Vuln" check), but I don't see the added value in the case of the system's PATH.

That being said, it is totally possible that there is a bug and that some paths are not properly reported whereas they should have been. In this case though, it's not a "feature request", it's a "bug report", and you should provide me with an example of a vulnerable path (full path, detailed ACL, current user name and SID, etc.) that was not properly detected so that I can find the issue in the code and fix it. However, I have to say that I use this script in real life penetration tests and workstations audits, and it finds vulnerable directory paths very frequently as this kind of vulnerability is common in corporate environments.

Finally, the fact that the script does report any vulnerable PATH directory on HTB boxes does not surprise me. Although it is quite common in corporate environments, as I mentioned before, exploiting a vulnerable PATH directory is kind of "lame". The goal of box creators is to bring challenge, not provide a straight path to SYSTEM.

In conclusion, you requested "an additional" check whereas the requested feature actually already existed. In reality, your request was more about the script's output. You'd prefer the script to show all the PATH entries with a status (vulnerable or not vulnerable). The problem is that it goes against the "philosophy" of the tool. If I do this for the PATH directories, I will have to do the same for all the other checks, which would be counter-productive. So, unless you spotted an actual bug, I won't change anything in the script.