Well said.
------ Original Message ------
From: "Simon Westlake" <[email protected]>
To: [email protected]
Sent: 11/14/2016 12:03:35 PM
Subject: Re: [AFMUG] Trango Security Issue
I wouldn't recommend panic anyway (unless your management
infrastructure is not properly secured, in which case, I would be
panicking about a lot more than a Trango backdoor.) As long as your
infrastructure is properly locked down and secured, most of these types
of issues are largely irrelevant in general, as the avenue of attack is
close to zero.
Most of my statements on this thread are philosophical. If someone said
to me, I'm designing a device, and I need a way to reset the password
if a user forgets it, would I recommend this approach? Definitely not.
If the question is (assuming all ISPs are properly securing their
infrastructure) - do I think this is going to be a massive security
risk? Probably not. But I think it is important to talk about proper
approaches, especially since Trango has posted in this thread looking
for feedback.
On 11/14/2016 10:58 AM, Adam Moffett wrote:
I can see both sides of this. Simon and Paul make correct and salient
arguments about having a back door, but like Ken I'm not panicking
about it.
------ Original Message ------
From: "Ken Hohhof" <[email protected]>
To: [email protected]
Sent: 11/14/2016 11:13:39 AM
Subject: Re: [AFMUG] Trango Security Issue
Just last week someone was dealing with a whole Mikrotik network from
a WISP they bought and the fired ex admin had changed all the
passwords. So it’s not just people too lazy to keep track of
passwords. There are all sorts of scenarios. I remember once I
couldn’t get into a Ubiquiti backhaul, after trying every typo I
could think of I finally figured out that I had changed the username
from ubnt to admon instead of admin. And we generally disable the
reset button due to problems with spontaneous false resets.
I remember actually remember leaving Trango radios at trango/trango
for quite awhile because I was so scared of mistyping the new
password and having to send a climber 200 feet up with a laptop.
(obviously you should change the password while the radios are still
on the ground)
From: Af [mailto:[email protected]] On Behalf Of Paul Stewart
Sent: Monday, November 14, 2016 9:58 AM
To:[email protected]
Subject: Re: [AFMUG] Trango Security Issue
Agree 110% …
It does suck re: having to climb a tower to reset a password but
would also think that folks might suddenly be inclined to keep better
track of passwords after having to do so a couple of times ;)
On Nov 14, 2016, at 10:52 AM, Simon Westlake <[email protected]>
wrote:
You may not be the only one to make that assumption, but I find it
hard to throw my hands up and say 'Oh well' to a hard coded, fixed
password root account that is publicly accessible on any kind of
device.
On 11/14/2016 9:44 AM, Ken Hohhof wrote:
I think in some cases this means climbing the tower with a laptop
and a serial cable though.
Am I the only one who assumes everything has one or more backdoors,
including my car? There’s the one the manufacturer knows about,
the one the NSA put there, the one the software engineer put there
and didn’t tell his boss about, the one the Chinese chip maker put
there, the one Fancy Bear put there …
From: Af [mailto:[email protected]] On Behalf Of Simon Westlake
Sent: Monday, November 14, 2016 9:11 AM
To: [email protected]
Subject: Re: [AFMUG] Trango Security Issue
There's no reason for it to be secret, either. If it exists purely
to assist customers who forgot their password, then there is no
reason to both disclose it, and offer the user the ability to turn
it off. As long as there is still a physical reset method, then any
fallout from forgetting a password ends up on the customer, if they
disabled the ability for it to be reset.
Let's just imagine right now that someone has already built a bot
that is going out, scanning for Trango radios, and modifying the
running code on them. You can argue that some fault lies with the
operator for not properly securing his/her network, but the root
cause of the problem is an insecure, root account, hard coded into
a radio, with a fixed password, that cannot be disabled.
On 11/13/2016 5:12 PM, Paul Stewart wrote:
True and now it’s been disclosed by a security researcher and this
blows up badly on the vendor in my opinion…. makes you wonder
what else they are doing in their software that they are not
telling you about - just an example and not suggesting there’s
more in this case
On Nov 13, 2016, at 5:51 PM, Ken Hohhof <[email protected]> wrote:
Well, it’s not a secret backdoor if you disclose it.
“You ever flashy thinged me?”
“No.”
“I ain’t playing with you, K, you ever flashy thinged me”?
“No.”
From: Af [mailto:[email protected]] On Behalf Of Paul Stewart
Sent: Sunday, November 13, 2016 3:56 PM
To: [email protected]
Subject: Re: [AFMUG] Trango Security Issue
Different people deploy them different ways … good or bad …
The biggest problem I have with this is when a vendor doesn’t
disclose this information and that a customer cannot choose to
remove this option if the vendor insists on putting it in place.
On Nov 13, 2016, at 4:35 PM, George Skorup <[email protected]>
wrote:
I don't exactly see the problem, especially with a PTP radio
that should only be accessible from within your network and
possibly only from management subnets/VLANs, too. If it's a
public facing piece of equipment like a router, then sure, I
agree.
On 11/13/2016 3:07 PM, Paul Stewart wrote:
Totally disagree with this… we would never let a vendor into
our network if there was a possibility of this. It puts our
network at risk from their stupidity ….
We aggressively look at this when new products are coming into
the network - realizing that sometimes there’s no way to detect
it but it’s a question we ask, tests that we run, and hope that
our confidence in this being possible is low.
On Nov 13, 2016, at 11:59 AM, Ken Hohhof <[email protected]>
wrote:
Yep. There are legitimate needs for the factory to have a
backdoor
--
Simon Westlake
Skype: Simon_Sonar
Email: [email protected]
Phone: (702) 447-1247
---------------------------
Sonar Software Inc
The future of ISP billing and OSS
https://sonar.software
--
Simon Westlake
Skype: Simon_Sonar
Email: [email protected]
Phone: (702) 447-1247
---------------------------
Sonar Software Inc
The future of ISP billing and OSS
https://sonar.software
-- Simon Westlake Skype: Simon_Sonar Email: [email protected] Phone:
(702) 447-1247 --------------------------- Sonar Software Inc The
future of ISP billing and OSS https://sonar.software
