From: Martin Walker (Martin.Walker@ctg.com)
Date: Sat Feb 08 2003 - 13:07:59 EST
Well unfortunately I'm seeing PBX security not that easily handled. It
is not just enough to restrict source IP addresses and control access to
the management software.
The problem is twofold, first that PBX, Voice Mail, Call Center Modules
and other modern telephony devices are more and more general purpose
Unix platforms (albeit with some additional special hardware and
software). The second part of the problem is that PBX and related
devices are often the "red headed step child" of IT. What I mean is
that telephony is more frequently managed by Facilities (ie the
department who manages HVAC, building maintenance, power, cleaning and
guard staff) rather than IT (at least in my client base). At most IT is
repsonsible for the environment only, power, temp, location etc and not
the management of the box.
When combined these two issues lead to organizations that implement
general purposes Unix platforms with zero OS level hardening. Even
worse, because the IT dept doesn't own the equipment and because
probably neither dep't realizes the problem, the devices aren't even
monitored in any way......a perfect hideout.
A recent pen test revealed several pieces of Avaya/Lucent/AT&T equipment
running everything....echo, chargen, telnet, ftp, sendmail, portmapper,
etc etc etc all buggy and unconfigured. If I crack the box (which
appears to be a cakewalk) I have complete control over an unmonitored
Unix platform. Great for hiding out, launching other attacks, storing
files etc. Further I can control the telephony system via that IP
connection by directly changing configuration files.
Scared? I can change, monitor, send or delete VM. I can reconfigure
Interactive Voice Response Systems (please enter your social security
number and pin, then hit pound)
Scared? I haven't even started talking about the computer-telephony
integration in the call center. This integrates the agents applications
with IVRS and various other pieces on the front end and the
organizations data store on the back end. EG. Many financial call
center applications ask for you to punch in ss#, account codes etc in
the IVRS. The system builds a database query and ships it off to some
back end db. This is so that your info comes up on the agents screen
when your call is taken. So, if I have control over the box can I build
my own queries? I've also seen systems that insert data into the
database in the same way.
Making matters worse is that the telephony vendors don't have a clue
about anything other than the telelphony side of things, and if you
harden the box yourself you'll void most vendor paper regarding support
etc.
Several steps need to be taken to effectively combat the situation.
First is that IT should own telelphony, not facilities. Second IT needs
to recognise these devices are general purpose computing platforms and
design the secured architecture appropriately. This would include
implementing firewalled "zones of protection" between the data access
layer (in this case the IVRS/call center), application layer (agent
applications) and the data storage back end. Third the boxes need to be
hardened and the IT department's standard security self-certification
program applied just like any other platform. A certification program
would include recurring certification requirements. (I know everybody
is using some sort of internal certification program to implement and
manage security across the organization.....right?).
The final additional step, that is EXTREMELY important and in fact
should be be in place BEFORE IT attempts to harden the box, is that
purchase/lease/acquisition contracts and on-going support and
maintenance contracts need to be renegotiated. This is done in order
that the responsibility and authority for both the management and
monitoring of security on the platform is defined. If the
responsibility for implementing security lies with the
selling/maintaining organization the user of the system must retain the
right to verify and test it is being done. There should also be strict
penalities in the form of defined liquidated damages for non-compliance.
-----Original Message-----
From: Rob Shein [mailto:shoten@starpower.net]
Sent: Wednesday, February 05, 2003 2:04 PM
To: 'Razvan'; pen-test@securityfocus.com
Subject: RE: PBX Security
First, the good news. PBX control can be restricted; no matter HOW
awful the access controls are, if the dial-up modem for remote admin of
the PBX (usually left there for support purposes by the company that
installed it) is turned off, you are safe from that means of attack. If
it is network-capable, make sure that the subnets/hosts that are able to
communicate with it on ANY level are highly restricted. And just about
all the high-end PBX systems have the ability to turn off whatever
administration from desktop sets may be possible.
Software updates are rather hard to patch in transit, however; one would
need something akin to snort + hogwash, with a rule to alter the packets
as they passed. This is about as far from trivial as I can imagine.
The solution to this is easy, however; have the patches hashed
remotely/sent encrypted and applied locally. This is also in keeping
with the "do not hook your PBX to the internet" concept.
A PBX is like any other bit of critical infrastructure; it can be set up
incorrectly, and woe to the organization that does so. The best thing
to do is render it inaccessible to untrusted users.
> -----Original Message-----
> From: Razvan [mailto:bugtraq@risc.ro]
> Sent: Wednesday, February 05, 2003 2:51 AM
> To: pen-test@securityfocus.com
> Subject: PBX Security
>
>
> Hi all,
>
> As promised, I return with the reasons I freaked when I saw
> what a PBX can become if used unwisely.
>
> First of all, there is the Call Fowarding - I Am Here
> feature, which allows you (whoever you might be) to redirect
> any extension to the phone you have physical access to (this
> is just a real life case I met.. not ANY extension, and not
> just any user can do that, with proper configuration). That
> is a very evil feature. Redirection of modem pools to my
> extension and the old "Login failed X 3 && cancel redirect"
> trick worked like a charm. Domain admin passwords were
> retrieved this way. Not to mention more elaborated social
> engineering attacks on the business processes of the company
> that are possible because of this.
>
> Second of all, and the most scary, I believe, is the lack of
> cryptographic controls on software updates for a PBX. AFAIK,
> there is absolutely no way the PBX can identify if changes
> were brought to the software update in transit, not digital
> signature, not even a hash (this is information confirmed
> upon repeated ocasions by the manufacturer's representative).
> This opens a door to a very dark room. We're not only talking
> about the usual hidden admin account, but imagine thousands
> of software updates being tampered with to automatically
> assign an extension to DISA with no authentication, bypassing
> the SMDR.
>
> This seems to be the case with one manufacturer, Mitel.
> Please tell me that I'm wrong, and please tell me that at
> least other manufacturers provide controls on their software updates.
>
> Also, I feel unable to come up with any sort of relevant
> advice on this matter. What's actually scary is the fact a
> PBX owner has practically no control over such an issue. He
> can have the most secure configuration, a relevant and
> enforced security policy, security conscious users, etc and
> he's still vulnerable. Or is he?
>
> Waiting your thoughts on this.
>
> Razvan Teslaru
> Romanian IT Security Company
>
>
>
> --------------------------------------------------------------
> --------------
> This list is provided by the SecurityFocus Security
> Intelligence Alert (SIA) Service. For more information on
> SecurityFocus' SIA service which automatically alerts you to
> the latest security vulnerabilities please see:
https://alerts.securityfocus.com/
----------------------------------------------------------------------------
This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
Service. For more information on SecurityFocus' SIA service which
automatically alerts you to the latest security vulnerabilities please see:
https://alerts.securityfocus.com/
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:27 EDT