Security Information Vulnerability Research Security Blog

Fuzzing the FIX Protocol

December 3rd, 2007 by , Filed under: Commentary, Full Disclosure

We have been asked by one of our customers to provide a beSTORM fuzzing module for the FIX protocol, for those who don’t know what FIX is – in laymen terms it what allows the world of finance to work as it is part of the Financial Information eXchange, the protocol is fairly simple and very insecure – not just because it is textual.

I will update you guys as soon as I can provide more details.

Share
  • http://axonsoftware.biz Serg Gulko

    Hello!

    Thing is that FIX protocol never used over Internet. Parties connected to each other through Radianz, VPN or using SSL. Of course, you can find people sending orders without any encryption….but from my point of view this is problem of people, not of protocol:)

    One more thing – FIX protocol is something what is using by very limited quantity(comparable to native brokers trading terminals etc) of clients. Each connection are named, so for sell side is very easy determine who tried to make something wrong.

    So from my point of view no need add extra security where it not required.

  • Just Guess

    The security that needs to be added is for the protocol parser not the logic of the product.

    Even if the connection is named, encrypted, and everything it doesn’t mean that the protocol parser by the product receiving this connection should be vulnerable to simple attacks ranging from the simple DoS to the more dangerous buffer overflow and code execution.

  • http://axonsoftware.biz Serg Gulko

    Good designed FIX gateways not available in public Internet. You can have access only through VPN to LAN(or something like this).
    And we can wish best of luck to attacker perform DoS through named channel:)
    As for code execution – yes, this is theoretically possible but first depends on your FIX engine which should perform fields validation according to settings(strings, numbers) and in second stage if you map incoming data into DB – on your application.
    I am not telling that if FIX is not very public protocol he should not be secure:) Of course not. Clients will not be happy if someone can still their financial information but in most of the times security problems of FIX are not very big. At least from my point of view.

  • Just Guess

    Your approach is problematic

    You as saying because it is internal, and secured by a named channel it should be tested for security

    One doesn’t justify the other

    Why do you use both a Firewall, Antivirus, IDS, VPN, etc if each just adds another layer of safety?

    I believe, like the author of this post, that testing is layers, testing your product and specifically the FIX protocol, gives you an assurance that if all else fails, you still have a good product that will be able to stand to an attack.

  • http://axonsoftware.biz Serg Gulko

    Hello!

    >>Why do you use both a Firewall, Antivirus, IDS, VPN, etc if each just adds another layer of safety?

    Only because we are talking about different types of safety.
    Unlike to web/http where almost anything can be a security hole FIX is more like private club. Only trusted members are invited and if someone decided go against rules – this mean that he lost his membership.

    Talking technically – security problems should be solved on level of FIX engines performing fields validation. Most of them doing such things. All the rest – is only good programming practice….
    I am not a big security guru so possible i missed something. Your colleague said ‘very insecure – not just because it is textual’. Why also?

  • Share







  • Categories


Security RSS Subscribe