Tag Archives: Asterisk

7 Asterisk VoIP Security Advisories Issued

Asterisk logoThe Digium / Asterisk Security Team has obviously been extremely busy ensuring that Asterisk is as secure as possible given that yesterday they released 7 security advisories, although only one of them (AST2014-16) was rated as “Critical”.  The others are rated as “Moderate” or “Minor” – but still are good reasons to upgrade to the latest versions of Asterisk.  The list of advisories is:

The issues are all fixed in the latest versions of Asterisk:

  • Asterisk Open Source 1.8.32.1, 11.14.1, 12.7.1, 13.0.1
  • Certified Asterisk 1.8.28-cert3, 11.6-cert8

Kudos to the Digium/Asterisk Security Team for the work they do in keeping Asterisk secure – and also for their openness in reporting the issues publicly!

2 Asterisk Security Vulnerabilities Could Lead To Remote Crashes

Asterisk logoThe great folks on Digium’s security team published two security advisories this week that could lead to remote crashes of an Asterisk server.

The first, AST-2013-004, Remote Crash From Late Arriving SIP ACK With SDP, has this description:

A remotely exploitable crash vulnerability exists in the SIP channel driver if an ACK with SDP is received after the channel has been terminated. The handling code incorrectly assumes that the channel will always be present.

The second, AST-2013-005, Remote Crash when Invalid SDP is sent in SIP Request, has this description:

A remotely exploitable crash vulnerability exists in the SIP channel driver if an invalid SDP is sent in a SIP request that defines media descriptions before connection information. The handling code incorrectly attempts to reference the socket address information even though that information has not yet been set.

My one critique of the security advisories is that they don’t contain any “mitigating circumstances” that explain the circumstances under which the vulnerabilities could be exploited. For instance, it would seem from reading the documents that at least in the first case there would need to be a successful SIP connection established first – and then ended – before the packet could be received that would cause the crash. Unfortunately I don’t personally know Asterisk’s internals well enough to comment on that.

Regardless, the fix here is to upgrade to the latest versions of Asterisk as documented in the security advisories.

Kudos to the Digium folks for issuing these advisories and continuing their clear process of letting people know about security within Asterisk.

Digium Releases 3 Asterisk Security Advisories

Asterisk logoThis week Digium released three security advisories allowing remote authenticated sessions to either crash an Asterisk server or escalate user privileges.  The advisories are:

In all cases the solution is to upgrade to the latest releases of Asterisk Open Source (1.6.2.24, 1.8.11.1 or  10.3.1 ) or Asterisk Business Edition (C.3.7.4).

 

Asterisk Remote Crash Vulnerability in SIP Channel Driver

Asterisk

The folks over at the Digium security team today released security bulletin AST-2011-012 for a remote crash vulnerability in the SIP channel drive. For info about the attack, they state only:

A remote authenticated user can cause a crash with a malformed request due to an uninitialized variable.

An assumption from this statement would be that an UNauthenticated user could not carry out this attack… but I admit to not personally knowing the SIP channel driver of Asterisk enough to be able to stand behind this conclusion.

Regardless, updates have been released in the form of new versions 1.8.7.1 and 10.0.0-rc1.

Two Asterisk Security Advisories, Including One Critical Remote Vulnerability

The Digium security team issued two security advisories this week for Asterisk:

The second one, AST-2011-004, is the far more concerning because it indicates that a remote attacker could connect to an Asterisk system and cause it to crash.

The solution, in both cases, is to upgrade to the latest Asterisk releases.

UPDATE: 3/18/11 – Olle Johansson pointed out on Twitter:

Either upgrade or do not use SIP/TCP. Installations only using SIP/udp is not affected and do not need to upgrade.

Thanks for the clarification, Olle.

Dialstring injection vulnerability in Asterisk

Olle Johansson recently alerted us that there is a “dialstring injection” vulnerability in Asterisk. As Olle notes in his post about the vulnerability, this is similar to a SQL injection attack against a database where there is not enough filtering being done on strings that are being input to the system. Olle writes:

Many VoIP protocols, including IAX2 and SIP, have a very large allowed character set in the dialed extension, a character set that allows characters that are used as separators to the dial() and the queue() applications, as well as within the dialstring that these applications send to the channel drivers in Asterisk. A user can change the dial options and dial something we should not be able to dial in your system. This article describes the issue in more detail and gives you some help on how to avoid this causing trouble in your Asterisk server.

Olle goes on to explain the issue in more detail and explain about how input from VoIP channels should be filtered before being sent to the Asterisk ‘dialplan’ for processing. He includes a plea for assistance:

We need everyone involved to pump this information out in all the veins that runs through the Asterisk eco-system. Audit your dialplans, fix this issue. And do it now. Everyone that runs a web site with dialplan examples – audit your examples, fix them. Everyone that has published books – publish errata on your web site. Please help us – and do it now.

Olle’s article goes into much more detail and offers suggestions for what you can do to protect your system. If you are an Asterisk administrator, it’s definitely an issue you should investigate and act on.


If you found this post interesting or helpful, please consider either subscribing via RSS or following VOIPSA on Twitter.


Asterisk Security Advisory – RTP Remote Crash Vulnerability

asterisklogo.jpgEarlier this week, the security team at Digium released Asterisk Projects Security Advisory AST-2009-010 identifying an interesting attack where an attacker can send a malformed RTP packet within the RTP stream and crash the Asterisk system. The fix identified is to upgrade to the latest version of Asterisk.

My one bit of feedback to the folks at Digium would be that their advisories do not provide any information about mitigating circumstances. (Would be great if they could add such a section.)

In this particular case, I confirmed with Digium that this advisory only affects systems that allow public unauthenticated calls over an IP connection. So Asterisk systems that are only used for PSTN connectivity – or only allow authenticated connections/calls – are not vulnerable to this attack. My Digium contact indicated:

The attacker would have to be capable of negotiating a RTP stream and then sending the Comfort Noise payload within the stream to crash the system.

He also indicated that IAX connections are not affected as they do not use RTP streams. So basically you are only vulnerable to this attack if you allow anyone to connect to your Asterisk box over an IP network presumably using the SIP protocol.

If you aren’t allowing those connections, it’s probably still good to upgrade… but you are apparently not vulnerable to the specific attacks outlined in the advisory.

Asterisk Security advisory – Information leak in IAX2 authentication

asterisklogo.jpgIf you are an Asterisk user, you should be aware that Digium has released AST-2009-001 Information leak in IAX2 authentication. The description is:

IAX2 provides a different response during authentication when a user does not exist, as compared to when the password is merely wrong. This allows an attacker to scan a host to find specific users on which to concentrate password cracking attempts.

The workaround involves sending back responses that are valid for that particular site. For example, if it were known that a site only uses RSA authentication, then sending back an MD5 authentication request would similarly identify the user as not existing. The opposite is also true. So the solution is always to send back an authentication response that corresponds to a known frequency with which real authentication responses are returned, when the user does not exist. This makes it very difficult for an attacker to guess whether a user exists or not, based upon this particular mechanism.

Digium classifies it as a minor security issue and notes in the advisory that patches are available.

Technorati Tags:
, , , ,