I didn’t realize that either until we switched SS7 providers recently. Our former one (Whom I am beginning to miss, truth be told) made it impossible to exchange signaling traffic with anything that you didn’t have a route built (and paid) for, which is how it’s been as far as I know since I got into this biz nearly two decades ago.
However, our new SS7 provider apparently lets any SS7 point code communicate with ours, as we started seeing random traffic from unknown point codes shortly after we switched providers. We reported it and they blocked that traffic, but in the process it became clear that they let anything through until and unless we ask them to block it. There’s also language in our ICA with them that says that if we are communicating with any point code that we haven’t purchased a route for, they have the right to back-bill it one they discover it. We’re in a contract now for three years, but at the end of it we may switch back to the original provider for this and other reasons. SS7 certainly feels a lot less secure than it did before. Luckily, our Class 5 End Office switch does not provide any data nor redirection capabilities over SS7 such as those exploited in the article. We also found that while we received the traffic from the unknown point code, our switch did not respond because we did not have a route built for it on the switch. But it still means that a DOS attack may be possible, and it feels like assigning our switch a public IP without a firewall in place, which makes me crazy. Mike Mike Ray, MBA, CNE, CTE Astro Companies, LLC 11523 Palm Brush Trail #401 Lakewood Ranch, FL 34202 DIRECT: call or text 941 600-0207 <http://www.astrocompanies.com> http://www.astrocompanies.com From: Christopher Aloi [mailto:[email protected]] Sent: Friday, April 22, 2016 9:28 PM To: Kidd Filby <[email protected]>; Mike Ray, MBA, CNE, CTE <[email protected]> Cc: VoiceOps <[email protected]> Subject: Re: [VoiceOps] SS7 I didn't realize you can now connect to another company without ordering the route-set from a third party. How does this work ? I feel old ! On Fri, Apr 22, 2016 at 2:40 PM Kidd Filby <[email protected] <mailto:[email protected]> > wrote: Very well said Mike. Back In The Day... Interconnection between 2 companies had to occur via a 3rd party, like Illuminet. Their had to be SS7 gateway providers and that's all they were allowed to do. Route SS7 traffic between LEC/ILEC/CLEC networks. Oh... do I remember the pains... Gateway-Screened... CNAM database corruption, LIDB services not provided.... Still makes my head hurt. Kidd On Fri, Apr 22, 2016 at 12:28 PM, Mike Ray, MBA, CNE, CTE <[email protected] <mailto:[email protected]> > wrote: It seems to me that this SS7 vulnerability issue is just the latest result of all of the de-regulation that’s been going on for the past… two decades or so. There was a time that you could not buy commercial access to the SS7 network; to get that access you had to be a real carrier. Also, back at that time, inter-company SS7 signalling could only occur on established, ordered signaling routes where both parties placed an order to open the route between them. Therefore, this would not have been possible back then because the carrier would not have ordered a route to the hacker’s point code(s) and it therefore would not exist. If I am a US local carrier in 2001, I have no need to order a signaling route to a German carrier either so even the hacker having full access to a German carrier’s network would not compromise my network. (in response to the nation-state issue) To get a call to Germany, I signal to the access tandem or IXC switch I’ve chosen to interconnect with in the US and that switch signals upstream, etc. If we were not on this path of de-regulation where whatever makes commercial sense for one company can open up the whole SS7 network to un-trusted parties, we likely wouldn’t be here. At some point, a decision was made somewhere to allow this loosy-goosy inter-company signaling over the SS7 network between two point codes that would not, under the original implementation of SS7, be able to talk to each other in the first place. If the drumbeat of “solve everything with IP!” continues, I hope that at least it gets solved by establishing something close to what the VPF was supposed to be, and not just a general dumping of all voice traffic across the internet between carriers. That certainly wouldn’t bode well for reliability or security. Mike Mike Ray, MBA, CNE, CTE Astro Companies, LLC 11523 Palm Brush Trail #401 Lakewood Ranch, FL 34202 DIRECT: call or text 941 600-0207 <tel:941%20600-0207> <http://www.astrocompanies.com> http://www.astrocompanies.com From: VoiceOps [mailto:[email protected] <mailto:[email protected]> ] On Behalf Of Dan York Sent: Thursday, April 21, 2016 3:45 PM To: Kidd Filby <[email protected] <mailto:[email protected]> > Cc: [email protected] <mailto:[email protected]> Subject: Re: [VoiceOps] SS7 This is generally true if the calls are *unencrypted* on VoIP... On Thu, Apr 21, 2016 at 2:20 PM, Kidd Filby <[email protected] <mailto:[email protected]> > wrote: Also folks, don't forget, the same outcome of recording someone's call is MUCH easier to accomplish once it is VoIP. IMHO, of course. ;-) ... BUT... what's fascinating is the recent rise in end-to-end (e2e) encryption among IP-based communications platforms that include voice. WhatsApp, for instance, just completed the rollout of e2e encryption on April 5, and not just for messaging, but also for voice and video calls as well as file transfers ( https://blog.whatsapp.com/10000618/end-to-end-encryption ). Just yesterday the team behind Viber announced that they will soon have e2e encryption for all clients. The app Wire ( http://wire.com ) also does e2e encryption for voice, video and group chats. In a US Congress hearing this week, a Congressman asked a Dept of Homeland Security representative if e2e encryption available in apps would have prevented this interception that happened via SS7. The DHS answer was that it would mitigate the interception of the content, although the location meta-data would still be available. (You can view the exchange via the link in this tweet: https://twitter.com/csoghoian/status/722854012567969794 ) The end result is that we're definitely moving to a space where the communication over IP-based solutions will wind up being far more secure than what we had before. Interesting times, Dan -- Dan York <mailto:[email protected]> [email protected] +1-802-735-1624 <tel:%2B1-802-735-1624> Skype:danyork My writing -> http://www.danyork.me/ <http://www.danyork.com/> http://www.danyork.com/ http:// <http://twitter.com/danyork> twitter.com/danyork _______________________________________________ VoiceOps mailing list [email protected] <mailto:[email protected]> https://puck.nether.net/mailman/listinfo/voiceops -- Kidd Filby 661.557.5640 (C) http://www.linkedin.com/in/kiddfilby _______________________________________________ VoiceOps mailing list [email protected] <mailto:[email protected]> https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list [email protected] https://puck.nether.net/mailman/listinfo/voiceops
