3. ● Scripts written (mostly) in PHP*;
● Placed on a server (mostly under existing PHP sites)
without authorization from server/web site owner;
● Used for "unauthorized maintenance" of the infected
server;
● By the "unauthorized maintenance", we mean literally
anything.
What are PHP shell scripts?
4. ● Running applications/scripts (with root privileges)
● "Piggybacking" on existing local exploits
● Modifying files
● Changing user passwords
● Enabling/disabling/reconfiguring system services
● Dumping, destroying and modifying databases
● Opening new backdoors to the system
"Unauthorized maintenance"
5. ● Surprisingly yes, C99shell and all of it's derivates seem
to be most widespread PHP Shells out there.
● There are literally thousands of PHP shell scripts out
there, quality varies.
Are there "the best" PHP shells?
10. ● But most of the responsibility is on the programmer.
● PHP team often does good job describing possible
security pitfalls in their documentation
Documented possible pitfalls
11. ● attacks through standard filesystem functions which
allow socket operations like fopen(), include(),
require()...*
● attacks through unvalidated upload forms (not
documented clearly enough, obviously...)
● in the worst case scenario, due to constellation of
multiple bugs/vulnerabilities/weak setup, attacker might
even use SQL injection to write files on your server!
mysql> SELECT `injected_malicious_data`
FROM `yourtable`
INTO OUTFILE "file.php"
Documented possible vulnerabilities
12. ● Legend says there were infections with shell scripts
through stolen FTP credentials.
So, it's about time you change your "god", "sex" and
"love" stuff. Also, change those "password" and
"password123". In other words, your server's security is
as strong as it is its weakest link.
● On shared hosting environments without proper user
account isolation, it might not even be you who is
infected but other shared hosting client. Consult hosting
support in order to track down how you were attacked.
Other methods of infection
14. And now the interesting part...
Let's take a peek at PHP shells code
15. ● Rather clever, if not smart, architecture
● Written mostly in PHP, but can bring any exploiting code
inside PHP source code in binary (compiled) form
(mostly base64 encoded within variables) or even
download needed exploits (source or binary) from 3rd
party sites, compile and/or run them.
● If needed, can pull its own components from 3rd party
sites.
General architecture
16. ● Decentralized development
● Resulting in many variations of all of PHP shells in
the wild
● Code often complied to such development process,
usually securing itself from redefining crucial
components
(if !function_exists())... prior to all important
definitions)
● Can rely on 0-day exploits!
Quick development cycle
17. ● The scary part: it's a really short way from "plain PHP
shell" to a full-blown bot script controlled through IRC
Quick development cycle
18. ● Not written by your know-just-a-little-coding regular PHP
dev (no pun intended)
● You'll see what I mean...
Coding style
19. ● Well documented code:
function mysql_query_parse($query, $output_type)
{
/*
if output_type == 0, no output,
if output_type == 1, no output if no error
if output_type == 2, output without control-buttons
if output_type == 3, output with control-buttons
*/
...
}
Coding style
20. ● Proper understanding and usage of variable scopes:
function c99fsearch($d)
{
global $found;
global $found_d;
global $found_f;
global $search_i_f;
global $search_i_d;
global $a;
...
}
Coding style
21. ● It's usually safer code than many of the production PHP
code in the wild:
● If it's a cross-platform shell, it performs checks before
doing a function unavailable on other platform(s)
● Variables included in HTML output are escaped, so
no easy path to unwanted XSS
● SQL query parameters are also escaped, no easy
path to unwanted SQL injections
Coding style
22. ● Variable/function names obfuscation is done/not done
in approximately 50:50 examples from our collected
PHP shells
● External URLs, usernames, passwords are mostly
always encoded using either base64 encoding or some
kind of ascii-code-to-hex-codes conversion
● Obviously not for real protection but obfuscation
against most obvious pattern-searching during
attempts of detection*
Coding style
24. ● Mostly quite ugly but always very efficient
● Sortable table outputs on every field
● You might be tempted to administer your server solely
through PHP shell scripts. :-)
GUI
27. These recommendations are best for hosters, but
the developers are also invited to have them in mind!
● Whenever possible, chroot or go even further with
isolation of different web sites on the same machine
(containers/pseudo-virtualization/virtualization), limiting
potential damage to just one site.
● Regulary update your server's OS – PHP shells (as
we've learned) can bring along local exploits.
● Seriously consider complex password policies if you're
running shared hosting environment.
System preparation
28. ● Disable potentially dangerous socket functionality of
filesystem PHP functions if you don't need it
(allow_url_fopen, allow_url_include in
php.ini)
if you're not sure – you don't need it
● When editing, keep in mind some systems
(*cough*Debian*cough*) may have multiple php.ini
files (one for mod_php, one for CLI, one for CGI...). Take
care of them all.
● Follow usual security principles in server administration
and maintenance.
Global PHP configuration
29. ● Consider further crippling PHP by disabling at least
program execution PHP functions if you don't need them
(through disable_functions).
● Which are those?
http://www.php.net/manual/en/ref.exec.php
● Leave something enabled from program execution
functions?*
escapeshellarg(), escapeshellcmd()
● While on that subject – you can't disable eval() like
this. :-)
Global PHP configuration
30. ● Always be checking uploaded files! (it is incredible how
much code does not do any kind of checks)
● Keep in mind not to rely on $_FILES[…]['type'].
Why?
Follow good coding practices
32. ● In general, checking for file extension could do you
just well... If you don't end up only on that, use it as the
primary defense measure.
● That might just not be enough sometimes. You might
want to step-up this game:
● check for mime-type on server. On linux, you can use
external FILE(1) utility. Assuming you haven't
disabled program execution functions.
● We'll see how others do it later.
Ok, how to check uploaded files?
33. ● Always be sanitizing and validating inputs. PHP shells
can be injected through various vectors:
● Apply programming techniques to eliminate possible
SQL injections (escaping, parametrization...)
● Always be escaping shell commands you execute and
their arguments.
● Always doublecheck on filenames of files (and their
paths!) you handle from the code!
Follow good coding practices
35. ● As far as file uploads go, WordPress checks for
uploaded media types by instancing them in respective
modules (i. e. calls GD's getimagesize() on images)
● WordPress is generally very safe CMS. 3rd party plugins
are usually the source of security issues and PHP shell
infections.
WordPress
36. ● Puts no limitation itself on the uploaded content, since it
is attached to e-mail messages and then deleted from
temporary locations.
● Is it possible to attack remote e-mail clients like that?
Depending on the destination client, it's possible. Not
something Roundcube devs should and could focus on.
Roundcube webmail
37. ● Guesses the mime-type by extension, and you limit
allowed mime-types for upload through configuration.
● You can enable upload of "dangerous file types" if you
want.
Dokuwiki
38. Bonus slide
What happens when frustrated
Sendmail administrators write
PHP shells?
http://blog.sucuri.net/2013/09/ask-sucuri-non-alphanumeric-backdoors.html