From: Rob Shein (shoten@starpower.net)
Date: Wed Feb 05 2003 - 14:04:15 EST
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