in the Wordpress directory I found some suspicious-looking files with random strings in their name e.g. uxs5sxp59f_index.php. Can I safely check their content ? I have a suspicion that the site has been infected because some of its links on external portals to the site with the malware.
5 Answers
In order for the opening of the file to pose a risk, the file would need to include an exploit for the specific text editor you use. Then when you open the file, the exploit would trigger.
While possible that's not very likely. It certainly isn't common.
The far more likely threat is that there is malicious PHP code in the file that triggers when the file is executed by a PHP server.
But all that aside, I'm not sure why you are questioning whether you have been infected when you are looking at files being served that you did not create and there are links to malware. You've been infected. Start with that assumption...
answered Nov 20, 2020 at 9:31
Generally, it's safe, but there are known instances where viewing a file with unix tools trigger an exploit. E.g. CVE-2019-8904, where running file on a file triggers a buffer overflow.
Edit: viewing a file with less may also be unsafe. less helpfully tries to decompress compressed files, and does other smart things, which makes it possible to exploit bugs in these helper programs.
-
-
Are there any situations where an attacker would want to introduce a payload through these files? The files can likely be executed by the server, without manual intervention. Nov 21, 2020 at 7:00
-
1The files will be executed by the server as the web user. The person investigating will do so with different privileges @BillThePlatypus– JCRMNov 23, 2020 at 11:53
Yes, you can. Even an infected PHP file is only a set of instructions to the PHP interpreter, and it will do nothing evil when opened on Vim.
I would first rename the file, so the exploit that already is running under Wordpress would stop working, and use Vim afterwards to check its contents. And make a full backup of the site while at it, export the database, and check the database for signs of infection.
Your Wordpress is infected, so plan on proper cleanup and reinstall. And try to use the least possible plugins, themes, extensions and add-ons. Wordpress itself has matured enough to be safer than its beginnings, but the same cannot be said for every third-party component out there.
answered Nov 20, 2020 at 11:39
-
You can't really guarantee though that the malware only affected Wordpress and didn't, say, add a key to the
authorized_keysfile.– user163495Nov 20, 2020 at 11:50 -
1I meant that if was executed only by Wordpress, not by Vim. And you are right. It could have added a key to
authorized_keys, or created a new cron job, or a reverse shell listening on UDP. It could have done a lot of things. But it would not spring to life by reading it on Vim. Nov 20, 2020 at 12:21 -
7Will do nothing evil when opened in
vim? What about CVE-2016-1248 (vim before patch 8.0.0056 does not properly validate values for the 'filetype', 'syntax' and 'keymap' options, which may result in the execution of arbitrary code if a file with a specially crafted modeline is opened.) Nov 20, 2020 at 22:40 -
A PHP file exploiting CVE-2016-1248 would not be a valid PHP file, so no, it is not likely. If the attacker already have write access to create a PHP file, why it would need to craft a special file to execute commands? Nov 21, 2020 at 23:03
-
1@MichaelHomer as a security engineer, you must take care of the most possible attacks, not every single theoretical ones. There are way too many possible attacks that no-one will ever use, as they depend on too much variables, and a handful of attacks people will really use: XSS, SQLi, LFI, RCE, web shells, and so on. While you are thinking about that vim modeline attack, the attacker is exploiting your server using that PHP file. Nov 22, 2020 at 17:18
Yes, as others have said an exploit for PHP is not an exploit for vim, but one word of warning: Depending on the server and/or environment setup, your vim may be configured to do more than just display the file. If someone uses the same user on the server for development, there may be vim plugins installed such as vim-lsp or ConquerOfCompletion (CoC) that will interpret and possibly run the code that you edit in order to provide code completion. Depending on the nature of the exploit, that could be as bad as running the file (and may be equivalent to running the file).
If you suspect such a setup, you can tell vim to ignore your configuration. Summarizing the top answers:
$ vim --clean uxs5sxp59f_index.php # Added in vim 8.0.1554
$ HOME=/dev/null vi -u NONE -i NONE uxs5sxp59f_index.php # Works on older versions
If you have files that you cannot explain, then you have a security risk. It is as simple as that. If possible, take the site off-line. Then run a copy to a place where you can do forensics. If you need to be up ASAP, remove the offending files before you re-open.
Files may be generated by your application. If you application generates them, your application programmers should know about them. If they are unknown, someone/thing else then you are exposing php pages on your site. this may be 'alternative' content, in the broadest sense of the word.
To find what these files are, I would first use strings uxs5sxp59f_index.php | more. See if you recognize them. If you don't, your serious problem is confirmed. strings is a relatively safe command in this case.
If you do recognize the content, try to figure out why it has such a strange name. Is it a temp-file generated by the application? Is it application specific (I don't use wordpress, so no hints from me there)
/usr/bin/lessor simply more(1) and you should combine them with od(1)