Thousands of Juniper Networks devices vulnerable to critical RCE bug More than 11,500 Juniper Networks devices are exposed to a new remote code execution (RCE) vulnerability, and infosec researchers are pressing admins to urgently apply the patches. It's somewhat of a repeat scenario for Juniper Networks, which only recently got done patching the last round of critical RCE bugs in Junos OS, …
The main issue with Huawei is how close it is to the Chinese state, so they can and would do as the CCP requests in the future. You might argue the same applies to other big names and their respective governments, but they are in more democratic countries so there are better checks & balances, not perfect, but a damn sight better that the CCP now allows. Open source solution instead?
The UK has analysed their code, etc, as part of Huawei's attempt to prove it was not spying and indeed the UK did not find any backdoors. But they did find piss-poor coding practices and difficulties in replicating build environments that would yield identical binaries, nothing nefarious, just piss-poor practice (e.g. not fixing version numbers of libraries and compilers per release version, etc). Maybe no backdoors, but plenty of loose windows and vents.
However, other big network companies like Juniper, Cisco, Fortinet, SonicWall, etc, have not had the formal scrutiny that Huawei has had so we don't know how good their code is, but on this sort of evidence it is the exactly the same piss-poor category.
There's the root of the problem, using stateless browser protocols in a security device.
Problem: “An Out-of-bounds Write vulnerability in J-Web of Juniper Networks Junos OS SRX Series and EX Series allows an unauthenticated, network-based attacker to cause a Denial of Service (DoS), or Remote Code Execution (RCE) and obtain root privileges on the device.”
“This issue is caused by use of an insecure function allowing an attacker to overwrite arbitrary memory”
Is it possible for these geniuses to design a MMU that don't trample all over adjacent processes.
Having a web interface is not the fundamental problem.
Having it public-facing is the first big problems, then having it coded by monkeys that seem to lack any basic ground-up design security is you next big problem.
The main advantage of SSH command line in terms of security is it depends on SSH to have done authentication properly before you get in. While those projects have had a fair share of bugs over the years, it is nothing compared to the web monkeys...
In the 2000's there was a "feature" in one prolific (around here) version of the Linksys firmware in consumer models (e.g. WRT 54GL) that was so bad that all you had to do was insert something in the URL to get access to the admin interface. Web UI monkeys indeed.
(I actually used that once to avoid resetting an ISP supplied router where the user didn't know his PPPoE credentials after hours. I just needed to get in and enable some port forwards)
There is a way to do that safely. You can install a custom CA in a virtual host, and demand that clients connecting to that present a certificate signed by that CA. That might actually be better than requiring users to remember a password.
Snooping enabled on Jupiter? Surely not!
Snooping enabled on Cisco kit?
Snooping enabled on Juniper kit?
Snooping enabled on Huawei kit?
Oh no.............it's those nasty Chinese folk who are the ONLY snoops!!!!!!
Wake up!! Smell the coffee!! EVERYTHING is being snooped in Cheltenham, Fort Meade, and Beijing!
Traceroute to your home ip address from work, and vice versa, then connect to those addresses (that are within your ISP) with firefox/chrome, and you should be able to tell if your ISP has made an attempt to harden their network. e.g. if you can connect and get a JWeb login, then they have not done so.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
