Pentesters LOVE VOIP Gateways ! - SANS Internet Storm Center

Pentesters LOVE VOIP Gateways !
As someone who does vulnerability assessments, you always hope your clients are doing a good job with their security infrastructure. Theoretically, the perfect assessment is "we didn't find any problems, here's a list of our tests, and here's a list of things you're doing right". In practice, though, that never happens.' Also in real life, there's that private (or vocal) "WOOT" moment that you have when you find a clear path from the internet to the crown jewels. I can start anticipating that moment when I see a VOIP gateway in the rack - these allow remote VOIP sessions (either from a handset or a laptop) to connect to the PBX, through a proxy. VOIP vendors (all of them) sell these appliances as "Firewalls", and usually they have the word "Firewall" in the product name. I had a recent assessment, where we found that the VOIP gateway was based on Fedora 7, with all server defaults taken. Yes, that includes installing an Apache webserver, a DNS server and a Mail server. All unnecessary, all exploitable (given the vintage). Not only that, but they enabled packet forwarding and SNMP, so that not only did the unit forward packets from the internet to inside resources, it also advertised that fact through default SNMP community strings, along with the internal subnets themselves ! Oh, and source routing was enabled - - sort of a pen-test trifecta ! In another engagement, we found a gateway from a different vendor, based on BSD (good start), but with a similar litany of issues: SNMP enabled on the exterior interface Default snmp community string Routing enabled Internal interfaces and internal routes listed via snmp Source routing enabled Oh, and the admin interface (with vendor default credentials) was facing the internet - not that we needed that, it was already open! an expired, self signed certificate. To top it all off, when you got to the admin interface, the you were looking at the word "Firewall" in the product name ! (yea, that made me smile too) Not having actually seen the unit, I asked the client to check to see if it might have been hooked up backwards (with the private interface on the internet side) - alas, that was not the case, the "hardened" interface had these issues ! It's still extremely common to see voicemail servers based on SCO Unix or Windows 2000 (Windows NT4 in a recent assessment ! ). One vendor in particular still has a production, new-off-the-shelf voicemail server based on Win2k. Mind you, all of the appliances had been in the rack for a number of years - the current crop of these devices are not nearly as open as some of the older ones. But that's actually part of the problem - people seem to consider Voice systems (PBXs and ancillary equipment) as "appliances" - somehow different than Windows or Linux servers. Which as you've probably guessed, is not wise - they are Windows or Linux servers! They need to be patched updated, monitored and included in every process that your internal, dmz and perimeter servers see. Even today, we see organizations trust appliances from vendors that don't place security at the fore. Then once they are installed, they are promptly ignored, sometimes for years. Anymore, if it has an ethernet jack, you should be asking security questions before it gets plugged in. And those security questions should be asked again, at least once or twice a year in the form of an audit, assessment or pentest. Anyway, all I can say is - when I'm looking for vulnerabilities, I LOVE (ok, I really really like) VOIP gateways ! ... but you knew I'd be saying that ! ============== Rob VandenBrink Metafore	Rob VandenBrink 488 Posts ISC Handler
Reply Subscribe	Nov 28th 2011 7 years ago
Excellent diary Rob! I would add my experience of finding gateways (often SBCs) with a implicit trust relationship to the upline RTP server. This invites theft of telephony services as the trust relationship often negates the need for endpoint authentication ... hence any endpoint with a valid terminal identifier can register with the RTP/SIP server via the proxy. My point is neither gateways nor SBCs should be permitted to serve as just a pass-through for RTP services; endpoint affiliation and registration should be required to the maximum extent afforded by the IP communications environment. As you so eloquently mentioned, perceiving VoIP gateway devices as simply another network appliance is a very dangerous school of thought.	VB33 6 Posts
Reply Quote	Nov 28th 2011 7 years ago
You haven't lived until you've written a script that robocalls and rickrolls the client's workforce during a pentest.	No Love. 37 Posts
Reply Quote	Nov 29th 2011 7 years ago
You haven't lived until you've written a script that robocalls and rickrolls the client's workforce during a pentest.	No Love. 37 Posts
Reply Quote	Nov 29th 2011 7 years ago

As someone who does vulnerability assessments, you always hope your clients are doing a good job with their security infrastructure. Theoretically, the perfect assessment is "we didn't find any problems, here's a list of our tests, and here's a list of things you're doing right". In practice, though, that *never* happens.'

Also in real life, there's that private (or vocal) "WOOT" moment that you have when you find a clear path from the internet to the crown jewels. I can start anticipating that moment when I see a VOIP gateway in the rack - these allow remote VOIP sessions (either from a handset or a laptop) to connect to the PBX, through a proxy. VOIP vendors (all of them) sell these appliances as "Firewalls", and usually they have the word "Firewall" in the product name.

I had a recent assessment, where we found that the VOIP gateway was based on Fedora 7, with all server defaults taken. Yes, that includes installing an Apache webserver, a DNS server and a Mail server. All unnecessary, all exploitable (given the vintage). Not only that, but they enabled packet forwarding and SNMP, so that not only did the unit forward packets from the internet to inside resources, it also advertised that fact through default SNMP community strings, along with the internal subnets themselves ! Oh, and source routing was enabled - - sort of a pen-test trifecta !

In another engagement, we found a gateway from a different vendor, based on BSD (good start), but with a similar litany of issues:

SNMP enabled on the exterior interface
Default snmp community string
Routing enabled
Internal interfaces and internal routes listed via snmp
Source routing enabled
Oh, and the admin interface (with vendor default credentials) was facing the internet - not that we needed that, it was already open!
an expired, self signed certificate.
To top it all off, when you got to the admin interface, the you were looking at the word "Firewall" in the product name ! (yea, that made me smile too)

Not having actually seen the unit, I asked the client to check to see if it might have been hooked up backwards (with the private interface on the internet side) - alas, that was not the case, the "hardened" interface had these issues !

It's still *extremely* common to see voicemail servers based on SCO Unix or Windows 2000 (Windows NT4 in a recent assessment ! ). One vendor in particular still has a production, new-off-the-shelf voicemail server based on Win2k.

Mind you, all of the appliances had been in the rack for a number of years - the current crop of these devices are not nearly as open as some of the older ones. But that's actually part of the problem - people seem to consider Voice systems (PBXs and ancillary equipment) as "appliances" - somehow different than Windows or Linux servers. Which as you've probably guessed, is not wise - they *are* Windows or Linux servers! They need to be patched updated, monitored and included in every process that your internal, dmz and perimeter servers see.

Even today, we see organizations trust appliances from vendors that don't place security at the fore. Then once they are installed, they are promptly ignored, sometimes for years. Anymore, if it has an ethernet jack, you should be asking security questions before it gets plugged in. And those security questions should be asked again, at least once or twice a year in the form of an audit, assessment or pentest.

Anyway, all I can say is - when I'm looking for vulnerabilities, I LOVE (ok, I really really like) VOIP gateways !

... but you knew I'd be saying that !

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

Rob VandenBrink

488 Posts
ISC Handler

Excellent diary Rob! I would add my experience of finding gateways (often SBCs) with a implicit trust relationship to the upline RTP server. This invites theft of telephony services as the trust relationship often negates the need for endpoint authentication ... hence any endpoint with a valid terminal identifier can register with the RTP/SIP server via the proxy. My point is neither gateways nor SBCs should be permitted to serve as just a pass-through for RTP services; endpoint affiliation and registration should be required to the maximum extent afforded by the IP communications environment. As you so eloquently mentioned, perceiving VoIP gateway devices as simply another network appliance is a very dangerous school of thought.

VB33

6 Posts

You haven't lived until you've written a script that robocalls and rickrolls the client's workforce during a pentest.

No Love.

37 Posts

You haven't lived until you've written a script that robocalls and rickrolls the client's workforce during a pentest.

No Love.

37 Posts