Angelcam Cloud Video Tested

Pretty neat. I tested with Samsung Cameras (Samsung employee...). Their support pages were no help - pretty much said Samsung cameras may work, but didn't have correct URI. I entered the URI that I have for MJPEG & RTSP and got it working.

MJPEG has low delay of approx 2-3 seconds. H.264 RTSP takes longer to start streaming and has approx. 10-12 second delay. Audio came through well for both streams. The live view app works well - lots of branding for free, and make sure to turn off the google map location. Easily viewed on mobile device.

The cloud recording free plan does not allow you to save/download/export clips, making it pretty useless.

I like the idea, however the "autodetect" needs to be better - they need to update their database of camera URI, and add more apps. I know that they have a bunch in beta. The time lapse allows you to create only 3 videos for free.

It is nice that it is HTML5 with no plug ins, however, it is NOT quick to jump around between cameras, etc. to use as a management dashboard. You can view the small thumbnails or full screen, but nothing in between.

The dashboard has a snapshot of the cameras, but it is always a few hours old, so that can lead to confusion. To get live video, you have to select a cam, then wait for it to load...

Most of the forums are 2-3 years old....

Thanks for the review!

On multi-camera availability (e.g. synchronous playback/export) - we created few variations of our UI and selected customers are testing it currently. This is one of the alternatives (combining live video monitoring & playback on one screen). When we'll have positive feedback from most of our customers for any winner, we'll release it publicly.

So what's the trick to getting the no-plugin required H.264 streaming going?

I am using the latest Chrome I think, Version 46.0.2490.71 m, but I noticed that the player used to render the live stream for me is Adobe flash.

Clever application and pitch but…

Some observations regarding the review of AngelCam Video Security; observations that can be applied pretty much to every other like product (D-Link, DropCap, NestCam, this cam, that cam the next cam et. al.).

First up – cost, which appears to be a bit steep. If I lived in a one room house with only one entrance and no windows, no driveway and no cars to park in the non-existent driveway then perhaps the cost of $40 per month for a single camera installation is marginally acceptable. But I don’t live and work in such an environment. In my case my home and business have more than one room, there are windows, there are three entrances, there is a drive and there are cars parked in the drive and to compound matters, there is an out building; by no means a unique setup. At minimum, six security cameras are required. For this the AngelCam numbers indicate a monthly nut in the neighborhood of $420. Added to that are onetime cost of an otherwise unnecessary router, cable modem, ComCast cable hook up and related network stuff. So, not including the one time costs involved, the annual out of pocket for an AngelCam solution is in the vicinity of $5000. I also question the longevity of the $10/month storage pricing as AWS S3 costs leave little headroom for profits. The otherwise unnecessary cable network installation is required to accommodate uplink bandwidth for 6 IP cameras doing 24/7 medium quality H264 HD video. Too bad AngelCam doesn’t support event driven recording as it would certainly improve their profits prospect and help reduce the bandwidth needs.

How about security – should a security product increase the user’s security risk? While I think not, I’m an outlier on this question. To wit, early this year HP released a study of 10 cloud based security systems using a battery of 10 security test criteria; and their findings, most products batted 1000 (all failing some tests) and all batted at least 700 (7 out of 10 failed) other tests. Enviable numbers for the majors but not so much for security products. My hopes that AngelCam would break the mold were dashed as I would learn. Use of AngelCam requires a hole punched through router and firewall to allow access to the IP camera; a front door wide open to the Internet. Added to this, AngelCam transmits camera credentials in the open over the Internet. So, it’s a snap for man-in-the-middle to grab the camera credentials, hack into the camera (that is likely running a variant of embedded Linux) infect the camera OS and from there jump to everything connected to the LAN. Adding insult to injury, although the Web App does use HTTPS to the cloud, only single factor credentials are used; the users email address is required for user name and there is virtually no restriction as to password; for my tests I used “a123”. Getting my email address is a snap, discovering my password takes minutes after which, bing, the hacker is in to my AngelCam account and the AngelCam cloud by impersonating me and using “secure HTTPS” protocol. Yes, of course I should have used a more challenging password but that would not demonstrate my point; there are lots and lots of people who continue to use “password” as their password, not advisable but they do. So it’s become the responsibility of the service provider to protect their clients by forcing use of strong multi factor credentials. Also, out of curiosity I launched Wireshark and sure enough, my personal video is streamed un-encrypted over the Internet available to anyone who may be interested. A claim that a security product is secure because parts of it use HTTPS or because it is hosted on AWS, Azure, iCloud or any other cloud service is an empty claim to be sure. In time I expect MS, Amazon, Google, Apple et. al. will start forcing their clients, in this case AngelCam, to provide their service clients, you and me, with better cloud service security. Until then “cloud security” remains an oxymoron.

Another security matter I take issue with in the AngelCam model is the concept of allowing the “free” developer access to my personal data, information and content. AngelCam, like SmartThings (Samsung), advertise for developers from around the world to join up and invest in and support their products. These totally un-vetted developers are then given the golden key to the kingdom, the cloud that holds the end users stuff. Whilst one might decide to put their trust in AngelCam or Samsung/SmartThings or others with similar business/product models, I wonder if they would do so if fully aware that in effect they were publishing their personal and private stuff to the world and anyone who wants to sign up as a service developer.

A final observation; while I’m happy to see that “Video Surveillance” is finally evolving to “Video Security”, shouldn’t a multi camera video security system include support for other related technology such as door locks, smoke detectors, CO detectors, water detectors door/window sensors, vibration sensors, motion sensors, and all the rest? Rhetorical question, of course it should.

I began this missive with it’s a “clever application and pitch” and I’m sure it will snare many but how much is it actually applicable to the subject of “security”. Missing from the list of clever gadgets (real or planned) is the very basic concepts of “motion detection”, “event enabled recording” and “event notification”; I could find no mention of either. Security is breached but there’s no notification; really? What’s the value of counting the number of criminals invading my home or business? Anonymizing the crooks to protect their identities seems a strange security system feature and counting cars or reading license plates seem far afield from the stated goal of home/business security system.

In closing, I did try out AngelCam and it did operate as advertised. It’s a neat product and application but perhaps not best suited for the application of home/business security.

John, agreed - like I said, they will snare the naïve.

Undisclosed 1 – correct, plain like in “plain text”

Today typically the Security-as-a-Service architecture such as used by AngelCam (and others) has at its center of the implementation a cloud Internet server, which in AngelCam’s case is hosted on an AWS S3 virtual machine. The cloud Internet server provides for three basic access paths for data flow; (1) the developer pathway normally accomplished over secure private network connection such as VPN/RDP or telnet/sh, (2) the public Internet connection between user Web/Mobile App for account setup, maintenance and content viewing and (3) the security device (in this case an IP camera) to cloud Internet service connection.

The data path or vector of interest in this case is that between cloud Internet service and the security device, path (3) from above and your vector 3 I believe.

Via path (2) the user establishes an SaaS account and in the process provides the service with certain personal data and information which in AngelCam’s case includes the external (public) IP address of the home/business router. The user also provides the access credentials and other such information required by the service to access the security device over path (3). Working together the user and the cloud Internet service figure out the correct string required to initiate an RTSP session with the security device and this is also stored in the cloud Internet server.

As an aside, there is the interesting question of what happens to the AngelCam account setup when the home/business Internet service provider decides to change the routers IP address. In the case of ComCast, this happens weekly. Following this, the next time it becomes necessary for the cloud service to re-connect (and invariably there will be a next time) it appears to me the reconnection will fail and the user will be forced into having to setup the camera account once again. I may be wrong, but I suspect this is the case since there is no mention of setting up DDNS and hence no way for the cloud service to know the new IP address assigned.

Be that as it may, the AngelCam service user also needs to setup their home/business router which may be done automatically, semi-automatically or manually. No matter which the results are the same; a hole per security device is blown through the routers firewall to allow access by the cloud Internet service to the security device.

Once setup is complete the cloud Internet service can initiate an RTSP session with the security device via path (3). Initiation is done by sending the RTSP string, established during account setup, in plain text format over the Internet to the public IP address that was provided during account setup. When the request string hits the router it is routed to the IP camera through the hole that was blown in the firewall.

From that point the un-encrypted plain video content are streamed from the security device via path (3) to the cloud Internet server where it is stored and made available for viewing via Web/Mobile App. Path (3) appears to be limited to RTSP streaming only with no out-of-band notifications leading to an assumption on my part that the AngelCam implementation has no “notification” ability, that is, no ability for the security device to notify the user of events such as motion detection indicating possibility of an intrusion. I know, this kind of defeats the purpose of the security device but...

As another aside; from the above you can see there are many opportunities for security breaches including; hacking the security device (IP camera) by a man-in-the-middle attack, stealing the video stream by a man-in-the-middle attack and pirating the account by impersonation attack. None of these possibilities are the responsibility of the cloud infrastructure provider, in this case Amazon and none are prevented by use of HTTPS.

DESCRIBE rtsp://root:pass@xx.xx.xx.xx:554/axis-media/media.amp RTSP/1.0

Above from shark, IP address is xx'ed out, camera as you guess is axis in default setup mode

Web site footprint all uses TLS 1.1 with AES 128 GCM and a 2048 bit RSA key using a SHA-256 hashed signature. So they got the crypto right, sort of. All their sites are comingled on the same key. So their customer data is no more important than their blog posts in terms of their network defense strategy. And RTSP should be sent over HTTPS or HTTP, and you should not be opening firewall holes. So this one sounds insecure.

There are a lot of things that could be done to improve/reduce user security risks. Using digest would help, multifactor authentication would help, encrypted user data would help... The question I suppose becomes, should the customer’s security be of concern enough to warrant such measures? Apparently not at the moment but at some point that becomes the more fundamental question to be addressed and I suspect that sooner or later security product providers will come face to face with it.

Fascinating turn this thread has made. A few random thoughts:

First off I’m not trying to apologize for the security vulnerabilities that Richard points out about AngelCam. Today I tend to assume that most implementations of cloud based surveillance products follow more mature principles that limit the particulars he points out. But in AngelCam’s case the goal is (I guess) to provide a convenient way to attach any RTSP source to the service and that limits the security options somewhat.

The HP paper that Richard mentions is pimping their Fortify On Demand offering which is a security scanner that itself is based on the OWASP’s draft IoT guidance. The thing about OWASP is it’s just a guidance. OWASP itself encourages people to ‘weight the pros and cons’ of each recommendation in the context of their own environment and system. Some recommendations are thus not always implemented even by systems that are relatively secure (for example, two factor authentication). So it’s pretty easy for HP, marketing wise, to take a category of products, evaluate them in detail against the entire set of OSWASP recommendations, and then claim that nearly everything they test is not secure and oh-by-the-way you need to buy their security scanner product.

I like Richard’s analysis but don’t agree with some implicit generalizations. Maybe I’m a little over sensitive, but I don’t believe you can look at HP’s marketing or AngleCam’s issues and then conclude that all cloud-based systems are inherently insecure or more insecure than the alternative. The state-of-the-art for providing remote access to a home security system for many years has been hanging a DVR off the local network and providing port forwarding to said DVR’s HTTP interface through the firewall. How many of those implementations fail to adhere to the OWASP guidance?

I do agree that providing a publically accessible path to a security system is something to be taken seriously. Thus any ‘cloud based’ solution needs to be scrutinized for security. And if you’re a provider/manufacturer of such a solution then security needs to be in the DNA of your development, deployment and operation. I propose that it can be done safely if it’s done well. The challenge is to discern between those that are doing it well both in terms of design and implementation and those that are not.

I can confirm Richard's findings that angelcam is sending user name and password in clear text in the RTSP URL.

I found it by using the RTSP Honeypot described here.

Good work, Richard!

Hi guys,
Thanks for such worthy discussion! Let me comment some parts of it.
The Angelcam platform is constantly growing and so are our security features. IP cameras nowadays only support RTSP protocol for video transfer, which (by design) isn't secure. The only thing we can transmit securely is password, using digest authentication. We've implemented this feature recently and we're going to launch it in a few days. There's a secure alternative to RTSP -- it's called SRTP. However, only a handful of Cisco IP camera use it. Due to the lack of such features we're currently working on a solution that will bring security to the next level. So yes, cloud-based services mature every day. I should also add that customers with security concerns can use Axis OneClick feature with HTTPS encrypted tunnel, which is supported by all Axis IP cameras.
I've just added 2-factor authentication to our roadmap, so thanks a lot for the feedback.
Once again, thank you guys for your posts.