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

]]> http://www.astblog.com/2011/12/08/possible-remote-enumeration-ofsip-endpoints-with-differing-nat-settings/feed/ http://www.astblog.com/2011/11/04/asterisk-18-outbound-dialing/ http://www.astblog.com/2011/11/04/asterisk-18-outbound-dialing/#comments Sat, 05 Nov 2011 00:44:20 +0000 ruddy gbaguidi http://www.astblog.com/?p=156 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

Just put an exclamation point (!) before your command :

*CLI> !date
Fri Nov  4 20:33:00 EDT 2011

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)

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

* 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

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

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

[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

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