SANS ISC: What Else runs Telnets? Or, Pentesters Love Video Conferencing Units Too! - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

As a side note to today’s iSeries / Mainframe story, and a follow-up to one I wrote last year (https://isc.sans.edu/diary/12103),  another thing I’m seeing is more and more on telnets (tcp port 992 - https://isc.sans.edu/port.html?port=992) is voice gateway and videoconferencing unit problems.

Specifically, when scanning for port tcp/992, you will likely run across more videoconferencing systems than mainframes.  They’ll often show up with less fingerprinting than the SNA platforms we discussed, for instance a videoconferencing unit (the host information in this story is from a recent penetration test, and is released with permission) might look like:

PORT    STATE SERVICE  VERSION
992/tcp open  telnets?

For the videoconferencing unit in my client’s test scope, the telnets session was unprotected by anything as crass as a a userid and a password – if you open up a tn3270 (telnet over ssl) session, you’ll get something like this:

Funny, no credentials were needed to get to this screen.  Not knowing exactly what we're on yet, let's type “help”, maybe we'll find that this box is "helpful":

Helpful indeed, looks like we've got full admin access, with no credentials!  But from that first terminal screenshot, we see that an HTTP website is enabled, maybe things will be easier if we try that?  From the screenshot below, we see this host gives you all the same admin information and rights as we had on the terminal session, also without a password!

What leaps out at me from this screenshot (aside from the vendor and model number ,greyed out in these examples)  is the firmware date (2006), and the “remote control” selection, which does exactly what it sounds like!

The “Admin Settings” page gives you all the most common items you’ll need to change if you were actually going to attack this host (remember, I’m still on that session from the internet, with no authentication):

And yes, you did see “Place a Call” in that last screenshot!  This particular option can add up to real dollars very quickly - there's an active community of folks stealing and reselling long distance service from units like this!

Note also, the install date and firmware date are the same (2006).  This is one *vintage* videoconferencing unit.  For some reason, people seem to think that maintenance of IP voice gear involves cleaning products rather than firmware updates!  As long as the unit is shiny, it must be fine!

We also found SNMP open, with the default community strings (public and private).  From this we found that this host was internet connected, then connected to the customers PBX (by listing the interfaces).  I'll spare you those screenshots, you'll find similar in the story we ran on Voice Gateways last year ( https://isc.sans.edu/diary/12103 )
 

So, the main lessons here are:

Never trust the vendor to correctly install anything.  This particular unit was installed as part of an RFP'd project by a VOIP vendor, who didn't see any issue with putting this on the internet. It’s just too common to see things configured to a minimum standard, with no regard for security.  This is not specific to voice or video gear, though we see this a lot in VOIP projects

Scan your own perimeter.  In fact, scan your own internal network also.  There was no reason for you to wait for a paid security assessment to find the easy stuff like telnet interfaces open,  admin interfaces with no credentials or default credentials, or SNMP open with default community strings.  We’d much rather find the fun stuff (problems in websites for instance) than easy stuff like this.

Never trust documentation when the vendor docs tell you what ports need to be open to a host.  I can't tell you how often I see vendors insist that they need inbound port 25 to *send* email, or inbound 53 to make DNS requests (both are incorrect of course).

Never put stuff outside your firewall unless you know exactly why it should be there.  The gateway we found in this story was indeed outside the firewall, the documentation for the unit actually states that there is a firewall onboard (there is no such thing)

Patch.  Your VOIP gear - the PBX, the phones, gateways, all of it, are really just a collection of computers.  If you don't patch them, they will be exploited - VOIP gear is a real target these  days!  The difference between exploits in your computer network and voice network is that when your VOIP gear is exploited, it will show up as a large long distance bill at the end of the month.  Hopefully your accounting group will see this as a problem, rather than just paying the invoice when this happens!

===============
Rob VandenBrink
Metafore