Yep. There are legitimate needs for the factory to have a backdoor, I assume Trango regularly bails out customers using that capability. But a cryptographic key that the factory can generate from the MAC address seems an ideal solution. Is there anything keeping Trango (and other vendors) from moving to this via a firmware upgrade?
No way to fix already deployed equipment without a firmware upgrade (or a time machine). And if you don’t upgrade firmware on critical infrastructure, well, to quote Pogo, we have met the enemy and he is us. From: Af [mailto:af-boun...@afmug.com] On Behalf Of Josh Reynolds Sent: Saturday, November 12, 2016 3:14 PM To: af@afmug.com Subject: Re: [AFMUG] Trango Security Issue +1 On Nov 12, 2016 1:37 PM, "Colin Stanners" <cstann...@gmail.com> wrote: Any security holes are perfectly secure until they are discovered. Having a backdoor into your products can be argued as good or bad, mostly depending on whether customers know or not. But the crux is that having a hard-coded password on devices is still monumentally stupid, when it's trivially easy to secure a backdoor in such cases (as long as the private key isn't stolen), e.g. the method of the password being a hash of the unit's MAC address run through public key cryptography.. that way customers need to contact tech support with the unit's MAC address to get the reset password. On Sat, Nov 12, 2016 at 1:17 PM, Chris Gustaf <ch...@trangosys.com <mailto:ch...@trangosys.com> > wrote: A couple clarifications on this- 1) All Trango microwave products have separate control and data planes, so root level access does not allow any packet sniffing. No user data goes through the CPU. 2) Trango investigated using a Salt to make each root level password unique, but opted against it since our support team frequently has been requested to access radios where the user level passwords were forgotten and reset to defaults. Without a known root password, a tower climb may be required to physically reset the radio to factory. 3) Trango opted instead to periodically change root passwords on firmware updates. The current method has worked well for 10 years with no breaches reported to us. In fact, Trango has passed PCI compliance testing with it's SL24 product using this method. That said, we would welcome a discussion on this since this type of tower mounted product differs from other network devices residing in a network closet. Regards, Chris Gustaf Trango Engineering Sent from my mobile On Nov 12, 2016, at 4:09 AM, Paul Stewart <p...@paulstewart.org <mailto:p...@paulstewart.org> > wrote: Yikes…. [+] Credits: Ian Ling [+] Website: iancaling.com <http://iancaling.com> [+] Source: http://blog.iancaling.com/post/153011925478/ Vendor: ================= www.trangosys.com <http://www.trangosys.com> Products: ====================== All models. Newer versions use a different password. Vulnerability Type: =================== Default Root Account CVE Reference: ============== N/A Vulnerability Details: ===================== Trango devices all have a built-in, hidden root account, with a default password that is the same across many devices and software revisions. This account is accessible via ssh and grants access to the underlying embedded unix OS on the device, allowing full control over it. Recent software updates for some models have changed this password, but have not removed this backdoor. See source above for details on how the password was found. The particular password I found is 9 characters, all lowercase, no numbers: "bakergiga" Their support team informed me that there is a different password on newer devices. The password I found works on the following devices: -Apex <= 2.1.1 (latest) -ApexLynx < 2.0 -ApexOrion < 2.0 -ApexPlus <= 3.2.0 (latest) -Giga <= 2.6.1 (latest) -GigaLynx < 2.0 -GigaOrion < 2.0 -GigaPlus <= 3.2.3 (latest) -GigaPro <= 1.4.1 (latest) -StrataLink < 3.0 -StrataPro - all versions? Impact: The remote attacker has full control over the device, including shell access. This can lead to packet sniffing and tampering, bricking the device, and use in botnets. Disclosure Timeline: =================================== Vendor Notification: October 7, 2016 Public Disclosure: November 10, 2016 Exploitation Technique: ======================= Remote Severity Level: ================ Critical
