Martin, I agree w/ most of your points. PBX's, IVR's, CMS's, etc. are typically forgotten or overlooked during network assessments. When these systems are scanned, they typically light up like Christmas trees. Additionally, we can hack audix, it's possible to eavesdrop on switched telecom networks, and toll fraud is always an issue. I won't even get into VoIP. Recently - within the last three to five years - PBX's and related systems have become more a part of the networking space, and have become more interconnected to data networks. Additionally, PBX functionality is moving from proprietary OS's to ones we know & love (or love to hate) - primarily Linux, MS, and Solaris. These systems are typically shipped open as it's impossible to guess what functionality customers will require. Thus, these systems are typically insecure. They are, however, securable - if that is a word. This is not meant to be an advertisement - note my bias as I'm a member of the Avaya Enterprise Security Practice. Our mandate is to focus on converged security. As part of that mandate, we have developed procedures in order to lock down these voice-associated systems; and we use open source & proprietary tools in order to assess the security of these systems and networks. My point is: Some vendors are beginning to realize how target-rich this environment is, and they are taking the appropriate steps in order to address the cognate security issues. Thomas N. Porter, Ph.D, Senior Consultant Avaya Enterprise Security Practice IM: AvayaTPorter tporterat_private -----Original Message----- From: Martin Walker [mailto:Martin.Walkerat_private] Sent: Saturday, February 08, 2003 1:08 PM To: Rob Shein; Razvan; pen-testat_private Subject: RE: PBX Security 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:shotenat_private] Sent: Wednesday, February 05, 2003 2:04 PM To: 'Razvan'; pen-testat_private 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:bugtraqat_private] > Sent: Wednesday, February 05, 2003 2:51 AM > To: pen-testat_private > 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 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 2b30 : Sun Feb 09 2003 - 16:25:12 PST