Security

"Vishing" advisory targets Asterisk

By Jake Edge
December 17, 2008

A light-on-details warning—issued late on a Friday no less—had users of the Asterisk telephony platform scrambling recently. It was issued by a US government group that includes the FBI, which tends to attract attention, and warned of unspecified vulnerabilities that would allow "vishing" attacks using subverted Asterisk systems. Vishing is a relatively new scam that uses phone calls in phishing expeditions (the name comes from combining 'voice' with 'phishing'), but typically using systems that are owned and run by the scammers.

Evidently, the FBI received word that Asterisk systems were being subverted by way of a vulnerability (AST-2008-003) reported last March. Systems were then used to make "thousands of vishing telephone calls [...] within one hour" trying to elicit personal information—generally credit card numbers—from victims. By using caller ID spoofing techniques those calls could appear to be coming from the credit card company itself. Typically, a pre-recorded message would give the user another number to call, where they would be prompted to enter the information via an interactive voice response (IVR) interface.

Asterisk is a multi-purpose free software suite that can act as a ~~public~~ private branch exchange (PBX), handle VoIP traffic, do IVR, and more. Because it provides such a general purpose platform, it does make an attractive target. It is probably also enticing to control such a device that is being run by—and can be traced to—someone else. But the folks at Digium—original developers and primary maintainers of Asterisk—don't really think the problem is as bad as was indicated.

The original problem was fixed months ago, so it clearly irks the Digium folks that it has been fingered now. In addition, the original advisory didn't even point to the vulnerability so users and Digium were left to guess what exactly was being exploited. The advisory was updated to include information about AST-2008-003, but there is still some skepticism about the potential for exploitation. On Digium's blog, community manager John Todd thinks the problem was overstated:

While I won't get into the details of configuration specifics, I would say that an administrator would have to consciously configure their system in what I believe to be an extremely unusual way in order to be victimized by this particular vulnerability. The flexibility of Asterisk lets a developer do almost anything, but it seems that there would need to be an almost absurd configuration circumstance that would allow this bug to be harmful in the way described.

While it may well be that this particular vulnerability is difficult to exploit, there will likely be others down the road that are less so. While some users may be getting a little more wary about phishing and email-based scams in general, phone calls have generally been considered more trustworthy. But it is no longer true that phone numbers are definitely traceable back to a physical location with a billed party known by the telephone company. Much of this information can be spoofed or re-routed in ways that make detection more difficult.

Phones have certainly been used in scams over the years, but the advent of caller ID has tended to put an undeserved stamp of authenticity on certain calls. If a pre-recorded message purports to come from GiantCompany and the caller ID entry has that name, it is easy to conclude that the call is genuine. Much of the same effort that has gone into educating the public about phishing will also need to be applied to vishing.

This is certainly not the first instance of PBX systems being abused either. Subverting PBXs for free long distance calls is a longstanding trick in the "phreaking" community. But Asterisk provides a much more capable platform, thus a much more useful tool, both for those that run them and those that subvert them. Asterisk users need to keep that in mind when security issues come to light.

Comments (17 posted)

Brief items

Google's Browser Security Handbook

Google has posted a Browser Security Handbook, written by Michal Zalewski. "This document is meant to provide web application developers, browser engineers, and information security researchers with a one-stop reference to key security properties of contemporary web browsers. Insufficient understanding of these often poorly-documented characteristics is a major contributing factor to the prevalence of several classes of security vulnerabilities." It is thick and detailed enough to make it clear that no web application developer can ever hope to understand all of the relevant details.

Comments (3 posted)

New vulnerabilities

aview: insecure tmp file usage

Package(s):

aview

CVE #(s):

CVE-2008-4935

Created:

December 15, 2008

Updated:

December 17, 2008

Description:

From the Gentoo advisory:

Dmitry E. Oboukhov reported that aview uses the "/tmp/aview$$.pgm" file in an insecure manner when processing files.

A local attacker could perform symlink attacks to overwrite arbitrary files on the system with the privileges of the user running the application.

Alerts:

Gentoo

200812-14

aview

2008-12-14

Security

"Vishing" advisory targets Asterisk

Brief items

Google's Browser Security Handbook

New vulnerabilities

aview: insecure tmp file usage

dovecot: improper permissions

drupal: multiple vulnerabilities

enscript: arbitrary code execution

firefox: multiple vulnerabilities

freeradius: symlink attacks

honeyd: insecure tmp file usage

jasper: multiple vulnerabilities

no-ip: arbitrary code execution

phpMyAdmin: sql injection via cross-site request forgery

povray: arbitrary code execution

roundcubemail: code injection

seamonkey: multiple vulnerabilities

tshark, wireshark: denial of service

uw-imap: buffer overflows, null pointer dereference