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