Fizzer Walkthrough

In September of 2013, GDS released a tool named Fizzer to fuzz the FIX (Financial Information eXchange) protocol.  You can find the original blog post here.

As a follow up to the original release of Fizzer, we wanted to give a brief walkthrough of running the tool.  Furthermore, different FIX receivers handle the fuzzed packets in different ways.  In addition, a couple of code changes can turn this tool into a quick way to test authentication or authorization in FIX systems.  For these reasons, we wanted to dive into some scenarios where you might want to modify the code.

Running Fizzer

Fizzer runs by inserting fuzz strings into FIX requests it parses from a raw packet capture.  The first step is to record a live FIX session between a client and server.  This session must be saved in RAW format to be accepted by Fizzer.  In Wireshark, this can be accomplished by following the TCP stream and selecting “Save As” for the selected conversation.

Once the session has been exported as a raw file, it can be given to Fizzer as a command line argument.  The host IP address, port, Sender Comp ID (sending institution), starting sequence number, and an optional output log file must also be specified.   Running the program without any command line arguments will show information about the usage of these arguments.

Common Modifications and Scenarios

Add Sender Comp ID to Ignored Tags

There is a line in the main loop which specifies which tags should not be fuzzed.  Some organizations may opt to include the SenderCompID (tag 49) in this list.  Adding “49=” to code below will instruct Fizzer to ignore that field.  By default, the BeginString, Message Length, MsgType, MsgSeqNum, and Checksum are ignored.  

else if (part.StartsWith(“8=”) || part.StartsWith(“9=”) || part.StartsWith(“35=”) || part.StartsWith(“34=”) || part.StartsWith(“10=”))


//Don’t fuzz these tags


Respond to Resend Requests

The FIX protocol includes specifications for a resend request initiated by the receiving application.  These are commonly used when an error with sequence numbers is detected or the receiving application was not able to adequately process a message.  Testing Fizzer against different FIX receiving servers showed varying behavior when responding to resend requests.  Some systems will block until a valid message is sent while others will proceed without issue.  The way sequence number and orderID are handled also varies between systems.  It may be necessary to customize or remove the section of code which resends the original message when a resend response is received from the server.  The following shows this section of code.

else if (Regex.IsMatch(fuzzResponse, getSoh() + “35=2” + getSoh()))


    Console.WriteLine(“[INFO] - Got Resend Request: ” + fuzzResponse);

    //try sending the orginal message to reset the system

    fuzzMsg = updateTimeSequenceChecksum(Original, sequence, ordId);

    Console.WriteLine(“[INFO] - Sending Clean Message: ” + fuzzMsg);

    testTime = DateTime.Now;

    sendData(client, stream, fuzzMsg, out fuzzResponse);

    responseTime = DateTime.Now - testTime;

     logMessage(testTime.ToString(“yyyyMMdd-H:mm:ss.fff”), “reset::” + fuzzMsg, fuzzResponse, responseTime.Milliseconds.ToString());


    //account for response sequence number



Modify Defines

Two global variables at the top of the program are used to define the starting order id number and the regex to detect sequence errors.  These will need to be modified for the individual environment.

Add new Fuzz Strings

A function getFuzzList() is used to generate the array of fuzz strings.  New test cases should be added to this section.

Extending Functionality

There are a number of ways to quickly modify the program to test beyond simple fuzzing.  In the past, just a few lines of code have been needed to perform automated authorization testing against all captured requests.  This was accomplished by only fuzzing the SenderCompID and using the function getFuzzList() to generate the list of other organizations.  In addition, fuzzing sequence numbers or sending numbers out of sync have yielded interesting results.  Modifying the sections of code that iterate sequence numbers can be used to test for these conditions in other systems.

Test Environment

One way to try Fizzer out is to leverage the QuickFix example applications located at the URL below.  Hint: try removing the message resend functionality as mentioned above.


HTTP NTLM Information Disclosure

Remote enumeration of host/service details is a core activity of any penetration test. In support of such activities, we’ve released a new Nmap script that anonymously enumerates remote NetBIOS, DNS, and OS details from HTTP services with NTLM authentication enabled.

NTLM authentication is supported over HTTP, and is often used to protect application content and resources from unauthorized access. As part of the HTTP NTLM authentication process, a series of challenge-response messages are exchanged. By analyzing the encoded NTLMSSP information contained within specific messages, potentially sensitive information can be enumerated from remote hosts.

Host information can be enumerated using NTLM over HTTP in a manner similar to NTLM authentication over SMB, in which remote host information can be enumerated by sending anonymous credentials. By sending a NTLM authentication request with null domain and user credentials (passed in the ‘Authorization’ header), the remote web server will respond with a NTLMSSP message (encoded within the ‘WWW-Authenticate’ header) and disclose information including NetBIOS, DNS, and OS build version.

While this is not an active exploit, it’s extremely useful for network reconnaissance: the information disclosed may be used as part of more complex attacks, such as leveraging domain information for brute forcing accounts, identifying internal hostnames during external to internal pivoting activities, or determining end-of-life operating systems.

Lets see how this works using the script we’ve written for Nmap:

#nmap -p443 —-script http-ntlm-info

Nmap scan report for
Host is up (0.040s latency).
443/tcp open https
| http-ntlm-info:
|  Target_Name: ACTIVEWEB
|  NetBIOS_Domain_Name: ACTIVEWEB
|  NetBIOS_Computer_Name: PRODWEB001
|  DNS_Domain_Name:
|  DNS_Computer_Name:
|  DNS_Tree_Name:
|_ Product_Version: 5.2 (Build 3790)

Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Since this script is considered default/safe, it will also run automatically when the ‘-sC’ or ‘-A’ flags are utilized.

During penetration testing such configurations are often encountered, and unfortunately are often passed over by many due to a lack of understanding the protocol and the type of information that can be anonymously enumerated. So how common are such web server configurations? Utilizing Shodan, below quantifies the number of internet facing web servers supporting NTLM authentication over HTTP and HTTPS:

Web Server Type HTTP HTTPS
Microsoft-IIS/5.0 (Windows 2000 Server) 4,342 1,067
Microsoft-IIS/5.1 (Windows XP) 1,945 151
Microsoft-IIS/6.0 (Windows Server 2003) 70,784 42,768
Microsoft-IIS/7.0 (Windows Server 2008) 13,790 8,241
Microsoft-IIS/7.5 (Windows Server 2008 R2) 47,235 34,493
Microsoft-IIS/8.0 (Windows Server 2012) 6,934 2,591
Microsoft-IIS/8.5 (Windows Server 2012 R2) 883 533
Microsoft Other (e.g. WinCE, etc.) 1,352 28
Unknown & Open Source Implementations 3,438 2,111
Total 150,703 91,983

*Note, does not account for hosts with both anonyous and NTLM authentication enabled

Currently, outside of disabling NTLM authentication over HTTP, there is no method to mitigate leaking such information under Microsoft IIS — all versions are affected by design.

This script, ‘http-ntlm-info’, has been tested against all current/past Microsoft IIS versions and open source HTTP NTLM implementations. It can be obtained here or via the current Nmap Subversion repository (r32706 or higher).

Note: If adding the script manually, the ‘nmap —script-updatedb’ command will need to be issued (as root/admin) to update the local script database.


Web-based Single Sign-On and the Dangers of SAML XML Parsing

Security Assertion Markup Language (SAML) is a popular XML-based open standard for exchanging authentication and authorization data between two systems.  In the world of enterprise cloud applications, SAML is one of the most common protocols for implementing single sign-on between enterprise customers and cloud service providers. While implementing SAML authentication for our SendSafely secure file exchange solution, we encounted some security concerns with one of the more popular open source libraries for parsing SAML requests. 

Check out our latest post over at the Send Safely Blog for the complete details. This post should be a must read for any organization that is handling SAML request data. 


Building Fortify Custom Rules for Spring MVC

Looking for a Fortify rule that combines the power of structural rules with dataflow analysis capabilities? The (currently not well documented) CharacterizationRule is an awesome type of rule that will let you go beyond the restrictions of traditional dataflow analysis rules by allowing you to define dataflow parsing instructions based upon a code structural match.

Here’s an example of a rule, used against a Java Spring controller class, that will identify tainted data from parameters mapped using Spring specific annotations. This can be used to identify XSS flaws using static analysis that were only previously identified through dynamic testing.

<CharacterizationRule formatVersion="3.17" language="java">
        Function f: f.parameters contains [Variable v: v.annotations[0] matches "org.springframework.web.bind.annotation.RequestParam" ]
        TaintEntrypoint(v, {+XSS})

Used on a class similar to the following, this would essentially add the taint flag ‘XSS’ to any parameters specified with the @RequestParam mapping annotation (fully qualified class names being required) contained within the query string of the requested controller.


@RequestMapping(value = "/url")

public class PageController  {

@RequestMapping(value = "/action", method = RequestMethod.GET)

public String action(@RequestParam(value = "q", required = false) final String parameter )  {

As mentioned earlier, this type of rule is currently not fully documented but some syntax guidance is available within Fortify SCA’s structural type system documentation. You can also leverage the Fortify custom rule editor to benefit from syntax completion and XML structure validation.


Pushing CSP to Prod Slides From Appsec USA

Note: This post has been crossposted from the SendSafely blog. You can find the original post at  

In case you missed the presentation by SendSafely’s Brian Holyfield and Erik Larsson at OWASP AppSec USA, we’ve posted a copy of the deck in our GitHub repository.  Brian and Erik discussed some of the challenges we faced here at SendSafely when implementing Content Security Policy (CSP) on our site.  There will also be a video recording of the talk posted in the AppSec 2013 YouTube Channel.

Thanks again to everyone that came out to the conference and especially those that came by our booth to say hi. We hope you all had as much fun as we did!