Asterisk Security Team
2011-Dec-08 22:47 UTC
[asterisk-users] AST-2011-013: 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 at 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.
Warren Selby
2011-Dec-08 23:05 UTC
[asterisk-users] AST-2011-013: Possible remote enumeration of SIP endpoints with differing NAT settings
On Thu, Dec 8, 2011 at 4:47 PM, Asterisk Security Team < security at asterisk.org> wrote:> Asterisk Project Security Advisory - AST-2011-013 > > ><snip>> 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. > >This seems very counter-intuitive for anyone that has their asterisk server on a public IP address and serves clients both behind and not behind NAT. I've always viewed it as the nat= setting inside the [general] context is for whether or not the asterisk server itself is behind a NAT, and then the nat= setting inside each [peer] definition is based on whether or not that particular peer / endpoint was behind nat or not. Have I viewed it incorrectly all this time? On that note, why have the nat= setting on peers in the first place if it's insecure / not recommended to have a setting that differs from the general nat= setting. I'm not trying to be smug, I'm generally curious about the reasoning behind taking this approach to deal with this security issue, instead of changing code somewhere (I'm not a programming, and thus have no idea how complicated such a change would be). -- Thanks, --Warren Selby, dCAP http://www.SelbyTech.com <http://www.selbytech.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20111208/bf3931e9/attachment.htm>
Barry Miller
2011-Dec-09 16:36 UTC
[asterisk-users] AST-2011-013: Possible remote enumeration of SIP endpoints with differing NAT settings
On Thu, Dec 08, 2011 at 04:47:37PM -0600, Asterisk Security Team wrote:> [...] > 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.I see that early this year, VOIPPACK (from the folks who brought us SIPVicious) announced "Additionally we improved vp_sipenumerate to be able to scan Asterisk servers regardless of the alwaysauthreject option". I'm guessing this is how they do it. VOIPPACK isn't free, so it's not as widely used as SIPVicious, but it seems to show that there's at least one exploit already out there. -- Barry