SIP Shoretel Hacked
So, we have had our shoretel hacked. Informed by our Comms provider.
Trying to get to the bottom of how, why, how to stop etc.
We had an international barr in place till the 28th Feb,
The hack occurred on the 1st and 2nd feb,
The comms co are not giving much away, so need help.
Thanks
Trying to get to the bottom of how, why, how to stop etc.
We had an international barr in place till the 28th Feb,
The hack occurred on the 1st and 2nd feb,
The comms co are not giving much away, so need help.
Thanks
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
They say its mailbox passwords being simple, however my view is that these should have been complete enough during deployment and also the system should enforce complexity right?
Nope, most systems do not enforce password rules for voice mail boxes, or end points. It's the administrators responsibility to know the environment they are in and enforce the correct security policy. Also, it's never a good idea for an administrator to enable dial through support.
ASKER
dial through support?
You get into a Voice Mail box an can then dial out again, also refereed to as dial through.
ASKER
ah thought as much. yes, i believe this was enabled... is this on each mailbox or COS?
Sorry, but I don't know. My Guess from many years ago is both...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Surely then any hack of a SIP system is either the ISP, Comms Installer or Shoretel themselves at fault?
ASKER
Here is the report from our comms co.:
On the 3rd February is was reported that companyA telephone lines had seen a large amount of outgoing International Calls placed over the weekend of the 1st and 2nd February.
A call was raised by the Comms Co. (job number J382979) at 12:02pm as it was suspected that the calls were fraudulent.
At 12:53, the call was picked up by User of Comms Co. technical support team, to establish how these calls were made through the ShoreTel system. At 13:10 the remote access was opened by Users at companyA.
We first ran a call detail report for the 1st and 2nd of February, and identified a large number of incoming calls to the Auto Attendant with a CLI of 100, 123. 10100, 1 etc. The number dialled was firstly a SiteB number labelled ‘Main Incoming’ and later again a SiteB Number labelled ‘User SiteB’ which both terminate on the SIP Trunk provision at SiteA. What appeared suspicious was that there were no outgoing calls logged to any international numbers in the CDR report. (These calls were probably calls for ‘probing’ purposes).
We checked the system for the standard security configurations that prevent voice mail phreaking (voicemail external call back, voice mail external notification and find me) and were confident that this was configured correctly to prevent voice mail break out, as the user group ‘voicemail notification’ had the relevant parameters including trunk to trunk, disabled. It was noted that 18 extensions were reported as having ‘simple’ passwords as a result of running the IDLint tool, and the list of the non-compliant extensions, was passed to User.
We then configured a DDI number to route to the Auto Attendant and tested the ability to break out from Auto Attendant, and we confirmed that break out was not successful.
The investigation was then moved on to the TMSncc log, which provides detailed information about all calls that arrive / made by the ShoreTel system.
Here it was identified that the calls were arriving at the ShoreTel and then being immediately routed out, and what was suspicious within the logs, the ‘dialled number (DNIS)’, was being shown as 8+0022891****** or 8+0035569******* or 9+00*********.
Our conclusion as to how the hacking occurred is as follows :-
The hackers were sending an Invite SIP message towards the Ingate SBC spoofing the TO:- address with initially 800xxxxxxxxxxxx (where xx is the international number)and later 900xxxxxxxxxxxx. It is assumed that the hackers were also spoofing the From:- IP address with Gamma’s signalling address (wan ip), (but cannot be proven as we don’t have a packet capture at the time the fraud was occurring), the Ingate SBC is correctly configured to allow traffic in ONLY from this address, so the Ingate saw this as trusted traffic and passed it on to the ShoreTel.
The Shoretel has 3 trunk groups configured two with an access code of 8 and one with an access code of 9, when the call was received by the ShoreTel it would see the 8 or 9 initial digit and would automatically access a new trunk from the relevant group, dial the remaining digits (International number) and tandem switch the incoming call to the outgoing call. The cost of the outgoing call would then be charged to Church House Investments.
The ability to route an incoming call directly to an outgoing call is provided by a feature called ‘Tandem Switching’, Tandem switching allows legacy voice systems to utilise a ShoreTel system for outbound dialing. The ShoreTel system supports both user-side and network-side PRI, allowing ShoreTel systems to flexibly support digital tie trunks to other systems. You can enable tandem trunking support for any PRI or SIP trunk group with a check box in ShoreTel Director. Tandem calls are associated with a user group for outbound trunk selection. Inbound calls recognized as tandem calls are redirected to an outbound trunk based on user group call permissions and trunk group access. When needed, a “dial-in prefix” can be specified that is prepended to digits collected on tandem calls. The concatenated set of digits is then used in outbound trunk selection for the tandem call.
After discussions with ShoreTel they have confirmed that there is an error in their documentation confusing “tandem trunking” with “trunk to trunk transfer” , see below;
“We recommend that the Tandem Trunking parameter be enabled (checked) otherwise transfers to external telephone numbers may fail via SIP trunks”
We have now disabled the Tandem Switching feature and Shoretel are going to amend the relevant documentation.
In conclusion there are 3 main points that allowed the fraudulent calls to be made:-
1. The Invite message towards the SBC contained a spoofed To:- address
2. The Invite message towards the SBC contained a spoofed IP address which was a trusted address as far as the SBC is concerned.
3. The Shoretel SIP trunk group had Tandem Switching allowed, which allowed automatic re-routing of the incoming call to the International destination.
My questions following this would be:
1. Who is to blame for the breach?
2. Who should be responsible for the cost of the hack?
3. Is their conclusion viable?
4. SHould they not be able to track exactly how and replicate the hack from logs at SIP provider side?
Thanks
On the 3rd February is was reported that companyA telephone lines had seen a large amount of outgoing International Calls placed over the weekend of the 1st and 2nd February.
A call was raised by the Comms Co. (job number J382979) at 12:02pm as it was suspected that the calls were fraudulent.
At 12:53, the call was picked up by User of Comms Co. technical support team, to establish how these calls were made through the ShoreTel system. At 13:10 the remote access was opened by Users at companyA.
We first ran a call detail report for the 1st and 2nd of February, and identified a large number of incoming calls to the Auto Attendant with a CLI of 100, 123. 10100, 1 etc. The number dialled was firstly a SiteB number labelled ‘Main Incoming’ and later again a SiteB Number labelled ‘User SiteB’ which both terminate on the SIP Trunk provision at SiteA. What appeared suspicious was that there were no outgoing calls logged to any international numbers in the CDR report. (These calls were probably calls for ‘probing’ purposes).
We checked the system for the standard security configurations that prevent voice mail phreaking (voicemail external call back, voice mail external notification and find me) and were confident that this was configured correctly to prevent voice mail break out, as the user group ‘voicemail notification’ had the relevant parameters including trunk to trunk, disabled. It was noted that 18 extensions were reported as having ‘simple’ passwords as a result of running the IDLint tool, and the list of the non-compliant extensions, was passed to User.
We then configured a DDI number to route to the Auto Attendant and tested the ability to break out from Auto Attendant, and we confirmed that break out was not successful.
The investigation was then moved on to the TMSncc log, which provides detailed information about all calls that arrive / made by the ShoreTel system.
Here it was identified that the calls were arriving at the ShoreTel and then being immediately routed out, and what was suspicious within the logs, the ‘dialled number (DNIS)’, was being shown as 8+0022891****** or 8+0035569******* or 9+00*********.
Our conclusion as to how the hacking occurred is as follows :-
The hackers were sending an Invite SIP message towards the Ingate SBC spoofing the TO:- address with initially 800xxxxxxxxxxxx (where xx is the international number)and later 900xxxxxxxxxxxx. It is assumed that the hackers were also spoofing the From:- IP address with Gamma’s signalling address (wan ip), (but cannot be proven as we don’t have a packet capture at the time the fraud was occurring), the Ingate SBC is correctly configured to allow traffic in ONLY from this address, so the Ingate saw this as trusted traffic and passed it on to the ShoreTel.
The Shoretel has 3 trunk groups configured two with an access code of 8 and one with an access code of 9, when the call was received by the ShoreTel it would see the 8 or 9 initial digit and would automatically access a new trunk from the relevant group, dial the remaining digits (International number) and tandem switch the incoming call to the outgoing call. The cost of the outgoing call would then be charged to Church House Investments.
The ability to route an incoming call directly to an outgoing call is provided by a feature called ‘Tandem Switching’, Tandem switching allows legacy voice systems to utilise a ShoreTel system for outbound dialing. The ShoreTel system supports both user-side and network-side PRI, allowing ShoreTel systems to flexibly support digital tie trunks to other systems. You can enable tandem trunking support for any PRI or SIP trunk group with a check box in ShoreTel Director. Tandem calls are associated with a user group for outbound trunk selection. Inbound calls recognized as tandem calls are redirected to an outbound trunk based on user group call permissions and trunk group access. When needed, a “dial-in prefix” can be specified that is prepended to digits collected on tandem calls. The concatenated set of digits is then used in outbound trunk selection for the tandem call.
After discussions with ShoreTel they have confirmed that there is an error in their documentation confusing “tandem trunking” with “trunk to trunk transfer” , see below;
“We recommend that the Tandem Trunking parameter be enabled (checked) otherwise transfers to external telephone numbers may fail via SIP trunks”
We have now disabled the Tandem Switching feature and Shoretel are going to amend the relevant documentation.
In conclusion there are 3 main points that allowed the fraudulent calls to be made:-
1. The Invite message towards the SBC contained a spoofed To:- address
2. The Invite message towards the SBC contained a spoofed IP address which was a trusted address as far as the SBC is concerned.
3. The Shoretel SIP trunk group had Tandem Switching allowed, which allowed automatic re-routing of the incoming call to the International destination.
My questions following this would be:
1. Who is to blame for the breach?
2. Who should be responsible for the cost of the hack?
3. Is their conclusion viable?
4. SHould they not be able to track exactly how and replicate the hack from logs at SIP provider side?
Thanks
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
we have a firewall in place and also ingate.
not till now.
surely a shoretel security issue?