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
Showing posts with label Security. Show all posts
Showing posts with label Security. Show all posts
Wednesday, 22 February 2012
Thursday, 16 February 2012
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
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
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
Monday, 6 February 2012
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:
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/
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)
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/
Friday, 3 February 2012
HTTP Session Hijacking
So. We all know about the infamous FireSheep, which caused an EPIC shitstorm when it came out - and was subsequently abused by many a bored student to "Frape" people in lecture halls.
For those of you who have slept throu gh the last year, here is a link to it...
Get FireSheep
Wikipedia: Firesheep
Firesheep on Linux
Now, onward! Firesheep only "Kind of" works on Linux, so we had to find other tools to do the same thing (session sidejacking without any ARP fuckery).
Also, installing FireSheep on Linux was such a total pain in the arse, even WITH instructions, that I soon got annoyed. I may write a .sh script to automate it all later, if I could be arsed.
However, fear not! Someone wrote something awesome! Hamster and Ferret!
Hamster and Ferret
It sets up a web proxy type thing and sniffs wireless. It works, most of the time.
It is also totally awesome!
Here is someone elses video on using it...
Now that is all pretty damn cool. But I found an even better tool yet on my travels...
SurfJack
Why is it better? 'cos it is written in python. That is why. And it is using SCAPY. I love SCAPY.
Check out their site here... Enable Security
There are, of course, a lot of nasty things one can do with session hijacking, and I planned a longer post on the topic but my fingers are tired.
For those of you who have slept throu gh the last year, here is a link to it...
Get FireSheep
Wikipedia: Firesheep
Firesheep on Linux
Now, onward! Firesheep only "Kind of" works on Linux, so we had to find other tools to do the same thing (session sidejacking without any ARP fuckery).
Also, installing FireSheep on Linux was such a total pain in the arse, even WITH instructions, that I soon got annoyed. I may write a .sh script to automate it all later, if I could be arsed.
However, fear not! Someone wrote something awesome! Hamster and Ferret!
Hamster and Ferret
It sets up a web proxy type thing and sniffs wireless. It works, most of the time.
It is also totally awesome!
Here is someone elses video on using it...
Now that is all pretty damn cool. But I found an even better tool yet on my travels...
SurfJack
Why is it better? 'cos it is written in python. That is why. And it is using SCAPY. I love SCAPY.
Check out their site here... Enable Security
There are, of course, a lot of nasty things one can do with session hijacking, and I planned a longer post on the topic but my fingers are tired.
Friday, 27 January 2012
Web Backdoors: Video
This is a video I made to quickly demonstrate some Web App Backdoors.
I demonstrate Weevely; FireInTheHole.py; PHPSploit; and two standard "web shells", the WSO2.php shell and the ITSecTeam shell.
I occasionally comment on each ones shortfalls, but here is the simple TL;DR one.
Weevely is amazing to use, has LOADS of features, the netcat bind and backconneect shells work perfectly, but it is slightly confusing for the first time user. It also remembers your current working dir and has a very intuitive shell (just like BASH) and fairly good error handling.
You can get it HERE: Weevely
FireInTheHole.py is fast, simple to use, uses both POST and/or GET and gives a terminal like session. It has no advanced features but has a couple of bugs, namely its non-interactive state. It *does* remember your current working dir however, which is very advantageous.
You can download it HERE: Fireinthehole.py
PHPSploit is a VERY nice "framework" which is currently in beta and has great potential. It looks a LOT like Metasploit, and I envision it becoming popular sometime in the future. It works fine, allows you to pull a lot of info, however it has some issues. It does not remember current working dir at all, so it can be rather annoying to "stack" commands for different dirs.
You can download it HERE: PHPSploit
I then demo the WSO2 PHP backdoor, which was failing pretty hard (some functions missing) and the ITSecTeam PHP backdoor, which seems designed to be "skid friendly" and has loads of features. I suspect both may be backdoored but have not investigated... YET. Neither had a functional backconnect or bindshell, and had a load of errors/bugs. I recommend *not* using these. You may find examples on google, and I plan to upload them myself later.
Now its video time!
I demonstrate Weevely; FireInTheHole.py; PHPSploit; and two standard "web shells", the WSO2.php shell and the ITSecTeam shell.
I occasionally comment on each ones shortfalls, but here is the simple TL;DR one.
Weevely is amazing to use, has LOADS of features, the netcat bind and backconneect shells work perfectly, but it is slightly confusing for the first time user. It also remembers your current working dir and has a very intuitive shell (just like BASH) and fairly good error handling.
You can get it HERE: Weevely
FireInTheHole.py is fast, simple to use, uses both POST and/or GET and gives a terminal like session. It has no advanced features but has a couple of bugs, namely its non-interactive state. It *does* remember your current working dir however, which is very advantageous.
You can download it HERE: Fireinthehole.py
PHPSploit is a VERY nice "framework" which is currently in beta and has great potential. It looks a LOT like Metasploit, and I envision it becoming popular sometime in the future. It works fine, allows you to pull a lot of info, however it has some issues. It does not remember current working dir at all, so it can be rather annoying to "stack" commands for different dirs.
You can download it HERE: PHPSploit
I then demo the WSO2 PHP backdoor, which was failing pretty hard (some functions missing) and the ITSecTeam PHP backdoor, which seems designed to be "skid friendly" and has loads of features. I suspect both may be backdoored but have not investigated... YET. Neither had a functional backconnect or bindshell, and had a load of errors/bugs. I recommend *not* using these. You may find examples on google, and I plan to upload them myself later.
Now its video time!
Thursday, 5 January 2012
Collection of web app backdoors (v1)
This is a collection of the common PHP (and ASP if I find them) backdoors used by malicious hackers to take over servers.
I am NOT responsible for your use of this!
Warning: There is every possibility these backdoors may be backdoored. I am going to eventually sort them into two folders - backdoored backdoors and clean backdoors. Then I can sit back and watch y'all go apeshit at some skiddies who backdoor their backdoors :D
Download the list here...Web Backdoors
I am NOT responsible for your use of this!
Warning: There is every possibility these backdoors may be backdoored. I am going to eventually sort them into two folders - backdoored backdoors and clean backdoors. Then I can sit back and watch y'all go apeshit at some skiddies who backdoor their backdoors :D
Download the list here...Web Backdoors
Subscribe to:
Posts (Atom)