Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Security Input Devices IT

IZON IP Cameras Riddled With Security Flaws 55

An anonymous reader writes "With recent action by the FTC against TRENDnet, the 'Internet of Things' has taken a sharp turn in the eyes of the public and government with regard to security. This week, Duo Security employee Mark Stanislav presented security research he did on the IZON IP camera from Stem Innovation. Through his testing, Mark found hardcoded credentials for Linux accounts (accessible by Telnet; Yes, — really), an undocumented web interface allowing for viewing a camera's stream (also with hardcoded credentials, user/user), and a variety of other failings including a lack of cryptography in most of the camera's functionality, including when uploading videos to Amazon Web Services's S3 storage." According to the above-linked article, "Contacted by The Security Ledger, Stem Innovation CTO Matt McBeth said that the IZON firmware, server system and iOS applications tested by Stanislav have since been updated, and that the research contains “inaccurate and misleading information.” Stem did not provide specific information about any inaccuracies."
This discussion has been archived. No new comments can be posted.

IZON IP Cameras Riddled With Security Flaws

Comments Filter:
  • Who cares about izon?

    You really need to worry more about dogs named Skippy.

  • by cmholm ( 69081 ) <cmholmNO@SPAMmauiholm.org> on Thursday October 24, 2013 @05:10PM (#45228679) Homepage Journal

    I'll be generous and guess that IZON farmed out too much of their software development to ... wherever. Perhaps the company's principals are more hardware oriented, but it's interesting that they're now advertising for an iOS team lead.

    • by cmholm ( 69081 )

      IZON... Stem Innovation, whoever.

    • To assume that they had any more involvement with the hardware than they did with the software is fairly charitable... At least random Chinese OEMs know how to build webcams and cheap 'n cheerful ARM SoCs, so that aspect of the plan probably went OK.
  • by LikwidCirkel ( 1542097 ) on Thursday October 24, 2013 @05:18PM (#45228763)
    Here's what happens... The company gets a Linux SDK from some chip vendor which works on some reference platform. This is intended for development and evaluation purposes and has many interfaces exposed, which is generally what you want for development. The producer then hires some cheap amateurish programmers to write some application code on top of the SDK to make the product do stuff. The stock kernel and filesystem is deployed as-is. No security audit is done, no unnecessary services are closed, and few things are removed from the stock SDK filesystem. It will never get fixed for any or all of the following reasons: 1) No one at the company has enough experience to lock down/strip down Linux - they just know how to write applications on-top. 2) There are deadlines and the management has a "it works, ship it!" mentality. 3) Some developer/engineer might know how to do things properly, but is so swamped with deadlines and babysitting all the juniors that it can't happen.
    • damn... forgot the explicit line breaks.
    • by icebike ( 68054 )

      To this, you have to add the distinct possibility that the intent was to leave a back door on purpose so that the tech support staff did not have to issue an RMA for users that simply forgot their password.

      (Yes, a simple hardware reset switch would do, but that can actually be harder to do as you have to support a wipe-able storage for that).

      • by adolf ( 21054 )

        (Yes, a simple hardware reset switch would do, but that can actually be harder to do as you have to support a wipe-able storage for that).

        You're overthinking this. The reset switch in any bit of modern consumer goods just signals the software (usually with a GPIO pin or similar) that it has been pushed. The software then behaves however it is programmed to behave based on this condition.

        Simple hardware reset switches went away when battery-backed CMOS RAM got replaced with flash EEPROM for storage of conf

    • They are always like this - especially if the vendors can keep the source secret. I've taken to running VLAN's at home - mostly WNDR3800 refurbs ($50 w/ Prime) [amazon.com] running OpenWRT and GS-108T switches [amazon.com] (poor GUI, but linux inside), feeding to a pfSense instance. Anything that's not all open source goes on an isolated VLAN that can't get traffic to or from anywhere without an explicit rule. pfSense makes it pretty easy to set up a VPN to get to data on the inside, so outside ports don't need to be open.

      I set i

  • Oh, how many of this story fills out spots on the Public Relations Security Bingo [crypto.com] game? I counted four. You have to refresh to get all of the possible options; there are more than fit on any one card :)

  • Anybody that would think these systems offer any level of security is only kidding themselves. They are a simple convenience to avoid needing to set up a VPN for trivial data. I wish I could find a better solution, but for a camera that sits in the window looking at the street not especially worried.

  • by Anonymous Coward on Thursday October 24, 2013 @06:21PM (#45229401)

    Until the really awfully managed company decided to outsource all of the software development to contractors. This was after wiping out the team in place before I joined. They are a very unstable company, which really favors knee-jerk decision making. I'm not surprised by any of this, the company is run by the idiot kid of a rich guy who doesn't know the first thing about tech. The hardware was well designed by the CTO, who apparently isn't able to steer the technology decisions of the company. Unfortunate. He's a good guy. But the company is ultimately helmed by the CEO, and he's a fat fucking moron.

  • I lost interest when I saw it requires an iPod, iPhone, or iPad.

Remember to say hello to your bank teller.

Working...