|
|
 |
|
|
|
register |
bbs |
search |
rss |
faq |
about
|
|
|
meet up |
add to del.icio.us |
digg it
|
|
|
|
2600 article/part regarding a flaw in the phone sy
NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.
The following short article appeared in the Winter 1991-92 issue of "2600", a
magazine that bills itself as "The Hacker Quarterly". (Their Internet address
is [email protected]) I thought it might be of interest, so I'm passing it
along. Enjoy!
-- Urizen
"U.S. Phone Companies Face Built-In Privacy Hole"
Phone companies across the nation are cracking down on hacker explorations
in the world of Busy Line Verification (BLV). By exploiting a weakness, it's
possible to remotely listen in on phone conversations at a selected telephone
number. While the phone companies can do this any time they want, this recently
discovered self-serve monitoring feature has created a telco crisis of sorts.
According to an internal Bellcore memo from 1991 and Bell Operating Company
documents, a "significant and sophisticated vulnerability" exists that could
affect the security and privacy of BLV. In addition, networks using a DMS-TOPS
architecture are affected.
According to this and other documents circulating within the Bell Operating
Companies, an intruder who gains access to an OA&M port in an office that has a
BLV trunk group and who is able to bypass port security and get "access to the
switch at a craft shell level" would be able to exploit this vulnerability.
The intruder can listen in on phone calls by following these four steps:
"1. Query the switch to determine the Routing Class Code assigned to
the BLV trunk group.
"2. Find a vacant telephone number served by that switch.
"3. Via recent change, assign the Routing Class Code of the BLV
trunks to the Chart Column value of the DN (directory number) of the vacant
telephone number.
"4. Add call forwarding to the vacant telephone number (Remote Call
Forwarding would allow remote definition of the target telephone number
while Call Forwarding Fixed would only allow the specification of one
target per recent change message or vacant line)."
By calling the vacant phone number, the intruder would get routed to the
BLV trunk group and would then be connected on a "no-test vertical" to the
target phone line in a bridged connection.
According to one of the documents, there is no proof that the hacker
community knows about the vulnerability. The authors did express great concern
over the publication of an article entitled "Central Office Operations--The End
Office Environment" which appeared in the electronic newsletter LEGION OF
DOOM/HACKERS TECHNICAL JOURNAL [sic]. In this article, reference is made to the
"No Test Trunk."
The article says, "All of these testing systems have one thing in common:
they access the line through a No Test Trunk. This is a switch which can drop
in on a specific path or line and connect it to the testing device. It depends
on the device connected to the trunk, but there is usually a noticeable click
heard on the tested line when the No Test Trunk drops in. Also, the testing
devices I have mentioned here will seize the line, busying it out. This will
present problems when trying to monitor calls, as you would have to drop in
during the call. The No Test Trunk is also the method in which operator
consoles perform verifications and interrupts."
In order to track down people who might be abbusing this security hole,
phone companies across the nation are being advised to perform the following
four steps:
"1. Refer to Chart Columns (or equivalent feature tables) and validate
their integrity by checking against the corresponding office records.
"2. Execute an appropriate command to extract the directory numbers to
which features such as BLV and Call Forwarding have been assigned.
"3. Extract the information on the directory number(s) from where the
codes relating to BLV and Call Forwarding were assigned to vacant directory
numbers.
"4. Take appropriate action including on-line evidence gathering, if
warranted."
Since there are different vendors (OSPS from AT&T, TOPS from NTI, etc.) as
well as different phone companies, each with their own architecture, the
problem cannot go away overnight.
And even if hackers are denied access to this "feature", BLV networks will
still have the capability of being used to monitor phone lines. Who will be
monitored and who will be listening are two forever unanswered questions.
|
|
|
To the best of our knowledge, the text on this page may be freely reproduced and distributed.
If you have any questions about this, please check out our Copyright Policy.
totse.com certificate signatures
|
|
|
About | Advertise | Bad Ideas | Community | Contact Us | Copyright Policy | Drugs | Ego | Erotica
FAQ | Fringe | Link to totse.com | Search | Society | Submissions | Technology
|
|
|
|
|
|
