jtodd December 6th, 2008
The folks at IC3 (Internet Crime Complaint Center) have issued a warning about “vishing” (telephony identity fraud) and Asterisk. The nature of the warning is extremely vague, and has left us guessing as to what the exact issue is that they reference and how Asterisk is involved. Digium nor anyone else involved with OSS Asterisk to my knowledge has not been contacted by the FBI or the IC3 (a division of the FBI) on this topic, so much of what we know is speculation at this point. Digium believes at this point that this warning was as a result of security issues that probably have nothing to do with Asterisk in specific, but are more general, such as some sites using poor password choices on VoIP accounts. It is possible that this is a re-hash of an earlier security issue that was resolved in March, or perhaps of a totally separate set of security issues which are unknown to us.
We’re concerned that the FBI has issued this warning without specific details and without contacting anyone involved with the project that we know of – Digium would be a natural choice. Typically, Law Enforcement Agencies would contact vendors or OSS project leads directly or via a CERT clearinghouse before posting publicly. We’ve sent emails and left frankly worded voicemails with whatever voicemail boxes we could find yesterday evening, but there’s been no reply as of yet – I’ll post an update when we hear from them. If it’s an old issue, then it’s probably solved, but the posting is not particularly clear and has left us a bit confused.
We believe (but can’t be sure) that the warning references a bug (AST-2008-03) that was discovered in March of this year. That bug allowed in some cases unauthorized callers to make calls through an unprotected “context” in Asterisk. Due to the nature of the bug there was fairly limited exposure – it would have required a fairly unusual set of configurations to permit fraud, and there was both a simple config file change that would provide protection, as well as an actual patch to the code which we have every reason to believe has been widely implemented by the very proactive Open-Source community using Asterisk in production environments. The bug didn’t allow arbitrary setting of caller ID, and would only work in a limited set of circumstances that personally I think would be unusual, though possible.
Despite there being a previously resolved bug in Asterisk which may have been an issue, it may be the case that the FBI has latched on to symptoms of another security matter and mis-diagnosed it as Asterisk-specific. There has been a recent upswing in fraudulent, malicious, or “vishing” calls through SIP systems in general due to poor security behaviors and password control. This isn’t symptomatic of any problem with Asterisk – it’s equivalent to people setting their email password to be the same as their username, or some other easily-guessed string. If you use a SIP client on the public Internet without VPN or firewall rules, and your password is less than 7 digits and doesn’t have any numbers, digits, or symbols in it, you’re probably more vulnerable than someone who has a stronger passphrase. There are people who will try to “brute-force” passwords on SIP accounts by guessing thousands of possible password variations, and the simpler the password the more likely it is to be compromised. This is just common sense, and isn’t reflective of Asterisk or any particular system – it is a human-factors issue. There have been reports of this type of attack happening with more frequency, with attackers then posing as banks or other “trusted” agencies once they have obtained a valid password on a victim’s SIP account. Even in these circumstances, the caller-id of the perpetrator is typically set to be the caller ID of the victim, so it would not be an advantage other than for cost and traceability for the visher to use these methods for impersonation – caller ID would not be effected, and this is functionally equivalent to someone stealing and using someone else’s cellphone.
Sorry for the fuss, and I suspect this is just a tempest in a teapot. Use good passwords, keep your packet filters up, and I’ll update things here as we hear more.
[UPDATE 2008-12-06 16:20 CST]
As we had surmised, the warning from the IC3/FBI on Friday was just a re-hash of a bug that was fixed back in March of this year. I was in touch with the agent in charge of this release this morning (after contact attempts on Friday failed) and he understood quickly that the wording was lacking in ways that created questions in the minds of readers, and this was being amplified by bloggers who more clearly outlined the set of questions raised by the advisory/release. To his credit, the IC3 agent quickly pushed through a set of changes today to the posting which more specifically describes the issue, which indeed is the AST-2008-003 SIP guest permissions problem.
This bug was discovered and patched for 1.2 and 1.4 versions of the software, and 1.6 releases were not vulnerable. Simple changes to site-specific configurations typically would be all that would be required even on systems that did not get patched or upgraded. The bug that is described is relatively obscure, and was found by Jason Parker here at Digium. We didn’t know of any “in the wild” exploits back then, though of course there may be some now. I’m still somewhat surprised that anyone has been able to use this bug to the extent that they were able to mount “vishing” attacks. 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.
We understand that the intent of the original posting was in good faith, but apparently some details got lost on the way which made this into a press-worthy incident when it was merely a re-iteration of a known issue. We’re hoping that this type of problem isn’t repeated in the future, and we look forward to working more closely with any agency that has Asterisk-related questions or security concerns.
Hopefully, the lessons learned here by others are: 1) Use industry-standard communications procedures when talking about specific projects or software packages (ex: CERT, vendor communication), 2) Be very specific in postings about what the vulnerability is, especially if there is a pre-existing fix, 3) Don’t post things on Friday afternoon right before everyone leaves for the day, 4) If you post phone numbers on your site for contact, make sure they work. Hopefully, this was a single isolated case and the next time there are any questions about Asterisk there will be the chance to discuss the press releases with concerned law enforcement agencies before they hit the wires.