It rather involved being on the other side of this airtight hatchway: Attacking a user by modifying that user’s files
A security vulnerability report arrived that went something like this:
Windows is vulnerable to remote code execution as follows:
- Modify the file
%USERPROFILE%\and add this line to the PlugIns section.AppData\ Local\ Contoso\ BlahBlah - Run the
contoso.exeprogram.- The
contoso.exeprogram loads its configuration from theBlahBlahfile.- When the Contoso app starts, it tries to create a plug-in from the object you configured in PlugIns section, passing the initialization data you also specified in the PlugIns section.
- By crafting the initialization data, you can get the system-provided object to run a command controlled by the attacker.
That’s all very interesting, but what is the vulnerability?
They never said.
The fact that the system-provided object can be induced into executing a command based on its initialization data is not surprising in this case: The initialization data for this particular system-provided object contains a serialized COM object, and deserializing it would naturally end up creating whatever you serialized.
My guess is that the finder was excited that they could modify a file in a way that leads to code execution when a program is run. But let’s look at our usual questions.
Who is the attacker?
The attacker is presumably somebody who is able to modify the configuration file.
Who is the victim?
The victim is presumably the user whose configuration file got modified.
What has the attacker gained?
Actually, if you look back at the earlier two questions, you’ll see that the attacker and the victim are the same person!
In order to modify a user’s files, you have to be that user or an administrator. In all cases, you haven’t gained any privileges beyond what you already had. If you’re the user, then you are attacking yourself. If you’re the administrator, well, it’s not interesting that the administrator can attack any user.
If you already had the power to modify the user’s files, then you don’t need to go to all the work of editing an obscure configuration file for a program the user might not even run. Just drop a batch file in the user’s Startup folder.
Light
Dark
4 comments
I usually don’t like to get involved with stuff that I don’t fully understand, but in this case I’ll try to play the devil’s dumb advocate: what if the Contoso app is misconfigured and it always wants to run with elevated privileges? The user is accustomed to just clicking OK on the security prompt because they trust the application. Even if they are not accustomed to clicking OK, they might just shrug it off as a hiccup after an automatic update and ignore it anyway. The user might be a lot more careful with an unknown script or application placed in the Startup folder (which does not benefit from automatic elevation, IIRC).
In this specific case, being able to place random plugins or specially crafted commands in a user-writable folder allows running malicious code with elevated privileges, or am I wrong? The owner of the Contoso application should at least be notified, to tighten up the permissions or stop loading executable code from a non-secure folder.
Requiring that the plug-in be in a secure folder doesn’t help. (1) Most users want to use plug-ins without requiring admin privileges. Imagine if you had to be admin to install a browser plug-in. (2) The executable in this case is indeed in a secure folder. It’s a system DLL that is being repurposed by the attacker. In order to carry out this attack, you must have already gained file planting access to the user, and it’s the file planting that is the vulnerability, not the consequences of the file planting.
You’re still attacking yourself though. You modified the config file and you have permission to elevate the executable, so you aren’t doing anything you couldn’t do anyway since if you can run Contsoso.exe elevated you could run malware.bat elevated if you chose to.
If the contoso.exe had installed a system service that read it’s plugin config from an unprotected directory, then an unprivileged user could cause plugins to be loaded with higher permissions than the user has. That would be a vulnerability in contoso.exe and not Windows, however.
Right, in that case, it could be a privilege elevation vulnerability in Contoso. But given the wording of the report, I don’t think it is the case: if it were, the reporter would have noted it. Anyhow, I think replying the reporter in that way would solve it: the ball would be again in their field, and if there were an elevation of privilege, s/he would be able to reply telling it.
That said, the attacker and the victim does not have to be the same person. An admin has access to every other user’s files, so it can “attack” other accounts. But even in this case, it wouldn’t be a vulnerability (“being an admin leads to control over non-admin users” 😛 ).