--- see below --
(from our http://www.aredn.org/about-us page)
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
--- see below --
(from our http://www.aredn.org/about-us page)
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
By not following the path we have in place all you did was delay getting this investigated.
I get AREDN Security Team alerts on my cellphone, they pop up and alarm me that I need to look into an email. Forum posts do not do this.
There is a reason we publish these policies and a reason we run these the way we do.
If you want to contact the Security Team direct with your submission we can certainly provide updates to you on that channel. I've generated Security Concern Submission SCS-2016-005 for you.
No one on the team is going to claim obscurity makes the solution more secure, but we sure as heck want and need the direct channel to look into an issue before random posts start going everywhere in a thread like this taking away the teams resources on something that possibly isn't an issue (or worse yet, is an actual real issue that we have to pull team members away from creating a fix to answer questions, I'll answer questions left and right after I get a fix out)
I've had a number of CVE's and other reports come in over the years since I started working on the project, guess what, generally not even relevant to the nodes, if relevant generally required adding 3rd party software modules after the fact, or are.not exploitable based on how have the nodes designed,
Your choice on how you want to proceed. The security team will take it up and go with it and analyze and report on it, if you want an update strongly suggest going through the published method.
In this case, we are running various software components inherited from OpenWRT, linux, and many other sources. The release of 3.16.1.0 is using an OpenWRT release and components from July 2014 timeframe. It is aging and inherit that security flaws will be discovered over time. For those of you running BBHN firmware, we're talking 2003 era and the list of known security flaws *is* extensive. To make this tangible , we're talking about the web server, telnet, ssh, olsr, and more software components that need continual upgrades to stay ahead of the security game.
This is a legitimate question of AREDN plans to stay current to protect a mesh node when it is attached to the internet and exposed (or from laptops and usb drives that may propagate a virus or malware when connected to an off-the-grid mesh network). The current development branch is upgraded to the latest release of OpenWRT to stay current. Some or all of the identified issues are already fixed and in the pipeline.
This is a risk management problem and we'll review the specific known security holes identified and determine if we will do a point release of 3.16.1.0. Fixes will come in the next release in a natural progression regardless. Upgrading a software component in the firmware with a security flaw generally causes a beta testing process to occur. Unless it's a limited impact change to do a point 3.16.1.1 release, the likely path to stay "security current" is in the upcoming release process and testing process (a point release may not bring the updates any quicker).
If we posted the specifics to everyone in the community, then this also puts our community at greater risk from those with nefarious intent that also now know. Also, not in our best interest to have train wreck discussions that draw attention from a lot of onlookers.
Joe AE6XE
I'm also a bit surprised that security is that big of a concern in our community. It's very easy for anyone to join the mesh. Keep non-mesh resources off the mesh, firewall early and often when it comes to providing an internet gateway, and use additional host security (fail2ban comes to mind) when the host is on mesh.
As of right now we really can't control who is on as you mention. There are tasks each user can do to protect thesmelves and their computers, its generaly up to the AREDN team to make sure what it puts out is secure. May have a bad actor get on the mesh (virus infected laptop, or direct attack) so we should at least (in my mind) keep the infrastructure secure as we can.
Thought I'll admit, that is a bit of a self centered selfish reason behind that, I really don't want to have to go out and flash every mesh node again like recently happened with AirOS access points.
Here's an interesting discussion... We all may face at some point the prospect to interconnect our mesh network with an Entity's network, e.g. Red Cross, City EOC, a Hospital, University, Church, etc. Our mesh network is foreign to the IT dept managing their network and will raise questions on the risk to attach them together. The risks will not be understood on day 1, nor are we saying the risks are unmanageable. It will take time and a process to get everyone comfortable and a definition of what is acceptable or not.
We may get a 'business' level OK to put the mesh node on their network in some way to demonstrate an emcomm capability. After attaching these networks, the IT dept may have routine scans looking for vulnerable devices on the network with a process to get them patched. In this example, I'd speculate this is what happened. Now comes the interesting chess move with the IT stakeholders... Do you let them know there's an entire network behind this mesh node that they have little knowledge or control--start having that conversation? Do you simply checkbox and plug the security gap the IT scans found and say nothing further at this time?
KJ6DZB, how has your IT dept absorbed these issues? Are they fire-walling the traffic with the mesh node to control it? Have you yet to have this discussion? The superset issue is not a security vulnerability on one device, it's that the entire mesh network presents an unknown risk. The IT dept will be wondering if we are letting someone plug a virus infected laptop into the Mesh network and are giving unrestricted pathways into the Entity's network putting them at risk they aren't controlling. They like to keep their jobs :) .
Joe AE6XE
The last thing we want to do is to provide an attack vector from the mesh into someone's network, whether that be someone's home internet or a served agency.
IF some one hadn't deleted my post other could have read what i received from my ID department.
I received an automated message from our Campos security bot. It scans networks hosts on our campus network. I have a Bullet M2 with the current release of firmware running as a gateway. The Bot detected that the service running on XXXX was Not a current, and that it needs to be updated to patch flaws.
AE6XE, There is no great Firewall of china here. They have issued an alert to patch the system.
---------------
In the event of a compromise, state law requires that additional steps be
taken if this computer stores or provides access to data containing personal
information such as social security numbers, drivers license numbers, financial
account or credit card numbers, or medical/health information. If this is the
case, you must notify ISP immediately. To find out more about this requirement
and the campus procedures for implementation.
-----------------
I need to report back that the problem is corrected or a plan of action to fix the problem! I would think of this as a need for a 3.16.1.1 release, and time for the dev team to take a look bring packages up to date for 2017.
73
Hi Mathison,
I meant no harm in deleting your post, in fact, just the opposite. Our security protocol is in action now and are assessing any potential impacts/mitigation options.
Since possible security vulnerabilities can be sensitive until assessed and addressed, the proper process is EXTREMELY IMPORTANT to follow. Public forums are NEVER a good way to raise these types of issues, as hackers do monitor public forums for this type of information.
I can say that development work on XW and our next release has been stopped (per our security protocol) while we address this.
Thanks for the report.
Even if the device gets patched, it will be better for you to have more control of the connection between the campus network and the mesh.
Security Team.
A number of publicly disclosed vulnerabilities were brought to the team
regarding the dropbear/dropbearconvert (ssh server) packages installed
on a node. After researching the reported vulnerabilities it was
determined that none of the reported issues are exploitable in a
standard AREDN deployed 3.16.1.0 node. For any of the flaws to be
exploited would require unsupported modification of the hardened image
distributed by the AREDN Team.
The AREDN Security Team has produced replacement packages for dropbear
that can be installed from the Administration page of a mesh node. In
addition the updated packages are being made a part of the nightly
development code branch.
Technical details follow:
CVE-2106-7406:
SERVER:
AREDN Nodes do not support the creation of additional users on the
system which is a core requirement to exploit this flaw. There is
currently no method that we are aware of to exploit this without first
becoming root on the mesh node and and overwriting core operating system
files.
CLIENT:
while the binary code is present on a mesh node the software never
utilized by AREDN or any program installed on the mesh node and as such
is not exploitable in a default hardened installation.
CVE-2016-7407:
The dropbearconvert binary is not installed on mesh nodes by and would
require manual installation and utilization from an outside source. No
portion of the AREDN system utilizes this key conversion technology and
as such an AREDN node would not be vulnerable to attack.
CVE-2017-7408:
The dblicent binary is never utilized by AREDN or any program installed
in the hardened image state and as such is not exploitable without first
compromising the node.
CVE-2017-7409:
The version of dropbear on mesh nodes is not compiled with the
vulnerable DEBUG_TRACE feature. We currently have no plans to do so in
the future.