Penetration Testing mailing list archives
RE: PBX Security
From: "Martin Walker" <Martin.Walker () ctg com>
Date: Sat, 8 Feb 2003 13:07:59 -0500
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/
Current thread:
- PBX Security Razvan (Feb 05)
- RE: PBX Security Rob Shein (Feb 06)
- Re: PBX Security Fabio Pietrosanti (naif) (Feb 10)
- <Possible follow-ups>
- RE: PBX Security Martin Walker (Feb 09)
- RE: PBX Security Thomas Porter, Ph.D. (Feb 09)
- RE: PBX Security Jonathan Rickman (Feb 10)
- RE: PBX Security Jacek Lipkowski (Feb 11)
- RE: PBX Security Thomas Porter, Ph.D. (Feb 09)
- RE: PBX Security Brennen Reynolds (Feb 10)