POST command saving php malware via non-existent file

[pmheart66]

Just got done running a malware check on my site, and it came back with 20 plus files dated 2013-2019
Rather than go through the old ones that may have been fixed, Starting with the newest ones,
a 25k file malware listed at SL-PHP-SHELL-abu.UNOFFICIAL FOUND

The thing is that it placed that file by naming itself. Not sure if there is a way for .htaccess to prevent posting to non-existant files or not. -- this may have been fixed in a new/updated version of apache, but it makes sense to just not allow posting to non-existant files anyway. It looks like it threw a "500" error? But obviously the file got created.

These have come over time, and from various IP's
I currently do not have a php site running in the tree that has access to this area, but was about to add some. (Wordpress)

Here is the log file for the most recently created one:

72.52.175.28 - - [26/Mar/2019:12:50:29 -0600] "POST /wp-pg.php HTTP/1.1" 500 60 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/12.0.702.0 Safari/534.24"
72.52.175.28 - - [26/Mar/2019:12:50:28 -0600] "POST /wp-pg.php HTTP/1.1" 500 349 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/12.0.702.0 Safari/534.24"

"wp-pg.php 25.45 KB Mar 26, 2019, 12:50 PM application/xhttpd-php 0644"

p.s. the scanner engine was "devel-clamav-0.99-beta1-632-g8a582c7"

[lucy24]

Not sure if there is a way for .htaccess to prevent posting to non-existant files or not.

Most rules don’t care whether the requested file actually exists or not. Why not globally block POST requests except for those specific files (such as a contact form) that actually require it? If you don’t have URLs in .php, you can also block any and all requests for .php (regardless of method).

[pmheart66]

Lucy, I don't think those are viable options...

Block ALL PHP? But as I said, I am about to install Wordpress in that area, and its already installed in other domains/directory trees.

block all bur known php files? ...do a list of all php files, and re-search every time I update my wordpress to block post requests?
I guess

The thing is none of the files were existing files. Even in the domains with wordpress. Perhaps it was happenstance that they didn't pick an actual file?

It seems like its an overflow thing with Apache or PHP. I would think its Apache since php should not have been called with no file existing. Not sure if its been fixed in apache.

While Its happened over the past 6 years, I'm not ready to get into the rest of the older infections (Listed below). First, because they are older. Second, I know this one does not involve wordpress, while those others might.

I know it was created at the exact second those log entries were made. no other requests were made to the server for one hour and 56 minutes before it was created.

I included the name of the most recent one, but here are the others.

SL-PHP-FILEHACKER-md5-bakk.UNOFFICIAL FOUND
SL-PHP-SHELL-md5-cjix.UNOFFICIAL FOUND
SL-PHP-BACKDOOR-GENERIC-md5-bdwq.UNOFFICIAL FOUND
SL-BIN-TROJAN-GENERIC-md5-bmw.UNOFFICIAL FOUND
HG.WSO.Shell.9.UNOFFICIAL FOUND
PHP.Shell-83 FOUND
SL-PHP-MAILER-GENERIC-md5-kxo.UNOFFICIAL FOUND
SL-PHP-SHELL-md5-cllf.UNOFFICIAL FOUND
SL-PHP-EVAL_REQUEST-md5-aiqf.UNOFFICIAL FOUND
SL-PHP-UPLOADER-1-hu.UNOFFICIAL FOUND

[phranque]

[26/Mar/2019:12:50:29 -0600] "POST /wp-pg.php HTTP/1.1" 500

there should be a web server error log file entry associated with the 500 response shown in the web server access log file.
perhaps that will provide additional clues.

The thing is none of the files were existing files. Even in the domains with wordpress. Perhaps it was happenstance that they didn't pick an actual file?

It seems like its an overflow thing with Apache or PHP. I would think its Apache since php should not have been called with no file existing. Not sure if its been fixed in apache.

in apache-speak, a POST request of a non-existent resource should return a 404.

[phranque]

welcome to WebmasterWorld [webmasterworld.com], pmheart66!

[w3dk]

The thing is that it placed that file by naming itself.

I would think that some other virus/malware scanning software that runs on the server would have perhaps renamed those files to alert you to the fact? (How did you run your "malware check"?)

I currently do not have a php site running in the tree that has access to this area

Where were these files located on the server? In a "temp-upload" directory or actually in a userland directory?

Not sure if there is a way for .htaccess to prevent posting to non-existant files or not. -- this may have been fixed in a new/updated version of apache, but it makes sense to just not allow posting to non-existant files anyway.

In the general sense... you can't simply block all POST requests to non-existent files. Most API endpoints don't map directly to existing files (the request is internally rewritten to a handler).

If you POST a request to a non-existent resource on a CMS like WordPress, then by default it will be routed through WordPress (as the request is internally rewritten to index.php) so it is then dependent on the CMS/WordPress dropping the request (as long there are no rouge plugins listening!).

Block ALL PHP? But as I said, I am about to install Wordpress in that area, and its already installed in other domains/directory trees.

You can still block most PHP files. Punch a few holes for login.php and wp-admin, etc and block the rest? htaccess is blocking HTTP requests, not filesystem requests.

[phranque]

htaccess is blocking HTTP requests, not filesystem requests.

.htaccess file directives can block both.

[lucy24]

Block ALL PHP?

No. Block all (or most) requests for php. For example, on a WP site almost everything gets rewritten to index.php -- but no user has any business requesting index.php by name.

[w3dk]

htaccess is blocking HTTP requests, not filesystem requests.

phranque: .htaccess file directives can block both.

What I mean is that a request must initially be made over HTTP for .htaccess to block it. As opposed to normal PHP includes etc., which are direct requests to the filesystem. There's only a handful of PHP files that need to be accessible over HTTP in a default WordPress installation - which can be handled with a few exceptions in .htaccess.

[lucy24]

What I mean is that a request must initially be made over HTTP for .htaccess to block it.

You'd think so, but access controls in .htaccess also apply to internal requests, regardless of how the server is doing it. I learned this years ago* by direct observation: auto-generated indexes (which you may not even think of as php), php SSIs that are invisible to the user, you name it. If you're in mod_rewrite, a condition looking at %{THE_REQUEST} generally takes care of it.


* Meaning that it was in 2.2. I haven't re-checked everything in 2.4.

[pmheart66]

I don't have 500 error logs from that long ago.

All the files we're within the public_html directory tree.

So we can't block all but a couple PHP files because even internal requests would be blocked.

(On my phone, so I can't check, but these would be from a localhost right? You can block up ranges, thus, white list PHP requests from localhost? )

[lucy24]

because even internal requests would be blocked.

If you didn’t understand the reference to %{THE_REQUEST} you need to say so, or nobody will be able to help you.