Correction des bugs de sécurité Foscam

Début juin 2017, la société F-Secure avait découvert plusieurs failles dans les caméras Foscam. Il y avait 18 vulnérabilités qui avaient été répertoriées.

Suite à cela, le constructeur Foscam a sécurisé ses caméras. Heureusement que la marque Foscam est connue car d’autres constructeurs moins connus mais utilisant les mêmes couches logicielles sont sans doute encore touchés par ces problèmes.

Pensez à mettre vos caméras à jour avec les derniers Firmwares qui sont disponibles sur http://www.foscam.com/downloads/index.html

Voici le résumé en anglais des réponses à chaque point de la part de Foscam  (http://www.foscam.com/important-security-firmware-announcement.html) :

1)   If a Foscam camera has never been used, the default ID and password are “admin” and “ .” We have investigated and confirmed that in any real use case, these default credentials become nonfunctional as soon as the camera is used for the first time and the user has set a password. During setup (by either Foscam App or Web UI), users are always required to specify a new user name/password; because you cannot take the camera online without changing the default password, it does not create risk. Every package’s documentation furthermore directs the user through this procedure which is necessary for enabling the camera to function.

 

2)   Formerly, a vestigial FTP account could be accessed in a limited number of models; but only over a local network, never a remote network. This account therefore presented a very negligible security risk, but in the latest firmware we have fixed a programming error that had prevented this account from being disabled.

 

3)   Formerly, there was a hard-coded password associated with the aforementioned FTP account (described above in item 2). As the FTP account has been disabled, these hard-coded credentials have also been removed.

 

4)   For customers buying multiple cameras, we implemented a configuration export function to increase the ease of setting up additional WiFi connections, alarm settings, etc. All camera models use the same hard-coded key for encrypting the configuration file when a user has chosen to export their configuration settings. On the surface, this may seem like a security concern, but in actuality there is no security risk: any unauthorized user must have administrative credentials to obtain this configuration file, as well as to access the cameras. Even with such access, an unauthorized user would only be able to obtain the userid/password of the unauthorized account which he/she was already using. In summary, unless the unauthorized user is able to crack a strong password, there is no way for them to obtain the configuration file.

 

5)   Formerly, the web user interface (Web UI) had a hidden credential used for manufacturer testing. Although this credential could not provide any means for ever accessing customer information or content (such as user name, password, video feed, etc.), the latest firmware deletes this testing credential.

 

6)   Formerly, the source code for the cameras contained vestigial telnet functionality, which was disabled and therefore not useful for unauthorized activity. Nonetheless, this source code has been deleted in the latest firmware.

 

7)   Formerly, with administrator rights the User Add command could be remotely injected. An unauthorized user would need (a) administrator privileges to perform a remote injection, and (b) any such user would need to have already cracked the strong password associated with the administrator account. Therefore, any such remote injection risk associated with the User Add command was extremely negligible. Nonetheless, the security of injection for the User Add process has been strengthened in the latest firmware.

 

8)   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.