PETA: Protocols Enable Tampering Also

Matasano is featured in a preview of their Hacking Capitalism talk at Blackhat, which they say will describe various holes in FIX:

You'd think electronic financial trading would be extra secure, but not so much: One of the most popular application-layer protocols in the financial industry leaves these money applications wide open to attack, according to researchers.

The application-layer FIX (financial information exchange) protocol is used by financial services firms, stock exchanges, and investment banks for automated financial trading. But apps written to the protocol can be vulnerable to denial-of-service, session hijacking, and man-in-the middle attacks over the Internet, as well as an attacker actually able to "watch" the transactions, says David Goldsmith, CEO of Matasano Security, who will present the firm's new research on FIX at the upcoming Black Hat USA briefings later this month.

... "For the most part, when you look under the hood of these protocols, we find almost no means of security," he says. The FIX spec, for instance, barely touches on how to secure data as it travels over the Internet.

And most apps that use FIX are written in C and C++, he notes, "which is not always super well-audited code."

FIX has no session-layer encryption built into it, so it isn't easy to encrypt the sessions. "So most people encrypt using external devices like VPNs or tools like 'stunnel,'" Goldsmith says. Although the FIX protocol was updated in the past year to free FIX apps from that session layer, he says, most of these apps are still running the FIX session layer.

And many FIX-enabled financial apps don't even use passwords for their sessions, mainly because the apps were originally mostly built for use internally for a private connection between business partners -- rather than over the Internet, which is increasingly becoming the preferred method.

Plenty of financial firms may be at risk of these types of attacks. According to the FIX Protocol Website, 75 percent of buy-side and 80 percent of sell-side financial services firms use FIX for electronic trading, with both types of organizations planning to expand FIX, according to a survey taken by TowerGroup. The site says more than three fourths of all financial exchanges surveyed support FIX in their applications, and that most major stock exchanges and investment banks use FIX for their electronic trading. Mutual fund, money manager, and small investment firms also deploy FIX.

Unlike credit-card theft, which ultimately can be stopped before causing much financial damage, an attack on FIX could be silent and deadly: "If a hacker was monitoring or viewing [the transactions], you may never know they are there," Goldsmith says. "[He] could take that information and use it to their advantage for insider trading... or to cause significant financial damage."

So what should financial institutions do in the meantime to protect themselves from attackers that hone in on financial protocols? Goldsmith says start by taking a look at applications "you haven't looked at in a while... When was the last time you changed passwords on applications built on FIX?"

"Even doing basic due-diligence goes a long way," he says. "It's very easy to treat these as internal apps and to not consider all the security ramifications. But these apps need to be treated very seriously."

This is crazy, but not surprising. There are many messaging systems in wide use that either do not deliver any security services or punt this responsbility to other product lines that you need to buy for basic authentication and authorization. SOAP and WS-* took early steps to address message level security, beginning with WS-Security which describes how to attach security tokens to messages. Why you would want your program to try to make a decision without being able to vet the integrity of the payloat is a mystery to me, but most protocols don't do this or require that you stand on your head. Some Restafarians are starting to learn from WS-Security, which is good to see, because message level security is missing from most REST examples I have seen so far. (just so I don't start any flame wars, it is also missing from lots of SOAP implementations as well). The problem is that even with architectures like SOAP and REST it still seems to be hard to get basic message level support to enable authentication and authorization, these things are still far from bulletproof as implemented. As Brian Snow (former ADET NSA) says, "we break implementations not standards."

Comments

[Iang]

It's only crazy from an outsider's pov. From the security of financial systems pov it is quite logical, if uncomfortable.

It is pretty clear that the whole world of systems and security is a mess. Banks and other FIs have long known that it is practically impossible for them to secure all these systems.

Hence, all of the FI systems rely to a dominating extent on a closed system and high levels of trust. In such an environment, adding security to something like FIX is not only a distraction, it's probably dangerous and certainly costly.

Discussions about session layer security are just nuts; if there's one thing we've learnt from 2 decades of ISO nonsense, it is that it is that bolting on security layers to any application protocol is not satisfactory. To bolt on WS-Security and such add-ons would be to suggest that all security requirements are the same everywhere.