Updates to Insecurety Research - PHP Command Injection!

So, we have written an article about PHP Command Injection (Applies to other platforms too, we just covered PHP).

Read it here! PHP Command Injection - Insecurety Research

More to come...

~Insecurety Research Team.

WebApp Haxploitation with Weevely, Introducing InterSect.

Ok. This is a fairly pointless demo I made to demonstrate how a web-application bug (in this case LFI + Command Injection) can be leveraged to gain complete root access over a server. I simply took a bunch of screencaps during the demo I made to show a friend "Why web app bugs are dangerous".

So. Here goes!

The web app we used here was THIS: Mutillidae - IronGeek

Part One: The Buggy Page.
This shows the buggy applications vulnerable page. It is a simple "Do a DNS lookup" page that just by looking at we can discern certainly has a Local File Inclusion vulnerability, and more than likely a Command Injection vulnerability.

Part Two: Lets Look for LFI
So. I knew there was LFI, and decided I would let fimap check for me, to see could I pull off any LFI-RCE stuff.

So. Now we know Fimap no canhaz RCE on the site, however there IS LFI. I want RCE, so I move swiftly along to the second vulnerability - Command injection.

Part Three: Command Injection
I decided to inject a Weevely Webshell into the app, so I put it up on my webserver and used wget to "inject" it.
Here is a screencap...

Ok. Shell seems injected, so we move on and try connect to it using the Weevely Client.

Part Four: There are Weevils In Your WWWROOT
Connecting to Weevely's PHP backdoor with the client. This is too easy...

So, lets see what it looks like in there...

SO! Got remote code execution and a "shell" like session. Let's see does Weevely's reverse shell work for us and try become uid=0 :D

Part Five: Netcat Sais Meow
First off, we start Weevely's reverse shell plugin and tell it to phone home to us... We will be listening for it...

Ok. Now for the listener end of things...

w00t! We haz a shell :D
... Moving Swiftly along...

We decide to check kernel version and randomly see what commands work. I decided to lsusb for some arbitrary reason. Don't ask.

Ok. So we move on to escalating/exploring!

Part Six: Enter InterSect.
So I decide to test out InterSect, a wonderful post-exploitation tool developed by ohdae of BindShell Labs.

Here is a screencap of wgetting Intersect to the target box...

Aaaaand now to RUN Intersect ......

Ok. Intersect does not want to run as NON root, so it tells me how to get root on the box... Seeing as I like root... lets go get some!

Part Seven: We Are uid=0, + Harvest Some Infodox
So. I simply run a hypothetical root-exploit I had left in /tmp and getr00t! (It was actually a SUID shell I dropped earlier, as my kernel doesnt like localroots and panics!)

So. Got root. What next? Lets try see does InterSect want to run this time...

It Works! Sadly my battery promptly /quit a moment later but I think you get the idea of what you can do!

LINKS:
BindShell Labs
Intersect 2 - GitHub
Weevely - GoogleCode
Fimap - GoogleCode
And Finally
Insecurety Research

New Project - ShellCode Collection/Repository

So. After getting sick of having to search all the time for shellcode, I decided it would be a nice idea to just create a nice repo of shellcode so people can just svn up and have a searchable repo of organized shellcode.

Hence I started this project.

It is a slow thing to start, and I seriously need people to help me. I can add people as committers if they want to help out, and the idea is to collect a wide variety of shellcode for various OS/Architectures/systems and have it searchable.

I eventually hope to clean up existing shellcode and add a python script for searching the repo, compiling, objdumping and encoding the shellcode.

Anyways, without further ado..

Project Homepage: Insecurety Research - Shellcode Repository
GoogleCode Page: Shellcode Repository at Google Code

Web Malware Collection Updated

Ok, quick post. The Web Malware Collection has had some updates done, and I am *Still* busy sorting samples to commit.

Currently it has 443 samples (according to this "find . -type f | wc -l" command)

Project Page: http://insecurety.net/projects/web-malware/
GoogleCode: http://code.google.com/p/web-malware-collection/

SVN repo is on googlecode so SVN up :D

POST-it DoS

So. Got bored waiting for a lecturer who showed up late, and decided to add some shit to POST-it DoS while working on code for RailGun.

I added a massive list of Useragents (like 70k of em or something, its big...), randomize-useragent-from-list function, and a rather epic random junk generator for the POST data instead of using just a big load of X's.

So now it hits a bit harder (actual random junk) and may even defeat some failures of IDS/IPS... until the target box dies, that is.

It KIND OF implements a SlowLoris attack of kinds too, just to make it even more awesome.

Check it out here --> POST-it DoS and as always, use SVN to get it :)

Denial of Service Attacks, Layer 7

This is a brief reposted post (one I wrote ages back) on how Layer 7, or "Application Layer" Denial of Service Attacks work.

Application Layer DoS attacks are a newer form of DoS attack. They work by not simply flooding/saturating the servers bandwidth, but by attacking a specific service, or application, running on the server. They often require far less bandwidth to accomplish, and are far more "efficient" an attack method. No massive botnets are required for an attacker to be able to effectively take out the target service.

I first got interested in Layer 7 DoS after realizing that LOIC and such "packet flooders" were essentially next to useless. TCP flooding was bandwidth intensive and required either a horde of fools, a large botnet, or a fucking huge datapipe to accomplish (a few cheap VPS's, however, made the job easier...). Sure, you could use spoofing and such attacks to enhance your "firepower", but when up against *big* targets with fairly impressive filtering, you were essentially wasting resources.

For those of you unfamiliar with Layer 7 DoS attacks, have a read of this paper from OWASP - it was what gave me my head start in understanding it all.
Layer 7 DoS - OWASP

Now. Onward to the "attack techniques". The series I wrote on DoS attacks was all about explaining what attack methods are used where, and seeing as the only edits done in this repost were a quick spellcheck and this comment, I do not plan on editing very much else. Yes, I am lazy.

HTTP GET DoS / SlowLoris Attack.
Wikipedia on Slowloris
Original page explaining it

Now, first off, list of affected target webservers:

• Apache 2.x 
• Apache 1.x
• dhttpd
• GoAhead WebServer
• WebSense "block pages" (unconfirmed)
• Trapeze Wireless Web Portal (unconfirmed)
• Verizon's MI424-WR FIOS Cable modem (unconfirmed)
• Verizon's Motorola Set-Top Box (port 8082 and requires auth - unconfirmed)
• BeeWare WAF (unconfirmed)
• Deny All WAF (unconfirmed) 

All of these are (according to RSnake), affected by the SlowLoris technique.

How it works is simple, it asks the server to wait. The server, being nice, waits. It does this simulating over9000 clients. The server keeps on waiting, being nice. Server dies, pretty much.

Now, to the interesting part. Attack Tools.
Original Slow Loris
TOR Loris - SlowLoris w/ Multiple TOR Proxies
PyLoris - Python SlowLoris
In Development: FluxLoris (Rapid SOCKS switching SlowLoris implementation)

HTTP POST DoS Attack (SlowPost)
This one was inspired by the OWASP paper I referred to above, and we released a PoC tool to exploit the bug around Christmas 2010. I worked on developing the tool and learned a LOT. Basically you are uploading (POST-ing) data to the server and saying "Hey, you! I am on a laggy connect! Please wait!". The server waits... And waits... You keep the connection open.
You do this with a literal shitload of threads.

It requires bugger all bandwidth and has a very destructive effect, rendering most webservers 404-ed within a few minutes.

So, here was our initial PoC tool:
POST-it v1

We had a more "lethal" variant but it is lost long ago, maybe some day I will dig it up and re-implement it, but given current climate, no point.

Now, onward, there are far better attack tools!
SlowPost by NEC - This one is VERY nice. Uses Proxy lists to anonymize the attack. Was written by the current mantainer of the "LOIC" package I believe.

OWASP HTTP POST DoS - This one is from OWASP, and seems to be moreso for testing.

R U Dead Yet - This one is considered the "industry standard" for HTTP POST DoS attacks. It works. Most of the time. I know of some unusual errors it has thrown in the past, but it has TOR support.

And finally, the well known and loved TORSHAMMER . This one is incredibly effective, known to drop servers within minutes. Anecdotal evidence has it one guy on a DSL line took out a bunch of Iranian government websites for a half hour a year or so ago, and then ate the Libyan .gov servers for second helpings! It works fairly reliably, and uses TOR.

There are a great deal of other attack tools out there exploiting these weaknesses, but the best bet (for now) to avoid the embarassment of someone taking you down a peg with some of these is to use the NGINX platform for a webserver. It works fairly well and seems to just blatantly ignore these attacks.

Further Reading...
Testing Webservers for Slow HTTP Attacks
http://en.wikipedia.org/wiki/Denial-of-service_attack
http://www.acunetix.com/blog/web-security-zone/articles/http-post-denial-service/
http://www.us-cert.gov/cas/tips/ST04-015.html
http://isc.sans.edu/diary.html?storyid=6601
http://www.funtoo.org/wiki/Slowloris_DOS_Mitigation_Guide
http://www.checkpoint.com/defense/advisories/public/announcement/071409-slowloris-dos-attack.html
http://www.bullten.com/what-is-slowiris-ddos-attack-and-how-to-mitigate-its-effect/