burkingman

@alexanderfoxc: To answer your question… I’m not sure what my debug log looked like. I updated the plugin immediately after noticing the hack and lost the old log. I tested afterwards and did see “[credentials hidden]” in the log. That’s probably how it was in the old log. Fortunately, I’d updated all my plugins not that long ago so I was running a fairly recent version.

Glad to know how the hack happened. Obviously, a combination of factors were involved. A default WordPress install isn’t that secure and a number of users probably don’t do much to harden their site: with that in mind, anything that can be done to make the plugin more secure will certainly be helpful. Glad to see some good ideas being brought up, and a quick response from the devs.

Thanks a lot to @mathieg2 for that .htaccess Options trick. Feels like I should have known that already; still, better late than never.

Thanks also to @wpinsider-1 for providing a security upgrade so quickly. I’m keeping my debug log deactivated for now: I noticed if I reactivate it, it gets created under the same filename as before, so the hacker could access it again since they already know the URL. As a workaround, I may modify the log filename in the WordPress database, but I wonder: could it be helpful, in future versions of the plugin, if a new log filename was generated whenever the debug log is reactivated? I hadn’t realized how much sensitive information goes through that log (since my first post, I figured out how precisely how the hacker managed to take over my account)…

I just encountered the same problem. As far as I can tell, the very first thing the hacker/bot did was access the Easy WP SMTP plugin. Then they seemed to know the exact filename for the debug log — and I checked: I can access that txt file directly from any browser without first logging into my WordPress admin account.

They then tried to find out my username using a couple of tricks which don’t work on my site (I’ve made the necessary modifications to counter those tricks a while back).

After that, they issued what looks like a “reset password” command using my WordPress username and a very specific 20-character key (not sure yet where the key came from), followed by a few attempts on the same URL but without the key or username. Then they came back and it looks like they managed to 1) enter the WordPress admin interface, 2) upload a malware plugin to my site (“Three column screen layout”, in a folder with a random-looking name), 3) execute it and 4) access the Easy WP SMTP settings page.

This all came from different IP addresses, but note the user agent string with the same spelling mistakes in it (“Mozlila”, etc.).

Here are the relevant entries from my access log (I’ve used curly braces to indicate information I’ve removed):

212.227.174.234 – – [06/Dec/2020:06:55:42 -0800] “GET {Easy WP SMTP plugin folder} HTTP/1.1” 200 4531 “google.com” “Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36”
41.230.236.11 – – [06/Dec/2020:10:25:40 -0800] “GET {Easy WP SMTP plugin folder with a couple of request parameters — I can email them to you} HTTP/1.1” 200 4714 “www.google.com” “Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36”
41.230.236.11 – – [06/Dec/2020:10:26:15 -0800] “GET /wp-json/wp/v2/users/1 HTTP/1.1” 404 4901 “www.google.com” “Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36”
41.230.236.11 – – [06/Dec/2020:10:26:51 -0800] “GET /?author=1 HTTP/1.1” 301 4432 “www.google.com” “Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36”
41.230.236.11 – – [06/Dec/2020:10:27:22 -0800] “GET {precise URL of the Easy WP SMTP debug log} HTTP/1.1” 200 35009 “www.google.com” “Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36”
41.230.236.11 – – [06/Dec/2020:10:28:04 -0800] “POST /wp-login.php?action=lostpassword HTTP/1.1” 302 4538 “www.google.com” “Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36”
41.230.236.11 – – [06/Dec/2020:10:28:47 -0800] “GET /wp-login.php?action=lostpassword HTTP/1.1” 200 5705 “www.google.com” “Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36”
41.230.236.11 – – [06/Dec/2020:10:29:20 -0800] “GET {precise URL of the Easy WP SMTP debug log} HTTP/1.1” 200 35299 “www.google.com” “Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36”
41.230.236.11 – – [06/Dec/2020:11:01:34 -0800] “GET /wp-login.php?action=rp&key={20-character key}&login={my WordPress username}%0D HTTP/1.1” 302 4657 “www.google.com” “Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36”
41.230.236.11 – – [06/Dec/2020:11:01:36 -0800] “GET /wp-login.php?action=rp HTTP/1.1” 200 3423 “www.google.com” “Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36”

{some redundant lines here}

20.62.40.13 – – [06/Dec/2020:12:38:44 -0800] “GET /wp-admin/plugin-install.php?tab=upload HTTP/1.1” 200 13209 “www.google.com” “Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36”
20.62.40.13 – – [06/Dec/2020:12:38:47 -0800] “POST /wp-admin/update.php?action=upload-plugin HTTP/1.1” 200 8948 “www.google.com” “Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36”
20.62.40.13 – – [06/Dec/2020:12:38:49 -0800] “POST /wp-admin/update.php?action=upload-plugin HTTP/1.1” 403 3173 “www.google.com” “Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36”
20.62.40.13 – – [06/Dec/2020:12:38:50 -0800] “GET /wp-content/plugins/qbfchs/mini.php?x=ooo HTTP/1.1” 200 4125 “www.google.com” “Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36”
20.62.40.13 – – [06/Dec/2020:12:38:51 -0800] “GET {URL of Easy WP SMTP settings page} HTTP/1.1” 200 13402 “www.google.com” “Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36”
20.62.40.13 – – [06/Dec/2020:12:38:51 -0800] “POST {URL of Easy WP SMTP settings page} HTTP/1.1” 200 1523 “www.google.com” “Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36”
20.62.40.13 – – [06/Dec/2020:13:10:03 -0800] “GET {Easy WP SMTP plugin folder with the same request parameters as before}” 200 4483 “www.google.com” “Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36”

• This reply was modified 3 years, 11 months ago by burkingman.

In case it might help: I’ve been getting similar errors (“SQL Hex Encoding Identified”) from ModSecurity. Did some testing and my impression is that if you let the chat window run long enough, it will eventually generate checksums that trigger ModSecurity. My site is also hosted with Dreamhost, who I think use the OWASP rules (https://www.netnea.com/cms/2016/01/17/most-frequent-false-positives-triggered-by-owasp-modsecurity-core-rules-2-2-x/). Unfortunately, since I’m on shared hosting, I can’t fine-tune Modsecurity; I can turn it off entirely, but that would leave my site too vulnerable (judging from my logs, it’s been blocking some actual hacking attempts).

One solution would be to have Wise Chat generate checksums in such a way as to avoid such ModSecurity false positives, but I have no idea how easy or hard that might be…

Here are two errors from my logs:
[Mon Jun 03 16:15:29 2019] [error] [client 98.143.999.999] ModSecurity: Access denied with code 418 (phase 1). Pattern match “(?i:(?:\\\\A|[^\\\\d])0x[a-f\\\\d]{3,}[a-f\\\\d]*)+” at ARGS:checksum. [file “/dh/apache2/template/etc/mod_sec2/99_dreamhost_rules.conf”] [line “329”] [id “1990091”] [msg “SQL Hex Encoding Identified”] [hostname “www.mysite.com”] [uri “/wp-admin/admin-ajax.php”] [unique_id “XPWqEUBvfwgAAHR8FB0AAAAG”]
[Mon Jun 17 14:24:29.305472 2019] [:error] [pid 2933] [client 204.19.999.999:52725] [client 204.19.999.999] ModSecurity: Access denied with code 418 (phase 1). Pattern match “(?i:(?:\\\\A|[^\\\\d])0x[a-f\\\\d]{3,}[a-f\\\\d]*)+” at ARGS:checksum. [file “/dh/apache2/template/etc/mod_sec2/99_dreamhost_rules.conf”] [line “329”] [id “1990091”] [msg “SQL Hex Encoding Identified”] [hostname “www.mysite.com”] [uri “/wp-content/plugins/wise-chat/src/endpoints/ultra/”] [unique_id “XQgFDYYYjkn4YF@3muE-iQAAAAU”], referer: https://www.mysite.com/chatpage/

Just in case my experience may help diagnosing this type of problem:

When I first installed the plugin, the calendar view would show up OK, but clicking the event list button or even the calendar button would result in a 404 error. My site is in French: the URLs being generated were […]/a-venir/ and […]/mois/. Both valid URLs: it looks like the first one was generated from the string “à venir” in the French translation, and the accent was stripped. Still, neither URL worked.

I discovered I could see either view by accessing […]/upcoming/ and […]/month/ instead. So, the plugin generated each view at the default English URL but referred to the French language file when creating links to those pages.

My WordPress installation is a bit atypical: I’m running multiple sites in two languages (French and English) and using the Backend Localization plugin to keep the back end in English no matter which site I’m working on. Still, the French URLs don’t work even if I switch the back end to French…

I wound up editing the French translation in Poedit so the plugin would translate “upcoming” to “upcoming” and “month” to “month”. Seems to work fine now; I’m just not sure why it wouldn’t work before.

I noticed that too. Maybe the French translation wasn’t updated along with the latest code update.

On the single event pages, in the “meta” section at the top of the listing, I was getting a few English words (the first four items read “Event:”, “Début :”, “Fin :” and “Updated:”). The solution I found was to:
– open the French language file in Poedit
– choose “Catalog > Upgrade from POT file…” from the menu
– open the tribe-events-calendar.pot file from the lang folder of the plugin (this caused Poedit to add a few entries which were missing from the tribe-events-calendar-fr_FR files)
– add my own translation for some of the new terms and for a few terms that were marked as “fuzzy” (coloured yellow)

(Incidentally, those two English items — “Event” and “Updated” seem curiously useless to me. The first one just repeats the event name which is already displayed as a title right above; the second one is not that interesting for the average site visitor and could be confusing since it’s right next to the start and end dates.)

I didn’t have any trouble with the month names in the various views, except for one detail: in the calendar (grid) view, the page title begins with “Evénements pour March 2012”, which looks damn silly. (Well, that’s how it shows up using the Twenty Eleven theme; using my custom theme, there’s no mention of the month in the page title… but that’s a quirk for me to figure out.) Then again, I’m running a weird installation with an English back-end and a French front-end, so my experience may not be typical.

I can send you my updated version of the French translation, if it can be of any use. I’m still tweaking it: there’s a few small oddities in the translation provided with the plugin.