文章

发布于

Compromised WordPress site

Today, I received a warning from Alibaba Cloud Security Center. A file scan reveals that wp-admin/network/theme-browse.php is likely a backdoor on one of the sites that I hosted. This article intends to record the findings and actions.

Immediately, I jump into confirming WordPress core’s integrity and confirm that these files should not exist:

$ wp core verify-checksums
Warning: File should not exist: wp-admin/network/test-file.php
Warning: File should not exist: wp-admin/network/manage-span.php
Warning: File should not exist: wp-admin/network/save-plugin.php
Warning: File should not exist: wp-admin/network/theme-browse.php
Success: WordPress installation verifies against checksums.

I can confirm that theme-browse.php is 100% malicious and points to a currently unavailable domain:

$switch="http://ink***ure.com/wp-includes/SimplePie/theme-captures.php?pl=2";

Action taken to reinstall all core files within wp-admin:

wp core download --force

Postmortem:

stat -c 'Path=%n
Modify=%y
Change=%z
Birth=%w
Owner=%U:%G
Perm=%a' theme-browse.php

Path=theme-browse.php
Modify=2016-03-29 14:45:30.000000000 +0900
Change=2026-01-30 12:21:27.858473359 +0900
Birth=2023-11-05 01:30:41.978928785 +0900

This shows that the file was inserted back in 2023, while the attacker backdated it to look like an old 2016 file. Further checks of my legacy backup files show that these files did exist as far back as at least 2020. Therefore, the 2016 timestamp may be correct, and the hosted site was likely exploited long before it was moved to my managed environment.

发布于

Biased Public Service Announcement – Don’t Use WordPress on App Service

It is my sincere advice to everyone to avoid using Azure’s WordPress on App Service, for the following reasons:
(Disclaimer: As the title suggests, this is biased – Azure has never been easy for me to use or understand, and I am not an Azure power user.)

  • The WordPress image relies on a Unison process to monitor filesystem events, syncing content between /home/site/wwwroot (the default FTP destination) and /var/www/wordpress (where the site is actually served).

    This introduces operational complexity to an already non-transparent build (none of this is documented in https://github.com/Azure/wordpress-linux-appservice). Even worse, filesystem monitoring never worked correctly in our environment.

    Update: After suddenly thinking to search for /var/www/wordpress in the GitHub repository, I finally found this document: https://github.com/Azure/wordpress-linux-appservice/blob/main/WordPress/enabling_high_performance_with_local_storage.md, which explains the behavior. However, it states that this feature is not enabled by default, but I don’t believe that was the case with this “Managed WordPress.”
  • It does not automatically create a Log Analytics workspace, which makes no sense to me. I’m really not a fan of how logging on Azure works – if you forget to enable a Log Analytics workspace, no logs are retained. When an outage happens, you’re left with nothing to investigate.
  • Debugging performance issues on WordPress on App Service was extremely unpleasant, especially given the lack of documentation on how Microsoft’s WordPress image actually works or what the recommended debugging steps are when Metrics provide no useful insight.

For these reasons, I would recommend everyone to just host WordPress on a standalone VM any day, or using an inexpensive managed WordPress provider from a smaller vendor.

发布于

Some recent experiences with mainstream VPNs

I have been using Cloudflare WARP+ for a while, mostly to protect myself when using public Wi-Fi. Today I thought I should give products like NordVPN and Surfshark a fresh try to see if they could surpass WARP’s performance.

During my test, I found that mysteriously both VPNs, when using WireGuard, achieved about 50% slower download speed with my ISP. Switching to OpenVPN (UDP) fixed this. However, if buying a modern VPN service only to end up using OVPN, I might as well build the server myself. (Note: NordVPN also had a much higher success rate when connecting with OVPN (UDP) compared to Surfshark, for some reason.)

In comparison to WARP, people should note that WARP was never designed to be a full-featured VPN. I mainly used it to ensure my traffic is securely sent out to the Internet. And WARP really shines in two things:

  • One click and it’s connected. No hassle. (However, server connection speed is slower than NordVPN.)
  • Really fast speeds when connecting to local websites, though not so much when multiple hops to other countries are involved.

In light of the findings above, I decided to make use of the 30-day money-back guarantee they both offer. With Surfshark, I simply told the bot I wanted a refund, got redirected to a form, filled it in, and voilà — it was done.

Now, that was a totally different story with NordVPN, despite their similar refund form. With NordVPN:

  • First, I had to provide proof via speedtest.net showing slower performance when using NordVPN.
  • Then I was asked to change protocols — which is when I discovered OVPN (UDP) actually runs faster. But again, I bought NordVPN specifically for the NordLynx protocol.
  • Finally, the live chat (Zendesk Sunshine) was a pain to use. I was asked to upload screenshots, but sending images kept failing. In the end, I managed to upload them as files.

In summary, compared to the straightforward refund from Surfshark, NordVPN really runs through their whole playbook to stop you from getting one. However, NordVPN does at least show a clear “refund request is processing” notice on their billing page, while Surfshark does not (though Surfshark will send you a confirmation email within 24 hours, according to their bot).

发布于

Quick note: 國内遞歸 DNS 支持 DNSSEC 了嗎？Nope。

~# dig @119.29.29.29 www.dnssec-failed.org. A

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> @119.29.29.29 www.dnssec-failed.org. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10361
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 400176fcef655802 (echoed)
;; QUESTION SECTION:
;www.dnssec-failed.org.         IN      A

;; ANSWER SECTION:
www.dnssec-failed.org.  3600    IN      A       68.87.109.242
www.dnssec-failed.org.  3600    IN      A       69.252.193.191

~# dig @8.8.8.8 www.dnssec-failed.org. A

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> @8.8.8.8 www.dnssec-failed.org. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 16567
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 9 (DNSKEY Missing): (No DNSKEY matches DS RRs of dnssec-failed.org)
;; QUESTION SECTION:
;www.dnssec-failed.org.         IN      A

説明：如果 www.dnssec-failed.org 能夠返回 A 記錄，則代表遞歸 DNS 沒有對 DNSSEC 簽名進行檢驗。
其他還測試了 114.114.114.114，以及 223.5.5.5，均不支持 DNSSEC 校驗。雖然 DNSPod 支持了 DNSSEC 功能，但在國内依然是沒有什麽用處。