[asterisk-dev] SIP, NAT, security concerns, oh my!

[Örn Arnarson]

One more thing that just came to mind;
Shouldn't alwaysauthreject be considered to be enabled by default for the
same reason?

My apologies if that is already the case.

Regards,
Örn
On Oct 21, 2011 11:24 PM, "Örn Arnarson" <orn at arnarson.net> wrote:

> Hello,
>
> I don't really have anything to add except from superficially -- just
> wanted to toss in my vote for which option to deal with this problem
> sounds the most appealing.
>
> In my opinion, option #3 sounds like a clear winner. From what I can
> tell from the historical background you wrote (which was a very
> interesting read, by the way), it seems like it should've been made
> the default behavior a long time ago anyway.
>
> Option #1 sounds like a really hard sell. Using UDP for SIP is such a
> norm that I can't remember encountering anyone who uses TCP apart from
> Microsoft Lync/OCS. Not to say that it's a bad idea at all, but once
> something has become a de-facto industry standard, it's hard to shift.
> I think this option would probably lead to most people ignoring the
> security issue.
>
> Option #2 also sounds like a hard one. If we assume that there will be
> some devices where this change will break their interoperability over
> certain NAT scenarios, it would be a cause of significant problems for
> people who I'm sure would much rather solve their security issues via
> firewalling or just ignoring them altogether. Additional security
> measures can be taken by most admins. Changing the code and
> re-compiling, or even getting the UA fixed by the manufacturer is a
> much harder task (or it may seem so to the person who has to perform
> it at least).
>
> Having the option to disable nat, and perhaps explaining the
> ramifications with comments above the sample entry, seems like the way
> to go to me. More versatility and more freedom for the user. Assuming
> that he knows what he's doing isn't such a bad thing, I think.
> Additionally,  I think having to disable something rather than enable
> is more likely to make you think about what it is you're disabling as
> well, so maybe it's enough. Especially if you do it in [general].
> Maybe that's just me though.
>
> Now, as to whether or nat=yes is always set on *my* definitions, then
> the answer is no. Why? Because I never bothered to actually check
> whether what nat=yes did was something that was desireable for all
> clients or not. All I knew was that if I had problems with NATed
> clients, this would usually fix it. I assumed nat=yes meant breaking
> some RFC behavior to try to satisfy shitty ALGs. Furthermore, as it
> isn't enabled by default I thought it could possibly have some
> detrimental effect on non-NATed UAs. I think maybe the name is a bit
> misleading.
>
> Anyway, sorry if this isn't helpful or relevant at all, but it seemed
> like you were basically asking for feedback from anyone with an
> opinion in the matter.
>
> Regards,
> Örn Arnarson
>
> On Fri, Oct 21, 2011 at 10:52 PM, Kevin P. Fleming <kpfleming at digium.com>
> wrote:
> > Sorry in advance for the length of this message... I've intentionally
> > included quite a lot of background information so that we can hopefully
> be
> > able to discuss this issue rapidly and reach consensus.
> >
> > Recently, a potential security issue was brought to our attention: it has
> > existed in (probably) every version of Asterisk that included chan_sip.
> It's
> > not something we'd classify as 'critical' or even 'major', but it is a
> > concern we want to address. Terry Wilson has spent some time
> investigating
> > it, and then he and I spent some time over the last couple of days
> thinking
> > about how (or if) it can be addressed.
> >
> > The essence of the problem is this: it is possible under some
> circumstances
> > for an attacker to be able to enumerate (discover) the names of SIP peers
> > (and possibly users) defined on an Asterisk system. If they can discover
> the
> > valid peer names, they can then focus password-guessing attacks on those
> > names, which increases their chances of being able to gain access to the
> > system. Generally speaking we've tried to make changes to Asterisk to
> remove
> > this type of 'information disclosure' vulnerability, in order to help
> > Asterisk users keep their systems as secure as possible.
> >
> > Unfortunately in this case, we can't solve the problem without removing a
> > useful feature of chan_sip. Here's why:
> >
> > According to RFC 3261, when Asterisk (acting as UAS) receives a SIP
> request
> > from another SIP entity (acting as UAC), any responses that Asterisk
> > generates must be sent back to the IP address that the request was
> received
> > from, but to the *port number* specified in the top-most Via header
> included
> > in the request (this is important: they are *NOT* sent back to the port
> > number the request was received from).
> >
> > For most SIP clients, who are not sending their SIP requests across NAT
> > devices, this is not a problem; they'll send their requests from port
> 5060,
> > and expect responses on port 5060 (and they'll either explicitly specify
> > port 5060 in that top-most Via header, or they'll leave it out and let
> the
> > RFC-specified default take effect). There could be some SIP clients out
> > there who send their requests from one port (port A), but want to receive
> > responses on a different port (port B). In this case, the top-most Via
> > header will include port B, not port A. In our experience, this is
> extremely
> > uncommon, but it is RFC compliant behavior.
> >
> > When NAT devices enter the picture, though, things get more complicated
> (as
> > they always do). Going back to the 'normal' SIP clients, that send
> requests
> > from, and expect responses on, the same port... now they have a problem.
> If
> > they send their request from port 5060, and expect responses on 5060,
> their
> > top-most Via header will reflect that. However, when the request crosses
> the
> > NAT on its way to the UAS, it will appear to have been sent from a
> different
> > IP address and port number than the UAC sent it from (by definition...
> > network address translation). Asterisk (the UAS) will respond back to the
> IP
> > address that the NAT used to send the request, but it will *NOT* respond
> to
> > the port number the NAT assigned; it will respond to the port number in
> the
> > top-most Via header. Unless the NAT device just happened to assign the
> same
> > port number (and some NAT devices will attempt to do that), or if the NAT
> > administrator has setup a static mapping for that port number, the
> response
> > will be lost... it will arrive at the NAT device, it won't match the port
> > mapping established when the request passed through, and the NAT device
> > won't forward it.
> >
> > This dilemma was identified long ago (over 8 years), and an additional
> RFC
> > was published: RFC 3581. This RFC allows the 'rport' parameter to be
> added
> > to Via headers; this allows UACs who are aware that their requests may be
> > crossing a NAT device (or even if they aren't aware, but just want to be
> as
> > safe as possible) to indicate to the UAS that receives their request that
> > the UAS should respond to the port that the request was received from,
> *NOT*
> > the port listed in the top-most Via header. Some people would say that
> this
> > is how SIP should have worked from the beginning, and that the extraction
> of
> > *only* the port from the top-most Via header never made any sense at all
> (I
> > would personally agree with those people), but history is what it is. In
> > addition to this behavior change, the 'rport' parameter also indicates
> that
> > the UAS should report back to the UAC the 'perceived' port number; this
> is
> > useful, but is not part of the problem being discussed here.
> >
> > Asterisk supports RFC 3581, and if a UAC includes 'rport' in its top-most
> > Via header, Asterisk will indeed respond to both the IP address *and*
> port
> > number that the request was received from.
> >
> > However (and here's where we run into trouble), there are some (maybe
> many)
> > SIP UAs out there that cannot (or just do not) include 'rport' in the
> > top-most Via headers of their requests. Because of this, these UAs can be
> > difficult to use behind a NAT device (unless the NAT is configured
> specially
> > as outlined above), because Asterisk can't deliver responses to the UA
> (port
> > number mismatch). In order to make these devices 'work', Asterisk gained
> a
> > 'nat' configuration option many, many years ago that, if set to 'yes' (it
> > defaults to 'no') tells chan_sip to act *AS IF* the UAC had included
> 'rport'
> > in its top-most Via header, even if it didn't. This does in fact solve
> the
> > problem; responses can now be delivered to the UAC, and the fact that
> > Asterisk adds 'rport' to the Via header in the response is not harmful...
> > the UAC just ignores it.
> >
> > In later versions of Asterisk this configuration option gained some
> > additional behavior (enabling 'connection-oriented media' mode), but
> again,
> > that's not part of this issue. In recent versions, the value of this
> option
> > can even be specified as 'force_rport' to more clearly indicate the
> desired
> > behavior.
> >
> > Now we get to the crux of the problem: this 'nat' option can be set both
> at
> > the '[general]' level in sip.conf, and also for peers. This means, of
> > course, that they values can differ (and frequently they will, but not
> > because the administrator intended for them to differ). This means there
> are
> > four possible combinations, with possible different behaviors. For the
> > purposes of this discussion, let's assume that a UAC is sending a request
> > (the request type does not matter) that does *NOT* include 'rport' in its
> > top-most Via header. In addition, the UAC is purposely sending its
> request
> > from port A, but specifying port B in the top-most Via header. Let's also
> > assume there is a peer called 'alice' defined in sip.conf.
> >
> > Scenario 1: [general] nat=no, [alice] nat=no
> >
> > No problem here; the behavior of Asterisk will be the same regardless of
> > whether the request matches the 'alice' peer or not.
> >
> > Scenario 2: [general] nat=yes, [alice] nat=yes
> >
> > No problem here; the behavior of Asterisk will be the same regardless of
> > whether the request matches the 'alice' peer or not.
> >
> > Scenario 3: [general] nat=no, [alice] nat=yes
> >
> > Problem here; if the request matches 'alice', Asterisk will respond to
> port
> > A. If the request does not match 'alice', Asterisk will respond to port
> B.
> >
> > Scenario 4: [general] nat=yes, [alice] nat=no
> >
> > Problem here; if the request matches 'alice', Asterisk will respond to
> port
> > B. If the request does not match 'alice', Asterisk will respond to port
> A.
> >
> > As you can see, in both scenarios 3 and 4, if the attacker happens across
> a
> > peer name (or source IP address) that happens to match a peer defined in
> > sip.conf, and that peer's 'nat' setting differs from the general NAT
> > setting, the attacker will be able to notice the difference in response
> > pattern from when the request did not match any peer.
> >
> > So now we know what the problem is, and what causes it. I'll offer up
> some
> > possible solutions below, and ask for you all to think about this
> situation
> > and help us decide on the right course of action. The eventual goal here
> is
> > to produce a security advisory document telling users about the situation
> > and what they can/should do to try to mitigate it; we don't expect that
> > there is any solution that will solve the problem for all users.
> >
> > Option 1:
> >
> > Recommend that all users to switch to TCP (or TLS) for SIP
> communications.
> > If they have a version of Asterisk that supports TCP, and devices that
> also
> > support it, they can disable UDP support and avoid this problem entirely
> > (since TCP does not have these NAT traversal issues to deal with).
> >
> > Option 2:
> >
> > Change Asterisk to always act in 'force_rport' mode, period
> > (non-configurable). It is possible that there may be some SIP UAs that
> would
> > break if Asterisk did not respond to the port listed in the top-most Via
> > header, but it seems rather unlikely at this point. Such UAs would almost
> > never be able to be used successfully behind a NAT device. In addition,
> it
> > is remotely possible that there are some SIP UAs that will break if they
> see
> > 'rport=<xxxx>' in the Via header returned by Asterisk in its responses.
> >
> > Option 3:
> >
> > Allow 'force_rport' mode to be disabled, but change the default to enable
> > it, in all currently maintained branches (1.4, 1.6.2, 1.8, 10 and trunk).
> > This has the same caveats as Option 2, but at least if a user *does* have
> > one of these bizarre SIP UAs to deal with, they can set 'nat=no' for that
> > device after carefully considering the ramifications of the change.
> >
> > There may be other options to consider, but Terry and I were unable to
> come
> > up with any.
> >
> > So, questions for the assembled audience here:
> >
> > Do you have any other options for us to consider?
> >
> > Are you aware of any SIP UAs that actually *REQUIRE* "nat=no" to
> > interoperate with Asterisk?
> >
> > Do you *always* set "nat=yes" on your SIP peer definitions? Do you also
> set
> > "nat=yes" in the '[general]' section? If not, why not?
> >
> > --
> > Kevin P. Fleming
> > Digium, Inc. | Director of Software Technologies
> > Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype:
> kpfleming
> > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> > Check us out at www.digium.com & www.asterisk.org
> >
> > --
> > _____________________________________________________________________
> > -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> >
> > asterisk-dev mailing list
> > To UNSUBSCRIBE or update options visit:
> >  http://lists.digium.com/mailman/listinfo/asterisk-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111021/0c570477/attachment-0001.htm>