How to r00t a webserver within minutes fuer n Appel und n Ei

The following is basics for responsible admins and everybody who cares about webserver-security (skiddies included;-)), but not known to many programmers and server-owners who get pwned all over the planet, 24/7. if you are familiar with rfi and metasploit and webapp-exploit you can skip reading this.

i want to show how easy it is to r00t a badly maintained server, just using a browser and some everywhere_found exploits.

DONT DO THIS AT HOME, KIDS

really, you shouldnt. and, this is just a proof-of-concept to show what is possible, not a step-by-step howto.

FOR THE 1337 h4X0rZ

yes. i know.

go home and play with your stuff[4].

some preface_info

if you check the know security_lists on a daily basis you'll get rapidly an overview of a lot of vulnerable webapps. small firms, projects, webdesigners and people who run that php_apps on webservers, since its quite easy and cheap nowadays to setup your own rootserver, don't care about patching the systems and, beside this, patching their webapps. it is my experience that the majority of webserver-owners dont care … lets say, very very hopefully suggested, 51 percent of current online webservers are poorly maintained. with a whole of 108.810.358 distinct websites (as of 2007)[2][3 = html-link], and lets take half of them out, since many websites and webservers are driven by bigger companies who mostly do care about security and run non_php stuff, we still have ~50.000.000 websites. lets assume that a normal webserver can take 1000 domains and serves webpages and webapps quite well we end up with 50.000 bare-metal webservers. and if half of them are poorly maintained … you get the picture. even if my mathematics is completely wrong, lets say it with the logic of a duck: there are more than a lot of possible targets.

naming

target ⇒ the server i'm going to r00t
donkey ⇒ a third server where i store my stuff online (shells, exploits, helpertools)

test-setup

no, i didn't hacked testosterton.org, its just one line in /etc/hosts.

to test the exploit i used a testserver with debian/lenny, with no security_patches applied since march. ok, i cheated a little since i used pre_compiled binaries, but i wouldn't count on build-utils on a webserver, and the most webservers one want to target will run 32bit-linux.


[ root@deb-testosteron :~] > uname -r
2.6.26-1-686

[ root@deb-testosteron :~] > ls -lrt /boot/
total 15528
-rw-r--r--   1 root root 1506512 2009-03-13 23:36 vmlinuz-2.6.26-1-686
-rw-r--r--   1 root root   928033 2009-03-13 23:37 System.map-2.6.26-1-686
-rw-r--r--   1 root root     91640 2009-03-13 23:37 config-2.6.26-1-686
-rw-r--r--   1 root root 6162429 2009-04-05 15:46 initrd.img-2.6.26-1-686.bak
drwxr-xr-x 2 root root       4096 2009-04-05 15:58 grub
-rw-r--r--   1 root root 7161465 2009-04-07 21:08 initrd.img-2.6.26-1-686

find a vulnerable webserver/webapp

you first need to find a webserver that let you upload any content or a webapp with a remote-file-inclusion-vulnerability; many exploits to actual existing vulns are found on milw0rm and packetstorm, i just want to note the latest wordpress-security-issue[1].

i'll skip a step-by-step explanation here, but it IS easy. i wrote my own scanner (thanks, google, for all the d0rks) within some hours and found 3000+ vulnerable webpages with (mostly vulnerable) joomla or wordpress-installations within 24hrs. you'll find a great varity of scanners out there on the interwebs.

you just need to decide wich vulnerability you want to target:

upload a file (php-shell) to a webserver
execute a php-shell via rfi-exploit
execute shell_commands via vulnerable php_scripts

execute your shell

i have all my stuff on my donkey (php-shell, customized exploits, helpertools) for direct access and hiding my origins. then i exploit the found target (maybe i'll show this using the latest wordpress-vuln later), upload my shell (or rfi them) and have now access to the server:

cool; i could now go on and read config_files, get mysql_passwords on this server, dump databases etc., but not today.

get exploits & execute them

next: download that nicies with exploits, shells, helpers etc to the target, using the store@donkey

last screenshot shows output from running the exploit, that lets you execute ANY command as root, lets say binding a shell to a port, download rootkits etc pp. at this point the server is fully compromised.

conclusion

general

rooting a webserver with an insecure webapp and no patches applied during the last, lets say 5 months, migth lead to a fully exploited server within 5 minutes, where the attacker doesnt need much more than some exploits on a third server, a browser and something like anonymouse.
finding these potential targets ist the most time_consuming part, but since there're a lot of nice crafted vulnerable_app_scanners for popular php-based webapps the scanning can be done overnight; may the d0rk be with you
exploiding the found targets is just a matter of time and knowlege; there are more exploits for a vary of webapps online accessible
knowing, that many servers are poorly maintained, (meaning: no patches. ever), it's no problem to find any server; just check how many inseure/old wordpress, phpbb, joomla or whatever you find; i bet, > 90 percent of these installations will never be updated, so it is no problem to find an exploit to a surely existing vulnerability. and where webapps are poorly maintained the servers itself are mostly in the same conditions.
we won't have much security on the internet; there are to many exploitable servers nowadays

for webserver-owners

let your server maintain by someone who knows AND cares about security
work out SLAs for security where your server-admin must prove and document what has been done on patches on a monthly basis; let your admin provide you with advisories or statements on critival bug-announcements; so you'll will know if your admin_of_choice hast the latest informations and takes the rigth actions; if you don't hear anything within half a year your admin migth be a little lazy
care about (at least a little) about security and take it serious, especially if you hold personal or payment data on your webserver
let your server maintain by someone who knows AND cares about security

ACHTUNG!!! 

Das Machine is Nicht fur Gerfingerpoken und Mittengraben. 
Is easy Schnappen der Springenwerk, Blowenfusen und 
Poppencorken mit Spittzensparken. 
Ist Nicht fur Gewerken by das Dummkopfen. Das Rubbernecken 
Signtseeren Keepen Hands in das Pockets. 
Relaxen und Watch das Blinkenlights

links and references

research/exploit_a_webserver_through_php.txt · Last modified: 2009/11/14 23:47 by dogtown