I expect:// a shell!

This blog post covers a fascinating method of leveraging Local File Inclusion to gain Remote Code Execution on a vulnerable host. It has several downfalls, but overall is one of the more interesting methods I have found, and I have not found any references to it anywhere that I looked online.

PHP has many “wrappers” to parse certain types of things. For example, the php://input or php://filter wrappers, which have been used in the past for both code execution and information disclosure – notably the PHP-CGI Arguement Injection exploit, which uses the php://input wrapper to inject code after making modifications to PHP.ini directives.

One of the more entertaining ones I stumbled across is how PHP handles the expect:// “wrapper”. For those who do not know, “expect” is a program/scripting language of sorts that one can use to interact with other interactive programs. Some of you may be familiar with pexpect from Python, which is used to interact with SSH sessions for automation. It is a rather powerful utility, and is often used by sysadmins to automate procedures which would normally require human interaction.

As it happens, amongst PHP’s many wrappers, there is an “expect://” wrapper. I stumbled across it by accident while looking up the correct way to use php://filter to read files via LFI (I will document that method later, it deserves a post of its own). I knew expect looked familiar, so when I looked more into it, I found examples of people using it in PHP scripts to automate things like ssh-ing to remote boxes, etc.

After a while it dawned on me that something interesting might just happen if I passed expect://ls to an include() call in a PHP script, so I decided to see what would happen.

I used the following vulnerable (to LFI) PHP script, and called test.php?hax=expect://ls

<?php
$code = $_GET[‘hax’];
include($code);
?>

It provided me with a directory listing of my webroot.

expecting shell

remote code execution

After a few minutes of thinking “oh, this is interesting”, I decided to see if I could knock up an interactive shell in Python to automate the whole procedure.

First off, I decided to see could I get it all to work out using Pythons “requests” module…

Seeing as it worked, now it was time to write a “shell”.

Gotshell?

got shell :)

Yes, I now had a somewhat interactive “shell” on the vulnerable host (localhost…). I considered releasing the proof of concept right there, however further messing about was warranted first, obviously. I needed to see how far I could “push” this vuln, and how cool I could possibly make the PoC tool before releasing it to the wild, where someone would doubtlessly give me much abuse about my python :P

So, without further ado, here is the video demo of it. It now checks if the host is vuln (very rudimentary check), and offers the “inline shell” or a reverse shell :) Download links at bottom :)

// Err, the video is on its way, I did not have time to clean it up sadly. I will edit this post in a day or so with the finished video, I promise :)

download link

Symantec Web Gateway 5.0.2 Remote Root Exploit

So I was browsing the net and happened across Muts’ latest PoC – an LFI bug in Symantec Web Gateway, which he claims gives remote root. You can see it here: Exploit DB

I read the exploit code and noticed, while beautifully elegant, it is a little bit of a pain in the ass to use, as you must edit it every single time.

I also was in the mood to knock up a quick bit of python, so here is what I made: Pastebin – Exploit Code

It is not the best, but was just my attempt to make the exploit code Muts provided a little better in the usability stakes :)

I have no Symantec WebGateway to test it in, but it should do the trick ;)

Anyway, thats it. All credit to Muts for finding the bug and writing the original exploit code, all I am doing is improving it. Will likely do this a lot for fun and to keep my programming skills sharpened :D

~infodox

More Decompile – Nuclear DDoSer

Seeing as it is the weekend, and I had promised this, here goes nothing… Yesterday you saw my decompile of the lame HTTP Flooder – see HERE – and today, I have decompiled Nuclear DDoSer.

I previously wrote about “Nuclear DDoSer” HERE , comparing it to the SlowLoris and Slowpost tools.

This thing, as a point of interest, operates in a similar way to how I theorize “XerXes” works, and with some modification and improvement could actually do a considerable amount of damage.

SO I will not be bothering making those improvements.

Go get it here…
http://insecurety.net/Downloads/NUCLEAR_DOS_DECOMPILE.tar.gz

MD5: c8248c60b438fe544c7dfdd847f53692
SHA1: c3757099dead3a3f7656c33a49072a8126174929

AS always, we decompile and release this stuff so you don’t have to, for purely educational purposes, and to satisfy our sense of schadenfreud toward the skidiots out there. “We do not like them very much”.

Decompiled Skidware – HTTP Flooder by “van1lle”.

Howdy all, see well, another GREAT day here at the labs! Sun is shining, boxes are overheating, sickness and most everyone is a little bit hungover at least…

Well, I decided to harvest a bunch of what I refer to as “Skidware” for decompilation purposes (practicing my .net fu) and decided to release this one first.

It is the source (and original binary) of a rather popular HTTP Flooding DoS tool, distributed on skript kiddie forums.

It is basically an app in C# that just spews “slowloris” at a server until it dies… Standard Layer 7 Denial of Service stuff. The original author bragged that he/she/it took down Virustotal using it.

So, here it is :D

MD5: 18a31dce229b2734eabdb207e2296a68
SHA-1: 04f70f94b91ade15ab2f1d968c152ef1e900a41b
Downloads…
http://insecurety.net/Downloads/HTTPFLOOD_DECOMPILE.tar.gz

We do not take responsibility for what you do with this.