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] = 2end
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-5Ln 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-9Ln 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-12Ln 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
OSVDB Vulnerabilities
Bugtraq
Penetration Testing
Carnal0wnage
The Exploitant
Lines 40-53: 
