In this article i will show how you can do Burp Fuzzing using Python programming language.

At some point in your career, you may find yourself attacking a web application or web service that
doesn’t allow you to use traditional web application assessment tools. Whether working with a
binary protocol wrapped inside HTTP traffic or complex JSON requests, it is critical that you are
able to test for traditional web application bugs. The application might be using too many parameters,
or it’s obfuscated in some way that performing a manual test would take far too much time. I have also
been guilty of running standard tools that are not designed to deal with strange protocols or even
JSON in a lot of cases. This is where it is useful to be able to leverage Burp to establish a solid
baseline of HTTP traffic, including authentication cookies, while passing off the body of the request
to a custom fuzzer that can then manipulate the payload in any way you choose. We are going to work
on our first Burp extension to create the world’s simplest web application fuzzer, which you can then
expand into something more intelligent.
Burp has a number of tools that you can use when you’re performing web application tests. Typically,
you will trap all requests using the Proxy, and when you see an interesting request go past, you’ll send
it to another Burp tool. A common technique I use is to send them to the Repeater tool, which lets me
replay web traffic, as well as manually modify any interesting spots. To perform more automated
attacks in query parameters, you will send a request to the Intruder tool, which attempts to
automatically figure out which areas of the web traffic should be modified, and then allows you to use
a variety of attacks to try to elicit error messages or tease out vulnerabilities. A Burp extension can
interact in numerous ways with the Burp suite of tools, and in our case we’ll be bolting additional
functionality onto the Intruder tool directly.
My first natural instinct is to take a look at the Burp API documentation to determine what Burp
classes I need to extend in order to write my custom extension. You can access this documentation by
clicking the Extender tab and then the APIs tab. This can look a little daunting because it looks (and
is) very Java-y. The first thing we notice is that the developers of Burp have aptly named each class
so that it’s easy to figure out where we want to start. In particular, because we’re looking at fuzzing
web requests during an Intruder attack, I see the IIntruderPayloadGeneratorFactory and
IIntruderPayloadGenerator classes. Let’s take a look at what the documentation says for the
IIntruderPayloadGeneratorFactory class:

/**
* Extensions can implement this interface and then call
* IBurpExtenderCallbacks.registerIntruderPayloadGeneratorFactory()
* to register a factory for custom Intruder payloads.
*/
public interface IIntruderPayloadGeneratorFactory
{
/**
* This method is used by Burp to obtain the name of the payload
* generator. This will be displayed as an option within the
* Intruder UI when the user selects to use extension-generated
* payloads.
*
* @return The name of the payload generator.
*/
String getGeneratorName();
/**
* This method is used by Burp when the user starts an Intruder
* attack that uses this payload generator.
* @param attack
* An IIntruderAttack object that can be queried to obtain details
* about the attack in which the payload generator will be used.
* @return A new instance of
* IIntruderPayloadGenerator that will be used to generate
* payloads for the attack.
*/
IIntruderPayloadGenerator createNewInstance(IIntruderAttack attack);
}

The first bit of documentation tells us to get our extension registered correctly with Burp. We’re
going to extend the main Burp class as well as the IIntruderPayloadGeneratorFactory class.
Next we see that Burp is expecting two functions to be present in our main class. The
getGeneratorName function will be called by Burp to retrieve the name of our extension, and we
are expected to return a string. The createNewInstance function expects us to return an instance
of the IIntruderPayloadGenerator, which will be a second class that we have to create.
Now let’s implement the actual Python code to meet these requirements, and then we’ll look at how
the IIntruderPayloadGenerator class gets added. Open a new Python file, name it bhp_fuzzer.py,
and punch out the following code:

from burp import IBurpExtender
from burp import IIntruderPayloadGeneratorFactory
from burp import IIntruderPayloadGenerator
from java.util import List, ArrayList
import random
class BurpExtender(IBurpExtender, IIntruderPayloadGeneratorFactory):
def registerExtenderCallbacks(self, callbacks):
self._callbacks = callbacks
self._helpers = callbacks.getHelpers()
callbacks.registerIntruderPayloadGeneratorFactory(self)
return
def getGeneratorName(self):
return "BHP Payload Generator"
def createNewInstance(self, attack):
return BHPFuzzer(self, attack)

So this is the simple skeleton of what we need in order to satisfy the first set of requirements for our
extension. We have to first import the IBurpExtender class, which is a requirement for every
extension we write. We follow this up by importing our necessary classes for creating an Intruder
payload generator. Next we define our BurpExtender class, which extends the IBurpExtender
and IIntruderPayloadGeneratorFactory classes. We then use the
registerIntruderPayloadGeneratorFactory function to register our class so that the Intruder
tool is aware that we can generate payloads. Next we implement the getGeneratorName function
to simply return the name of our pay-load generator. The last step is the createNewInstance function
that receives the attack parameter and returns an instance of the IIntruderPayloadGenerator
class, which we called BHPFuzzer.
Let’s have a peek at the documentation for the IIntruderPayloadGenerator class so we know what
to implement.

/**
* This interface is used for custom Intruder payload generators.
* Extensions
* that have registered an
* IIntruderPayloadGeneratorFactory must return a new instance of
* this interface when required as part of a new Intruder attack.
*/
public interface IIntruderPayloadGenerator
{
/**
* This method is used by Burp to determine whether the payload
* generator is able to provide any further payloads.
*
* @return Extensions should return
* false when all the available payloads have been used up,
* otherwise true
*/
boolean hasMorePayloads();
/**
* This method is used by Burp to obtain the value of the next payload.
*
* @param baseValue The base value of the current payload position.
* This value may be null if the concept of a base value is not
* applicable (e.g. in a battering ram attack).
* @return The next payload to use in the attack.
*/
byte[] getNextPayload(byte[] baseValue);
/**
* This method is used by Burp to reset the state of the payload
* generator so that the next call to
* getNextPayload() returns the first payload again. This
* method will be invoked when an attack uses the same payload
* generator for more than one payload position, for example in a
* sniper attack.
*/
void reset();
}

Okay! So we need to implement the base class and it needs to expose three functions. The first
function, hasMorePayloads, is simply there to decide whether to continue mutated requests back
to Burp Intruder. We’ll just use a counter to deal with this, and once the counter is at the maximum that
we set, we’ll return False so that no more fuzzing cases are generated. The getNextPayload
function will receive the original payload from the HTTP request that you trapped. Or, if you have
selected multiple payload areas in the HTTP request, you will only receive the bytes that you
requested to be fuzzed (more on this later). This function allows us to fuzz the original test case and
then return it so that Burp sends the new fuzzed value. The last function, reset, is there so that if
we generate a known set of fuzzed requests — say five of them — then for each payload position we
have designated in the Intruder tab, we will iterate through the five fuzzed values.
Our fuzzer isn’t so fussy, and will always just keep randomly fuzzing each HTTP request. Now let’s
see how this looks when we implement it in Python. Add the following code to the bottom of
bhp_fuzzer.py:

 

class BHPFuzzer(IIntruderPayloadGenerator):
def __init__(self, extender, attack):
self._extender = extender
self._helpers = extender._helpers
self._attack = attack
self.max_payloads = 10
self.num_iterations = 0
return
def hasMorePayloads(self):
if self.num_iterations == self.max_payloads:
return False
else:
return True
def getNextPayload(self,current_payload):
# convert into a string
payload = "".join(chr(x) for x in current_payload)
# call our simple mutator to fuzz the POST
payload = self.mutate_payload(payload)
# increase the number of fuzzing attempts
self.num_iterations += 1
return payload
def reset(self):
self.num_iterations = 0
return

We start by defining our BHPFuzzer class that extends the class IIntruderPayloadGenerator.
We define the required class variables as well as add max_payloads and num_iterations
variables so that we can keep track of when to let Burp know we’re finished fuzzing. You could of
course let the extension run forever if you like, but for testing we’ll leave this in place. Next we
implement the hasMorePayloads function that simply checks whether we have reached the
maximum number of fuzzing iterations. You could modify this to continually run the extension by
always returning True. The getNextPayload function is the one that receives the original HTTP
payload and it is here that we will be fuzzing. The current_payload variable arrives as a byte
array, so we convert this to a string and then pass it to our fuzzing function mutate_payload.
We then increment the num_iterations variable and return the mutated payload. Our last function
is the reset function that returns without doing anything.
Now let’s drop in the world’s simplest fuzzing function that you can modify to your heart’s content.
Because this function is aware of the current payload, if you have a tricky protocol that needs
something special, like a CRC checksum at the beginning of the payload or a length field, you can do
those calculations inside this function before returning, which makes it extremely flexible. Add the
following code to bhp_fuzzer.py, making sure that the mutate_payload function is tabbed into our
BHPFuzzer class:

def mutate_payload(self,original_payload):
     # pick a simple mutator or even call an external script
     picker = random.randint(1,3)
     # select a random offset in the payload to mutate
     offset = random.randint(0,len(original_payload)-1)
     payload = original_payload[:offset]
     # random offset insert a SQL injection attempt
     if picker == 1:
        payload += "'"
     # jam an XSS attempt in
     if picker == 2:
          payload += "<script>alert('BHP!');</script>"
     # repeat a chunk of the original payload a random number
     if picker == 3:
           chunk_length = random.randint(len(payload[offset:]),len(payload)-1)
           repeater = random.randint(1,10)
           for i in range(repeater):
               payload += original_payload[offset:offset+chunk_length]
# add the remaining bits of the payload
payload += original_payload[offset:]
return payload

This simple fuzzer is pretty self-explanatory. We’ll randomly pick from three mutators: a simple SQL
injection test with a single-quote, an XSS attempt, and then a mutator that selects a random chunk in
the original payload and repeats it a random number of times. We now have a Burp Intruder extension
that we can use. Let’s take a look at how we can get it loaded.

www.extremehacking.org
Cyber Suraksha Abhiyan, CEHv9, CHFI, ECSAv9, CAST, ENSA, CCNA, CCNA SECURITY,MCITP,RHCE,CHECKPOINT, ASA FIREWALL,VMWARE,CLOUD,ANDROID,IPHONE,NETWORKING HARDWARE,TRAINING INSTITUTE IN PUNE, Certified Ethical Hacking,Center For Advanced Security Training in India, ceh v9 course in Pune-India, ceh certification in pune-India, ceh v9 training in Pune-India, Ethical Hacking Course in Pune-India