Inbound routes SECURITY BREAK

[topogigio]

If a tenant creates an inbound route with some condition, but NOT also the condition "destination number=XXX" that the "Destinations" always creates, it can receive every call for every other tenant (gateway)!

I tried to create in a tenant an inbound route that checks only the "caller_id_number". If I call the SIP trunk (gateway) of an OTHER TENANT, from that caller number, the inbound route is triggered and the call is answered by a tenant that does NOT OWN the gateway I called. So I call the phone number of a tenant, and the call is managed by an other tenant. Not a safe multi-tenant environment!

I think that is mandatory that Fusion will add some kind of condition or other feature to protect gateways.

 

[DigitalDaz]

I have never heard this before but I'm sure it will be fixed very quickly.

 

[ad5ou]

Dial plan creation by a tenant or anyone other than a super admin is dangerous.
The above example is pretty harmless compared to the damage that could be done.

Other than limiting who can create/edit dial plans, I can’t imagine an easy way to stop the problem noted. Dial plans in the public context don’t care which tenant a call is for until after the condition match.

 

[DigitalDaz]

Dial plan creation by a tenant or anyone other than a super admin is dangerous.
The above example is pretty harmless compared to the damage that could be done.

Other than limiting who can create/edit dial plans, I can’t imagine an easy way to stop the problem noted. Dial plans in the public context don’t care which tenant a call is for until after the condition match.

I agree with the original poster here. The Destinations option is available to admins so this absolutely needs mitigation. Immediately to mitigate this you can check in destination that a condition exists that checks condition for destination number exists. Inbound routes are a different ballgame but tenants do not have access to that and instead have access to destinations.

 

[topogigio]

You are right, but I think there is still a problem with the GUI. Also if I use an admin, and not a superadmin, and I create a Destination (and not an inbound route, that I cannot create using that kind of user), the route is created in the "public" context. So still I can "intercept" other tenants incoming calls, if I know a valid URI.

This is less than what I described in first post (that requires a superadmin), but still it seems not ok. I think that Fusion may always create rules in the context where I am, not public/traversal. At least if I am NOT a superadmin that has explicit selected this kind of rule.

 

[DigitalDaz]

No, the Destinations checks for duplicates so you cannot intercepts someone elses DID, that is the theory anyway. It looks like this may well need some work though.

 

[topogigio]

That's right
But why "Destinations" creates inbound routes in the public context instead of the tenant one?

 

[DigitalDaz]

Actually just checked this and Destinations has no facility to add multiple conditions, only inbound routes so there is no problem here so long as they cannot use wildcards. There should be no problem in the public context, as was pointed out above. The PBX does not know WHO the did belongs to until it has evaluated it.

 

[ad5ou]

I haven’t checked specific permissions but I feel an admin should be able to edit an existing destination via the drop downs but should not have access to create a new route/destination. If those permissions aren’t set that way, perhaps a bug or feature request is in order.

 

[DigitalDaz]

I haven’t checked specific permissions but I feel an admin should be able to edit an existing destination via the drop downs but should not have access to create a new route/destination. If those permissions aren’t set that way, perhaps a bug or feature request is in order.

Admins have always had a right to create a new destination. The original post referenced an issue that needed superadmin right, ie the outbound route. The Destinations look Ok as it checks for duplicates so you shouldn't be able to take another tenants number.

 

[Adrian Fretwell]

Just checked this on our v4.4.5 test box and found that an Admin user can add a destination like ^016\d+$ which may or may not hijack another domains inbound depending on the processing order. See my switch log output.

67827b87-b86d-4c59-91a1-98435ef8a950 Dialplan: sofia/external/01636xxxxxx@testlab.a2es.co.uk parsing [public->01246589xxx] continue=false
67827b87-b86d-4c59-91a1-98435ef8a950 Dialplan: sofia/external/01636xxxxxx@testlab.a2es.co.uk Regex (FAIL) [01246589xxx] destination_number(01623888xxx) =~ /^(01246589xxx)$/ break=on-false
67827b87-b86d-4c59-91a1-98435ef8a950 Dialplan: sofia/external/01636xxxxxx@testlab.a2es.co.uk parsing [public->01643888xxx] continue=false
67827b87-b86d-4c59-91a1-98435ef8a950 Dialplan: sofia/external/01636xxxxxx@testlab.a2es.co.uk Regex (FAIL) [01643888xxx] destination_number(01623888xxx) =~ /^(01643888xxx)$/ break=on-false
67827b87-b86d-4c59-91a1-98435ef8a950 Dialplan: sofia/external/01636xxxxxx@testlab.a2es.co.uk parsing [public->^016\d+$] continue=false
67827b87-b86d-4c59-91a1-98435ef8a950 Dialplan: sofia/external/01636xxxxxx@testlab.a2es.co.uk Regex (PASS) [^016\d+$] destination_number(01623888xxx) =~ /^(016\d+)$/ break=on-false
67827b87-b86d-4c59-91a1-98435ef8a950 Dialplan: sofia/external/01636xxxxxx@testlab.a2es.co.uk Action export(call_direction=inbound) INLINE
67827b87-b86d-4c59-91a1-98435ef8a950 EXECUTE sofia/external/01636xxxxxx@testlab.a2es.co.uk export(call_direction=inbound)

 

[DigitalDaz]

Destination accepts regex??!!!

 

[Adrian Fretwell]

Destination accepts regex??!!!

Yes it does in 4.4.5. I was surprised!

 

[DigitalDaz]

My understanding is that this is now fixed, certainly in master.

 

[Adrian Fretwell]

My understanding is that this is now fixed, certainly in master.

That is good news. Is there any speculation as to when we will see the next stable release? I haven't found any mention on the Fusion members area.

 

[DigitalDaz]

That is good news. Is there any speculation as to when we will see the next stable release? I haven't found any mention on the Fusion members area.

He fixed it about 5am his time, he has done something in stable but I am not sure what. He was out on his feet, I didn't want to interrogate him at that time of morning

 

[ad5ou]

[QUOTE="Is there any speculation as to when we will see the next stable release?[/QUOTE]

It has been mentioned in Monthly continuing education videos. No set date yet, but soon. He has a few features to build/finish before shifting branches.
I think he has said goal was October.

 

[DigitalDaz]

I think he has said goal was October.

I'll think January then

 

[markjcrane]

I sure hope it is sooner than January we are working hard to make it sooner.

 

[DigitalDaz]

@markjcrane Thanks for the fix.

For you guys, here is what Mark has done for this:

• Added a new permission under Category: Destinations Permission: destination_number this new permission is given to users in the superadmin group by default.
• Anyone that has permission to edit Destinations but doesn't have the destination_number permission will have read only access to the destination number.
• I removed default permission to add Destinations from users in the admin group because this would give them ability to add a Regex for the number and hijack other peoples calls.
• We already checked destination_numbers for duplicates to help with security but when the regex was added it could get around the duplicate and still be an issue.
• Changes applied to both 4.4 and Master branches.

As you can see, this has been applied to both branches.