_______ ÞÛÛÛÛÛÛÛÛÜ ÞÛÛßßßßßÛÛÛ ÞÛÛ ÞÛÛ ÞÛÛ____ÜÛÛÛ "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.