[asterisk-users] AST-2011-013: Possible remote enumeration of SIP endpoints with differing NAT settings

[Warren Selby]

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>