Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Exploits-HackingTools
[Top] [All Lists]

[UNIX] IAX2 Channel Driver Resource Exhaustion Vulnerability

Subject: [UNIX] IAX2 Channel Driver Resource Exhaustion Vulnerability
Date: 1 Aug 2007 09:27:12 +0200
The following security advisory is sent to the securiteam mailing list, and can 
be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html 

- - - - - - - - -



  IAX2 Channel Driver Resource Exhaustion Vulnerability
------------------------------------------------------------------------


SUMMARY

The IAX2 channel driver in Asterisk is vulnerable to a Denial of Service 
attack when configured to allow unauthenticated calls. An attacker can 
send a flood of NEW packets for valid extensions to the server to initiate 
calls as the unauthenticated user. This will cause resources on the 
Asterisk system to get allocated that will never go away. Furthermore, the 
IAX2 channel driver will be stuck trying to reschedule retransmissions for 
each of these fake calls forever. This can very quickly bring down a 
system and the only way to recover is to restart Asterisk.

DETAILS

Vulnerable Systems:
 * Asterisk Open Source versions 1.2.20, 1.2.21, 1.2.21.1, and 1.2.22
 * Asterisk Open Source versions 1.4.5, 1.4.6, 1.4.7, 1.4.7.1, and 1.4.8
 * AsteriskNOW pre-release beta6
 * Asterisk Appliance Developer Kit version 0.5.0
 * s800i (Asterisk Appliance) version 1.0.0-beta5 up to and including 
1.0.2

Immune Systems:
 * Asterisk Open Source version 1.2.23 and version 1.4.9
 * AsteriskNOW Beta6
 * Asterisk Appliance Developer Kit version 0.6.0
 * s800i (Asterisk Appliance) version 1.0.3

Within the last few months, Digium made some changes to chan_iax2 to 
combat the abuse of this module for traffic amplification attacks. 
Unfortunately, this has caused an unintended side effect.

The summary of the change to combat traffic amplification is this. Once 
you start the PBX on the Asterisk channel, it will begin receiving frames 
to be sent back out to the network. Digium delayed this from happening 
until a 3-way handshake has occurred to help ensure that we are talking to 
the IP address the messages appear to be coming from. When chan_iax2 
accepts an unauthenticated call, it immediately creates the ast_channel 
for the call. However, since the 3-way handshake has not been completed, 
the PBX is not started on this channel.

Later, when the maximum number of retries have been exceeded on responses 
to this NEW, the code tries to hang up the call. Now, it has 2 ways to do 
this, depending on if there is an ast_channel related to this IAX2 session 
or not. If there is no channel, then it can just destroy the iax2 private 
structure and move on. If there is a channel, it queues a HANGUP frame, 
and expects that to make the ast_channel get torn down, which would then 
cause the pvt struct to get destroyed afterwards.

However, since there was no PBX started on this channel, there is nothing 
servicing the channel to receive the HANGUP frame. Therefore, the call 
never gets destroyed. To make things worse, there is some code 
continuously rescheduling PINGs and LAGRQs to be sent for the active IAX2 
call, which will always fail.

In summary, sending a bunch of NEW frames to request unauthenticated calls 
can make a server unusable within a matter of seconds.

Resolution
The default configuration that is distributed with Asterisk includes a 
guest account that allows unauthenticated calls. If this account and any 
other account without a password is disabled for IAX2, then the system is 
not vulnerable to this problem. For systems that continue to allow 
unauthenticated IAX2 calls, they must be updated to one of the versions 
listed as including the fix below.


ADDITIONAL INFORMATION

The information has been provided by  <mailto:russell@digium.com> Russell 
Bryant, Digium, Inc..
The original article can be found at:  
<http://ftp.digium.com/pub/asa/ASA-2007-018.pdf> 
http://ftp.digium.com/pub/asa/ASA-2007-018.pdf



======================================== 


This bulletin is sent to members of the SecuriTeam mailing list. 
To unsubscribe from the list, send mail with an empty subject line and body to: 
list-unsubscribe@securiteam.com 
In order to subscribe to the mailing list, simply forward this email to: 
list-subscribe@securiteam.com 


==================== 
==================== 

DISCLAIMER: 
The information in this bulletin is provided "AS IS" without warranty of any 
kind. 
In no event shall we be liable for any damages whatsoever including direct, 
indirect, incidental, consequential, loss of business profits or special 
damages. 




<Prev in Thread] Current Thread [Next in Thread>
  • [UNIX] IAX2 Channel Driver Resource Exhaustion Vulnerability, SecuriTeam <=