Ubiquiti called out for security flaw
Credit to Author: Michael Horowitz| Date: Sun, 19 Mar 2017 18:48:00 -0700
When it comes to evaluating networking devices (routers, Access Points, switches), almost everyone focuses on the hardware. Not me. My RouterSecurity.org site is devoted to software.
But, there is yet another crucial aspect to evaluating devices – the personality of the company behind it. Specifically, how it reacts to the inevitable software flaws.
At the end of 2016 assorted bugs in Netgear routers were made far worse by the company’s slow reaction. Now, Netgear has a whole new procedure for dealing with bug reports. Time will tell how well it works.
This week, the focus is on Ubiquiti Networks. Over at SmallNetBuilder.com, Tim Higgins just reviewed their latest access points and started off the review pointing out how popular Ubiquiti access points are with the Ars Technica crowd.
But, a Vienna, Austria-based security firm, SEC Consult, which has reported router flaws in the past, just reported a bug in 4 Ubiquiti devices. They believe the bug also exists in another 38 devices.
The flaw, in pingtest_action.cgi, allows authenticated users to inject arbitrary commands into the web interface. It’s not a brutally critical thing.
The most interesting aspect of the Security Advisory, to me, was the “Vendor contact timeline.” Below is an incomplete and edited copy of it.
VENDOR CONTACT TIMELINE
Nov 22, 2016: Initial bug report
Nov 22, 2016: Ubiquiti considers the bug a duplicate of bug #143447
Nov 25, 2016: Ubiquiti says that bug #143447 should be fixed in the next firmware release
Jan 10, 2017: SEC Consult asks for a patch. No answer.
Jan 17, 2017: SEC Consult asks for an update. Ubiquiti says the Proof of Concept hack does not work.
Jan 18, 2017: SEC Consult explains their Proof of Concept again
Jan 19, 2017: Ubiquiti says they received a similar report and assumed a duplication. They tell SEC Consult that the Proof of Concept never worked and did not make any sense.
Jan 20, 2017: SEC Consult uploads a video showing command injection on an up-to-date device
Jan 21, 2017: Ubiquiti responds that they were able to reproduce the problem. They also posted the real cause.
Jan 24, 2017: SEC Consult asks whether the vulnerability is a duplicate of #143447
Jan 24, 2017: Ubiquiti says it is not and that this issue will be fixed as soon as possible.
Feb 3, 2017: SEC Consult asks for a status update. No answer.
Feb 21, 2017: SEC Consult asks for a status update. No answer.
March 1, 2017: SEC Consult tells Ubiquiti that they will go public with the flaw in two weeks. No answer.
March 16, 2017: SEC Consult goes public
Four months, no bug fix.
Back in November, Lucian Constantin of IDG, the same reporter who just wrote about the Ubiquiti flaw, had a story in PC World about a flaw in a router from my favorite router vendor, Peplink.
The two cases could not be more different.
Constantin reported that the person who reported the flaw “was impressed with how Peplink responded to his report and how the company handled the vulnerability.” A Motherboard article said basically the same thing and added that Peplink gave the person who reported the flaw a free router as a gesture of good will.
No one expects software to be perfect. I have run into a couple software problems with the Peplink routers I maintain. But reporting the problems was easy and the assistance from tech support was all that anyone could hope for.
That’s what you want in a vendor.
Personally, I use and recommend the Pepwave Surf SOHO. It’s the cheapest router Peplink offers. How fast is the Wi-Fi? I haven’t tested it. What’s the Wi-Fi range? I don’t care. Can it handle a 200 Mbps connection to the Internet? No. Is it dual-band? Mine is not (new ones are). Can the USB port be used for file sharing? No. How secure is it? Much more than your router.
– – – – –
Now that Computerworld, and all of parent company IDG’s websites, have eliminated user comments, you can get in touch with me privately by email at my full name at Gmail. Public comments can be directed to me on twitter at @defensivecomput