FortiGuard XOR Encryption in Multiple Fortinet Products

https://seclists.org/bugtraq/2019/Nov/38

by andromaton • 7 years ago

146 89 7 years ago

mkj2• 7 years ago

Does responsible disclosure really make sense for design flaws like this? Any motivated attacker would have already noticed it too you'd think.

steven_is_false• 7 years ago

I'm not sure "Responsible Disclosure" makes sense in any case.

kortilla• 7 years ago

It does if you’re ethical and care about potential fallout.

tfha• 7 years ago

Acting responsibly as a researcher who has discovered a vulnerability requires delicately balancing a question of two greater evils. Will more people get hurt overall if we announce the vulnerability sooner, or will more people get hurt overall if we wait until the vendor is ready?

In most cases, working with the vendor to allow a patch and a warning to be released is the path of least harm. But sometimes the right decision is to announce a vulnerability before the vendor has issued a patch.

yoloClin2• 7 years ago

Any motivated attacker would have already noticed it too you'd think.

Motivated is a keyword here. Opportunistic attacks occur, and probably make up for the majority of such attacks.

mkj2• 7 years ago

An attacker would be beyond opportunistic if they're already monitoring upstream traffic in this case?

tptacek7• 7 years ago

"Responsible disclosure" is an Orwellian term coined to coerce researchers into aligning their actions with the incentives of vendors. The better term is "coordinated disclosure", and coordination sometimes does make sense, and other times does not.

jcims• 7 years ago

Bug bounties are the real chilling force here, not the terminology used to describe a disclosure protocol. From what I recall before then there was a full spectrum of behavior, some would let the vendor steer the disclosure, some would set a timeline and stick to it, and some would hang the scalp as soon as they could.

I don't know that I personally ever witnessed any major fallout from the release of a zero day. Seemed like more of a speculative risk than anything. Plenty of shaming to go around though.

gwd8• 7 years ago

"Responsible disclosure" is an opinionated term, and there's nothing wrong with people using it if they think that what they're doing is actually responsible. In fact, one advantage of using it is that it should, in theory, make one thing about whether the coordination you're doing is responsible or not.

I was at first inclined to think that a year and a half was way too long to actually be considered "responsible". But if the outcome of that process was that FortiNet now has actual encryption in place (as one would hope since the advisory recommends people update their software, instead of recommending switching to a competing product), then I think there's an argument to be made that the effort put in will probably have been beneficial on the whole.

nathanaldensr• 7 years ago

If there were ever a reason to become cynical about grandiose marketing claims, this is it.

ben509• 7 years ago

Well, no one else is using that particular static key, so it is a "unique security fabric."

I do love the low key burn of putting that vendor description up front.

gamegod• 7 years ago

I wonder how much they paid to gag the researchers for the 17 months it took them to fix this.

vvanders• 7 years ago

Am I reading this correctly that they couldn't be arsed to do DTLS/TLS and so they rolled their own lame crypto?

userbinator3• 7 years ago

I suspect it was more that they never intended to use "true encryption" but just wanted to lightly obfuscate the data. Using strong crypto in a commercial product, especially one intended for international distribution, still brings up a bunch of legal issues that they may have been trying to sidestep:

https://en.wikipedia.org/wiki/Export_of_cryptography_from_th...

Having worked before (fortunately not for long) in an environment where trying to argue for "using the OS's crypto library is easy" would've been shot down with a strict "NO!" from management, I can definitely see how this situation occurred. That was a long time ago, but this may have been code left over from that era, and I'm not surprised if many more examples of such, along with people who are still in that mindset, still exist today.

I've seen similar things in all manner of other software (mostly DRM-related, so I won't say more...) --- it's not a hard wall, but a shield from casual observers and "keeping the honest people honest" type of idea.

linsomniac• 7 years ago

I'm not sure you can call XOR+static key "rolling your own crypto". :-/

userbinator3• 7 years ago

the static XOR key has been removed from this advisory

...because it's easy enough to determine from the plaintext and ciphertext?

terom• 7 years ago

  >>> cb = bytes.fromhex('6968766f606e776c2d2d21262138475c5b5a475b545e475c6b6a776b646e776c6b6a772b646e776c6b6a776b646e776c6b6a776bbadf04036b6a776c616a846f')
  >>> pb = b'\x02\x02\x01\x04\x04\x00\x00\x00FGVMEV0000000000\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00@\x00\x00\x00\x00\x00\x00...'
  >>> print(''.join(chr(c ^ k) for c, k in zip(cb, pb)))
 
 kjwkdnwlkjwkdnwlkjwkdnwlkjwkdnwlkjwkdnwlkjYEJ

EDIT: The repeating XOR key is pretty obvious. Just ignore the junk at the end from the `...` in the given plaintext.

Scoundreller• 7 years ago

Key looks more like they just bashed the home row with a few extensions of the longer fingers.

Thorrez• 7 years ago

Interesting, kjwkdnwl hasn't been seen before in Have I Been Pwned.

all_blue_chucks• 7 years ago

They can patch the bug but they can never take back all the data that was leaked over that encrypted-not-encrypted channel.

throwaway1492• 7 years ago

Up to a couple of years ago, Checkpoint had been shipping a 10 year old version of openssh. I always wondered if anyone figured that one out :D

lucb1e• 7 years ago

You could have posted that when you found out instead of wondering whether you're the only one seeing it?

anfilt• 7 years ago

Wow that's a pretty big blunder.

RantyDave• 7 years ago

A year!

rdslw• 7 years ago

This speaks about Fortinet: "2018-06 - 2019-11: Multiple conference calls, discussing technical details, agreeing on disclosure time"

Translation: half a year to communicate:

- you send it unecrypted

- yes we do.

GrayShade• 7 years ago

That's... a year and a half.

gwd8• 7 years ago

Given that the advisory advises you update rather than stop using them, hopefully a year and a half to actually implement some sort of actual encryption. And hopefully the reporters were paid for "discussing technical details", like, how to actually use an encryption library.

retSava2• 7 years ago

Well, posting over HTTPS (with the worst certificates removed) instead of HTTP, perhaps with certificate pinning, isn't that hard and goes a long way.

tuczi2• 7 years ago

Good point. As far as I know, a long time to fix isn't an exception but rather a standard in such cases. That hursts even more :(

danmg• 7 years ago

This is the problem with 'responsible disclosure.' Companies will just drag their feet indefinitely, like an undergrad who stalls and manages to talk the instructor into assigning them an incomplete instead of just failing them outright. Just flunk them and don't reward that behavior: full disclosure.

fulafel2• 7 years ago

Previously... https://duhkattack.com/

Though the main harm of VPNs IMO is that they lead to "the secure company-internal network" style thinking.

acqq2• 7 years ago

That was also very bad, but this now is even much more obviously worse.

The common is, both are by the same company NASDAQ: FTNT, with almost 2B revenue which, as stated officially, provides "top-rated network and content security, as well as secure access products that share intelligence and work together to form a cooperative fabric"

https://www.fortinet.com/corporate/about-us/about-us.html

api• 7 years ago

I've thought for a long time that this is a broader problem with the whole firewalls-and-NAT network security paradigm. It leads to a "soft underbelly problem" and a complacency that leads to insecure internal systems.

From what I've seen: God help most organizations if someone gets to the internal LAN!

The rule should be: If your thing can't run securely on the unfiltered Internet, it's broken. Any firewalling and such should be a defense-in-depth afterthought.

Of course this is kind of perfect world thinking. The reality is that quite a lot of software is either broken or insecure by design (e.g. databases that assume a secure LAN and don't even authenticate nodes) and so in practice we're quite far from this being practical for all but the most carefully managed deployments. Developers are also notoriously lazy about security while developing. I'm as guilty of this as the next dev sometimes.

fulafel2• 7 years ago

I think the latter part of this is too pessimistic - network segmentation works as long as it's fine grained. Put that kind of apps on their own isolated vlan/vpc/equivalent and put an authenticating ssl proxy or something as the gateway.

arminiusreturns• 7 years ago

I hate fortinet stuff. My number one reason being the binary blob vpn client for linux, that you can't even download without an account. (so not in repos, have fun deploying to many machines) Also the annoying but more benign fact that everything has "Forti" in front of it.

drybjed• 7 years ago

There's openfortivpn[1] in Debian Buster, which is an open source[2] VPN client, and doesn't start with 'forti'.

[1] https://packages.debian.org/buster/openfortivpn

[2] https://github.com/adrienverge/openfortivpn

tssva• 7 years ago

You can always package it yourself and place it in a repo private to your organization.

DaniloDias• 7 years ago

Is anyone that works with Fortinet surprised?

vectorEQ• 7 years ago

fortiXOR crypto suite

aitchnyu• 7 years ago

Tangential, but are Fortinet products annoying as well as dangerous? What should I tell a boss who is considering their devices in front of their ISP line?

rishabhd• 7 years ago

Show him this -

   1) Fortinet tries to explain weird SSH 'backdoor' discovered in firewalls - https://www.theregister.co.uk/2016/01/12/fortinet_bakdoor/

   2) Fortinet Finds More SSH Backdoors - https://www.bankinfosecurity.com/fortinet-finds-more-ssh-backdoors-a-8826

   3) Fortinet backdoored fortios or hackers did for monitoring since last 5 years - https://www.securitynewspaper.com/2019/08/29/fortinet-backdoored-fortios-or-hackers-did-for-monitoring-since-last-5-years/

gruez• 7 years ago

Please don't use blockquotes as they're unreadable on mobile.

1) Fortinet tries to explain weird SSH 'backdoor' discovered in firewalls - https://www.theregister.co.uk/2016/01/12/fortinet_bakdoor/
2) Fortinet Finds More SSH Backdoors - https://www.bankinfosecurity.com/fortinet-finds-more-ssh-bac...
3) Fortinet backdoored fortios or hackers did for monitoring since last 5 years - https://www.securitynewspaper.com/2019/08/29/fortinet-backdo...

chedabob• 7 years ago

We run one of their firewalls and it's pretty good, but between the security issues, and overhauling the licensing between 6.0 and 6.2 release, it's got me considering ditching it when we upgrade our network in the new year.

ericcholis• 7 years ago

Out of curiosity, what are you considering? I'm shopping as well.

zaroth2• 7 years ago

How does this not result in FortiNet customers suing, to say nothing of shareholders and the FTC?

To intentionally design an insecure obfuscation for customer confidential traffic, and then keep it in place for a year and a half after someone discovers and reports it, is obviously negligent and causes real damage to the companies who bought this defective product.

NedIsakoff• 7 years ago

That's why you pay your legal time extra money to write a good "Terms of Services".

zaroth2• 7 years ago

Deceptive business practices can't be over-ruled by Terms of Service.

precurse• 7 years ago

They won't even create a fix for their software after blatantly disabling TLS server validation in their FortiSIEM product: https://packetstormsecurity.com/files/154702/Fortinet-FortiS...

They use the "-k" curl flag throughout their code (disabling ALL certificate validation), since I assume is to make initial configuration easier. Rather than fix this going forward, they created a workaround document which all new and existing customers need to follow to secure their setup.

daef2• 7 years ago

The key doesn't even seem to be 'encrypted' itself, since it's found via strings:

Found the magic bytes here:

https://www.hybrid-analysis.com/sample/4dc1a98813bfa60b0139b...

(in the strings for 4dc1a98813bfa60b0139b54302cd2a8580bdd0cfea9b4adf1e6d27e1a0bbea33.bin , between 'Kindesmisbrauch' and 'Kunst und Kultur'

abarringer• 7 years ago

The patches are not available yet.

The 6.0 download hasn't been updated. It's still 6.0.6. https://www.forticlient.com/downloads

tuczi2• 7 years ago

A long time ago, I thought such things don't really happen but the more experience I have less surprised I am.

xvf22• 7 years ago

This is the company that shuffled a hard-coded password instead of fixing it. The developers got around the strings AP_image|grep "hardcoded password" "check" the managers were doing on the AP code by just moving it to the controller code instead.

They still have a hard-coded root password on their WLC controllers.

HocusLocus• 7 years ago

I think XOR encryption is the future and gratefully devour every YC article!

FortiGuard XOR Encryption in Multiple Fortinet Products

Related Stories