Worst case scenario of having the ability to remotely write files to disk as admin

Question

I'm working on creating a program ("My Program") that will communicate with another program ("Their Program") via XML commands over a raw TCP/IP connection. Their program allows files to be written to the disk remotely with administrator privileges. This interface is enabled by default (MAJOR security flaw, I know), and I'm trying to give the other company a worst-case situation of what could happen if a hacker were made aware of this vulnerability and exploited it on a corporate-intranet-connected computer.

How localized is the security threat?
Can the attacker compromise network/server security using only this exploit (possibly to exploit other vulns.)? The user is a local admin but a standard network user.
What other possible threats might be exploitable because of this "feature" that I perhaps have overlooked?
What would be the best way to protect against this, while still keeping the functionality required? Is there a way to artificially sandbox the program, or check if the files written to disk are not in a sensitive place?

@Polynomial If by arbitrary, you mean can be specified by the attacker, then YES. x( — Matt, Aug 24 '12 at 09:39
Is this limited to a single directory? Can the attacker choose the file extension? And is that directory accessible via some other protocol, such as http? — CodesInChaos, Aug 24 '12 at 09:41
@CodesInChaos: No, yes, and "it depends". The connection is a raw query, and defaults to port 4096/7 (the software typically runs with two internal instances), but this can be changed to any available port. — Matt, Aug 24 '12 at 09:44
@Rell3oT Full admin access (ie, "Run as Administrator"). It won't work without it. — Matt, Aug 27 '12 at 07:18

score 9 · Accepted Answer · answered Aug 24 '12 at 09:50

9

Ok, this is a pretty nasty flaw. If directory traversal is possible, the attacker might overwrite often-used executables in order to infect the box with malware. From there, the rest of the network could get infected through a whole range of different mechanisms: USB spreading, remote code execution vulnerabilities, spear phishing, etc.

Worse, they could use the malware infection to steal any credentials stored on the machine (if it's Windows, there are encrypted Active Directory caches in memory) and log into other systems.

If you're running any public-facing servers that offer up files (e.g. HTTP, FTP, SharePoint, etc) the attacker could overwrite those files with false information, or malware.

At minimum you're looking at a DoS vulnerability, where the attacker fills up your system with large files until the disk is full.

answered Aug 24 '12 at 09:50

Polynomial

132,208
43
298
379

Is there any way that this could be exploited from outside the corporate network, i.e., via some sort of XSS? – Matt Aug 24 '12 at 10:24
Depends how the software is accessed. It might be possible to use XSS with websockets on a poorly secured browser. – Polynomial Aug 24 '12 at 10:54
1

Thanks, good to know. I'll mark this as the answer in two days, just to see if anyone else answers. – Matt Aug 24 '12 at 11:10
It seems to me that this feature is still limited to only users with administrator priviliages. – Ramhound Aug 29 '12 at 11:07
@Ramhound I think you misunderstood. "Their program allows files to be written to the disk remotely with administrator privileges." - the process writes the files at the same privilege level as an administrator. It doesn't require admin privileges to log into it. – Polynomial Aug 29 '12 at 12:32

score 7 · Answer 2 · answered Aug 24 '12 at 13:26

If the attacker gets to choose the files he can overwrite, then he just has to replace a few operating system files to completely own the machine (e.g. replace the kernel and wait for the next reboot).

If the file names are "contained" (i.e. the files written to by the attacker will necessarily appear in a specific directory or a subdirectory thereof, without any possibility to overwrite system files), then most problems can be avoided, but it still allows the attacker to upload "nasty stuff", the kind we prefer never to see on our servers (e.g. virus and other malware). As a baseline, the "upload file feature" allows for an attacker to fill the server with pedophile pornography, which is a liability (this argument alone should be sufficient to convince any sane businessman that this feature is a bad idea).

I wanted to avoid the kiddy pr0n argument, but you hit the nail on the head. It's a massive liability, and not particularly fun to deal with. — Polynomial, Aug 24 '12 at 14:17

score 6 · Answer 3 · edited Jun 16 '20 at 09:49

Just to add some point of view: Have you heard about the 10 Immutable Laws of Security ? It's a bit old, simple, etc., but goes to the point.

Inside it you'll find some rules:

Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore

Law #2: If a bad guy can alter the operating system on your computer, it's not your computer anymore

Law #4: If you allow a bad guy to upload programs to your website, it's not your website any more

If someone can upload files to a server, save those files anywhere, with any name, with admin priveleges, basically he owns the computer. If the interface is enable by default, he doesn't even have to trick someone to upload those files!

What he can do:

DoS by filling up the whole space
Use the server to store information as a repository, be that information: piracy, pornography, stolen credit-card information...
Overwrite system files and get unlimited access to the OS, and then do anything he wants
Spread contamined files by overwriting files that other users would download
Access any information stored in the computer, including security archives
Spread worms (remember the Nimda worm ?
Be the source of attacks of any other computer / sytem in the network / internet ?
It that sever have secure content that is served through HTTPS, people would access it thinkin it's secure, but it wouldn't be...

There's a similar adage for a device with a malware infection: once it's infected, nuke it from orbit and start again - it *cannot be trusted*. — Polynomial, Aug 29 '12 at 08:07

score 2 · Answer 4 · answered Aug 29 '12 at 07:58

I agree with everyone else who says this is bad.

What I want to add is to answer your question of how to mitigate the threat. The answer will depend upon the exact functionality of "Their Program" and what resources it needs to be able to access as part of its legitimate, ordinary functionality.

The first and most natural suggestion to try: run "Their Program" in a virtual machine, so it cannot access the real filesystem. This way, it can write to the filesystem of the virtual machine, but no harm is done; at worst, the VM gets compromised, but not the underlying physical machine. Whether this will work depends upon what kind of access "Their Program" legitimately needs.

If this is too restrictive, you can also consider sandboxing technology, like SELinux, AppArmor, Systrace, seccomp, and more. (If it is running on Windows, I'm stumped. I don't know of a good sandboxing program for Windows. That doesn't mean none exists, of course.)

Their program needs to have admin access to one of two network cards (as it creates and sends custom packets). Would a virtual machine support this? — Matt, Aug 29 '12 at 08:43
@Matt, I don't know! You could try and see (or try asking on, say, ServerFault). If you can't use a virtual machine, another simple solution is to run "Their Program" on a separate machine, and don't let that machine have access to your real filesystems (e.g., don't give it the network password for your network filesystem). — D.W., Aug 29 '12 at 17:31

Worst case scenario of having the ability to remotely write files to disk as admin

4 Answers4