On Hacking and Being Hacked

TLDR; If you self-host a Wordpress site, make sure you can restore from backups and check your site using wpscan and other tools regularly.

Is it irony or synchronicity when you learn hacking in more detail and end up being hacked.

Lessons learned from a WordPress hacking challenge and having your WordPress site hacked. Lessons learned from a WordPress hacking challenge and having your WordPress site hacked.

Hacking

On Monday 15th May 2018 I was working through a hacking challenge on Immersive Labs.

It was based around a WordPress site and the site was up to date with the most recent version of WordPress. I thought I was going to get nowhere, but I experimented with some tools and approaches and with a combination of wpscan, and dirb I managed to:

• gain access as an existing user
• gain access as an admin
• see the wp-config to find the database name, username and password

I was in the middle of trying to access the database when I received an email from my web host informing me that my website SeleniumSimplified.com was offline because of a malicious page.

Waagh!

Hacked

The hosting company took my site offline so any issues were not visible to me easily. I could not access my site via the IP address or the domain.

• I looked in the Google cache for the page and could see nothing obvious.
• I asked the hosting company for more detail on what their scanner had picked up.
• I FTP’d into my site to see if there were any obvious signs of tampering, which there were
• I logged into the WordPress database for any obvious signs - and there were

Taking Action

At this point I have a decision to make about what to do next:

• restore file system and database from backup and patch Wordpress
• restore backup into WordPress.com
• convert site to a pre-rendered version of the WordPress pages and remove the malicious scripts
• convert site to a static site and avoid WordPress

With each of these there are risks.

Action Risks

Testers identify Risks.

Risks of restoring site:

• what if the backup has malicious data in it?
• what if the file system and database were hacked at different times?
• what if we have no backup?
• what if the restore fails?
• what if it is hacked during the patch process?
• what if the hacker managed to get the passwords?
• what if it gets hacked again?

Risks of rendering:

• render from where? need to have the site up to crawl it for rendering?
• how to remove the malicious scripts from the rendered pages?

Convert Site:

• how long will that take?
• where will we get the data to convert from?

I decided to convert the site to a new static version using HuGo

Because:

• No future WordPress hacks - this isn’t the first time I’ve had a WordPress site hacked.
  • I think moving to a Wordpress.com hosted instance would have helped avoid this.
• No more hassle with MySQL databases and versions of PHP not matching installs
• I wanted to get something back up quickly
  • I had already converted all of my posts to HuGo and Markdown to have an offline archive in the event of any of my sites failing, over at TesterHQ.com so I could quickly create a site with all the posts, I’d just have to convert the pages.
  • I have been using TesterHQ as my source blogging platform i.e. I write my posts for all my blogs on TesterHQ in Markdown and then to publish on other sites I copy the rendered HTML into those other sites. So the content was up to date.
  • I briefly considered redirecting SeleniumSimplified.com and creating a new set of pages on CompendiumDev.co.uk but I wanted to retain the urls from SeleniumSimplified.com in Google and other search engines as much as possible.
  • I have been meaning to move away from WordPress for some time but kept putting it off because it wasn’t a priority.

Action Taken - Convert then Investigate

I decided to convert the site prior to investigating because it was more important for me to get up and running again, than know why it happened.

I copied all my TesterHQ Selenium Simplified posts into a new Hugo Instance and then copied the HTML for the pages which were not represented in TesterHQ into Turndown to convert to markdown and then created HuGo pages.

What took time?

• I experienced some HuGo issues with it not rendering the pages. I needed to update to the most up to date version of the template I was using on TesterHQ and that fixed it.
• When I migrated to TesterHQ I added meta data for the permalink based on WordPress post id, but search engines link to the readable URL so I needed to migrate all the URLS to redirect.

i.e.

http://seleniumsimplified.com/post/2017-03-16-changes-in-selenium-webdriver-3-1-0-3-2-0-3-3-0-and-3-3-1-for-java/

not

http://seleniumsimplified.com/?p=3968

Investigate

I haven’t finished investigating yet. But I do know:

• This hack took place on the 5th of May - because the image files and compromised WordPress files were added and amended on 5th May.
• When I restored the database back to 4th May, none of the injected scripts were present.
• The site had been hacked before, but I didn’t notice. I think the hacker managed to upload files to the site but hadn’t been able to use them to compromise the site.
• I found some PHP DB access and file access scripts in the root level. But these dated from earlier than May. I assume that an earlier WordPress file injection exploit was used to upload them.
• I found a file in the root folder with a set of permissions that prevented me downloading the file and properly accessing the directory.

I also know:

• my WordPress install was up to date
• WordPress was set to auto-update (was this a risk?)

I think:

• I had disabled all of the 3rd party addons on WordPress, so I don’t quite know how the Hacker gained access.
• The hacker used a tool because I searched for the injected payload and found this post, among others, describing the exact script I found injected in the database.
  • https://www.webdandy.co.uk/case-study-1-why-wordpress-maintenance-is-important/

What did the hacker gain?

I have no idea.

Current Status

• No WordPress
• Changed passwords
• Original content
• Should have all links the same
• No comments

I’ll figure out what to do with comments later. I think blog commenting is ‘broken’ generally: too much spam, I don’t particularly like disqus. I’ll need to look into a solution long term my site.

I haven’t added Google Analytics in yet.

I have to amend the site for SEO, and I haven’t double checked all page redirections or internal link redirections yet.

Lessons Learned

• Because I used WordPress with auto-updates and had removed plugins I thought I was pretty safe. I was wrong. Clearly I left something open long enough for something to get in.
• Backups are essential. Without backups I would have had to manually cleanse the database with a combination of complex SQL queries. But I still wouldn’t be sure I had completely fixed it.
• Having backups gave me a quick restore option. I could have just restored from a database and file system backup. And then deployed a new set of WordPress files. And changed all passwords. But I still wouldn’t have been sure that it wouldn’t happen again.

Monitoring:

• Bigger companies will hopefully have monitoring solutions in place to avoid this type of thing.
• The monitoring needs to be at a source level to look for anything unexpected.
• But - if you have dynamic content that you exclude from monitoring, and a hacker injects scripts into that part of your page you won’t know.
• I’m sure there are good monitoring tools available, I’m not sure if they are affordable for small companies.

I now see that I have a gap in my tool set for an effective monitoring solution for web applications.

But I also need to tool to monitor all the parts of my setup - much like when we conduct technical testing - checking results just at the GUI, isn’t enough, we need to look in the database, and on the file system, and everywhere else the system touches the technical infrastructure.

With a WordPress site I rarely have to look at the file system. I probably look at it more than most because I used to upload images via FTP into an image folder rather than using the WordPress upload. But I stopped doing that when I moved to TesterHQ because I upload all the images to TesterHQ instead. I had not identified this as a risk to SeleniumSimplified.com when I did this, but clearly this meant that I looked that the blog file system even less than before, and this made me more vulnerable to not detecting the result of file upload exploits.

Self-Hosting:

• Self-hosting provides flexibility, it also provides a maintenance headache.
• Self-hosting is a pain.
• Simple wins. Keep things simple.
• Static web sites are great for self-hosting because a restore is a re-deploy.
• If I wanted to use WordPress again I would use a Wordpress.com hosted site
• For most of the ‘open source’ forums or commenting systems etc. I would probably look for a hosted version - and yes, you do pretty much have to pay for these.
  • Make the pain someone else’s problem.

Hacking:

• There are scripts for pretty much everything to support the hacker. When I was using the hacking challenge I hadn’t used wpscan or dirb before. Within 5 minutes (max) for each, I was running them against the target and finding exploitable or useful reconnaissance information.
• If you do self-host a WordPress site then I thoroughly recommend investigating wpscan and if you self host any other site or application - do a search for tools that detect and exploit vulnerabilities in that application, then use them on yourself.

We need to learn, or know someone who will, attempt to hack ourselves first so we can protect against someone coming later.

Depending on the data you are trying to protect. Keeping things simple and having effective monitoring and recovery strategies. Might be cheaper than a complicated implementation and protection strategy.