search

OpenLI-NZ / openli

Open Source ETSI compliant Lawful Intercept software
GNU General Public License v3.0
82 stars 25 forks source link

Packets missing while intercepting two LIIDs on the same call #35

Closed charbelMat closed 6 months ago

charbelMat commented 4 years ago

When two SIP targets belonging to two different LIIDs call each other, RTP packets are missing. This behaviour appeared many times with different scenarios where both LIIDs have a call. The library is working correctly and all packets are present for one LIID being intercepted with a non targeted SIP user. Is this related to the collector creating unique interception sessions or the provioner's config ? Thank you for your support and for this awsome Library.

salcock commented 4 years ago

Hi,

Thanks for reporting this issue. This isn't the first time I've heard about this bug, so it is definitely on my list of things to fix before the next release.

It'll definitely be a problem with the collector's VOIP sync thread not recognising that it needs to create multiple intercept sessions in that situation, rather than a configuration issue.

salcock commented 4 years ago

I have a few questions about your problem, just to make sure that I've replicated the bug correctly:

charbelMat commented 4 years ago

Hey @salcock , Thank you for your fast reply.

Thank you again!

salcock commented 4 years ago

Ok, in that case it is fairly obvious what is happening.

Based on advice I've had from network operators and the LEAs here in NZ, the target detection in OpenLI does not trust the "From:" field in the SIP headers. This field can easily be spoofed while still having the call succeed, so a suspicious user can change their "From:" header to avoid detection (or convince other people to change their "From:" to match the target, such that the collected evidence can be thrown out due to over-collection).

Instead, OpenLI relies on the presence of Proxy Authorization to determine the real identity of the user that is making an outgoing call. For most operators that we work with, this seems to work well -- their SIP sessions are all authenticated and the SIP packets are tapped at a location where the Auth fields are present. Our HI2 doesn't grab the initial "INVITE, 407, ACK" packets of the SIP stream, but LEAs seem OK with that.

In your case, the INVITE succeeds without requiring auth so the caller is never recognised as one of the targets.

I suspect that the solution to this problem will depend on the reason for the missing auth. Is this simply a case that there is no auth because both call endpoints belong to the same realm?

charbelMat commented 4 years ago

Ok now I can see why we have this issue. First, we are not using proxy auth => the problem with trusting the "From:" header. Second, both callers belond to the same realm. But I noticed in the library, and in this func specifically "check_sip_auth_fields", both cases are being tested, with and without proxy auth. But what I can't see is why the "From:" header is not being trusted with normal auth...

Thank you again for your valuable feebback!

quangvnm commented 4 years ago

Hi @salcock ,

It fact, the INVITE has associated Authorization field, if this field is missing, the caller will receive 401 Unauthorized status with the necessary information to authenticate.

e.g: caller A call B, passing by SIP server, there are two calls with different call ids:

So I asked myself if we can use the Authorization header in the flow, if there is nothing, fall back to "From" field?

salcock commented 4 years ago

Authorization is already intended to work as an alternative in the absence of Proxy-Auth (see https://github.com/wanduow/openli/blob/58229160d6ca45a6a5ea52d031f9363117d45c43/src/collector/collector_sync_voip.c#L537-L538 and https://github.com/wanduow/openli/blob/58229160d6ca45a6a5ea52d031f9363117d45c43/src/collector/sipparsing.c#L579-L617).

I will have to double check that code is working as intended.

The second part of this issue seems to be related to trying to intercept both legs of the SIP transaction, i.e A -> SIP server and then SIP server -> B. In the ETSI specifications (TS 102 232-5), it states that all parts of multi-leg call should be recognizable by having the same O fields in the SDP portion of the SIP messages. From the examples I've been given so far, this doesn't appear to be the case for your SIP traffic?

To explain further, what the standards think should happen is, assuming A is the intercept target:

A sends INVITE with Authorization field. OpenLI sees INVITE, matches Auth field contents against target info for A. OpenLI remembers Call-Id and SDP O from that INVITE, as belonging to the call. SIP server sends INVITE to B without Authorization field. OpenLI sees INVITE, cannot match against target info. OpenLI looks at Call-Id for INVITE. No match, because the call ID is unique for each leg. OpenLI looks at SDP O for INVITE. This matches because this should be unchanged between legs. OpenLI intercepts INVITE B as part of the intercept for A, based on the SDP O match.

Now, obviously there's a lot that can go wrong here. The biggest problem may be the assumption that SDP O is not going to change -- the examples in the standards only talk about a situation where the endpoints are using a SIP proxy. If your server is not really acting as a proxy, then maybe the assumptions don't work any more.

Alternatively, there could be bugs in any one of the above steps that are preventing the matching from occurring correctly.

I will try to look into this more when I have some time (again, the examples you've already provided are going to be very useful for this, so thank you!). But hopefully what I've said will help you understand what OpenLI is trying to do, even if it might not be doing it exactly right :)