The problem: You’ve used .htaccess / .htpasswd to restrict access to the wp-admin directory of your WordPress installation. However, when someone accesses wp-login.php, they can simply click “cancel” or press the escape key in the authentication dialog to reach the WordPress login page:
You also have to explicitly protect the wp-login.php file. Open the .htaccess file in the root directory (not in the wp-admin directory) and add something like this1:
Suppose you have a document with a date and time column. Calculating time differences is easy, you can simply subtract an earlier time from a later one1. In the screenshot below, column C shows the difference between the time in consecutive rows (column B). However, you can see that this simple approach fails just after midnight:
The time difference in row 4 is negative and also wrong. This becomes very clear when you switch to a 24h time format and enable negative times2:
Solution: Include the date in the calculation
Internally, dates are represented as whole numbers and times as fractional numbers smaller than 1 (1 would be 24h = 1 whole day). This means you can simply add date and time! Therefore, a better formula to calculate time differences is:
By including the date, this formula works fine after midnight.
A3-A2 is the simple time difference calculation we used in the beginning. (A3<A2) returns TRUE only when the next day starts and the time is “smaller” than in the row above (see row 5, column C). What makes this work for our purposes it that TRUE is evaluated as 1 while FALSE is 0 (see column D). As mentioned above, a date/time value of 1 corresponds to 1 day (24h).
In row 5, Excel is therefore calculating the difference between 24h and 23h 59min 59s, which is 1 second.
1 This will work if Excel correctly recognized the value as a time (not a text). You can test this with the ISNUMBER function which should return TRUE. 2 The easiest way to get Excel to show negative times is by enabling the 1904 date system in the advanced options. 3 If you want to see time values of 24h or more, use an elapsed time format with square brackets, e.g. [h]:mm:ss instead of h:mm:ss.
Some restaurant websites in Luxembourg are poorly designed and make it difficult to find important information (such as the opening hours, the address or perhaps a menu that has been updated in this decade). What happened yesterday was even more confusing: I was immediately redirected to a suspicious page that claimed to conduct a survey.
This is a so-called malicious redirect. The goal is usually to generate ad revenue for the hacker or to try to install malware on the vistor’s computer. I took this opportunity to test several tools which claim to be able to scan websites for vulnerabilities and malware. You’ll find the results below. Of course, I also notified the restaurant.
I didn’t hack the website.
It’s not my website, which means I couldn’t test any popular tools which have to execute code on the server (e.g. MalCare, WordFence, WP Cerber Security). These tools may be more powerful although a malicious redirect should also be detected by external scans.
This is obviously not a comprehensive test. I’m also not a security expert.
Google Safe Browsing
There’s nothing wrong with the website according to Google. However, the report was last updated on March 29, 2019 and it’s likely the website was fine then.
Hackercombat asks for a name, business email and phone number before sending you the result of the security scan. The email I received confirmed that the “website has been affected by malware” and offered a link to a page with general information and a “100% free” malware cleanup service.
Quttera‘s results were inconsistent. The website was first rated as clean. Shortly afterwards, it was classified as suspicious in a second scan:
The detailed report did not clearly identify the issue as a malicious redirect.
ReScan.pro consistently identified the malicious redirect and made it very clear that the website has critical issues.
All that SiteGuarding’s malware scanner tells us is that the website was already blacklisted by Yandex Safebrowsing. Note: This scan and the second Sucuri scan were executed several hours after the other scans.
At first, Sucuri‘s external scan failed to detect the malicious redirect and claimed that no malware was found. It did complain about HTTPS mixed content which may have been a consequence of the redirect:
When re-testing the website several hours later, the report looked quite different:
To make matters more confusing, it seems that the restaurant’s webmaster was already working on fixing the issue at this time (you can see in the second report that the CMS was now listed as “unknown”).
I gave up on Web Inspector as it was still “waiting [for] a free detection server” more than 8 hours after I first submitted the URL.
The results are not entirely satisfying. While I didn’t expect an external scan to be able to tell me how the malicious redirect was implemented, it seems that most of the tools had difficulties detecting the redirect at all. Only ReScan.pro managed to quickly and consistently identify the issue while also giving me immediate access to the report.
To put it in another way, when I notified the restaurant, the only report I could include to show that this was indeed a problem on their side was the one provided by ReScan.pro. Quttera and Sucuri did not show (clear) warnings at the time, Hackercombat did not give me immediate access to their report and Web Inspector was useless.