1

I have a directory on an Apache server dedicated to serving images, and I have those images rw for www-data (Apache process runs as www-data).

I've configured it like this, because in the authenticated part of the site (which runs Django), I have buttons with backend code that can change these images as needed.

These images are visible to the world, and are served directly through Apache (and not through Django).

How might an attacker use these permissions to change the images, or otherwise compromise my site if there is no WebdAV, no FTP, and no other SSH users on the server apart from myself?

trajekolus
  • 111
  • 1

1 Answers1

2

A few possibilities, ordered by likelyhood:

  1. Your django app may contain weaknesses that allows an attacker to execute arbitrary code as user www-data.

  2. Django itself may contain a weakness that allows for remote code exection.

  3. Apache itself may contain a weakness that allows for remote code execution.

In all three scenearios, an attacker gains access to the file system, or, in case you've chrooted your process, to the part of the filesystem in the chroot jail. An attacker being able to change your images probably isn't the biggest problem (depending on the nature and use of the images, of course). A much more dangerous problem is that he might place other code in your images directory, since www-data probably has write access to the directory. This means that

  1. An attacker can now place arbitrary code and data on your server and
  2. Access that code and data remotely, because it sits under the webroot of your apache server.

These two abilities are very useful for an attacker. He might start mining bitcoins on your server, or use it to send spam e-mails, or make it part of a botnet, or use it to distribute illegal material, and so on.

The image write permissions themselves are harmless in that they can't be exploited to gain access to your server, but they are a problem once an attacker has managed to breach your server, because they give him a place to stand on, so to speak.

Out of Band
  • 9,150
  • 1
  • 21
  • 30
  • So any compromise require an as yet to be discovered flaw which may not ever exist for long if the server and all software kept up to date? – trajekolus Mar 13 '17 at 12:13
  • The risk may still be too high for something financial, but if it is for a server that just provides some interestingness on the web, the risk seems low enough to me. – trajekolus Mar 13 '17 at 12:19
  • @jdoer1997: Basically, yes. But that's always the case with exploited services, and you can assume there *are* flaws. It's clever to design systems in a way that minimizes the damage in case a flaw is exploited. – Out of Band Mar 13 '17 at 13:15