
FortiGuard XOR Encryption in Multiple Fortinet Products - andromaton
https://seclists.org/bugtraq/2019/Nov/38
======
rdslw
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.

~~~
gwd
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.

~~~
retSava
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.

~~~
tialaramex
This "XOR encryption" is vulnerable to an eavesdropper with almost no
technical capability.

Even just HTTPS with no checks whatsoever (think 1990s Perl scripts or Python
Requests with all the checking explicitly switched off) is protected against
eavesdroppers, so that would require an active attacker (or a large quantum
computer) to defeat, far more sophisticated than this trivial nonsense.

~~~
retSava
Yeah exactly, that's my point - going from "oh shit" to "I feel fairly
comfortable" in this case shouldn't take 1.5 years.

------
fulafel
Previously... [https://duhkattack.com/](https://duhkattack.com/)

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

~~~
api
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.

~~~
fulafel
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.

------
userbinator
_the static XOR key has been removed from this advisory_

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

~~~
terom

      >>> 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
Key looks more like they just bashed the home row with a few extensions of the
longer fingers.

~~~
segfaultbuserr
Apparently, running "uuidgen" is too difficult for them. Which, shouldn't be a
surprise for someone who already decided to use XOR "encryption".

~~~
zamalek
XOR encryption is unbreakable with an one-time pad that matches the message
length (that's basically AES CTR). It's one of the most secure cryptography
primitives we have.

The problem is deciding to use home-grown encryption.

~~~
loeg
This isn't a one-time pad. It's reused for every message.

~~~
daef
It's reused every 8 bytes...

~~~
loeg
That too.

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

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

~~~
userbinator
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...](https://en.wikipedia.org/wiki/Export_of_cryptography_from_the_United_States#Current_status)

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.

~~~
acqq
> 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:

But apparently they sell VPN software. That's their product. The obscured by
not encrypted output is the information from the inside of the VPN, and more.

They could not avoid solving legal issues anyway when selling VPN.

They completely deserve a "doghouse" tag on Schneier's blog:

"A decade ago, the Doghouse was a regular feature in both my email newsletter
Crypto-Gram and my blog. In it, I would call out particularly egregious -- and
amusing -- examples of cryptographic "snake oil."

I dropped it both because it stopped being fun and because almost everyone
converged on standard cryptographic libraries, which meant standard non-snake-
oil cryptography. But every so often, a new company comes along that is so
ridiculous, so nonsensical, so bizarre, that there is nothing to do but call
it out."

FortiGuard qualified IMHO. A big seller of VPN software to companies (2B
revenue!) who is deliberately faking encryption.

------
zaroth
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
That's why you pay your legal time extra money to write a good "Terms of
Services".

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

------
daef
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...](https://www.hybrid-
analysis.com/sample/4dc1a98813bfa60b0139b54302cd2a8580bdd0cfea9b4adf1e6d27e1a0bbea33?environmentId=120)

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

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

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

~~~
tptacek
"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.

~~~
gwd
"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.

~~~
tptacek
The term was literally coined by a group of vendors, and uses the word
"responsible" so as to launder their commercial preferences into a universal
norm. It worked so seamlessly that people casually use the brand without even
thinking about where it came from or what it implies; it's like the word
"kleenex" but with malign moral freight. It's the purest example of
Orwellianism I can think of in our field; a direct weaponization of language
itself.

On the other hand it's 5 in the morning and I've been awake for 4 minutes so
it's possible that when I'm fully conscious I'll feel differently.

~~~
gwd
> It's the purest example of Orwellianism I can think of in our field; a
> direct weaponization of language itself.

It doesn't seem to me any different than "pro-life" or "pro-choice"; or
"Catholic" (which means "universal") or "Orthodox" (meaning "right-
believing"), or "progressive".

I know people that won't use "Catholic", but instead will say "Roman" or
"Papist" (since that organization is objectively based in Rome, and does
follow the Pope); and people who won't use "pro-life", but always say "anti-
abortion" or "anti-choice", or who won't use "pro-choice" but use "anti-
abortion" instead. I understand where they're coming from and respect their
preferences. I myself tend so put "progressive" in quotes, because I don't
consider all causes "progressives" pursue to be making progress.

But such people normally don't go around injecting themselves into other
conversations and complaining about the terms people do use. Rather, they
simply engage in the conversation and use their preferred term.

I use the word "responsible disclosure" because I think we should be
responsible about both how we disclose things and how I keep things secret.
Both disclosing immediately, and sitting on an issue for years, are
irresponsible in my view. Ideally issues would be reported, fixed, pre-
disclosed, and disclosed within a few weeks. Having things _fixed_ in that
time frame is not always possible, particularly when you're dealing with a
company that is so utterly clueless as the one described here. Given that,
whether it's more responsible to zero-day everyone or to sit on it for a year
isn't very obvious, and reasonable people can come to different conclusions.

~~~
tptacek
It turns out I still feel the same way as I did when I woke up at 5AM. I mean,
I went back to sleep. But I've been up for a little while now, and I'm pretty
sure I'm right, and "responsible disclosure" is way more Orwellian than "pro-
life"; there's at least a colorable argument that "pro-life" is descriptive of
a policy position, whereas there's nothing "responsible" at all about
independent researchers disclosing information to the public only on a
vendor's schedule and terms.

~~~
gwd
> there's nothing "responsible" at all about independent researchers
> disclosing information to the public only on a vendor's schedule and terms.

Right, so the reason we disagree is that we have different understandings of
what "responsible disclosure" means. From Wikipedia:

> In computer security or elsewhere, responsible disclosure is a vulnerability
> disclosure model in which a vulnerability or an issue is disclosed only
> after a period of time that allows for the vulnerability or issue to be
> patched or mended. This period distinguishes the model from full disclosure.
> [1]

And full disclosure:

> Full disclosure is the practice of publishing analysis of software
> vulnerabilities as early as possible, making the data accessible to everyone
> without restriction.

Nowhere does it say that this is done "on a vendor's schedule and terms". On
the contrary, unless there is some other agreement in place, the discoverer
_can_ publish any time they like; and so in reality control of the schedule is
_always_ at the discoverer's terms.

This is recognized in the XenProject's Security Response Process [2]:

> When a discoverer reports a problem to us and requests longer delays than we
> would consider ideal, we will honour such a request if reasonable. If a
> discoverer wants an accelerated disclosure compared to what we would prefer,
> we naturally do not have the power to insist that a discoverer waits for us
> to be ready and will honour the date specified by the discoverer.

Google Project Zero typically report a vulnerability and say, "We're telling
everyone about this in 90 days, hope you're ready."

 _That_ is my expectation of "Responsible disclosure". If SEC Consult waited
18 months, it's either because 1) they had a contract with Fortinet of some
sort, or 2) they were convinced that waiting 18 months would cause less harm
to people than zero-daying everyone.

[1]
[https://en.wikipedia.org/wiki/Responsible_disclosure](https://en.wikipedia.org/wiki/Responsible_disclosure)

[2] [https://xenproject.org/developers/security-
policy/](https://xenproject.org/developers/security-policy/)

~~~
tptacek
As I said at the top of the thread: it often makes sense to coordinate with
vendors, and natural preferences often do align. But it sometimes doesn't,
and, at times, it even makes sense to disclose without any coordination. Un-
coordinated disclosure isn't intrinsically irresponsible, and so the term
"responsible disclosure" is misleading. This isn't just my idea, and the term
itself has become disfavored among vulnerability researchers.

~~~
gwd
> Un-coordinated disclosure isn't intrinsically irresponsible,

I agree with this.

> and so the term "responsible disclosure" is misleading.

I think this is a key point. As I said, I think "responsible" implies being
responsible on _both_ sides: _neither_ simply publishing without sufficient
time for a vendor to make a fix, _nor_ waiting indefinitely while the vendor
waffles around or tries to pretend the vulnerability doesn't exist.
"Responsible disclosure" focuses (or ought to focus) on minimizing harm to
users, whereas "coordinated disclosure" focuses on cooperating with the
vendor. As such, "Responsible disclosure" in fact carries within itself the
threat of going public if the vendor is dragging their feet, where
"coordinated disclosure" doesn't.

I continue to think that we should use the term "responsible disclosure", and
insist that it mean _actually behaving responsibly to users_.

[Minor edits]

~~~
tptacek
I understand what you're trying to say. You're saying that conceptually there
is such a thing as being "responsible" or "irresponsible" about disclosure,
and I think that's true!

The problem is that ( _charitably_ ) the term of art (or _uncharitably_ ,
brand) "responsible disclosure" is attached to some very specific norms,
including "not releasing vulnerabilities without a patch" and "giving vendors
a commercially reasonable amount of time to create a patch" and "working
closely with vendors to coordinate that time window" and "redacting or
carefully reducing POC code", which are not themselves universal or even
generally "responsible".

They're _commercially_ responsible, to be sure! But it should not be an
obligation of unpaid third party researchers to expend any effort whatsoever
to be responsive to a vendor's commercial concerns. It's a nice thing to do,
and some people are just preternaturally nice to vendors, and that's usually
fine, but there's nothing deontologically "responsible" about that.

~~~
gwd
> You're saying that conceptually there is such a thing as being "responsible"
> or "irresponsible" about disclosure, and I think that's true!

I'm saying more than that.

We both seem to agree that there is an ongoing war about disclosure; and that
large vendors (through a mix of good, neutral, and bad intentions) are warring
to make disclosure more convenient and less painful for themselves, to the
detriment of their users (and ultimately themselves as well); and that the use
of words is one arena in which that warfare exhibits itself.

But we've come to opposite conclusions about the best way to fight the war in
this specific arena.

You've observed that companies are trying to define "responsible" to mean
"commercially responsible". But rather than recognizing _this attempt at
redefinition_ as an attack, and insisting on using the word "responsible" to
actually mean responsible towards users, you seem to think that _the use of
the word itself_ is an attack; and want to instead try to insist on using a
different term, "coordinated disclosure".

I think that's a bad strategy. You're advocating that we surrender the word
"responsible" entirely to large vendors. Large vendors are not going to stop
using the word "responsible"; if right-minded security researchers simply
abandon the word, then the broader public are going to be entirely at the
mercy of vendors to decide what's "responsible". Furthermore, as I've argued,
using "coordinated" shifts all focus to the vendor, removing any focus from
the user at all.

In the war over disclosure, your strategy seems to me to hand a massive win to
big vendors.

I think a much better strategy is to counter-attack. The word "responsible" is
too valuable a term to just give up. We must continue to insist that
"responsible" means "responsible to users"; and we must continue to insist
that there are times when pressuring and even embarrassing large companies _is
the most responsible thing to do_.

~~~
tptacek
There's nothing I can say to this that I haven't already said. "responsible
disclosure" is a term of art. It means something you don't mean. You can
redefine it for yourself, but people reading you will take its actual meaning,
not yours.

------
abarringer
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](https://www.forticlient.com/downloads)

------
aitchnyu
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
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
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/](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...](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-
> backdo...](https://www.securitynewspaper.com/2019/08/29/fortinet-backdoored-
> fortios-or-hackers-did-for-monitoring-since-last-5-years/)

------
xvf22
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.

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

~~~
ben509
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.

------
throwaway1492
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
You could have posted that when you found out instead of wondering whether
you're the only one seeing it?

------
arminiusreturns
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
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](https://packages.debian.org/buster/openfortivpn)

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

------
DaniloDias
Is anyone that works with Fortinet surprised?

------
anfilt
Wow that's a pretty big blunder.

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

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

------
vectorEQ
fortiXOR crypto suite

------
RantyDave
A _year_!

