“The Wordfence Web Application Firewall has blocked 467 attacks over the last 10 minutes. Wordfence is blocking these attacks, and we’re sending this notice to make you aware that there is a higher volume of attacks than usual.”
If it’s your first time to have received an email like this, it can cause your heart to skip a beat or two. But you shouldn’t really worry and honestly, there isn’t much you can do anyway. This message is proof that Wordfence, your friendly WAF for your WordPress blog, is working as intended.
This blog post will focus on some of the most common types of attacks I have recently observed against my website, followed by mitigation suggestions and a summary of points on how to make your own website most resilient to these and other attacks.
Suggestions and tips are welcome, as always. Let’s go.
Connections from bad reputation IP addresses
One of the most basic, most commonly encountered and easiest to detect types of malicious activities are the incoming connections to your website or web application from IP addresses with bad reputation.
This kind of activity is largely automated and executed by crawlers and scanners that search for vulnerabilities, misconfiguration and other weak points that can be exploited.
MITIGATION: Employing spam filters, blocklists or geo-blocking techniques to disallow connections from known bad IP addresses and high risk countries. Also using some of the dedicated plugins for WordPress.
More often than not, connections from bad reputation IP addresses are linked to spam campaigns, which brings us to the next item on this list.
Example: https://www.talosintelligence.com/reputation_center/lookup?search=41.98.208.139
Spam
Spam is as old as email, but the spam hitting websites and web apps is a bit different to what you would expect to see in your inbox.
The most common spamming methods include attempts to bulk-post comments under blog posts and articles. These comments will usually include URLs of suspicious websites – anything from advertising drop-shipped products to financial scams and suspicious substances vendors.
Note that the more malicious spam campaigns will proliferate URLs that lead to risky websites, where malware drive-by download could be a real possibility.
You might also see spam sign ups to your newsletter, which can result in multiple fake email addresses appearing in the subscription list, resulting in a slower distribution of your newsletter.
MITIGATION: Same as above + regular manual reviews of the approved comments to catch and delete those that somehow managed to bypass the automated filters.
Rogue login attempts
This malicious activity can come in several different flavours – from attempts to log in as a user to admin account brute forcing. Often a simple user account takeover attempt is an action against that particular user, not the entire platform – but if the attackers can gain admin access, they can do much more damage that way.
Attackers often try inputting generic credentials – I see these attempts nearly every week (login: admin; password: admin, etc.). More sophisticated actors might delve into data breach records to find your old email addresses and dig up your old password if they were in a breach. They will then try to feed those credentials into the login panel, in the hope that you were lazy and decided to reuse some of the passwords.
MITIGATION: Do not use default credentials! Use unique, alphanumeric passwords too. If you have test or service accounts, make sure you disable them if they are not in use. Unused and old / dormant accounts should be deleted as well. To protect against brute force attacks, use plugins that limit login attempts or other similar solutions. Finally, enable multi factor authentication on all accounts.
Connections from parties with a malicious user agent
This is a threat that can be closely related to any and all of the above mentioned ones.
The detection is based on identifying HTTP requests involving user agent headers with client information. These by default reveal the web browser type & version, the operating system, platform, etc.
When malicious activity such as brute force attacks or malware proliferation takes place, user agents commonly associated with this activity can be blacklisted and any future similar connections dropped.
Certain types of malware for example often use a particular HTTP user agent for communicating with the C2 servers. Check out the Github repository below for a large list of examples:
https://github.com/mthcht/awesome-lists/blob/main/Lists/suspicious_http_user_agents_list.csv
MITIGATION: Enable a WAF or a similar type of a connection filtering system. To bolster that setup, you can import a list of malicious user agents like the one above and customise the filtering rules accordingly.
Malicious file uploads
Every blog or personal website offers the feature of uploading files – but naturally, the idea is that the upload function is exclusively for users and admins with the correct permissions.
Rogue actors attempt to upload files without permissions, hoping that the website’s or web app’s server is misconfigured and that it allows code execution. Instead of uploading images or videos like a regular user would, the attackers will try to upload executable code, like PHP scripts or JSP files.
MITIGATION: Anti-malware solutions can be used to scan any uploaded files. Beyond that, robust server configuration, patching and updates are always recommended.
Unauthenticated file downloads
This attack is made possible by the vulnerability described in CVE-2019-19985 – basically, some really old versions of the Email Subscribers & Newsletters plugin for WordPress are vulnerable to unauthenticated file downloads, resulting in data breaches and unauthorised disclosure.
I do my best to patch and update everything I can on the day of the patch release. I doubt these attacks were targeted ones, since I would not have software with a 5 year old vulnerability just sitting there, ripe for the hacking. But I’m sure there are still websites out there that do…
MITIGATION: Patch, patch and patch again. Also, be sure to uninstall any unused or redundant plugins, if you don’t need their functionalities on the website.
Cross-site scripting (XSS)
This is a very well known attack – cross-site scripting is a type of a code injection attack. The attacker basically injects script code into the web pages in a way that might involve an element of social engineering – for instance, using a malicious link sent via email.
The malicious script will be injected into user-provided input. This attack can also be carried out by modifying requests. The consequences of XSS can include malicious redirection, capturing user credentials (as they are being typed on a malicious clone website, for example) or the execution of various browser based exploits.
It’s worth noting that XSS can occur in one of the three variants:
Stored XSS – the malicious payload ends up getting stored in a database, comment field or anywhere where user input is accepted. It can affect subsequent user interactions.
Reflected XSS – it occurs when user input is being returned to the user, like in the instance of a webform where a user submits their name and then sees a new page that reads: “Hello, name”. The difference is that instead of the “name” value the user receives the malicious script and could end up getting redirected to a malicious website.
DOM-based XSS – the malicious script is injected into a response. It involves manipulating the document object model (DOM) data to craft a malicious URL. Worth noting that the DOM-based XSS attack happens on the client browser.
Examples of XSS code recently used to attack my blog:
1'"()&%<zzz><script>alert(document.domain)</script>
</script><script>alert(document.domain)</script>
url=%22%3E%3Cscript%3Ealert(document.domain)%3C%2Fscript%3E
MITIGATION: There are a number of techniques that can be used to stop the XSS attacks, with the main one being input sanitisation & validation – which basically means disallowing some special characters such as brackets to disable script execution. Read more about XSS prevention in this OWASP Cross Site Scripting Prevention Cheat Sheet.
Directory traversal
Another attack method that targets vulnerabilities arising from misconfiguration. Directory traversal can be effective when web servers allow the inclusion of operators that navigate directory paths. Moreover, file system access controls don’t restrict access to files stored on the server.
The idea here is to exploit the directory structure in the search of a file that contains hashed user passwords, outside of the areas of the filesystem that are reserved for the web server.
Example attack:
rev = a/../../../../html/pix/f/<input><img src=x onerror=alert(document.domain)>.png
_variables = {"_metadata":{"classname":"i/../lib/password.properties"},"_variables":[]}
MITIGATION: Regular patching is a solid defense mechanism. User input validation also works.
SQL injection
Another well known type of an attack, this time directed against databases. It can target both the confidentiality and the integrity of the database – SQL injections typically result in data breaches or unauthorised records alterations.
Various SQL commands can be injected into the fields that accept user input. This results in the execution of predefined SQL commands and subsequent exploitation.
Example:
cat_list = (SELECT(0)FROM(SELECT(SLEEP(6)))a)
MITIGATION: Check out this OWASP SQL Injection Prevention Cheat Sheet for a comprehensive guide.
SUMMARY
So here’s what I do to keep my own site as safe and secure as I can:
- ABP – Always Be Patching – regular application of patches, updates and security fixes is mandatory for the online wellbeing of any website or web application. Make sure to set up email alerts and notifications for whenever a new patch becomes available. Don’t put it off, do it now.
- WAF – Web Application Firewall – you can install Wordfence for free on any WordPress site, so there is really no excuse not to. With a small amount of tuning it takes care of over 90% of the problems for you in an automated way.
- 2FA – two factor authentication – ideally a hardware token or a mobile OTP app. Mandatory layer of defence in the event of unauthorised disclosure of your login credentials.
- Credentials hygiene – strong, unique password (not reused!), stored encrypted in a password manager.
- Hardening – this means removing all unused themes, plugins, accounts, forms and pages. The ultimate goal is to reduce the potential attack surface.
- Monitoring – regardless of the good setup, you still have to keep an eye on everything and dabble in the security settings from time to time.
Great overview of the most common attacks and defense methods. Perhaps it’s worth adding something about the importance of creating regular backups? This can be the last line of defense in case of a successful attack.
hehhwujvwvgdvvuaub