PHP features many ways to introduce and create strings. Most of them are known from other programming languages and are listed and explained in the PHP documentation. ³

The most common way to work with strings in PHP is to make use of single or double quotes for delimiting. Both ways work fine, although a double-quoted string is treated differently by PHP than a single-quoted string. Double-quoted strings, for example, can contain escape sequences for special characters such as line breaks or tabs, and even null bytes, so if the developer uses a construct such as "hello goodbye" it will be treated differently than ‘hello goodbye’. The first example will actually contain the newline, while the second version will just show the character sequence backslash and the letter n.

Quite a range of escape sequences can be used, starting with the null byte , several kinds of control characters, the carriage return/line feed combination, and whitespace such as , , v, and . Of course, the escape character can also be escaped, with \, and to prevent the variable from expanding, we can use $. It is even possible to make use of octal and hexadecimal entities inside double-quoted strings. The syntax, as you may have guessed, is [tableindex] or x[tableindex]. Let us look at some examples:

The same is true for variables embedded inside double-quoted strings. All variables embedded in double-quoted strings will be parsed and (as mentioned in the PHP manual) expanded. That means their content will be joined in the string at the position they were added. This is a nice feature, because it saves some typing work, especially regarding concatenation operators. At the same time, however, it can be dangerous to use. First, let us look at the syntax. Basically, it is just embedding the variables inside the string, as in "hello$a goodbye!." If $a is set to contain an exclamation mark, the result will be hello!goodbye!. There are several variations regarding the syntax we can use here. PHP has an affinity for curly brackets. As we can see, the following examples work too:

This support for delimiting the label of the variable to expand is necessary, since the parser cannot really know where the label ends and the rest of the string begins. Take the construct hello$agoodbye; will it result in $a or $ag or $agood? There is no way to find that out for sure. But there is more we can do inside double-quoted strings. For example, we can access array indexes, as well as members of objects. And since we already know that PHP allows us to access strings like arrays, we can add some more obfuscation spice:

Not only is it possible to access array indexes, play with numerical obfuscation, and access strings inside double-quoted strings, but we can also call functions and object methods:

The first example snippet shows how to call the phpinfo() function. The second one already implements a small shell to evaluate everything coming in from the GET parameter cmd. So, if the script containing this code is called with test.php?cmd=echo%201; the output will be hello goodbye1hello goodbye, showing that the code will be executed before the echo statement is finished. Note that the index 0 of the variable $a is being used too, since the eval call returns nothing, which is equivalent to 0 in PHP.

But PHP allows more ways to work with strings. For example, we can work with strings that are not quoted at all. The following example will throw a notice on configurations where the error reporting is enabled, but it will still work fine:

Since version 4, PHP has supported the heredoc syntax, and since version 5.3, it has supported quoted heredoc labels and the slightly advanced nowdoc format.

PHP treats strings inside heredoc blocks like double-quoted strings, so escaped character sequences can be used and variable expansion is enabled, as the next examples demonstrate. Also, newlines and other comparable control chars are preserved. Nowdoc does not expand variables, so what heredoc is for double-quoted strings, nowdoc is for single-quoted strings.

There is yet another way to introduce and generate a string in PHP that is not as well known as the techniques we already discussed. You may have already spotted it in the preceding snippet. It is the binary string feature, where strings are introduced by the letter b preceding the actual quoting. It looks like this:

This might be particularly interesting to sneak past filter rules and badly written parsers, and can be used with single- and double-quoted strings as well as with heredoc and nowdoc.

As soon as we have generated the string, PHP provides us with a plethora of methods that we can use to add and remove additional encoding and obfuscation. It starts with the entity encoding and decoding we already know, using html_entity_decode() and comparable functions, and ranges from base64_decode() to functions such as str_rot13() performing a ROT13 encoding and shifting the characters by 13 ASCII table indexes, and so on. Of course, PHP also provides methods for getting a character by its table index, as in chr(). The use of chr() will be pretty interesting in PHP 6, since it will support Unicode codepoints as well as characters and codepoints from the ASCII table (see http://php.net/manual/en/function.chr.php).

PHP also provides actual encryption functions, which can be useful in code obfuscation as well. If an attacker finds a way to hide the key for the decryption from the eyes of the forensics specialist trying to analyze the payload afterward, even low encryption quality can be pretty effective and can require hours of work to actually decipher the code. In the next section, we will discuss some of the ways we can do this.

Since PHP 4, developers have had access to superglobals, which are predefined variables available in the global scope (see www.php.net/manual/en/language.variables.superglobals.php). They are meant to ease access to data embedded in the HTTP GET string or the POST body as well as other data structures provided by the user, the runtime, and the Web server. Table 6.2 lists the currently available set of superglobals and gives a short explanation of each.

Superglobals are easy to access. Let us see how to get information on a given _GET variable, assuming we call the test script we use with the _GET parameter a=1:

For additional payload obfuscation, $_GET can be considered the least useful, since everything coming in via $_GET will be visible in the Web server's logfiles for later analysis. The POST body of a request is, thus, far more interesting, since an attacker can just create a small snippet of code triggering an evaluation while the actual payload is coming from a POST variable. The same is true for several variables in the _SERVER array. Several fields in this array can be modified by the attacker and filled with short triggers or even fragmented data, possibly bypassing either logging mechanisms and Web application firewalls (WAFs) or intrusion detection system implementations. Also, the deprecated equivalents can still be used in modern PHP versions, so not only does $_SERVER contain the environmental and runtime data but so also does $HTTP_SERVER_VARS.

Now let us use JavaScript and the XMLHttpRequest (XHR) object to see an example of how to manipulate field values in the _SERVER array. The following code snippet shows how to craft Ajax requests and attempt to overwrite the necessary fields:

Usually, user agents append the additional cookie data to the existing cookie string, so a little bit of regular expression magic would be necessary to get to the correct set of data. Of course, it is also possible to define and use arbitrary header data and hide the payload, and this is mostly used in situations where a WAF or intrusion detection system needs to be bypassed. Here is an example that illustrates the possible use of superglobals in obfuscation:

The example shows a very simple use of a fragmented payload coming from one self-defined request header and one request header that was overwritten by the attacking user agent. Even if the attack is noticed after it occurs it will be very hard to determine what the actual payload consisted of.

To obfuscate access to the necessary superglobal array it's possible to cast it into another data type beforehand—for example, to have it be an object of the type stdClass. Any existing object can, of course, also be cast back to be of type array too:

Unfortunately, casting a complex data type to a simple string will not cause an implicit serialization of the object, but rather will just return the former data type as a string.

One final note regarding the $_SERVER array. The technique of encrypting an attack payload in this way to hide information could be very valuable for an attacker. If an encrypted payload is being submitted via GET or POST and the key to decipher the text is being sent via an HTTP header or some other field the attacker can control, it will be extremely difficult (if not impossible) for the victim to put this information together after detecting the attack.

As with JavaScript and many other languages, PHP allows use of function calls and statements inside string concatenations. This, of course, makes a lot of sense for many real-world situations such as translation tools, templating engines, and other scenarios. But we can also use this feature for obfuscation and make it harder for an investigator to read the code. It is a very basic and simple obfuscation method, but it is nevertheless worth mentioning.

The initial vector we showed in the section “Obfuscation in PHP” used this technique, among others:

Here, we used an empty array and the silenced false to add useless padding to the original payload to decrease its readability. It is also possible to work with functions that actually return data which cannot be used in the payload. A simple exclamation mark before the call renders the entire statement false, thus making it silent in the concatenation process:

The example also contains the three comment styles PHP knows, which is one-line comments introduced by // and # as well as multiline comments delimited by /* and */, often referred to as C-style and Perl-style comments.

Another technique that is useful in an obfuscation context involves the variable variables PHP supports (see http://php.net/manual/en/language.variables.variable.php). This feature basically enables the developer to create variables with dynamic labels—for example, inside a loop. We used this feature in several of the example snippets, as it is rather well known and quite easy to understand. Here is a short example:

Since this feature does not stop with $$ but can be used with even more chained variable delimiters, it is easy to create code that looks quirky and is very hard to read. The following example illustrates this:

PHP also enables us to define the variable label in another way: using curly bracket notation.

Curly bracket notation is comparable to the variable variables feature, since it allows us to execute code when forming the label for a variable. There are not many use cases in real-life applications where this feature makes sense, but some structural and design patterns are easier to implement with dynamic variable labels. The feature is easy to explain via the following example, in which we create several variables using curly bracket notation:

As you can see, almost arbitrary code can be executed inside the curly brackets. And of course, it is also possible to work with comments, newlines, and all the other string-based obfuscation techniques we learned about earlier in this chapter. An interesting fact is that variables declared inside curly brackets will be available in the surrounding scope, not just inside the curly brackets themselves.

The only actual limitation that plays a role for us in terms of code obfuscation is that only one statement can be used inside the brackets. It is not possible to terminate a statement with a semicolon and start over with another one. If an attacker does want to execute several statements, a small trick can help in this regard: using the include() or require() functionality and fetching the payload from another file (or from another domain, if the PHP configuration was sloppy), or a data URI. All the content of the file that is included will instantly be executed as expected.

We will go into more detail regarding data URI inclusions and more ways to use include and require for code obfuscation in the next section, “Evaluating and executing code.” But before we do, here's another way to execute several statements: Just create a string of the payload to execute and feed it into an eval call, again enabling multiple statements between curly brackets:

There are a lot of ways that strings can be evaluated and executed in PHP. One of the most basic ways is, of course, the classic include, meaning some file at some location that is reachable by the Web server or PHP runtime will be loaded, and all of its contents will be executed as though the file was opened directly by the PHP engine. The basic syntax is easy, and the family of include functions can be called either as a function or as a statement. Depending on the php.ini options, it might be possible to include resources via a URL, although this feature is switched off by default in modern PHP versions. The following snippet shows the php.ini settings responsible for this behavior:

Let us look at some examples for local file inclusion:

The last example snippet represents classic remote code execution. Whatever PHP code is stored on the evil.com domain will be executed on the box that executes the require_once statement. Another bad thing with inclusions is their vulnerability against null bytes in case the php.ini file or the application itself does not provide protection against it. It is easy to end a string used in an include with a null byte. A classic scenario looks like this:

If the gpc_magic_quotes setting is inactive, the injected null byte will just do its job, cutting the string and actually taking care that /etc/passwd is being included, and not a file with the.tpl extension. If gpc_magic_quotes is switched on, which is the default for most older PHP 5 versions, it can usually be tricked by injecting a very long path and forcing a truncation. Quality resources on attack vectors such as this are available at the following URLs:

It is a good thing that at least allow_url_include is switched off by default, because it opens the door for a lot of interesting ways to include and execute data, as well as obfuscate and smuggle payloads past firewalls and other protective mechanisms. Not only can standard HTTP URLs be used but also file URIs, data URIs, and even the PHP stream handlers can be included in this way. Although file and data URIs are not really new to us, stream handlers are. Let us look at some examples to learn more about this:

In the preceding code, we can see that PHP understands file URIs as well as data URIs. But what other protocol handlers are available? As mentioned, we are talking about streams here, which have been available since PHP 5. Streams are meant to provide a large array of possibilities to treat incoming and outgoing data before it's sent or internally processed. Instead of, for example, implementing his own complicated solutions for transferring binary files from application A to application B, a developer can make use of streams and encode the file in base64 to make sure no dangerous characters are put on the wire. Also, the data URI stream handler can be used for urlencoded data or any other format desired.

The methods for treating the string data can be stacked, as shown in the last example snippet where we first applied ROT13 encoding on the included file and then applied base64 encoding. Note that this would not make any sense in a real-life scenario, but it is possible to do. Also, we can use empty read= or write= directives as well as pipes and slashes for extra obfuscation.

You can find a thorough write-up on the php:// stream handler at http://illiweb.com/manuel/php/wrappers.php.html.

As you can see, the inclusion of an existing file containing PHP code via a filter stream is equivalent to a regular include. But what should you do if there is no suitable file to include? Several papers have been published in the past few years explaining more or less reliable methods for getting a file uploaded on the targeted server, but streams provide a more elegant way to do this. It is possible to combine php://-filter with data URI streams, as the next examples show, or just to use data URIs all alone:

The possibilities for encoding or character-based obfuscation are quite limited here, but at least we can use URL entities and mix upper- and lowercase characters. Only the protocol handler itself cannot be modified, so variations such as d%41ta: or even dAta: will not work at all.

Before we lose ourselves in code evaluation via inclusion and dissecting the stream handlers, let us look at the possibilities PHP provides for evaluating and executing code and how we can use those functions for obfuscation.

The most common function for evaluation (a.k.a. Direct Dynamic Code Evaluation) is, of course, eval(). In PHP, as well as in many other languages, it does nothing more than receive a string as an argument and execute the content of the string as PHP code. If the result of an eval statement needs to be returned to be used as a variable value or something similar, it is possible to use the return inside the string to be evaluated. Everything after the return will be ignored by the parser.

An injection point inside the string to evaluate can usually bypass the return barrier and make sure that code behind it can be executed as well. The kind of bypass logically depends on the injection point, but either comments, ternary operators, or constructs, as shown in the following code, can help:

Of course, it is possible to use entities in double-quoted strings, as shown in previous sections, but there is yet another way to generate strings for eval statements and other tricks. The technique is actually a kind of evaluation, but on the shell layer rather than in PHP itself. It is known as backtick notation, a form of shorthand documented as an execution operator in the PHP docs, ⁴ and a form of shorthand for the native function shell_exec().

PHP knows several functions capable of passing strings through to the command line. Besides shell_exec(), these functions include exec(), passthru(), and system(), among others. They are documented on the program execution function pages in the PHP docs (see www.php.net/manual/en/ref.exec.php). The main differences between them are their behaviors regarding return values and output display. Using the backtick operator, as mentioned, is equivalent to executing shell_exec(), which makes it particularly interesting in our demand to obfuscate code. Here is a very basic example showing how strings can be generated with this technique:

In the preceding code, PHP executed echo 1 on the shell and returned the received 1 to the echo statement, which results in nothing more than an echo 1. The interesting thing here is the possibility to use shell entities, and thus get a new layer of obfuscation via encoding. Not only can we use PHP entities but we can also use double-encoded representations of characters coming from the shell. Inside backtick operators, no quoting has to be used as long as the canonical form of characters or the octal entity representations are being used. Quotes are required only if hex entities need to be used.

The second snippet shows that undeclared variables are being ignored, and that arbitrary padding is placed at the end of the string. For a forensics researcher, it is now extremely difficult to determine where the actual payload ended and the padding began. Here is an example utilizing this technique, combined with double-quoted string obfuscation:

The preceding example also adds the trick of using a one-line comment in combination with an entity for creating a new line, x0A. We can, of course, use one-line comments as well as block comments.

As mentioned, PHP knows a lot of ways to evaluate strings as actual executable code, and this book does not attempt to enumerate them all. Still, it is worth mentioning call_user_func(), call_user_func_array(), and register_shutdown_function(), which are discussed in detail at the following URLs:

The following example shows how we can use these functions to evaluate strings, with the first parameter controlling what function is to be called and the second parameter controlling the passed arguments:

This combination easily allows us to execute arbitrary code; eval() itself cannot be passed as an argument, but it is easy to get around this limitation via system and the PHP CLI or other tricks. Another commonly abused feature suitable for evaluating arbitrary code is the almost legendary e modifier for the regular expressions used by the PHP function preg_replace() (see www.php.net/manual/en/function.call-user-func-array.php):

Anonymous functions in PHP are an interesting case to study, since this is one of the very few ways to actually assign functions to variables and work with lambda-like features. Many programming languages feature comparable functionality—among them JavaScript, as well as many functional languages such as Lisp⁵ and Haskell. ⁶ Here, we dive into the theoretical background of anonymous functions, and instead we discuss how they are used in PHP to evaluate and obfuscate code.

Anonymous functions in PHP are created with the function create_function(), which accepts two mandatory parameters. The first character is a string of one or more comma-separated arguments for the function to create. The second character is also in string form and represents the actual function body to execute. An example of a very basic anonymous function performing string concatenation for two passed arguments looks like this:

The first parameter can, of course, also be an empty string, or even null, if no arguments are required. PHP is surprisingly strict regarding the type check in this situation, but as long as nulls or any form of string is being passed, this will work. As the following examples show, this is valid for binary strings, and even when another anonymous function returns a string. And if double quotes are used, all techniques for string obfuscation can be used as well.

The interesting thing about create_function() for obfuscation is that we can infinitely nest one anonymous function to be an argument for another anonymous function, which helps a lot in making code unreadable and hard to analyze. It is the same as endlessly nesting eval chains, enabling us to encode the actual executed string infinitely. The following snippet shows an eval chain used in combination with create_function():

It is also easy to add function calls to base64_decode(), rot13(), or other encoding and decoding functions to the mix. The following example shows a very simple way to use more encoding techniques:

In addition to working with lambda-like features, anonymous functions also enable us to work with variable functions. In PHP, callbacks and code structuring are based on the new predefined Closure class. This class unfortunately cannot be instantiated directly. Also, serializing anonymous functions either returns the serialized form of the return value or in more complex setups throws a fatal error. Consider the following code to learn how anonymous functions can be used:

This feature is perfect for effective code obfuscation since it allows us to spread the business logic that is forming and executing the payload all over the vectors used for an attack. As in JavaScript, it is also possible to nest anonymous functions—mixing them up with the results of create_function() and eval() as well as using curly bracket notation for the label the function is being named with, including the dirty include tricks.

Anonymous functions cannot be used without an actual assignment. JavaScript is far more flexible in this regard, and allows (function(a){})(1), but for better obfuscation, again the superglobals or other variables can be used.

Still, this feature opens the gate for a whole new set of obfuscation techniques: nesting anonymous functions, combining them with create_function() and the mentioned eval, as well as the huge array of possible string obfuscation techniques enabling an attacker to create almost unreadable code. If the actual payload is again encrypted and can only be decrypted with knowledge of the key hidden in some variable of the $_SERVER array or any other data which is out of band and usually not being logged, it is possible to create vectors that are quite bulletproof against forensic measures, which makes extensive logging unavoidable and requires high levels of intrusion detection and intrusion prevention intelligence to be able to provide a decent protection level. The following example shows a mildly obfuscated but already hard to read representation of an echo 1; using create_function() and anonymous functions, while at the same time playing with the different scopes and the possibility of using same-named variables all over the code:

This feature is somewhat similar to the way older PHP variables function in terms of obfuscating code in cases where PHP 5.3 or later is not present on the targeted machine. This feature can be called quirky, if not something worse, and it is easiest to explain with an example:

If a string is being assigned and a function with the same name exists in the scope, the string can magically reference the function, and the function can be executed via the variable to the string to which it is mapped. This even works with superglobals, allowing code such as this:

It is even possible to work with native functions and map them to variables via simple string assignment. At the time of this writing, PHP seems to block several functions for access via this technique; eval() fails, as does system_exec(). But system(), for example, works like a charm and allows code snippets such as this to work:

This can be considered obfuscation heaven and enables far more complex and quirky examples, especially when combined with the already mentioned obfuscation techniques.