[VoiceOps] Hackers Crash Clay Co. Phones ...

Ryan Delgrosso ryandelgrosso at gmail.com
Mon Aug 18 16:53:29 EDT 2014

I dunno that's a slippery slope. Im not a proponent of putting 
management of your network services into someone elses hands, especially 
things like this where the service provider should have visibility into 
what they are or are not admitting.

Agreed on your synopsis of call admission control, the border should be 
able to make these decisions rapidly, freeing up softswitch resources to 
actually serve customers.

This sounds like good territory for an acme SPL plugin, possibly in 
conjunction with this enum extension 
http://tools.ietf.org/html/draft-kaplan-enum-source-uri-00 unfortunately 
i dont see a clear path for this in the TDM world but my exposure there 
is limited. It would seem like a good solution might be using ENUM (with 
source URI) to build statistics centrally based on calling/called 
numbers and then forcing the ENUM response once thresholds are hit to 
illicit an appropriate decline message for flagged invites with a 
retry-after interval allowing you to effectively throttle specific call 
scenarios assuming your origination carriers will behave correctly.

2 of the examples we discussed previously were:

1: Social media death star. Justin biebers (or anyone else with millions 
of rabid followers) twitter account  (53.7M followers) gets hacked and 
attacker tweets "Call this number for free tickets" or similar.

2: T-DOS using stolen sip accounts effectively turning other service 
providers into a death star. More damage per source number (higher CPS 
than social media per attacker but less distributed source). This one 
seems much easier to create given the ease with which stolen sip 
accounts can be acquired, and harder to mitigate if the stolen accounts 
support callerID spoofing.

Both of these situations are exacerbated by LCR resellers creating at 
times 10-20 invites from 1 due to route advancing when the destination 
is truly congested, which gets worse when the LCR resellers in turn have 
resellers in route etc etc.

Of course any solution needs to have provisions for conveying congestion 
control to the originating network so they stop route advancing.

I think this has commercial viability for access providers protecting 
their customers business interests and for implementers designing 
solutions but perhaps not so much in a carrier to carrier capacity 
(beyond appropriate support of signaling congestion control).

On 8/18/2014 12:48 PM, Mark R Lindsey wrote:
> Ryan, does it seem as though TDoS will be most effectively addressed by the origination companies?  i.e., the guys with the TDM trunks to the local tandems, such as incumbents, Verizon, Level(3).
> It seems to me that some use of statistics could probably make reasonable guesses about whether a given PSTN origination call is likely to be legitimate (for a call from A to B). For example, I'll bet you could make a good start looking at numbers and geographic areas:
> 	-- Has telephone number A called to telephone number B before? Or B->A ?
> 	-- Has GeographicArea(A) called to telephone number B before? Or GeographicArea(B) -> A?
> The more you know about telephone numbers A and B, the more you could guess about the likelihood that a given call is legitimate.
> And getting good at this should be a competitive advantage, just as effective anti-spam is an advantage elsewhere. Vendors that build the edge gear -- in particular, the SBC and TDM SS7 gateway vendors -- should be leading the way.
> And wholesale carriers could take some advantage and make it broadly available. For example, let's say Verizon came along and said, "Here's a reason to port your numbers from Level(3) to us: When you're under attack, we're going to be smart about the ways we selectively admit calls to your network."
>>>> mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey
> On Aug 18, 2014, at 13:52 , Ryan Delgrosso <ryandelgrosso at gmail.com> wrote:
>> IP DDOS and TDOS are really two different problems but yes we as ITSP's and CLECs living in the IP space are absolutely susceptible to both.
>> Ive done a fair amount of research into both of these topics and we have seen varying cases of both, but usually IP DDOS steals the spotlight because the numbers are bigger and the effects are usually more widespread whereas a TDOS attack is rarely felt by anyone that doesn't live in the affected region or isn't actively trying to call the victim, and usually telcos keep these issues pretty close to the chest.
>> I expect this sort of attack is going to increase in magnitude in the coming 24-36 months as attackers figure out how to wield it. Mark Collier gave a very interesting talk at one of the CFCA events on this topic, though the focus was on the enterprise victim, but the lessons are really the same. There just arent really any good tools to mitigate this sort of attack today, especially at the carrier level.
>> -Ryan
>> On 8/18/2014 6:30 AM, Matt Yaklin wrote:
>>> It seems like almost every telephone company can be hit like that
>>> except the ?largest?...
>>> A denial of service attack by simply calling so many times it
>>> fills up their main trunks.
>>> And we saw how the large IP colo providers handle this for customers
>>> who get dos'd. The amount of bandwidth they have is staggering and
>>> they still cannot guarantee you will stay up if a ?skilled? attacker
>>> wants you down. So you keep throwing money at it until you are
>>> so well established online that you look at your monthly bill and
>>> want to puke.
>>> matt
>>> On Mon, 18 Aug 2014, Frank Bulk wrote:
>>>> http://www.wibw.com/home/headlines/Hackers-Behind-Phone-Outage-In-Clay-County-271463051.html?ref=051
>>>> Painful issue for Big River Telephone!
>>>> Frank
>>> _______________________________________________
>>> 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

More information about the VoiceOps mailing list