Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

On Hacking and Being Hacked

DZone's Guide to

On Hacking and Being Hacked

We investigate the lessons learned as we review the experience of one author's adventure of having his WordPress site hacked.

· Security Zone ·
Free Resource

Discover how to provide active runtime protection for your web applications from known and unknown vulnerabilities including Remote Code Execution Attacks.

TL;DR: 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?

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 easily visible to me. 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 the file system and database from backup and patch WordPress
  • Restore the backup into WordPress.com
  • Convert the site to a pre-rendered version of the WordPress pages and remove the malicious scripts
  • Convert the site to a static site and avoid WordPress

With each of these, there are risks.

Action Risks

Testers identify risks.

Risks of restoring the 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? Do we need to have the site up to crawl it for rendering?
  • How do we remove the malicious scripts from the rendered pages?

Converting the 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.
  • 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. They're 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 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 knowing why it happened.

I copied all my TesterHQ Selenium Simplified posts into a new Hugo Instance, then copied the HTML for the pages that 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 metadata 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.

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 at 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 from downloading the file and properly accessing the directory.

I also know:

  • My WordPress install was up to date
  • WordPress was set to auto-update

I think:

  • I had disabled all of the 3rd party add-ons 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 a post, among others, describing the exact script I found injected in the database.

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 long-term solution for 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 toolset 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 filesystem. 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 at 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, but it also provides a maintenance headache.
  • Self-hosting is a pain.
  • Simple wins. Keep things simple.
  • Static websites 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.

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. 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) to 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.

Find out how Waratek’s award-winning application security platform can improve the security of your new and legacy applications and platforms with no false positives, code changes or slowing your application.

Topics:
security ,hacking ,wordpress ,backup ,hacked

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}