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.

  1. How localized is the security threat?
  2. 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.
  3. What other possible threats might be exploitable because of this "feature" that I perhaps have overlooked?
  4. 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?
  • 1
    Is the remote filename arbitrary?
    – Polynomial
    Aug 24, 2012 at 9:37
  • @Polynomial If by arbitrary, you mean can be specified by the attacker, then YES. x(
    – Matt
    Aug 24, 2012 at 9:39
  • 6
    Wow. Best advice I can give is "prepare for a shafting".
    – Polynomial
    Aug 24, 2012 at 9:40
  • 1
    What permissions does the program have?
    – user11869
    Aug 24, 2012 at 13:43
  • 3
    then just like everyone else says. youre screwed...
    – user11869
    Aug 27, 2012 at 12:47

4 Answers 4


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.

  • Is there any way that this could be exploited from outside the corporate network, i.e., via some sort of XSS?
    – Matt
    Aug 24, 2012 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, 2012 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, 2012 at 11:10
  • It seems to me that this feature is still limited to only users with administrator priviliages.
    – Ramhound
    Aug 29, 2012 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, 2012 at 12:32

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).

  • 1
    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, 2012 at 14:17

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...
  • 1
    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, 2012 at 8:07
  • 1
    @Polynomial: ^what really happened to MIR... ;)
    – Matt
    Aug 29, 2012 at 12:14

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, 2012 at 8: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, 2012 at 17:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .