Possible remote enumeration of SIP endpoints with differing NAT settings
Asterisk Project Security Advisory - AST-2011-013
Product Asterisk
Summary Possible remote enumeration of SIP endpoints with
differing NAT settings
Nature of Advisory Unauthorized data disclosure
Susceptibility Remote unauthenticated sessions
Severity Minor
Exploits Known Yes
Reported On 2011-07-18
Reported By Ben Williams
Posted On
Last Updated On December 7, 2011
Advisory Contact Terry Wilson <twilson@digium.com>
CVE Name
Description It is possible to enumerate SIP usernames when the general
and user/peer NAT settings differ in whether to respond to
the port a request is sent from or the port listed for
responses in the Via header. In 1.4 and 1.6.2, this would
mean if one setting was nat=yes or nat=route and the other
was either nat=no or nat=never. In 1.8 and 10, this would
mean when one was nat=force_rport or nat=yes and the other
was nat=no or nat=comedia.
Resolution Handling NAT for SIP over UDP requires the differing
behavior introduced by these options.
To lessen the frequency of unintended username disclosure,
the default NAT setting was changed to always respond to the
port from which we received the request-the most commonly
used option.
Warnings were added on startup to inform administrators of
the risks of having a SIP peer configured with a different
setting than that of the general setting. The documentation
now strongly suggests that peers are no longer configured
for NAT individually, but through the global setting in the
“general” context.
Affected Versions
Product Release Series
Asterisk Open Source All All versions
Corrected In
As this is more of an issue with SIP over UDP in general, there is no
fix supplied other than documentation on how to avoid the problem. The
default NAT setting has been changed to what we believe the most
commonly used setting for the respective version in Asterisk 1.4.43,
1.6.2.21, and 1.8.7.2.
Links
Asterisk Project Security Advisories are posted at
http://www.asterisk.org/security
This document may be superseded by later versions; if so, the latest
version will be posted at
http://downloads.digium.com/pub/security/AST-2011-013.pdf and
http://downloads.digium.com/pub/security/AST-2011-013.html
Revision History
Date Editor Revisions Made
Asterisk Project Security Advisory - AST-2011-013
Copyright (c) 2011 Digium, Inc. All Rights Reserved.
Permission is hereby granted to distribute and publish this advisory in its
original, unaltered form.
–
_____________________________________________________________________
– Bandwidth and Colocation Provided by http://www.api-digital.com –
asterisk-announce mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-announce
asterisk 1.8 outbound dialing
If you want to make outbound calls, there is a new alternative in asterisk 1.8 to the old asterisk call files.
You can now use the asterisk CLI command: channel originate
There are two ways to use this command. A call can be originated between a
channel and a specific application, or between a channel and an extension in
the dialplan. This is similar to call files or the manager originate action.
Calls originated with this command are given a timeout of 30 seconds.Usage1: channel originate <tech/data> application <appname> [appdata]
This will originate a call between the specified channel tech/data and the
given application. Arguments to the application are optional. If the given
arguments to the application include spaces, all of the arguments to the
application need to be placed in quotation marks.Usage2: channel originate <tech/data> extension [exten@][context]
This will originate a call between the specified channel tech/data and the
given extension. If no context is specified, the ‘default’ context will be
used. If no extension is given, the ’s’ extension will be used.
For a more complete outbound dialer with predictive, progressive functionality, check here
Execute linux shell command from asterisk shell
This is a quick tip to execute a linux shell command from asterisk shell.
Just put an exclamation point (!) before your command :
*CLI> !date
Fri Nov 4 20:33:00 EDT 2011
How does asterisk match sip users/peers in sip.conf
After setting up sip users or peers in sip.conf and making calls, you may wonder why asterisk either reject your call or send it to default context.
When asterisk receive new sip session, here is how it tries to see which user or peer in sip.conf the call belongs to:
1. Asterisk checks the SIP From: address username and matches against names of devices with type=user
The name is the text between square brackets [name]
2. Asterisk checks the IP address (and port number) that the INVITE
was sent from and matches against any devices with type=peer
Note that type=friend equals both user and peer.
So, you may want to run “sip set debug on” to see what the other end is sending in the From field.
You would then have to setup the right [name], the right host and defaultip.
Check also insecure field.
;insecure=port ; Allow matching of peer by IP address without matching port number
;insecure=invite ; Do not require authentication of incoming INVITEs
;insecure=port,invite ; (both)
Asterisk dynamic conf files
Some times, you want your configuration file to be generate dynamicly from an external process for exemple.
To do so, you can use the #exec directive in the configuration file.
First, active execincludes in /etc/asterisk/asterisk.conf
vim /etc/asterisk/asterisk.conf
execincludes = yes
Then in your configuration file add:
#exec /usr/bin/config_generator.sh
config_generator.sh can be written on any program and need to be executable.
You can a
Asterisk mixmonitor cmd
Today, in asterisk 1.6, we will see what the MixMonitor Application does and in which context you can use it. What may be usefull are:
* MIXMONITOR_FILENAME variable will contain the full recording path at the end of the cmd
* Option ‘a’: Can be use if the file you want to record to already exists. It will be overwrite without this option. If you specify the ‘a’ option, it will be append instead.
* Option ‘b’: Will wait for the call to be bridge before start the recording
* You can adjust volumes from ‘-4′ to ‘4′ using the V(x) or v(x) for spoken and heard
* When the recording is over, the command specified in the ‘command’ parameter will be call.
-= Info about application ‘MixMonitor’ =-
[Synopsis]
Record a call and mix the audio during the recording. Use of StopMixMonitor
is required to guarantee the audio file is available for processing during
dialplan execution.[Description]
Records the audio on the current channel to the specified file.
${MIXMONITOR_FILENAME}: Will contain the filename used to record.[Syntax]
MixMonitor(filename.extension[,options[,command]])[Arguments]
filename
If <filename> is an absolute path, uses that path, otherwise creates
the file in the configured monitoring directory from “asterisk.conf.”
options
a: Append to the file instead of overwriting it.
b: Only save audio to the file while the channel is bridged.
NOTE: Does not include conferences or sounds played to each bridged
party
NOTE: If you utilize this option inside a Local channel, you must
make sure the Local channel is not optimized away. To do this, be sure
to call your Local channel with the ‘/n’ option. For example: Dial(Lo
cal/start@mycontext/n)
v(x): Adjust the *heard* volume by a factor of <x> (range ‘-4′ to
‘4′)
V(x): Adjust the *spoken* volume by a factor of <x> (range ‘-4′ to
‘4′)
W(x): Adjust both, *heard and spoken* volumes by a factor of <x>
(range ‘-4′ to ‘4′)
command
Will be executed when the recording is over.
Any strings matching ‘^{X}’ will be unescaped to ${X}.
All variables will be evaluated at the time MixMonitor is called
Error: missing /dev/dahdi
Another system another dahdi error.
This time I’m under CentOS. After building dahdi as usual without problem, when I try to run
service dahdi restart
I get the following error after a lot of missed modules
Error: missing /dev/dahdi!
After a lot of research, I found out that I was using kernel-PAE by running
`uname -r` because of 64 bits server.
And the source installed was not the right one.
So, you should install
yum install kernel-PAE-devel kernel-devel kernel-headers
Then, make sure that your build link in “cd /lib/modules/`uname -r`” directory points
to the right kernel source directory.
In my case, I have at the finish
[root@fonivadev /]# cd /lib/modules/`uname -r`
[root@fonivadev 2.6.18-194.32.1.el5PAE]# ls -l build
lrwxrwxrwx 1 root root 45 Jan 13 23:33 build -> /usr/src/kernels/2.6.18-194.32.1.el5-PAE-i686
[root@fonivadev 2.6.18-194.32.1.el5PAE]#
Now, go back in dahdi source directory and
make clean
make all
make install
Dealing with IRQ on E1/T1/Pri
Sometimes, you may run into weird quality problems when having a digium card.
This may include random drop calls, cuts in the calls etc …
This may have something to do with the IRQ sharing on your server. Please make sure that the digium card has it own dedicated IRQ interupt
To do so, run:
lspci -bvvv
This will show all hardware on your server as well as their IRQ number. If your digium card has the same IRQ with another hardware, you may be in trouble.
There are some solutions:
1. Disable or remove the other hardware (like USB) if you don’t use it.
2. Reboot your server and go in the BIOS to see if you have an option to setup IRQ
3. Change the digium hardware slot and see if that fix the problem
How to show all asterisk command during build
Since asterisk 1.4.X, you may notice that when building, it shows something like :
[CC] app_dial.c -> app_dial.o
Somes may want to see the asterisk full command and see what is being linked. To do so, run
NOISY_BUILD=on make install
You do not appear to have the sources for the `uname -r` kernel installed.
So, this maybe the first error you have when trying to build dahdi.
On CentOS, to fix it, it is simple.
First update yum
yum update
yum upgrade
Know your kernel version
uname -r
Search the package kernel-devel right for your version and install it
yum install kernel-devel kernel-headers
Goto to /lib/modules/ directory
cd /lib/modules/`uname -r`
ls -l
If you see a broken build link out there. Point it to the new installed kernel source in /usr/src/
ln -s /usr/src/kernels/(your-kernel-source-dir) build
Reboot your machine
Now, you should be able to build your dahdi sources.
Enjoy
Our sponsors
