16 ms·
SSH Backdoor found in Fortinet firewalls
- exo762 11y agoHugged to death. Archive link: https://archive.is/WU8l3 https://archive.is/WU8l3
- zymhan 11y agoCan someone provide some context? A python script alone is kind of hard to decipher.
- 001spartan 11y agoThere is a hard coded SSH password, 'FGTAbc11*xy+Qqz27', in Fortigate devices < v5.0.7. You can use this script to access any device before that version. EDIT: 5.0.7, not 5.0.2
- zokier 11y agoIt's bit more complex than that; it uses challenge-response system, the "FGTA..." string is used as a "key"
- 001spartan 11y agoCorrect, you can't use the password alone, but the challenge/response method used is readily available online, and easy to implement.
- stcredzero 11y agoApparently, some people who make firewalls believe in security by obscurity. (They could at least have used an RSA key to verify. Though that would still have been bad.)
- mistaken 11y agoI've worked at a large telco testing CPE devices (routers and whatnot) and it was common place to find backdoors like this. The devices were made by a third party vendor and most of them had hardcoded passwords and hidden debug features.
- coldpie 11y agoJust reading the code, it looks like it connects to an SSH session with the name Fortimanager_Access and does some special handling of the password request (see custom_handler) which grants access. Once that's complete, it turns control over to you to type and run commands on the firewall. I don't quite understand the special handling. Looks like it takes a byte from the server's output, hashes a special string containing that byte, and passes that back to the server. This is the backdoor. Edit: Maybe that "special handling" is just standard protocol and it's just sending a plaintext password. I dunno.
- 001spartan 11y agoIt uses a kind of challenge/response, where the device provides a salt that is used with a hardcoded password for that account. It seems to look like 'AK1' + base64(salt|SHA1(salt|password|Fortinet magic)) according to http://fossies.org/linux/john/src/FGT_fmt_plug.c http://fossies.org/linux/john/src/FGT_fmt_plug.c, a cracker for Fortigate passwords.
- EvanAnderson 11y agoIt's a custom SSH authentication method invoked with a special username, "Fortimanager_Access". The protocol is a weak "challenge/response" using hash of the challenge concatenated with a string (used in multiple firmware versions and not at all unique to the device).
- deleted 11y ago[deleted]
- sschueller 11y agoNice, who's next? Maybe it is time we build open hardware and software for important things. Can't trust anyone. Doing audits of open hard and software is a whole other problem however.
- ausjke 11y agothat's a shame but we're used to it these days I guess. if you want to do backdoor probably should do it better, something like port knocking to start with at least.
- stcredzero 11y agoif you want to do backdoor probably should do it better, something like port knocking to start with at least. Come to think of it, backdoors are fundamentally "security by obscurity". Or insecurity through obscurity, depending on your POV.
- roywiggins 11y agoKnowing the Juniper Dual_EC_DRBG constants were fiddled with doesn't help you actually snoop, since working backwards to the generating constant is computationally unfeasible. Similarly hardcoding someone's SSH public key isn't going to help anyone else gain access just by knowing it's there, is it?
- Someone1234 11y ago> Come to think of it, backdoors are fundamentally "security by obscurity". Or insecurity through obscurity, depending on your POV. This one is. But they aren't always. For example, if a manufacturer put in a support/recovery backdoor, documented it, and utilised a secret that only the end user and manufacturer should know (e.g. something on the physical label), then that would be a backdoor while not relying on any obscurity for its security (or no more than a password does). The biggest difference between a "good" backdoor and a "bad" one is if it is documented. If the manufacturer is too scared to document it then it likely sucks and they know it.
- matt_wulfeck 11y agoAlso if you look at the complexity of the code, you'll know something like port-knocking would have had no affect (probably just an extra line in the custom handler). People that discover these these types of exploits each machine code for breakfast.
- Daviey 11y agoI almost had a reallllllly.. bad day. Thankfully, it is only version 4.x up to 5.0.7.
- Cuuugi 11y agoMe too, 5.2 phew
- arca_vorago 11y agoAnother one bites the dust. I'm ready for more though, because it is vindicating my position on FOSS. While FOSS isn't a panacea, at least you can read the code!
- 0x0 11y agoLike heartbleed, gotofail, or the debian ssl entropy bug? :)
- daveloyall 11y agoNot at all. Those were bugs. This is/was a feature. For this, there'd have to be a specific function in some Fortinet products for handling the special challenge/response backdoor. A magic string like `"FGTAbc11*xy+Qqz27"` in firewall source code is going to jump out at you. Unlike an extra goto...
- 0x0 11y agoHow do you know those were bugs and not features? ;)
- deleted 11y ago[deleted]
- jodrellblank 11y agoYou can. Do you? When's the last time you read the IPTables code? OpenSSH? The console login prompt? The Grub2 bootloader login prompt? NSSwitch? Krb5? Do you mean "hopefully someone else will"? Because that's what I mean.
- tptacek 11y agoThis probably isn't as bad as Juniper's, because you don't generally get external SSH access to a Fortinet box.
- sarciszewski 11y agoIt's still good to hear that these backdoors are being discovered (and hopefully expunged).
- venomsnake 11y agoI think the main problem is the companies attitude towards the security of their problems. What else is in there? Credibility is in a way binary - you either have it or don't.
- ecnepsnai 11y agoI fail to see how Fortinet had a bad attitude towards this issue. It was found, and fixed, 18 months ago before any of this information was released publicly.
- venomsnake 11y agoThe existence of the issue in the first place.
- dogma1138 11y agoYou don't get external SSH access to Juniper FW's either its either from the local LAN or more commonly through a separate management network/vlan.
- rgbrenner 11y agothey're equal on that part.. but the ssh backdoor was only one part of that announcement. The second part was a backdoor in the VPN (via Dual_EC_DRBG), that permits a passive eavesdropper to decrypt the connection: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7756 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7756 https://www.schneier.com/blog/archives/2015/12/back_door_in_ju.html https://www.schneier.com/blog/archives/2015/12/back_door_in_...
- jorge-fundido 11y agoMaybe backdoor was a bad way to describe it? Maybe it's used as a customer-initiated support channel for when the customer wants the vendor to access the device.
- 001spartan 11y agoThat may be, but it's still a backdoor by definition. There are better ways to allow a vendor to access a device, and a hardcoded password that nobody else knows about is not exactly a "front door".
- EthanHeilman 11y agoSupport channel has to be the best euphemism for a backdoor I've yet heard. USG probably would have had better luck if they pitched backdoors as a consumers protection measure and had a law mandating that: 1. Software companies must always have a remote and practical method to correct dangerous flaws in the software they issue. 2. To protect consumers' valuable records, all device manufacturers must back up all data on any device the produce. Such backups should ensure that the data is always accessible by the user even if the user were to lose their password or keys. It would be a security disaster, and it already is.
- myth_buster 11y agoPlease don't give away ideas. You be surprised how well these things would resonate with layperson.
- eeZi 11y agoFortinet support just uses TeamViewer or Webex when they need access to a device, or you create an account for them. Source: Fortinet admin
- Smushman 11y agoYes - if it isn't obvious (which is should be to anyone here) this was probably used as an beta method for a control/communication channel protocol, Probably inter device only (not meant for a user or support). Built by a programmer who was told to 'get the communication working for this new feature we want to implement'. So he hacked open a hole with a very large cudgel where he should have used a scalpel.
- eeZi 11y agoSee relevant thread in r/netsec: https://www.reddit.com/r/netsec/comments/40lotk/ssh_backdoor_for_fortigate_os_version_4x_up_to/ https://www.reddit.com/r/netsec/comments/40lotk/ssh_backdoor... > It leaves no traces in any logs (wtf?). It keeps working even if you disable "FMG-Access". It won't let you define an admin user with the same name to mitigate it, so make sure that SSH access on your devices is at least restricted to trusted hosts!
- BlackFly 11y agoThe interesting thing from that thread is that it appears it has been patched years ago. Then again, maybe they only changed the "password" in the newer versions.
- nickpsecurity 11y agoThis is why high-assurance security products were/are required to have: 1. Clear description of every feature and requirement in system. 2. Mathematical spec of those where English ambiguity could effect results. 3. High level design with components that map 1-to-1 to those. 4. Low-level, simple, modular code mapping to that. 5. Source-to-object code verification or ability to generate from source on-site. What people in faux security mocked as mere "paperwork" or "red tape" were actually pre-requisites for defeating subversion my mentally understanding a system from requirements all the way to code. A problem like this would've been impossible in such a system because it would be beyond obvious and probably unjustifiable with requirements tracing. Every story like this further validates the methods that consistently produced systems without all the security problems plaguing modern security products. Situation isnt inevitable or even necessary: merely an inversion of scientific method where security companies and professionals consistently refuse to use what's proven to help and reuse tactics proven to fail. It's gotta stop. That it wont is why I favor liability legislation tied to a reasonable baseline of practices. We can use an inexpensive subset of what worked in highly assured systems. 80/20 rule. Baseline would look more like Secure64 or HYDRA firewall than shit like Fortinet and Juniper. Hackers would work for exploits. I know Im dreaming, though, as DOD and NSA just dropped mandate to EAL1 w/ 90 day review for some stuff. (Rolls eyes).
- matt_wulfeck 11y agoYour assurances are good but the software simply _must_ be open source with a reproducible build. We're kidding ourselves to put our faith into these closed-source products and that's only just now becoming clear. Open source. It's the only thing that will work for us long term.
- nickpsecurity 11y agoDid you read my comment at all before replying? One step is the source, one step implies reproducible build, and alternately specifies a stronger requirememt (source-to-object verification). And no, OSS with reproducible builds is nowhere near enough for software to be trustworthy. It's why even Orange Book had more than one sentence in its feature and assurance activities recommendations. Let's put it to the test though. If Im right, most the majority of OSS software will be similarly to proprietary full of easily-prevented holes, undocumented/barely-clear functionality, and difficulty even building it. Whereas high assurance systems would've had the opposite attributes while faring well during professional pentesting w/ source. One of us was right for a decade straight. Maybe it's because the principles and practices I promoted... work? Evidence in the field is on my side. Neither OSS nor good builds are enough.
- matt_wulfeck 11y agoOpen hardware and open source. It's our only path. In my opinion the best way for this to happen is to make it part of the government procurement process, that will inject cash into the ecosystem. I really believe this has already begun with the FANG[0] tech giants with Open Hardware initiatives. At some point you can begin pooling your resources to create safe, secure, and fast platforms that everyone can use. [0] facebook, amazon, netflix, google
- godzillabrennus 11y agoThis is why http://Pfsense.com http://Pfsense.com should get even more coverage on here than it does. Chris and his team do an incredible job of creating secure open firewall software.
- mulander 11y agoWho does the great job again? https://www.reddit.com/r/BSD/comments/391nyj/pfsense_considered_harmful_to_the_community/ https://www.reddit.com/r/BSD/comments/391nyj/pfsense_conside...
- bashtoni 11y agoAlso OpenWRT: https://openwrt.org/ https://openwrt.org/
- xcasex 11y agonot as long as everything runs privileged as the superuser. running all services as root by default is bad juju.
- wtallis 11y agoThat's certainly true of servers, but it's way less important for the limited set of services a router typically provides. Aside from the services that really need root because they're changing system settings, you've pretty much got just dnsmasq and hostapd out of the box. Isolating them is nice if you've got the storage space for that extra complexity, but it's not like OpenWRT is a massive attack surface with gaping holes.
- INTPenis 11y agoThese backdoors in the news lately - Juniper and now Fortigate - are scary, but thinking back on 10 years in IT I've never operated in a network where SSH on network equipment was accessible to anyone without intranet access through either physical location or VPN. On top of that I am now in an organization where we're starting to implement security levels on networks, anything above level 0 requires 2FA to access and you can never connect a lower level to a higher level. So best practices are a good thing.
- lfx 11y agoWhat are you using for 2FA?
- INTPenis 11y agoIronically enough Juniper Junos. :)
- Animats 11y ago"I've never operated in a network where SSH on network equipment was accessible to anyone without intranet access through either physical location or VPN." Doesn't help. The attacker just has to get user-level access on some machine on the intranet or in the data center, which can be obtained via other attacks. Then then can attack other machines via the local network to escalate.
- INTPenis 11y agoYes but best practices still apply for example client networks in office do not by default have access to network equipment. This is where VPN services like Junos (ironically Juniper) work well because they give you 2FA and group based access. So if you're not in the networking admins group then you have no reason to have SSH access to the networking equipment.
- Animats 11y agoThe weakest application in your server farm can provide a way into the local network. One of the reasons Amazon uses their own software-defined network switches is so they can limit internal connectivity within their "cloud" to prevent such attack escalation.
- perna_m 11y agoofficial statement from Fortinet http://ftnt.net/1TTc1Bz http://ftnt.net/1TTc1Bz
- HNaTTY 11y agoThis script worked for me once I enabled SSH on the lan interface on my FortiGate 100D running 5.0. But the only command that seemed to do anything is "exit". Everything else gave an "Unknown Action 0".
- deleted 11y ago[deleted]
- hoodoof 11y agoBut think of the upside - so many terrorists were probably caught because this code existed. We must fight to ensure all firewalls have back doors or face a true terrorism threat.