I thought it'd be helpful to illustrate how a vulnerability goes from the code written by a developer to the metasploit module added that makes exploitation easy for script kiddies. This post is helpful for developers as they might see just how simple script kiddies can own your box. This post might also be helpful for sys admins so they can understand exploitation occurs and maybe what to look for. This post may also be helpful to security professionals to simply understand the basics of what an attacker is doing.
For this setup, I have created 2 linux boxes in virtual box (both set to Host-Only adapter so they have their own ips and can talk to eachother). 1 has kali linux and plays the role of the attacker. 1 has ubuntu server and plays the role of the victims public facing web server. The website will be written in php. The vulnerability will be poorly written code with a command injection flaw. The exploit will be written in ruby as a metasploit module.
Please don't get stuck focusing on the code / vulnerability (as it's simple and silly, although many times mistakes aren't much more complex but instead just basic programming 101 mistakes). Please also don't focus on the exploit / metasploit module (as it's also simple and could be enhanced to be more powerful). Instead please sit back and try to grasp/visualize the 10,000 foot high overview of how a developer writing php code and can turn into a script kiddie rooting your web server.
Now that I've set the stage, let's have some fun!
I have a website running apache (/etc/init.d/apache2 start). In the root folder of the website I have a 'hidden' administrative page that my perhaps well-intentioned webmaster decided to write so that he can work from home. Per the screenshot below it allows him to run commands like "ps -aux" if the website is running slow and determine what might be the cause.
The disgusting code looks something like this
Notice the code uses the extremely unsafe shell_exec method, it performs no input validation, and the page doesn't even require authentication. This leads to a
command injection vulnerability because I can basically run any shell command I want under the same privileges that the website runs under (www-data). Security by obscurity is perhaps the only defense here and we all know that doesn't cut it. There are 100 more reasons I could list for why this is the worst idea anybody could ever come up with, but that is for another day. Also if interested the nl2br method simply converts newlines to html breaks so the output is prettier.
Now the webmaster doesn't just host one website, he's actually provides a standard platform for all his customers and hosts this same codebase on many webservers. So this vulnerability is actually widespread across many sites on the Internet. Mr. evil attacker is recon'ing and scanning and by happenstance comes across this vulnerability. He wants to share it with the world, so he writes a metasploit module in ruby. Below you can see that ruby module, and in it the payload is 'cmd' or a command prompt. And the scarey part to me is that the actual exploit code is really short. Look at that 'exploit' method at the end, it's really really short as many of these modules are. This one simply calls an HTTP GET and passes the payload into the AdminCommand query string. Take a quick deeper look at the code below. Seriously, it's not very complex. In fact it's almost too easy.
The attacker saves this ruby file into the exploits folder (~/.msf4/modules/exploit/neonprimetime_web.rb). Then the attacker loads metasploit console (./msfconsole). Once at the msf command prompt, the fun begins. The script kiddie can say 'use exploit/neonprimetime_web', set the RHOST to the ip of the website he wants to attack. Then type 'exploit'.
Let's also look below at the Ubuntu web server now. Oh Crap! There appears to be a connection going back to the script kiddie on port 4444!
Let's look at the Apache logs. What the? That's an ugly looking bash command. No script kiddie could understand that. That's the beauty of Metasploit. It has all the pre-built payloads that open up the reverse shells and get you access into things. It does it all for you.
Script kiddie isn't done, he can run commands on YOUR web server!
Oh boy, from the ubuntu web server we can packet capture and see the commands run and the results sent back.
Script kiddie has the permission of the account running the web service. I think you're in trouble.
Now if the account running apache has minimal privileges, the attacker may have to work harder to find an unpatched privilege escalation vulnerability (buffer overflow or something) on your server and gain root. But believe me, that's not going to be hard. There are open source scripts that kiddies can run on a victim server that will crawl thru the server and literally spit out recommendations of which privilege escalation vulnerability will work for that victim. If the website is already running as root or some privileged account, well then it's probably all over, you already handed him the keys to the kingdom. He's going to create something that persists, and probably pivot to the rest of the servers on your network.
I hope you enjoyed the walk-through and it has opened your eyes to just how important writing good code, following best practices, and patching vulnerabilities is. The bad guys are good at this, they've made it mundane, simple, and repeatable. You have to work hard to protect your things.
NOTE: This example above was created with the intention to educate and create awareness only. This information should not be utilized information for anything malicious.
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
