You are here

Vulnerability Detected

18 posts / 0 new
Last post
kj6dzb
kj6dzb's picture
Vulnerability Detected

--- see below --
(from our http://www.aredn.org/about-us page)

K5DLQ
K5DLQ's picture
The members of the AREDN™
The members of the AREDN™ team believe in the responsible disclosure of security vulnerabilities present in the software. To further the goal of responsible disclosure we request those persons who believe they may have discovered a security vulnerability please contact securityteam@aredn.org and work with us to ensure that the vulnerabilities are patched prior to public disclosure.
 
kj6dzb
kj6dzb's picture
 I came home and found this
 I came home and found this in my work email box I will spare the forum the first part of the email from the IT department, Im not thrilled to see this in my email box... Consider this notification the fix was detailed in the first post. I need to know if this is going to be addressed, or if I should shut down. 
AE6XE
AE6XE's picture
KJ6DZB,  It is an option to
KJ6DZB,  It is an option to turn off functionality exposed to your IT department.   There are more options than all or nothing to consider.  Take a look at the particular port in question and turn it off from access to your IT department.  This does not affect the core routing functionality of the mesh node or access from the mesh network side.
KG6JEI
Let me be blunt,
Let me be blunt,

​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.
kg9dw
kg9dw's picture
Can a moderator add some
Can a moderator add some context to this post? 
AE6XE
AE6XE's picture
As many of you know, the IT
As many of you know, the IT security world is a constant activity of keeping ahead in a cat and mouse game of find and fix cycles.  In the open source world we generally stay ahead of the game.  Many home wireless devices quickly fall behind and vendors don't patch them in lieu of spending effort to create the next big thing to generate more revenue.  

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
kg9dw
kg9dw's picture
Context
Thanks Joe, that was my reason for asking for context. Posts like this one create concern where it may not be warranted. When the team decides to do a point release, I'll take notice. :-)

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. 
KG6JEI
Part of your points are
Part of your points are exaclty why I always push a security focus.

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.
AE6XE
AE6XE's picture
Attaching a Mesh Network to
Attaching a Mesh Network to another Entity's network

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 

 
kg9dw
kg9dw's picture
NAT mode !
That's part of the reason why I used NAT mode when hooking a node to the local EOC (and by extension local government) network. But the next logical step would be for another firewall to be between the NAT'd node and the EOC network to prevent someone who may have taken over the EOC mesh node from getting into the EOC network. 

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. 
kj6dzb
kj6dzb's picture
IF some one hadn't deleted my

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  
 

K5DLQ
K5DLQ's picture
Hi Mathias,

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.
 

kj6dzb
kj6dzb's picture
My name is Mathison not
My name is Mathison not Mathias....

 
K5DLQ
K5DLQ's picture
apologies
apologies
kg9dw
kg9dw's picture
you've got options
I wouldn't wait for a patch. I would add a firewall between the device and the campus network. Go grab a Linksys router (less tha $20), double-NAT to the node, and only open the ports you want to expose to the campus. 

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.
KE6UPI
I read your post the other
I read your post the other day.. Great IT security they didn't say a thing about the telnet was wide open.
K5DLQ
K5DLQ's picture
The AREDN Team thanks Mr. Ott
The AREDN Team thanks Mr. Ott for bringing his concerns to the AREDN
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.

 

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer