How To DDoS a Federal Wiretap 112
alphadogg writes "Researchers at the University of Pennsylvania say they've discovered a way to circumvent the networking technology used by law enforcement to tap phone lines in the US. The flaws they've found 'represent a serious threat to the accuracy and completeness of wiretap records used for both criminal investigation and as evidence in trial,' the researchers say in their paper, set to be presented Thursday at a computer security conference in Chicago. Following up on earlier work on evading analog wiretap devices called loop extenders, the Penn researchers took a deep look at the newer technical standards used to enable wiretapping on telecommunication switches. They found that while these newer devices probably don't suffer from many of the bugs they'd found in the loop extender world, they do introduce new flaws. In fact, wiretaps could probably be rendered useless if the connection between the switches and law enforcement are overwhelmed with useless data, something known as a denial of service (DOS) attack."
Buffering... (Score:5, Informative)
As someone who worked on a CALEA system for 18 months, implementing, testing and helping design, I can tell you one thing.
The specs of all the systems are such that they DO NOT BUFFER the actual voice, only the data. I mean the numbers punched, busy signals, etc. Buffered voice would rapidly overwhelm the system, so it is just dropped if the link from the CO (central office) to the LE (law enforcement) goes down.
Call data can be buffered for days, so that isn't dropped.
This isn't a flaw, it was a design decision. Good luck DDoSing a major telco switching office.
Some background about Matt Blaze (Score:5, Informative)
Here's a bit of background the /. editors didn't give you.
If you take a 2-second look at the paper (the pdf link in the summary), you see Matt Blaze's name.
He's been doing other work on making law enforcement wiretapping not work. For instance, go to http://www.usenix.org/events/sec06/tech/ [usenix.org] and search the page for "Blaze"; you should find his talk (http://www.usenix.org/events/sec06/tech/mp3/blaze.mp3) and the Q&A session.
He also gave essentially the same talk as the first (under a different title) at http://www.usenix.org/event/lisa05/tech/ [usenix.org] (again, search the page for "Blaze" or go straight to http://www.usenix.org/event/lisa05/tech/mp3/blaze.mp3 [usenix.org]).
He also spoke at hotsec06, http://www.usenix.org/events/hotsec06/tech/ [usenix.org], with no recorded mp3, and at an e-voting panel, http://www.usenix.org/events/sec07/tech/ [usenix.org].
As you might infer, this isn't the first time Mr. (Dr.?) Blaze has been studying wiretapping (or other security issues). He's also quite a good, entertaining speaker. I recommend giving him a listen.
The short story (from the usenix talks): press the "C" key on your old 4x4-keypad phone. That's the in-band signal (doh!) used by law enforcement to mean "don't record now". Or, look up the tone frequency, then play it back at a much lower volume with a tone generator (your laptop might do) so it's more comfortable to talk over.
A couple things... (Score:5, Informative)
...for those who didn't RTFA:
First, this apparently applies to VoIP systems and cell phones, not analog land lines.
Second, it is not a DDoS attack, as the headline claims. It is a DoS attack, though. That extra D means "distributed" and refers to situations where you bring many computers (say, a botnet for example) to the party so that your cumulative traffic-generation ability exceeds your target's capacity. Those techniques are not in play here. I guess Internet-based distributed attacks have become so common that people don't bother knowing what the acronyms really mean anymore.
The channel you're trying to flood is a 64kbps data link between the phone company's switch and the law enforcement equipment. That is to say, the spec calls for 64kbps - so you don't really know if they have more than that in implementation. The idea is that if you program your system to rapidly make useless connections (such as text messages to random numbers) then you can flood this link and the equipment will lose track of the metadata describing an important message you send along during the flood. "Rapid" is on the order of 40 text messages per second; maybe you can program your equipment to do that.
They have not been able to test this attack in practice, and they're making assumptions - some of which I doubt - about what the result would be. Seems like a lot of trouble to go to for the chance that maybe there'll be a random probability that the call you care about doesn't get logged - and even then you won't know after the fact whether it worked. Anyone who takes communications security seriously enough to apply that much effort, will apply it to doing something more certain to work.
Re:Redundant Technology (Score:5, Informative)
Not really. That stuff is a firehose, and few jurisdictions are capable of handling anything like it. CALEA is for small town police depts as well as the FBI. Warrants are entered by the PD clerk, which are submitted to the CALEA system. The system is separate from accounting and everything else, so no one who isn't authorized has access to the info.
The system then flags a number and whenever a call is made to or from that number, it is duplicated inside the switch and a stream sent to the CALEA system. This includes busy signals, party line calls, SMS, etc.
The CALEA system establishes a secure tunnel (IPSec) inside the telco network to an IPSec gateway. We were working with Juniper boxes at the time. From there, the tunnels are broken out to the various law enforcement offices that have open warrants. One goes to the FBI, one to NYPD, etc. The entire internal network was GbE for the nodes and 10 GbE for trunks. Again, good luck DDoSing that.
Tunnels to the various LEOs varied in size depending on the size of the department and how many active warrants they had. A minimum of 1.54 Mbps, IIRC. Pipes to the FBI in Quantico, LAPD, NYPD and a couple others were larger by default.
I work on CALEA and DDOS is not possible (Score:5, Informative)
The fact that these researchers worked off of the standard for delivery compliance aka CALEA, has given them the false impression that all they need to do prevent a wiretap is to overload the connection between the agency and the DMS (the switch your call goes through).
What the J standard does not go into is the fact that at every step of the way there are checks to determine if data can be sent. If it cannot then it is stored until it is able to be sent. It is not uncommon for connections in the IP realm to come up and down so the system can buffer them both at the DMS, as well as at several points inbetween through the various offboard devices in the chain. Typically the data makes 2 stops between the DMS and the LEA.
This is strictly for the data portion of the call, IE dialed digits, in the wirless world it would include MMS/SMS, GPRS, etc.
The voice portion of the call is trunked from the DMS to the PSTN via a 3 way calling feature with 1 way audio. It basically dials the LEA's recording equipment every time the target makes a call, their equipment will record automatically when it answers the phone, like an answering machine. However the voice portion doesn't always have to go to a LEA. It can be configured to go to several phone numbers such as an agents mobile phone, a recording device, or other 3rd party.
Now you could overload the agencies recording equipment if you knew what number to dial using a war dialer type of attack, but that would lead authorities to your door and it would not prevent other agencies and other monitoring centers from receiving that same data. Most bench warrants will have several involved agencies each receiving intercepts from a single target.
Suffice to say that if you have a tap on your phone, it's going to get to the LEA and there isn't much you can do about it.
Re:A couple things... (Score:3, Informative)
...for those who didn't RTFA:
First, this apparently applies to VoIP systems and cell phones, not analog land lines....
VoIP and Cell systems are packetized data, just like normal analog phones are once they get to an RT or CO (read up on SS7). Most cell towers have VoIP connections back to a CO somewhere, and VoIP terminating on the POTS network first has to be converted to normal SS7 packetized traffic. This means the wire tap is tapping actual data packets from the SS7 channel (hence the mention of "only" 64kbps, which is actually a full ds0, same as a normal analog line). The attack mentioned (going from the way the summary presented it) requires taking up all available channels on the same switch that the tap is being placed on, so there are not enough available ds0 channels left for the tap to send its data, or alternatively, creating multiple voice channels that are targets for the tap so that it cant send all the voice even with a high compression codec (assuming its limited to the single ds0) . This is only capable if you get a bunch of people to dial into the same switch at the same time, basically a DDoS, or place multiple calls from the tapped phone or send sms/other stuff that takes up data channels. This has the same effect as what happens when a radio station announces that "10th caller gets tickets" to some concert, and you try to call but get "all circuits busy". But still, good luck flooding all the channels in a CO....
Tm
Re:Some background about Matt Blaze (Score:5, Informative)
My old 4x4 keypad phone doesn't have a C key.
Probably because it's only a 3x4 keypad phone. You want a keypad like this [futurlec.com], the C is on the same row as the 7, 8 and 9.
You may also want to review your counting skills. ;-)
Re:Buffering... (Score:4, Informative)
Well, the company's lawyers got the FBI to sign off on the voice buffering bit, and yes it was mostly a capacity issue. Whether that'll change in the future is up to whether or not the gov't decides to pay for it. I think that was the main argument. "You want HOW MUCH DATA buffered? Excuse us while we break out the BIG calculator to prepare you a quote."
No, we weren't interpreting data. Raw XML was passed over for control and signal data, and voice was sent as a raw codec stream. The codec was from Qualcom, and we did have to assist in making sure the FBI could receive and decode it properly. Only the FBI needed the help because they wrote their own code. All the other LEOs used off the shelf software from Qualcom.
For a while, I had a laptop that could inject requests into the stream -- bypassing the warrant step -- create an arbitrary IPsec tunnel and feed a raw stream of XML+voice to any IP of my choosing. I used to work at the hotel at night debugging call data. We had a microcell network set up in one of the suites.
Educational stuff.
Re:Redundant Technology (Score:1, Informative)
The entire internal network was GbE for the nodes and 10 GbE for trunks. Again, good luck DDoSing that.
Exactly.
The theory is that there is only a single 64k data channel from the Telco to the law enforcement agency. 64kbps is the amount of data assumed for a single voice call, so to say that they installed these things with the ability to only tap ONE phone call at a time is a little naive IMHO. More than likely they have been running full PRI trunks or loading it onto a nice fat fiber pipe for some time.
In any case, it's actually a fairly moot point, because as long as you're saturating the 64k connection for your phone number, it's not like you can actually USE it for anything, and as soon as you start talking and not redialing it's recording you anyhow. And there is a limit on how fast the call agent will even allow you to setup and tear down calls. Besides, I've worked in a Telco data center, and the local law enforcement's server was directly connected to the call switch with a cable, and sat right next to it in our datacenter, and the agency would just log into it and pull down whatever logs they needed at the time.
Besides, if you already know you're being tapped, the best way to avoid it is just not talk on the phone.