J. Oquendo
2013-11-26 19:12:20 UTC
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 willA 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
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