Posted on 04/18/2016 6:31:09 PM PDT by Swordmaker
Update: Rep. Ted Lieu has now written to the Chairman of the House Committee on Oversight and Government Reform requesting a formal investigation into the vulnerability. In his letter, the Congressman says that the flaw threatens ‘personal privacy, economic competitiveness and U.S. national security.’ The full text of his letter can be found at the bottom of the piece.
Apple may take iOS security so seriously that it’s willing to do battle with the FBI over it, but German hackers have demonstrated that all phones – even iPhones – are susceptible to a mobile network vulnerability that requires nothing more than knowing your phone number. Armed with just that, hackers can listen to your calls, read your texts and track your position.
60 Minutes invited the hackers to prove their claims by giving a brand new iPhone to Congressman Ted Lieu – who agreed to participate in the test – and telling the hackers nothing more than the phone number. The hackers later replayed recordings they’d made of calls made on that iPhone …
Rep. Ted Lieu said that he was shocked by what the hackers had been able to achieve.
Last year, the president of the United States called me on my cellphone. And we discussed some issues. So if the hackers were listening in, they would know that phone conversation [and the President’s mobile number]. And that’s immensely troubling.
Nohl said that the SS7 vulnerability was well-known in some quarters, and that there was a reason it hasn’t yet been fixed.
The ability to intercept cellphone calls through the SS7 network is an open secret among the world’s intelligence agencies — -including ours — and they don’t necessarily want that hole plugged.
Lieu said that this was totally unacceptable.
The people who knew about this flaw and saying that should be fired. You cannot have 300-some million Americans – and really, right, the global citizenry – be at risk of having their phone conversations intercepted with a known flaw, simply because some intelligence agencies might get some data. That is not acceptable.
While the court battle between Apple and the FBI is over, they will again face off in Congress tomorrow. Apple general counsel Bruce Sewell and FBI executive assistant director Amy Hess will testify on separate panels before House Energy and Commerce subcommittee. Separately, two members of the Senate Intelligence Committee have proposed a bill to force tech companies to decrypt devices for law enforcement, though one Senator has vowed to block the legislation with a filibuster.
Pinging dayglored, ThunderSleeps, and Shadow Ace for a very important message from the hacking community!
The latest Apple/Mac/iOS Pings can be found by searching Keyword "ApplePingList" on FreeRepublic's Search.
If you want on or off the Mac Ping List, Freepmail me
 CCITT developed the Signalling System 7 (SS7) specification. SS7 is a common channel signalling system. This means that one channel is used only for sending the signalling information, whether the system has one bearer channel or multiple bearer channels. The hardware and software functions of the SS7 protocol are divided into layers which loosely correspond to the OSI 7 layer model.The SS7 protocol suite is illustrated here in relation to the OSI model: Click the protocols on the map to see more details.
 BISUP Recommendation Q.2763 (02/95). http://www.itu.int/ITU-T/. The B-ISDN User Part (B-ISUP) is applicable to international B-ISDN networks. In addition, the B-ISDN User Part is suitable for national applications. Most messages and parameters specified for international use are also required in typical national applications. Moreover, coding space has been reserved in order to allow national administrations and recognized operating agencies to introduce network specific signalling messages and parameters within the internationally standardized protocol structure. B-ISDN user part messages are carried on the ATM signalling link by means of S-AAL service data units, the format of which is described in 6.2/Q.2110. As a national option B-ISDN user part messages can be carried on the STM signalling link by means of signal units, the format of which is described in 2.2/Q.703. The format of, and the codes used in the service information octet are described in 14.2/Q.704. The service indicator for the B-ISDN user part is coded 1001. The signalling information field of each message signal unit containing an B-ISDN user part message consists of an integral number of octets and encompasses the following parts: a) routing label; b) message type code; c) message length; d) message compatibility information; e) message content. The structure of the B-ISUP protocol is as follows:
Discard Message Indicator The following indicators are available 0 Do not discard message 1 Discard message Send Notification Indicator The following indicators are available 0 Do not send notification 1 Send notification Release call indicator The following indicators are available 0 Do not release call 1 Release call Transit at intermed exch. Indicator The following indicators are available 0 Transit interpretation 1 End node interpretation
Interested in more details about testing this protocol?
DUP ITU-T recommendation X.61 (Q.741) http://www.itu.int/itudoc/itu-t/rec/q/q500-999/q741.html The Data User Part (DUP) defines the necessary call control, and facility registration and cancellation related elements for international common channel signalling by use of Signalling System No. 7 for circuit-switched data transmission services. The data signalling messages are divided into two categories:
The general format of the header of call and circuit related messages is shown as follows:
The general format of the header of facility registration and cancellation messages is shown as follows:
Routing Label The label contained in a signalling message and used by the relevant user part to identify particulars to which the message refers. This is also use by the message transfer part to route the message towards its destination point. It contains the DPS, OPC, BIC and TSC fields. DPS The destination point code (14 bits) is the code applicable to the data switching exchange to which the message is to be delivered. OPC The originating point code (14 bits) is the code applicable to the data switching exchange from which the message is sent. BIC Bearer identification code (12 bits). For bearers which form part of a 2.048 Mbit/s PCM system according to Recommendation G.734, the bearer identification code contains in the 5 least significant bits a binary representation of the actual number of the time slot which is assigned to the bearer. The remaining bits of the bearer identification code are used where necessary, to identify one among several systems, interconnecting the originating point and destination point. For bearers which form part of a 8.448 Mbit/s PCM system the bearer identification code is coded in accordance with the scheme specified for the circuit identification code for the corresponding case in Recommendation Q.723. TSC Time slot code (8 bits). If the data circuit is derived from the data multiplex carried by the bearer, identified by the bearer identification code: Bits 1-4 contain, in pure binary representation, the channel number of the circuit within the 12.8 kbit/s or 12 kbit/s phase; the channel number being in the range: 0-15 for 600 bit/s circuits 0- 3 for 2400 bit/s circuits 0- 1 for 4800 bit/s circuits 0 for 9600 bit/s circuits Bits 5-7 contain, in pure binary representation, the number of the 12.8 kbit/s or 12 kbit/s phase, the phase number being in the range 0-4; Bit 8 is coded 0. In the case where the data circuit uses the full 64 kbit/s bearer rate, the time slot code will be 01110000. Heading code The heading code (4 bits) contains the message type code which is mandatory for all messages. It uniquely defines the function and format of each DAP message. Message specific parameters Contains specific fields for each message. Spare bits Not used, should be set to “0000”. Interested in more details about testing this protocol? ISUP Q.763 http://www.itu.int/itudoc/itu-t/rec/q/q500-999/q763_23976.html ISUP is the ISDN User Part of SS7. ISUP defines the protocol and procedures used to setup, manage and release trunk circuits that carry voice and data calls over the public switched telephone network. ISUP is used for both ISDN and non-ISDN calls. Calls that originate and terminate at the same switch do not use ISUP signalling. ISDN User Part messages are carried on the signalling link by means of signal units. The signalling information field of each message signal unit contains an ISDN User Part message consisting of an integral number of octets. The format of the ISUP packet is shown in the following illustration:
Routing label The label contained in a signalling message, and used by the relevant user part to identify particulars to which the message refers. It is also used by the Message Transfer Part to route the message towards its destination point. Circuit identification code The allocation of circuit identification codes to individual circuits is determined by bilateral agreement and/or in accordance with applicable predetermined rules. Message type code The message type code consists of a one octet field and is mandatory for all messages. The message type code uniquely defines the function and format of each ISDN User Part message. Each message consists of a number of parameters. Message types may be: Address complete Answer Blocking Blocking acknowledgement Call progress Circuit group blocking Circuit group blocking acknowledgement Circuit group query @ Circuit group query response @ Circuit group reset Circuit group reset acknowledgement Circuit group unblocking Circuit group unblocking acknowledgement Charge information @ Confusion Connect Continuity Continuity check request Facility @ Facility accepted Facility reject Forward transfer Identification request Identification response Information @ Information request @ Initial address Loop back acknowledgement Network resource management Overload @ Pass-along @ Release Release complete Reset circuit Resume Segmentation Subsequent address Suspend Unblocking Unblocking acknowledgement Unequipped CIC @ User Part available User Part test User-to-user information Parameters Each parameter has a name which is coded as a single octet. The length of a parameter may be fixed or variable, and a length indicator for each parameter may be included.
MAP EIA/TIA-41 http://www.tiaonline.org.com Mobile Application Part (MAP) messages sent between mobile switches and databases to support user authentication, equipment identification, and roaming are carried by TCAP In mobile networks (IS-41 and GSM) when a mobile subscriber roams into a new mobile switching center (MSC) area, the integrated visitor location register requests service profile information from the subscriber’s home location register (HLR) using MAP (mobile application part) information carried within TCAP messages. The packet consists of a header followed by up to four information elements. The general format of the header is shown here: The format of the header is shown in the following illustration:
Length The length of the packet. MAP parameters Various parameters dependent on the operation. Interested in more details about testing this protocol? MTP-2Q.703 http://www.itu.int/itudoc/itu-t/rec/q/q500-999/q703_24110.html Message Transfer Part – Level 2 (MTP-2) is a signalling link which together with MTP-3 provides reliable transfer of signalling messages between two directly connected signalling points. (Compliant with ITU Q.703 1994 and ANSI T1.111 199.) The format of the header is shown in the following illustration:
MTP-2 header structure
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
BSN Backward sequence number. Used to acknowledge message signal units which have been received from the remote end of the signalling link.
BIB Backward indicator bit. The forward and backward indicator bit together with forward and backward sequence number are used in the basic error control method to perform the signal unit sequence control and acknowledgment functions.
FSN Forward sequence number.
FIB Forward indicator bit.
LI Length indicator. This indicates the number of octets following the length indicator octet.
SIO Service information octet.
SIF Signalling information field.
Checksum Every signal unit has 16 check bits for error detection.
Interested in more details about testing this protocol?
MTP-3 Q.704 http://www.itu.ch/itudoc/itu-t/rec/q/q500-999/q704_27792.html
Message Transfer Part – Level 3 (MTP-3) connects Q.SAAL to the users. It transfers messages between the nodes of the signalling network. MTP-3 ensures reliable transfer of the signalling messages, even in the case of the failure of the signalling links and signalling transfer points. The protocol therefore includes the appropriate functions and procedures necessary both to inform the remote parts of the signalling network of the consequences of a fault, and appropriately reconfigure the routing of messages through the signalling network.
The structure of the MTP-3 header is shown in the following illustration:
|
Service indicator |
Subservice field |
|
4 bits |
4 bits |
|
MTP-3 header structure |
|
Sub-service field The sub-service field contains the network indicator and two spare bits to discriminate between national and international messages.
Interested in more details about testing this protocol?
Q2140 Recommendation Q.2140. http://www.itu.int/ITU-T/ The SSCF for NNI Signaling standard consists of the Service Specific Coordination Function (SSCF) in conjunction with the Service Specific Connection Oriented Protocol (SSCOP) which defines the Service Specific Convergence Sublayer (SSCS). The purpose of the Service Specific Coordination Function is to enhance the services of SSCOP to meet the needs of the requirements of the NNI level 3 protocol. In addition the SSCF at the NNI provides communication with Layer Management for proper operation of signalling links. The SSCF at the NNI is the uppermost sub-layer in the protocol stack for the SAAL at the NNI. By construction, it utilizes the services of the underlying SAAL sub-layers, in combination with its own functions, to provide an overall SAAL service to the SAAL user, as described below. The SAAL at the NNI provides signalling link functions for the transfer of signalling messages over one individual signalling data link. The SAAL functions provide a signalling link for reliable transfer of signalling messages between two signalling points. A signalling message delivered by the higher levels is transferred over the signalling link in variable length Protocol Data Units (PDUs). For proper operation of the signalling link, the PDU comprises transfer control information in addition to the information content of the signalling message. The protocol header structure is as follows:
|
8
|
7
|
6
|
5
|
4
|
3
|
2
|
1
|
Octets
|
|
Reserved
|
1
|
|||||||
|
2
|
||||||||
|
3
|
||||||||
|
SSCF Status
|
4
|
|||||||
| 1 | Out of Service |
| 2 | Processor Outage |
| 3 | In Service |
| 4 | Normal |
| 5 | Emergency |
| 7 | Alignment Not Successful |
| 8 | Management Initiated |
| 9 | Protocol Error |
| 10 | Proving Not Successful |
 |
|
SCCP Q.713 http://www.itu.int/itudoc/itu-t/rec/q/q500-999/q713_23786.html The Signalling Connection Control Part (SCCP) offers enhancements to MTP level 3 to provide connectionless and connection-oriented network services, as well as to address translation capabilities. The SCCP enhancements to MTP provide a network service which is equivalent to the OSI Network layer 3. (Compliant with the ITU specification Q.713, ITU-T: Signalling System No. 7 SCCP Formats And Codes 03-93 SS7 Basics/ Toni Beninger/ S038 1991 ANSI T1.112.)
The format of the header is shown in the following illustration:
|
Routing label |
|
Message type code |
|
Mandatory fixed part |
|
Mandatory variable part |
|
Optional part |
|
SCCP header structure |
| CR | Connection Request. |
| CC | Connection Confirm. |
| CREF | Connection Refused. |
| RLSD | Released. |
| RLC | Release Complete. |
| DT1 | Data Form 1. |
| DT2 | Data Form 2. |
| AK | Data Acknowledgment. |
| UDT | Unidata. |
| UDTS | Unidata Service. |
| ED | Expedited Data. |
| EA | Expedited Data Acknowledgment. |
| RSR | Reset Request. |
| RSC | Reset Confirm. |
| ERR | Protocol Data Unit Error. |
| IT | Inactivity Test. |
| XUDT | Extended Unidata. |
| XUDTS | Extended Unidata Service. |
Mandatory fixed part The parts that are mandatory and of fixed length for a particular message type will be contained in the mandatory fixed part.
Mandatory variable part Mandatory parameters of variable length will be included in the mandatory variable part. The name of each parameter and the order in which the pointers are sent is implicit in the message type.
Optional part The optional part consists of parameters that may or may not occur in any particular message type. Both fixed length and variable length parameters may be included. Optional parameters may be transmitted in any order. Each optional parameter will include the parameter name (one octet) and the length indicator (one octet) followed by the parameter contents.
Interested in more details about testing this protocol?
TCAPQ.773 http://www.itu.int/itudoc/itu-t/rec/q/q500-999/q773_24880.html
TCAP (Transaction Capabilities Application Part) enables the deployment of advanced intelligent network services by supporting non-circuit related information exchange between signalling points using the SCCP connectionless service. TCAP messages are contained within the SCCP portion of an MSU. A TCAP message is comprised of a transaction portion and a component portion. (Compliant with ITU recommendation q.773.)
A TCAP message is structured as a single constructor information element consisting of the following: Transaction Portion, which contains information elements used by the Transaction sub-layer; a Component Portion, which contains information elements used by the Component sub-layer related to components; and, optionally, the Dialogue Portion, which contains the Application Context and user information, which are not components. Each Component is a constructor information element.
|
Tag |
Length |
Contents |
 |
|
TCAP packet structure
|
Tag The Tag distinguishes one information element from another and governs the interpretation of the Contents. It may be one or more octets in length. The Tag is composed of Class, Form and Tag codes.
Length Specifies the length of the Contents.
Contents Contains the substance of the element, containing the primary information the element is intended to convey.
TCAP Packet Types
TCAP packet types are as follows:
TUP ITU-T Recommendation Q.723. http://www.itu.int/ITU-T/. Signalling System No.7 – Telephone User Part.The Telephone User Part (TUP) carries the telephone user messages on the signalling data link by means of signal units. The signalling information of each message constitutes the signalling information field of the corresponding signal unit and consists of an integral number of octets. It basically contains the label, the heading code and one or more signals and/or indications. The service information octet comprises the service indicator and the subservice field. The service indicator is used to associate signalling information with a particular User Part and is only used with message signal units (see Recommendation Q.704, § 12.2). The information in the subservice field permits a distinction to be made between national and international signalling messages. In national applications when this discrimination is not required possibly for certain national User Parts only, the subservice field can be used independently for different User Parts. The TUP header structure is as follows:
|
8
|
7
|
6
|
5
|
4
|
3
|
2
|
1
|
Octets
|
|
Message Type Code
|
1
|
|||||||
Message Type Code The message type code. The following message type codes are available:
| 0x11 | Initial Address |
| 0x21 | Initial Address With Additional Information |
| 0x31 | Subsequent Address |
| 0x41 | Subsequent Address With One Signal |
| 0x12 | General Forward Setup Information |
| 0x32 | Continuity Signal |
| 0x42 | Continuity Failure Signal |
| 0x13 | General Request |
| 0x14 | Address Complete |
| 0x24 | Charging |
| 0x15 | Switching Equipment Congestion Signal |
| 0x25 | Circuit Group Congestion Signal |
| 0x35 | National Network Congestion Signal |
| 0x45 | Address Incomplete signal |
| 0x55 | Call Failure Signal |
| 0x65 | Subscriber Busy Signal (electrical) |
| 0x75 | Unallocated Number Signal |
| 0x85 | Line Out Of Service Signal |
| 0x95 | Send Special Information Tone Signal |
| 0xA5 | Access Barred Signal |
| 0xB5 | Digital Path Not Provided Signal |
| 0xC5 | Misdialled Trunk Prefix |
| 0xF5 | Extended Unsuccessful Backward Setup Information |
| 0x06 | Answer Signal, Unqualified |
| 0x16 | Answer Signal, Charge |
| 0x26 | Answer Signal, No Charge |
| 0x36 | Clear Back Signal |
| 0x46 | Clear Forward Signal |
| 0x56 | Reanswer Signal |
| 0x66 | Forward Transfer Signal |
| 0x76 | Calling Party Clear Signal |
| 0x17 | Release Guard Signal |
| 0x27 | Blocking Signal |
| 0x37 | Blocking Acknowledgement Signal |
| 0x47 | Unblocking Signal |
| 0x57 | Unblocking Acknowledgement Signal |
| 0x67 | Continuity Check Request Signal |
| 0x77 | Reset Circuit Signal |
| 0x18 | Maintenance Oriented Group Blocking |
| 0x28 | Maintenance Oriented Group Blocking Acknowledgement |
| 0x38 | Maintenance Oriented Group Unblocking |
| 0x48 | Maintenance Oriented Group Unblocking Acknowledgement |
| 0x58 | Hardware Failure Oriented Group Blocking |
| 0x68 | Hardware Failure Oriented Group Blocking Acknowledgement |
| 0x78 | Hardware Failure Oriented Group Unblocking |
| 0x88 | Hardware Failure Oriented Group Unblocking Acknowledgement |
| 0x98 | Circuit Group Reset |
| 0xA8 | Circuit Group Reset Acknowledgement |
| 0xB8 | Software Generated Group Blocking |
| 0xC8 | Software Generated Group Blocking Acknowledgement |
| 0xD8 | Software Generated Group Unblocking |
| 0xE8 | Software Generated Group Unblocking Acknowledgement |
| 0x1A | Automatic Congestion Control Information |
| 0x2C | Metering Pulse Message |
| 0x1D | Operator Signal |
| 0x1E | Subscriber Local – Busy Signal |
| 0x2E | Subscriber Toll – Busy Signal |
| 0x1F | Malicious Call Tracing Signal |
 |
|
Interested in more details about testing this protocol?
SS7 Family Protocol Information BICC | BISUP | DUP | ISUP | MAP | MTP-2 | MTP-3 | Q2140 | SCCP | TCAP | TUP
| Additional Information |
I am impressed!!!!
I bow before your greatness.
Very informative, thank you for taking the time.
“invited the hackers to prove their claims by giving a brand new iPhone to Congressman Ted Lieu – who agreed to participate in the test”
Let’s repeat the experiment with a fresh-from-the-store phone rather than one that the hackers and 60 minutes had access to prior to the test.
60 Minutes had and has credibility issues.
“60 Minutes had and has credibility issues.”
Yes they do.
However, this impacts all cellular phones, not just the iPhone. They singled out the iPhone in the headline to attract readers. That’s quite scummy.
I wonder if they’d get their panties in a bunch if people would start using apps to encrypt phone conversations in realtime. I almost want to do that for fun. Seriously, just require each end user to agree on a particular key to use (much like one time pads) and encrypt the call. Not pretty, but it’d work ... and it’d be enough to cause some chuckles I think.
This kind of garbage is starting to really torque me off. I have absolutely nothing to hide and my phone conversations are quite boring ... but that’s nobody’s damn business ... get a frigging warrant if you want me to bore you to tears when you listen in on my calls about my latest sinus infection or how frigging tired I am :-).
Thanks for the ping.
We’ve know about the issues in ss7 signalling for a long time. Personally, I think the that particular ‘flaw’ was purposely made a part of the spec.
If there's concern about hacking cell phones, you can bet the only concern is how it affects him and his socialist friends.
Brought to you by the fine folks who authorized the 1996 Telecom Act, CALEA and HIPPA.....
It had nothing to do with the make of the phone. It had to do with a vulnerability to on the NETWORK, not the phone.
How do you think the NSA listens in?
To safeguard the privacy of innocent persons, the interception of wire or oral communications where none of the parties to the communication has consented to the interception should be allowed only when authorized by a court of competent jurisdiction and should remain under the control and supervision of the authorizing court.
Nothing contained in this chapter or Section 605 of the Communications Act of 1934 shall limit the constitutional power of the President to take such measures as he deems necessary to protect the Nation against actual or potential attack or other hostile acts of a foreign power, to obtain foreign intelligence information deemed essential to the security of the United States, or to protect national security information against foreign intelligence activities. Nor shall anything contained in this chapter be deemed to limit the constitutional power of the President to take such measures as he deems necessary to protect the United States against the overthrow of the Government by force or other unlawful means, or against any other clear and present danger to the structure or existence of the Government.
Upon an application made under section 3122 of this title, the court shall enter an ex parte order authorizing the installation and use of a pen register or a trap and trace device within the jurisdiction of the court if the court finds that the attorney for the Government or the State law enforcement or investigative officer has certified to the court that the information likely to be obtained by such installation and use is relevant to an ongoing criminal investigation.
A telecommunications carrier shall ensure that its equipment, facilities, or services…are capable of expeditiously isolating and enabling the government, pursuant to a court order or other lawful authorization, to intercept, to the exclusion of other communications, all wire and electronic communications carried by the carrier within a service area to or from equipment [and] to access call-identifying information.
Currently, all Internet wiretaps using the Carnivore system begin with an FBI investigation. As with any wiretap, the FBI requires its investigators to ask for permission. According to the Illinois report, the process the FBI follows to obtain a wiretap is as follows:
--For a full mode wiretap only
· A case agent in an investigation determines a wiretap may be needed.
· The agent contacts the FBI’s Chief Division Counsel (CDC), familiar with statutory requirements.
· The agent contacts a Technically Trained Agent (TTA); an experienced Special Agent with advanced training.
· After consulting with the CDC, the TTA, and with field office supervisors, the case agent will determine if the wiretap is required.
--For a pen register wiretap only
· The case agent requests pen-register surveillance in writing, with a justification for necessity.
--Then, for either full mode or pen mode
· FBI shows a judge the relevance of the information sought to the investigation.
· FBI shows a judge why traditional enforcement methods are insufficient.
· FBI must submit request with information such as target internet service provider (ISP), e-mail address, etc.
· This process may take up to 4-6 months.
At this point, two court orders are issued; one that authorizes the intercept, and a second, which directs the ISP to cooperate with the investigation. After receiving a court order, the FBI begins conversations with the target ISP. Carnivore is deployed when:
· The ISP cannot narrow sufficiently the information retrieved to comply with the court order.
· The ISP cannot receive sufficient information.
· The FBI does not want to disclose information to the ISP, as in a sensitive national security investigation.
Let's get on a big boat with a huge net and go fishing!
If it is deemed necessary, a Carnivore computer is taken from FBI headquarters and brought to the ISP. The TTA takes responsibility for the installation of the system, for configuration of the system based on the court order, and for securing the work area at the ISP. After this, the TTAs work is done; the TTA does not receive or complete minimization on any of the information collected by Carnivore.
At this point, the case agent can retrieve the intercepted information remotely as it is received by Carnivore, or he can await the information on the Jaz disk from the computer.
The hardware components of the Carnivore system are:
1) a one-way tap into an Ethernet data stream;
2) a general purpose computer to filter and collect data;
3) one or more additional general purpose computers to control the collection and examine the data;
4) a telephone link to connect the additional computer(s) to the collection computer.
Figure 2: Carnivore Hardware Architecture
One Way Tap
The connection from the filtering/collection computer to the ISP's network is a third-party one-way tap. The device, called the Century Tap, is produced by Shomiti Systems. The one-way tap is placed between a link from a switch to a subnet, as illustrated in the figure above.
The configuration reported in the Illinois report only works for standard Ethernet. Although the tap is capable of being used with full-duplex Ethernet, the researchers at the IITRI have determined that the presence of collisions could cause packet loss, or even the capture of wrong packets. In full duplex mode, this problem is exacerbated by increased throughput.
Filtering/Collection Computer
The computer which resides at the ISP is a Pentium-class PC installed with a 2 GB Jaz Drive, a standard 10/100 Mbps Ethernet adapter, a modem, Windows NT, and the software package pcAnywhere, produced by Symantec. It connects to the one-way tap through its Ethernet adapter. It connects to an outside control/examination computer through a modem using a special telephone link. According to the Illinois report, the computer is installed without a monitor or keyboard.
Control/Examination Computer
Any computer may act as a control/examination computer, so long as it has installed on it: pcAnywhere, the DragonWare package including CoolMiner and Packeteer, a modem, and the proper keys and passwords to access the Windows NT administrator account, pcAnywhere, and the telephone link.
Telephone link
The filtering/collection computer communicates with the control/examination computer through a telephone line, which is installed especially for its use. The telephone line is protected by third-party devices from Computer Peripheral Systems, Inc; (CPSI) from their line of Challenger Security Products (CSP). The protection devices come in pairs; a Lock is a device attached to the phone line on the end of the filtering/collection computer, and a Key is another device attached to the phone line on the end of the many control/examination computer being used.
Figure 3: Carnivore Advanced Menu
"Carnivore software is a component of a software suite called DragonWare written by the FBI. The other components of DragonWare are Packeteer and CoolMiner, two additional programs that reconstruct e-mail and other Internet traffic from the collected packets." The software will be examined in two ways, first its functionality, and second its architecture.
Functionality
Carnivore's functionality can be broken up into 3 areas: Filtering, Output, and Analysis.
Filtering
The filtering system provided with the software is intended to take the large amounts of data passing through the tapped network stream and prevent the unwanted data from being stored. The software provides the user many different options for filtering and the combination of filters:
|
Fixed IP |
Can choose a range of IP addresses. |
|
Dynamic IP |
If not in fixed IP mode, one can choose to include packets from in either Radius or DHCP mode. |
|
Protocol Filtering |
One can choose to include packets from TCP, UDP, and/or ICMP in either Full mode, Pen mode, or none. |
|
Text Filtering |
One can include packets that contain arbitrary text. |
|
Port Filtering |
One can select particular ports to include (i.e. 25 (SMTP), 80 (HTTP), 110 (POP3)). |
|
E-mail address Filtering |
One can select to include packets that contain a particular e-mail address in the to or from fields of an e-mail. |
Output
The software produces three types of files when storing packets, files with extensions '.vor', '.output', and '.error'. The actual data collected from the network is saved in a .vor file. The '.output' file contains a human readable version of the settings used to collect the data in the corresponding '.vor' file. Finally, the '.error' file keeps track of any system messages that may have been generated during collection. The software does not prevent files from being stored on the local hard drive, but they are typically stored on the 2GB Jaz Drive attached to the system.
Analysis
The DragonWare package provides two programs to analyze the information stored in the '.vor' file produced by Carnivore.
Packeteer
This program takes the collection of IP packets in .vor files, reconstructs the TCP session, and creates a series of files that can be viewed with CoolMiner.
CoolMiner
This program can be set up to show only certain types of packets.
Architecture
The Carnivore software consists of four components: TapNDIS driver, TapAPI.dll, Carnivore.dll, and Carnivore.exe
TapNDIS (written in C) is a kernel-mode driver, which captures Ethernet packets as they are received, and applies some filtering. The source is divided into 13 files, 9 of which are borrowed intact or with only minor changes, from WinDis 32 sample programs. 2 others were generated by Microsoft Developer Studio. The remaining two files contain all the logic for driver-level filters and for writing data to a file. The IITRI assumes this to be the core of the Carnivore implementation.
TapAPI.dll (written in C++) provides the API for accessing the TapNDIS driver functionality from other applications.
Carnivore.dll (written in C++) provides functionality for controlling the intercept of raw data. This is where pen mode truncation occurs.
Did you understand any of that? I do but, this is my job.
All you really need to know is this part: "At this point, the case agent can retrieve the intercepted information remotely as it is received by Carnivore"
The FBI perform's its own minimization. That is, "control of the information is removed from a third-party source". The FBI and other agencies such as DOJ and DEA have no clients to protect. That means they have no legal or lawful reason to actually perform minimization, the 1st and 4th amendments be damned! Remember Reagan's sarcastic joke "I'm from the government. I'm here to help"??? You just have to trust they are of the highest morals and operate with pure and nuetral ethics.
Has there been any news of late that would give you a reason to trust them?
Well, you shouldn't as the FBI IITRI review of Carnivore states “the statutory suppression remedy available for illegal interception of other communications in Title III is not extended to electronic communications… the data gathered would not automatically be thrown out as evidence.”
Wow?! you mean you could just keep the information and use it later whenever it suited you? Courts said "Yeah, they can do that".
Thanks to Swordmaker for the ping!!
OOPS Indeed!!
This means every conversation and email made by Hillary Clinton on her phone was intercepted.
The Russians and Chinese know where Clinton and obama were during the Benghazi attack but we are not allowed to.
These guys didn’t present anything new, that I can see.
We knew about these issues for years and after The Telecommunications Act of 1996, SS7 was going to be an issue as follows:
2001 IEEE Proceedings United States Military Academy, West Point
http://www.daairatoulatif.com/admin/upload/10.1.1.121.6125.pdf
The protocol was originally designed for a closed telecommunications community; therefore, it possesses limited authentication facilities. However, deregulation now requires
phone companies to provide SS7 connections to any entity for a modest fee.
The Internet-PTN convergence allows attackers inroads
via entities with poorly secured SS7 networks.
ISDN connections are also points of unauthorized entry.
Once access to a PTN is gained, an attacker can perpetrate
modification, fabrication, interception and interruption on a potentially massive scale.
Fort example, during a terrorist bombing incident, an attacker can modify en- tries in a call forwarding database to re-route all phone calls to emergency services, disrupting them and possibly increasing the number of casualties
Thank you, Vendome. Your detailed history of 1st and 4th A. violations using ISP providers as the intercept point is both stunning and depressing. Totalitarian. We’ve been reading about these usurpations here on FR since its early days. Now you’ve put it all together. But what can we do to keep our lives private?
T.W.
Use encryption from inception of any communications or transmission you believe is important.
Just Look up TOR and also the history of anonymizing on the internet.
There are encryption tools for your devices, storage, etc.
SS7 and Internet don’t play well together.
BTW, Google serves up the Internet as they want you to see it. Kind of like POS AOL. It’s their version.
Alternative search engines give you greater access to the internet and are more secure as well. Think DuckDuckGo
Technology is, in its nature, developing based on current progress. Sometimes it is worth going back to the blue box era to discover something in today’s world. More or less recent scandals involving NSA’s practice to track, listen, and intercept communication without authorization made a splash, but not many took the time and effort to understand the magic behind this. Kudos for Washington Post: they went looking into this.
After little research taking me 50 years back in time, I will explain the technology behind and demonstrate that one does not need NSA resources or an army of hackers to repeat the trick on you.
The calling protocol that is used for one network to “talk” to another was developed in 1970’s and is called SS7. The protocol was somewhat refined around 2000 with a SIGTRAN specification, which made it IP network environment friendly. This, however, meant that all the weak links on the upper level of SS7 infrastructure were carried over.
Picture that the communication is made possible not by one, but in fact several hundreds of links, which result a chain that triggers phone on the other end of your call ringing. Referencing back to my earlier post on “Evolution of Authentication”, I would like to demonstrate that the same principle of security level assessment applies here: the chain is as safe as it’s weakest link.
During my time in Deutsche Telekom Consulting, I was involved in review of a number of networks (fun times included climbing down sewers following copper lines laid there in 50s-60s-70-s, which were used by corporations and governments in 2003-2004 and likely still to be in place). The hardware and software providers vary from network to network and are extremely segmented, which leads to a simple result: they have to keep their chains wide open to make sure that the next chain link can integrate.
So did anyone know about these vulnerabilities until 2013? In short: of cause. First reference I have discovered dates back to a report published in 2001, which I (admittedly) could not read to full extent due to my neglected Swedish. Google Translate may help you.
It was also made public by Tobias Engel during a Chaos Computer Club Congress held in 2008, when Tobias made a live demo of tracking abilities:
And, of cause, it was most widely reported during NSA scandal involving Edward Snowden, that revealed how NSA was exploiting the weaknesses of SS7 to create a very intelligent and complex series of solutions enabling them to simultaneously track and analyze millions of citizens without their nor carrier’s knowledge or approval.
So what does one require to make this work? The list is quite short:
Apart from the computer itself, remaining ingredients are free and publicly available on the Internet.
It may have slipped under your radar, but apparently now there is a legal way to use this technology to track anyone worldwide, and NSA is not involved at all: the service offering is open to public and provided by a NASDAQ listed Verint Systems Inc. (NASDAQ: VRNT). In their product description, which was made public, they refer to the system as “Skylock”. During search I even stumbled upon a certification of encryption capabilities of this product by NIST (certificate scan).
Verdict? Abandon illusions of privacy if you still had them.
Sources:
Disclaimer: this article is a warning to regular citizens about low technological barrier protecting their privacy specifically in relation to mobile phone hacking using ss7 protocol. It is not a guide to hack-a-phone. I will intentionally leave a few aspects uncovered. I urge all readers NOT to use this technology and hope that the solution to restrict this ability to track phones will be implemented soon.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.
