[VoiceOps] SS7

Sat Apr 23 13:17:51 EDT 2016

Mike;

HOLY smokes... they let anything thru???  The it way scary.  Does the word *RUN
*come to mind.

Kidd

On Sat, Apr 23, 2016 at 6:54 AM, Mike Ray, MBA, CNE, CTE <
mike at astrocompanies.com> wrote:

> 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
>
>
>
>
>
>
>
>
>
> *From:* Christopher Aloi [mailto:ctaloi at gmail.com]
> *Sent:* Friday, April 22, 2016 9:28 PM
> *To:* Kidd Filby <kiddfilby at gmail.com>; Mike Ray, MBA, CNE, CTE <
> mike at astrocompanies.com>
> *Cc:* VoiceOps <voiceops at voiceops.org>
> *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 <kiddfilby at gmail.com> 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 <
> mike at astrocompanies.com> 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
>
> http://www.astrocompanies.com
>
>
>
>
>
>
>
>
>
> *From:* VoiceOps [mailto:voiceops-bounces at voiceops.org] *On Behalf Of *Dan
> York
> *Sent:* Thursday, April 21, 2016 3:45 PM
> *To:* Kidd Filby <kiddfilby at gmail.com>
> *Cc:* voiceops at voiceops.org
> *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 <kiddfilby at gmail.com> 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
>
> dyork at lodestar2.com  +1-802-735-1624   Skype:danyork
>
> My writing -> http://www.danyork.me/
>
> http://www.danyork.com/
>
> http://twitter.com/danyork
>
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
>
> --
>
> Kidd Filby
> 661.557.5640 (C)
> http://www.linkedin.com/in/kiddfilby
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
>

-- 
Kidd Filby
661.557.5640 (C)
http://www.linkedin.com/in/kiddfilby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20160423/5dd12b15/attachment-0001.html>