Hacked account resulting in high bills

[noord]

Hello all,

Not sure if this forum is intended only for AV-reports or also general questions about security. If it's in the wrong place, feel free to move this to the correct forum


Unfortunately, the 3CX account of a user has been compromised.
That allowed the hackers to login to WebClient and place outbound calls to expensive numbers.

For that client, we had outbound rules in place of course and limited calling to almost all foreign countries.
Unfortunately, there was an issue with our rules and the acceptance of our upstream provider. I thought I'd share this here, perhaps someone else has the same not-working-as-expected configuration. And also the gather some more best-practices and tips and suggestions from others here.

So, we had calls to almost all foreign countries blocked.
If someone called 001xxxx from the WebClient, 3CX would block it because it identifies the call as being to the United States (which is blocked for example).
If someone called +1xxx, 3CX would also block it
But, if someone dialled 1xxxx, 3CX does not recognize it as a call to a foreign number (US) and doesn't block it right away (which is fine and as it should be).
So, it goes down the outbound rules.
I had rules in place for numbers starting with '00', replace with a '+' and send to the carrier.
I had rules for numbers with length 7 (which would be a local number in the same city), don't strip, just add +31 20 xxxx (country code and area code). That way, people don't need to enter an area code if calling a local number. Many people are still used to that.
But then, I had a rule to pass anything else 'as is' to our trunk provider.
That's because sometimes 'strange' numbers also exist, for example 14xxx numbers which are used to call your local city administration. If you want to call the town hall of Amsterdam, you'd call 14 020.

However, there was an unexpected issue with this.
Our trunk provider, cm.com, accepts numbers as: +31201234567, 0031201234567 or 31201234567.
The first two forms are filtered by 3CX country codes-filter, but the latter is not.

So, this way, they were able to bypass the country filter and still make a call to another country.

There are a few things going on here:
1) We clearly should not have this last rule (the pass 'as is' to the trunk provider)
2) CM.Com should not add a '+' or '00' to any numbers passed to it as 31201234567, in my opinion.
2a) If I send a number in the form of 0201234567, it does go to Amsterdam correctly)
3) 3CX's country filter doesn't trigger when a number doesn't start with '+'or '00' but with the country code directly
4) In CM.Com it is possible to set-up a cost limit per month, but that limit is only calculated after a call ends. So in our case, the set-up 4 sim calls to an expensive number and let those connecions open for the maximum time allowed. I believe the default is 3 hours in 3CX. The number was around 5 euro per minute. So, 4 calls for 3 hours still gave us a bill of 3600 euro. Then the cost control of CM.Com kicked in and blocked further calls. But the damage had been done

So, the issue isn't really with 3CX, not really with CM.Com, not really with us, it just a very unfortunate combination of circumstances.
We were not aware the filter could be bypassed because we were unaware CM.Com would add a '+' or '00' to any numbers not start with '0', '+' or '00'.
Then the cost control only kicking in after a call ends and preventing new calls after that was also unexpected.
Fortunately, 3CX does limit calls to 3 hours by default

So I hope this post will prevent anyone from running into this.
And perhaps some form of 2FA can be implemented for the web client, that would be really useful. Even if people then lose their passwords somehow, it's a bit more difficult for hackers to log in. Or perhaps some kind of IP/Country filter could be implemented, only allowing logins from IP addresses registered to certain countries. Not 100% fool-proof of course but it's an extra layer.

 

[Ronald Lysmont]

Hi Noord,

Thanks for sharing this post. We are also using CM.com SIP trunks and I was also not aware of their call handling.

An extra 3CX security layer is not nice to have, it's a must.
* 2FA is almost a standard security item so 3CX development, get on with it!
* Outbound time limit should be easy to implement, even outbound call frequency
* Allowed Country/Region IP Access Protection should also be available

 

[AWS2P]

Well you should ask a better security to your SIP Provider , to follow end customer customs, block unusual hours and days of calls, block international destinations, block overcharged numbers , ecetera...

SIP provider should close a lot by default, and let go only what's allowed by customer

 

[bitn2]

I would check the users extension for a less secure password. You could do a lot by your self to secure the 3cx.

 

[noord]

I would check the users extension for a less secure password. You could do a lot by your self to secure the 3cx.

Yes, but this is all assuming a hacker has gained access to a password. It was written on a note, an e-mail account was 'hacked', doesn't matter how they got the users' password and whether or not it was strong.
They have access to a user account, how do we limit the (financial) damages they can do?
And I was primarily trying to warn other people to not make the same false assumptions I did

 

[bitn2]

One problem was your outgoing rule that is not correct. The other problem is the non secure hardware or password of your user so that it was possible to get it and use it for stuff like this. And yes, your provider should monitor expensive calls better to block this before it reaches that much money.

 

[noord]

Yes, I also have a disussion with the trunk provider about this.
For example. the emergency number is 112.
If I were to send it to them like that, would they assume I mean phone number 12 in the United States?
And that's just one example, there are many 'strange' numbers in Europe/NL.
See this site for list: https://www.bellen.com/mobiel/telefooonnummers-in-nederland

So that's the main reason for our 'catch all' rule. There are all kinds of 'strange' numbers and we don't want to create many rules and maintain them all across all instanced. And if they didn't prepend a '+', then it would have all worked out. We had a different trunk provider before and they never added / prepended anything. So a call would simply fail then if the number was invalid.

Thinking about this brings me to a feature request:
It would be really great if we were able to export and import outgoing calls-rules in 3CX
Of course, the trunk provider might have a different name on a different instance, so when importing 3CX could say 'hey, I see provder ABC in your import, do you mean provider AB because that's what I have' but it would save us a lot of work

 

[bitn2]

In Germany there are also a lot of different numbers. But its not a problem to send the numbers with 4 outgoing rules with +49 in front or 0049 (depens on the provider). Emergency numbers are set in the pbx and service numbers like 0800 are in the countries rules..

 

[noord]

Yes, that's a bit of a problem.
For example, we have the area code (0)180 in NL.
So I can call subscriber 123456 in that area with +31 180 123456 (spaces for readability).
But, we also have the number 1801 you can dial, it's for number information

If I just enter that number on eg. my cell phone or landline, it works fine.

If I want to send that through our trunk provider, I cannot send it as 1801 because they assume I mean some number in the US. They prepend a + because the number itself does not start with a 0 or a +.

So, I need to to prepend +31 myself. That's fine, so I'll send +31 1801 (spaces for readability).
But that's almost similar to +31 1801 23456
This is just one example, there are many more.

That brings me back around to the face that I think, a trunk provider should never prepend a + or 00 by itself. 3CX doesn't prepend that by default either. If someone calls 123456789, the call just fails and doesn't get routed to the US because 3CX thinks, 'hey, let's add a '+'

 

[SteveITS]

export and import outgoing calls-rules

vote here: https://www.3cx.com/community/threads/the-ability-to-import-and-export-outbound-rules.69225/

 

[leejor]

If I want to send that through our trunk provider, I cannot send it as 1801 because they assume I mean some number in the US. They prepend a + because the number itself does not start with a 0 or a +.

Special short (local) numbers are, of course going to be handled differently by a national provider. However, when using SIP, the digits are not collected one at a time, as it was (is) with PSTN providers. The digits are sent, and dealt with, as a whole. If your provider requires that short numbers are prefixed with a + and countrycode, then that is easily accomplished in the outbound rules without allowing international calls to use the same rule.

It may require additional rules to cover these special numbers.
For 1801, for example...the outbound rule would specify the complete number, 4 digits in length, then add the required prefix before sending. If this rule were near the top of the list, then someone dialing 1801...(and additional digits), then the number would not match that rule and the search would continue down the list.

Remember the number is examined as a whole, not a digit at a time.

I believe that it was mentioned earlier about talking to your provider regarding limits on placed calls. Many providers allow you to set the maximum per minute rate, blocking anything to numbers with an exorbitant charge. One would think that would be a default setting, but....

 

[noord]

Remember the number is examined as a whole, not a digit at a time.

Thank you for your extensive reply.
Yes, I know numbers are examined as a whole, not digit-by-digit.
But what I meant to say was, with what the trunk provider is doing, we need a whole lot of rules.

For example, 1801 is a valid local number.
So, I need a rule that says 'starts with' 18 and length '4'.
But there are also numbers staring with 14 and they can have a length of 4, 5 or 6 digits.
So, that's 3 additional rules. And I can go on for quite a while.

That's why I took the shortcut of just sending a number 'as is' with a 'catch-all' rule and let the trunk provider figure it out.
But, as it turns out, they add + to any number they don't immediately recognise.
So I need to know if they also accept a call to '112' as '+31112' and a call to 1800 as '+311800'. Then, I can just have one rule that prepends +31 to any number not starting with either 00 or +. I have of course already asked them this (and could try it of course, but I can't possible try all possible numbers - I don't want to try 112 for example), so I'll await their reply first.

But this is what I meant to say. And creating a lot of rules isn't that bad, but then I would like the ability to export and import them to other instances

 

[leejor]

Unfortunately, as you've discovered, creating a catch-all rule can leave the PBX open to unintended consequences. If possible, it is better to "weed out" any "special numbers" in the upper regions of the outbound rules. Many, starting with the same two digits, and with the same number of digits, can probably be combined into a single rule.