Malybuzz - Network Fuzzer |
What is this?
Malybuzz is a Python tool focused in discovering programming faults in network software. It's a fuzzer and his function is to create malformed requests of the desired protocol to cause an unexpected situation which the target software can't manage correctly. The fact is that the appropriate security measures aren't adopted developing network-based applications nowadays, and it's an excellent channel to penetrate in a system, or to cause a Denial of Service at least.
The normal execution of the tool is composed by several steps. Firstly the malformed commands are generated depending on the configuration, the target application and the used protocol. After that, the communication channel with the target is established, and the commands begin to be sent. For each sent command a response will be waited and will be checked. If it's not correct, this situation will be reported, and otherwise the sending process will be continued.
The specification of each protocol is done through two XML files: one of them specifies the possible commands which can be sent and the other the possible responses for each of the commands. Nowadays only FTP and SIP protocols are defined but the addition of new ones is simple. For a better knowledge of the tool and the process to follow in order to add new protocols I recommend you reading the User Manual.
Usage
Usage: Malybuzz.py <target_host> <'tcp'|'udp'> <protocol> [options]
Usage: Malybuzz.py <target_host> <'tcp'|'udp'> <protocol> -g <commands_xml_file> <output_file>
Usage: Malybuzz.py -z <fuzzing_session_file> [options]
Usage: Malybuzz.py -h
OPTIONS
-h : print this help.
-v : set the verbose mode.
-k : keep the fuzzing state when session is aborted,so it will be possible to resume it. The session file is stored in the Restore folder.
-b : set it if the protocol to fuzz returns a banner.
-p <remote_port> : set the remote port.
-s <source_port> : set the local port.
-t1 <response_timeout> : set the response timeout in milliseconds after being sent a request. By default 100.000 ms.If 0 no timeout.
-t2 <ping_timeout> : set the timeout in milliseconds after being sent a ping probe. By default 2 ms.
-t3 <between_time_requests> : set the time in milliseconds between fuzzing requests. By default 500 ms.
-c <max_timeouts> : continue on timeout and set the maximum number of timeouts. If 0 no limit.
-f <first_command> : set the first command to send in the specified protocol.
-xc <xml_file> : set the commands configuration file we want to use to do the fuzzing. No sense with -z.
-xr <xml_file> : set the responses configuration file we want to use to do the fuzzing. No sense with -z.
-o <commands_file> : open a commands file and load it in the actual fuzzing session. It must be in the 'Restore/Commands' folder. No sense with -z.
-l 1|2|3 : log the fuzzing session in the 'Logs' folder with the specified level.
1: Critical,error and warning messages.
2: Level 1 plus info messages.
3: Level 2 plus debug messages.
-z <fuzzing_session_file> : resume a fuzzing session from a session file.
-g <xml_file> <output_file> : generate the commands we want to send extracted from a xml file and save them in the Restore folder. No sense with -z.
How does it work?
- How can I launch the fuzzing session?
The general syntax is:
./Malybuzz.py target_host tcp|udp protocol_to_fuzzThis is an example for the SIP protocol:
./Malybuzz.py 192.168.0.25 udp sipBut this is the default way, this won't fuzz anything, it's only a sample. This is based on the sip.xml template file of the Protocols/Specifications/UDP/sip folder. In this folder there are some useful samples,like inviteFuzzingLength.xml and inviteTest.xml. To create your own fuzzing test you must make a copy of the templates and samples and modify them. Once you've done it you can launch the test as follows:
./Malybuzz 192.168.0.25 udp sip -xc Protocols/Specifications/UDP/myOwnSIPFuzzing.xmlAlso, by default, the first command which is sent in SIP fuzzing sessions is the CANCEL command. Perhaps I'll change this in the next release, but at this moment you must add '-f INVITE' if you want to obtain some valid communications with the SIP application (if you want, you can modify the responses protocol file sip_states.xml too). So...
./Malybuzz 192.168.0.25 udp sip -xc Protocols/Specifications/UDP/myOwnSIPFuzzing.xml -f INVITEAn FTP example can be the following:
./Malybuzz 192.168.0.25 tcp ftp -xc Protocols/Specifications/TCP/ftp/ftpTest.xml -bThe '-b' option must be added if the application returns a banner message when it receives a connection.
- If I want to do the same fuzzing tests against various targets, do I have to generate the same commands all the time?
No, you can generate the commands with the '-g' option:
./Malybuzz.py 192.168.0.25 udp sip -g Protocols/Specifications/UDP/sip/inviteTest.xml mySIPCommandsThis will create some fixed tests in the Restore/Command/mySIPCommands[date]@[time] folder which you can use with the '-o' parameter as follows, gaining some time:
./Malybuzz.py 192.168.0.25 udp sip -o Restore/Commands/mySIPCommands2007-10-21@23:39:11/mySIPCommands ./Malybuzz.py 192.168.0.30 udp sip -o Restore/Commands/mySIPCommands2007-10-21@23:39:11/mySIPCommands
- But, what happens if I must shutdown the computer before the fuzzing session has finished? The next time, will the session be started from the beginning?
No, you can specify that you want to store the session when it's aborted adding the '-k' parameter, and Malybuzz will copy your fuzzing point in the Restore folder. After that, you will be able to resume it with the '-z' option:
./Malybuzz 192.168.0.25 udp sip -xc Protocols/Specifications/UDP/myOwnSIPFuzzing.xml -f INVITE -k ./Malybuzz -z Restore/192.168.0.25_sip2007-10-21@23:46:08
- This tool is sooooo baaaaad...I obtain a lot of timeouts and this doesn't run like it's supposed to do.
OK, be quiet...this is not a magic wand. The fuzzing effectivity depends on the target application and the fuzzing configuration. You must understand the application behaviour and set some values to the different available timeouts (t1, t2 and t3). Perhaps you have to modify the responses protocol XML file too, in order to trace an specific communication line (send Y command when it receives X response, for example). The timeouts configuration can be done easily, but the other one is a bit more complex.
- OK, but how can I configure a fuzzing session? what types of fuzzing can I do?
Like I've said, if you want to do your own tests you must copy and modify the base protocol file. You can mark the commands and fields to be sent with the attribute 'send' set to 'yes', and specify that you want to fuzz them with the 'fuzzing'. The possible values for this attribute are 'overflow', 'formatString', 'badString', 'badNumber', 'badPath', 'badIp', 'badHost', 'repeat', 'sql' and 'binary'. You can set more than one fuzzing type by separating them with commas. A little example:
<global-arg name="URI_PROTO" type="text" send="yes" fuzzing="overflow,badString">sip:</global-arg>
Docs
More info
