Windows privilege escalation: Abusing npm’s design patterns to escalate your permissions

4 months ago 28
BOOK THIS SPACE FOR AD
ARTICLE AD

Mohammed Dief

Trying to get back to bug bounty today I ended up deciding to hack on GitHub bug bounty program again, I didn’t regret it that much cause yeah I managed to get some content for my medium blog, yeah whatever

Anyways, npm is actually owned by GitHub and you can report vulnerabilities in npm to GitHub itself if you didn’t know, and npm command line tool is within the scope of the program, the stuff we’re allowed to hack and CLIs are actually my favorite.

Whenever I’m hacking on CLIs I always start by starting up process monitor so I can actually see what’s happening behind the scenes, understanding the CLI functionality is actually really important cause most vulnerabilities in CLIs depend on how far can you go outside the box, and trust me it’s way less painful than going through the entire codebase.

Also another thing to mention is that you wanna keep an eye for files the application can’t locate, you can get some easy DLL injection vulnerabilities using this technique and it will help you understand more of the functionality of the application seeing what the application is actually looking for

Anyways, I started process monitor and I started using npm normally on my D:\ disk ( don’t ever use CLI tools in the C:\ directory you will just miss stuff ) until I noticed this

npm loading modules outside the disk

If you don’t understand, I will simply explain this to you, In Linux npm looks for node_modules in the current folder, If it doesn’t find it then it just keep going a directory back until it finds a node_module, It’s the same way in windows, npm is looking for a module named bluebird and it’s looking for it in the C:\ directory, it can’t find it so it’s just going back a directory until it finds it

The issue here is any windows user can create folders under the C:\ drive, literally any user, such a behavior npm is doing shouldn’t happen at all cause the only thing stopping normal users from modifying some random executable on the system is ACL

Now we know where the vulnerability is we can actually move further, Once npm finds node_modules it actually starts looking for the required module inside of it, that means to figure out what module npm is trying to load we must create the folder at C:\node_modules, creating the folder then running npm again we actually get that it’s trying to load a module named bluebird

npm trying to load bluebird

If you don’t know how require works in node, a module in node doesn’t always have to be a folder, that’s why node tries all the possible importable extensions if it doesn’t find the module folder, that means a simple bluebird.js is enough for our exploit here

With that said I created a simple exploit in JavaScript that would just log something into the console and execute a system command

custom bluebird module to exploit the npm vulnerability

And after running npm the exploit actually works, upon using npm in general it doesn’t have to be an install command or anything else, affects all users in the system

show-casing the working exploit

The attack scenario is something like User [A] (normal user), User [B] (normal user), and User [C] (admin), If User [A] goes and plant the exploit in C:\ driver, all the other users in the windows instance are affected, allowing them to gain access to User [B] and User [C] whenever they use npm that’s installed in the machine for all users, It’s a clear privilege escalation requiring no permissions at all

Timeline:

[07–11–2024] The vulnerability was reported to GitHub

[07–11–2024] GitHub security team said the issue is out of scope because it requires local access and they might make this functionality more strict in the feature, the report got closed as informative

[07–11–2024] I requested permission to write about this vulnerability and they agreed

Read Entire Article