Comes down to design, You shouldn't be designing it in such a way you aren't using A VPN over the internet, A vlan internally or your own security lan.
Claimed Security Vulnerability in Axis, Aimetis and Milestone VMSes
Published Nov 09, 2015 05:00 AM
A Swedish research firm has claimed to discover a 'critical vulnerability' in major VMS software platforms including Axis (ACS), Aimetis and Milestone.
*** ****, ***** ********, ****** * notice [**** ** ****** *********], ********* to **** *** ******** ** ********** color.
*** ******* ** *** ***** **** connect ** ******* ** *****, ***** we ******* ** **** ************ ****. VMSes **** ** *** *** ***** would ** ******* ** **** **** regardless.
**** ***** *******, * ***** ************ user ***** ********** ****** **** ****** credentials ***** *** ** ******** / intercepted. *******, ***** ******** ****** **** these ***** *** *********** ** *******, noting [**** ** ****** *********]:
"**** *** ************ ** ********* *** traffic ******* *** ******* *** *** VMS ***** ***** ** ******* ** HTTP ************** ********* ****** ** *** the *** ** ******* *********** *** HTTP ***** ************** ******* ** **** Digest **************.
**** *** ******** ******* *** *** allows ** ** ********* *** ************** protocol *** **** *** ******** **** a *********** ** ** *** **** using *****."
***** ******** **** **** ******* ***** VMS ******* ***** ** *********** ** this *** **** *** ******* ** verify ****.
[******: ******* ******* * *** *** this *******, ***** ** ****** ** the ******** *****.]
******* ** *** **** ** ********, since ************* **** *** *** ***** with ***** ******, **** **** ** not * ********** ******* (****** *** using ***** *** **** **** ** a ******* ** ******).
*** ** *** ******* ******** *** a **** ******* **** *** ***** ******* ***** ** ********* ****/*** ****** Https ***** ** ******** ***** ****** ******* this. *******, ***** ******** *******, ********** that ********* "**** *** ******** **** *** ****** it ** ********** ** ** * camera ****** ****** ** ************."
******* **** ** ***** ** ****** our ********* ************ ** ******.
Comments (18)
UI
Undisclosed Integrator #1
Nov 09, 2015U
Undisclosed #2
Nov 09, 2015JH
John Honovich
Nov 09, 2015That's one of the issues with these issues, to be exploited there is a narrow avenue to do so. Even if it could be done, since it needs to be done physically in a very specific spot, the probability of it being used is quite low.
U
Undisclosed #2
Nov 09, 2015IMHO, these are the perfect type of vulnerabilities to be found. Bad enough sounding to force the vendors into hopefully fixing them, but infeasible to use by most.
U
Undisclosed #5
Nov 09, 2015And since none of the platforms likely support certificate pinning, they are essentially susceptible to a MITM attack as well ( if you can get physical access to the VLAN and/or network there are lots of ways to intercept encrypted traffic that is not fully secured).
UE
Undisclosed End User #4
Nov 09, 2015The predicated assumption with that statement is that:
- They have access to your encrypted tunnel
- The tunnel is generally accessible over the internet
Both statements being false ensures that no access can occur if this is a closed network (even over VPN). If an airgap is used in design - premise network is isolated from access via a physical (not virtual or software based) firewall on different (non-routed) networks, then there is no potential for exposure unless from within.
Good design precedes secure networks - without it you shouldn't expect that any system you have in operation that operates over HTTPS will be secure.
U
Undisclosed #2
Nov 09, 2015...without it you shouldn't expect that any system you have in operation that operates over HTTPS will be secure.
Though even if someone is directly on your LAN, as is predicated in this exploit, an HTTPS connection should be secure, no?
UM
Undisclosed Manufacturer #3
Nov 09, 2015Some cameras allow you to require digest authentication, as opposed to allowing digest/basic to both be available. I think the trick, is that the VMS needs to have a setting to require SSL or digest authentication, and to fail the connectin otherwise - so it couldn't then back down to basic authentication.
Using 802.1x and IP filtering can require a certificate for the device to allow it on to the network and then who it talks to. This could then ensure a 3rd party isn't inserted into the conversation...
U
Undisclosed #2
Nov 09, 2015I think the trick, is that the VMS needs to have a setting to require SSL or digest authentication, and to fail the connectin otherwise - so it couldn't then back down to basic authentication.
Maybe even once successfully connected via digest, always insist on digest. Not all cameras support digest (even now!), but there is no good reason I'm aware of that once you know it's capable, to downgrade it.
There are a couple different favors of digest auth out there, so even if a camera supports it, it's not guaranteed the VMS can use it. But once they have, for a given MAC, why go back?
MR
Miriam Rautiainen
Nov 09, 2015I’m the Product Manager for Aimetis Symphony VMS.
While the security vulnerability described is primarily a network issue and requires access to the LAN on which the VMS and cameras are operating, Aimetis’ latest Device Pack (DP-35), released last week, addresses this issue. Aimetis DP-35 and the accompanying Release Notes are available free for download for all of our distributors and resellers. This free update prevents potential attacks described above by disallowing the HTTP authentication downgrade.
Aimetis takes all potential security issues seriously and deals with these matters in a proactive and transparent nature. In addition to providing free software fixes, Aimetis issues Security Advisories on its website that provide instructions for issue resolution along with technical support details. We also immediately notify all Aimetis certified distributors and resellers globally about the Security Advisory regardless of how remote the risk may be.
JH
John Honovich
Nov 09, 2015U
Undisclosed #2
Nov 10, 2015This is a good oppurtunity for ONSSI Occularis 5.0 to shine over Milestone!
Did SeeTec do security right?
JH
John Honovich
Nov 11, 2015Genetec released 2 knowledge base articles related to this topic:
- KBA01403 - Deactivating Basic authentication for the HTTP and RTSP protocol
This article explains how to deactivate basic authentication for the HTTP and RTSP protocols to prevent Address Resolution Protocol (ARP) spoofing attacks between the Archiver and a camera. - KBA01404 - Reactivating Basic authentication for HTTPS communication
This article explains how to reactivate basic authentication when an HTTPS connection type is being used for a camera.
RT
Ryan Twitchell
Nov 11, 2015Easy to read breakdown on these types of attacks: https://www.praetorian.com/blog/man-in-the-middle-tls-ssl-protocol-downgrade-attack
I actually want play the devil's advocate for basic authentication as I see it getting some bad press.
TL;DR: if you have an encrypted connection (including HTTPS) or otherwise can prevent interception of your HTTP streams, basic authentication can be a good thing. If you are using only HTTP and are sending data through hostile territory, then digest authentication may be the way to go.
This is as far as HTTP server security is concerned (and every IP camera is basically a little HTTP server) and may not be applicable in all contexts:
Digest authentication has a minor problem. Due to how digest authentication works, it typically requires the server to store your password on disk in order to authenticate you. Basic authentication, however, allows the server to keep only a hash (a "fingerprint") of the password. Storing only the hash makes it more difficult for anyone accessing the server (or camera) to discover your password. But servers that store the whole password (like any time digest auth is used) make this data available to anyone who gains access to the server. Since passwords get reused a lot, this kind of breach can have a bigger impact.
Yes, basic auth sends your password over the wire. Any kind of connection can involve sensitive information, and technologies like HTTPS and TLS are designed to protect this information when used properly, and when kept up to date with known vulnerabilities.
I cannot find an easily digestible reference to support this right now (no pun intended), but anyone interested should be able to confirm this with a little research.
U
Undisclosed #2
Nov 11, 2015But servers that store the whole password (like any time digest auth is used) make this data available to anyone who gains access to the server. Since passwords get reused a lot, this kind of breach can have a bigger impact.
Servers don't need to store the whole password by itself. The user, realm, password hash, HA1, can stored instead. That way it won't be useful outside of the realm.
RT
Ryan Twitchell
Nov 16, 2015I was writing based on some old memories, but a quick read of the RFC shows that you are correct for some cases. My goal in posting previously was not to argue against digest authentication only to raise awareness that basic authentication is not always to be shunned.
I would not argue this point further, except to mention that digest auth depends specifically on the MD5 algorithm. I do not believe storing a password based on its MD5 digest is considered safe in recent years, due to advances in collision attacks against MD5 specifically. Not depending on HTTP digest authentication, a server could store passwords with any hash algorithm (such as bcrypt) and be able to use basic auth.
U
Undisclosed #2
Nov 16, 2015I would not argue this point further, except to mention that digest auth depends specifically on the MD5 algorithm. I do not believe storing a password based on its MD5 digest is considered safe in recent years, due to advances in collision attacks against MD5 specifically.
I would not defend this point further except to mention that RTSP digest authentication does not depend on collision resistance:
In 2011 an informational RFC 6151[11] was approved to update the security considerations in MD5 and HMAC-MD5. For HMAC-MD5 the RFC summarizes that - although the security of the MD5 hash function itself is severely compromised - the currently known " attacks on HMAC-MD5 do not seem to indicate a practical vulnerability when used as a message authentication code." -Wiki
JH
John Honovich
Nov 17, 2015Note: Milestone confirms they are aware of this issue, we are awaiting a response. One would hope they would respond sooner to such concerns.