One of the tools offered by default in Kali and many other hacking related distros is WPscan, a black box WordPress vulnerability scanner. I wanted to learn how to use this tool because it would help with recon on CTF challenges, practice boxes from vulnhub, and even trying to keep my own blog vulnerability free.
Before I tell you more about the tool and how it can be used, I have to throw out the usual disclaimer. Do not use this tool on any WordPress site you don’t own or have permission to scan. I ran WPscan on my own blog and brought the whole site to it’s knees. If you did that to a professional blog or your company’s blog then you could have major problems when you get caught.
If you don’t have a personal WordPress instance to test, then look at getting OWASP’s Broken Web App installed. It has a vulnerable instance of WordPress included that you can scan against and even try to harden. When things break, just reinstall the VM and start over from scratch.
I have a Kali VM installed on most of my computers. By opening a terminal and typing wpscan -h you can learn about all of the options and possibilities for how to scan a WordPress instance. If you want to avoid all the “bells and whistles” then just run wpscan –url <target> –enumerate p to scan and try to find vulnerable plugins.
The scan and the results
WPscan scans the site looking for version numbers and other exposed information that can be compared to a database of vulnerabilities. While running the scan against my site, there was one vulnerability found. There was also a small issue because the WordPress version was public. I was able to research the vulnerability using the links provided from the scan output. While the “fix” isn’t a perfect patch, it’s better than ignoring the vulnerability until the next update is ready. The version was easy enough to hide by deleting the stock readme.html file.
The issue wasn’t removed on the next scan. The scanner is a quick tool to find some vulnerabilities based on version numbers and other information from the site. There’s no proof of concepts or attempts to validate if a vulnerability is a false positive.
Unexpected fun with WPScan
While running the scanner the –enumerate p option will brute force the website with requests to gather information about plugins. This crippled my site when over 20 simultaneous database connections made the site unresponsive. This wasn’t solely due to the scanner, but to the fact that I created this blog in college. Which means I took the cheap and easy route. Digital Ocean’s one click solution on the smallest VM made that possible.
The reason I’m not afraid to tell all you hackers about this is because I was able to resolve the issue with some help from friends at #misec. They told me about adding a swapfile that could help boost some power to my little VM. Since then I’ve been able to run WPscan multiple times without a single fatal performance issue.
Edit: A swapfile is NOT recommended for preventing DoS resulting from scans or a spike in traffic. This is a quick fix and a cheap band aid. If your company uses WordPress or you have a personal blog thats getting a lot of traffic, upgrade the VM or migrate to a better server that can handle the requirements. This was pointed out to me when I first heard of using a swapfile and again on Twitter after posting this.
I know there is a lot of different people reading this post; mentors, coworkers, students, friends and family. So I’ll be as thorough as possible to cover all the bases. Mainly because I’m very excited about all of this and I want to write down all of the details before it gets too late. (Feel free to skip a paragraph if it gets too boring)
First off, it is capture the flag! Why am I so pumped about a game of capture the flag? It’s the international hacker version of capture the flag!! Imagine this, Russia (the ru part) is the host. They give every team a virtual machine (vm) with a number of applications “ready” to be deployed. Each team is responsible for keeping their apps online as well trying to bring down other teams apps. Our Russian hosts have access to everyone’s apps and are able to “drop” flags throughout them. Flags are strings like “A23HFK36JG732IE436GHD8OVH1297QUF=” and you know it’s a flag because it’s 32 capital letters and numbers followed by a “=”. Each app has a unique twist that makes the game more interesting. For example, one app was written in Python, another was in C and used .cgi files (WHAT?). Some apps stored data in mysqli and sqllite databases, others used files with JSON. The variety added complexity that made the game more fun. #Misec (a local hacker group and our team) arranged people into four groups. Red team focused on attacking other apps and searching for flags. Blue team was responsible for defending our apps and hardening the server. Green team was ops, they built and maintained the network. Fuchsia team was our developers and became jack of all traits because they worked along side red team on code dives while implementing blue team’s defenses.
I was a part of the red team. I really enjoy penetration testing and I knew this would be great experience. Our team lead was Austen. He walked me through a lot of what it means to be on the red team. I’m very thankful for his help. This was my first time implementing a lot of tools on the Kali OS and I had no idea what I was doing. Last weekend was a prep meeting and I found out that my old Kali box wouldn’t update, so I had to prepare a new one during the week. #Misec was really helpful every time that I got stuck or hard a question during setup.
My day started at 3:30am with a blaring alarm clock. That was probably the worst part of the day, which also means the day would only get better right? I arrived on site around 4:20, just in time to help hang wires and bring in equipment. As everyone showed up, we brought out our machines, connected everything and got the VMs ready. I worked with Brad (Fuchsia lead) and Austen to reset the root password and config SSH so that I could log in from Kali. Once our environments were set up, the red team started looking for what ports were open and what services were listening. This was the first time we found what the apps were using. Like I said earlier in the explanation, there was a wide range of databases and languages at our disposal. Brad dumped the databases and passed it around for others to try and understand while Amanda (El Conquistador and Blue team leader) searched for passwords and configurations that needed to be updated. Otherwise other teams could use the default accounts to own us.
Throughout the morning, the green team worked to get the apps online. As they did that, the red & fuchsia teams searched high and low for vulnerabilities in our VMs that would get us an advantage against other teams. The blue team continued to check our apps and secure them as needed. I spent this time running my VM through Armitage. I wasn’t able to find any exploits right away that the apps were vulnerable to, but that was to be expected. Armitage is very automated and it’s hard to customize exploits to work with specific apps. After that turned out to be unsuccessful I turned my attention towards Burp Suite. However, I wasn’t able to configure it correctly so I turned my attention towards code dives hoping to find something obvious like SQL injection or worse. The apps were all in their own directories under home/ and it was very interesting to look through how our hosts had made the VM. As I was looking around, Austen found one of the apps used the same auth token in a cookie for every user in the app. I helped him confirm that by recreating what he did on my VM. The idea for a exploit was that if we could pick up a player’s cookies when they dropped flags off to the host, we could get into the apps they were just at. Austen also found a second vulnerability where for the Python app, the password was “hashed” by turning numbers into their ascii hex equivalent. I wrote a small python script to decode the hashes incase we ever got a hold of another teams JSON files. Just a quick note, this is the first script I’ve written to help break a web app and I was really excited to see how easy it seemed; the development background (and wide range of python libraries) really helped.
The apps go live
Between 11 and noon, the green team was able to bring our app online at full capacity. This was our first time being able to score points and everyone was really excited. However this also brought a new issue, where other teams could now attack us. The plan seems to be working pretty well though, we were earning points for keeping the app alive and no one seemed to be trying to attack the server too badly from the outside. As soon as the red team had access to other teams, we started to poke other teams servers to see what was possible. I tried to find a way to get my python script to work, but first I needed a way to find the json file. I tried calling it directly from the URL, SSH-ing into their application server, and just crawling through the app. This didn’t turn out very well so I tried another tactic. Now that we had real targets, maybe it’d be worth trying Armitage again, other applications might not be as hardened as ours, right? Well, like my VM, it didn’t return any easy results, so I abandoned the idea to return to poking at random teams’ apps, hoping to find a XSS or SQL injection bug somewhere. While I was digging around, my box froze. I have no idea why, but it used to happen all the time when I was running windows7 (I assume it was related to the hardware). I just rebooted Kali and continued my barrage of random attempts to attack other teams.
During my assault, Amanda came over to ask if we had done a game-wide nmap scan to list all of the active teams. The game was a almost 3/4 of the way done and no one on the red team had thought to scan everyone after we had gotten our apps up on the game network. Amanda showed me how to use RAWR, a python wrapper of nmap that allowed us to scan and log more cleanly then just saving nmap output straight to a text file. While Amanda filled me in, she was scanning some of the other teams’ servers. I used Python to create a input file for RAWR that would hit the production box for 254 ip addresses. As I started to run the scanner, Austen found another way to grab flags by recreating auth tokens for users of a Ruby app. He quickly wrote up a Ruby script to loop through different teams and a range of IDs (both were used to create the auth tokens) and distributed the code amongst the red team to try and crack as many teams as possible. He ran the code first and started to find flags on the other teams servers, however when he went to turn them in, the host’s scoreboard server was having connection issues.
Down to the wire
Since there were issues from the host, we tried to hold onto flags until we were able to reconnect to the scoreboard and turn them in. This was risky because it was going on 2pm and the game was only live for another hour. As soon as Austen found a valid flag, the red team started running his script over different teams trying to get their apps to give up more flags. I made a couple modifications to his script on my box so that instead of going through 100 IDs on a team, then going to another team (and so on), the script would ask me for what team to scan and wouldn’t iterate to a second team. I was able to use this modification to run a few scripts at once and try to grab as many flags as possible. As we were searching, we were able to find a good amount of flags. The second modification I was trying was to add inputs for the starting and ending IDs for the script. I couldn’t get it to work and didn’t know why until after the game ended when I asked Austen to look it over. I was still able to get 6 flags in the last ten minutes of the game and I was very excited to have contributed to increasing the team’s score. It felt amazing. At the end of the game, we were ranked 118th out of over 300 teams and I was proud to have helped and learned so much, especially since we climbed 3 ranks within the last few minutes!
I want to give a huge shout out to Misec for pooling some great local talent into an awesome team. Thanks to Steven for organizing this year’s event and to Jason for building our infrastructure/network. Also, if it wasn’t for Austen, Brad, Amanda, Wolf, Ben and everyone else who helped me and made me feel like a member of the team. I wouldn’t have been able to learn as much as I did or have as much fun without you. I can’t wait to see what will happen at ruCTFe 2016!
I’ve had a couple posts about Kali on here already. But I still haven’t had a chance to fully get in to it myself. I know, it’s tragic right? Well for those who know less than I do about it; Kali is a linux distro from Offensive Security that comes packed with tools and programs that make hacking easy. However carrying around a computer for work, one for class, one with Windows, and a tablet or two isn’t really an option, unless your bag is designed for 80lbs. A quick fix for that is to allow remote connections between other computers. My infosec mentor suggested this idea so I could have easy access to the tools available on Kali.
Setting up SSH
I want to set up an SSH port on my kali box so I can access the tools from anywhere I have an internet connection. Currently I have Kali on an old windows computer that used to run vista. I really don’t want to carry that around. However I always have my macbook air for classes so I can use that and then connect to my other, heavier, computer. Setting up SSH on a kali box is really easy, I followed one of many tutorials online and it all seems to work when i run ssh user@localhost. I even set up some cool ascii art to personalize the process of logging in. I had fun with that part.
The complicated part is my router from Comcast. For some reason I cant set up correct port forwarding so outside SSH traffic can get to my laptop. If anyone can help me figure that part out, I’d owe you one! At first I thought it was because I have a router behind a router on my network. but even after fixing that and moving to the outter network. I still can’t get port forwarding to work and it seems that it’s because Comcast doesn’t like having their rental equipment used as a network bridge. I’m not entirely sure if those reports are true; but after struggling for so long with this and not being able to get it working I’m starting to assume it’s true.
If you’ve never played with BASH/terminal or you don’t know what Linux is. I suggest you read into that first before you get much further into hacking. Most of Kali’s toys are based off of the terminal, so in order to run them, you will be typing commands like “nmap -A http://your-ip-address”. This link is Offensive Security’s website where they have some awesome documentation about what’s available on Kali.
If you want a link to learn about terminal / Linux, try here. I borrowed this link from a web administration class, but the information is what matters!
Everyone wants to break into their neighbors wifi or steal someones password at Starbucks, but depending on National, State, and local law, even packet sniffing could be illegal. So how do we safely practice how to hack before we are ready to find Sony’s back door? We set up a environment for virtual machines on our local computer or server!
For those of you who don’t know what a Virtual Machine is, it’s a “computer” inside your computer. Using programs like VMware or Oracle’s VM VirtualBox (which is free) you can have multiple systems running on your computer depending on your computer’s RAM and processing power. I suggest you download VirtualBox to get started: https://www.virtualbox.org/wiki/Downloads
After you have that installed, you need to get the operating systems that’ll make up your VMs. I suggest using Kali for your “hacker” machine and OWASP’s BWA for your “victim” machine. OWASP is a open source community for watching web application security. You should check outhttp://www.owasp.org to learn more about them. Be sure to check out their top 10 vulnerabilities for websites. You can download the files for both VMs at the links below. Special note about the BWA VM: It’s made of VMware files, there’s no installing like you would with Kali. Be sure to use an existing harddrive and select one of the files from the .zip folder you downloaded. https://www.kali.org/downloads/ http://www.slideshare.net/michael_coates/lab-setup-28126110
If you’ve never used a linux operating system before, I suggest you learn fast! Check out how to use the bash commands (terminal) and learn some of the tools that Kali has to offer.
Now, your “victim” is specifically made to have vulnerabilities! Its up to you to find them, or if you want more of a step by step then I suggest you google how to get in or check out the BWA project files
Confession: While writing this blog I got OWASP BWA working on my Windows machine for the first time. I’m very excited to try it out!