One of my biggest pet peeves in life is having some non-techie ask me a question about how to do something the right way, then spend the next three hours justifying to me why they did it the wrong way and will continue doing it wrong. I’m not saying that I’m the best at what I do, but I am pretty good. At least, I’m better at programming than someone that has never written a line of code in their life. I don’t take my car to the mechanic and tell him how to fix it. I don’t go to the doctor and tell him how to do a surgery. No! Instead, I trust them and rely on them to do what it is that they have been trained to do.
Until about five years ago, one of the services that I provided as a contractor was network and web application security auditing. In fact, I even taught classes on how to protect your software and web applications for misuse and abuse. During a class I was teaching about PHP security & exploitation, I had a guy stand up during the middle of my speech and tell me that I didn’t know what I was talking about. He said that everything I talked about was bullshit and was not possible in the real world. More specifically, he said that my techniques could not be used against his company’s website.
So, to humor him, myself, and the rest of the people in the room, I asked if he would allow me to do a live evaluation of his website which he bravely agreed to. The first thing I asked was did he have an outward facing website? Meaning, did he have a website that could be accessed over the web? He said he did and gave me the URL to the site. So, I loaded up the page in my browser and almost pissed in my pants from laughing at all of the security vulnerabilities right there on the home page. One of the biggest and probably easiest vulnerabilities is what I’m going to share with you now.
The website that he gave me to evaluate was a blog for his sales reps. It was designed so that any sales representative could post news updates and sales lead information for other reps to follow. Although a username and password were required to gain access to the page that allowed the reps to post new messages and to view contact information, there was still a huge vulnerability staring me in the face, just waiting to be exploited. Right there on the home page was a form that allowed sales reps and their customers to upload PDF files which once uploaded were listed in a section just below the form that allowed anyone to download these files without being required to log in. So, to prove that this guy didn’t know what he was talking about, I decided to make this my first target (and it was easy enough to do to humiliate this guy a little, especially after he tried humiliating me first.)
The first thing I did to get this exploit going was I clicked around a couple of the links on the page, taking notice of what the URLs said in the address bar. Even though this guy came to my “PHP” class, I still needed to verify that his site was written in PHP. After a few link clicks on his site, I knew that it was indeed written in PHP. Already having BackTrack running for the class, I next clicked on the menu and navigated off to BackTrack > Maintaining Access > Web Backdoors > Weevely. This opened a shell prompt and displayed the usage report for the weevely.py script. Now, I could’ve easily went with the simple backdoor PHP script that weevely provided. But, some virus scanners and intrusion detection systems will detect this script as a trojan and will block it from being used. To get around that, I needed to make an encrypted copy of the file that was also password protected so that only I could make use of it. To do that, I ran the following command:
#./weevely.py -g -o /root/Desktop/hello.php -p SomePassword
The command above simply tells weevely to generate (-g) a new backdoor file and output (-o) it to my desktop as “hello.php” and encrypt it with the password (-p) “SomePassword”. I could’ve output this file to any folder on my filesystem, but the desktop seemed to be the easiest location for me to get to quickly. Anyways, now that I had an encrypted backdoor file ready, it was time to put it to work. To do that, I went back to my browser and navigated back to the homepage where the file upload form was located. From there, I went ahead and clicked the “Browse” button, selected my “hello.php” file from my desktop, and uploaded it to the server using the “Upload” button. Once the file was uploaded, it appeared in the list below.
Next, I right-clicked on the file in the list and selected “Copy Link Location”. Then, I went back to my shell prompt where I used weevely to generate my backdoor and issued a new command which told weevely to connect to that backdoor and open a shell prompt on the remote computer. Here is the command I used to do that:
#./weevely.py -t -u http://www.his-website.com/path/to/uploaded/file/hello.php -p SomePassword
As you can see in the command above, I replaced his actual URL with a dummy URL for privacy. You’ll also noticed that I passed the same password (-p) as the one I used when I generated the backdoor earlier. Once I issued this command, I was immediately presented with a shell prompt for his server. From there, I could issue any command just like I would if I was actually sitting at his computer. With a simple “whoami” command, I realized I was running as the user “apache”. I could now wreak havoc on this guy’s server and there was nothing he could do about it. However, he still wasn’t convinced that I was actually on his server. He thought that I was blowing smoke and that the weevely script did nothing more than display a fake shell prompt. So, I typed in “cat /etc/passwd” and showed him a list of the users that were on his server. To take things one step further, I issued a “wget” command to download a privilege escalation Perl scrip I had and in no time had full root access to his server.
After a few changes to his website’s homepage, he finally realized that I did indeed have full control of his server. Since the class was intended to educate developers about vulnerabilities in PHP if left untreated, I had to go into an explanation of how I did this, why it happened, and how to avoid it. I told him that all of this could have been avoided if 1) He put his file upload form behind a password protected form and 2) He added file extension checking to the code that handled the file upload. If a user uploaded a file that didn’t meet his specific file criteria, the file would be rejected. Also, this would’ve never been possible if he had “safe_mode” enabled in PHP.
Anyways, even after showing the guy that I did indeed have complete access to his server, he was still convinced that his web applications were 100% bullet proof and secure. I think that he continued believing that for 2 reasons. The first reason is because we offered ourselves to be hired as independent security specialists where we would do a complete evaluation of his systems at a cost. But, the guy seemed cheap and not interested in paying us to help him. He acted like we should do it for free. Plus, he also made a few unnecessary remarks about my age. At that time, I was only 25 years old and this guy was probably in his late 70s. During my 23 years of developing software, he’s not the first or last person to not believe in me just because I was so young. I later found out that this guy had a granddaughter that was only a couple of years younger than me. So, I can see where he felt that my young age meant lack of experience and knowledge. But, that’s for another post. 🙂
PayPal will open in a new tab.