Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I hear stories about insecure web servers and sites which people (or bots) break into and execute their own code on the server.

My question is how is that possible? I heard of people putting their own javascript on websites stealing cookies and techniques how to do that. I never heard of actual attacks to execute code. I know mysql injections can be used to steal data and put in javascript code on pages. But i am still having trouble thinking of how the weakness of a site can compromise a server. How is that possible?

share|improve this question
add comment

6 Answers 6

up vote 10 down vote accepted

To be able to run code on your server, I could:

  • Upload a file using one of your web forms. But instead of an image, I upload a PHP file. Then I can run the code in the PHP file with the privileges of the webserver process.
  • Exploit a buffer overflow to get a shell on your server.
  • Log in as an administrator and upload code:
    • Social engineer the password from one of your administrators.
    • Use an XSS attack to steal session cookies from one of your administrators.
    • Use an SQL injection attack to read the password table, then:
      • read the passwords that you stored in cleartext, or
      • run a password guessing program to crack your poorly chosen passwords.
    • Use a directory traversal attack to get a copy of your system password file and use one of the password-cracking methods mentioned above.
    • Physically steal a backup tape to get a copy of your database and use one of the password-cracking methods mentioned above.
  • Use any of dozens of methods of taking over a machine on your intranet and using that as a platform to upload code to the web server.
  • Physically get myself in front of your server console.

Note that I don't necessarily have to attack your app. I can attack vulnerabilities in your webserver, OS, or people for example.

share|improve this answer
    
I like this answer. I feel more confident –  acidzombie24 Nov 14 '11 at 22:46
    
@acidzombie24: Note that my list is not necessarily exhaustive... –  bstpierre Nov 14 '11 at 22:49
add comment

The simplest would be a executable upload vulnerability. The set-up scenario would be that a site allows users to upload files to the site, say, images that the users might want to attach to forum posts they create. If there aren't security measures, and the files that the users are allowed to upload live in a web-accessible, executable location, there is the potential for a malicious user to upload something like a *.php or *.asp file instead, with code that will be run when the user navigates to the uploaded file.

share|improve this answer
add comment

The high value attacks are ones that get a root shell on a server. At that point you can run whatever you like.

One step down from that is an attack which uses functionality within a web app to gain a shell, which can be escalated to root. Sometimes that escalation is through uploading an executable to user space which gains privilege through an exploit.

share|improve this answer
add comment

Three very common webserver attacks would be Cross-Site Scripting attacks, and SQL Injection attacks, and Directory Traversal Attacks (maybe the most common).

All of these are very similar, and if successful are the result of poor input validation.

While these may not actually put the physical server itself at risk, there are more painful things than losing a server. Like losing a database full of financial processing information, or PII.

Input validation is probably the single most important thing for web application developers to understand.

Even a very simple app, like a script that makes files available for viewing or download can put you at risk if you're passing files with a path to a script to cause the file to be downloaded or viewable, and you don't do any sanitizing on the paths to ensure, for example, that they are relative, and within the DOCUMENT_ROOT, then you could end up with a webserver that would be quite happy to display your /etc/shadow file, or your iptables configuration, or anything else that lives in a file on your server.

share|improve this answer
add comment

You can also think about any shell code exploit. Think that the webserver can have some vulnerability that allows someone to cause a buffer overflow, and using it he can inject some code that will give him access to the shell.

Since the webserver is one application, it might be vulnerable to this kind of attack. For example, in this thread someone complains about being attacked by a shellcode through his webserver.

share|improve this answer
    
buffer overflow... is that even possible in a managed or an interpreted language!? –  acidzombie24 Nov 14 '11 at 19:27
3  
@acidzombie24: keep in mind that the interpreter is written in C... see for example CVE-2008-5557 "Heap-based buffer overflow in ext/mbstring/libmbfl/filters/mbfilter_htmlent.c". Or it could be a buffer overflow in the webserver itself: cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3747. –  bstpierre Nov 14 '11 at 22:14
add comment

Here is a great book for you "Hacking: The Next Generation". It illustrates many examples of how attacks are executed. If the server hosts an App that does not restrict uploaded files types for example, a malicious user can upload a shell (there are many of these) and run it over http. Most of those shells allow privilege escalation. So if the server is not updated/patched the attacker will have root access on the server. I've seen this happening many times, mainly in cheap web-hosting.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.