Foscam · @foscam
16th Jun 2017 from TwitLonger
TECHNICAL DETAILS ON F-SECURE REPORT
For the more technically minded, our Security R&D Team has outlined the validity of these claims and which firmware version your camera needs to be upgraded to:
If you have any questions on these issues and want to clarify if your camera is secure, feel free to email us as press@foscaminc.com
1) INSECURE DEFAULT CREDENTIALS - while all Foscam cameras come with a default set of user credentials that are easily found on the camera itself, in each application that Foscam supports REQUIRES a change of password to a secure password. The camera will not be operational for use unless this step is completed or the user makes an explicit choice NOT to change the password.
2) FTP SERVER PASSWORD - REPORTED BUG AND ADDRESSED
In an earlier version of firmware, an FTP account could be accessed in a limited number of models; but only from trusted users within a home network, not from an external attacker. While this may present a very negligible security risk, we have updated the firmware to address this previous issue.
3) FTP SERVER PASSWORD HARDCODED - REPORTED BUG AND ADDRESSED
As mentioned above, this issue has been addressed in the latest firmware. And, as before, this trusted, local access presented an extremely small security risk since it was not accessible from the outside world. In service to this concern, we have since removed these hard-coded credentials.
4) HARD CODED CONFIGURATION BACKUP FILE
While the issue reported sounds like a security concern, this functionality is used by a number of our worldwide installers to install multiple cameras in locations without having to manually enter all access details at each installation. While there is a hard-coded password for protection from one camera to the next, the onus of security is on the user to ensure that the configuration file is not available for any hacker to have access. And, in order to hack the backup configuration file, the hacker would have to expend tremendous effort to decrypt the strong password.
5) HARD-CODED MANUFACTURER CREDENTIALS - REPORTED BUG AND ADDRESSED
Earlier camera firmware had a hidden credential that provided access to some low-level functionality for the purposes of quality assurance testing. While this credential did not provide any means for accessing private customer information or content, the latest firmware deletes this testing credential.
6) TELNET FOR TESTING - REPORTED BUG AND ADDRESSED
As mentioned in 5), the firmware did support a vestigial telnet functionality for quality assurance testing and upon release was disabled and therefore not useful for unauthorized activity. As in keeping with the earlier comments, this functionality has been deleted in the latest firmware release.
7) REMOTE COMMAND INJECTION FROM USER ADD - REPORTED BUG AND ADDRESSED
Again, in order for this injection to occur, the hacker would have to have administrator privileges to perform a remote injection. Since the administrator password would already be strengthened due to our password constraints, the unauthorized user would have to have very strong processing ability. Thus, any security risk associated with this issue was extremely negligible. With the report of this minor issue, our Security R&D Team has since strengthened our system to address this slight issue in the latest firmware.
8) REMOTE COMMAND INJECTION FROM USER ADD - REPORTED BUG AND ADDRESSED
Formerly, with administrator rights a remote command injection could be attempted in /mnt/mtd/boot.sh via productconfig.xml. Just as above in item 7, and for any computer device, if a user has administrative access, the user can control the device; but this necessitates cracking the strong password associated with the administrator account. Any such possibility, of such a remote injection, was therefore extremely negligible; nonetheless, we have strengthened the security of injection for productconfig.xml in the latest firmware.
9) Since implementing firmware security enhancements in 2016, an anonymous Onvif account (which is a standard implementation for devices to work with Onvif supported NVRs, i.e. most vendors must implement this to support Onvif) could retrieve limited camera information, such as Firmware versions. But such camera information could only be retrieved via the local network (never from outside of the local network without the user explicitly enabling uPnP, which is always disabled by default); and, it was impossible to thereby access any private information or content (such as a user’s username/password, video feed, image etc.). Furthermore, the anonymous account does not have the privilege to call `devicemgmt’, or `SetDNS’.
Please note that while this anonymous Onvif account therefore posed no substantive security risk, our new firmware has nonetheless disabled the anonymous Onvif account by default. For users who would like to use the devices together with certain NVRs which require it to be enabled, they can do so when logged in via Foscam Web UI or Foscam VMS. We have disabled the anonymous Onvif account by default as a reassurance of any concern of unknown risk, although no such risk has been discovered and Foscam’s Onvif implementation is fully safe to use with NVRs even when the anonymous account is enabled.
10) Formerly, with administrator rights an attack on the permission assignment of /mnt/mtd/boot.sh could be attempted. Just as above in items 7 and 8, and for any computer device, if a user has administrative access, the user can control the device; but this necessitates cracking the strong password associated with the administrator account. Any such possibility, of such a risk for unauthorized access, was therefore extremely negligible; nonetheless, we have strengthened the security of this permission assignment in the latest firmware.
11) Formerly, with administrator rights an attack on the permission assignment of /mnt/mtd/app could be attempted. Just as above in item 10, and for any computer device, if a user has administrative access, the user can control the device; but this necessitates cracking the strong password associated with the administrator account. Any such possibility, of such a risk associated with any attempt of this method, was therefore extremely negligible; nonetheless, we have strengthened the security of this permission assignment in the latest firmware.
12) Due to confusion among some users regarding the privileges of the anonymous Onvif account (see item 9 above), we are confirming that ever since firmware security enhancements we implemented in 2016, this account has lacked any ability to call `media` and `GetStreamUri’.
Please note that while this anonymous Onvif account therefore posed no substantive security risk, our new firmware has nonetheless disabled the anonymous Onvif account by default. For users who would like to use the devices together with certain NVRs which require it to be enabled, they can do so when logged in via Foscam Web UI or Foscam VMS. We have disabled the anonymous Onvif account by default as a reassurance of any concern of unknown risk, although no such risk has been discovered and Foscam’s Onvif implementation is fully safe to use with NVRs even when the anonymous account is enabled.
13) Due to confusion among some users regarding the privileges of the anonymous Onvif account (see items 9 and 12 above), we are confirming that ever since firmware security enhancements we implemented in 2016, this account has lacked any ability to call `devicemgmt’ and `SystemReboot’.
Please note that while this anonymous Onvif account therefore posed no substantive security risk, our new firmware has nonetheless disabled the anonymous Onvif account by default. For users who would like to use the devices together with certain NVRs which require it to be enabled, they can do so when logged in via Foscam Web UI or Foscam VMS. We have disabled the anonymous Onvif account by default as a reassurance of any concern of unknown risk, although no such risk has been discovered and Foscam’s Onvif implementation is fully safe to use with NVRs even when the anonymous account is enabled.
14) Due to confusion among some users regarding the purpose and limitations of the internal camera firewall, we are confirming that the Foscam Firewall is not a full-featured firewall like what is implemented in a personal computer. It is designed to provide basic IP filter functions to stop consistent sniffing from certain IPs, or only enable designated access from certain IPs.
15) Formerly, our login protocol refused login attempts for 5 minutes after 6 failed attempts occurred within 10 seconds. This was designed to prevent brute force hacking attempts. With this policy, any 6 digit case-sensitive password comprised of random letters and numbers would require roughly 3,600 years to crack by way of brute force hacking.
This was also designed to avoid affecting human users, because most users cannot complete 6 attempts in 10 seconds manually; nonetheless, for this same reason our products were misperceived as missing this essential security mechanism when users attempted to log in with multiple invalid passwords. We have therefore changed our login protocol to refuse login attempts for 5 minutes after 6 failed attempts in 30 seconds. While this change allows average users to test this function easily, by tripling the original time window of 10 seconds, it also triples the number of years that would be required to crack a password with the same complexity.
16) Formerly, denial of service (DoS) attacks could be performed on the RTSP video feed. This did not pose any privacy risks for customers, but under such an attack, the user would be prevented from accessing the video feed and the camera would require a restart to reestablish the live feed. To further strengthen protection against DoS attacks, we have updated the RTSP component in the latest firmware.
17) Due to confusion among some users regarding the privileges of the anonymous Onvif account (see items 9,12, and 13 above), we are confirming that ever since firmware security enhancements we implemented in 2016, this account has lacked any ability to call `Status’ and `Device Information’.
Please note that while this anonymous Onvif account therefore posed no substantive security risk, our new firmware has nonetheless disabled the anonymous Onvif account by default. For users who would like to use the devices together with certain NVRs which require it to be enabled, they can do so when logged in via Foscam Web UI or Foscam VMS. We have disabled the anonymous Onvif account by default as a reassurance of any concern of unknown risk, although no such risk has been discovered and Foscam’s Onvif implementation is fully safe to use with NVRs even when the anonymous account is enabled.
18) After the release of firmware security enhancements in 2016, anonymous Onvif accounts (standard implementations for devices to work with Onvif supported NVRs, i.e. most vendors must implement this to support Onvif) could only retrieve limited camera information (e.g. Firmware versions), and only via the local network (i.e.,never from outside of the local network without the user explicitly enabling uPnP, which is always disabled by default). Private information or content (e.g., a user’s username/password, video feed, image etc.) cannot be accessed with this method, and furthermore, the anonymous account lacks the privilege to call `devicemgmt’, or `SetDNS’. However, if a camera’s firmware version pre-dated those 2016 updates, or if an unauthorized user had obtained administrator rights, then a buffer overflow attack could be performed exploiting the setDNS method used by Onvif. In the unlikely event of this occurring, it would nonetheless not pose any privacy risks to customers because only their access to their own video feed would be affected, until the camera automatically restarted itself to reestablish the live feed connection. And for any computer device, if a user has administrative access, the user can control the device; but this necessitates cracking the strong password associated with the administrator account.
Any possibility of risk, associated with any attempt of this buffer overflow method, was therefore extremely negligible: it necessitated cracking the strong password associated with the administrator account, or required the user to be running very outdated firmware (i.e., dating prior to releases in 2016). Nonetheless, to further strengthen protection against any such buffer overflow vulnerability, we have updated the Onvif component in the latest firmware.
Please also note that although, since 2016 firmware versions, the anonymous Onvif account has been verified as posing no substantive security risk, our new firmware nonetheless has disabled the anonymous Onvif account by default. For users who would like to use the devices together with certain NVRs which require it to be enabled, they can do so when logged in via Foscam Web UI or Foscam VMS. We have disabled the anonymous Onvif account by default as a reassurance of any concern of unknown risk, although no such risk has been discovered and Foscam’s Onvif implementation is fully safe to use with NVRs even when the anonymous account is enabled.
In conclusion, in writing the above we have endeavored to show that Foscam always puts security first, and that we make a continuous and sincere effort to stay ahead of industry standards. As we’ve explained, all of the above eighteen issues have been fixed (and in some cases, have already been resolved for over a year). No known breaches have occurred, even before these fixes, and we hope that this clarification redresses any contrary competitor statements by simply offering the facts. To our customers, thank you for trusting us. We will always strive to honor your trust and earn your business by responding to security concerns with the utmost seriousness, timeliness, and diligence.