Since everyone else is doing it...
Top 10 posts of of the year 12/26/2008 - 12/26/2009 - blogspot
Adding your own exploits and modules in Metasploit
Gray Hat Python: Python Programming for Hackers and Reverse Engineers Book Review
Dumping Memory to Extract Password Hashes
Using the Metasploit SMB Sniffer Module
Metasploit and WMAP
Metasploit + Karma=Karmetasploit Part 1
Token Passing with Incognito
Metasploit + Karma=Karmetasploit Part 2
Getting your smartcard to work with Ubuntu
msvctl -- pass the hash action
Top 10 posts of of the year 12/26/2008 - 12/26/2009 -- AttackResearch
Release of the TOR Backdoor
Coming soon to a pentest near you... (assagi teaser)
Microsoft DirectShow MPEG2TuneRequest Stack Overflow P0C
Why I hate web app pentesting...
PDF Defiling Intro
Past, Present, and Future of Security and the Security Community
Failing the Test of Trust (guest post By Timelord)
More On Metasploit Meterpreter & Timestomp
Security Conferences, pen tests and incident response
Metasploit JSP Shells
Top 10 Keywords that brought people to the blog -blogspot
Top 10 Keywords that brought people to the blog - AttackResearch
client-side penetration testing notacon edition slides
Top 10 Referring Sites - blogspot
Top 10 Referring Sites - AttackResearch
Top 10 Countries - blogspot
Top 10 Countries - AttackResearch
carnal0wnage [Shared Reader]
Sunday, December 27, 2009
Since everyone else is doing it...
Posted by CG at 5:53 PM
Friday, December 18, 2009
Today I was asked to give a proof-of-concept as a fun way of entering the holiday season. The idea was to prove why file upload (without extension / file type checking) can be dangerous. The target client and web server were both using A/V. We already knew it was possible to upload whatever type of file you chose. The question was, as the administrators demanded would be the case, would the A/V stop such an attack.
Using solely the technique gained Here , which is @Mubix's site......sadly......the answer is NO. Now a week ago this would have worked. Recent A/V updates have changed that. So how to get around it?
Note: I've been warned by @carnal0wnage
that this technique will most likely flag on some products because of the UPX packing.
That being said, it worked great against the A/V and it turned out to be a fun day.
Create and encode the meterpreter payload as instructed on Mubix's site (link above).
Download the UPX packer Here. I chose the upx-3.04-i386_linux.tar.bz2 for BT4.
Now simply bunzip2 & tar -xvf the file and cd into the upx directory. Perform a ./upx
Need some last minute books to beat up on Oracle? Here's a list.
(you'll have to go to the rampant press site http://www.rampant-books.com/book_0701_oracle_forensics.htm)
Posted by CG at 9:39 AM
Friday, December 11, 2009
From the old skool files...
This is the very first episode of the Net Cafe series. It was shot on location at a cybercafe in San Francisco called CoffeeNet. It looks at the hacker culture and their influence on the early growth of the internet. Guests include Dan Farmer, author of SATAN and COPS; Elias Levi (aka Aleph 1), webmaster of underground.org and Bugtraq; also "Reid Fleming" and "White Knight" from Cult of the Dead Cow. Originally broadcast in 1996.
I'm sure most folks have already used this feature but for those that haven't, I came across a situation recently where I was asked to test an Intranet application and found the 'do WWW Authentication' piece of functionality made life much easier for me.
So as you may know from my earlier post regarding extracting HTML comments using DirChex, Burp Suite and a Burp Suite Plugin this process is very quick and very simple.
DirChex is basically a dumb application. It is fed a list of URIs like so:
(That last line was for you Jack)
and it blindly requests each URI thru the proxy of your choice. The whole idea is to view the request/response as an unauthenticated user. I provide no options for setting a cookie/sessionID/login creds.
Here is the problem I ran into. I'm testing an Intranet application, the application uses NTLM which is tied to your Windows Domain account to receive access to the main page of the application. Only after you've first authenticated via your domain account will you have access to the actual application (which has a login form, technically your half authenticated?). So to test the "unauthenticated" portion you technically have to be authenticated :-)
This is where you can save your self some time. If you utilize the 'do WWW Authentication' option every request that is sent via Burp will automatically have the NTLM/Basic/Digest credentials included.
Navigate to the 'Comms' tab ('Options' tab in later version) and fill in the following:
Hope this helps someone.
Wednesday, December 9, 2009
Just as an update, if you downloaded the Backtrack 4 DirChex_v1.1 tool and are having issues with the install relating to the apt-get install libXXXX portion, ensure you enter "apt-get update" FIRST so that the newest packages and their corresponding locations are up to date.
Friday, December 4, 2009
On a recent pentest one of the findings that came up (actually it seems like this finding is on every pentest) is the web server allowing SSLv2.
In the course of doing the report I of course wanted to point to a good reason why this was the case. It was actually difficult to find a CVE/CVSS/etc to say why its bad, in fact I never did. Kind of the same with allowing VRFY on your SMTP server. We all know its bad, but where is the proof.
Nevertheless, here are some links that were useful in understanding the problem.
OSVDB updated their entry for SSLv2
Also a couple of tools to do some checking for you:
nmap will do this for you with -A with port 443 open or with the sslv2 script
ssl-cipher-check.pl from http://www.unspecific.com/ssl/
Example output from the tool site:
$ perl ./ssl-cipher-check.plDefault Output:
: SSL Cipher Check: 1.2
: written by Lee 'MadHat' Heath (at) Unspecific.com
./ssl-cipher-check.pl [ -dvwas ]
default port is 443
-d Add debug info (show it all, lots of stuff)
-v Verbose. Show more info about what is found
-w Show only weak ciphers enabled.
-a Show all ciphers, enabled or not
-s Show only the STRONG ciphers enabled.
$ perl ./ssl-cipher-check.pl mail.yahoo.com
SSLv3:RC4-MD5 - ENABLED - STRONG 128 bits
SSLv3:DES-CBC3-SHA - ENABLED - STRONG 168 bits
SSLv3:RC4-SHA - ENABLED - STRONG 128 bits
** SSLv3:DES-CBC-SHA - ENABLED - WEAK 56 bits **
** SSLv3:EXP-RC4-MD5 - ENABLED - WEAK 40 bits **
** SSLv3:EXP-DES-CBC-SHA - ENABLED - WEAK 40 bits **
** SSLv3:EXP-RC2-CBC-MD5 - ENABLED - WEAK 40 bits **
SSLv3:AES128-SHA - ENABLED - STRONG 128 bits
SSLv3:AES256-SHA - ENABLED - STRONG 256 bits
TLSv1:RC4-MD5 - ENABLED - STRONG 128 bits
TLSv1:DES-CBC3-SHA - ENABLED - STRONG 168 bits
TLSv1:RC4-SHA - ENABLED - STRONG 128 bits
** TLSv1:DES-CBC-SHA - ENABLED - WEAK 56 bits **
** TLSv1:EXP-RC4-MD5 - ENABLED - WEAK 40 bits **
** TLSv1:EXP-DES-CBC-SHA - ENABLED - WEAK 40 bits **
** TLSv1:EXP-RC2-CBC-MD5 - ENABLED - WEAK 40 bits **
TLSv1:AES128-SHA - ENABLED - STRONG 128 bits
TLSv1:AES256-SHA - ENABLED - STRONG 256 bits
** SSLv2:RC4-MD5 - ENABLED - WEAK 128 bits **
** SSLv2:RC2-CBC-MD5 - ENABLED - WEAK 128 bits **
** SSLv2:DES-CBC-MD5 - ENABLED - WEAK 56 bits **
** SSLv2:EXP-RC4-MD5 - ENABLED - WEAK 40 bits **
** SSLv2:EXP-RC2-CBC-MD5 - ENABLED - WEAK 40 bits **
** SSLv2:DES-CBC3-MD5 - ENABLED - WEAK 168 bits **
*WARNING* 14 WEAK Ciphers Enabled.
Total Ciphers Enabled: 24
Links that go with the above tools
ssl-cipher-check author's talk slides
Disabling SSLv2 on a variety of services: