phrequency_2002
_______
ÞÛÛÛÛÛÛÛÛÜ
ÞÛÛßßßßßÛÛÛ
ÞÛÛ ÞÛÛ
ÞÛÛ____ÜÛÛÛ "Telefono Modularr Spectacularrrr"
,ÜÜÜ ÞÛÛÛÛÛÛÛÛÛ
ÞÛÛÛÛÛÝÔßßßßßß'_
ÞÛÛÛÛÛÛ ÛÛÛÛÜ ÞÛÛÛ ÜÛÛÜ ÜÛÛÛÝ ÛÝ ÞÛ ÜÛÛÜ ÞÛÜÛÛÝ ÜÛÛÛ_ÞÛ ÛÝ
ÞÛÛÛÛÛÛ ÞÜ ÛÝ ÞÛ ÞÛ"'ÞÛ ^ÛÝÞÛ ÛÝ ÛÝ ÞÛ ÞÛ ^ÛÝÞÛÝ ÛÝ ÛÝ ßß ÛÝJÛ
ÞÛÛÛÛÛ ÞÛÛ_ ÛÝ ÞÛ ÞÛ ÛÛßßßÝÞÛ ÛÝ ÛÝ ÞÛ ÛÛßßßÝÞÛ ÛÝJÛÝ ÞÛÞÛ
'ÛÛÛÛÛ ÞÛÛÛ ÛÝ ÞÛ ÞÛ ÞÛÜÜÛ ÔÛÜÜÛÝ ÞÛÜÛÛ ÞÛÜÜÛ ÞÛ ÛÝ ÛÛÜÛÛ ÛÛ
ßÛÛÛÜÜÜÛÛÛÛ ß' Ôß Ôß "ßß "ß"ÛÝ ßß"ß "ßß ß "' ßßß ÛÛ
ßÛÛÛÛÛÛÛÛÛ, ÛÝ ÛÛ
"ÛÛÛÛÛÛÛÛ'
ÔßÛÛÛÛß Phrequency Issue #2 -------> 18/02/02
CONTENTS
#+#+#+#+
Introduction .................................... Phreakau Team
Hacking Optus Voicemail ......................... Zaleth
RIM Identifiers ................................. Zaleth
Updated FAST Map ................................ Zaleth
Credit Phone (B1/B2) FAST Block Workaround ...... Zaleth
Le Fone : Epic Journey of a Phreak .............. No Protocol
Features and Telecommunications Security ........ Marlinspike
Cable Pressurisation and Alarm Systems .......... Dataclysm
Locating Telstra Exchanges ...................... Dataclysm
Automatic Line Testers in Australia ............. Dataclysm
Australian Phreaking News ....................... Phreakau Team
CONTACTS
#+#+#+#+
To send feedback regarding one of the articles in this ezine
please select from one of the following email addresses :
Dataclysm - dataclysm@tokyo.com
Marlinspike - p0lter_g@yahoo.com
Zaleth - zaleth@hushmail.com
IMPORTANT SITES
#+#+#+#+#+#+#+#
Here is a listing of links to sites that contributors maintain and
where further information can be found :
http://phreakau.linuxphreaks.org/
= Phreakau Homepage
http://forum.onecenter.com/ausphreak/
= Public Australian Phreaking Forum
http://www.zaleth.f2s.com
= Zaleth's Phreaking Homepage
http://dataclysm.wiggerz.net
= Digital Infraction Homepage
INTRODUCTION
#+#+#+#+#+#+
If you only knew how much effort went into getting this issue out. The
good thing is we're not a one night wonder anymore. This issue has
more instructional articles than the last. I have a feeling this issue
will become required reading for this and future generations of
phreaks. Its all relevant to phreaking in .au, its all original and
each article took vast amounts of blood and sweat to research. We are
also pleased to announce that every writer for this issue is a
certified sociopath with deep seated and complex problems stemming
from far beyond a mere desire "to be bad". Don't believe me? Read on.
I feel so grateful to have the opportunity to work with such talented
and fine fellows. Just remember, we put this ezine out to increase the
skill and knowledge of Australian phreaks. Don't just leech this
information. Use it to build on with your own research, learn from
what you can see of our techniques of gathering information. You won't
know what it is all about until you do your own research. It may seem
hard, but little will you know that you'll look back on those times as
some of the best in your life. Enjoy.
Propz to Forbze for the logo. Now we are l33t.
Just one last thing before we continue. If you are one of these crack
toking rebels that take us for nothing more than over-glorified beige
boxers and/or you are reading this ezine with nothing more than the
intention of finding a beige boxing like technique to exploit and be
k-rad with, you need go no further than the following instructions :
Beige Box ----------------------<======================= Phone Line
| Extension ----> \\\\ \\\\
Ring 12722199 \\\\_}====< Attach to ur testicles
kthx.
#+#+#+#+#+#+#+#+#+#+# HACKING OPTUS VOICEMAIL #+#+#+#+#+#+#+#+#+#+#+#+#
- Zaleth -
Recently a friend of mine purchased a mobile from Optus and was also given this
booklet called "Optus Mobile Digital" which gave me the information Optus gives
its mobile phone customers information about getting their own voice mail box
(VMB).
I will keep this tutorial short, here are a few steps on hacking into the
target's VMB, mainly covering the authentication process.
>From a Touchtone phone (DTMF Tones, Not Pulse) do the following:
Dial: 0411 000 321
When Prompted type in your targets mobile number (04xx xxxxxx) and press Hash
(#).
You will now get prompted for a pin, this may be difficult, so here are the
defaults:
0000
12345
If the person has setup up their mailbox correctly they have chosen a pin from
4 to 9 digits, now people have a habit of using the code, 123456789 to fill up
the max digits thinking no one will guess it or 987654321 & 098765432.
It is relatively easy to find the phone pin by going through these steps,
Say the last six digits of the mobile are 123456 then the pin maybe 123456.
Say the person lives in the Postcode 9898 then their pin maybe 9898.
Another goodie I found was people tended to use years which held memories such
as 1999, 2000 and 2001. So check for pins which use year dates.
If you know the target well and they often use the net and have a good idea of
what 'leet talk' is then check 31337 & 313370 I have found one person using
this. Aren't they shockers.
Here are a few more tips MN (Mobile Number(Will refer to the last 6
digits)).
MN - 1
MN + 1
MN (1st Digit) + 1
MN (1st Digit) - 1
(All the way to 6)
Hopefully that was some help, as you can tell you're on your own for finding
the pin.
The Menu:
Voice Prompt Guide-
[4] Record your Greeting
[6] Record your Name
[7] Set your pin
[8] User Options
[9] Exit the System
[0] Help
If Voice Mail starts playing messages wait till the message finishes and you
will get prompted with the following:
Voice Prompt Guide-
[6] Return the call [5] Save the message
[3] Delete the Message [7] Replay the message
If you want to keep eavesdropping on this account avoid changing pins,
otherwise the person could ring the support line and get it changed.
Covering your tracks, if your hacking someone else vmb make sure you're not
calling from your phone or anyone else's you know otherwise you will be found
out.
#+#+#+#+#+#+#+#+#+#+#+#+# RIM IDENTIFIERS #+#+#+#+#+#+#+#+#+#+#+#+#+#+#
- Zaleth -
You may be walking the dog, driving in a car, riding your push bike (and a
hard earned thirst needs a cold beer and the best known beer is VIC, Vic
Bitter.) and you may see a RIM. Not only are RIM's on the ground they can be
found up in the air on power poles (Feeling lucky?).
Over last year I collected a few RIM identification codes. I haven't got every
single code nor do I have every identification type.
_____________________________________
| Pair Gain System | Category |
|==========================|==========|
| ALCATEL RCM | R1 |
| SCADS | P4 |
| SCADS RADIO | P6 |
| TELSPEC 2 DPGS | N4 |
| TELSPEC 4 DPGS | P2 |
| RAM8 PHASE 1 | B5 |
| RAM8/2 | B7 |
| EXTEL6/16MLC | B2 |
| INTEGRATED RIM | AA |
| NON INTEGRATED RIM | ZZ |
| RIM | C1 |
| TELSPEC6/15 MLC | B1 |
'====================================='
A few more RIMs I would like to grab are: AE, X1 & A1
X1's are seen everywhere (not the smartphone).
#+#+#+#+#+#+#+#+#+#+#+#+# UPDATED FAST MAP #+#+#+#+#+#+#+#+#+#+#+#+#+#
- Zaleth
(Field Access to SULTAN Testing)
During June last year Nelix and myself saw a very old map of FAST. We looked
around to see if there were any more up-to-date maps with little success, so
Nelix and I bring to you the current map of FAST.
ANT1 - Analogue Network Terminator 1
____FAST_____
/ \\\\
|¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯|
[1] Test this line [2] Other (Test another line)
| "Reads out number" | "Enter full national number
(1) Sultan Test (9 or 10 digits) then # if
(2) Ringback Test you make a mistake press ** "
| (1) Right number (2) Wrong number
(4) Line and ANT1 (1) Sultan Test
(5) Technical support (3) To activate an ANT1
and pair gain system (4) Line and ANT1
(5) Technical support
and pair gain system
#+#+#+#+#+#+# CREDIT PHONE (B1/B2) FAST BLOCK WORKAROUND #+#+#+#+#+#+#+#
- Zaleth -
I was at the airport one afternoon examining a B2. I picked up the receiver and
it was asking my to swipe a plastic card, I looked around the keypad and
noticed a SERVICE CALL button so I pressed that and I got a dial tone.
What we have done is enabled a direct dial out of the phone to service only
calls excluding 127x prefixed numbers. So I dial FAST and try an ID & PIN but
when I press one number I get cut off. So what I did next was hang up, picked
up the receiver pressed service call and dialled FAST when I got through I held
down service call and input the ID & PIN and I was in.
You can also use a tone dialler for the authentication process but since this
was an airport with hundreds of camera's I thought it was probably best not
too. You can use the iPrimus DCX on credit phones as well.
So here are the steps:
1] Pick up the receiver.
2] Hold down SERVICE CALL button.
3] Dial in the service number (e.g. DCX &/or FAST).
4] When asked for Authorisation hold down the SERVICE CALL button and
input what ever is necessary.
Enjoy this for whatever reasons :)
#+#+#+#+#+#+#+# LE FONE : AN EPIC JOURNEY OF A PHREAK #+#+#+#+#+#+#+#+#
- No Protocol -
Thanks to my mate Baldy (for access to tools I didn't have) & Others (no names
mentioned), for their zany brand of inspiration.
--------
Prologue
--------
Early 1990 the obsession to computing was under way, there were 3 different
types of PCs on our school grounds 8086, 80286 and a single Mac, which sadly
exist as of today. From basic computer exploration spawned many other
interesting underground activities, from DIY bomb making, basic forgery... to
the more mundane activities of vandalism & practical jokes, naturally
phreaking came along as well.
The journey was born from thoughts of stupidity to inspiration.
The idea, to steal a payphone.
Talk to many hackers provided useless yet entertaining theories on how this
could be achieved, from :
Chaining the fone to my van & driving off,
Smashing the fone up, to
Cutting the fone out using an angle grinder.
Each had huge implications counter to a guarantee of success.
--------------------------
PRIMARY TARGET ACQUISITION
--------------------------
In order to successfully complete such a task there were a few fone
selection criteria that had to be met :
1. the fone must be a fair distance away
2. it must be new (personal choice)
3. it must not be too close to any houses or main roads
I talked to my friend about my upcoming 'stunt', he told me of a payphone in
his area that fit the above criteria, all I had to was go get it.
-----------------------
DAY 1 - SATURDAY 3.30AM
-----------------------
The air was crisp & rigid, the eagerness of the mind, a bottle of Jolt & 2
layers of clothing made it almost non existant, it was 3.30am on a Saturday
morning.
With a specific fone located & no plan in mind, today's objectives were
simple, remove as many screws & bolts as possible & look the fone over for
possible entry points.
Later on in the night I started drawing plans in order to aid me to some
conclusive methods.
(Available with this document If I decide to release it.)
With basic drawings & some possible ideas the plan was now set;
"There are not too many ways to steal the fone by itself, so I'd have to
steal either the whole payphone booth or just the back section, you can guess
which I chose."
My only concern was cutting the power for the light & fone lines.
I know that the gestapo put alarms on the fones which sound when if there is
any damage done to them, so the wires would have to be the last thing to go.
---------------------------
NEXT WEEK - SATURDAY 1.00AM
---------------------------
There where a few too many cars on the road that night for my liking, a car
pulls up, its my mum's ex boyfriend thinking I've broken down. SHIT!. In
order to kill some time I decided to go trashing for a few hours & then return
back when the din had subsided.
"MEANWHILE BACK AT THE FONE"
Like trying to climb Everest in a suit of armour and a pair of tight jeans,
I managed to climb on top of the box using a milk crate & a bin close by,
removed the 2 back bolts, loosened the front 2 & looked for any additional
screws on top, these came out suprisingly easy.
---------------
SATURDAY 1.00PM
---------------
During the day I did some measurments to my van to see if the fone booth
would fit in & how close I could back up to the booth to stick it in; 1.3m
close & 2.2m in, hmmmm excellent.
-------------
SUNDAY 2.00AM
-------------
Darkness, rain, air colder than dry ice, its 1.40am, warm & tired, "to go or
not to go?, that is the question". I, unlike this generation of giveruppers,
fought the temptation of staying in bed & decided I should press on.
To pass the time till 2am, I read yet another inspiring chapter of cyberpunk.
I've come this far, Hey! Why the fuck not.
That night I came across a snag, 2 screws that hold the back on were slightly
worn & damaged making it harder to remove them, torn between whether or not
to give up, I pressed on with the others.
In order to avoid suspicion that the fone was being removed, I prepared a few
screws on Saturday by cutting the heads off some from last week's escapade &
superglued them back into place as to give the illusion that the box was
solid, yet was hanging by a thread.
2 1/2 hours later, after finishing tonight's objectives, I decided to go
home, a kid walked passed just after I finished for the night (phew, close).
-----------------
WEDNESDAY 10.00AM
-----------------
One day prior to WED my friend noticed a kid leaning on the inside of the
fone booth as he was driving by.
"This would be good, for he would certainly loosen the fone for the big day."
Surely enough I was right, I was contacted during the day about the fone, my
mate noticed the whole side had completely detached from the back (NOT GOOD),
as surely the gestapo would march back into Poland & 'fix it'.
In order for it not be fixed, I managed to talk my friend into going to the
scene of the crime during the day & cleaning the mess up.
Thursday, pre Friday jitters are trying to beat me from D-Day. Its not that
I'm afraid of getting caught, its more a case of
"What happens the day after when & if I pull this off?"
"What project will come next?"
In some ways I feel as though I'm retiring, yet it is only the beginning.
A hilarious scenario enters my head, what if I attached an old rotary fone to
what remained of the booth, would people be so stupid as to use it?
Unfortunately I couldn't find a spare fone for this little joke.
-----------------------
BIG DAY - FRIDAY 1.00PM
-----------------------
Collected caution tape from down the road, so people will get the impression
that the fone is being fixed & won't report anything. "Chances are that the
fone will stay this way for a few weeks before anything gets done to it."
The alarm was set to go off at 2am but woke up at 1 so I decided to do a pre-
trash to pass the time till around 2.20am, didn't find much.
Some trashers had already done the area & left one of my
favorite bins upside down, garbage strewn everywhere.
ASSHOLES, "The point of trashing is to get as much stuff
as possible over a long time". In order to keep this place
available I cleaned the mess up which wasn't very pleasant.
------
2.20AM
------
I parked the van in a park several blocks from the fone so as to avoid too much
exposure near it. The trek to the site was long, many thoughts paced through my
head. Should I? Shouldn't I?
The problem screws where the only things left holding the fone booth together
which I managed to remove with some force. A bit of prying & the booth started
to wobble as though an earthquake were a happening. A small black spider
scuttled away. Just as well.
The moment of truth had arrived, feeling really sweaty I trekked back to the
van & pondered whether or not to remove my number plates. I'll only be 5 min
at the most, why trouble my escape?
Backed my van behind the fone, to roughly 1.3m as previously measured, & left
the handbrake off so I could push it to suit.
I tried to lean the fone panel on an angle so it would support itself on what
remained of the box, but the sheer weight was too much. The booth wobbled, the
back cracked out from under the plastic domed roof on top & onto my foot,
OOOWWW! not wanting an accident involving my back windscreen I pushed the van
to another meter & tried to drop the beast to the ground, but the power cable
just wouldn't let it.
Van back at 1.3m, using all my strength I lowered the beast into the back
with me underneath & onto a couple of PVC tubes I'd prepared earlier.
SHIT I thought, its too late to back out now as the fone line had severed
when I lowered it.
An image of Police car pulling up with lights flashing & bright light from a
flashlight enters my mind.
I grabbed my mum's tree secateurs from out the front seat & cut the power
cable, sparks burst everywhere like fireworks on a new year. Not wanting to
hang around & tape the box up liked I'd planned to do, I quickly pushed the
booth into the back & drove off.
"SHIT, I did it YYYYYYYYYYYEEEEEEEEEEHHHHHHH!!!! I'm screwed Now, WOOOHOO!!!"
------------
1 WEEK LATER
------------
Feeling EXTREMELY Paranoid! Peering out my window every time a car passes.
-------------
2 Weeks Later
-------------
I've realized that if anyone knew I did it, I would have had a visit by the
gestapo by now.
Its now sitting on my desk fully operational. I regret not filming the event.
XX/XX/0X
Diagrams of the X2 and screws can be found at the phreakau site :
http://phreakau.linuxphreaks.org/
Thanks to Zaleth for the computerized version.
#+#+#+#+#+#+#+# FEATURES AND TELECOMMUNICATIONS SECURITY #+#+#+#+#+#+#+#
- Marlinspike -
0.01 : Contents
=-=-=-=-=-=-=-=
0.01 Contents
0.02 Introduction
1.01 Common Channel Signalling
1.02 Switch(SSP)-Based Features
1.03 Intelligent Networking
1.04 So What Is Intelligent Networking, Really?
1.05 STP's - Signal Transfer Points
1.06 SSP's - Service Switching Points
1.07 IP's - Intelligent Peripherals
1.08 SCP's - Service Control Points
1.09 SCE - Service Creation Environment
1.10 SMS - Service Management System
1.11 IN Services
2.01 Interfaces
2.02 Concerns Over Interfaces
2.03 Customer Interfaces
2.04 Basic CPE Signalling
2.05 Undocumented Telstra Home/BusinessLine
2.06 Telstra Remote Access
2.07 Intelligent Peripheral-Based Interfaces
2.08 Security of PIN-Based Authentication
2.09 Customer Interfaces To The SMS
3.01 Telco Interfaces
3.02 OAM&P Interfaces
3.03 CCS7 Interfaces
3.04 Basic CCS7 Security
3.05 Basic CCS7 Vulnerability Taxonomy
3.06 Service Control Point Attacks
3.07 Signal Transfer Point Attacks
3.08 Service Switching Point Attacks
3.09 Intelligent Peripheral Attacks
4.01 What Are Feature Interactions?
4.02 Theoretical Examples of Feature Interaction
4.03 The Feature Interaction Landscape
4.04 Feature Interaction Causal Classification Approaches
4.05 Feature Interactions In The Australian Phone Network
5.03 Conclusion And Further Research
0.02 : Introduction
=-=-=-=-=-=-=-=-=-=
Like it or not, a part of your security, whether you are a large
corporation, small business or home user, is outsourced. Think about this,
in the OSI network model you have a protocol stack and at the bottom is the
Data Link Layer. You think that layer is secure? Nothing can influence and
indeed completely control that layer, route it to wherever, insert data,
interrupt, monitor that layer at will? You are wrong. The data network that
is the telecommunication system controls the media you use for data transfer
and communication. Its security is your security.
When you look at technological advances in telecommunications systems over
the last 20 years you think digital switching and common channel signalling.
The introduction of common channel signalling and its outmoding of in-band
signalling greatly increased security of the telecommunication network. Blue
boxes and the like became obsolete. However, with the introduction of new
technology comes new capability. Telecommunication companies are always
quick to exploit new capability of the phone network to offer value added
(hence revenue generating) services to the community. Extra features in the
telephone network are those value added services.
A feature is a service that supplements or modifies the basic POTS service
that we know and love. Typical examples of features include Call Waiting,
Call Forwarding Unconditional & Calling Card Calling.
In the last decade a significant advance in offering new features is
Intelligent Networking. As a result of this advance many features have been
streamlined and many more features are on the way. This article discusses
the security ramifications of offering features in a phone network with some
emphasis on the use of Intelligent Networking to do so.
This article has four appreciable sections. The first describes the
technology involved, pay attention here as the material is necessary for
understanding the rest of the article. The second section describes the
customer interfaces to features, how they work and their security
vulnerabilities, the third discusses telco interfaces and goes into security
of the CCS7 protocol. The fourth and final chapter details a fascinating
field of telecommunication security that stems from the use of features,
feature interactions.
We will follow the concept of "give a man a fish, feed him for a day. Teach
a man to fish, feed him for life". That is, I will present some working
examples of exploits, but the article is based around getting you to
understand how the exploits work and how to locate, identify and exploit
new vulnerabilities yourself.
This article is the result of around 3 months worth of research and
writing and formed from information gathered from around 50 - 100 obscure
academic and research papers and hands on experimentation. I've learned a
lot from my research on this subject and I've tried to include all the
juicy stuff here so I hope you enjoy it.
1.01 : Common Channel Signalling
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Before Intelligent Networking, the introduction of Common Channel
signalling was one of the most significant upgrades to the PSTN. That is,
the upgrade from analogue signalling between exchanges to digital
signalling. The basic concept of Common Channel signaling can be depicted
as such :
_____ _____ ---- : Are CCS7 Links
| | | |
| STP |-------| STP | ==== : Are Voice Links
|_____| |_____|
/ \\\\ STP : Signalling Transfer Point
___/_ _\\\\___ - Data switching point.
/ \\\\ / \\\\
| SSP |=============| SSP | SSP : Service Switching Point
\\\\_____/ \\\\_____/ - Telephone Exchange.
Single lines are CCS7 links and Double lines are voice links. In models
previous to this one, voice and signalling information were transmitted
on the same single trunk. This had a number of security and efficiency
ramifications.
We know why it had security ramifications, regular users ended up sending
signalling information along with voice. It was the same channel, so they
were able to. It was less efficient because an entire voice link needed to
be established whether the call could eventually be connected or not. If the
end line was busy the entire process would generate no customer payment,
but would incur costs. Using data to set the call up cuts these costs.
The way this model works is, when someone wishes to place a call, their
SSP, the originating SSP, generates a request for call setup, addresses it
to the SSP that services the called party, the terminating SSP and then
sends the request to its nearest STP, which forwards the request to the
terminating SSP. If the call is able to be completed, there is a bit of an
exchange of data and the voice trunk is then activated in both directions,
connecting the call. Its alot more complicated, but that's an overview. The
communications protocol used for the transfer of call setup data is CCSS7
Common Channel Signaling System 7 or CCS7 / SS7 for short. CCS7 is the
abbreviation Telstra and other Australian telco professionals use so that's
what I use. CCS7 was approved by the CCITT in November of 1980 and most
telecommunications providers around the world began migrating their networks
to it shortly afterwards. Within Australia, CCS7 was approved by Telecom/OTC
management somewhere in 1982 and after an intial testing and planning
period, cutover began around 1986.
The CCS7 protocol was designed with future intelligent networking
application in mind although when first implemented it did not include this
capability to any great extent. Intelligent Networking builds upon the CCS7
network to create the feature rich telephone network we know today.
1.02 : Switch(SSP)-Based Features
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Before we go on to describe IN and the concept of Intelligence in the
network, let us first examine the method by which many features were (and
still are) provided within the SSP (switch) itself.
The step directly before digital signalling between exchanges was the
introduction of exchanges with Stored Program Control. Before this, analogue
exchanges could be made to perform certain tasks only by hardwired logic. To
provide a new feature to customers, the switches would require hardware such
as relays and springs added to perform a new logical task. Obviously, this
was a slow process and changing or adding new services would take a long
time.
Stored Program Control exchanges perform logical operations just like a
modern computer. They have a central processor that runs commands. Service
Logic Programs (SLPs) and subroutines that build them, the programs that the
exchange uses to perform its logical tasks, are stored in memory and run by
the processor when required. Also, there is volatile storage, like RAM in a
personal computer for storage and manipulation of call 'state' information
and 'variables' regarding the call. There will also be volatile storage for
the processor to interrogate regarding things such as state information of
the switch, for example which lines and switches are busy and which are
available. Finally, the processor will have some kind of interface to the
electro-mechanical parts of the switch such as the voice circuits.
Typical exchange processing tasks would include the examination of digits
for routing analysis, or the selection of a path through the switching
matrix as two examples.
To build upon the basic capabilities of Stored Program Control exchanges,
more advanced Service Logic Programs can be implemented. These would include
such features as Call Waiting. As an example, a Call Waiting SLP would work
by detecting an incoming call to a number serviced by the switch, detecting
that the line to which that call is trying to reach is busy, detecting that
the Call Waiting feature is active on the line, returning a Call Waiting
'stutter' tone to the caller and sending an audible pip down the line to
alert the called party. If the called party signals the switch that they
wish to accept the call, the switch detects this signal (switch-hook flash,
followed by '2' etc.) and puts the current voice circuit on hold and puts
the caller through.
Other features that work in a similar way include Call Forward, Conference
Calling, Abbreviated Dialing and so forth.
An important fact to note here is that the times that a switch determines a
feature or SLP is to be run can map to the PICs (Points In Call) and TDPs
(Trigger Detection Points) described in [Section 1.06] relatively accurately.
For example, in the Call Waiting system described above, at the Terminating
Switch - Line Busy Check trigger detection point, the switch knew to check
for active Call Waiting and if so, run the Call Waiting SLP.
Being cognizant of this commonality will be especially helpful to us when
we go on to describe feature interactions between IN Based and SSP based
features.
Another type of Switch-Based feature are the CLASS (Custom Local/Load Area
Signalling System) features. These features are the same in terms of Service
Logic types, but are capable of receiving information from the incoming CCS7
packets. Namely the ANI (Automatic Number Identification - or caller's
number) from the ISUP (ISDN User Part) portion of an incoming CCS7 call. So,
the ANI of the caller becomes a variable used within the Service Logic
Program. An example, of this type of service would be CND (Calling Number
Display), Selective Call Screening (Based on an inputted table of calls to
deny/allow, stored at the switch) or *10# Call Return (The switch keeps an
accessible record of the last number to call each subscriber.)
These Switch Based features are marketed by Telstra as packages under the
title HomeLine or BusinessLine depending on the feature. They used to be
called EasyCall, but they are now called HomeLine and BusinessLine.
A large difference between these features and IN features is that
switch-based features are coded on the switch as the platform. This requires
specialised knowledge, standard hardware and cutover to many locations at
once, rather than one centralised location. It is obviously alot slower to
implement new Switch-Based services rather than new IN based services as we
will see.
1.03 : Intelligent Networking
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
While the CCS7 concept cut costs relating to call setup, there were still
many other benefits that could be realised from full exploitation of a
common channel signalling technology. For example, many corporations in
Australia have offices in diverse geographical locations around the nation
and may change or add locations quickly. They face the problem of
consolidating their communication systems. The profits of offering value
added services to customers that can be tailored specifically to individual
needs can be enormous. This is where Intelligent Networking came in. In
short, Intelligent Networking or IN, enables the telephone network to make
decisions on the routing and processing of calls autonomously. Not just that
though. It also allows the rapid addition of new methods it uses for
processing calls, new features, as required. Intelligent Networking was
phased into the Australian phone network by OTC in the early '90s.
We'll start with a topological diagram of an IN network and explain each
system, known as Network Elements or NEs, individually :
_____ IN Network Topology
| | =-=-=-=-=-=-=-=-=-=
| SCE |
|_____|
o
__o__
ooooooooooooooooooooooo| |ooooooooooooooooooooo
o | SMS |ooooooooooooooooo o --- : CCS7 Links
o oooooooooooo|_____|ooooooooooo o o
o __o__ o o __o__ o o === : Voice Links
o (_____) o o (_____) o o
o | | o o | | o o ooo : OAM Links
o | SCP |----------------------| SCP | o o - Usually X.25
o \\\\_____/ o o \\\\_____/ o o
o \\\\___ oooooo oooo ____/ o o
o _\\\\_o_ _o_/_ o o
o | | | | o o
o <------| STP |-----------| STP |--------------->
o |_____| |_____|-----\\\\ o o
oooooooo ______/ | \\\\ o o
_o_/_ ___/_ _\\\\o_ o
/ \\\\ / \\\\ | | o
<=======| SSP |================| SSP |========| IP | o
\\\\_____/ \\\\_____/ |____| o
o o
oooooooooooooooooooo
AIN : Acronym Intensive Network
AIN : Advanced Intelligent Network; Aka IN (The heading is really a crap
joke)
CCS7 : Common Channel Signalling No. 7 - Inter Exchange Data Signalling
Protocol
IP : Intelligent Peripheral - Usually a collection of IVR's
IVR : Interactive Voice Response - Automated voice system controlled by
DTMF tones
OAM : Operations Administration & Maintenance - Service system and links
aka OAM&P
SCP : Service Control Point - Database server for IN
SLP : Service Logic Program - Feature application, code run on nodes
SMS : Service Management System - Controls, updates and Maintains the IN
SSP : Service Switching Point - Telephone Exchange upgraded for IN
STP : Signalling Transfer Point - CCS7 Router
The acronyms are there as a reference. In the diagram, there are arrows
leading off on trunk lines and CCS7 links from an SSP and the STPs. This is
because this is all part of a network. The STPs are connected to other STPs
and the SSPs can be connected to other SSPs. Even though this ASCII diagram
sucks I have tried to adhere to the standards for representing each type of
Network Element. Circles for SSPs, Squares for STPs & Cylinders for SCPs :)
1.04 : So What Is Intelligent Networking, Really?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I know you haven't noticed this, but the question of what Intelligent
Networking actually IS can be hard to describe ;). This is because the
system is deliberately designed to have a multi-function capability. It may
be helpful at this stage to briefly describe a basic IN service. We'll use
placing a call to a 1800 number as an example.
OK, so a user connected to an SSP wishes to make a call to a 1800 number
which is terminated at another SSP. First thing is, the user dials the
number. As soon as this is done, logic in the SSP is triggered. It requires
the intelligence of the network to route the call. A CCS7 packet is
formulated, addressed to an SCP and sent to the nearest STP. The STP then
forwards the packet to the SCP. This is where the magic happens. The SCP
will examine the query and notice that a certain originating user
(presumably there is a field analogous to ANI in proprietary & application
specific TCAP component portion parameters) has called a certain 1800
number. The SCP then consults it's database, coming up with the number for
which this call should be routed to, the number that corresponds to the
called 1800 number. The SCP then constructs a reply packet with the number
to route the call to and sends it to the originating user's SSP. When the
SSP receives this information it can begin the process of routing the call
as a regular CCS7 call as shown above until the call is completed.
A more advanced function would be the SCP routing the call to a certain
number based on time of day, day of the week, originating ANI or any number
of other factors regarding the call.
The key concept to note here is that in use of the Intelligent Network, the
intelligence, or knowledge of how to route calls, is taken out of the SSP
and placed in the SCP or SCP's. In the network itself.
Let's now go a little deeper into each node or Network Element in the
Intelligent Network and use them to explain the more advanced concepts
behind Intelligent Networking.
1.05 : STP's - Signal Transfer Points
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
These are the simplest Network Element to understand, so I will start with
them. They are basically CCS7 routers. They route data over the CCS7
network. In the IN, their function is essentially the same as in regular
CCS7 networks. A node such as an SSP will address a CCS7 packet to another
node on the network and send it to an STP for routing. The STP will then
send it on it's way. IN uses the CCS7 protocol and existing CCS7 networks
as they are, it simply adds new elements and stretches CCS7's capabilities.
STP's are usually deployed in pairs. That is, two STP's basically do the
job of one of the STP's in the above diagram. Infact, where one STP is in
the above diagram, imagine there are two, doing the same job. This is
basically a redundancy measure. If one STP becomes congested or goes down,
the other STP can take up its workload.
STP's can also provide a function known as Global Title Translation.
Addresses on a CCS7 network are 3 byte values known as 'Point Codes'. Every
node or even STP knowing exactly how to route to every Point Code on the
CCS7 network is infeasible, especially when we are talking about sending a
packet to a node on another Telco's interconnected CCS7 network. This is
where GTT comes in. When a CCS7 packet is addressed, it's Point Code
address can be the nearest STP and the Global Title field can be filled in
to indicate the final destination. Upon receipt of this packet, the STP can
translate the GT to a Point Code and route the packet. In addition to this,
based on the Global Title, the STP can forward the packet to an
intermediate STP, or an STP that it knows will be better able to forward
the packet to its fully translated destination.
A Global Title is typically something like an untranslated 800 number,
calling card number etc. GTT translates a GT to point code and subsystem
number, which identifies a specific application at the destination
signalling point (ie. SCP).
The CCITT has assigned Australia initially with 16,000 point codes to use
for its network, with an additional 16,000 in anticipation of a second CCS7
network. These point codes have been distributed among the states for use in
the hierarchial by state CCS7 network in Australia.
1.06 : SSP's - Service Switching Points
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
These are the Telephone Exchanges in the network, your Ericsson AXE'es,
System 12 and DMS-100 exchanges all fall into this category. They are the
points of the network where calls terminate to customer telephone lines
and where voice lines to other SSP's / Exchanges are served.
To serve in an Intelligent Network, SSP's must be able to determine when
they require the intelligence of the network to complete the call. For this
purpose they are outfitted with systems that detect 'triggers' during
processing of calls.
Under IN two Basic Call Models (BCMs) were created complementary to the
existing call models in telecommunication systems. These BCMs model a series
of Points In Call (PICs) that an SSP goes through when processing a call.
Each PIC can have one or more Trigger Detection Points (TDPs) checked upon
reaching it, that is circumstances where special handling of the call may be
required. If a PIC has TDPs that indicate a need for special handling if
triggered, that TDP can be said to be active and the PIC to which it belongs
can be said to have an active trigger. The Basic Call Models, modelling the
PICs in a call come in the Originating Basic Call Model and the Terminating
Basic Call Model which look something along the lines of :
Originating Basic Call Model Terminating Basic Call Model
=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-=-=-=-=-=-=-=-=-=-=-=-=-=-
O_NULL T_NULL
| |
AUTHORISE_ORIG_ATTEMPT AUTHORISE_TERMINATION
| |
COLLECT_INFORMATION SELECT_FACILITY
| |
ANALYZE_INFORMATION PRESENT_CALL
| |
SELECT_ROUTE T_ALERTING
| |
AUTHORISE_CALL_SETUP ACTIVE
| |
SEND_CALL RELEASE_PENDING
|
O_ALERTING
|
ACTIVE
|
RELEASE_PENDING
These PICs will correspond to Trigger Detection Points like :
INFO_COLLECTED & COLLECT_TIMEOUT for COLLECT_INFORMATION. Essentially you
will have some times in the call that information can be tested like :
* Immediately after phone is taken off-hook
* After some of the digits are collected (ie. if a long distance prefix is
entered on a phone line that has STD barring).
* After all the digits have been collected and can be analysed.
* When the route to the destination has to be determined (ie. may require
assistance if the route is congested.)
* Check whether terminating resources are available.
* Present call (for example to determine if the called party will accept a
call from the calling ANI).
* Line busy check (eg. maybe calls can be routed to an alternate number in
this instance, such as call diversion or message bank).
* Line answer check (ie. did the call timeout?).
If an active trigger is detected by the SSP, a request for information on
how to process the call is sent by TCAP to the appropriate SCP. As you can
see from the number of PICs above, there is considerable opportunity for
intelligent routing of calls.
In the big picture of the Intelligent Network, the PICs that have active
triggers depend upon the type of service and the Service Logic Program (SLP)
that the SSP is playing a part of.
1.07 : IP's - Intelligent Peripherals
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Often, an Intelligent Network feature will require additional information
from the customer besides the number they have called in order to route the
call. Usually an IVR (Interactive Voice Response) system can be used for
this purpose. A common application of IP's is to play a message and wait for
input from the caller via their DTMF keypad on their phone. For example, a
subcriber to a prepaid calling card service can call his service's access
number, an active trigger will be hit at his SSP and the call will be routed
to the SCP, the SCP then routes the call to an IP that plays a message
requesting that the customer enter his calling card number and PIN on his
phone keypad, it can then collect the entered digits and request
verification from the SCP. Once the card number and PIN are verified by the
SCP and the corresponding message sent to the IP, the IP can prompt the
caller for the number they wish to call. Another example would be
messagebank services.
IP's can also play a part during the immediate off-hook point in call if
voice activated dialling is supported. This is one instance where an SSP
might encounter an active trigger at this first PIC. The call is initially
routed to the IP for collection of the number, the caller says for example
"Dial Miss September" and the digits are eventually sent to the SSP so it
can continue processing the call.
The voice line from an IP is usually an ISDN line hanging off one SSP or
another in the network.
It should be noted here, to avoid confusion, that an Intelligent Network IP
is not the only system capable of IVR around. Customer terminating equipment
such as a PABX is perfectly capable of generating complex IVR queries from a
connected customer and processing it on its own. A PABX can't interface with
the IN however.
1.08 : SCP's - Service Control Points
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Often referred to as the brains of the Intelligent Network, these are the
database servers that hold the information on routing of special calls.
These are not switches or routers, usually they are commercially available
computing machines such as SUN, running operating systems such as UNIX (Sun
hardware and UNIX seem popular with Telstra anyway :p)
Queries and Replies between an SSP and an SCP (and IP and SCP) after a
trigger hit are performed using CCS7 TCAP, Transaction Capabilities
Application Part. TCAP messages use SCCP (Signalling Connection Control
Part) for transport. SCCP is where the Global Title or Point Code +
Subsystem Number are sent. A TCAP message is comprised of a Transaction
Portion and a Component Portion.
The Transaction Portion contains information regarding what type of
information is being transferred. This information is known as the package
type, there are seven different package types. I may as well include them
here :
(*) Unidirectional: Transfers component(s) in one direction only (no reply
expected).
(*) Query with Permission: Initiates a TCAP transaction (e.g., a 1800
query). The destination node may end the transaction.
(*) Query without Permission: Initiates a TCAP transaction. The destination
node may not end the transaction.
(*) Response: Ends the TCAP transaction. A response to an 1800 query with
permission may contain the routing number(s) associated with the 800
number.
(*) Conversation with Permission: Continues a TCAP transaction. The
destination node may end the transaction.
(*) Conversation without Permission: Continues a TCAP transaction. The
destination node may not end the transaction.
(*) Abort: Terminates a transaction due to an abnormal situation.
As you can see, a query to the SCP may result in a response or may result
in a finite set of conversation messages exchanged between the SSP and SCP.
The Component Portion contains components. There are six kinds of
components (again literally ^C^V'ed from the specs) :
(*) Invoke (Last): Invokes an operation. For example, a Query with
Permission transaction may include an Invoke (Last) component to
request SCP translation of a dialed 800 number. The component is the
"last" component in the query.
(*) Invoke (Not Last): Similar to the Invoke (Last) component except that
the component is followed by one or more components.
(*) Return Result (Last): Returns the result of an invoked operation. The
component is the "last" component in the response.
(*) Return Result (Not Last): Similar to the Return Result (Last) component
except that the component is followed by one or more components.
(*) Return Error: Reports the unsuccessful completion of an invoked
operation.
(*) Reject: Indicates that an incorrect package type or component was
received.
The interesting part of the Component Portion is that components include
parameters. These are call variables that the SCP might need to read and
use for call processing. It can also include variables that the SCP wants
to write to the SSP for call processing. Variables typically come in such
forms as CallingPartyID, CalledPartyID, AlternateBillingNumber etc. In this
manner, an SSP can query the SCP for applications such as where to route a
call, send the neccessary information regarding the call and receive a
reply with the information on where to route it. The application depends
upon the Service Logic Program. (Note: That the ANI as it is sent between
SSPs during call setup is sent in ISUP messages and therefore is not sent
along with TCAP messages, TCAP must send it as a parameter just like any
other call variable.)
SCP's are often deployed in mated pairs, just like STP's. This is less
common than with STP's though. If there are a redundant pair of STP's, there
will be a CCS7 link between them so that they can ensure their data is
uniform.
Just a small note here on billing systems. How billing is performed in an
Intelligent Network is not a part of any IN standard, probably due to the
fact that many of these systems are run by telcos on proprietary (and
therefore varying) platforms. Sometimes, the SCP includes back-end databases
that perform billing functionality (ie. changing who a call is billed to in
the case of a 1800 call), sometimes it merely stores the information and is
queried for it at a later date or periodically by another system, sometimes
there is a separate SCP on the network that the IN SCP sends call
information to, sometimes it is run as a part of the SMS. It is also
possible for an SCP to write to a variable such as AlternateBillingNumber
at the SSP. SSP's are perfectly capable of handling the sending of
information to billing systems for straightforward calls. It really depends
on the telco that runs the network. I believe that in the Australian phone
network the last option, the SCP writing variables to the SSP, is what is
used. This seems like the most robust option anyway.
1.09 : SCE - Service Creation Environment
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
When a service, or in terms of what the IN can use - a Service Logic
Program, is created it must specify the different jobs that each Network
Element must perform to provide the service.
In regards to the SSP it must specify upon which Trigger Detection Point/s
an active trigger must be placed to halt the call and query the SCP for
further information at the correct time. In regards to the SCP it must
formulate the variable processing databases the SCP must use in order for
the call to be routed to the correct line or IVR at an IP at the correct
time and under the correct circumstances.
The SCE is the environment where these services are created and tested. The
hardware used, like the SCP's are commercially available operating platforms
like SUN hardware and UNIX.
IN service logic programs are created in the SCE by using a building block
type approach. Each component of the IN is modular and can have many
different applications based on how it is used and how it is used in
relation to other components. A graphical programming approach is preferred.
At Telstra, they based their SCE systems around the CASE (Computer Aided
Software Engineering) tools.
Later in this article, I will explain some examples of IN services and you
can see how use of triggering at different TDP's and performing number
translation in different ways can result in almost limitless IN services. A
big part of the SCE and the modular nature of IN is to reduce the lead-time
for new services and introduce them very rapidly.
1.10 : SMS - Service Management System
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
As you can see from the diagram above, the SMS is not connected to the CCS7
network. The OAM (Operations Administration & Maintenance) links are usually
run over an X.25 network.
Papers describe the SMS as the heart of the IN. The same papers describe
the SCP as the brains of the IN. Maybe the human body analogy doesn't sit
too well hehe, but it illustrates that while the SCP's make decisions in the
IN, the SMS is responsible for the upkeep and control of the IN.
To begin with, when a new feature has been created in the SCE and is ready
for deployment, it is sent to the SMS for activation in each of the IN
nodes. The SMS distributes the database schema to the SCP's and distributes
information on which trigger detection points should have active triggers to
the SSP's.
Generally, master records of the SCP databases are kept in the SMS. These
are checked against the SCP databases during times of low activity (SCP's a
real-time systems and must be able to process calls quickly) to ensure that
all data is up to date. Furthermore, the SMS contains the management
functions for provisioning the IN services to customers and also for
modifying the service details for various services (for example, in the case
that a customer wishes to modify where a number is routed.) If the customer
has an interface by which to modify their IN service, it is likely that this
either directly or indirectly interfaces with the SMS.
The full scope of functionalities provided by an SMS are largely network
and system dependant. The SMS may be capable of performing a large number of
tasks however, such as monitoring the network for faults and collecting
stored billing data from the SCP's. As you can imagine it is a very powerful
system with control over all other parts of the IN.
1.11 : IN Services
=-=-=-=-=-=-=-=-=-
Now that we know how the IN works, I will explain some IN services offered
in Australia. This will help to illustrate the multi-function capability of
IN and give us a wide variety of solid examples to work with later in this
article.
e1800 - Enhanced 1800
This is basically, the example used above. When an SSP receives a call to a
1800 number it contacts the SCP for further information. The enhanced 1800
service is customisable enough to be able to route calls based on the caller
location, caller ANI, time of day, day of the week and so forth. A simple
example.
Priority 13
This is the service provided by the numbers in the 13 nn nn prefix. A major
factor in this case is that calls to 13 numbers are all billed at local call
rates. Most of the time, they will be diverted to a number based on the
caller location and the call will be a local call due to the service. At
other times, it is likely that the call will have been placed outside the 13
number's service area and the call refused. The call can also be diverted
based on a number of other criteria, such as whether the first preference
number is busy, the time of day and so forth. In Telstra literature, they
are always hawking the value of this type of service in an advertising
campaign, the theory being that one number Australia-wide is easy for
customers to remember, now go out and make a gay song with your 13 number in
it.
---> Just FYI, the above two services are known as enhanced InWATS
services, that is - Enhanced Inward Wide Area Telephone Services.
It's terminology :)
Customnet Spectrum ACD (Automatic Call Distribution)
This is a service often used in call centres, or call centres with multiple
working sites. The service will handle large volumes of incoming calls,
routing to a group of numbers based upon which number has been idle the
longest. If no numbers can be found to route the call to, the call can be
routed to an IVR until a number becomes available. This enables the customer
to handle their ACD in the phone network rather than purchasing and
maintaining termination equipment for the purpose. There are also
interfaces, ACD MIS (Management Information System) interfaces, that allow
supervisors to change the length of queues coming into the system, the
numbers that calls are routed to and also receive data based on where calls
have been routed etc. for management purposes.
Customnet Spectrum Network Wide Centrex
Centrex is PABX service offered by telcos. Instead of having a PABX system
at the local site, the PABX functionality is managed by the telco. Users
can call extensions and at cheaper rates and so forth just like a regular
PABX. Before IN, Centrex was only available if the users were all in the
same exchange area. Using Intelligent Networking, calling an extension type
number can cause a trigger hit and the Intelligent Network routes the
call to its destination, a Centrex user at a remote exchange.
Telecard - Automatic Calling Card Service
This is a prepaid or account calling card service offered by Telstra. The
user dials an access number, a trigger hit is envoked at the exchange and
the user is routed to an IVR. Here, the user enters their calling card
number and PIN. If this is verified, the call is put through and is billed
to the user or credit is reduced on their account.
2.01 : Interfaces
=-=-=-=-=-=-=-=-=
Features are added to a service to give the customer more personalised,
more customisable options and provide a degree of control over how they
use the service. In order to do this, they must have an interface to the
service in order to provide input in order to issue the service the
necessary instructions so it can perform the desired actions.
Likewise, in a feature rich environment there is alot more management
and requirement for instructions, programming etc. to be issued via telco
staff in order to maintain the system and ensure it is working in the
manner by which they offer the features as products.
In a feature rich environment, these interfaces are a necessity. There
are also likely to be alot of them. In addition, a feature rich
environment creates a need for a more complex underlying infrastructure
with a large amount of Network Elements performing the many tasks
required to create the environment. Any accessibility of this kind creates
a vulnerability. Vulnerability can be mitigated, but it can never be
completely removed. The facts that authentication technology over current
phone lines is limited and that many required Network Elements in an
infrastructure such as IN are running on operating platforms with known
vulnerabilities do not help either.
We will begin by describing the types of interfaces that can cause
problems within the telecommunication network, will then go on to describe
some examples of attacks on Customer Interfaces and will complete this
section with examples of attacks on Telco Interfaces. This is by no means
a concise compendium of attacks of this kind. There are definitely other
attacks not mentioned here. This section is designed to give you a feel
for and knowledge of attacks possible.
2.02 : Concerns Over Interfaces
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
So, in regards to the many interfaces in a feature rich environment like
the modern telecommunication network, what are the risks. How can an
insecure interface be used to leverage a security breach or act in a
manner it was not intended?
Defeats of Authentication on Privileged Interfaces
An interface that provides an advanced interface to the network, that
allows control over some kind of functionality in the network poses a
threat if that control is allowed into unauthorised hands. Likewise an
interface by which privileged resources or confidential material are
accessed is by nature designed to be kept out of unauthorised hands. To
mitigate this, these kinds of advanced and private systems require
authentication. The level of authentication required depending on the
privilege of the functionality or the value of the commodity protected.
This class of interface comes in two particular types; customer interfaces
(eg. control over where a number is routed) and telco interfaces (eg. OAM&P
systems). The concern here is the authentication mechanism being defeated
or bypassed, thereby allowing an unauthorised person privileges over the
network.
Interfaces Where There Was Not Supposed To Be An Interface
Obviously, a certain kind of less privileged interface to the phone
network is required to begin with in this case. The concern here is
interfaces that do not control everything as well as the designers
intended and if leveraged correctly can provide a more privileged level
of interface to the network than was intended. An example of this, is
the old in-band signalling problems described in [Section 1.01]. This type
of attack could be described as bypassing access controls in an interface.
Naturally if there was no interface, there would be no potential for this
attack.
Interfaces To Functions That Can Interact And Behave Incorrectly
This problem can actually be inherent in how the interface is designed,
as we will see later when we go into feature interactions. Features are
by nature advanced and depend on many properties and variables within the
controlling environment. Often a badly designed pair (or larger number)
of features can interact with one another creating an unintended result.
This problem can be compounded when combined with the first type of
problem and a function or feature requiring authentication and therefore
a greater degree of functionality is one of the interacting routines.
2.03 : Customer Interfaces
=-=-=-=-=-=-=-=-=-=-=-=-=-
These are the interfaces that are allowed by the telecommunications
carrier to customers. The interfaces mostly enable control over the
functionality of the specific customer's service only unless access
controls can be attacked which is described in a later section.
2.04 : Basic CPE Signalling
=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lets start with the basics. CPE Customer Premises Equipment must be able
to signal the exchange with the information it wishes to send. This is
typically done by DTMF (Dual Tone Multi Frequency) tones down the phone
line. This is used to indicate to the exchange numbers to be dialled and
also, special DTMF sequences can be sent to the exchange to indicate
instructions as to operating features such as activate call-waiting (*43#).
The path between the customer and the exchange is an analog sound path via
copper wiring, that is why DTMF is used. DTMF can also be used, once a
sound path is created between the caller and a remote system in order to
instruct the system. An example of this would be entering a PIN or entering
a choice of options from an IVR's menu.
In the past, decadic signalling was used to signal digits to the exchange.
Older rotary telephones (the phones with a dial instead of a keypad) use
this type of signalling & many exchanges still accept it for dialling
numbers. It works by quickly 'pulsing' or disconnecting the line for the
size of each number (ie. 1 pulse for 1, 2 pulses for 2 etc.). This system
is not used today as it will not work on circuits multiplexed together at
pair gain systems before the exchange, will not work on remote systems and
does not provide the kind of interface required to activate and manipulate
features of the telephone service (HomeLine features cannot be used with
a decadic/rotary phone).
Another type of signalling possible with standard Customer Premises
Equipment on a standard analogue telephone line is the switch-hook flash.
This can be implemented in a button on the phone (ie. Recall/Flash) or
by the user depressing and rapidly releasing the switch-hook. This is often
used in-call to interact with features on the line, such as call-waiting
where if a call-waiting pip is received, flashing the switch-hook and
pressing '2' on the DTMF keypad to switch to the incoming caller.
An interesting thing to note here is that the switch-hook flash and the
decadic dialling signals are the same types of signalling. Unwitting owners
of telephones have occasionally placed a protective gate over a keypad or
dial or a lock on the dial of a phone expecting that people will not be
able to dial numbers. However, with a switch-hook, decadic dial pulses can
be simulated by flashing the switch-hook the size of the number wished to
dial, pausing for a small interval and flashing the switch-hook for the
size of the next number and so on. This would fall into the second type
of problems with interfaces listed above [Section 2.02].
2.05 : Undocumented Telstra Home/BusinessLine
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Telstra Home/BusinessLine features are typically activated and controlled
on the line which you wish to manipulate the features of. So, to divert
a call to a number from your home phone, you pick up your Touchfone 400
and go :
[Call Divert] [Call Divert]
And any calls to that number will be diverted. First thing to note here
is that the 'authentication' is physical access to the phone line you
wish to manipulate. So, a phreaker can connect a beige box to a line
outside your house and forward all your calls to a line under their control
effectively 'becoming' you.
So, many of you will have seen a phone like a Telstra Touchfone 400 and
seen that there are separate buttons for a number of features. You're
thinking that these must indicate additional types of signalling than I've
described above. Well, sit back and learn chuck because this is a function
of the user-friendly way the phone is designed and infact, the above
signalling types are incorporated into the new buttons. I'll explain two
of the Touchfone 400 functions below and how they work in order to
demonstrate how this works :
Call Divert
OK, just scroll up a little to see how this is activated using the
Touchfone 400. In addition to this, prior to diverting a phone number, you
can set the 'type' of diversion. Press : [STORE] then, depending upon
which type of call diversion you wish to activate and set :
[1] For Forward Immediate {*21} {#}
[2] For Forward On Busy {*24} {#}
[3] For Forward On No Answer (upon timeout) {*61} {#}
And then [Call Forward]. On the surface, it appears that you are merely
pressing afew buttons here, but what is actually going on is you are
instructing the Touchfone to store one of the actual Home/BusinessLine
DTMF tone sequences in [Call Forward]. When the Touchfone detects your
pressing [Call Forward] a second time, it will send [#] rather than the
tone sequence, so for the default, Forward Immediate :
[Call Forward] [Call Forward]
Sends: {*21} {#}
As you can see, this works out exactly the same as just entering the
regular DTMF tone sequence.
Call Waiting
Call Waiting depends on the [Call Waiting] button. During a call :
{pip tone on line} [Call Waiting] [2] - To switch to the other call.
The [Call Waiting] button, or [Recall/Flash] on different phones, equates
to a switch-hook flash, or even a decadic dialed '1' (not that you will
be able to dial '2' afterwards though).
Activating Call-Waiting is similar to activating Call-Forward :
[Store] [Call-Waiting]
Sends : {*43#}
If you listen when you use these features on a Touchfone, you will hear
these tones being sent. The point of this is, there is no new signalling
that a Touchfone 400 uses and in addition, lines that have a feature
activated using a Touchfone or, using the regular DTMF tones sequences
have essentially both been activated the same way and can therefore be
further manipulated either way.
2.06 : Telstra Remote Access
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This has grown to become one of my favourite features offered by Telstra.
It is designed to be a way of remotely controlling features of a telephone
line. That is for example, from your home telephone line (or indeed any
telephone line) controlling the call forwarding parameters enabled on
your office telephone line (at a different location). Costs an extra 5
bucks a month I believe. Authentication is required because otherwise any
random individual can change where anyone else's Call Forwarding forwards
to, thereby rendering the system pretty darned unreliable. A PIN is
required for authentication.
To begin with, you dial the access number for the exchange in which the
number you wish to control is in. That is, the access number is different
for each exchange the manipulable numbers are in. This is due to the fact
that the state tables and service logic for features controlled by
Remote Access are in the local exchanges rather than the intelligent
network. They are not different depending upon the user, they are different
depending upon the exchange the service is in.
To begin with, a user dials their Remote Access (access) number, they will
then be prompted with the announcement :
BEEP. Welcome to the Telstra Remote Access service. Please enter the
telephone service you wish to control, followed by a star, and then
your PIN followed by a star.
Once this is done, you can control the telephone service (ie. call
diversion etc.) as you would if you were physically connected to the line.
It is possible to use this service to determine whether or not the Remote
Access feature is available on the line you are trying to control, the
IVR will notify you if you have tried to control an invalid number after
you have entered the number and PIN combination.
The feature you have tried to use is not provided as part of your
service. To add this feature, please call Telstra on 13 22 00
during business hours. Calls to this number are free.
So this means that you can enumerate valid Telephone numbers, by
determining when you receive the different error message than you would if
you entered an incorrect PIN. This highlights two implications :
(1) After performing a wardial to determine which telephone numbers
service a specific company, you can then test each number to see if
it is possible to remotely forward this number to a number under your
control.
(2) If your goal is to determine ANY number which you can remotely
control because you do not wish to physically access the line it is
on (ie. reducing your area of vulnerability, timing, because you are
lazy), then it is possible to do so. This would be used in for
example, exploitation of a feature interaction (see section below), or
having a number you can route to you whilst having people whom you
don't want knowing your direct phone number, among other things.
Changing regular services' call diversion is not the only thing that can
be done with Remote Access. Features of a Centel centrex service can be
controlled via Remote Access as well. In the latter case, if you are
forwarding to a number external to the specific Centel system it must be
prefixed with a '0' as when requiring an outside line from a Centel system.
2.07 : Intelligent Peripheral-Based Interfaces
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
The Intelligent Network is designed to offer a wide and customiseable
variety of interfaces to people using Intelligent Network based Service
Logic Programs. These are provided through the Intelligent Peripherals in
the form of various Interactive Voice Recordings. Some typical examples of
these interfaces would be :
PIN Access To Freecall Number
If a company does not wish unauthorised people, or unauthorised people
not in a table of certain numbers, unauthorised people in certain distant
areas etc. access to their freecall service they can protect the service
with a PIN.
PIN For Accessing Stored Information
An example of this would be MessageBank Advanced Virtual, where during
congested periods at a call center calls are routed to a MessageBank where
they can be taken and later retrieved, by calling an access number and
using a PIN as authentication.
PIN To Determine Routing
Often, instead of offering a caller a long list of IVR options for where
their call may be routed and especially if some access control is required
to prevent specific users going to areas other than those assigned to them,
an IVR can be set up to prompt the caller for a PIN and route depending on
which PIN was entered. An example of this is the Telstra HomeLink service,
although it can be found in many other applications, such as used by
specific companies or for access to conference calling resources (where the
PIN may be longer than just four digits).
Telstra Telecard Calling Card Service
To use this service the caller calls the access number, which sends the
caller to an IP IVR where they are prompted to enter their account number,
then their PIN and once authenticated they can have their call billed to an
account that has been setup for the purpose rather than having the call
billed to the line they are physically using.
2.08 : Security of PIN-Based Authentication
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
As you can see above, many of the interfaces that require authentication
use a four digit PIN for the authentication. The purpose of this section
is to familiarise you with the security properties of the humble PIN as it
is used in telecommunication systems. As you will see, it is a suitable
authentication system when used to keep out curious unauthorised users,
but is unlikely to keep out a determined attacker.
Two important things that affect security in the context of PINs used in
telecommunication systems rather than say banking or computer network
security applications are :
(1) There is no audit trail. That is, the user of the system has no way
of determining how many incorrect attempts have been made to access
and when the last access to was for their privileged interface, and
they have no way of determining what "address" (ie. ip address equates
to telephone number) that has been used to access their interface.
Sure, the telephone company has access to this information (if they
try hard enough to extract it from their massive databases) but the
user of the system does not. This means a user cannot modify his
behaviour in the event of an attempted attack (often meaning a more
successful one may follow) and the eyes of many (the users) are
replaced by the eyes of a few (telco staff). Adding an audit trail
that users can view would be costly, driving up the price of the
feature and would add too many complicated options for the average
"assumed stupid" (and for good reason) user to fathom.
(2) There is no retry counter. In banking security applications, if a
certain number of incorrect PINs are entered, an ATM machine will keep
the card, thereby preventing further brute force attacks. In
telecommunication applications, the risk of attack vs the cost of
service loss of availability to the user and service by the telco in
order to restore it when every "actually stupid" user keeps entering
the incorrect PIN means it is not viable to offer a retry counter.
Henceforth, an attacker can sit there and try every possible PIN
without being thwarted.
(3) Users can usually pick their own PIN. A bank chooses your PIN for you,
ensuring randomness, while in telecommunication systems you are usually
able to choose it yourself. This is desirable as otherwise a secure
method would need to be established for getting the PINs to customers
and in the event of a possible compromise, a user being removed from a
group of people authorised to know the PIN or maybe just a change of
mind the PIN would need to be changed. This creates a situation where
it is possible for a user to choose an easily guessed PIN, or atleast
a PIN that is easier to guess than a randomly generated one.
As you can see, the security issues relating to PINs in telecommunication
systems come down to ease of use, or the "assumed stupid user" problem
(as I like to call it) and costs of providing a more secure service. As in
many other areas, security is forsaken for marketability.
Of course, in order to attack a PIN, you need to know the access number
to dial in order to even make the attempt. For many systems, especially
those with many independant users, the access numbers will be public
knowledge and obtainable with a little digging. If all else fails, the
service can simply be subscribed to in order to obtain the access number.
It does help to notice that lists of such numbers are an important thing
for a phreaking community to compile.
OK, so hacking a PIN by going from 0000 - 9999 is possible, but takes a
hell of a long time. What can we do to minimise the amount of tries we
have to make before we get the correct PIN? One thing is that humans, being
naturally the finders and users of shortcuts and fond of reliability, will
pick a PIN that is easy for them to remember. Ultimately, I recommend
thinking about it and making your own list of likely PINs. Here is a list
you might like to include :
(*) All the same number : 1111, 2222, 3333 ...
(*) Incrementing Numbers : 1234, 2345, 3456 ...
(*) Decrementing Numbers : 9876, 8765, 7654 ...
(*) Last four digits of access/service number backwards : 1234 - 4321
Access number would be the number rung to access the interface;
Service number would be, in the case of HomeLine, the line whose
feature is being controlled, or a MessageBank number etc.
(*) Last four digits of access/service number +1 : 1234 - 1235
(*) Corners or edges of keypad : 1379, 2468
(*) Keypad down/up : 1472, 4725 ; 5274, 2741 ...
Another approach that can be taken once the most likely PINs are exhausted
are trying large, but more likely combinations of PINs. To brute force a
4 digit PIN you would ordinarily require roughly 10,000 attempts (5000 on
average), however searches aimed at likely combinations can reduce the
amount of tries required :
(*) Birthdate (dd/mm) PINs : ie. [00 - 31] [00 - 12] equates to 372
attempts, 366 if you eliminate the non-dates in that space.
(*) Double digits : ie. 1100, 1122, 1133 ... requires an attack space of
90 (remembering to eliminate all same pairs as they have been tried.)
(*) Repeated Pair : ie. 0101, 0202, 1919 ... requires an attack space of
90 if remove all same numbers. Extra 10 if include 0 at the start and
end of pairs.
If that doesn't work and you do not wish to move to another user on the
system, then you can eliminate those numbers and do a brute force search
on the rest.
In the case of Home/BusinessLine etc services, when a service is first
activated, the PIN is set to the last four digits of the service number
(telephone number for those of you who have bad retention). Many people
would not change their PIN from this number and would continue to use it.
Telstra has recently changed this, probably due to security problems. In
order to activate a new feature on your line you must change the PIN from
the default. One PIN is stored in the exchange for each user, so when you
change your PIN for one feature it is changed for all other features as
well.
[Pickup] *30 [Old PIN] * [New PIN] * [New PIN]# [Hangup]
For those of you that wanted to know. Note the reliability of the double
New PIN entering requirement to prevent idiots forgetting their PIN.
Secondly, you can automate the task of PIN brute forcing by using tools
designed for the purpose. PABX/VMB hackers will work depending on how
customisable they are. If they can issue the PIN after any number of
prompts, then its ok. They basically come in two types, the ones with
which you have to press a key on to indicate the next prompt from the
system (such as the Telix VMB Hacker in Phrack 35 Loopback) and the ones
that use voice response to determine where the prompts are (like THC-PABX
hacker).
You might be wondering now, why is a PIN used for authentication if it
sucks so badly? The answer is, it is really the only type of authentication
that can be used. Remember, POTS is limited in the type of signalling it
can handle. It only has the hook-switch and the DTMF keypad for signalling.
In the future, when we are all using data connections such as ISDN to
connect to the telephone network, we might be able to use something more
advanced like digital certificates or biometrics (ugghhhh - both of these
are another article anyway) but for now we're stuck with a PIN. Actually an
advanced challenge/response type of authentication is possible. Users have
a token into which they enter a challenge issued by an IVR from the system
they wish to authenticate themselves to and the token returns a series of
digits which are entered via the DTMF keypad. I've actually heard they use
a system like this on some PABX Direct Inward Systems Access Services.
However, Telstra issuing every fuckwit HomeLine user with a token at this
time is non-cost-feasible and non-user-friendly in the extreme. So for now,
PINs it is.
2.09 : Customer Interfaces To The SMS
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
For customers with an advanced Intelligent Network service, a great deal
of control is required over the service. A simple DTMF-IVR interface would
be lacking in regards to the amount of configuration that would be
required for say, an advanced CustomNet system. Telstra offers a few data
based interfaces to the SMS for this purpose. Security is a significant
issue in relation to these interfaces, particularly in relation to customers
jumping across multi-lateral security boundaries and affecting other
customer's services and also, gaining higher privileges on the system, the
implications of which are described in [Sections 3.1 - 3.9]. Attacks
on these interfaces are essentially a computer security issue, these
issues are already well-known and are beyond the scope of this article. It
does however, do good to note that vulnerabilities in such interfaces are
already well-known and so the provision of these interfaces create security
issues. It is also a good example of the modern convergence of
telecommunication and data systems.
SCAI (Switch to Computer Applications Interface)
This interface is usually provided on a Basic Rate ISDN interface (ie.
OnRamp MicroLink) and is a way by which applications running on a customer
server can interface with the SMS or intelligent switch to control the
Intelligent Network service in real time. I believe, from diagrams I have
seen in Telstra documentation, that the data is transferred on the ISDN
D-Channel, through Austpac and to the SMS / Intelligent Switch as a host
on the Austpac network. Naturally, this would mean as long as the NUA is
known, it could be called into by other types of devices and authentication
would likely by something such as a user / password pair or challenge /
response etc.
Using the SCAI interface, an application can receive and send data to
the Intelligent Network. It can receive information like ACD Data such as
status reports in real-time and Caller information (ie. ANI, locality etc).
Caller information can be provided to ACD agents as calls come through. The
SCAI can also send instructions to the network, such as where to route
calls.
A primary use for the SCAI is to allow the customer computer application
to make automated decisions based on information, for example upon receipt
of caller information from the SCAI an application can request to the
switch to route the call to a location based upon its own processing of the
data.
Web - CustomNet Control
CustomNet Control is a Telstra.com online service that is used by
CustomNet users to configure their CustomNet service. Staff movements and
changes in departments can mean that a CustomNet service may need to be
reconfigured and CustomNet Control is an available tool by which to
accomplish this. Online reports on the status of the service are also
available. CustomNet Control is a web-based application, accessed by using
the digital certificate Telstra.com issues its users. Functions offered
include :
(*) The ability to view and then change or modify the features on
CustomNet services such as updating the name display or changing
call barring access.
(*) Move services between call pick up groups.
(*) Swap the telephone numbers on analogue extensions.
(*) View and change members of Call Pick Up, Hunt Group, Intercom and
Speed Call Groups.
(*) Provide reports on telephone features.
(*) Update service address details.
(*) Apply pre determined feature sets to CustomNet services.
(*) Copy feature sets between CustomNet services.
Other
Other interfaces to the SMS exist, such as dialup and of course voice -
ringing up your Account Manager (for corporate clients) and having them
change your service parameters manually. I believe an Identification
Number is required.
3.01 : Telco Interfaces
=-=-=-=-=-=-=-=-=-=-=-=
As with customer interfaces, an advanced network such as an AIN requires
many more management interfaces for OAM&P (Operations, Administration,
Maintenance & Provisioning) purposes. The increased number of nodes in
an AIN means increased interfaces to those nodes, and by the compromise
of one node, other functionality within the network can also become
compromised as we will see.
Many interfaces to the nodes of an AIN are computer based, interfaces
from other nodes that can be usurped by a human. Interfaces designed to
be used by human operators are naturally authenticated and are not allowed
to customers. They must either have the authentication compromised or be
somehow interfaced from a higher level.
3.02 : OAM&P Interfaces
=-=-=-=-=-=-=-=-=-=-=-=
In the AIN model itself there is a standard OAM&P interface to all nodes
on the network, the SMS. Typically these interfaces will be over X.25 and
will be a part of a Closed User Group (they only accept connections from
a trusted group of X.25 hosts) and/or will require authentication for
access. At the very least an SMS will be able to control AIN Service Logic
variables in the nodes (ie. Trigger Detection Points in the SSP's,
databased entries in the SCP's) and so compromise of an SMS or the SMS'es
OAM&P interface to a node will result in access to this kind of
functionality at the least.
The SCE environment is also a point of vulnerability. Third party
software developers can introduce Service Logic Programs that contain
backdoors. There are dangers in regular application development as well.
Broad capabilities of features can introduce feature interactions which
we will get into in a later section.
There are certainly other OAM&P interfaces to nodes other than the SMS
interface. This is especially true for the SSP which may have many
separate interfaces to different equipment within, for monitoring and
changing of parameters. Mediator, AUTOCAT & AXE AOM are interfaces that
provide an especially high degree of control over SSP's. STP's may
require an interface for modification of routing tables and so forth. A
full description of all interfaces to these nodes is far beyond the scope
of this article, but let us just note that there are many different
OAM&P interfaces to the broad variety of nodes on an AIN/CCS7 network.
These interfaces would typically be over X.25 or PSTN dialup. Another
important fact to note is that many of the nodes, the SCP's, SCE's and
SMS'es are running on operating systems such as UNIX in which security
issues and vulnerabilities are already well known.
3.03 : CCS7 Interfaces
=-=-=-=-=-=-=-=-=-=-=-
The CCS7 protocol was never designed to be secure. It was designed as
a call setup communication system within a closed network of trusted
nodes. Compromise of a CCS7 interface is akin to the in-band signalling
problem of the analog telephone networks, only worse. Much more
functionality is offered and a hacker on a rogue CCS7 interface can do
alot more than the Blue Boxers of the old days. In a modern day, enhanced
and feature rich environment there are a few circumstances that can make
certain interfaces a security issue in this sense :
Compromise of a Node on the Network
This is an obvious point, but often missed. If a node on a CCS7 network
is compromised, so is its interface to the CCS7 network. It is now
untrustworthy and a large security issue.
ISDN
ISDN D-Channel (Data Channel) provides a powerful signalling interface
to the CCS7 network. There is much functionality and with more powerful
functionality comes the risk that some unexpected interface can result.
The D-Channel is a Common Channel signalling link just as CCS7. Infact,
ISDN was originally meant to extend the concept of Common Channel
signalling all the way to the customer. Certain CCS7 data can be
fabricated from a malicious ISDN connection. For example, in the
Telecommunications Digest in Jan, 4, 1997 it states :
"It is to this day possible to spoof ANI/CNID with certain PRI connected
PBXs on certain models of switch."
Provisioning of CCS7 Connections to Outsiders
In these days of deregulation, one thing that introduces untrusted
parties to a trusted network is the provisioning of CCS7 connections
to various telecommunication service providers. They can't provide the
service without the CCS7 connection so they have to have it.
3.04 : Basic CCS7 Security
=-=-=-=-=-=-=-=-=-=-=-=-=-
Okay, so the protocol was never designed with security in mind. However,
a few basic add-ons and precautions can be taken to mitigate the
vulnerability of a CCS7 network. I will explain them here before I go on
with the vulnerabilities.
Gateway Call Screening
Typically, the way to deal with untrusted parties on the network is to
screen packets, for things like unauthorised requests and packets that
appear to be coming from a Point Code outside those allotted to the
network a packet is coming from (hence indicating a spoofing attempt).
You would have seen above, that many interfaces are capable of causing
a vulnerability under certain circumstances only. This is because of
screening in place. This screening would typically be implemented on an
STP with Access Control Lists or the like, in a manner analogous to a
firewall. A company named Sevis Systems formerly had a CCS7 firewall
offering, however they went out of business.
As with TCP/IP firewalls though, the network remains vulnerable if the
attack is from a trusted node, a node on the internal network where it is
not subject to screening or the attack involves exploitation that the
firewall does not recognise and will pass as regular traffic.
Point Codes Secrecy
As mentioned in [Section 1.05] Global Title Translation is often used
to obscure the final destination Point Code from untrusted nodes as it
traverses the network. There is very little information that I could
find on this, but Point Codes are considered sensitive information by
Telecommunication companies and are mostly considered proprietary. With
the destination Point Codes it would be possible to accurately map a
CCS7 network and understand which nodes offered which services. Gateway
Call Screening and that secret Point Codes only provide security through
obscurity are often given as reasons why provision of Point Codes to
third party providers etc is not considered a security risk, but it
sounds to me that in such a flimsy security environment any security is
better than none at all. Presumably, knowledge of exact Point Codes can
lead to things like sending of queries to specific SCP's that are known
to provide certain (ie. cheaper, confusing etc.) results.
3.05 : Basic CCS7 Vulnerability Taxonomy
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This section is designed to familiarise you with some of the
vulnerabilities in the CCS7 _Protocol_. That is, as mentioned before,
attacking the OAM&P interfaces to the nodes is not covered here. The
reason for this section is to add a discussion on security of a CCS7
network in the AIN context, enhanced, complex and as such vulnerable. We
will primarily be dealing with how a compromised node or rogue interface
can influence security of the entire network, rather than specifically
going into what can occur within the node itself (ie. altering of number
routing tables, activation of lines and monitoring of circuits with an SSP
as an individual node and the like are not covered here.) This
information was compiled from a number of sources.
I had also toyed with the idea of adding a "quick and dirty" CCS7
overview here, so that you would not need to refer to anywhere else for
a full understanding of the material. However, some excellent references
already exist and replication of CCS7 protocol information has already
been attempted in .txts & zines and I am not willing to join them.
Instead, when I mention a particular instruction sent within a CCS7
message I will briefly describe the surrounding part of the protocol. For
a full understanding of CCS7 I recommend one (or all) of the following
professional tutorials :
Telecommunications Journal of Australia (Vol 31, No.3) : The CCITT No. 7
Common Channel Signalling System for Digital Networks - Subocz, M.
Performance Technologies : SS7 Tutorial : http://www.pt.com/
Illuminet : Signaling System 7 (SS7) : http://www.iec.org/
As you can see the last two are available on the internet while the
first, although specifically Australian is not. The information is the
same as CCS7 is an international standard.
The attacks end up falling into four categories :
(*) Fabrication : This refers to complete creation of CCS7 messages,
possibly spoofed and containing information designed to achieve some
purpose.
(*) Disruption : This refers to the ability of a node to prevent a
message from getting through to somewhere, or garbling checksums to
prevent them from being accepted at its destination, for example.
(*) Modification : This refers to the action of taking a message going
through or from a compromised node and altering it to convey a
different meaning at some level.
(*) Monitoring : All CCS7 nodes are vulnerable to this attack. In
common computer security parlance it is known as 'sniffing'. It
involves examining messages enroute for sensitive information.
3.06 : Service Control Point Attacks
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Attacks on an SCP involve fabrication or modification of TCAP messages
sent to the SCP in order to generate a request or instruction of the
attackers choosing.
Queries / Requests For Sensitive Information
Typically, a node will send a TCAP message to the SCP asking for
information and the SCP will reply with the information. So, sensitive
information can be requested by a rogue node. This could be PIN or
Calling Card information designed to allow the attacker authenticated
access to an application of the Intelligent Network, or it could be
private customer information, depending upon which SCP or application on
an SCP was being attacked and what information it held.
Instructions And Writes To The SCP
If the application running on the SCP allows for modification of its
databases via TCAP, sensitive and control information can be changed to
arbitrary values. This could mean an attacker could change the PIN of
another application so he could authenticate himself or modify billing
information, forward 1800 numbers to arbitrary locations and so forth.
Naturally, being able to write to an SCP via TCAP will depend on the
application, it would be possible for customer interfaces to send changes
to the SCP by their node's (IP, SSP) OAM&P links to the SMS and make
the changes that way. On the other hand, if the IN application Service
Logic an attacker is hoping to subvert requires a 'conversation' of
TCAP messages with the SCP, then values will be written to the SCP, if
perhaps only temporarily.
3.07 : Signal Transfer Point Attacks
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Denial of Service
The fact that CCS7 makes use of ways to route around faulty links and
such opens up the possible for such information to be deliberately
introduced in order to _completely_ isolate a node. An STP is the optimal
location to introduce this information as other nodes rely on them for
relay of their communications.
LSSU DoS
One way reliability is enhanced is by sending of LSSU Link Status
Signalling Units between signalling points on the network. These convey
information of the status of the signalling point that the LSSU is
coming from. The are sent on direct links between nodes only, that is
they do not traverse the network and one particular node will only see
LSSU's from its neighbouring nodes.
One field within the LSSU, the checksum, is included to ensure
correctness of the signalling unit transferred. A simple attack is to
deliberately corrupt this field. Requests for resending will be sought
and the checksum field corrupted once again. The neighbouring node will
shortly assume the checksum corruption indicates an unreliable link and
use another one (that is, if another one is available and hasn't been
Dos'ed as well.)
MTP3 DoS
The Message Transfer Part - 3 or Network Layer of the CCS7 protocol
stack, in addition to provision of network addressing and distribution
of CCS7 packets includes provision for such network reliability
functions as controlling traffic during congestion, routing traffic away
from failed links and alternate routing. Such services are naturally a
hotbed for fabricated denial of service attacks.
Attacks On Global Title Translation Databases
The STP stores the translation tables for Global Title Translation. An
attacker could modify these tables to redirect traffic to malicious or
confusing databases, thus gaining control of every call requiring a
query to such a database.
In addition to this, being able to read the translation tables will
provide the attacker with exact point codes for nodes on the network
and how they correlate with the various Global Titles. As was mentioned
above, Point Codes are considered sensitive and proprietary information.
Modifying Gateway Screening Logic
STPs are often deployed as CCS7 firewalls by use of ACLs (Access Control
Lists) that screen packets. Access to an STP would facilitate the
modification of these ACLs, to allow packets that breach the network's
security policy through, or to deny service to legitimate packets. Access
to these tables would also provide an attacker with information regarding
what packets he can or can't get onto the internal network or past the
firewalls on the network.
Sniffing Traffic
All nodes on a CCS7 network are vulnerable to monitoring attacks, an STP
however is worth special note as all traffic must flow through STPs
making them an optimal host for sniffing attacks on the network.
3.08 : Service Switching Point Attacks
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
ISUP IAM Flooding DoS
During standard CCS7 call setup, the first type of message sent from the
originating exchange to the destination exchange is the so-called IAM
or Initial Address Message. This includes information such as the called
number and the CIC (Circuit Identification Code - Identifies inter-SSP
voice trunks), the _calling_ number is optional as technically only the
originating exchange need know this information to complete the call (not
that it doesn't end up getting sent anyway - flags are usually used to
indicate Caller ID Blocking. Whether those flags are honoured or not is
another story ..)
Both attacks involve sending a large number of IAM messages to a single
SSP on the network, but with different goals that both deny service.
The first DoS goal is to reserve all the outgoing/incoming Circuits by
reserving all the outgoing/incoming Circuit Identification Codes. The
target SSP will send ISUP ANM (Answer Messages) messages in reply, but
these are discarded or disrupted enroute to the SSP the messages are
spoofed to be from. This is easy if the rogue node claims to be an
intermediate SSP in a chain from the originating SSP for example.
The second type of DoS goal is to simply send so many spoofed IAMs that
the target SSP cannot handle the load and becomes congested. The target
SSP will send ANM messages to the SSPs the IAMs are spoofed to be from
and receive error messages. That means its links will be receiving or
sending 3 different types of messages concurrently, whilst the DoS'ing
node need only send one, thus conquering it in terms of bandwidth.
3.09 : Intelligent Peripheral Attacks
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Like other nodes used in Intelligent Network applications, the IPs must
make use of TCAP to communicate with SCPs. Attacks on IPs can involve
modification and fabrication of TCAP messages to gain access to the
authenticated interfaces they provide.
Fabrication of Replies From SCP
When an IP requires a PIN, Calling Card number and so forth to compare
to user entered input it queries the SCP. This information could be
intercepted, disrupted and replaced, or wholly fabricated (eg. from an
0wned SCP) to include a known value that can then be input to the IP.
Modification of Queries To SCP
On the way out, queries regarding authentication information and such
can be modified to query the SCP for information from an account for
which the authentication information is known to the attacker.
4.01 : What Are Feature Interactions?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
To put it simply, a Feature Interaction is a circumstance when two or more
features, when used in combination, produce some result other than that
which they would when used separately. This result can often be unwanted,
making one of the features misbehave. For its seeming simplicity it is in
actual fact a highly complex problem. The features may be activated at
application level, a customer pressing numbers on a keypad, but the
interactions stem from causes deep within the phone network, often right
down to the binary code running at exchanges and telecommunication control
systems.
So far in this article we've seen that the exchange stores call data
variables and variables containing status information of calls. We've seen
that feature Service Logic Programs can run at the exchange and through the
Intelligent Network via TCAP messages to and from an SCP. We know that an
executing feature may need to read and write to the call and status
variables. Finally, we have seen how calls can be modelled around
Originating and Terminating Basic Call Models, Points In Call at which
features can be triggered.
A feature would be activated and run at a PIC, read and write the call
variables it requires to perform its function and continue the call. What
would happen however, if one feature ran, read and used a call variable and
continued the call only to be followed at a later PIC in the same call by
another feature that wrote to that same call variable already used in the
course of its execution? The first feature would now have utilised
information that is incorrect for the eventuating call. The first feature
may have become completely undermined. This is a general type of feature
interaction.
The feature interaction problem is exascerbated by the introduction of the
Intelligent Network and the Rapid Service Creation concept it is built to
envisage. At the same time it undermines that concept as with every new
feature introduced the potential interactions between them grow
exponentially.
The fact that I want to teach you to find new exploits is truer here than
in any other section of this article. As such, I will detail working
exploits in the Australian phone system (mainly in the final part),
however, there will be many theoretical, obsolete and overseas examples
designed to teach you concepts regarding how feature interactions work and
what kinds of things you are looking for.
4.02 : Theoretical Examples of Feature Interaction
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
The problem may be easier explained by example, so here I will present
three _theoretical_ examples. These potential interactions are not
necessarily active in the Australian phone network and have been chosen due
to their coverage of concepts necessary for understanding. In this section
I will also explain these interactions in the context of the common feature
interaction causes, which are further explained in [Section 4.04].
Call Waiting & Three-Way Chat
Call Waiting is a feature designed so that a user can be on a call with
someone and a third party can call them, the exchange alerts the user to
an incoming call and to switch to the incoming call, the user does :
[Hook-Switch Flash (Or Equivalent ie. RECALL button)] and presses [2]
The user has put the first party on hold and is now talking to the third
party.
Three-Way Chat is a feature designed so that a user can be talking to one
party, decide to add a third party to the call and so ring them up and add
them in to the conversation. This is done by going :
[Hook-Switch Flash (Or Equivalent ie. RECALL button)] : To Get a dialtone
Entering : [Phone Number of Third Party]
And once connected to the third party : [Hook-Switch Flash] [3]
To conference the calls together.
Note that the feature control signalling procedure as shown above is
equivalent to other methods of doing it with different CPE equipment (as
explained in [Section 2.04 & 2.05]). The problem arises if a user is
subscribed to both features. Usually, the features will work correctly
depending on the context of the call at hand. But consider the situation
in which a user is on a call to someone and wishes to establish a three
way call. At this exact same time, someone has placed a call to the user
activating his call waiting feature. In this situation, the context is
ambiguous and so should the exchange :
1. Issue the user with a blank noise and wait for them to press [2] to
switch conversations?
or
2. Issue the user with a Three-Way Chat dialtone so he can call someone
else?
As you can see, if one feature is activated over another, the other
feature will not be working properly. This interaction brings up four
issues :
(*) The feature that is activated over the other actually depends upon
which feature's execution thread is run through the exchange processor
first. This can generally be considered random and is known as a
'Race Condition'.
(*) This interaction could be avoided if the feature activation control
signals issued by the user for each feature were different. However,
this is why I explained how there are only limited signals available
from CPE equipment [Section 2.04 & 2.05]. The exchange must interpret
which signal means what depending upon the CONTEXT. The true meaning of
the signals depends upon the customer's intentions which may become
different from the context in certain situations.
(*) Storing information about the context of a call involves storing
STATE information regarding the call at the exchange. Both features
share this information and can both write to it. If one feature takes
over because it was the first to respond to the signal it will have
control of the state information at that time.
(*) Both these features often require the use of only one three-way bridge
available to a user at the exchange. If one feature is active, it will
be using the user's bridge and the other feature will not be able to
activate as it requires that same resource.
Call Forwarding & Originating Call Screening
Call Forwarding enables a user to 'forward', or redirect, calls to their
number to another number. This would be useful, for example, if a user
redirects their office number to their home number outside of office hours.
Originating Call Screening enables a user to block certain numbers, or
certain types of numbers such as STD, Premium Rate numbers etc. from
being called on his line.
In this case, a telecommunications carrier would be able to foresee an
interaction such as when a user blocks Premium Rate numbers from being
called from their line with OCS, and a young ne'er-do-well in the house
forwards the line to a Premium Rate service and calls their own number thus
bypassing the Call Screening feature. But what about something involving
two lines?
User A has screened the number of one of his hated enemies from being
called on his line.
User B has forwarded his line to that of User A's hated enemy.
User A calls User B's number.
What happens? Does the call get forwarded thus violating User A's
Originating Call Screening feature? Or Does the call not go through, thus
leaving User A wondering why he can't ring User B and violating User B's
Call Forwarding feature?
This interaction can also come into play when the forwarding is invoked
by an AIN feature. For example, a local number is on the OCS list and the
user rings a 1800 number which the IN translates to the screened local
number.
(*) This interaction overwrites one call variable (the called number) used
by one feature, by another.
(*) Note the crossing of Originating Basic Call Model and Terminating
Basic Call Model. The fact that a relied upon variable is passed over
these models makes this a hard interaction to deal with. In most
phone networks, this interaction would go undealt with and the call
would thus go through.
(*) We see here, one feature assuming that the 'name' (number) addressed
refers to one specific end party. This is a violation of naming
assumptions made by the OCS feature (sorry if this sounds abit cryptic
right now).
(*) This interaction might lay dormant for a large period of time as it
takes two people configuring their features in just the right way
for them to interact before it becomes apparent.
Automatic ReCall & Caller ID Blocking
This one is a cool one! In addition, with abit of modification, this
interaction has been known to affect PABX systems as well.
Caller-ID Blocking is the opt-out feature that can be used to prevent
your number from being sent to and displayed on CND boxes of people that
you call. Enhances privacy and so forth.
Automatic ReCall allows a user to Automatically Return a call that was
made to them when they were busy. More than one call can come through to
the line and they are placed in an Automatic ReCall queue at the exchange.
When the user becomes free, their line is rung and so is the caller's. The
queue of incoming caller's is then gone through one by one. Alternate
services may only offer the LAST incoming caller without offering a queue.
The interaction works simply thus :
User A who has activated caller-id blocking ringing user B who is engaged.
User B then uses his Automatic ReCall feature to ring back User A.
User B has itemised billing and so receives User A's number with his next
bill.
There are many variations on this interaction. For example, in the context
of PABXes rather than general telecommunications switching systems, a NIST
PABX Vulnerability Analysis paper discusses an interaction between
Caller-ID Blocking, Automatic ReCall & Call Waiting :
User A calls User B with Caller-ID Blocking activated.
User B Does not answer the call or is engaged.
User B later uses Automatic ReCall to call back User A.
User A answers and User B immediately hangs up.
User B quickly calls back User A hoping to invoke User A's Call Waiting.
User A hangs up and if Call Waiting had been invoked, the PABX rings back
both User A and User B. In this case, User B gets User A's number on his
CND box as he is rung.
Note: That in some PABXes and Phone Systems, Call Waiting is controlled
by a hook-switch flash only to switch between callers. There is no
pressing '2' after the flash to indicate what you wish to do, you are
immediately switched. This differs from the Australian / Telstra system.
(*) Automatic ReCall changes the status of a Callee to that of a Caller.
Assumptions made regarding the types of calls that can result from
calls in which a feature is involved can result in the feature not
operating correctly if the type of call is changed. The ability of
parties in a call to control this status of the call can result in
interactions of this kind.
4.03 : The Feature Interaction Landscape
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Feature Interactions are a rather pervasive problem, and as such vary in
degrees of damage they may be perceived to cause. The use of the term
Feature Interaction in the context of damage is slightly misleading.
Features will interact and some are designed to. Some can be allowed to
interact as long as they do so in a certain way or within certain
constraints.
In the literature, Feature Interaction refers to an INTERACTION between
features that may or may not be desirable. An undesirable feature
interaction is formally termed 'Service Interference' so as to avoid
confusion.
In addition to some feature interactions being benign, some Service
Interferences are not perceived as predictably exploitable by a party bent
on subversion. On the other hand however, whether a feature interaction
is perceived as damaging, exploitable, or predictably exploitable depends
upon the situations in which they have been encountered. With a bit of
imagination in its use, a perceived benign, or perceived constrained
feature interaction may possibly become a fully exploitable feature
interaction.
As with other fields of data security, a feature interaction could be
termed as a feature or a bug depending upon the viewpoint of the user and
the situation.
Resolvable Feature Interactions
When a Feature Interaction is discovered in a set of features, it is not
immediately the end of the feature. Typically, one feature reads and uses
a call variable that another feature writes to. This may be handled by
giving one of the features PRECEDENCE (or priority) over the other
feature. Generally, this is done by making sure that the features are in
order in the Basic Call Model. One feature is triggered at an earlier
Trigger Detection Point and the other is triggered at a later Trigger
Detection Point.
Presumably priority can also be set by setting a flag during the
execution of one feature that another feature is not allowed to overwrite
a variable of if it encounters that flag. CCS7 employs a technique like
this for a large amount of call forwards, it can set a flag to prevent
calls from being forwarded again.
It is also important to let the customer know which feature will have
priority over another feature so that their intentions cannot be removed
from the intention of the features involved. The features will still
interact, just in a set manner. If the customer does not know how they
interact then their intentions can easily be removed from the intentions
of the features and this is considered a Service Interference. Priority
of features will be aimed at serving the predicted preferred priority of
the customer if possible.
Telstra has set priority of some of its features in this manner. To aid
illustration of this concept by example, I will include them here as they
are in the Telstra HomeLine User Guide which documents feature priority
during incoming calls :
1. Call Forward overrides all other HomeLine features.
2. Call Forward Set the Time overrides Call Forward Busy and Call
Forward No Answer.
3. Call Forward Immediate overrides Call Waiting. Call Forward No
Answer takes over if Call Waiting is not answered. Call Forward Busy
takes over if you are in a three-party conference. For example, if
Call Forward Busy and 3-Way Chat were both turned on and you were in
the middle of a conference call, any incoming calls would be
automatically forwarded to your programmed number.
4. 3-Way Chat overrides Call-Waiting. For example, during a 3-Way Chat
call, you will not receive the Call-Waiting tone.
5. Variable Number Forward overrides Fixed Number Forward. If you
program a Variable Number Forward, calls will be forwarded to that
number rather than a Fixed Number Forward (stored at the exchange).
This applies to all three Call Forward Features.
6. Abbreviated Dialling and Call Forward override Call Control. For
example, when Call Control is turned on, any Abbreviated Dialling
numbers may be called, and any calls forwarded by Call Forward will
still occur. If you wish to program numbers for Abbreviated Dialling
or Call Forward which are already restricted by Call Control, you
must turn Call Control off prior to programming.
7. If you have both Call Waiting and Call Forward No Answer, the forward
time selected for Call Forward No Answer will determine how long
Call Waiting tones will be delivered (unless the forward time is
longer than 45 seconds). You may alter the length of time your phone
will ring before it forwards. The time may be set from 5 to 60
seconds. This new time, once set, remains as the default time.
Lastly, something to note is that some feature interactions can be
considered DESIRABLE. That is, they are supposed to interact. An example
of this would be Call Forwarding & an AIN Call Logging Feature. Call
logging would read and use variables like CallingPartyID and CalledPartyID
which Call Forward then writes to.
Unresolvable Feature Interactions
An unresolvable feature interaction is one that cannot be mitigated by
setting priority. This may be because of for example, that they both
overwrite essential variables or because offering one in priority over
another would not match most customer's wishes in the least, or simply
due to other technical reasons.
An unresolvable feature interaction may still be desirable, or it may
still be possible to offer the service as the potential misuse is
outweighed by the value of the feature. The interaction described above
involving Call Forward & Originating Call Screening would be an example of
this. Various arguments could be used to show that the potential misuse
is limited. In the example above one would probably be that seeing as the
forwarding party pays for extra charges incurred by the call, it is fine
for someone with say, STD barring to have their call forwarded through
them.
After we are done with this, we are left with true Service Interference
type feature interactions. These interactions, if discovered, are highly
likely to result in one of the features being removed from service, fixed
or never deployed in the first place.
As you can see, it is rather sketchy classifying feature interactions in
this way. In the end, this is probably up to management of a telco which
offers the services. I'd say though that whether a feature with a known
interaction is deployed or not depends on four factors :
(1) Frequency of occurrence : If the interaction constantly plagues the
set of features and not just under certain conditions.
(2) Damage caused by the occurrence : If the damage is only a possible
momentary confusion or a feature not working some of the time then
this wouldn't be too bad, however if it completely undermines
another highly relied upon feature such as Caller ID, or disconnects
the call, causes major inconvenience etc. then it would be bad.
(3) Predictability of occurrence : This is whether it is easy to make
the feature interact to perform some nefarious purpose. It would be
safe to assume that an interaction capable of say, creating free
calls but under normal use would rarely occur, but could be
predictably induced would have a much higher frequency of occurrence
than it would under normal use.
(4) The value of the feature : It may make the phone service easier to
use or it may generate obscene amounts of revenue. This is a factor
that the others would be judged against.
The point of all this is, assuming that a telco knows about an
interaction, they may try to mitigate it and they may allow it dependent
on a number of factors. Therefore, with abit of imagination, an 'allowed'
feature can easily become something that can be exploited.
The Stupid User Problem
Above, we saw that a feature interaction can become a service
interference based upon the situation or whether it corresponds to the
user's intentions or not. Many 'interferences' I have seen documented seem
to be feature interactions with nothing more than a user's stupidity,
gullibility, or lack of knowledge of feature capabilities in their phone
network. The flip side of this coin is the cleverness of an attacker who
attempts to exploit the flaw deliberately, adding a social engineering
element to the equation.
Lets us take for example, the case of Betty, An elderly pensioner living
in an area that is quiet during her usual out and about hours of between
4.00 and 10.00am but plagued with thugs and delinquents later in the day.
Now Betty is getting a tad lonely at 6.00am and decides to ring up her
friend across the road. Little does she know that at the exact moment she
picks up the phone to ring her friend, she receives a telemarketing call
from Save The Dolphins International. Infact, the incoming call is so well
timed that she picks up to dial out before her phone has rung to announce
the incoming call. While expecting to get a dial-tone she gets "Greetings
fellow dolphin lover". Betty is baffled! While any normal person would
realise that a freak occurrence has occured, Betty can't handle it. She is
so baffled, that infact, in her highly medicated state, she drops dead
from brain implosion. The telephone company is sued by the proprietors of
her estate for millions of dollars.
This is an example of a mild feature interaction gone extremely wrong due
to the stupidity of the user. Naturally, while the telephone company would
want to guard against such an interaction, they will accept the risk of
running it in the telephone network. Now, let us see how this interaction
could possibly be manipulated by an attacker to deliberately fool someone
else :
John is a gentleman living on his own after his wife passed away. He is
feeling lonely (yes, at 6.00am) and so decides to call his friend "Miss
September" to arrange an appointment for later in the day. Little does he
know that across the road is Marvin who is watching his every move through
a pair of binoculars. As John picks up the phone to dial out, Marvin whips
out his cellphone and rings John's number, hoping to time it exactly right
so that his call is put through before the first ring and just before
John picks up the handset. Lets say he succeeds. Marvin has control of the
line. Marvin plays dial-tone down the line and John dials numbers on his
phone not realising that they are doing nothing. Marvin plays a ring tone
and then a high-pitched "Hello?". "Hoho!", John says, "Miss September. How
about an appointment later in the day?". But it is not Miss September, it
is Marvin. "Hoho!", Marvin says, "This is a private investigator hired by
the proprietors of your dead wife Betty's estate. You've just cost
yourself millions of dollars by violating the infidelity clause in your
dead wife's will." The feature has been exploited.
Another example of this kind of stupid user interaction is a jail trick
from the US. The phone company introduced an automated reverse charges
service where you gave it the number to call, record who you are and the
service would ring the callee and say "Would you like to accept a reverse
charges call from" and then the recording of you saying who you are,
followed by "Please press 1". A feature of this service was that, in
America's multi-lingual environment, you could have the "Would you like to
accept a reverse charge call from" in Spanish. People would make the
service send the recording in Spanish, but then, instead of their name,
they would say ... "If you would like to hear this message in English
Please press 1". Seeing as most people wouldn't understand the Spanish,
they would press 1, but doing that would really accept the charges thus
leaving them talking to a crim who promptly attempts to social engineer
them into forwarding the calls through their PABX entirely on their own
money instead.
These are examples of seemingly innocuous feature interactions that while
not a problem that can be easily foreseen, if widely exploited become a
major problem. I have to admit the first example is abit far-fetched and
is really a conceptual understanding example. The second, became a major
real-world problem.
4.04 : Feature Interaction Causal Classification Approaches
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Studying the causes of feature interaction can be very helpful for
someone interested in discovering new interactions as it can educate them
regarding what capabilities and situations to look for.
A causal classification method we have already become familiar with is
the Data Sharing classification. That is, features in a call share the
call and state variables of the call. If a feature reads and uses a
variable which is later written to by another feature we have an
interaction. This is a low level approach to examining the causes of
feature interaction.
A method that I have seen used examines problem features and how they
might interact with other features (and stupid users) is also used. I will
use a classification scheme like this to go into real world feature
interactions in a the last part of this section. This method helps to
understand what the capabilities of a feature are and what other
interactions it may be capable of introducing.
Another, and I think, complementary approach to identifying and
classifying the causes of feature interaction lies in examination of the
causes of interaction at a higher level pointing towards the functions
and capabilities of features rather than purely variable competition. A
highly regarded scheme from academic literature identifies three classes of
feature interaction causes; Violation of feature assumptions, limitations
on network support and problems intrinsic in distributed systems. There are
many different sub-classes within these, some of the more widespread of
which we will discuss as examples. I will overview these classes here,
hopefully in an easier to understand manner or atleast provide you with a
commentary on existing material. Be aware, that a feature interaction can
be caused by one or more of these causes.
Violation of Feature Assumptions
Not realising that a variable may be later written to in a call is an
assumption made by a feature. Due to features often being developed over a
long time and/or separately from other features in a network, they can
make many assumptions regarding the environment they are operating in.
Some of these assumptions are :
(*) Assumptions about Naming : A 'name' refers to a means by which a node
or a party in a network is known. A common assumption made by features
is that addressing a call to one 'name' will address that call to one
party. Certain other features violate this assumption, Call Forwarding
and similar services (AIN 1800, line hunt etc.) can make one name
refer to any other party or even multiple parties depending upon call
variables (ie. CallingPartyID). Remember the interaction between Call
Forwarding and Originating Call Screening? That was an interaction of
this type. Call Forwarding violated assumptions made by OCS.
(*) Assumptions about Call Control : My personal favourite. A feature may
assume that they are going to be used only in a certain type of call.
For example an originating call. However, features such as Automatic
Recall can alter the call type from Callee to Caller. This has
ramifications in regards to PICs that are passed and which party's
exchange they are passed at.
Limitations on Network Support
Bandwidth, signalling sophistication. These are examples of network
support. If this is lacking there may not be enough resources to give the
feature all the information it requires and a feature has to intepret much
based on context which can frequently be ambiguous.
(*) Limited CPE Signalling Capabilities : As we mentioned before, an end
user has only a small number of signals they can send to the exchange
in order to control their features. DTMF, Flash and disconnect. If the
context in which they are used in not clear a mistake can easily be
made.
(*) Limited Network Communication Capability : It is common in AIN setups
to only allow a certain amount of TCAP queries for each call. This is
enforced due to the possibility of feature interactions causing a
continuous loop. However, a consequence of this action may be that
features triggered legitimately, if triggered after many others, may
not be allowed to go through.
Intrinsic Problems in Distributed Systems
The problem of managing systems with millions of users and in which the
users have access to more than a small amount of functionality is a major
problem, not just regarding security in the computer science industry.
(*) Resource Contention : We saw an example of this in the Call Waiting
vs 3-Way Chat interaction. They both compete for a 3-way bridge at
the exchange. If one feature is activated, other features may not be
able to due to resources having been used.
(*) Timing & Race Conditions : Combined with ambiguous signalling, race
conditions (which control thread 'wins the race') in terms of which
control thread is currently active in the processor can cause
interactions. Also, things like how long the switch-hook is depressed
can indicate a flash or a disconnection depending upon the timing of
the depression.
(*) Distributed Support of Features : A simple example of this is AIN vs
Switch Based Features. It might be easier to track and coordinate the
features and their capabilities on one of those network elements, but
tracking them across network elements becomes much harder.
(*) Non Atomic Operations : If a feature cannot execute in a call while
another feature is executing it can be said to be atomic (smallest
possible type of execution sequence building block; analogous to
atom). If a second feature executes before another is done, you may
not just have a problem of data sharing between PICs, you have the
problem of data sharing between execution cycles, within the time the
features are executing and reading, writing and using variables.
Spaghetti.
4.05 : Feature Interactions In The Australian Phone Network
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
OK, this is the part you've probably all skipped to. This is where I
apply the techniques we've learned to the Australian phone network and
detail feature interactions that are alive and working in the Australian
phone network. I will classify by Call Forwarding problems, then Call
Control Assumption problems and will go on to give you abit of additional
info on how to find new feature interactions.
:: Call Forwarding Interactions ::
Toll Free STD
We've seen a couple of ways HomeLine feature settings can be altered by
an unauthorised individual (Remote Control, Biege Box). An obvious
example would be to forward the number to a number interstate. Calling the
number would incur the cost of a local call, however the forwarding
number would pay for the STD charges.
Telstra has attempted to mitigate this problem, or atleast make it more
obvious to a customer, by allowing forwarding to STD numbers only on
Call Forwarding Unconditional. Call Forward Busy & Call Forward Timed do
not allow forwarding to STD numbers.
The forwarding party always pays for any extra costs incurred for calls
to an STD number. If the caller paid, there would be greater problems.
Imagine an unscrupulous 1800 number owner forwarding calls to his other
number, a 1900 number. It is far more easily exploitable.
The fact of the matter is, Telstra are fully aware this feature
interaction is operational in their network, but know that businesses
wish to forward their numbers to interstate locations when off on the road
and homeowners when they are on holiday. The result? Telstra accept the
risk.
Impersonation
Your target in this case could be a dialup or a person. Simply put, you
forward their number to a number under your control and pretend to be them.
This could mean offering them a login screen or trying to social engineer
them.
Harrasment
Its been done plenty of times before. Forward their number to a porn line
or see how many porn shops and brothels you can social engineer or beige
box into forwarding their lines to your target's number.
Man-In-The-Middle Attack
Lets see now what happens if we add a conference calling capability to
the equation. We will use a "third party" service (ie. either a bridge with
a tap or a computer with two modems sending data between).
Imagine a list of dialup numbers in a call centre or for remote access to
a computer system. They are set up in Line Hunt, that is if the dialed
number is busy the call goes through to another number and if that number
is busy, another one and so on. The next available line is "hunted" for.
Take one of those lines (not the main one) and unconditionally forward it
to a line under your control. Your line connects to your "tap" device and
then calls out to the main line number again.
This causes serious problems for dialup security. If the authentication
system on a dialup uses challenge/response, this can be bypassed by getting
a legitimate challenge and feeding it to the caller in real time. Receive
his legitimate response and use it to gain access, then disconnecting the
real caller from the conference.
The same thing can be done with Selective Call Forward. You configure the
feature so that whenever anyone but you calls a number they are forwarded
to your "incoming conference" line. When you call back the number (now
monitoring everything and in complete control of the call) your number is
put through.
It would also be possible to do this if you kept the caller idling on the
line when the call was forwarded to you and turned call forwarding off
before making the call to the same number, it might be a bit difficult to
implement though.
Malicious Malicious Call Trace
No its not a typo, I've typed malicious twice. So someone is ringing you
up with Caller ID Blocking enabled and you want to know who it is. Maybe
they're hassling you, maybe its your ex-girlfriend trying to gain your
acceptance for breaking up with you (whatever). You want their number.
Malicious Call Trace could get it, but in that case the number would be
printed out at the exchange and a polite letter sent out to the caller. That
scenario is unacceptable. You want to go round their house and beat the shit
out of them or ring them up and hassle them! Here's what you do.
Forward their number to a 1800 number owned by a local business with
Itemised Billing. People with 1800 numbers pay for the calls made to them
and so can get the number of the caller regardless of Caller ID blocking
(You know which business has itemised billing because you frequently go
through people's mail looking for documents you can use to create false
identities.) Now, when they call you up, they will be forwarded to the 1800
number, be momentarily confused but get recorded on their bill. Now, when
their next bill is due you nick their mail. Viola, stalker surprise.
Hidden Called Number
This is the reverse of silent line. They don't know the number that they
call. Sounds impossible huh? Well, you want someone to be able to contact
you, but you don't want to give them your real number. What do you do? You
forward someone else's number to your number. It will be changed after a
while but its good for those on the fly social engineering attempts where
they demand to call you back or they have to call you back the next day or
in an hour.
:: Call Control Assumption Interactions ::
This section details interactions that are a result of feature assumptions
regarding call control and not the Telstra call barring feature Call
Control (although the feature Call Control is discussed as an interacting
feature).
Call Return (*10#)
Call Return is the Australian version of Automatic Recall. If someone
calls you and you miss the call, you can DTMF dial *10# to get a recorded
message of who it was that called you. This is actually an old vulnerability
that has been fixed. I found it in a post to the newsgroup aus.comms :
On Wed, 25 Nov 1998 08:50:20 GMT, mobile@poboxes.com (Robert Bozinovski)
It detailed an interaction between EasyCall Call Control (Allows barring
of numbers such as STD numbers) and EasyCall Call Return (*10#). A feature
of this service was that, you are prompted to dial '1' if you wish to call
the number that it gives you. If the number that it gave you was an STD
number, or a number that was blocked under your Call Control configuration,
the call would be put through.
Call Control is a CLASS feature and was implemented in Australian phone
network 30 October 1998. The vulnerability was reported to Telstra on 27
October 1998, the vulnerability was fixed 1 December 1998 nationally.
My best guess on what the cause of the interaction was is that when the
Call Control feature allowed you to immediately call the number it skipped
over a number of PICs, the result of which the Call Control feature was not
activated.
Call Return will not allow you to find out or call back without knowledge
the number of a caller with a silent line, although I wish they would as it
could possibly introduce some nice vulnerabilities. That is probably why
they don't.
12456, 12455 & Call Control
This was a test I did after reading about the Call Return interaction. I
remembered that on calling directory assistance (12455) one weekend, after I
received the number, I was given the option to dial '1' and immediately be
put through to the number I had requested. My test was to determine whether
this feature, or 12456 (always automatically put through) would put me
through to an STD number while my phone had STD barring enabled. Calling
from a line with STD barring enabled I found that I was unable to call
12456, but what surprised me was that when I called directory assistance I
didn't receive the prompt to press '1' and be immediately put through.
Not exactly groundbreaking news, but it is interesting. Technically, it
could still be classed as a feature interaction as it denies the use of
features that aren't directly related to the type of things that are wished
to be denied. The optimal response to this kind of thing would be that I
could not be automatically put through to an STD number, however, it would
give the option to be put through via 12456 or pressing '1' in 12455 for
non-std numbers. Could this be a quick fix for a feature interaction
previously noticed? It certainly points to some interesting ground for
potential interactions in Telstra's network anyway.
Payphones
This is a test I did around 2 hours before writing this. In the UK, they
had a similar problem when they introduced a feature called Ringback. If
they dialed an engaged number, they could enter a special DTMF sequence and
when the number was free both phones would be rung back. The call would be
billed to the subscriber. However, when used from payphones, due to the
phone being rung back there was no time that they had to put coins in the
phone.
For starters, I tried out Call Return (*10#) on payphones. Had problems
with entering the activation code on X2s because '*' means redial. Had to
be done with a tone dialler. Also tried it on a Blue Phone. I got a "The
feature you have tried to use is not provided as part of your service"
message. This is interesting because Call Return is enabled on all Telstra
landline phones by default. They would have to be taken off payphone lines
specifically. So what would happen if someone used a payphone on a regular
line? My guess is they'd be vulnerable.
We have a feature synonymous with the UK's Ringback over here, its called
Call Back Busy, when you get an engaged tone you go :
[Switch-hook flash] *37#
I haven't specifically tried this on payphones, but I tried *#37* which
tells you whether you have a Call Back Busy arranged and I got a "The
feature you have tried to use is not provided as part of your service" so
don't expect it to work. BTW did you know if you type in *nn# with n as any
old number like 89 you still get the "this feature is not provided as part
of your service" message even if the numbers don't correspond to any feature
available?
:: Finding New Feature Interactions ::
If you want to find a new interaction there are two approaches that you
can take :
1. Exploit a feature or interaction deemed acceptable by discovering an
imaginitive use.
2. Find an actual 'bug' type feature interaction.
Finding a new feature interaction is pretty much brainstorming, lateral
thinking. If there were a technically accurate method of discovering
interactions they would most likely be fixed. However, if you understand
how features & interactions work, what cases & situations to look for you
are better equipped to make educated guesses or do tests along a particular
line as you saw me doing in the last section.
For discovering some types of feature interactions you do have a technical
option when attempting to discover actual bug type interactions. There are
regular International Workshops on Feature Interaction detection and some of
the analysis methods that are used in the development process can be used to
detect interactions based upon things like analysis of call variables and
their use. Naturally a major barrier is that we do not have the source code
for features and therefore do not know what variables to use. However, you
can create abstract variable sets based upon what you know about how the
feature needs to work. Example variables I have used throughout this
article, CalledPartyID and CallingPartyID may not be what the variables are
called, but I know that for some features, this information is needed and
so a variable that stores this information exists.
5.03 : Conclusion And Further Research
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
So there you have it. While not as conducive from a user point of view as
something like the internet, a modern day telecommunications network is
still a viable breeding ground for security flaws.
This paper described security flaws regarding mostly to applications for
users (features), but do not think that this is the only type of security
bug that is present. This article may have covered a lot of ground, but
there is far more that it did not cover. In addition, you should treat this
article as an overview or introduction to the topics discussed, there is
still much more research that can be done into various topics only touched
upon here. Some further research topics are discussed below for those who
are just interested or those who wish to learn some more :
(*) To start with, there are in all likelihood plently of working feature
interactions in the Australian phone network. I studied a few features
for interactions while writing this, but I didn't examine all of them.
Someone interested in discovering new interactions would do good to
regularly check the telstra.com.au newsroom for new features being
introduced into the network and what possible interactions they might
cause.
(*) A full taxonomy of features was not presented here. It is considered
a user exercise to find out features currently in use in the Australian
phone network. It is quite easy and the only reason they weren't
included was because of space constraints. Check out
http://www.telstra.com.au/products/ for starters. In addition, exact
specifications or source code of features would certainly make
interesting reading, especially as pertaining to the exact variables
used by the features.
(*) Not all user interfaces were detailed here. Plently will spring up all
the time and, even for systems that aren't to do with phone network
feature control.
(*) OAM&P Systems were talked about, but none were detailed in this
article. This is a particularly interesting area of research as hacks
on these systems can provide an intruder with amazing amounts of
functionality. I'd certainly be interested in any information regarding
these systems, not just including how to bypass authentication, but
where they reside, what capabilities they have, instruction sets and so
forth.
(*) Feature interactions between user features and telecommunication test
systems were not gone into in detail here. This has lead to some of
the most interesting bugs of recent years, such as the 199 bug.
(*) Check out http://www.openss7.org/ They have created a free CCS7 stack
for Linux boxes. Why not put some proof of concept code together for
some of the CCS7 protocol hacks outlined in section 3. For that chapter
I mostly only chose the vulnerabilities that made sense to me, others
exist, but a lot of them are mainly concerns from the telecommunication
research and academic community. Actual CCS7 stacks will probably have
different APIs for interface and so the code would have to be ported to
a system used by actual telcos, but it would teach a lot.
(*) Something that I didn't end up having time to research was exactly how
much signalling on ISDN-D Channel could interface with CCS7 signalling,
particularly in the ISDN User Part. Apparently it is quite significant.
(*) The next generation in Intelligent Networking is TINA, I haven't looked
too much into it so I don't know too much about it (time constraints),
but check out http://www.tinac.com/ for the TINA Consortium. Telstra is
a part of it. Particularly check out papers to do with CRYSTINA,
CRYptographically Secure TINA.
- Marlinspike : p0lter_g@yahoo.com 08/02/02 05:18AM
#+#+#+#+#+#+#+# CABLE PRESSURISATION AND ALARM SYSTEMS #+#+#+#+#+#+#+#+#
- Dataclysm -
'DISCLAIMER'
I'd be surprised if any information in this article could *directly* be used
for illegal purposed by your average phreaker. This article is intended for
educational purposes, it doesn't really list any 'k-rad payphone exploits', so
unless you need to intercept high security transmissions from the actual cable
itself, this file won't give you any illegal information. Although I have
*attempted* to make this article interesting for phreakers of all levels of
skill, the sheer nature of the topic will probably write this article off as
'one of those technical documents that people always skip over in zines'.
Life's a bitch.
___________________________________________
CONTENTS
Introduction
Pressurisation Principles
Alarms & Bypass
- Contactor Alarm Principles
External Type
Contactor Gauge
In-joint Bellows Type
- Electromechanical Pressure Transducer
- Identifying Alarm-related Components
- Contactor Bypass
- EMPT Bypass
- Universal Bypass
System Design & Components
Interaction with Networks
Faults
Outro, References & Shouts
___________________________________________
INTRODUCTION
If you lived in rural Australia back in the 1950s, you can probably relate to
having the un-insulated 200km telephone 'pair' made from fencing wire drop out
every time it rained. Well, too bad Telstra hadn't yet thought up cable
pressurisation, because it would have increased the efficiency and clarity of
your pair ten fold. This file will *hopefully* give you a basic understanding
of Cable Pressurisation Alarm Systems - it will help you distinguish between
lines you can beige off of, and trunks that will spew molten metal at your face
if you cut them (I'm not making that up). This topic has absoluteley no
documentation on the internet (official or hpa) that I can find, so I thought I
should at least summarise the system. Anyway, enough rambling, into the
technical discussion.
___________________________________________
PRESSURISATION PRINCIPLES
Some time during the 1950s, some bright young field SME, full of potential,
came up with the idea of using air pressure to stop moisture entering cables
and thus shorting the connection. Prior to this, only defense and emergency
services had used cable pressurisation on their private trunks. Telstra (then
Australian Post Office {wow, pre-Telecom stuff... must be interesting...}),
realised the logic in 'prevention', and declared that from this day forth, 'all
large size junction and trunk cables', 'all large size customer main and branch
cables down to the cabinet and/or pillar', and 'all special circuit cables in
need of individual consideration' would be protected by the awesome power of
'pressurized air'.
Cable pressurisation is not too complex a principle; simply put, the air
inside the cable insulation/piping is of a higher pressure than the outside air.
Therefore, if the cable is punctured, moisture will not be able to get it due
to the air being *rapidly* expelled from the trunk. Cable pressurisation also
makes it easier for a field SME to locate the fault in the cable, by testing at
given points they can narrow the puncture down to a distance of roughly 200
metres.
There are two main types of Cable pressurisation systems: the static pressure
system, and the continuous supply system.
The static pressurisation system is only effective if all openings and leaks
in the cable are sealed. All pillars and branch cables need to be properly
sealed, as does the exchange end. A technician at the exchange pumps air into
the cable from cylinders, until the pressure reaches a set density - 70kPa to
be exact. More air is only pumped in when the pressure falls.
The continuous supply system is pretty self-explanatory. It is the main system
used by Telstra, and dry air generators for the system are installed at most
exchanges. These generators continuously pump air into the cables, keeping it
at a steady pressure of 70kPa. This makes it ok for there to be small air
leaks, as they are countered by more air being pumped into the trunk.
"So how does this affect me?", I hear you ask. Well, if probably won't unless
you're either very smart, or very stupid. Unless you want to intercept
inter-exchange datel communication lines, which is above the skill level of
your average phreaker, or attempt to beige from say, a trunk in a manhole,
which is below the skill level of your average phreaker, chances are you won't
have to deal with pressurised cables. But it always pays to be prepared, and
documenting obscure parts of the Telstra network can lead to discovering new
exploits.
___________________________________________
ALARMS & BYPASS
The two main types of alarms you need to be concerned with are contactor alarms
and electro mechanical pressure transducer alarms. Cable Pressurisation Alarm
Systems (CPA Systems), all use these types of alarms to alert an exchange when
cable pressure has dropped below 50kPa. Other less relevant alarms are also
listed in the next section, 'System Design & Components'. I will deal with
contactor alarms first.
~Contactor Alarms Principles~
These little gadgets are kind of like micro switches, except they are
triggered by air pressure, rather than physical pressure. When the air pressure
is high, the two contacts (metal bellows) are forced apart. However, when the
pressure drops below 50kPa, they spring back together, looping the circuit and
triggering the alarm. These alarms are spaced at such a distance that in the
event of a sheath fault occurring, a contractor will be able to rectify the
fault before the pressure drops below 20kPa, usually every two kilometres.
The two main types of contactor alarms are 'external type' and 'in-joint', but
both operate and work in the same way. However, obviously there _are_ some
differences, as I've attempted to outline below:
External type, in-joint and contactor gauge type contactor alarms all detect
air pressure using similar pressure-influenced internal bellows. Infact, the
only real difference is where the alarm is located and therefore how air is
routed through it. Basically, external type contactor alarms are 'external', as
the name would suggest ;), thus they are situated in a rectangular box which
branches off from the cable. Essentially, they 'sample' the air, rather than
act as part of the conduit itself. In-joint type contactor sensors intersect
the cable. They come factory-calibrated and then cannot by bypassed using the
'contactor alarm bypass' method. They are mainly used on coaxial cables, sealed
at atmospheric pressure. Contactor gauge pressure sensors have a gauge, and are
slightly larger, but work on the same principles as in-joint type contactor
alarms. However, the 'bellows' are slightly different. They are attached to a
tube, which the air flows through. When the pressure is !high, the tube is
full of air, and the bellows are spaced apart. When pressure drops to a certain
level, the contacts touch each other and short the circuit.
All contactor alarms on a cable are connected in parallel to a single pair.
When a contactor is switched it shorts the the alarm pair, and a scanner
monitoring the line at the exchange raises an alarm, which is then forwarded to
a WMC (Work Management Centre). The scanners can also be used to detect the
resistance, which can be used to locate the fault more precicely by detecting
which contactor triggered. Where the cable is used for the operation of carrier
systems, the pair with the worst crosstalk characteristics can also be used for
the alarm pair.
~Electromechanical Pressure Transducer Alarm Principles~
In essence, this sensor is a sort of potentiometer (variable resistor), in
that the air pressure influences a contact which can pivot along a row of
several resistors, connected to the other contact. The air pressure forces the
pivot contact to connect in series a set resistance. For this reason, EMPT
alarm pairs must be individual, rather than in series like contactor alarm
circuits. The resistance ranges from 100 kOhms to 3.82 MOhms and corresponds to
a pressure range of 0 kPa - 65 kPa. Both in-joint and external (manhole wall
mounted) EMPT sensors are in use, in much the same was as contactor alarms. At
the time at which the information used to write this article was written, a new
EMPT alarm was being developed, which worked in series rather than requiring
dedicated alarm pair circuits for each sensor. It could possibly be in use, but
it is likely, even if it is, that it is only used on rather new cables and
links. It would not be very common, but if encountered, it should be treated
like a cross between a contactor and an EMPT alarm, and the bypass modified as
such.
~Identifying the Contactor Alarm and Pair~
Ever noticed a rectangular box (a.k.a. pressure test point) in a manhole
roughly 15cm by 8cm? No? Thats because contactor alarms aren't installed in
most manholes ;). You're best bet, when looking for a CPA sensor, is to aim for
large manholes, or even a cable well near an exchange. Don't bother with the
wussy 2x1 manholes, etc.
Alarm pairs are a different matter altogether. If you do, for some reason,
want to manipulate an alarm pair, I suggest you do it on a relatively isolated
and unimportant trunk, since to access the pair itself you're going to need to
first sever the cable. Remember, contactor alarms are connected in parallel,
not in series, so short circuiting one alarm will decrease the resistance,
enabling a Field SME to easily locate the fault by comparing results to a table
(talked about further in Network Interactions).
Alarm pairs will usually be kind of separate from the rest of the trunk. While
the other pairs will mostly likely be coated in shitty plastic insulation, the
alarm pair will *usually* have thicker polyethylene insulation. I guess the
motivation behind this is 'how can an alarm pair alert the exchange that there
is moisture in the circuit if there is moisture in the circuit?'. I'm not
complaining though, as this is the only way I can think of to actually
distinguish between a normal pair and an alarm pair. Sometimes, an alarm pair
will also be protected by paper insulation; usually on much older cable
circuits.
~Contactor Bypass~
Contactor alarms can be bypassed quite easily with a little knowledge of cable
pressurisation. Now, I'm going to presume that seeing as you have read to this
point, you are an 'above-average' phreaker and/or have a use for this
information. Say you wanted to intercept some Datel communications travelling
from one exchange to another along a main trunk. These trunks do not connect to
any Cross Connection Units (CCUs) such as a pillar or cabinet, so you will need
to find a service point such as a manhole and cut the actual cable. This will
trigger alarms - not immediately, but to intercept any inter-exchange sensitive
communications you'll need to be there for a while, and you don't want to be
interrupted by a friendly technician enquiring why you've severed a major trunk.
The first point I would like to bring up is that these cables will probably be
pressurised at the high-security level of 95kPa because they contain SECURITEL
DDL lines. A little tip for j00... DON'T FUCKING CUT THE TRUNK IN HALF!!@#%! If
you sever inter-exchange transmissions you'll get half of Telstra arriving in
their little vans.
In order to bypass this alarm, one method involves re-calibrating the alarm to
a new pressure, in effect reducing its sensitivity. While hard to do correctly,
it is still probably the easiest bypass available for these types of alarms.
(btw, remember that while it would be good, you do NOT have to bypass all
alarms in a series, just the one you are working on at that time. It probably
won't effect you if a technician turns up at the next testing point along the
cable.)
Now... contactor type pressure alarms, be they external type or gauge type,
have an external 'testing point'. Using this point they can be calibrated. The
testing point should be rather easy to spot. It looks like a small rectangular
box attached to the conduit for an in-joint type alarm, or is simply an
extension of the external type contactor alarm. Using these test points, the
sensors can be calibrated to the required level by a Field SME, or by a
phreaker >;).
Firstly, a tip - don't open it up unless you have social engineered the WMC or
disconnected the alarm pair. While this makes it harder to calibrate to your
required level (as you have to guesstimate what pressure setting you have it
at), it stops the alarm from triggering before you have a chance to calibrate
it.
Ok... now find the test point. It is simply a schrader valve poking out of the
conduit, and looks a lot like the valve on a bicycle tyre. With one hand,
slowly unscrew the test point, releasing air and de-pressurising the cable.
With the other hand, adjust the screw on the top side of the contactor alarm
test point quickly anti-clockwise. Without a pressure guage attached you are
just going to have to guess at which point you are at, but thankfully, and
inconsitencies will probably go unnoticed as long as by the time the test point
is completely opened, the contactor calibration screw has been turned as far as
it will go to the left. Remember, 'high pressure' alarms are usually only
installed at the exchange, and so as long as you open the test valve
afterwards, you could probably completely adjust the calibrator screw before
opening up the cable for safety. (I hope this made sense. I _have_ done this
before, so I know from personal experience that it works, but it is rather
difficult to explain. If you are intending to do this and are not completely
comfortable with how to complete this procedure, feel free to contact me at
dataclysm@tokyo.com with questions or for further details).
Bourdon Tube Gauge type contactor alarms have external contacts. These can
just be removed. Simply open the box and either hold the tube in its extended
position, or remove a contact itself (carefully). These alarms are much easier
to bypass than the more common external type, but unfortunately I didn't add
"more common external type" for laughs.
In-joint contactor alarms are used mostly to guard coaxial cables, and CANNOT
by bypassed by using the above method, since they have no external calibration
point. If, for some reason, you want to tap a coaxial cable, you will need to
sever the alarm pair itself, or use a universal bypass.
~EMPT Bypass~
External Electromechanical Pressure Transducer sensor alarms have a Schrader
calibration test valve fitted, and therefore can be bypassed in much the same
way as external and guage type contactor alarms can be. However, since the
resistance values are different (and MUCH more sensitive), care must be taken
to either precicely synchronise the bypass calibration movements. If I
encountered an EMPT alarm, I would prefer to take my chances with cutting the
alarm pair itself. However, its your choice. Once again, I can be contacted for
enquiries and/or further details on EMPT bypass methods.
~Universal Bypass (both contactor and EMPT)~
Since cable take a while to fall below 50kPa, you may be able to take
advantage of the continuous flow pressure system. It tolerates small leaks...
If you locate your pair quickly you can patch up the cable (leaving a small
area for your tap to connect of course). Depending on how much air is being
lost, you may be able to leave the tap unnoticed (at least by the CPA scanners)
for up to a week.
You could always attach your own air pressure source through a bypass valve or
testing point valve, although you would need a regulator to prevent trigerring
any high-pressure alarms. Perhaps this equipment could be taken from an
exchange?
Social engineering an exchange, or better a WMC may also provide you with
limited time, and is probably the best method if you want to simply intercept
some data. Just ring up the WMC of your area (numbers can commonly be found
trashing at an exchange in the area), and notify them that you will be
servicing a cable in the selected area. Remember to pretend that you are new,
as an excuse for not following the correct procedure. Don't be afraid to ask
procedure-related questions to the operators! They will take for granted that
you are a legitimate technician since (1) you have the controlled WMC number,
(2) you are actually notifying them, & (3) no phreakers are stupid enough to
beige of a major trunk for the purpose of obtaining free calls, and they know
this.
My personal choice of method? - Social engineering the WMC followed by
re-calibrating the contactor alarm. If intending to tap a trunk I'd ring my
local WMC informing them of my intention to 're-calibrate' the alarm at a
certain point, something along the lines of "...have been asked specifically to
fix a fault not yet listed in the DIRECTOR database, proceeding to so-and-so
point, please ignore any cable pressurisation alarms coming from this area
under maintenance...". Secondly, I'd try to be as discreet as possible when
tapping the actual line, by using the afforementioned bypass methods. The more
'ninja' like you are, the less likely they are to send another technican to
'help' you rectify the fault, and the less likely they are to become
suspicious.
___________________________________________
SYSTEM DESIGN & COMPONENTS
CPA systems are designed following several guidelines:
- All large size underground trunk, junction and main customer cables from
MDF's to pillars are to be protected by continuous pressure.
- Long distance coaxial cables and other cables requiring higher security have
a pressure of 95kPa, and alarms are triggered when the pressure falls below
70kPa.
- Some cables may have higher pneumatic resistance than others, and thus any
pressurisation alarm systems installed on these cables are only good for a
longer-term alarm rather than immediate. Such cables include the 'special'
cables mentioned before, requiring high security. Because they are usually
under 100 pairs, there is much less space for the air to get through, therefore
there is a higher pneumatic resistance. I suppose it could be compared to
blowing air through a pipe and a straw.
In the exchanges I have seen during my travels, I have noticed a room
'connected' to the back with large air vents. I presume that this is the
pressurisation room, because I can hear fans and motors coming from inside. The
machines inside this room are called 'compressor/dehydrators', gathering air
from outside, removing all moisture from it before pumping it into a cable.
Some smaller exchanges may replace this equipment with cylinders containing the
air. These cylinders are pressurised at approximately 14MPa, and are fitted
with double reduction regulators to control the release of the air into the
cables and keep it at 70kPa. RAX and unmanned exchanges usually use cylinders.
Because these cylinders only contain either 1.3, 3.2 or 6.4 cubic metres of
air, when there is a major sheath fault a portable compressor/dehydrator is
moved to the exchange. Portable compressor/dehydrators come in two types, the
P129 Electric Motor Driven, and the P130 Engine Driven.
If pressure is urgently needed in the field, cylinders can be used to supply
it. D" size cylinders (1.3m^3, 10kg) are used mainly for 'flash testing' of
cable joints and CPA fittings. E" size (3.2m^3, 32kg) are used to charge new
cables initially, and after service. G" size (6.4m^3, 56kg) are stored at
exchanges not using compressors/dehydrators. Cylinders are only drained to a
minimum pressuer of 1000kPa, otherwise moisture in the cylinders may enter the
cables. If a cylinder neck is damaged, it can 'become a deadly missile' (quote
from over-excited Telstra manual).
In a typical CPA system, air is pumped into the cable using a
compressor/dehydrator, which cools the air and dries it using a heatless air
dryer. However, before it enters the actual cable, the air is stored in an Air
Reciever to regulate the flow. Along the cable are located several different
alarms sensors, including the contactor switch which I have already talked
about. Other alarms include sensors which trigger if it no longer senses a
supply of air from the compressor, humidity alarms and high pressure contactor
alarms. I can guarantee these alarms wont affect you during any 'legitimate'
phreaking activities, ie. not stupidly vandalising trunks.
Many phreakers wonder what the point of manholes are. Manholes are mainly used
for CPA monitoring and service rather than cross-connecting pairs. For this
reason, manholes can often contain dangerous gas, such as nitrogen, due to
leaks in cable sheaths or joints. Its not a good idea to screw around with
bypass valves, test points and the such inside manholes, as it (1) could be
dangerous, and (2) would be pretty damn pointless.
___________________________________________
INTERACTION WITH NETWORKS
Most of the info I used to write this article is slightly outdated, so I added
this section to cover the more up-to-date interaction with Telstra networks.
Such interactions include Exchange Systems and Work Distribution Systems [WDSs]
such as DIRECTOR - with regards to fault reporting and restoration, etc., but I
have focused more on the alarm interaction side of things.
All the info I have refers to internal exchange alarms being triggered by
contactors and humidity sensors, etc., but I also caught a referral to 'a new
WDS being introduced to handle these alarms'. Well, we all know most exchanges
aren't usually occupied at night, so it would seem unlikely that Telstra have
chosen to stick with *any* exchange based alarms whatsoever, and the
introduction DIRECTOR and WMCs [Work Management Centres], as well as the
increased responisibilities of the GOC [Global Operation Centre] with regards
to faults and CAN activities, it would be not only more efficient, but much
more convenient to have the alarms automatically notify such networks and
systems.
Basically, upon being triggered, an alarm will send data directly to a WMC via
DDLs [Dedicated Data Lines]. They will be automatically filtered by a CAN Fault
System (thats another article in itself... hmmm...), and classified to a degree
between 'urgent' and 'non-urgent', much like other CAN system faults, like
RIM/RCM equipment (PGSs). This alarm (fault) is then forwarded to DIRECTOR, all
still at the WMC. All the alarm detection processes, such as matching the
resistance of the alarm pair up to a table to determine the rough location of
the fault, etc, is also done by the CAN Fault System.
What this means for us is that once an alarm is triggered, depending on how
important you judge it would be classified as, it would be best to finish up
and get out of there quickly. This only stresses the importance of a ninja like
approach to alarm bypass, rather than a 'hit and run'.
___________________________________________
FAULTS
Contactor alarms are relatively quick in signalling faults a distance from the
exchange, but closer faults may be recognised by air flow readings at the
exchange. Either way, it is quite easy to locate the exact where-abouts of a
sheathing or jointing fault. The process of rectifying the fault begins with
exchange staff calling in a CPA technician, done through a Work Dispatch System
such as DIRECTOR. The CPA technician visually inspects the line, keeping an eye
out for leakage from valves and test points, leaking seals or pillar/cabinet
tails, leaking contactor alarm cases and low insulation resistance across
contactor terminals. If the visual inspections do not succeed in locating the
fault, halide gas is pumped through the cable from a test point and detected
with an electronic gas detector (Krowkon gas detector is used by Telstra). Once
the fault has been located and sealed, a report is filed to the Supervising
Engineer, Lines Practices and Protection Section again using DIRECTOR.
Fixing the fault can range from simply tightening/sealing a loose connection,
to up-rooting a 200m section of cable between manholes. Usually, the leak will
be located in a manhole, since it is as these points that the conduit is
exposed to the 'outside' world. Faults can be localised further by using a
technique known as 'soaping' the joints, which basically consists of applying a
liquid over the entire exposed length which reacts when the dry air is pumped
out. Other fault location methods include filling the trunk with a gas which
reacts with phenophalene and using a solution called 'Sherlock B' which, unlike
the soap solution, does not shrink and crack the polyethylene cable coating
sometimes used.
___________________________________________
OUTRO, REFERENCES & SHOUTS
Well, with any luck that may have proved to be of some use to some people. It
was certainly a learning experience for me documenting this more obscure part
of the CAN, but then again, I have a use for it ;). Other 'Mega Super Happy'
articles are available at the digital infraction homepage. Check it out at
http://www.digital-infraction.org
As always, comments and constructive criticism are welcome. For example
'dataclysm, I hate your writing style' is NOT constructive. A better
alternative would be 'dataclysm, I hate your writing style because you include
too irrelevant lame jokes and seem to be partially illiterate, and this is what
you can do about it...'
Shouts go to Psyincerise for helping with the info for this article, and
Marlinspike for checking the speling, etc. <--- note witty joke. Which brings
me to my next point: any errors in this document, be they grammatical or
spelling, are his fault. Muaahaahaha.
.eof.
#+#+#+#+#+#+#+#+#+#+# LOCATING TELSTRA EXCHANGES #+#+#+#+#+#+#+#+#+#+#+#
- Dataclysm -
Disclaimer:
Disclaimers shouldn't really have to be written on such material. Freedom of
speech, and equally important, of information, are basic rights which are
somewhat deprived, such as our right to a private home life, and our right as
humans to private communications. The information presented in this tutorial
may be used to discover further information, which can directly be used to
somewhat secure our right to private communications. In my 'anti-disclaimer'
idealogy, I'm not going to say "use these methods at your own risk". Rather,
get the fuck out there and find some of these Exchange locations, share them
with the rest of the hacking and phreaking community, and trash the hell out of
them. If you get caught, tell them that "dataclysm brain-washed me". Most of
all, don't be pressured into accepting this reality as the only possible
version. Contribute to the growing change in the world by understanding the
technology which makes civilisation tick.
Introduction:
So, you're an aspiring phreaker, desperately looking for a cleverly hidden
Telstra exchange so you can trash it and become elite... or maybe you're
slightly more advanced and are compiling a list of local manned exchanges so as
to find the right one to break into? Either way, this text can help you.
Firstly, I'd just like to give a bit of background as to why I wrote this text.
When I first started phreaking, months ago now, I only knew the location of one
Telstra Exchange. I quickly became bored with scavenging through the dumpster,
and set out in search of more 'profitable' exchanges. Up until this day I'd
never done a search quite as big as this one was, for exchange locations in my
area. But I found nothing. I realised that while exchange locations in NSW and
WA had been mapped out in Morpheus Laughing, many phreakers in other states
faced the grim challenge of locating their exchanges on their own. Further
more, there were absolutely NO FUCKING TEXTS on doing this. Eventually I found
a method which, although innefficient and difficult, bore the results I was
looking for. I located a lot of exchanges in my local area, but my dream of
compiling a national listing was still far from complete. I set out in search
of another, easier, more efficient method. When I read about Pulse Echo Testing
I finally found what I was looking for...
Oh yeah, and even if you are really elite and know all the locations in your
area, this text still may be of interest to you since it also outlines ESA and
therefore LRD location as well.
In this text I have outlined two different methods of locating Telstra
Exchanges. Chances are, one of the methods listed will help you locate you're
closest exchange, no matter where you are. If, like me, you are interested in
compiling whole area databases, a combination of the methods will probably be
your key to success. Some methods have been discovered by others in the past,
but they never wrote anything in detail on it.
THE FIRST METHOD - COMPILED RESOURCES
This was the first method I discovered, and was also the one I used to locate
ALL my local exchanges. The idea first came to me when I was searching on the
internet for "exchange locations", and found reference to an exchange zone and
location map available to ISPs.
Firstly, to clear up any discrepancies, these maps DO exist. Don't even bother
trying to obtain one, though, unless you actually ARE an ISP, or you are
fucking brilliant at social engineering. Most lower level Telstra customer
operators have no idea that these maps actually exist, so you'll need to speak
to some one quite high up in the ranks, and even then your chances of actually
successfully obtaining such a map are slim at best.
If you want to try to get an Exchange Location and Zone map, remember, that
you *don't* want it for the locations of the exchanges, rather the zones, so
you can calculate call costs for your customers and thus service areas. If you
actually manage to obtain this map, you'll find it is rather big, and has small
dots on it. These are the exchange locations, and you'll probably have to layer
the map itself over a street directory to find the actual addresses..
In itself, I don't consider the exchange map to actually be a 'method' as
such, since the chances of actually obtaining one are not very good. The actual
method listed here is slightly more complicated.
To start off, search on the internet for your local council home page. Now,
I've yet to find a council that doesn't keep summaries of their meetings on the
internet. You are looking for a section entitled 'minutes'. It shouldn't be to
hard to find if you have an IQ over 70. Once in this section, there should be a
search field (again, I've yet to see a homepage without one...), in which you
should type several combinations of the words 'exchange', 'Telstra',
'telephone', and 'telecommunications'. With any luck, you should find reference
to a 'Telstra Exchange' in one of the minutes. It will probably be mentioned
either as the topic (eg. for renovations, or putting up signage fronting a main
road), or as part of the neighbourhood (ie. "nearby the construction site are
several facilities, including a Telephone Exchange"). If you decide to go with
this method, I suggest you try not only your actual area, but a few neighboring
ones as well, if you are serious about finding an exchange in your area.
This method is rather shaky, and you may experience limited success with it,
but I thought it was worth a mention in here since I found it quite useful. To
date, I've found about 40 exchanges nation-wide this way. They're all mentioned
in my listing.
THE SECOND METHOD - AUTOMATIC LINE PULSE ECHO TESTING
My personal favourite method. Works well in metro areas, but don't even bother
if you live in the sticks. Now, the theory behind this method is slightly
complicated, but I'll go into that later on. You will need:
- A payphone nearby
- An AGS (FAST) ID and PIN
- A relatively recent edition of the White Pages
- (optional) A reverse directory
- Paper and a pencil
- A street directory
- A ruler
- An IQ over 70 (or a calculator, its your choice)
- Access to the Internet
Once your little 'arsenal' has been assembled, its time to choose the exchange
you want to find. Lets say, for example, that I lived in Kensington, SA, and I
want to find my closest exchange.
1. Right, its time to give the Telstra homepage a few hits. Go to
www.telstra.com.au and navigate your way to the ADSL section of the site. Now,
lets find if my area is ADSL enabled? I enter in my phone number, and up comes
a results page listing my ESA [Exchange Service Area] as 'NRWD' in the top
right corner of the screen. Alternatively, if your area isn't ADSL enabled, it
will give you an error screen. You will need to go throuh the prefix section in
the back of the white pages by hand to match up your prefix with your Exchange.
In step one we established that the closest exchange to my area, Kensington,
was the Norwood Exchange.
2. Ok, lets hit the books. In the back of the White Pages Telstra has
kindly provided us with a list of prefixes, matching their exchanges. I'm
looking for the Norwood Exchange prefixes. Best to write down a few - 83346xxx,
83664xxx, 840143xx. If I'm fortunate enough to have a reverse directory, I can
just enter in these prefixes and find numbers in that range, complete with
addresses. However, lets say I don't, so I have to go through the White Pages
by hand and locate addresses with corresponding phone numbers in those
prefixes. I want roughly 6 addresses, and when I find them I write the
addresses and their phone number down.
3. Now for the fun part, lets trundle down to the nearest payphone and
work around the FAST block. (courtesy of Zaleth and Dies Irae, where would we
be without these two...? Probably doing the tests from a beige box hooked up to
some one else's line, but thats a hassle). 180005005, follow on, * (redial),
hold down '1'. I enter my AGS ID and PIN and am presented with a menu. I press
'2', to perform a test on a remote line. I enter in the FNN [Full National
Number] and then press hash. 0883664178#. The number is read back to me, and to
confirm I press '1'. I perform a SULTAN test on the line, and listed to the
results playback.
If the SULTAN test is unable to be performed, if could be one of three
things:
1. The line is part of a PBX, try a different line.
2. The line goes through a PGS, try a different line.
3. Repeated failure may suggest that SULTAN equipment is not
installed for that prefix. Try a different prefix for the
same ESA.
Patiently ignore all the crap which is read back to you. After the SULTAN test
has been completed, I want to perform "further testing". I dial '7' for the
"A-B Open Circuit" test, and listen for the final result. A recorded voice will
give a figure in metres, saying 'virtual distance'. Write this figure down next
to the address of the number.
4. Repeat step 3 for the remaining numbers, 6 numbers should provide you
with at least 4 successful distances. Usually 4 will be enough, narrowing the
exchange location down to within about 50-100m, but for the perfectionists out
there you may want to try 5 successful numbers.
5. Return home, and get the ruler, calculator, and street directory. Mark
out all the addresses in the street directory (using pencil). Then, divide all
the distances you got by two, to get the virtual length of one leg to the
exchange. Using basic trigonometry, pinpoint the intersection of the 4
distances for a pretty accurate stab at the exchange location. It will probably
be on a main road, usually at an intersection of a side street or lane. All you
need to do now is confirm the location. If you can't be fucked getting down
there, ask a friend who lives nearby to look around for a base station, since
exchanges usually have mobile phone towers on their grounds. Congratulations,
you've dealt Telstra a blow by finding a 'classified' location.
Arghh... I guess its time to go into the theory now... Well, most ALTs
[Automatic Line Testers] are equipped with an A-B O/C [Open Circuit] test
function. The way an automatic tester would perform this test is by using a
Pulse Echo Tester. Basically, how this works is by sending a ping (or 'pulse')
down the line, and timing the 'echo', or 'return'. The ping can only travel
through an open circuit, so this test is used in most ALTs do determine whether
the line is open or not. SULTAN, however, uses flashy little RVAs [Recorded
Voice Announcements] to give a virtual line distance. I presume it would factor
in stuff like line resistance, inductance, insulation to earth resistance, and
other variables, but knowing Telstra... (heh)
It all seems nice and convenient until you realise that theres not feasable
way that Telstra could (or would, for that matter) actually calculate the
distance from the exchange. The reading we receive is a total line distance.
Lines don't go straight from the exchange to the CPE [Customer Premise
Equipment], they take a windy road, passing through CCUs [Cross Connecting
Units], such as pillars and cabinets (btw, a single pillar or cabinet is
referred to as a CCP [Cross Connection Point]), and cable looping in junction
pits and manholes. A single triangulation using these results would probably be
quite innaccurate, but using 4 or 5 can yield usable results.
A basic layout might be something like this: (please excuse crappy ascii
diagram...)
______CPE
J (pit)
|
|
X (pillar)
\\\\
\\\\
\\\\
O (cabinet)
|
|
|
# (exchange)
As you can see, the line does NOT go directly from the Exchange to the CPE,
rather it passes first through a cabinet, then through a pillar, and finally
branches off from a junction pit. The cable distance might be up to a hundred
metres longer than the actual distance.
There is a way, however, to combat this innaccuracy. If you have a reverse
directory, you can afford to be picky and select houses that are *closer* to
the exchange (ie directly in the ESA suburb), leaving less room for error.
At first, I tested the Pulse Echo Tester triangulation method in an ESA in
which I knew all the CCU locations, and I was able to locate the exchange to
within a metre, but this is a LOT more effort, and I only have CCU location
listings for metro SA suburbs.
MAKING AN EXCHANGE LOCATION AND ZONE MAP
Its always been a sad and twisted fantasy of mine, to walk back into the
Telstra shops and give them a map of so-called 'classified' exchange locations
and zones.
Anyway, if you want to be /<-r4d 31337, and have an exchange map of your own,
you'll need to go to the Telstra site (www.telstra.com.au), and download an
ADSL map of your general area (eg. SA rural, Sydney metro, etc). Simply use a
graphics editor which supports layering, such as Photoshop, and apply the map
over a digital state suburb map. Alternatively, you could always guesstimate as
to which zones match up with which ESAs.
Next, take your compiled list of Exchange locations and possibly ESAs, and
either pinpoint the locations on the ADSL map, or just include an attached
location table. If you're feeling really 0-d4y, add your stolen CCU and cable
location listing to have a virtual network map! I haven't personally bothered
to do this. Cool; yes. Time consuming, relatively pointless, difficult; also
'yes'.
LOCATION LISTING
"Theres no use in re-inventing the weel". To get you started, I've included my
current exchange listing, which has been contributed to by several other
people. A fair few of the locations were also taken from Morpheus Laughing
ezine, and the proper sources have been credited. ESAs have been added to the
Morpheus listing, as well as more locations.
[Notes: Distribute this freely, but don't take credit for it ;)
Submit any locations or LRDs/ESAs you have, and they will be added
List by dataclysm, WA & NSW locations from Morpheus Laughing
SA locations found using techniques listed in Phrequency #2, dataclysm
Most NSW locations by Lord Hades, Morpheus Laughing #3
Most WA locations by iMoRtAl, Morpheus Laughing #2
Multiple contributors include:
Psyincerise, LoC, Czar, Zaleth, Cheeba, gOdFraY, SubCom, RiOtEr
Single contributors include:
boris_G, crisis^, OrIgIn, Vertisch, Alian, xtc_teckno
Last updated: 12 February 2002]
*****************************
* South Australia: 34 *
* Northern Territory: 4 *
* Queensland: 8 *
* Victoria: 13 *
* Tasmania: 3 *
* New South Wales: 140 *
* Western Australia: 95 *
* ACT: 4 *
* Other: 5 *
*****************************
______________________________________________________________________________
================================SOUTH AUSTRALIA===============================
------------------------------------------------------------------------------
Exchange LRD/ESA Location
------------------------------------------------------------------------------
Adelaide ADEL Flinders and Waymouth Exchanges
American River AMRV
Andamooka ANDM
Balhannah BLNH
Bangham BHAM Bangham Tce, Bangham
Bangor BGOR
Birdwood BDWD
Blackwood BKWD
Bordertown Decourcey St, Bordertown
Borrika BRKA
Boston Island BNIS
Braemar BEMR
Brighton BRIH
Bundaleer North BNLN
Carpentaria CRIA
Carrieton CRRN
Chain Of Ponds COPS
Clarendon CRDN
Colona COLA
Coober Pedy CRPY
Coonalpyn COPN
Coorabie CRAE
Coorang CRNG
Coromandel Vly CLVY
Croydon CRYD
Crystal Brook CLBR
Cundalabie CUND
Cygnet River CGRV
Edwardstown EDWN 688-692 South Rd, Glandore
Elizabeth EZBH Cnr Elizabeth & Phillip Hwy, Elizabeth
Elliston A ELNA
Everard A EVRA
Flinders FLNF Cnr Flinders & Pulteney St, Adelaide
Flinders Island FLIS
Frome A FROA
Frome FROM
Gairdner A GARB
Gairdner C GARC
Gairdner D GARD
Garra Lands GRAL
Gawler GWLR High St, Gawler
Gepps Cross GPCS 558 Main North Rd, Blair Athol
Geranium GNNM
Glendambo GLBO
Glenelg GLLG
Glenunga GUGA 111 Sydney St, Glenunga
Golden Grove GNGE Cnr The Grove Way & Golden Grove Rd, Surrey Downs
Goss GOSS
Great Bight GTBT
Greenwith GWTH
Gumeracha GUMA
Gurrai GRRI
Hammond HAND
Hampstead HPSD
Handorf HNDF
Harriet HRET
Hawker HAER
Henley Beach HNLY
Herbert A HBTA
Herbert B HBTB
Hiview HIVW
Hope Forrest HEFT
Indian Pacific INPC
Iron Baron INBN
Iron Knob INKB
Jabuck JBUK
Kadina 4 Hay St, Kadina
Kangarilla KANG
Karoonda KRND
Karratta KRTA
Kersbrook KSBK
Kingscote KNGE
Koonalda KLDA
Kringin KRGN
Kyancutta Section 101, Head of Wannamana
Lameroo LMRO
Laura LURA
Leigh Creek LECK
Lenswood LSWD
Lobethal LOBL
Lonsdale LSDE Nth Side Flaxmill Rd, Christies Downs
Louth Island LHIS
Loxton North Balfour Ogalvy Rd, Loxton
MacGillivray MRAY
Maralinga MALA
Marla MRAA
Mclaren Vale MNVE
Melrose MLSE
Meningie East MGEE
Millicent Sixth St, Millicent
Mintabie MIIE
Modbury MDBY 134 Reservoir Rd, Modbury
Montacute MTCT Montacute Rd, Rostrevor
Morchard MCHD
Morgan MRGN
Morphett Vale MTVX
Mt Barker MTBK
Mt Gambier MTGA James St, Mt Gambier
Mt Hope MTHR
Mt Pleasant MTPT
Mt Torrens MTTS
Murtho MTHO
Nairne NRNE
Naracoorte Moore St, Naracoorte
Neptune Island NEIS
Normanville Ronald St, Normanville
North Adelaide NALE O'Connell St, North Adelaide
Norwood NRWD Cnr The Parade & Maesbury St, Kensington
Nullabor NULA
Nundroo NDRO
Nuriootpa 12 Murray St, Nuriootpa
Oak Valley OKVY
Orroroo OROO
Osborne OSBN
Paradise PRDS
Parndana PRDA
Parrakie PRKE
Peebinga PBGA
Peneshaw PNSW
Pinnaroo PNRO
Prospect PROT
Policemans Pt. PCPT
Port Adelaide PTAD
Port Augusta 5 Mackay St, Port Augusta
Port Elliot Cnr Port Elliot Rd & Sturt St, Port Elliot
Port Lincoln 22 Park Tce, Port Lincoln
Quorn QURN
Reynella RELA
Roper ROPR
Rosedale Roseworthy Rd, Rosedale
Salisbury SALA
Seaford SEFD
Semaphore SEMC
Sheringa SHGA
Smithfield SMFD
Spilsbury Isl. SYIS
St Marys STMF Cnr Daws Rd & Perry Ave, St Marys
St Peters STPE 96 Payneham Rd, St Peters
Stirling STIC
Stokes Bay SKBY
Tanunda 3 Sobels St, Tanunda
Tarcoola TCLA
Tarcowie TCOW
Terowie TROW
The Ranges TRNG
The Ranges (H) THRG
The Ranges (K) TKRG
Thistle Island THIS
Tooperang TPNG
Unley UNLY
Victor Harbour VRHR Ocean St, Victor Harbour
Victoria River VIER
Waymouth WAYM Cnr Waymouth & Bentham St, Adelaide
Wedge Island WGIS
West Adelaide WESA
West Coast DRCS WTCT
Wilkawatt WKWT
Williamstown WLTN
Willowie WLOW
Wilmington WLMG
Wilpena WIPA
Wisanger WSGR
Whyalla 55 Playford Ave, Whyalla
Woodville WDVL
Wynarka WYKA
Yalata YATA
Yankallila Main Sth Rd, Yankallila
Yumali YMLI
Yundi YNDI
Yunta YUNT
------------------------------------------------------------------------------
______________________________________________________________________________
==============================NORTHERN TERRITORY==============================
------------------------------------------------------------------------------
Exchange LRD/ESA Location
------------------------------------------------------------------------------
Alyangula AYLB
Arnhem ARNN
Berrimah Stuart Highway, Winnellie
Causarina Vanderlin Dve, Wanguri
Daly DLLY
Darwin Smith St, Darwin
Davenport DAVE
Galiwinku GWKU
Gove GOVE
Maningrida MNGA
Milimgimbi MGRP
Nhulunbuy NLNF
Petermann PETN
Plenty PLNY
Ramingining RAMI
Ranken River RANK
Rodinga RODG
Simpson SIMN
Tablelands TABS
Tanami TNMI
Tiwi TIWI
Wagait WGAT
Winnellie RAAF Gates, Winnellie
Yuendumu YUEM
------------------------------------------------------------------------------
______________________________________________________________________________
==================================QUEENSLAND==================================
------------------------------------------------------------------------------
Exchange LRD/ESA Location
------------------------------------------------------------------------------
Boundary Road, Narangba
Bay Terrace, Wynnum
Charlotte Street, Brisbane
River Road, Caboolture
Bli Bli Bli Bli Rd, Bli Bli
Chapel Hill Moggil Rd
Sandgate Rainbow St, Brisbane
Wangaratta Fosang Lane, King Valley
------------------------------------------------------------------------------
______________________________________________________________________________
===================================VICTORIA===================================
------------------------------------------------------------------------------
Exchange LRD/ESA Location
------------------------------------------------------------------------------
Belmont 173 High St, Belmont
Corio Princes Hwy, Corio
Exhibition GOC 5/300 Exhibition St, Melbourne (Echelon is here)
Glen Eira 19-21 Selwyn St, Elsternwick
Geelong 19 Lt Ryrie St, Geelong
Lara Station Lake Rd, Lara
Leopold Ballarine Hwy, Leopold
Lonsdale Lonsdale St, Melbourne
Moolap Bellarine Hwy, Moolap
Newport 88 Hall St, Newport
North Geelong 189 Melbourne Rd, North Geelong
Ocean Grove The Terrace, Ocean Grove
Queenscliff Bowen St, Pt Lonsdale
Tooradin Tooradin/Station Rd, Tooradin
------------------------------------------------------------------------------
______________________________________________________________________________
===================================TASMANIA===================================
------------------------------------------------------------------------------
Exchange LRD/ESA Location
------------------------------------------------------------------------------
Davey St, Hobart
Sandy Bay Rd
Runnymede Tasman Hwy
------------------------------------------------------------------------------
_____________________________________________________________________________
===============================NEW SOUTH WALES===============================
------------------------------------------------------------------------------
Exchange LRD/ESA Location
------------------------------------------------------------------------------
Arndell Park ARDK Lot 6 Kenoma PL
Ashfield ASHF 11 Hercules ST
Austral AUST 4th and 12 AVE
Avalon AVAL 15th Old Barrenjoey RD
Balgowlah BALG Sydney Rd and Woodlands St
Balmain BALM Montague and Dowling ST
Bankstown BANK 18 Kitchener PDE
Bankstown Airport BAKA Lot 4 Marion ST
Baulkahm Hills BAUL Russel and Windsor RD
Berambering Pk BMBG
Berkshire Pk BKPK
Berowra BERO CNR Berwora Waters
Bilpin BLPN Bells line of Road
Birralee BIRR CNR Mccallums and Chilcott
Blackheath BLKH Wentworth ST
Blacktown BLAC 69 Fluscombe DR
Blakehurst BLAK 507 Princess Highway
Blaxland's Rdg BLAX
Bondi BOND 16 Roscoe ST
Botany BOTA 38 Tenderson RD
Bringelly BRGY Lot 1 Badgery's Creek RD
Brooklyn BROO
Burwoood BURD 32 Railway PDE
Campsie CAMP 395 Canterbury RD
Canoelands CALD
Carlingford CARL 413 North Rocks RD
Carramar CARR 6 The Horsley DRV
Castle Hill CAST Old Northern RD
Castlereagh CRGH
Catai CATI
Chatswood CHAT Victoria AVE
Chipping Norton CHIP 23 Earnest RD
City East EAST 330 Liverpool ST Darlinghurst
City South CYSH
Coffs Harbour Moonee St
Colo COLO
Colo Heights CHTS 219 Putty RD
Como COMO 11 Ortona PDE
Concord CONC 35 Yarralla ST
Coogee COOG 56 Dolphin ST
Cranebrook CNBK Lot 111 Borrowdale Way
Cremorne CREM 219 Military RD
Cronulla CRON 4 Wilbar AVE
Dalley DALL
Dee Why DEEW 1/7 Cumberland ST
Drummoyne DRUM 60 Lyons RD
Dural DURA 969 Old Northern RD
Eaglevale EGVL Lot 54 Cornelian AVE
Eastwood EWOO 101-105 Chatham RD
Ebenezer EBEN Wilberforce and Wisemans
Edensor Park ERPK 8 Bonnyrigg AVE
Edgecliff EDGE 369 Edgecliff RD
Emu Plains EUPS Lot 1 Russle ST
Engadine ENGA 1091 Princess HWY
Epping EPPI 3 Oxford ST
Erskine Park ESPK Altham PL
Fiddletown FIDD Hollands RD
Five Dock FIVE 192 Great North RD
Freeman's Reach FRCH Lot 19 Creek Ridge RD
Frenchs Forest FREN 510 Warringah RD
Galston GALS 47 Schools RD
Glebe GLEB ST Johns RD
Glenbrook GLBK Glenbrook and Haynet ST
Glenorie GLEN Old Northern RD and Harrison
Granville GRAN Maud and Hutchinson ST
Grosse Vale GVLE Grossewold RD
Guildford GUIL 2 Guildford RD
Gunderman GDMN Wisemans Ferry RD
Harboard HARB 375 Oliver ST
Haymarket HMKT
Hazelbrook HZBK 16 Great Western HWY
Helensburgh Walker St
Holsworthy HOLS Labuan RD
Homebush HOME 68 Beresford RD
Hornsby HORN 290 Pacific HWY
Horsley Park HORS
Hunters Hill HUHL 3 John ST
Hurstville HURS 39 Bridge ST
Ingleburn INGL 29 Albert ST
Katoomba KTBA 144 Katoomba ST
Kelly Ville KELL Old Windsor RD and Windsor RD
Kemps Creek KEMP Elizabeth DRV
Kensington KENS 113 Todman AVE
Kent Street KNST
Kenthurst KENT Kenthurst and Volunteer RD
Kenthurst North KNTH Blue Gum RD
Killara KILL 637 Pacific HWY
Kingsgrove KING 107 Wolli ST
Kograh KOGA Belgrave ST and Post Office LN
Kurajong KURG Burralow RD
Kurajong Heights KRJH Douglas ST
Kurnell KURN 4 Bridges ST
Lakemba LAKE Croydon RD
Lane Cove LANE Lot 46 Burns Bay RD
Lawson LWSN 4 Honour AVE
Leppington LEPP Heath and Dickson ST
Leura LERA Leura Mall
Lidcombe LIDC 1 Taylor ST
Linden LNDN Great Western HWY
Lindfield LIND Beaconsfield PDE
Lithgow Roy st, Nr Post Office
Liverpool LIVE 40 Terminus ST
Llandilo LLDO Lot 31 Northern RD
Lower Portland LPTD Lot 2 River RD
Lundenham LUDM Lot 1 Northern RD
Manly MANL Lot 21 Belgrave ST
Marayla MRYA
Maroota MRTA
Maroota South MRTS Wisemans Ferry and Sackville
Maroubra MARO Loch Maree and Story ST
Maruya Page Street
Mascot MASC 904 Botany RD
Matraville MATR 1 Romani RD
Medlow Bath MDWB ST Albians and Railway PDE
Menai MENA Menai RD
Miller MILL 87 Cartwright AVE
Minto MINT Kent ST
Miranda MIRA 576 The Kingsway
Mona Vale MONA 1763 Pittwater RD
Mooney Mooney MOON Pacific HWY
Mosman MOSM 850 Military
MT Ku-Rin-Gai MTKU Lot 1 Pacific HWY
MT Wilson MTWN Queen RD
Mulgoa MGOA Allan RD
Narrabeen NARR 7 Windsor RD
Newtown NEWT 2 Mary ST
North Parramatta NPAR Gladstone and Sorrell
North Richmond NHRD Beaumont RD
North Ryde NRYD 165 Lane Cove RD
North Sydney NSYD Mount and William ST
Northbridge NBRI Eastern Valley Way
Orchard Hills ORHS Bringelly RD
Palm Beach PALM 856 Barrenjoey RD
Parramatta PARR 21A George ST
Peakhurst PEAK 41 Beaumans RD
Pendle Hill PENN 18 Pennant Hills RD
Penrith PNTH 90 Henry ST
Pitt Street PITT Pitt St, Sydney
Pitt Town PITN Off Bathurst ST
Potts Point POTT Mcleay and Greenknowne
Pymble PYMB Lot 1 Bungalow RD
Quakers Hill QUAK 3-5 Railway RD
Ramsgate RAMS 28 Alice ST
Randwick RAND 206 Allison RD
Redfern REDF 101 George ST
Regentville REVL Lot 1 Lutrell ST
Revesby REVE 2 Doyle RD
Richmond RCHD 314 Windsor RD
Riverstone RIVE 80 Riverstone RD
Rockdale ROCK 395 Princes RD
Roodty Hill ROOT 115 Rooty Hill RD
Rose Bay ROSE 64 Dover RD
Rouse Hill ROUS Lot 180 Edwards RD
Rydalmere RYDA 431 Victoria
Ryde RYDE 124 Blaxland RD
Sackville Reach SRCH Sackville RD
Sefton SEFT 93 Carlinford RD
Seven Hills SEVE 33 Brahms RD
Shavely SHAL Lot 306 Noumea ST
Silverwater SILV Parramatta RD Nth Lidcombe
South Strathfield SSTR 481 Liverpool RD
Springwood SPWD 143 MacQuarie RD
ST Albans STAL MacDonald River
ST Leonards STLE 524 Pacific HWY
ST Marys STMA Queen ST
Sutherland SUTH 40 Auburn ST
Sylvania SYLV 96 Princess HWY
Tennyson TNYN
Terrigal 101 Ena St, Terrigal
Terry Hills TERR Mona Vale and Aumona RD
Thirroul Lady Charignton Dve
Turnbull TNBL East Kurrajong RD
Undercliffe UNDE Hill ST and Livingstone RD
Vaulcluse VAUC 4 Olphert AVE
Wharoonga WAHR 33 Goonambarra RD
Warragamba WGBA Fourth ST
Warrimoo WMOO Great Western HWY
Waverly WAVE 112 Bronte RD
Wentworth Falls WFAL 8 Cascade ST
West Wetherill Pk WWPK 10 Metters PL
Wetherill Pk WETH 8 Kings RD Fairfield
Willberforce WFCE 22 Kings ST
Willoughby WILL 370 Eastern Valley RD
Windsor WSOR Lot A MacQuarie
Winmalee WNML 4 Singles Ridge RD
Wisemans Ferry WFRY
Young Cloete Street
------------------------------------------------------------------------------
______________________________________________________________________________
===============================WESTERN AUSTRALIA==============================
------------------------------------------------------------------------------
Exchange LRD/ESA Location
------------------------------------------------------------------------------
Applecross AAPX 101 Adross St (cnr Macrae)
Armadale ARMD Jull St (Next to post office)
Ascot ASOT Hardley Rd, Belmont
Ashfield Wesfarmers, Railway PDE
Attadale ATTA cnr Curtis & Holme Rd, Melville
Baldivis BALD Baldivis Rd (south of Fay Rd)
Ballajurra BLJA Illawarra Cres
Bassendean BSDN Wilson Street
Bateman BATA Hassel Cres (off Leichhardt St), Bullcreek
Beechboro cnr Amazon Drive & Sacramento Ave
Belhus Chateau Place, (Before security gate)
Bentley office Ewing St (Near Sevenoaks Street)
Bulwer BWER
Bullsbrook BBKE Bullsbrook Road
Burns Beach Marmion Ave (1km past Burns Beach Rd, on left)
Byford BYFD cnr Blytheswood & South Western Hwy
Carmel CAML Carmel Road near cnr of Ash Street
Cannington CANN cnr Wharf St & Albany Hwy
Canning Vale CNVL Amherst Rd (near Nicholson Ct)
Caversham RAAF Harrow Street
Central CTAN
Chidlow CHID Thomas St, near Rosedale Rd
Chittering Downs Meadowbrook Ramble
City Beach CYTB cnr Templetonia Cr and Kingsland Ave
Cottesloe CTOE cnr Stirling Hwy and Congdon St
Currumbine cnr Marmion Ave & Moore Drive (on rght)
Darlington DLNT cnr Montrose Ave & Darlington Rd
Doubleview DBLV Scarborough Beach Road (cnr Hutriss Rd)
Forrestdale FTDL Hale Road near Hanover St
Forrestfield FRFD
Fremantle FMTL Short St (near Market St)
Gidgegannup GGNP Reserve Road
Girrawheen GIRR Girrawheen Ave, near Hudson Ave
Girrawheen CA WGF2
Glenroyd GRYD cnr Berry & Reserve Road Gidgegannup
Glen Forrest GFOR cnr Hardey Rd & Railway Parade
Glen Forrest CA WGF2
Gnangara R42 Site, off Wetherell Rd (pine plantation)
Gosnells GOSN cnr Dorothy & Hicks St
Greenmount GRMT Innamincka Rd, (near round-about)
Hamersley HAMS cnr Beach Rd and Okley Rd, Carine
Herne Hill HERL Gt Northern Hwy, near McDonald St
Hilton HILN cnr South & Chamberlain St
Hutingdale Balfour St, (between Holmes and Bullfinch)
Jandakot JKOT cnr Forrest Rd & Elderberry, South Lake
Joondalup JDLP Winton Ave, Joondalup CBD
Kalamunda (L/Y) KALM Railway Rd, (opposite Kalamunda Hotel)
Kalbould McCleery St
Kelmscott KELM Albany Hwy (near Railway Stn)
Kewdale KEDL Miles Rd (near Stores)
Kingsley KSLY Ardrossan Loop (opposite no. 36)
Kingsley CL WKY2
Lansdale cnr Mosey St and Rogers Way
Lesmurdie LESM Rooth Rd (near Lesmurdie Rd)
Maddington MADD cnr of Attfield and Herbert
Maida Vale MDLE Kalamunda Rd (near Hawtin Rd)
Malaga (L/Y) Westchester Rd
Manning MNNG cnr Ley St & Manning Rd
Maylands MAYM cnr Guildford Rd & Penninsula Ave
Maylands Police Bank Rd
MDLD V101-102 cnr Dalgety & Swan St, Middle Swan
MDLD V103-104 cnr Marshall Rd & Dulwich St
MDLD V105-107 cnr Marshall Rd & Arthur St
Medina MDNA 4 Calista Ave (near Summerton Rd), Calista
Menora (behind Inglewood pool) Alexander Drv
Midland MDLD cnr Morrison Rd & New Bond St
Midland (L/Y) cnr Elgee St & Freguson St
Mindarie Rothesay Hts (off Anchorage Dr)
Mt Hawthorn cnr Scarborough Beach Rd and Oxford St
Mt Helena MTNA cnr Evans & Marquis St
Mt Helena CB WMH2
Mt Yokine MTYK (radio site) 1 Osborne Rd
M.T.X. WGP2
Morley MLEY (near Marlows) Russel St
Mullaloo MLOO cnr Coral St and Marmoin Ave, Craigie
Mundaring MDNG Gt Eastern Hwy (next to Police)
Mundaring CB WMU2
Mundijong MDJG Jarrahdale Rd ( near South West Hwy)
Nedlands NDLN cnr Stanley St and Elizabeth St
Neerabup NRBP cnr Wanneroo Rd & Gibbs Rd
Ocean Reef cnr Santiago Pwy and Baroola Pl
Optus Lockridge (Telecom switch room) Altone Rd, Kiara
Osborne Park 12 Carbom Crt (Unit 6)
Parkerville PVIL Owen Rd near Byfield Rd
Palmyra PMYA Canning Hwy (near Petra St)
Pearce RAAF (RAAF PABX room) Gt Northern Hwy, Bullsbar
Perth North (off lunchroom) 1 Bendsten Pl
Pickering Brook PKBK Pickering Brook Rd (opposite primary)
Pier PIER
Quinns Rock about 70 Quinns Rd (top of hill)
Riverton RIVT cnr Corinthian & Modillion Rd
Rockingham RKHM Simpson Ave (near Read St)
Roleystone ROLY Holden Rd
Rottnest ROTT Cristie Dv, Rottenst
Rolling Green Green Pl
Sawyers Valley (microwave tower site) 1.2km east of town
Scarborough SCBH 10 Stanley St
South Coogee CGEE Rockingham Rd (near Dalison Ave)
South Perth SPTH Angelo St (near Coode St)
Spearwood SPRD Mell Rd (off Rigby St)
Springs cnr McKnoe Drive & Charcole Rd
Straton Farral Rd
Subiaco SUBT cnr Park St & Rockeby Rd (behind P.O.)
The Lakes TLAK Gt Eastern Hwy
Tuart Hill TUTT cnr Wanneroo Rd &Myinbar Way
Two Rocks Lisford Ave (before Soverign Ave)
Victoria Park VICP cnr Teague St & Axon St
Vines (PABX room) The VInes Resort Hotel
Wanneroo WANO 916 Wanneroo Rd
Warnbro Holcombe Rd (near Warnbro South Rd)
Wellington WLTE 2nd floor, 639 Wellington St
Wembley WMBY cnr 31 Marlow St & Ruslip St
Wundowie WUND Boronia Ave (near fire station)
Wooroloo WOOR Linley Valley Rd
Yanchep YANP Glenrothes Cr (oppos fire station)
------------------------------------------------------------------------------
______________________________________________________________________________
=========================AUSTRALIAN CAPITAL TERRITORY=========================
------------------------------------------------------------------------------
Exchange LRD/ESA Location
------------------------------------------------------------------------------
Braddon Mort Street
Kambah Morrison Street
Monash Cowdery Place
Tuggeranong Reed Street
------------------------------------------------------------------------------
______________________________________________________________________________
================================OTHER LOCATIONS===============================
------------------------------------------------------------------------------
Location Address
------------------------------------------------------------------------------
Training School, SA Cnr Cashel St & Adelaide Tce, St Marys
Telstra NCT, SA 22 Henley Beach Rd, Mile End
C&C HQ, SA Cnr Pirie St & Exchange Place, Adelaide
Telstra Depot, SA Cnr Currie St & Clarendon St, Adelaide
IS&W Melbourne, VIC 40/242 Exhibition St, Melbourne (03 9634 6152)
------------------------------------------------------------------------------
.eof.
#+#+#+#+#+#+#+#+# AUTOMATIC LINE TESTERS IN AUSTRALIA #+#+#+#++#+#+#+#
- Dataclysm -
___________________________________________
INTRODUCTION
The Americans have DATUs, the Europeans have FRBs and LPIs... we in Australia
tremble at the awesome power of ALTs - Automatic Line Testers.
The idea is relatively simple. A technician, working in the field, dials up a
number to access Automatic Line Testing Equipment at the exchange. By acting
like a virtual-multimetre, the exchange sends audio signals to the CT
(Communication Technician) depending on the type of test accessed, or
automatically programmed to be accessed in series. The convenience and
efficiency provided by such equipment has guaranteed rapid technology advances
in this area, advances obvious to anyone comparing from afar the differences
between SNR-P and SULTAN.
Over the years Telstra has seen the rise and fall of several such systems; the
most popular being SNR-P, SLT, SALT, SULT and finally, SULTAN. In this article,
I intend to firstly cover operation procedures for the different ALTs, comparing
similarities and contrasting improvements, before providing a relatively basic
overview of the theory and principles behind accessing such equipment and
performing the line tests. Think of it like a physics lesson at school; with
both practical and theoretical aspects.
___________________________________________
SULTAN
No, I haven't chosen to document these testers in chronological order. Nor have
I chosen to expend much effort on the SULTAN system itself. Since it is the most
recent and 'adaptive' of all of Telstra's currently operating ALTs, there is
plenty of information available on the internet, both official and underground
sourced.
SULTAN, SUbscriber Line Testing Access Network &/or Subscribers Univeral Line
Tester Access Network, is accessed through FAST, (Field Access to SULTAN Testing
- 1800 050 051). Due to its appearance in AXE LSS, AXE LSS-D, AXE RSS-D, AXE-10
series and ARE-11 exchanges, it is digitally integrated and fully computerised.
Instead of simple frequency tones being played down the line, and then being
compared to a table of possible results, SULTAN provides RVA (Recorded Voice
Announcements), which define variables such as resistance and capacitance with
more accuracy. For example, while an ALT such as SULT would play a Busy tone if
insulation resistance on a line was between 0.5 to 1 MOhms, SULTAN would ring
back with the actual figure, "Insulation Resistance to Earth is equal to, 0.79
Mega Ohms".
On top of this, SULTAN also has the never before seen (in Australia, at least)
ability to test other lines than the line being called from. They don't even
have to be connected to the same exchange. Technically, however, one may argue
that this is actually the doing of FAST. While correct, it is important to
remember that FAST and SULTAN are integrated, and work as a pair. FAST in itself
is *technically* not an ALT, not even an manual line tester, merely a PBX-like
service providing access to the ALT SULTAN.
Most of the tests able to be performed by SULTAN are resistance, capacitance and
open circuit tests. However, further testing can be accessed after the main
SULTAN results have been read. Pulse Echo Testing can be employed to find virtual
line distances, as well as many other features that were not incorporated into
the previous ALTs, specifically ones which had the capability, such as SULT.
___________________________________________
SULT
SULT, SUbscriber Line Testing (127 22 199), is still enabled on most AXE LSS-D,
AXE RSS-D, AXE LSS, AXE-10 series, AXE-R, ARE-11 LEVEL, SRB STEP, ARK-521M,
ARK-521D, ARK-511D and ARK-511M exchange switching equipment types, but is now
commonly only used for a 'ringback test'. SULT can really do a lot more than
simply ring back a line to check it is working. Insulation resistance testing,
resistance testing, bell testing and foreign battery testing can all be employed
through SULT.
Originally, SULT exchange equipment was exploited to gain free phone calls
simply by ringing the tester (the number back then was '199'), waiting for the
phone to ring back, and then dialling the number at the dialtone. Telstra tried
numerous times to prevent this before going to the source of the problem.
Payphone ringers were disabled, and later incoming call bars were placed (albeit
under different circumstances). The SULT access number was changed several
times, probably for standardisation purposes however. Eventually, Telstra
disabled SULTs ability to direct out going 'test' calls directly through
exchange equipment, and soon afterwards, SULTAN was introduced and SULT became
redundant. This is discussed further in the theory section.
Upon ringing SULT from the line to be tested, the ring is registered by
exchange testing equipment after three rings. Seven seconds later, the exchange
rings the customer line, connecting it directly to SULT exchange equipment. The
SULT equipment is programmed to react to certain commands given by the user in
the form of DTMF tones. Each number pressed corresponds to a certain type of
test, eg. pressing '9' would perform a mandatory check on the SULT equipment
itself to ensure all test results can be relied on. As was standard for Telstra
ALTs prior to SULTAN, different tones generated by the SULT equipment symbolised
different test results. The tones used were a standard dial tone (communicating
a successful test), an 'N.U.' tone, usually symbolising a 'incipient fault' (ie.
a probability of a severe fault occurring in variables are left as they are),
and a Busy tone indicating a severe fault, classified as preventing the proper
function of a line in a serious way.
Below is a table of the possible tests and results:
============================================================
TEST DIGIT DIAL BUSY NU
------------------------------------------------------------
SULT Check 9 OK -Faulty-
Foreign Battery 0 OK Inc. Sev.
Bell Test (full) 3 delay of 4-5 secs
Bell Test (half) 4 before ring received
Insulation A to B to Eth 5 OK Inc. Sev.
Insulation A&B to Earth 6 OK Inc. Sev.
Insulation A to B 7 OK Inc. Sev.
Line Loop Resistance 8 OK Inc. Sev.
Decadic Dial Test 1 then 0 OK wght.flty. count
VF Test 1 then 1-9 OK -Faulty-
============================================================
___________________________________________
SALT
SALT, Subscribers Apparatus Line Testing &/or Subscribers Automatic Line Tester,
is accessed by a unique code, different for each ESA (Exchange Service Area). It
is similar in a testing sense to SULT, but incorporates values seen in SNR-P and
SLT, such as the unique access code.
SALT is not active on AXE exchanges, nor ARF or ARE. Infact, you can only really
access it from SxS, SRB STEP, 2000 STEP, ARK series and ABID & ABRAD expanded
exchange types, which basically limits it to country areas not using RAX exchange
switching equipment types. For this reason, the unique access codes are employed.
Below are a small listing on a few SA metro exchange SALT access codes, however,
all of these have been disabled since.
CRYD, Croydon, 241
FRKL, Franklin, 5106
GPSC, Gepps Cross, 26206
GUGA, Glenunga, 72
NRWD, Norwood, 335
PRPT, Prospect, 449
STPE, St Peters, 4206
As you can see, these numbers have no real format. I suspect, but am not
positively sure, that these access codes are based on prefix allocations for the
corresponding exchanges. Keep in mind that exchanges contain different equipment
types for different prefixes - a lot of SA exchanges are part-AXE RSS-D, and
part 2000 STEP (for the smaller prefixes). SALT access codes, and for that
matter, SNR-P and SLT exchange access codes, can only be called from within that
ESA, unless the call diverted through the respective exchange (ie. through use
of diversion equipment, call forwarding, an IES [Internal Extension System], or
extender service).
I have edited and rather dodgily compiled instructions for the operation of
SALT have been listed below: (sorry, no nice table like for SULT ;)
To obtain access to SALT tester:
Dial the access code number for the particular exchange.
- If the tester is free ring tone will be heard.
- If no tone is heard wait for busy tone, hang up and try again.
- If the tester ebcomes free while waiting, ring tone will be heard.
Hang up and wait for telephone bell to ring (about 4 seconds).
Lift receiver on ring back. If dial tone is heard the circuit is ready for
testing to proceed.
The SALT is released when the handset is replaced after a test.
Insulation resistance tests (a) A to B (b) A and B to earth.
This is a combination test which tests both the insulation resistance between
the pair and the insulation resistance to earth.
Dial 5 - Listen for ring tone.
Hang up - Wait for telephone bell to ring.
Lift receiver on ring back.
Listen to tone -
* 900Hz = Line OK (I.R. over 1M ohm)
* Busy tone = Line faulty (I.R. between 0.5 and 1M ohm)
* NU tone = Line faulty (I.R. below 0.5M ohm)
If the service fails this test, use code digits 6 and/or 7 to isolate
the problem.
Insulation resistance, A to earth and B to earth.
Dial 6 - Listen for ring tone.
Continue as for Insulation resistance tests. (code digit 5)
Insulation resistance, A to B
Dial 7 - Listen for ring tone.
Continue as for Insulation resistance tests. (code digit 5)
Line loop resistance test
Dial 8
Listen to tone -
* 900Hz tone = Line OK
* Busy tone = Loop resistance too high.
* NU tone = Loop resistance 200 ohms or less.
Dial test
Dial 1, listen for ring tone, then dial '0'.
Listen to tone -
* 0.5 sec 900Hz tone then ring tone = Dial OK
* NU tone = Pulse faulty
Bell test (full voltage)
Dial 3 - Listen for ring tone.
Hang up - ring back in 4 to 5 seconds.
Lift receiver to trip ring.
Bell test (half voltage)
Dial 4 - Listen for ring tone.
Continue as for full voltage test.
Test control of SALT
Dial 9 - Listen for dial tone, which indicates that the testing equipment is
functioning correctly. This test may be done at any time after access to SALT
has been connected. Hang up to release the testing equipment.
___________________________________________
THE TESTS THEMSELVES
Now seems like an illogical time as any to briefly go over the tests themselves
for the less academically-inclined.
Insulation Resistance tests [I.R.], such as A&B leg insulation resistance to
earth, is performed to determine if the line is conducting to the earth,
therefore creating sloppy line conditions.
A-B Resistance tests the resistance between the A leg and the B leg, as the name
might suggest. A low resistance value reading may indicate a short circuit some
where along the length of the line, possibly due to moisture and/or crappy or
damaged pair insulation.
Bell tests and dialing tests test basic features of the customer's telephone.
Whether decadic dialing is working correctly, whether VF dialing is activated,
and whether the bell correctly inducts the varying voltage to produce a ring
tone are all checked using the corresponding tests.
Capacitance testing checks a line's capacitance, again, a logical conclusion to
draw ;). A related test is the open circuit test, available using SNR-P, SLT and
SULTAN. Strangely enough, SALT and SULT seem to have no support for capacitance
testing, perhaps because there are other easily available means of performing
this test?
Loop resistance testing tests the open loop resistance - basically the
resistance provided by the pair itself. Line resistance varies depending on the
width of the copper cable itself, a thicker pair equals less resistance, and
therefore less signal loss. High resistance can create a 'dulling' effect,
reducing the amplitude of the voice.
ALT testing tests the actual exchange testing equipment, which is essential to
know that future testing on the line is reliable and accurate.
___________________________________________
SNR-P
Subscriber N? Remote - P?. SNR-P is an ALT enabled on ARK 511 and 521 SCAX
(Small Country Automatic Exchange - [a RAX]) exchange lines, and is extremely
similar to SLT.
FIR-P, while not substantial enough to warrant its own section (at least from
the small amount of information I have been able to gather on it...), is once
again almost identical to SNR-P, but is used on ARF and ARE-11 LEVEL exchange
lines.
Unlike SALT/SULT tests, all four tests are automatically carried out in series
by the exchange testing equipment. In this case, it is similar to FAST enacting
a SULTAN test on a line. SULTAN gathers the *best* aspects of every current ALT
and compiles them into one big test, what I like to refer to as a
"Super-elite-ALT". FST-C is similar in concept to FAST, but I'll come to that
later ;). Anyway, if a fault is found, the test is interrupted and a specific
tone relating to the faulty test is heard. These tests and tones are listed
below:
=================================================================================
1. FB CR Tone Foreign potential more negative than -60V DC,
or greater than 42V AC.
2. LIR NU Tone Low insulation resistance between either leg and earth;
or foreign potential less negative than -60V DC, or
less than 42V AC.
3. S/C PT Tone Low insulation resistance between A and B legs.
4. O/C Dial Tone Open circuit or low capacitance between A and B legs.
=================================================================================
If all tests are carried out successfully, an 'All OK' tone is heard, however,
if one test is faulty, after blasting the relevant tone down the line, the
exchange equipment applies a foreign battery to the line and an interrupted ring,
enabling the technician to speak to the customer if he is testing from a CCU or
jointing pit/point.
SNR-P is accessed by dialling an exchange-specific access code, in the same
fashion and format (or lack-of, rather), as SALT. This then activates the
equipment, and when the technician hangs up, SNR-P performs the above tests on
the line in series. This takes roughly a minute, after which the SNR-P exchange
equipment rings back the line and accesses the tone corresponding to the test
results, and if faulty, connects the FB (foreign battery).
___________________________________________
SLT
SLT, Subscriber Line Testing, is the same test as SNR-P... but it is accessed
differently and is enabled on different exchange equipment types. SLT is
installed on RAXs that SNR-P does not cater for, namely C-Type RAXs such as
APO C STEP (as opposed to APO B STEP for SNR-P testing). (btw, even if this
article is irrelevant to your purposes, you're gonna learn a hell of a lotta
acronymns simply by reading it. Impress your friends with your apparent
knowledge of the telecommunications system! hehe). APO C STEP exchanges are
small step by step (SxS) exchanges, with only a few still in operation in
country areas - therefore implying that SLT is a dying ALT.
1 FB CR Tone Foreign potential more negative than -60V
2 LIR NU Tone Low insulation resistance between either leg and earth
3 S/C PT Tone Low insulation resistance between A and B legs
4 O/C Dial Tone Open circuit or low capacitance between A and B legs.
As you can see, the tests are practically identical to those of SNR-P, and are
carried out in the same manner, with the ring back and tone confirmation,
foreign battery and interrupted ring enabling customer to chat with technician
about the current condition of their line. An 820Hz 'All OK' tone is heard if
the tests encounter no faults, the same as for SNR-P. If a fault IS encountered,
no further tests are done until the technician clears the fault and accessed
SNR-P anew.
The really interesting thing about SLT is how it is accessed; through FST-C.
Infact, its so important to ALT principles (and relevant to FAST/SULTAN access
for that matter), that I've included it in its own section.
___________________________________________
FST-C
Field Subscriber Testing (on) C-type (exchanges). I'm not sure if FAST is used
for the same reasons as FST-C, being to ensure that the line being tested is
clear of transmission bridges.
The FST-C number is equal to the customer's number + 200 for prefixes 200-399.
Since this is difficult to say, I'll just quote a section of an SLT information
sheet:
"For example: Subs No. = 235, auto test number = 435. If exchange numbers are in
the 500-599 range, subtract 100; if in the 600-699 range add 100."
Note: SALT and SNR-P access numbers, now that I think about it, may be
configured using the same formula. However, it may be slightly different, only
operating on the same principles.
___________________________________________
ALT EXCHANGE EQUIPMENT PRINCIPLES
I've decided to make this section sweet and short, due partly to my laziness,
partly to my lack of time before the release of this zine, and mostly due to the
unfortunate event that I wasn't able to get my hands on the info I wanted in
time... however, I promise you a detailed look at the entire Customer Access
Network in my next article, briefly glancing at ALTs and concentrating on
Exchange equipment interaction, PGSs, RIMs/RCMs and other
channeling/multiplexing stuff... right down to distribution systems, network
integration and CAN components (such as pit types, pillar/cabinet details/PGS
equipment).
Access codes or standard numbers allow a user to operate ALT equipment remotely,
however, the equipment can be controlled (ie. reprogrammed), by dialing up using
a modem. As is standard with most Telstra systems, special software is required
(as well as proper authentication), but older systems such as SNR-P and/or SLT I
suspect may simply interface with a VT100 terminal emulator. ALT exchange
equipment is installed at exchange racks supporting that type of test equipment,
as outlined for each ALT type I have covered above. Some ALT equipment provides
direct outdialing for test purposes, but this has been disabled in most
exchanges, and is not in use (to the best of my knowledge) with SULTAN equipment.
ALT equipment is in a PBA card format, much the same as digital switching
equipment itself (yes, I have some! hehe).
I _was_ intending to include an ASCII diagram of an ALT access network layout,
but due to time restrictions, that will have to be included in my next article.
FST-C and FAST act like PBXs (Private Branch eXchanges), for lack of a better
analogy, in that they provide a 'user friendly' interface between the raw test
menu (see: SALT, SULT) and the technician. This is obvious in the way that
SNR-P, SLT and SULTAN can all perform a series of tests consecutively, while
SALT and SULT have the ability/disadvantage of being/having to be manually
programmed to an extent. SULTAN combats this, being a Super-elite-ALT, by first
providing a full consecutive testing process, followed by the option for
further, individual and to some extend, differe, test options.
___________________________________________
OUTRO
Well, I hope reading this article was as interesting and informative as it was
for me to write and research it. Shouts go to:
Dr Embargo: I never did get the information you said you had, but from some of
the quotes you said it looked to be rather identical to the stuff I could get.
Thanks anyway for the intelligent discussion on www.ausphreak.org ;)
Marlinspike: Thanks for being patient about the delayed forwarding of this
article and the others to you for the release of Phrequency #2... hehe, sorry.
We'll all look back and laugh one day at this 'character building' exercise.
Psyincerise: As always, thanks for helping me obtaining the information. We've
come a long way...
Anyway, www.digital-infraction.org - check it out! Sure, its still in its
construction stages, but it'll be up VERY soon... (oooh, the anticipation...)
.eof.
#+#+#+#+#+#+#+#+#+#+# AUSTRALIAN PHREAKING NEWS #+#+#+#+#+#+#+#+#+#+#+#
The first two were taken from Telstra internal newsletters. The last is a
reprint of a commercial news article.
NETWORK OPERATIONS
#+#+#+#+#+#+#+#+#+
The Network Operations group aims to be the single operator of choice for
platform and products to internal customers, joint ventures and partners. While
doing so, they intend to move forward in operating the network of the future to
deliver world class standards and meet customer expectations.
WITH THE FORMATION of Network Operations, the group's Executive General
Manager, Michael Lawrey sees the existing integration and centralisation of
Telstra's operational functions as providing a solid base for the new team to
progress to the next level of platform and product management.
"We will continue to influence our business to maximise our alliances
and our competitive advantage using established and new capabilities,"
he said. "We will also be able to deliver greater value by reducing
duplication, hand-offs and overlaps in our processes."
The Network Operations group is made up of three key business groups
- Global Operations, OnAir Network Operations, and parts of the former Advanced
Customer Technology group, previously of Service Edge.
The merging of these groups will allow the maximising of existing similarities
and the realisation of new opportunities through these new partnerships.
Michael said the total platform and network management view will enable
end-to-end service management of Telstra's products.
"This new operating model will mean the group will gain involvement in new and
upcoming technologies as outdated platforms are exited from the business.
"There are opportunities for the group to maximise existing capabilities to
release resources for our people to work on new revenue." he added.
The major accountabilities
The Network Operations group is responsible for the operation and centralised
activation and assurance functions associated with all of Telstra's network
platforms.
They also provide a single point of contract for internal customers, and use a
reactive and proactive network fault management approach through a diverse
workforce located in all regions across Australia.
Additionally, the group manages the performance of the networks, traffic,
configuration and inter-carrier services, while monitoring any alarms and
faults that may become evident. This involves managing the daily operations of
Telstra's network events and outages to minimise the risk to our network and
customer relationships.
Last month saw more than 1,000 planned events. An event is a situation that
is, or potential to be customer impacting.
Network Operations also sees approximately 900,000 alarms per month for PSTN,
250,000 alarms for mobiles, 700 for DDN, 25 for Securitel and 1,000 for
Transend.
Additionally, the group manages the logical and physical security of our
systems and sites (logical for systems and physical monitoring is for people
requiring access to Telstra security buildings such as exchanges.
"In order to respond to our business and customer needs, there are six key
elements my group group will focus on - our people; differentiated customer
service; improved customer service; our partnerships; the systems we use; and
robustness and security of our network." Michael said.
The various networks
The Network Operations group is responsible for all of the Telstra platforms
that make up the following networks :
* Public Switched Telephone Network (PSTN).
* Intelligent Network (IN).
* Access network.
* Enterprise network.
* Data networks such as DDN.
* Internet Protocol (IP) networks such as ADSL and SDN.
* Complex products and overlay networks such as ISDN.
* Niche networks such as fax and 000.
* OnAir networks such as CDMA and GSM.
* Broadband cable network.
* Domestic satellite services.
PSTN network
* Telstra's PSTN network is fully digitised and connects almost all Australian
homes.
* It switches approximately 35 million calls per day, 99.94 per cent of which
are connected first time.
* The network concentrates traffic from more than 10,000 sites to almost 300
digital node switches across Australia.
* More than 12 billion local calls were made on our network last year. There
were also 250 million STD and ten million ID calls made.
Access and niche networks
* One RIM can carry up to 480 customers. There are currently over 5,500 RIMs
in the network with 888,829 connected customers.
* ADSL technology uses our existing copper PSTN network providing users a
super fast internet service. There are currently more than 50,000 Telstra
Big Pond ADSL subscribers.
* Broadband cable performs two functions - it provides Foxtel cable television
and provides internet access to Big Pond via the cable modem.
* Satellite earth stations at Bendigo in Victoria, Ningi in Queensland, and
Gnangara in Western Australia.
* Transend and Argent EFTPOS networks serving over 500,000 point of sale
terminals.
* Telstra card products maintained with approximately 2.5 million Telecards
and almost 11.9 million PhoneAway 1 and 2 cards in operation.
Wireless networks
* Telstra has approximately five million GSM and 500,000 CDMA customers.
* Our GSM network has 3,450 base stations, 4,080 transmission points, 137,500
voice channels, and 53 control nodes.
* Our CDMA network has 2,100 base stations, 78,000 voice channels and 22
control nodes.
* MessageBank has 4.66 million mail boxes.
IP networks
* Telstra's optic fibre network spans 3.1 million kilometres.
* SDH and PDH technology underpins the carriage of all information and
products for Telstra's networks by providing connectivity through the optic
fibre network.
* The management of Switched Data Network comprises 320 Nortel passport
switches servicing ATM and frame relay services, Telstra Private IP Services
(TPIPS).
* Big Pond Home has more than 800,000 customers.
* Dial IP has more than 850 corporate customers.
* MegaPop has more than 15 Wholesale/retail customers.
Complex Customer Activation
* Dedicated customer support to five managed service contracts in both voice
and data.
* In excess of 21,000 tickets of work processed per month.
* Provision of third level escalated technical support to 952,000 services in
operation across multiple platforms.
MAKING TELSTRA.COM MORE SECURE
#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+
Telstra's online services are driven by three goals : Enhance the online
customer experience, generate new revenues and drive out costs. One of the
cornerstones of a better customer experience is the ability to support
personalised services for our customers.
Introducing SiteMinder - The easier, more reliable and more secure way for our
customers to login to and move around telstra.com. Implemented by the customer
identity team in the Infrastructure Services group, SiteMinder is a
commercial-strength, off-the-shelf software package that is bringing a more
secure yet simpler approach to customer access.
SiteMinder makes several improvements to the telstra.com login process such as
support for Single Sign-On across multiple applications and domains. This is in
direct response to the many requests from our customers for a single username
and password that will give them access to all that Telstra has to offer
online.
Password lockout will now apply after three incorrect passwords. Users can
seamlessly navigate between sites within telstra.com without having to log out
and then log back in again. There is also now an automatic inactivity timeout,
overcoming the widespread problem of users forgetting to hit he log-out button.
SiteMinder will also make it quicker and easier to add new sites and services
to telstra.com, making it possible to shorten the lead-time to implement new
applications.
At the heart of a successful customer experience is the ability to have an
excellent identity infrastructure that delivers a consistently secure and
convenient service encouraging users to visit and revisit.
Working towards this aim is the team responsible for developing SiteMinder,
Stuart Elkins, IT and business analyst; Phil Virgona, commercial manager,
Alison Payne, technical specialist, Adrian Pizzica, integration specialist and
Craig Oakley, technical developer.
Significant credit is also due to Tuk Christou and Glenn Clarke for their
deployment expertise and the operational expertise of Angie Than and Stephen
Bancroft.
Thai Bui, Retail project sponsor, said that, "As part of a long term vision to
deliver an outstanding customer identity management solution, we have chosen to
invest in an industry leading product to replace our current crop of
custom-built systems. SiteMinder will form a key building block for identity
management."
The immediate benefits for customers are that telstra.com is now more reliable
and secure, and logins are occurring more quickly. telstra.com currently
handles peaks of 12,000 logins per hour.
In coming months, SiteMinder will play a key role in the integrated solution to
replace digital certificates for consumer and small business customers.
Customers will then be able to login to many Telstra online services from any
computer, personal digital assistant (PDA) or wireless application protocol
(WAP) device, with the ease of using a username and password.
MAN ARRESTED OVER TELCO HACKING
#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#
Caitlin Fitzsimmons
FEBRUARY 15, 2002
POLICE have arrested a Sydney man for allegedly hacking into the database of a
large telecommunications company.
NSW Police said they arrested the 21-year-old man this morning after executing
a warrant at his Kingsford home, in Sydney's south. The officers seized a
computer, documents and other equipment.
The arrest followed a month-long Commercial Crime Agency investigation, after
the telco complained an intruder was accessing restricted parts of its
databases.
Police said the man was taken to Maroubra Police Station and charged with
unauthorised access to a computer system and two counts of unauthorised
modification of data with intent to cause impairment.
Both offences were introduced as part of the Crimes Act in 2001.
The man has been released on bail and is due to appear before Waverley Local
Court on March 6.