
I don't normally post to this list, as it is more for the SP side of things. A few weeks back we had a publically exposed LifeSize video conference unit compromised. It was not installed particularly well, given the limitations to the administrative PIN code, but it has shell access enabled, and a flash portal which purportedly has rights execution issues. The vendor has a firewall device that would place these behind it on private space - was that in play where your units were attacked? We've since removed these until we can provide a full video call control infrastructure, to keep from exposing these appliances, but I figured it was the poor PIN code that was hit, not the device itself. Adam Pawlowski SUNYAB

On Tue, 26 Nov 2013, Pawlowski, Adam wrote:
I don't normally post to this list, as it is more for the SP side of things. A few weeks back we had a publically exposed LifeSize video conference unit compromised. It was not installed particularly well, given the limitations to the administrative PIN code, but it has shell access enabled, and a flash portal which purportedly has rights execution issues. The vendor has a firewall device that would place these behind it on private space - was that in play where your units were attacked? We've since removed these until we can provide a full video call control infrastructure, to keep from exposing these appliances, but I figured it was the poor PIN code that was hit, not the device itself.
Adam Pawlowski SUNYAB
This LifeSize was "theoretically" behind a firewall. I will explain 'that' one. We manage(d) the FWs (SSGs btw) there however... Client 'demanded' they have access to be able to change things as they saw fit. So whatever rules are, or were in place, is who knows. That became the Pottery Barn rule for us (you touched it you bought it). Now... Depending on which version of LifeSize you have, you're either running Apache, or now Lighttpd, both of which are "DoS'able." So that's fine and dandy, where DoS comes into play however, the user "Test()" is an anomaly because this user was ALSO coming into the PBXNSIP systems' CDR logs. We try whenever not to ever make devices public, but when clients want to be able to have their PBXs have their calls forwarded from their PBX, to their cells, refrigerators, and toilets, we have to let them know: "hey this is what can (and usually does) happen." They're all chipper with it until they get a bill for $50,000.00 because someone went ahead and used a strong password of 12349876 even though we have shown them: "look, these attackers, can test hundreds of thousands of password in a minute..." LifeSize: I want to say a lot, but it would be stepping on toes. My suggestion, if you need to put it online, do so for the duration of use, then pull the plug. Same goes for the Polycoms. One of these days, I will stop being lazy and write up some advisories I have been holding onto for some time... Maybe we should all get together and keep a running WIP (work in progress) of a "Best Practice" which would be a no bs, vendor neutral: "DO THIS NOW" whitepaper of sorts. I'd be willing to spew theories/thoughts/practices. (By the way chucking VoIPSA back on this thread, I know many criss cross that list, but some on that list, don't traverse this one). -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF
participants (2)
-
ajp26@buffalo.edu
-
sil@infiltrated.net