Vulnerabilities ********
* **** ** *** **** ********** mailing ***** *** ********* * ***************:
******: ** *****-**** ******* ******* ***********
******: ****** ****** ****** *** ***
******: *** ******** *** ** ****
******: ****** ****** ******** ****** *** arbitrary ***** ** **** ** ********** CSRF ******
******: **** ****** .*** ******* *** binaries *******
******: ********* ** ******* *** **** interface
**** *** **** ****** ***** ********** ** ***** ***************** ************ ************.
Key ******** / *******
*** **** ** ** ******** ************ using ***** *************** ** ********* ***.
** ****** ***** ******* *** **** ** the ********* ******** ** ** ***:
- ******** ** **** ** ***** * user **** ******** * ********* **** in ** ***** ** ** * website, ***** ***** * ****** ** the ******
- ******** ***** *** ******** ** ******* or ******** ** * ********** ******* to ******* ** ***** ** *******
- *** **** ****** ** **** **** while ****** **** ***** ******* ******** ** the **** *** ******* *** **** is ******* **
- *** ******* *** ** ******** ***** to *.*.* **** ***** ******* ******** 3 ***** ***, ** ***** ****
********* *** **** ** *** ***** ** **** the ****** ********** ********* ** *** ability ** '********' *** ******. *******, this ** ****** **** *********** *** difficult ** ******* **** *** ***** ********, ***** ****** *** *** ******** connect ** * ********** ****** *** backdoor **.
************, *** ************ ******** ***** ********* limit ** ******** ** ******* ****** to a **** ******* ****** ** *******, if ***, ******** *** ******* ** this ***** **** *** ***** *******.
*** ******* ** ******* *** *** vulnerable ** **** *******, ** ***** is ** **** ** ******** * malicious **** ***** ****** **** * VMS **** *** ***** ****** ** a ******.
Affects ******** ***** ** *.**
**** **** ******** ******** ***** ** 5.70 *** * ********* *** ************* that ***** **** **********. ***** ******* older ******** ************** ******* ******** **** ****' ******* ******* *** *** ** **** cameras. ***** **** ****** **** ***** firmware *********, ***** *** ***** * wide ***** ** ******* *** ***** updated ******** ** *** *********.
** ** ******** ****** ** *********, users ***** ** ******* ** ******** the *** ** ******** ** ****** the ******, *** * ******* ***** than *** ******* ******* **** ***** so, *** ***** ******* ****** ** clicking ***** ** *******/********* ***** **** logged **** *** *******.
CSRF ******* - *** ** *************
***** *************** ******* ****** ***** ***************. ** *****, **** ******* **** on * **** ***** ****** **** a ******'* *** ********* *** **** ******* the **** ** ***** * **** that ********** ** * ******** ******* on *** ******. *** **** ** often ********* ** ********* ****, **** as * **** ** ** ***** where *** **** **** "***** **** to ***** **** *******", *** *** URL *********** ** * ******* ** the ****** (**: ****://***.***.*.**/***-***/******.***).
*** ***** ***** ******** * **** high ***** ******** ** ****:
******* *** **** ******* *** ****** to *** ******, *** ***** *******, VPN, ** **** ***** *****, *** attacker **** *** **** ******** ****** access ** *** ******, **** **** need ** ***** *** **** **** clicking * **** **** * ********* crafted ***.
CSRF **********
**** ******* *** ********* ** ********* * special ***** ** **** ** *** request. *** ***** ** * **** string ********* ** *** ******, *** sent ** *** ****** ** ******* with *** *******, ***** ***** **** the "****://***.***.*.**/***-***/******.***" ******* **** **** "****://***.***.*.**/***-***/******.***?*****=***********". ** * **** ***********, *** token ** **** ******, ****** ** effectively ********** *** ** ******** ** guess *** ******* **** ***** ********* link.
VAPIX ******** **** ***** ***
********* ** ****, ***** ***** *** ** not ********** **** **** ******, ***** prevents **** **** ***** **** ********* to ******* **** *******.
Axis **** ****** - ********* ***
**** ******** * *****-** **** ****** on ***** *******, ** **** ** easier *** ***** ** **** ****** files ** ***** **** ***** ** the ******. **** **** ****** ** called ** *** *********, ***** **** as **** ** ******** *******, ****** it *** ********* ** ******** ** overwrite *** **** ** *** ******.
**** **** **** ****** **** ** removed ** * ****** ******* ** further ****** ******* *********.
Comments (19)
Undisclosed Integrator #1
Interesting. Does Google do these tests randomly or is this a researcher doing this as a side project? Is this possibly related to the Arecont to Axis switch from last year?
Create New Topic
Michael Gonzalez
03/24/17 09:07pm
Excellent information and article, thanks. So if I'm reading this correctly, is it safe to assume this type of exploit is rendered even more unlikely when the camera network is logically segregated from the internet/internet connected devices?
Create New Topic
Jon Dillabaugh
03/27/17 12:10am
Can't believe people still sell these vulnerable devices.
Create New Topic
Undisclosed Manufacturer #3
A vulnerability is a vulnerability. Any and all devices on the network whether that network is "isolated" or not, can become a source of a network attack.
We as the "good guys" must protect our network from any and all possible intrusions. For the "bad guys" they only need to find one weakness to exploit, so the advantage will always be with the bad guys.
Your presumption that certain vulnerabilities are worse than others (a scale of 1 to 10) presumes that all exploitable vulnerabilities will result in the same impact to the system. A vulnerability of "1" (your scale not mine) can be severe if it is on a mission critical system where more aggressive attacks from more determined hackers are being launched and the success of the attack will have a severe and significant impact on the system or operations of an organization which may reach beyond just the camera system.
We as an industry need to take information security more seriously. There are some manufacturers who are knowingly allowing common vulnerabilities and exposures either because they don't want to invest the money in properly hardening their devices or they are responding to customer requests to exchange convenience for security. I have unfortunately encountered integrators and end users who complain about the challenges of implementing very robust IT security in their network. In addition, a highly secure network requires constant maintenance and upkeep as new CVE's are discovered not only with the devices but with the computing and network systems that they are attached to.
We have not heard the last of these vulnerabilities and they will continue to plague our industry. The real questions for those who appreciate and desire strong IT security are, is how pro-active your vendor is being with their information security and how quickly do they react when a vulnerability is discovered?
Keep up the good work in reporting this information as awareness is the first step to providing a more secure system, but unfortunately, the bad guys are always looking for ways in and sooner or later they will probably find one.
Create New Topic
Undisclosed Manufacturer #3
My point is that both matter if they are exploited. I guess my concern is the attitude that "well it is hard for someone to exploit so it is no big deal." Perhaps I am reading something into this that wasn't meant. As an IT security professional, the risk of a CVE isn't judged based on "how hard" it is to exploit it is judged on what damage can be done by exploiting it. My concern is the disconnect between our industry and network security professionals. I guess I am objecting to the premise of the question. if we want to rate a vulnerability we need to do so based on what damage can be done. For example, if a vulnerability allows someone with special expertise to change the date/time of a camera, that might be considered a low risk. if the vulnerability can be used to launch a more serious attack on the network, delete data or launch a DoS attack for example, that is a more serious exposure regardless of how hard it is for someone to do.
Create New Topic
Wade Pinnell
Agree!
John, you are correct to focus on the vulnerabilities of hardware. Any responsible End-User will base their overall cyber-security programs on a Risk Management approach. It is the only practical way to administrate security.
Risk is a factor of the Threat (who is attacking), the Vulnerabilities in the system and the Consequence of an attack. While a bit simplified, this is the general equation. Some Risk methodologies are volumes long and mathematically complex processes.
Customers rarely provide enough details on Consequences to their business or the Threats they need, or are willing to, protect against. Add to this equation, that most integrators don't possess the qualified consultative assets to conduct a comprehensive Risk Management Study
So in the end, your premise is correct. Lowering the vulnerability in hardware may be the only practical step an integrator can unilaterally deliver to a customer.
Create New Topic