Something triggers and infinite loop of local HTTP get commands against a page

  • Resolved gregscott

    (@gregscott)


    3 years, 2 months ago

    This could be an attack against a vulnerability or maybe a bug. I’m still not sure. I recently upgraded from WordPress 5.8.1 to 5.8.2, running on a Fedora 35 VM. I noticed a couple days ago that the website seemed very slow. Top showed 0 percent idle, and

    tail -f /etc/httpd/logs/access_log showed zillions of entries like this:

    fe80::65dc:5d0e:b7eb:47ae%ens3 - - [18/Dec/2021:10:55:44 -0600] "GET /category/phishy-emails/ HTTP/1.1" 200 27106 "https://www.dgregscott.com/category/phishy-emails/" "WordPress/5.8.2; https://www.dgregscott.com"

    That IPV6 address above is my localhost. So, something triggers this infinite loop generating zillions of HTTP get requests.

    This may be an attack – the entries I’ve seen so far are all against one of my “phishy emails” blog posts. But they are all local – which suggests somebody may be exploiting a vulnerability. Or maybe 5.8.2 introduced a bug because the problem started right after my 5.8.2 update.

    When I restart httpd.service, the ugliness stops for a while.

    Does anyone have ideas about what triggers this? Meantime, I’ll see if I can find any clues buried in access_log.

    The page I need help with: [log in to see the link]

Viewing 2 replies - 1 through 2 (of 2 total)
  • Thread Starter gregscott

    (@gregscott)

    Maybe I fixed it. Details below.

    I found a way to reproduce the problem at will – in a browser window, go to blog –> Phishy emnails. In another terminal window, do tail -f /etc/httpd/logs/access_log

    Every time I clicked on “Phishy emails”, my tail -f went nuts with zillions of

    fe80::65dc:5d0e:b7eb:47ae%ens3 - - [18/Dec/2021:18:18:28 -0600] "GET /category/phishy-emails/ HTTP/1.1" 200 27106 "https://www.dgregscott.com/category/phishy-emails/" "WordPress/5.8.2; https://www.dgregscott.com"
fe80::65dc:5d0e:b7eb:47ae%ens3 - - [18/Dec/2021:18:18:34 -0600] "GET /wp-content/uploads/2021/11/KamalaBackdoorSpam-1024x924.png HTTP/1.1" 200 269366 "https://www.dgregscott.com/wp-content/uploads/2021/11/KamalaBackdoorSpam-1024x924.png" "WordPress/5.8.2; https://www.dgregscott.com"

    In a third window, I did
    systemctl restart httpd.service
    and the machine-gunned log entries stopped.

    With more testing, I found I could reproduce the problem by clicking on **any** blog post in the “Phishy emails” category.

    Clicking other posts and pages did not trigger the behavior; just “Phishy email” posts or the category.

    Maybe somebody injected a malicious .htaccess or other config file? I didn’t see any.

    And then I noticed a brand new pending update. It was the Divi theme, updating from 4.14.3 to 4.14.4. I applied the update and the problem stopped.

    So…

    looks like it was either a Divi theme bug or somebody inserted something hostile into the theme directory. I also updated Divi a few days ago, so it could be either. I’ll keep an eye on it for a while.

    Thread Starter gregscott

    (@gregscott)

    Long story short – the problem was a Divi theme bug with Divi 4.14.3. Other people had similar problems. The 4.14.4 update fixed it.

    I checked my backups and found I updated to Divi 4.14.3 on Dec. 16 2021 at 8:49 PM. My website logs show the problem started at 20:54:02, or roughly 5 minutes later. After I learned how to reproduce the problem at will, the problem stopped immediately after I updated to Divi 4.14.4. For an attacker to introduce something malicious, they would need to do it within 5 minutes of my update, and dated the offending file the exact same as all the other files in the themes/Divi directory tree.

    I posted this in a Facebook group named “Divi Theme Users” and before the admins of that group deleted my post, several people commented they had similar problems with Divi 4.14.3.

    So this one turned out to be a theme thing.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘Something triggers and infinite loop of local HTTP get commands against a page’ is closed to new replies.