Table of Contents:
Like many of you, I was worried about the Bricks Builder vulnerability in versions <= 1.9.6. Hats off to the Bricks team for patching the software and notifying us ASAP. That is a sign that the company cares about their users and product.
As WordPress and Bricks developers, we have to wear many different hats every day, and the security hat is by far the most stressful hat to wear.
As I see it, you have two options when an event like this one comes out. Option 1, do everything in your power to see if your sites have been compromised. Option 2, bury your head in the sand and hope you weren’t targeted. Many sites were hit and there were numerous hacks reported in the Bricks Facebook Community.
I chose option 1 and immediately started looking at my servers and sites.
In this post, I will document what I did throughout the incident. I will continue to update this post with what I have done to secure my servers and sites and share what I learned from the many brilliant people I read and learned from on Facebook and other channels.
Begin Update 2024/02/18
I had one sandbox site that was not patched by the 2024/02/14. I used this site as a testing site for new ideas. The mistake I made was not adding it to my MainWP dashboard. If I hadn’t forgotten about this one, I dpoubt it would have been compromised.
I was able to tell that the site was compromised via SFTP. There were PHP files in the root directory of the site that should not have been there.
Here is what I did to find the malware
In my GridPane control panel, I noticed my 1-click login was not working for a site. So I logged into the the server via SSH and ran the -htop command to see what the server was working on…and boy it was hard at work. CPU utilization was 100%.
I noticed the system user for this site was the same user as the site that wouldn’t connect with the 1-click login command in my GridPane console.
Next, I used FileZilla to SFTP into this site. The first thing I did was check the root directory and I saw PHP files named weird things like 7yhxh.php and other strange files. So, I knew the site had been hacked at that point.
Next, I downloaded the access log that shows who is trying to access this site to look at in a minute.
I saw on Facebook that the attackers were sending a POST method to the server with a URI of
- “/wp-json/bricks/v1/render_element/ HTTP/1.1”
I searched the log file and saw this from an IP address that was not mine….Uh-O.
I Emailed Tom at We Watch Your Website
I sent an email to Tom over at We Watch Your Website. He is highly regarded in the Industry as one of the best malware remediation experts.
He confirmed the hack from the log files and is going to review the server for any other malware that should not be there.
What Else Did I Do?
I wrote a python script to parse my GridPane access log files into an Excel sheet. The script would help me sift through the log file and search for “/wp-json/bricks/v1/render_element/ HTTP/1.1“
My workflow was:
- SFTP into a Brciks site
- download the log
- run the .log file through the py script
- look for a the telltale URI with a response code of 200
- If I had a hit for this URI, I would check the IP to make sure it wasn’t me
- If the IP was not my own, I would check the response code to ensure it was not a 200
Once Bricks patched the exploit, the log file would return a 403 code if someone tried to attack the site.
What You Can Do To Check If Your Site Was Hacked
First, get access to your site’s access log file. Then, search for the “render_element” and make sure the response code was not a 200. If you see it is a 200 response code for this line item, and the IP was not yours, you probably were hacked.
Maldet Scans On My Server
One thing I was disappointed in was Maldet scans never marked the files placed on the hacked site as a positive hit. I had been reviewing the nightly scans and everything looked fine and I was breathing easy.
End Update 2024/02/18
My Server Stack and Setup
I am a HUGE fan of GridPane and run their Developer Plus plan in my marketing Agency, Aperture Digital Marketing, and on my WAAS offering over at Busi Sites. So here is my setup:
- GridPane Developer Plus
- Snicco Fortress
- WP Fail2Ban
- 7G WAF
- Maldet and ClamAV
- We Watch Your Website
- Bricks Builder
- Bricks Forge
- Advanced Themer
- Automatic CSS
- Bricks Extras
Inside GridPane, I turn on all additional security measures they offer for almost all sites.
What Steps I Took To Secure My Websites
First and foremost, I updated every single site to version 1.9.6.1 as soon as possible. I had most sites running MainWP. With MainWP, I could bulk updated all my sites at once. Just to be safe, I logged into every Bricks site to double check they were running 1.9.6.1. This was time consuming as I have about 30 sites on Bricks. But, I wanted to make sure, so I just sucked it up and checked manually.
Next, I logged into each server via SSH and ran a maldet scan. All scans came up clean, but I didn’t think that alone was enough to call it good.
I then decided to check the wp_users table of every site to see if there were any new users created. Luckily, no new users had been added to any of my sites.
I use PHP My Admin to view the MySQL database and can easily view each table.
I Spent Alot Of Time Reading FaceBook Posts
Rick Tribe had a very thoughtful write up you can read here. I went through his list and checked for random PHP files on each website. I log into each site using SFTP and use FileZilla to browse the site’s file structure.
Rick wrote:
In most cases, an attacker will upload a backdoor to the website. This will provide them with access to your site, even after you’ve updated to the latest version, so only updating to the latest version is not enough! Some examples I’ve seen:
https://www.facebook.com/groups/brickscommunity/permalink/1321187481879102/
– wp-content/themes/593qp77o/options.php
– wp-content/themes/twentytwentyfour/Ui.js.php
– wp-includes/blocks/comments-pagination-numbers/pqniksbk.php
– wp-includes/blocks/rss/hvsjspjs.php
Another great idea from this post was to check for new files created on the site. If you have SSH access to your server, you could check for new files in the terminal.
The command to find new .php files was:
find . -type f -name "*.php" -newermt "2024-02-13"I tweaked the date a bit to check all the way back to January 25th. Do note – when you run this command, you are going to see a lot of files that were changed. You are going to have to sift through the data and see if anything looks suspicious.
I Spent A lot Of Time Reviewing Individual Files With SFTP
Once you gain SFTP access, you can see your folders and files in an easy to use GUI. Again, I use FileZilla. I did a lot of manual checks, but below is generally what I was looking for.
I Looked for strange files:
- in the root directory
- in the theme folder
- in the plugins folder
- in the wp-includes folder
- in all the folders 🙂
I searched for file types like .js and .php in the uploads folder.
I sorted large file trees by date modified to see if any files were modified recently.
All this looking and poking around is good, but there are just too many files to manually look at yourself.
I Installed WordFence And Ran A High Sensitivity Scan
I don’t use WordFence on my sites normally, but I wanted to see if their tool would pick up anything. So, I installed WordFence and ran scans. My process to run this was:
- took a manual backup called beforeWordFence
- Installed the plugin
- Ran the scan
- If the site was clean, I rolled back to the before WordFence update
I White Listed My IP Address in CloudFlare For WP Login URLs
Some may consider this step overkill, but I white listed my IP address in Cloudflare for all WP Login URLs. If Clients login regularly, I waited for them to call me and ask why they couldn’t log in. When I explained the situation, the saw me as being proactive and generally thanked me for my efforts. I would much rather tell a client that there site was locked down that saying “yea, you got hacked on my watch.”
What this means is I set a rule that blocks any one but me from accessing the wp-login.php file.
If you don’t want to straight up block users from the login pages, you can use the CloudFlare captcha challenge. I use the challenge on sites where users sometimes login.
I Contacted GridPane Support
I am trying to be proactive, so I sent support a ticket asking what my options were. GridPane is awesome and always helps out. Since I am on Dev+ plan, I have extra support options like preemptive support and vulnerability remediation for 50 websites.
The support technician said my sites and servers looked ok on their end and didn’t notice anything out of the ordinary.
My advice is to start talking to your hosting provider, people on the WP community, and ask questions if you have them.
Facebook can be a bit toxic sometimes, so try not to get worked up if someone says something mean or hateful.
I Reviewed My Disaster Recovery Budget
I have a line item in my monthly budget for disaster recovery. This money is set aside for a rainy day when disaster strikes. If you don’t have any cash set aside for something like this, I recommend you start shifting some money towards one. Start with $50 a month and go from there.
Other Security Items To Consider
Two factor authentication (2FA). If you don’t have it set up, then you should look into a security program that uses an authenticator app for 2FA. Snicco Fortress on GridPane requires 2FA with a third party authenticator app that generates a one time passcode for every admin login. You can also configure it for other user roles if you need.
Whats Next?
My next steps are to continue monitoring my sites and servers for new admin users, spikes in CPU, new posts In did not add, and new files that don’t look familiar to me.
If I see anything out of the ordinary, I am going to reach out to the numerous security firms out there to get some help. It may cost a bit of money, but that’s part of managing websites for clients.
Getting hacked is not the end of the world. But, it is extra work and you should disclose it this to your clients. You then need to work with a security agency to see about data breaches.
So, take a few weeks to read up on proper security protocols. Maybe even invest in better hosting and security software that will help you secure your sites.
Finally, ask for help. We can’t all be experts at everything. Lean on the community and ask for help if you need it. Open up your wallet and pay for help if you need it and for peace of mind.