This is a good move for them - but I don't think it addresses the lock-in issue. If you want to use Meraki with another VMS such as Milestone (or Genetec, Exacq, etc...) at the same time it's good. There are legitimate use cases for this, so this is helpful, and a step in the right direction.
Cisco Meraki Unlocks IP Cameras With RTSP Tested
****** ****** ** *** ******* ** 3rd ***** ****/***** ********** **** **************** ** "*** **** ** ***** * ******** problem".
** ****** * ****** ******* (******,****) **** *********, *** ** **** report, ** ******* ******'* **** ********* and ***** *** ******** **:
- **** ** *** **** *** **** of ****** **** ***?
- **** *********** **** **** ****?
- *** **** ******* ******'* *********** *********** vs *******?
- *** **** ****** **** *******?
- *** ** ** **********?
- **** ****** ******* *** *********?
Executive *******
***** ** ****** **** *********** (****** the *********** ** ****, * ****** video ********* ********) *** ** ***** Meraki ***** ******* ***** ***** **** 3rd ***** *******, ** ***** ** risky ** *** **** ** * way ** *********** ******* **** **** Meraki ** *****.
*******, ****** **** **** *** '*** a ****** ******' *** *********, ******* that **** *** ***** ********** ** blocked ******* * ************ *** **** one ***** *** ** **** ** make ****** ************* ******* ******* ***.
****** **** ********* ********* ******* ** our *****, ********* ** ********* ******** without ******. ************** *** ************* ** the ******* *** ********* **** **** than * *******. *******, ***** **** (only) ***** ******'* **-***** ****** *** vehicle *********, ***** ** ********.
** ******** ************* ***** ******* (*-* seconds) **** *** **** ****** ****** direct *** ********* ** *** ****** interface (*-* *******), *** ****** ****** streaming (*-* *******). ******* *** **** stream ** **** ********* ** *** local *******, ******** ****** ******* ********* substantially.
***** *** ****** ************ *** *******, we **** **** ** ******* *** Meraki *******, **** **** *******, ********* RTSP, *** ****** ****** ********. ****** said **** *** *** **** ******** ***** ****** ******* ******* of ***********. ****** ********* **** *** ****** will ******** ** ****** **** **** even **** ******* ********.
Best *** **** - ********** *** ***** ******* ** *****
*** **** *** **** *** **** new ******* ** ********** ***** ****** but ********** ** *** ***** *******, e.g., ***'* ******** ****** ******* ** PSIM, ************* *** ***** *** ** video ********* **** *** ******* (*******, Anyvision, ********, ******, ***., ***.).
Verkada ** - ******* *** ***** **** ****-**
****** *******, *** ******* ** ******* one's ***** ** *** ***** ******* is ** ********* ******** ** *******'* fully ****** *****. *******, ** ** a ******** *** ******** *** ***** systems *** ** ** *** * fully '*****' *** ** ******* ***** that ****** ***** ** ********** **** they ***** *** *** **** ********* if *** **** *** ******** ** pay ****.
Meraki **** ********
***** ** * *-****** ***** ******* the ******* ** ******** ****** **** and *********** ** *********:
Streaming *********** ***** / *** *******
** ***** **** ********* *********** ** be *****, **** *** ********** ***** H.264 **** **** ***. ******* ******* from ******** ******** *** ********* ******* did *** ***** *** ******.
** ******** ******* *-* ******* ** latency:
** ******** ~* ******* ***** ******* of *** ***** **** ****** **** direct *** ********* ** *** ****** web ******:
*** **** **********, **** ** ************* better ***********, ********* **** ****** ** real-time **** **** ***** *** ****** web *********.
****** ************* ********** *** *** ********* **** ***, which ******* ** ****** ******* ******** to ****:
***** **** ** *** ***** **** Live ********* (***), ***** ** **** is **** ** *** *********, *** delay **** ** ************* *******. ******** RTSP **** *** ****** *** ********* delay *** ***** *********.
Minimal ************* - ** ******** *********
**** ********* ** ******* *** ****** and ** * ****** "***/**" ****** in ****** ********, ***** ****** ** performed ** * ****/*****-****** *************:
***** ** ** *****/******** ******** ** supported *** ******* *** **** ******, which ** * ************ ******* *******, providing **** ****** ** ***** ******* without ***** ** ********.
****** **** **** **** ****** ** used *** ***** *** ****** ***** integrations:
** ** **** **** ** ****** RTSP ** * *** ***** ** simple *** **** *** *********. ******** you *** **** * ******** *** password, **** ** *********** ** ***** text *** ***** ** * ***** sense ** ********. **** ** *** we ***'* ***** **** ****** *** specifically **** *** *** ***** **** enabled ** * ******.
********** ** ***** **** ** * minimally ********** ********* ** **** ********* with **********, *** *** ** *** primary **** **** ************* ******** ** get ***** **** *** ******.
No ****** ** ********* / ****** ******
***** ****** ******* ***** **-***** ****** and ******* *********, *** **** ****** does *** ******* ***** ****** ** data. ** **** **** ** *** Milestone's ******-***** ****** *********, *******, **** will ** ** ***** *** ****/*** that ** *** ***** **:
****** ******* **** **** ********* ** targeted *** ************ ** ***** ********* systems, ***** ***** *** *** *** included ******-***** *********.
Risk ** ******
*** **** ** ****** ** **** are ********* ***** * **** ** unlock ***** ******-** ****** *** ******* out ** ********* ************ ******** ** open ******** *******.
*******, ** **** ****** ****** ***** also *** ****** *** ******** *** WiFi, ****** *** **** **** *** overall **** ** ***** ******* ***** ecosystem ** ***.
****** **** **** ** *** *** RTSP ** * "****** ******" *** system ********* **** **** ******, *** temporarily ********** *** ****** ******* ** an ******** ***:
********** ********* **** * ******* ** be **** ** *** *** ******. We ***** *** ** ******** **** from *********** ** ** ********** *****, but ** * ****** **********, **** isn't ********* ********.
**** ** ** *** ***** **** functioning, * ***'* *** **** ** a ****** ****** *** * **** to ******* *** ** *** ***** open ******. ** ***'* ******* ***** and ** *** ******* ** *** camera ***** ** ***********, ************ *** stream ******* *** ***** ****** ************** could ***** ** ******* *.*. ****-***** adjustments.
Cameras *********
**** ********* ** ********* *** ****** ********** ****** ** ******, ***** *** ****** **** *** in '*', ******* ** *.* ******** and *****. ** ****** **** ** 4.5 ********.
Hans do you have any experience or insight with integrating with another VMS as you suggested? I have an opportunity that may require this approach. Any info you can share would be greatly appreciated.
thanks
feel free to reach out to me - I'm in the office today - 512-473-0500. I have a call for the next hour - but I'm more flexible this afternoon.
Thanks for the comprehensive report - good job.
Very interesting.
There 100% are ways to leverage RTSP + encryption and non-vulnerable passwords. Not true, just lazy and no business motivation from Cisco.
Lack of authentication means they may as well scrap the feature. Before anyone says "it's behind a firewall", lets discuss most successful attacks occurring laterally. Crunchy outer shell, soft gooey center. Cybersecurity matters and Cisco certainly knows it.
Before anyone says "it's behind a firewall", lets discuss most successful attacks occurring laterally.
yes, let's discuss. can you point me to any known lateral attacks where the video streams were the target?
Most customer breaches are not reported to the public. If you are expecting a high-profile disclosure of such, that would be a bit silly. I certainly know that every breach that I have been involved with for incident response has incited an immediate NDA from the customer before any business terms were settled upon (whether a publicly-disclosed event or not).
Are you inferring that the door should be left open and we can all trust that no one will walk through it? Then further, if someone walks through it - that the general public will receive notification of such a breach? If so, you are grossly underestimating the sophistication of the modern bad actor as well as the motivation for disclosure from average businesses. Every breach I have been involved with for incident response over the last several years has had a fairly long incubation period of data gathering before whatever event led to discovery.
Most customer breaches are not reported to the public. If you are expecting a high-profile disclosure of such, that would be a bit silly.
silly me, i took your "let's discuss most attacks happening laterally" to mean you were ready to provide further information.
or even an anecdotal NDA sanitized report like,
the hackers hacked thru the corporate firewall and proceeded to pull video from an unsecured video camera. then, after observing the security guard asleep at his post, they entered the premises...
do you think things like that happen?
It is not my problem to supply you with easily referenced articles of lateral attacks (which is what I clearly stated). These come in all kinds of shapes and sizes. Most commonly, I see them start at exposed RDP when 3389 is opened to web and then that gets compromised and then attacks move laterally.
I would certainly never disclose any detail whatsoever in the recovery efforts I have aided in the past. Sanitized or non-sanitized, it would provide me with zero commercial value in taking the time to do so.
I am happy to have an open discussion around your defense of leaving the door open when it is an easy problem to solve. Not sure why you are deflecting that this is stupid.
A more likely consequence is intellectual property theft as it does not require physical escalation. At the end of the day - the intent is irrelevant and ignoring security vulnerabilities in the security industry is...well, stupid. Should all professionals all ignore best practices across the board? The more glaring and obvious holes that are left exposed, the easier attack vectors get. Ya know, defense in depth and all that.
It is not my problem to supply you
For sure, but if you want to convince people to your cause, it's helpful to strengthen your case.
I do think the bigger issue is that 'physical security' professionals tend to undercount the risk of internal threats, e.g., to this day, Hikvision USA allows anyone with local network access to reset the admin passwords for Hikvision devices.
Rather than be dismissive with #1, you might want to him (and others reading over).
John, completely understand what you are saying but the request was not about lateral attacks as I cited. Requesting that would have been realistic. It was randomly pigeonholed to be very specific to this particular instance to include unauthenticated RTSP requests which is obviously hyper-specific to request as a particular citation. Nobody allows unauthenticated RTSP unless the intent is to open things up because it is bad practice. Because of this, nobody is going to publish a paper about something getting compromised after a user intentionally turned off RTSP authentication.
Meraki not providing for authentication here is irresponsible. It is providing a feature and ignoring cybersecurity.
If the user was not intentional in the pigeon-holed question, I will happily apologize and provide a plethora of lateral-attack related information.
It was randomly pigeonholed to be very specific to this particular instance to include unauthenticated RTSP requests which is obviously hyper-specific to request as a particular citation.
you are incorrect about pigeon-holing.
my initial request was only
can you point me to any known lateral attacks where the video streams were the target?
which is about as general and un-"hyper-specific" as you can get.
I think it is fair to agree to disagree here :-)
Unless a user was intending the entire world to access a stream, unauthenticated RTSP would never be enabled. You won't find attack articles or studies about people purposefully compromising their own systems in this way. There is nothing of "interest" or case studies to inviting your neighbors into your house and then calling the police for trespassing. Can't avoid that "threat". You just wouldn't invite the neighbors in the first place if you didn't want them entering.
Meraki has a responsibility to safeguard their customers. That was ignored here (installed a door frame but no door).
If anyone is not familiar with the concept of lateral attacks that could affect a surveillance system - I will educate all day. Would love an entire conversation about all of the ways that professionals in our industry ignore cyber threats that they don't think are likely. They are real threats and hoping for the best is not practicing our due diligence that we owe those we swear to protect.
Meraki has a responsibility to safeguard their customers.
Jacob, for the record, i believe that there is no defensible excuse for Meraki not to include at least digest auth in the feature. my speculation would be that they are either unwilling to invest more resources in a "grudge" feature, or even that they are purposely omitting it in order to not make a more robust enterprise solution. and users are right to demand a secure connection.
that said, your initial position of
Lack of authentication means they may as well scrap the feature.
is an overreaction, for several reasons.
1) it is not enabled by default
2) it is clearly documented as unsecure
3) the user could, if they wish, secure the connection between the camera and the VMS, by using a dedicated VLAN.
4) There is no other way to get the stream to a 3rd party VMS.
so Jacob, I ask you, if you own 100 Meraki cameras that you may or may not wish to migrate/mirror at some point, do you really wish they would scrap the feature?
I'm not sure of how case-specific that is, but just the very first Google search with the "RTSP cyber vulnerabilities" brings some stuff to worry about: CVE - Search Results
can you point me to any known lateral attacks where the video streams were the target?
I believe this has happened in the nation-state hacking world. I recall a story (probably Darknet Diaries) where one nation's hackers were able to access a webcam feed of another nation's hacking team. The webcam feed helped them locate and dismantle the other side's operation. [citation needed]
Also, I would be concerned about another type of insiders. We have had to help a client catch a supervisor who was stalking a coworker through the VMS. If you have an unauthenticated video feed, that becomes a lot harder to deal with.
For some regions in the world (like certain coundtries in the Middle East) where ONVIF is mandated by local regulations, unless there is real Onvif support, this might still not be enough to be touted as a "benefit" and will still not allow the cameras to be considered "open" in the eyes of many.
Meraki opened up its cameras to 3rd party NVRs/VMSes by offering RTSP streaming because of "the need to solve a business problem".
If they wanted to solve a business problem, just stop making the cameras altogether. I would say the same thing for Ubiquiti. Ubiquiti cameras are way overpriced for what they are. ONVIF may not be the greatest, but no one is going to waste time supporting direct integration for cameras because both of these lines I can't believe would be the first choice for integrators.
I like Ubiquiti products and what I have used of Meraki products I have liked. The cloud setup and management is fine. The issue is that I want to use my choice of VMS and Meraki and Ubiquiti aren't on my short list for a VMS.
On the flip side, these cameras fit in where IT people are already invested in the system and someone says that they need cameras. IT says, no problem Ubiquiti or Meraki have cameras and I can manage them like all my switches and routers. I get what they are trying to do, but there is still a gap between security products and strictly IT products even though some may think they are the same thing.
RTSP is my last choice for recording a stream anyways.
RTSP is my last choice for recording a stream anyways.
agreed. i'm waiting for a MJPEG over HTTP option :)
It is very hard to secure RTSP in a way which is simple and easy for customers. Although you can have a username and password, this is transmitted in plain text and leads to a false sense of security. This is why we don't offer this option and specifically call out the issue when enabled on a camera.
Interesting that they don't seem to be aware of Digest Authentication for RTSP (where you do not send the password as plain text), or tunneling RTSP over HTTPS.
This is a massive move for them. Can't wait to build this integration into Sequr/Genea Access Control
This just ups the game for their hardware. Hopefully they will build some decent resolution camera with multi-imager.