16

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.

nsog8sm43x
  • 269
  • 2
  • 3
  • [This question](https://security.stackexchange.com/questions/39231/how-do-i-deal-with-a-compromised-server) should give you all the information that you need. –  Nov 20 '20 at 10:36
  • 8
    See also [Can "cat-ing" a file be a potential security risk?](https://security.stackexchange.com/questions/56307/can-cat-ing-a-file-be-a-potential-security-risk) – Sjoerd Nov 20 '20 at 12:27
  • In general it's never safe to do anything with malware, but in this case it's safe because it is extremely unlikely that the file is anything but PHP code. – reed Nov 20 '20 at 13:47
  • You could use [less(1)](https://man7.org/linux/man-pages/man1/less.1.html) as `/usr/bin/less` or simply [more(1)](https://man7.org/linux/man-pages/man1/more.1.html) and you should combine them with [od(1)](https://man7.org/linux/man-pages/man1/od.1.html) – Basile Starynkevitch Nov 21 '20 at 05:47
  • 1
    The xxd and strings commands are even better. To be honest I'd hesitate to use an editor- even a vi derivative- since so many of them attempt to do smart rendering things which (a) might hide any problem sequences and (b) might potentially be infected by an exploit. – Mark Morgan Lloyd Nov 21 '20 at 11:16
  • hexdump -C is probably safer than more and less... provided one beleives that PATH and its directories are not compromised. – fraxinus Nov 21 '20 at 12:54
  • I'd be inclined to use a hex edit program, such as Hex Editor Neo on Windows. Such an editor is designed to handle any matter of binary gibberish without being tricked into doing something. – Hot Licks Nov 21 '20 at 22:53
  • @reed *anything*? Are there known ways to exploit, say, opening a file and reading it from a Python script? – Karl Knechtel Nov 22 '20 at 00:37
  • I'll note that I once demonstrated the ability to cause a simple DIR command on MS DOS to invoke batch file commands. It was not obvious that you could do anything dastardly with this, but you could provoke some weird behavior. – Hot Licks Nov 22 '20 at 02:16
  • @KarlKnechtel, of course, but it's a zero-day and I can't tell you the details! Lol – reed Nov 22 '20 at 10:54

5 Answers5

52

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...

schroeder
  • 125,553
  • 55
  • 289
  • 326
18

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.

Sjoerd
  • 28,897
  • 12
  • 76
  • 102
  • Note that `less` only exhibits that behavior if you use `lesspipe` – SuperStormer Nov 21 '20 at 00:13
  • 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. – BillThePlatypus Nov 21 '20 at 07:00
  • 1
    The files will be executed by the server as the web user. The person investigating will do so with different privileges @BillThePlatypus – JCRM Nov 23 '20 at 11:53
5

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.

ThoriumBR
  • 51,983
  • 13
  • 131
  • 149
  • You can't really guarantee though that the malware *only* affected Wordpress and didn't, say, add a key to the `authorized_keys` file. –  Nov 20 '20 at 11:50
  • 1
    I 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. – ThoriumBR Nov 20 '20 at 12:21
  • 7
    Will 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.) – Ljm Dullaart Nov 20 '20 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? – ThoriumBR Nov 21 '20 at 23:03
  • I can't imagine what about a modeline exploit could make something necessarily *not* a valid PHP file; a file containing just the modeline is a valid PHP file. There also doesn't seem to be any reason that a file containing an editor exploit must contain only valid PHP code. I *can* imagine the user running the editor to have different permissions than the web server user that likely created the file. That it is overall not *likely* is still true, yes. – Michael Homer Nov 22 '20 at 04:46
  • 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. – ThoriumBR Nov 22 '20 at 17:18
  • All that is true, but there were a bunch of strong factual claims made above that are false, to concerning degrees. "A PHP file exploiting CVE-2016-1248 would not be a valid PHP file" is so utterly so as to call into doubt the reliability of everything else. – Michael Homer Nov 22 '20 at 19:07
4

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
Chris Bouchard
  • 141
  • 2
2

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)

Ljm Dullaart
  • 2,007
  • 5
  • 11