WordPress Hacks

1. WordPress Hacks A Valpo Hacks Presentation April 2017

2. Prereq • Kali 2. Download the ISO at https://www.kali.org • For this hack we recommend using a Live USB stick or full installation rather than a Virtual Machine (because the password cracking which requires full use of hardware for CPU and GPU)

3. Overview • We will be demonstrating how to hack a WordPress website and escalate to SSH server access through a very common vulnerability (SQL injection) • The majority of the presentation will NOT be specific to WordPress, almost everything will also apply to Joomla!, Drupal, and other popular CMS and custom web applications • Everyone is invited to participate in hacking the vulnerable WordPress website which we are hosting at https://1337.valpohacks.com/c1 • Anyone can practice hacking the website before, during, or after the meeting. Don’t worry about breaking anything, the entire site is wiped and restored every 3 hours.

4. Agenda (1 of 2) • Quick Valpo Hacks history • 1. Why would anyone want to hack your WordPress? • 2. Perform some common web hacking recon tasks with ‘wpscan’, ‘nmap’, ‘w3af’, ‘dirbuster’, ‘nikto’, and Google • 3. SQL injectable plugin discovery • 4. Use ‘sqlmap’ to dump wp_users table which will give us WordPress usernames and hashed passwords • 5. Offline bruteforce of hashed passwords using hashcat (CPU or GPU cracking) and ‘rockyou’ wordlist will reveal several weak passwords • 6. We will log into WordPress CMS with admin user, and edit a PHP page to insert a PHP backdoor which we will create using ‘weevely’

5. Agenda (2 of 2) • 7. We will use weevely to escalate to SSH access by digging • through PHP files and looking for passwords stored in • plaintext config files. We could also check in bash history • for a root password used in a command, and check the • database for passwords stored by plugins. • 8. After finding a few possible passwords, we will try to log in to SSH with them. We will find the password for the ‘one337’ user and log into SSH. • (Normally after obtaining SSH access at a non-root level a hacker would then look for ways to escalate to root, but we will end the presentation at SSH access of normal user because we don’t want to expose a rootable server to the internet) • 9. Security Recommendations

6. Valpo Hacks History (1 of 2) • This meeting is our 1 year anniversary of the group • so I wanted to take a minute to give new members a quick history • The short story is it began in March last year when I was looking online to find other people in Valparaiso who were also into bitcoin. I found @bool (Valpo Hacks Co-founder). I sent him a message on twitter and he wanted to meet at Figure Eight to talk about it sometime, so we did and he also invited another friend. • It turned out that we all had an interest in hacking/cybersecurity as well, and @bool suggested we start a meetup so we could meet others in the community with similar interests and we could present on cybersecurity related topics • So Valpo Hacks was started and we had our first meeting April 10, 2016 • @cameronbanga (Valpo Hacks Co-founder) found us through @bool’s initial reddit post and the three of us have coordinated the group since then

7. Valpo Hacks History (2 of 2) • More Info: • We have a meetup page here: https://www.meetup.com/Valpo-Hacks-Meetup/ • You can download this presentation and others from our • website here: https://www.valpohacks.com • Be sure to ask for an invite to our Slack chat channel where we currently have 42 members of Valparaiso's IT community at • https://Valparaisodevelopers.slack.com

8. 1. Why would anyone want to hack my WordPress? (1 of 2) • Maybe your WordPress is just a blog about cats, no one would want to hack that right? Who would care to steal control of your cat blog? • A WordPress blog about cats is still a major target for hackers, here are some motivations that a hacker might have for hacking a seemingly useless blog site: • #1 – To use your site as a platform to launch attacks on other sites. Your site may not contain anything useful for a criminal hacker (no credit cards, no social security numbers etc), but the hacker still can use your site to cover his tracks by making it the origin of other attacks. Also, your bandwidth (internet speed to your webserver) is valuable because it can be used to DDoS other sites. • #2 – To use your site as a malware host. Cyber criminals want to infect as many computers as possible to gain credit card info or whatever they are looking for, and they need a webserver to host malware which they trick end-users into downloading and installing. The problem is, the webservers that they host the malware on are constantly being discovered by anti-virus companies (cat and mouse game), and being blocked, so they constantly need new domain names, new IP addresses, and your insecure cat blog will work just fine for that

9. 1. Why would anyone want to hack my WordPress? (2 of 2) • #3 – To use your webserver for email spam campaigns. • Similarly to malware sites constantly being banned by AV companies, so is true with spam servers. The cyber criminal constantly must find fresh domains and IP addresses to spam from. • #4 – Bragging rights. Lots of hackers are just bored teenagers whose crime of choice is cyber graffiti. They want to tag their name all over your cat blog and brag to their friends about how they ’pwned’ you. • #5 – Hacktivism. Your cat blog might be hacked by a bunch of cat haters (you never know). Hacktivism (political or social motivated hacking) is a motivation of many hackers. • #6 – Cyberwarfare. Against a cat blog? It is possible. There are many groups of hackers who aim to cause cyber damages to the United States government and businesses. Your cat blog may be a target just because of where it’s hosted or where you’re from.

10. 2. Web Hacking Recon (1 of 3) • The purpose of our recon is to find out as much as possible about the web application, the framework or CMS used, the language written in, the webserver OS, libraries or plugins used, and even more information about the owner (check domain registration records, email addresses on website, Google etc), the webhost, other sites on the same server (the target site might be very secure, but if there is an insecure site on the same server it might be an easier entry point). The more you know about how it works, the easier it will be to find out how to break it and discover a security flaw. • We can check if this site is a WordPress install by navigating to 1337.valpohacks.com/c1/wp-admin and see if the login page comes up for example • Builtwith.com is a tool that might give us more information also

11. 2. Web Hacking Recon (2 of 3) • Once we have discovered the target site is running WordPress, we will want to find out more about the theme used and plugins • ‘wpscan’ automates the process, it can discover the theme, plugins, and list potential vulnerabilities. It can also enumerate usernames, and bruteforce passwords if desired • We can use nmap to check which ports are open. 80 is for HTTP traffic, 443 is for HTTPS traffic, those ports we expect to be open. Other common ports are 21 – FTP, 22 - SSH, 53 – DNS, 25 – SMTP, 143 – IMAP, 993 – Secure IMAP, 110 – POP, 995 – Secure POP. Anything other than those might be interesting to look into. Especially look out for port 8080 or 8443, these are non-standard HTTP and HTTPS ports which can typically be opened by going to http://site.com:8080 or https://site.com:8443. It might be an insecure default page for some kind of application or something which you can take a look at.

12. 2. Web Hacking Recon (3 of 3) • ‘w3af’ is an automated webscannerthat comes with Kali. However, some problems with it: it is very noisy (generates tons of red flags for anyone monitoring the site), it gets IP banned very quickly if the site has any kind of security (web application filter) in place. It typically will generate lots of false positives, but occasionally will find something interesting like an SQL injection. Be careful with it, it can sometimes unintentionally cause websites to crash from the flood of requests that it sends. • Dirbuster:dirbuster is a very useful recon tool. It does a bruteforce search on a webserver for directories and files. It can find interesting things sometimes – like a database backup that the web admin accidentally left in the public_html directory • Nikto:Nikto is a webscanner like w3af, it can find more information about the webserver, and sometimes turns up some interesting configuration mistakes or admin tool pages that were accidentally left open on the server • Using Google for recon: You can look for all pages indexed by Google by searching “site:yoursite.com”. You can also search for just php pages by searching “site:site.comext:php”. There are many variations which can turn up more targets for hackers to look into.

13. 3. SQL injectable plugin discovery (1 of 3) • I’m not going to perform all of the recon tasks that I discussed, but lets take a look at wpscan real quick • Wpscan –e –u 1337.valpohacks.com/c1 • This will output some information about the WordPress version, theme, plugins, and it will enumerate usernames • <I will discuss the results of the output> • Lets also do an Nmap scan. I will use the GUI version of Nmap called Zenmap • Port 22, 80, 443 are open. We also find out the server OS is Debian and versions of OpenSSH and Apache servers. We could look into potential exploits for those. SSH being open is a good thing, it means there is hope for us to get command line control of this server remotely. • Let’s manually inspect the website itself. • We can see that it is a simple one page website. If we right click we can inspect the HTML, CSS, Javascript code if we are interested. Another important thing we can do is click the network tab and see what is loaded when the page loads, which may give us other files to take a look at.

14. 3. SQL injectable plugin discovery (2 of 3) • When we refresh the page with the network inspector open, we can see all of the files that are loaded – images, css, javascript files etc. • We are looking for any place where the user can interact with the server. We see the contact form allows for user input, and the review form as well. These are potential injection entry points. For the Review form we would likely be trying SQL injection because we can assume that the input is going to be passed to a database to be stored. For the contact form, we know that the input is likely to be sent in an email to the site admin. If we attacked this we might be trying to inject email headers which would allow spam to be sent to a victim email address rather than the contact message to be sent to the site admin. • When we click page “2” to see more reviews, we notice in the inspector network tab (and page URL), a GET parameter being submitted – “/?srm-page=2”

15. 3. SQL injectable plugin discovery (3 of 3) • To test that GET parameter to see if it is SQL injectable we can use sqlmap, which automates the process of discovering and exploiting SQL injection. • In terminal of Kali, use this command to test the GET parameter for SQL injection: • Sqlmap –u “https://1337.valpohacks.com/c1/?srm-page=2” • A Boolean-based Blind SQL injection vulnerability is discovered, the • backend database is found to be MySQL • Now we can use this vulnerability to look around inside the database, and dump the usernames and password hashes for WordPress users • To discover the database tables: • Sqlmap –u “https://1337.valpohacks.com/c1/?srm-page=2” --tables

16. 4. Use ‘sqlmap’ to dump wp_users table • We found 2 potentially interesting tables: wp_users and srm_users • Wp_options is also of interest because plugins sometimes store usernames • and passwords there as well • Lets dump both of those: • Sqlmap –u “https://1337.valpohacks.com/c1/?srm-page=2” –T wp_users,srm_users,wp_options –-dump • It will ask if we want to store hashes for later cracking, say yes • It will ask if we want to crack the hashes, say no (we will use a different tool to crack them) • Now we have our wp_user dump and we are ready to crack passwords. Also we were able to get some more information on the reviewers, but that doesn’t interest us very much. • We did find email username, password, and server settings in plaintext inside of wp_options however. A hacker could use this to send spam/malware. We should make note of the password and check later to see if it is reused in other places like for the SSH user for example.

17. 5. Offline GPU or CPU bruteforce of WordPress hashes using hashcat (1 of 4) • Now we have dumped the WP password hashes, we can see it was output to: • /tmp/sqlmapfm4NSH2862/sqlmap-hashes-YneKVz.txt • (for me anyways, it will be different location for you, check your sqlmap output) • Open file finder and hit ‘CTRL+L’ to change directory to ‘/tmp/’ then you can find your sqlmap hash output there • Remove the username and ‘:’ from the beginning of each hash, and save the edited file to Desktop • Open terminal and ‘cd Desktop’ • Now we will crack the hashes using hashcatCPU, however keep in mind if you have a Nvidia or AMD GPU it can greatly speed up the process

18. 5. Offline GPU or CPU bruteforce of WordPress hashes using hashcat (2 of 4) • First we will check to make sure we have the proper drivers installed to use hashcatCPU based cracking. • In terminal type “hashcat –-benchmark”, if it doesn’t output an error about • device not being found, then it is working, else you will need to Google the • error and find driver install instructions • Hit CTRL+C to stop the benchmark • Type ’locate wordlist’ to output all wordlists installed on Kali • The wordlist we will use to bruteforce with will be /usr/share/wordlists/rockyou.txt • The command to start the WP password cracking is (from Desktop directory): • Hashcat –m 400 –a 0 –o cracked.txthashes.txt /usr/share/wordlists/rockyou.txt • Command explanation: The ‘-m 400’ sets the mode to 400 which is the WordPress type of hash, -a 0 sets the attack to 0 which is ‘straight’ aka dictionary attack, the ’-o’ specifies an output file of cracked.txt to output cracked passwords, hashes.txt is the file containing the WP hashes to crack, and the last input is the location of the wordlist.

19. 5. Offline GPU or CPU bruteforce of WordPress hashes using hashcat (3 of 4) • You can press ‘s’ at any time to update the status of the crack • On my cheap laptop CPU, it estimates that it will take 5 hours, but on my 4GB GPU at my home desktop this would take only 2 minutes! • So I will RDP into my desktop at home and run the crack there. Here’s the GPU I bought a few years ago (AMD Radeon R9 290X):

20. 5. Offline GPU or CPU bruteforce of WordPress hashes using hashcat (4 of 4) • After the cracking finished, we see we were able to discover 3/5 of the WordPress passwords because they were in rockyou.txt • The 3 passwords are: valparaiso07, indianapacers, and 2194336487 • Now we have to compare the hashes to see which username and password go together (open cracked.txt and compare to our original output in /tmp directory in Kali) • Now we can see superadmin = indianapacers, kevin=valparaiso07, and vwc = 2194336487 • Now we can log in as each user and see what kind of privileges they have inside WordPress (we want an admin account, but some of these might not be admins)

21. 6. Plant PHP Backdoor in WordPress (1 of 2) • Go to https://1337.valpohacks.com/c1/wp-admin to test logins • We test ’superadmin’ but find out that he doesn’t actually have admin privileges, he appears to just be a subscriber, the lowest level user in WordPress • We test ‘kevin’ and we can see he has more privileges than superadmin, but we know he isn’t an admin because he is missing some module sections like ‘Plugins’ and ‘Users’. He is not able to create new users or view existing users for example. • We test ‘vwc’ and we have finally found our admin account. We can tell it is admin by going to the Users menu and we can see vwc’s role is “Administrator” • Now it is time to create a PHP backdoor which we will plant inside WordPress to get server level access. We will create the backdoor using a program called ‘weevely’

22. 6. Plant PHP Backdoor in WordPress(2 of 2) • Open terminal and type in ‘weevely’ to see options • Create a backdoor: • weevely generate backd00r ~/Desktop/Backdoor.php • This will generate a backdoor with password ‘backd00r’ in root’s desktop directory • Right click the backdoor on the desktop and “Open with Text Editor” • Copy all of the contents to clipboard (CTRL+A to select all then CTRL+C to copy) • Login to WordPress with the admin account (vwc) • Go to Appearance > Editor • Click 404.php under templates to edit the 404 page • CTRL+A to select all PHP code on the 404 page, then CTRL+V to replace it with the PHP backdoor • Click “Update File” to save changes • We can now connect to our PHP backdoor! Use this command in Kali terminal: • Weevely“https://1337.valpohacks.com/c1/wp-content/themes/sydney/404.php” backd00r

23. 7. Escalate Priv from PHP Backdoor to SSH (1 of 2) • Now we are connected to the PHP backdoor which serves as a command-line like interface to the webserver. (It’s very simple in theory, it is just accepting your command-line input through a web request, passing it to the webserver command line via a PHP call and then returning the output back to you) • It is limited in someways to SSH due to the fact it is being passed through PHP, but can do most basic things like viewing/editing files, changing directories. There are also modules built into weevely that make more complex operations simple. Type ‘:help’ from a connected weevely backdoor to see weevely’s options • Enter ‘:system_info’ which is a weevely command to grab more info about the server we are connected to • Enter ‘:audit_filesystem’ which is a weevely command that will find which directories and files our user has permissions to access on the webserver • Enter ‘cd c1’ to navigate to the c1 directory • Enter ‘ls’ to see files inside this directory • Enter ’cat wp-config.php’ to view the contents of the wp-config.php file

24. 7. Escalate Priv from PHP Backdoor to SSH (2 of 2) • We have found a password for the database inside wp-config.php. We will make a note of this password to check later if it has been reused for the SSH password • Lets also check bash history to see if there are any passwords stored there. Bash history is a history of commands entered by the user while logged into SSH. To view it, go to the user’s home directory at /home/one337 and then enter ‘cat .bash_history’. We find what appears to be a root password that was used to log into MySQL! • Now we are ready to attempt to log into SSH using the passwords that we have uncovered. First we would try root and P@SSW0RD!, but it doesn’t work (because Valpo Hacks didn’t want to expose a rootable server to the internet) • The :system_info command returned the username of the user that we are backdoored into. You can also type ‘whoami’ to findout that username which is ‘one337’. Lets try some passwords that we have found to SSH in as this user

25. 8. Login to SSH (1 of 1) • The passwords that we have discovered so far are: • indianapacers(a WordPress user password) • 2194336487 (a WordPress user password) • Valparaiso07 (a WordPress user password) • P@SSW0RD! (found in .bash_history) • myEmailP@$$isverysecure (found wp_options table) • Valp0H4xz! (db password) • After trying all of these passwords to log into SSH as user “one337”, we find that the correct password is ‘Valp0H4xz!’. Apparently the web admin used the same password for his database as he did for his SSH user in this case, bad idea but common problem.

26. 9. Security Recommendations (1 of 3) • 1. Learn Linux if you are a Linux web admin/sys admin. If you like IT certs like I do, you might checkout Linux+ or LPIC-1 certification which can pad your resume and increase your knowledge in Linux basics such as filesystem layout, basic security, common commands, config files, scripting, email, databases etc. The more you know about how it works, the easier it is to secure it. • 2. Understand Linux file permissions. It really only takes a few minutes to learn the basics https://www.linux.com/learn/understanding-linux-file-permissions • 3. The most common hacks are because programmers forget to sanitize input from users. Learn how to filter SQL injection in order to handle queries securely. Don’t roll your own input filtering solution, rely on tried and true libraries. Know that anytime you are accepting input from a user and doing something with it on the server side, it is a potential security hazard. • 4. Never allow editing of executable server side code (like our 404.php page) from within your CMS. This can be disabled in WordPress by adding a parameter inside wp-config.php: • ## Disable Editing in Dashboard • define('DISALLOW_FILE_EDIT', true); • That would have prevented us from inserting the PHP backdoor from WordPress admin by editing the PHP code. • 5. WordPress admins – recommended security reading: https://codex.wordpress.org/Hardening_WordPress

27. 9. Security Recommendations (2 of 3) • 6. Don’t forget that your bash history is saved to a log file. You might want to disable that • When entering passwords, you should request a prompt rather than entering it in command-line so that it won’t be logged. For example, rather than doing this: • Mysql –u root –pP@$$W0RD! • Do this instead: • Mysql –u root –p • After you hit enter, it will prompt you for a hidden password entry which will not be logged to bash history. • 7. Don’t use weak passwords or you will get bruteforced or dictionary attacked online/offline. Set password requirements to try to prevent your users from using weak passwords • 8. Don’t reuse passwords. Always use a different password for everything, as you saw we were able to get the SSH user password because the web admin had reused it when creating the database user and password which we found in plaintext inside wp-config.

28. 9. Security Recommendations (3 of 3) • 9. Also be aware of passwords that are stored in plaintext files like wp-config • 10. Don’t use your own email address when setting up plugins like WP-SMTP or other web application mailers. The credentials were stored in plaintext in the database. It is better to have a ‘no-reply@yoursite.com’ email address there rather than your primary email address just incase the credentials become exposed, it would be less of a security breach. • 11. Never use root account for website database access, always create a user with access only to the database the web application needs access to. • 12. Learn how to hack as we did today so that you can pentest your own websites. This ‘reviews’ plugin was a real life example of a bad WordPress plugin I had installed for a client’s website. After I tested it for SQL injection I found it was injectable, and I contacted the developer. He fixed it and released a new version, so I was able to protect my website and many others who downloaded the plugin. Don’t trust any plugin, hack them all and help secure them for others!

29. A quick look at the SQLi vulnerable plugin code • Vulnerable Code (GET input placed directly into SQL query): /* retrieves the reviews from the database */ publicfunctionget_reviews_by_container($page) {         global $wpdb; $reviews = $wpdb->get_results('SELECT * FROM '.SRM_DB_REVIEWS.' WHERE  container_id = ' .$page. ' AND status=1');         return stripslashes_deep($reviews); } • Fixed Code (GET input cleaned by WPDB object and then added to placeholder in SQL query): /* retrieves the reviews from the database */ public function get_reviews_by_container($page) { global $wpdb; $reviews = $wpdb->get_results( $wpdb->prepare('SELECT * FROM '.SRM_DB_REVIEWS.' WHERE container_id = %d AND status=1', $page) ); return stripslashes_deep($reviews); } More info on WPDB https://codex.wordpress.org/Class_Reference/wpdb