PHPShell is a php script that allows you to execute shell commands on a web server. Malicious php shell script - where the legs grow from What is php shell

Recently, on the vast expanses of the Internet, I came across the mention of " PHP Shell". A couple of years ago this utility helped me a lot and now I want to give a kind of debt to its developer Martin Geisler (http://mgeisler.net/).

What is the purpose of the "PHP Shell"? I believe that every "advanced" web programmer, let alone sysadmins, has come across and used SSH. SSH allows us to remotely access the server and execute shell commands on it (well, there are all sorts of commands like walking through directories back and forth, up and down, move, delete and copy files, run scripts and all sorts of clever utilities), as if wire to your monitor from system unit lengthened to incredible sizes and reached the host's server. I must say that it is possible to tunnel through ssh and X-graphics, a desktop image showing running window applications, but this is clearly not for web servers.

In short, if you don't have SSH on your hosting, then "what's wrong in the Danish kingdom." The downside is that often SSH is disabled by default on your "fresh" site, and it takes some time to quarrel with support for ssh to work. That is exactly what happened on that distant winter evening. I urgently needed to transfer the site from one machine to another, during which problems arose, and I habitually reached for the putty shortcut on the desktop in order to see what was "inside" the patient. Oops ... and ssh support is not activated. How to be? If you are skilled enough in programming in some language there, then it will not be difficult to write a small script that implements the desired task. I opened google and, having run through a couple of links, I found a mention of PHP Shell. In short, I left home on time.

In truth, I was very fortunate to have had enough of the stripped-down shell capabilities that PHP Shell provided me - it's still an imitation of it.

At its core, PHP Shell uses php function- proc_open. This function runs a command and opens I / O streams in order to enter some information into the application (imitating manual input like on a keyboard) and output the results of the work (if you know what pipes are, then we are talking about them). In fact, the proc_open function is an improved and expanded version of the exec or system functions. Those, however, only started the program, and did not give the opportunity to interact with it, you had to immediately in the parameters command line specify all the data necessary for the command to work. proc_open allows you to create pipes associated with your php-script, and accordingly you can simulate data entry into the program and read the results of its work. For lovers free hosting I'll tell you right away:

"NO, YOU WILL NOT BE ABLE TO GET SSH ACCESS WITH THE PHP Shell."

The point is, for free or very cheap hosting, it is customary to run php in safe_mode. A number of functions are disabled in it, including proc_open.

"NO, YOU WILL NOT BE ABLE TO OPERATE THE INTERACTIVE SOFTWARE USING PHPSHELL."

The very essence of the web tells us that it is not possible to run some program on a remote server that would continue to work and would allow us to enter and output data during several separate http requests.

"NO, YOU CANNOT GET ACCESS TO ALL PROGRAMS, FILES AND FOLDERS ON THE SERVER."

The script runs either on behalf of apache, and then its capabilities are limited only by the fact that the rights to do the apache account. Or as an option, if suexec is used on the hosting (http://en.wikipedia.org/wiki/SuEXEC), then your rights will coincide with the rights account from which the php script is launched.

Let's assume that this doesn't stop you and you've downloaded and unpacked the archive on your server into a folder, say phpshell. If you enter "somehow-called-your-site / phpshell / phpshell.php" into the address bar of the browser, then you will be asked to introduce yourself, enter your name and password - of course, these are not the credentials that you received from your hoster

So you need to set up permissions: who can access the shell through this utility. To do this, find the users section in the config.php file and add the username and password to it in the following form:

Vasyano = secret

If you are confused by the fact that the password is set in clear text, then using the pwhash.php file you can find out the folding of the md5 password and it will be stored in the config.php file

Now we try to enter again and get into the window, where in the lower part of the window we enter the command, click "start" and then the result of its execution is displayed in the center of the page window

That's all, maybe phpshell will help you somehow.

Malicious WSO PHP shell script detected /libraries/simplepie/idn/OpenIDOpenID.php (Joomla! 3 site). On this moment defined only by some antiviruses like JS / SARS.S61, PHP: Decode-DE, Trojan.Html.Agent.vsvbn, PHP.Shell.354, php.cmdshell.unclassed.359.UNOFFICIAL.

One "fine" day (it’s like anyone), one of our wards (http://ladynews.biz), as a result of scanning his site with an antivirus hosting, received this message:

Files with malicious content were found in the account. We strongly recommend that you restrict access to your FTP account only from the IP addresses you are using, and also use anti-virus protection to check your account for viruses. Check out our Security and Hacking Prevention Guidelines to Prevent Reinfection.

Of course, it was proposed to deal with this disgrace - scanning with the standard ClamAV antivirus, with a set of default anti-virus databases, did not give any additional result.

At the time of the beginning of this story (2015-10-23), this virus shell script was absent in the anti-virus databases of most antiviruses, including such "monsters" as Comodo, DrWeb, ESET-NOD32, GData, Kaspersky, McAfee, Microsoft, Symantec, TrendMicro and etc., which was also confirmed by the VirusTotal online scanner on 2015-10-23. Only a few antiviruses were able to identify the malicious PHP script:

Antivirus Result Date of AhnLab-V3 JS / SARS update. S61 20151022 Avast PHP: Decode- DE [Trj] 20151023 NANO- Antivirus Trojan. Html. Agent. vsvbn 20151023

On the same day, ClamAV and Dr.Web were notified about the detection of a malicious script. ClamAV is still stubbornly silent, and Dr.Web reacted to the malicious package within 24 hours:

Your request has been analyzed. The corresponding entry has been added to the Dr.Web virus database and will be available during the next update.
Threat: PHP.Shell.354

Dr.Web kept its promise and the virus script OpenIDOpenID.php is now defined as PHP.Shell.354, however many antiviruses such as ClamAV, Comodo, DrWeb, ESET-NOD32, GData, Kaspersky, McAfee, Microsoft, Symantec, TrendMicro, etc. they still have no idea about it (as of 2015-10-25).

Ok, we deleted the file, but for how long? Where it came from, we can only guess. What's next? We begin to put all sorts of Securitycheck components and twist the rules in .htaccess prohibiting access to everything and everyone, because on shared hosting (aka Shared hosting, shared hosting), we have no authority for more. How long these measures will save, no one knows.

By the way, on the topic of any Securitycheck components ... Securitycheck is a component for Joomla! and quite good. And here is a certain "Antivirus Website Protection" utter crap that I highly discourage anyone from using, here is a practice-proven review of this "Antivirus Website Protection":

This Component also creates a pack.tar file in your / tmp that contains your configuration.php and any other passwords found! BE AWARE

Which in translation means: "this component also creates backup the entire site in the file /tmp/pack.tar, which contains configuration.php with passwords from the database! BE CAREFUL "- this means that" Website Protection "does not smell from this component, which should also lead the victim to think about changing the paths to the / logs, / tmp, / cache directories and denying access to them.

By clicking on this link, you can understand that the problem is at least more than a year old. Looking here, we will understand that the masking of the shell script is not done by the tricky base64_encode / gzdeflate, which means that somewhere else there must be a part that calls / connects OpenIDOpenID.php and executes base64_decode / gzinflate. So OpenIDOpenID.php is only a result (aka a consequence), and not a reason where the victim complains that spam has started to be sent from the server on an industrial scale, and manual removal malicious files does not help, after which the victim has no one else to complain about except for NIC-RU hosting. "Leaky" virtual hosting may well be very good. even often IMHO people work there for a salary, and not for an idea, but in some cases the problem can be much deeper.

For example, "Malicious iFrame injector detected in Adobe Flash file". I think it's not a secret for anyone that you can write interfaces for uploading files to a site in Flash and do many other interesting things in ActionScript. Virus in .swf files ( Adobe flash), as practice has shown, can remain unnoticed for years and be a black door on the site ( aka back door - back door) through which files like "OpenIDOpenID.php" are "thrown", which can be deleted until blue in the face and to no avail.

What to do, how to find the "weak link" among thousands of files? To do this, you need to use the so-called heuristic analysis and, in some cases, use third-party anti-virus databases. It should be borne in mind that heuristic analysis, depending on its settings, can give many false positives than when using additional virus signatures from third-party developers.

Where can I get third-party anti-virus databases? For example, databases with third-party antivirus signatures for ClamAV can be obtained free of charge at www.securiteinfo.com, malwarepatrol.net, rfxn.com. How do I use these additional anti-virus databases? This will be a completely different story. We can only say that additional anti-virus databases for ClamAV from rfxn.com (LMD (Linux Malware Detect) project) are aimed at searching for malware in web applications and give better results. rfxn.com also states that 78% of threats whose fingerprints are in their database are not detected by more than 30 commercial anti-viruses - and most likely they are.

So ... How did the story with the malicious PHP shell script OpenIDOpenID.php end?

It was decided to stock up on additional anti-virus databases for ClamAV from malwarepatrol.net and rfxn.com, download a backup copy of the site files and scan them locally, here is the scan result:

$ clamscan / ladynews.biz / ../ game_rus.swf: MBL_647563.UNOFFICIAL FOUND / ../ farmfrenzy_pp_rus.swf: MBL_647563.UNOFFICIAL FOUND / ../ beachpartycraze_rus.swf: MBL_2934225.UNOFFICIAL FOUNDly / MBL_647563.UNOFFICIAL FOUND / ../ loader_rus.swf: MBL_647563.UNOFFICIAL FOUND ----------- SCAN SUMMARY ----------- Known viruses: 4174348 Engine version: 0.98.7 Scanned directories: 3772 Scanned files: 18283 Infected files: 5 Total errors: 1 Data scanned: 417.76 MB Data read: 533.51 MB (ratio 0.78: 1) Time: 1039.768 sec (17 m 19 s)

/libraries/simplepie/idn/OpenIDOpenID.php as above mentioned .swf files have been deleted, but is the problem solved? It's hard to say so far - we are digging further ...

From the decrypted version of the file /libraries/simplepie/idn/OpenIDOpenID.php(http://pastebin.com/WRLRLG9B) by looking at the @define constant ("WSO_VERSION", "2.5"); , it becomes clear that this is a product called WSO. After digging a little the network for the keyword WSO, the following results were obtained:

It turns out that the topic is not new for a long time, so we pick regexxer in our teeth, continue to pick up the site files and find: Error opening directory "/ home / user / libraries / joomla / cache / controller / cache": Access denied

Aha, here you are, s.ka where else seranulo! We look at the rights to the directory, which should not be by default, = chmod 111 (aka Run for Owner / Group / All). Thus, something sits somewhere and spreads itself through catalogs, hiding itself even from viruses with chmod 111.

After installing chmod 551 for the catalog and looking inside, there was found /libraries/joomla/cache/controller/cache/cache/langs.php, the source code of which is available here: http://pastebin.com/JDTWpxjT - directory / libraries / joomla / cache / controller / cache delete.

Great, now we put in order the chmods for all files and directories:

# bulk change of rights (chmod) on files in the directory. / dirname and below find / home / user / public_html -type f -exec chmod 644 () \; # bulk change permissions (chmod) on. / dirname and below find / home / user / public_html -type d -exec chmod 755 () \;

Once again we repeat the antivirus check with additional clamscan /ladynews.biz databases, but everything is supposedly clean.

We repeat the search for files with regexxer and try to search by keywords OpenIDOpenID, OpenID or WSO - and, we come to the conclusion that p.det turned out to be much wider and deeper:

- it shouldn't be here, here is its source: http://pastebin.com/jYEiZY9G
/administrator/components/com_finder/controllers/imagelist.php- it shouldn't be here, here is its source: http://pastebin.com/0uqDRMgv
/administrator/components/com_users/tables/css.php- it shouldn't be here, here is its source: http://pastebin.com/8qNtSyma
/administrator/templates/hathor/html/com_contact/contact/toolbar.trash.html.php- it shouldn't be here, here is its source: http://pastebin.com/CtVuZsiz
/components/com_jce/editor/tiny_mce/plugins/link/img/Manager.php- it shouldn't be here, here is its source: http://pastebin.com/2NwTNCxx
/libraries/joomla/application/web/router/helpsites.php- it shouldn't be here, here is its source: http://pastebin.com/ANHxyvL9
/plugins/system/ytshortcodes/XML.php- it shouldn't be here, here is its source: http://pastebin.com/GnmSDfc9
/templates/index.php - it shouldn't be here, here is its source: http://pastebin.com/gHbMeF2t

/administrator/components/com_admin/index.php and /templates/index.php were probably entry scripts that executed the main code using the highly deprecated eval () function, which also used:

Well, the logic behind masking the malicious code is clear. Now, if we search for the "eval ($" construct, we will find a lot more interesting things:

/administrator/components/com_admin/sql/updates/postgresql/php.php- http://pastebin.com/gRHvXt5u
/components/com_kunena/template/blue_eagle/media/iconsets/buttons/bluebird/newsfeed.php -
/components/com_mailto/helpers/index.php -
/components/com_users/views/login/file.php -
/components/com_users/controller.php- infected and requires replacement!
/includes/index.php -
/libraries/joomla/string/wrapper/section.php -
/libraries/legacy/access/directory.php -
/libraries/nextend/javascript/jquery/InputFilter.php -
/libraries/nextend/smartslider/admin/views/sliders_slider/tpl/config_tinybrowser.php -
/libraries/xef/assets/less/admin.frontpage.php -
/media/editors/codemirror/mode/rust/Alias.php -
/modules/mod_kunenalatest/language/zh-TW/smtp.php -
/modules/mod_kunenalogin/language/de-DE/XUL.php -
/plugins/content/jw_allvideos/jw_allvideos/includes/js/mediaplayer/skins/bekle/CREDITS.php -
/templates/sj_news_ii/html/mod_sj_contact_ajax/toolbar.messages.php -

Not all of the still viral PHP scripts have code posted on pastebin.com because only 10 publications are allowed within 24 hours. V general order removal is roughly the following:

Yes, I almost forgot - before starting the removal of malicious scripts, it will not hurt to add several rules to .htaccess prohibiting direct access to any .php files in any directories, but allowing access only to the root files / or /index.php and / administrator / or /administrator/index.php - this will block the nasty attacker from accessing incoming shell scripts hidden in various system directories:

(pub) (/ pub) (reg)

# --- +++ PROTECT SOME FILES AND DIRECTORY +++ ---# RewriteCond% (REQUEST_URI)! ^ / ((Index) + \. Php |. * \. (Htm | html | txt | xml) | + |. * / + |. * /. * \. (Css | js | jpg | jpeg | png | gif | ico | eot | svg | ttf | woff | woff2 | html) +)? $ RewriteCond% (REQUEST_URI)! ^ / (administrator) + / (index \ .php)? $ RewriteRule ^ (. *) $ - # # --- +++ // PROTECTED SOME FILES AND DIRECTORY +++ ---

UPD 2015-10-28: Well, what? Are you already relaxed? It's too early...

Now let's look in the wilds of the site files for binary files that shouldn't be in the engine at all:

find / mypath / -executable -type f find / mypath / -type f -perm -u + x find / mypath / -type f | xargs file | grep "\: \ * data $"

Whoever is looking will always find (binaries):

/modules/mod_p30life_expectancy_calc/tmpl/accordian.pack.js
/images/stories/audio/34061012-b1be419af0b9.mp3
/libraries/xef/sources/folder/navigation.php
/libraries/joomla/application/web/application.php
/libraries/joomla/document/json/admin.checkin.php
/libraries/nextend/assets/css/LICENSES.php
/libraries/fof/config/domain/toolbar.categories.html.php
/libraries/fof/form/field/client.php
/libraries/phputf8/sysinfo_system.php
/components/com_mobilejoomla/index.php
/components/com_mobilejoomla/sysinfo_system.php
/components/index.php
/components/com_banners/sysinfo_config.php
/components/com_kunena/views/home/admin.checkin.php
/components/com_jce/editor/tiny_mce/plugins/source/js/codemirror/toolbar.checkin.php
/components/com_jce/editor/tiny_mce/plugins/colorpicker/admin.cache.php

Let's summarize

It was not possible to reliably establish where the legs of this infection grew from, whether the recently found in the engine is to blame critical vulnerability allowing SQL injection and privilege escalation, or the above-mentioned .swf files marked as malicious, or some vulnerability not yet discovered in one of the third-party components or plugins, or a leaky virtual web hosting, is a question remains open?

Currently discovered malicious files cleaned up, the engine files are completely re-uploaded, the rules in .htaccess are barricades ... Who has time and is interested in putting together and picking this pile of shit, you can download the archive wso-php-shell-in-joomla.zip - all of the above are packed there malicious PHP files, archive password: www.site

TOTAL: There is never too much paranoia, and any free or commercial antivirus with its heuristics along with additional signature databases is far from a panacea. Therefore, any anti-viruses are an outdated tool for protecting an active multi-user environment, and to prevent various unknown threats, you should use paranoid protection methods, for example: virtualization, SELinux, Bastille Linux, immutable bit, ecryptfs etc!

Threat: WSO PHP Web Shell
Victim: ladynews.biz

Most attacks on corporate resources involve the injection of web shells - code that makes it possible to control infected machines from outside the network. AntiShell Web Shell Hunter is a security tool that includes a set of mechanisms for detecting web shells.

Web shell is a script that is uploaded to the server and serves for remote administration. It only becomes malicious when it is controlled by an attacker. And in this case, he poses a serious threat.

The infected server does not have to be connected to the Internet - it can be located on the company's internal network. Then the web shell is used to gain access to other hosts with critical applications or information.

Any language supported by the target web server can be used to write web shells. In practice, PHP and ASP are most commonly used as they are the most popular. Malicious programs on Perl, Ruby, Python and Unix shell are also widespread.

Web shells are installed in a fairly standard way for malicious applications - using vulnerabilities in the CMS or software web server. After that, they function as backdoors, allowing an attacker to execute arbitrary commands on the remote machine, including injecting ransomware or launching attacks on other servers.

A particular danger with web shells is their relative simplicity. Modifying the script, resulting in another program, is a task that even a beginner can handle. Because of this quality, it is difficult to detect web shells with standard antivirus tools.

Like others malware, web shells can be identified by a number of external features. However, a significant part of them may also refer to completely legal files, therefore, any suspicious indicators must be considered in a complex, analyzing the whole picture, and not its fragments.

Possible indicators of the presence of a web shell on the server can be:

periods of abnormally high server load;
the presence of files with a suspicious timestamp (for example, later than the time last update ON);
Availability suspicious files in places accessible from the Internet;
the presence of files that contain links to cmd.exe, eval and the like;
the presence of suspicious authorizations from the internal network;
the presence of files generating unusual traffic.

Obviously, "manual" analysis in this case, if possible, requires too many human resources, so its application is devoid of any practical feasibility. Garhi Technology's AntiShell Web Shell Hunter automates this process, claiming to be guaranteed to recognize all known web shells.

The application is based on the following technologies:

search by keywords. All files are scanned for words and commands that may be associated with the attack;
signature analysis: search for signatures of known web shells;
analysis of the longest lines. Often, malicious code is encrypted in such a way as to bypass keyword searches. This makes lines of code especially long, which makes them detectable;
calculation of Shannon's entropy in source code... Each line of code is assigned a rating, based on which you can judge the degree of threat;
search for malicious code using the coincidence index method.

This solves one of the main problems of web shell detection, associated with the variety of languages used and the possibility of easy modification. These factors do not affect the operation of AntiShell Web Shell Hunter, which makes it universal and can be used to protect any server.

Since files that have not been modified since the previous scan are excluded from processing, AntiShell Web Shell Hunter does not place a high load on the server. In addition, this approach reduces the verification time.

At the same time, administrators can independently set the scan time based on daily fluctuations in the server load. If necessary, the daily routine is replaced with a weekly or even monthly, which allows you to optimize the operation of the entire system.

The program detects the files containing the web shell code and provides the system administrator full information by object: date and time of creation, owner's name, rights, and so on.

All this data (but not the files themselves) also goes to the client center of the developer company, which, on their basis, can provide support in handling the incident and investigating its consequences. Customers who have signed up for a paid service can also use special utility download the infected files themselves for further analysis.

Messages about found objects are sent to the system administrator by e-mail... There is no need for him to personally monitor the process.

Today AntiShell Web Shell Hunter is the only tool aimed specifically at detecting web shells. A number of anti-virus applications include a similar function, but only as an additional option, which is inactive by default. As a rule, they rely solely on signature analysis, so their effectiveness is poor.

As the use of web shells to attack servers is becoming more common, it makes sense to protect the system with a specialized solution. As the saying goes, there is never too much security.