==Phrack Magazine== Volume Four, Issue Forty-Two, File 4 of 14 Prelude to a Kiss - Lessons Unlearned Are Doomed To Bring Misery Ad-Infinitum - The following is an article I wrote for a mainstream computer security periodical called ISPNews. At the time, I had been discussing the idea of a bi-monthly column with the editor at that time, Len Spitz. (Now the editor is Michael Alexander, ex-of Computerworld) The following article, although very, very tame by my standards, and admittedly lacking in enough hardcore information to help security professionals to apply a quick fix to their many problems, caused quite a stir among the folks at ISPNews. Since this article was from me, a self-proclaimed hacker, it underwent an extraordinary amount of scrutiny. Rather than be accepted or denied by the editor, my article got the dubious honor of being sent before an editorial advisory board. I checked every back issue of ISPNews and could find no mention of such an entity until the November/December 1991 issue, the issue immediately following an length interview with none other than myself. When I questioned Len Spitz about this rather odd fact, he maintained that this committee had indeed existed, but stammered his way through my question to name any other article that they had convened to judge in the past, and to explain the duties of such a group. He could not give me any answers. The group itself was obviously geared to be a type of kangaroo-court. It consisted of: William J. Cook -- The man who less than two years prior had ordered my privacy and civil rights violated by the Secret Service solely on the basis of two bulletin board posts and my association with members of the Legion of Doom and the Phrack Magazine staff. William H. Murray -- A senior consultant with Deloitte & Touche who had two weeks prior stood up before my presentation to the MIS Training Institute's 11th Annual Conference and said loudly "I can't take this any more, I'm leaving," to the astounded audience. The man who went on to state in his own column in ISPNews, "Can we lie down with dogs and get up without fleas?" and "Ask yourself if you wish to work in a profession populated by rogues. Ask yourself if you want your reputation mixed with theirs." Winn Schwartau -- A security consultant with a broad view and an open mind, undoubtedly resulting from his background in the music industry, as opposed to the bean-counting world of MIS. David J. Stang -- Director of research, NCSA. Noted virus specialist. This was the group. Here is what they said about my article: Bill Cook -- "It's very well-written and informative, but shouldn't be published for legal reasons." (What those reasons might have been were not stated, nor did Mr. Cook return my call to his office.) Bill Murray -- Was not even given the file to read, as his response was deemed to predictable. Winn Schwartau -- "Publish it. This is valuable information." David Stang -- Was not given the file because, according to Len Spitz "David is just a virus expert, and this isn't in his arena, so we gave it to Ray Kaplan." Ray Kaplan -- Did not want to comment on it because he said, "It's not my expertise, so I gave it to a friend." I believe Ray did not want to get involved with anything having to do with hackers after the reactionary attitudes of the DECUS attendees towards his defense of Kevin Mitnik that nearly left him in bankruptcy. I cannot blame him at all. (Hell, I like the guy...he's certainly more brazen with attitude these days, I mean, he went to HoHoCon for God's-sake!) Ray's Friend -- "This is of absolutely no use to the information security professional, but of great use to the hacker community." I still do not know who Ray's "friend" was. I hope his Alzeheimer's has subsided since this comment. Needless to say, the article went unpublished. Shortly thereafter I received a letter from Robert Fox, an assistant vice-president at Sprint. Somehow my little article had snaked its way over to Kansas City. It's amazing how one faxed copy of an article could have reached so many people in such a short period of time. Mr. Fox had the following to say: ------------------------------------------------------------------------ United Telecom/US Sprint 9221 Ward Parkway Kansas City, Missouri 64114 816-822-6262 Robert F. Fox January 13, 1992 Assistant Vice President Corporate Security VIA AIRBORNE EXPRESS Mr. Chris Goggans COMSEC Suite 1470 7322 Southwest Freeway Houston, TX 77074 Re: Your Article "Packet-switched Networks Security Begins With Configuration" Dear Mr. Goggans: A copy of the referenced unpublished article, which is enclosed with this letter, has come to our attention. After review, we believe the article is inaccurate and libelous. If published the contents of the article could cause damage to Sprint customers, Sprint and our reputation, and we request that you not publish or otherwise disseminate it. In addition, we believe some of the information contained in the article has been obtained through violation of the property rights of Sprint and/or our customers and we demand that you cease any efforts or attempts to violate or otherwise compromise our property whether or not for you personal financial gain. Sincerely, Robert F. Fox Enclosure ------------------------------------------------------------------------ Regardless of how Mr. Fox came into possession of this article, i have to question his letter based on his comments. First he states that the information is almost criminally incorrect and could cause harm to Sprint's reputation. Then he states that information in the article has come to be known through the violation of the security of Sprintnet and/or clients of Sprintnet. In effect, I am both a thief and a liar according to Mr. Fox. Well, if I were a thief the information could not possibly be inaccurate if it were obtained from Sprintnet or its clients. If I was a liar, why would they think the information came from themselves and/or their clients? Mr. Fox's thinly veiled threat caused me great amusement. I then decided no mainstream publication would touch this article. I don't know why everyone is so scared of the truth. Perhaps if the truth were known people would have to work, and perhaps if the truth were known some people would be out of work. None of this is of concern to me anymore. I am here to speak the truth and to provide uncensored information gathered from a variety of sources to provide readers of this magazine the facts they need to quench their thirst for knowledge. This article is included as a prelude to a series of articles all based on packet switched networks as related to information merely alluded to in my harmless little article. To our readers, "enjoy." To the cowering so-called security experts, "kiss my ass." ------------------------------------------------------------------------ Packet-switched Networks Security Begins with Configuration For many companies the use of packet-switched networks has allowed for increased interconnectivity of systems and easy remote access. Connection to a major public packet-switched network brings increased access points with local dialups in many cities around the nation as well as access points from foreign countries. With the many obvious benefits provided by this service, improper configuration of either the host's connection to the network or of the network itself can lead to extreme security problems. The very connection to a public packet-switched network immediately increases the exposure of that particular system. America's two major commercial networks, BT-Tymnet and Sprintnet, are probably the most popular US targets for hackers around the world. The wealth of systems available on these two networks has provided hackers with a seemly endless supply of sites on which to sharpen their skills. The ease of use inherent in both networks makes them popular for legitimate users as well as illegitimate users. The Telenet software utilized in the Sprintnet network allows users to enter a network user address (NUA) in the standard format as outlined in the X.121 numbering standard: DDDDAAAHHHHHPP Where D = the four digit data network identifier code (DNIC) A = the three digit area code corresponding to the host H = the host address P = the port or (sub) address On domestic calls the DNIC for Sprintnet (3110) is stored in all Sprintnet equipment and is used as the default. By merely picking an area code, most often corresponding to the standard area codes of the North American Numbering Plan, and an additional one to five digits a would-be intruder can connect to any number of systems while looking for targets. In the past many software packages have been written to automate this process, and large scans of the network have been published in a variety of underground media. The Tymnet II software utilized in BT's Tymnet prompts the user for a mnemonic which corresponds to a host or number of hosts. The mnemonic, or username, is referenced to a fixed host address in the network's Master User Directory (MUD). This username may allow the caller to connect to a variety of sites, as opposed to merely one, by entering additional information in separate fields after the username. It may also correspond to a network gateway thereby allowing the user to enter a number in the X.121 format and connect to that specific site. This particular network, with its primary use of words as opposed to numbers, has been compromised by intruders who guess common words or names in their attempts to connect to remote sites. Each network has its own particular set of problems but solutions to these problems are both simple and quick in implementation. SPRINTNET The first deterrence in securing a host on this network is to restrict access to the site. This can be accomplished in a number of ways. The most obvious is to have the site refuse collect calls. All calls on Sprintnet are reverse-billed, unless the site has specifically asked that they not be billed for incoming calls. This makes the site accessible only through the use of a Network User Identifier (NUI). Another method of restricting access from intruders is to place the host in a closed user group (CUG). By electing to have the host in a CUG, the administrator can allow only certain NUIs to connect, and can also restrict the actual addresses from which access is allowed. For example: A site is placed in a CUG that will allow only calls from the company's remote branch in Dallas to access the host and only with the NUI created specifically for that branch. All attempts to access the site from an address outside the 214 area will result in an error message indicating an invalid source address. All attempts to connect with an invalid NUI will result in an error indicating an invalid ID. This information is maintained in the networks main TAMS (TP Access Management System) database, and is not subject to manipulation under normal circumstances. Many sites on the Sprintnet network have specific subaddresses connecting to a debug port. This is usually at subaddress 99. All connections to debug ports should be restricted. Allowing users access to this port will allow them the ability to load and display memory registers of the Sprintnet equipment connected to the port, and even reset as well as enable or disable the host. Most debug ports are equipped with preset passwords from the vendor, but should be changed. These ports should also restrict connection from all addresses except those specified by the company. An additional measure that may foil intruders relying on software programs to find all addresses in a given area code is to request that the host be given an address above 10000. The time involved in scanning the network is extensive and most casual intruders will not look past the 10000 range. In fact, many will not venture past 2000. BT-TYMNET Any company having a host on the Tymnet network should choose a username that is not easily associated with the company or one that is not a common word or name. If an intruder is aware that XYZ Inc. has a UNIX based system on TYMNET he or she would begin attempts to find this system with the obvious usernames: XYZ, XYZINC, XYZNET, XYZ1, XYZUNIX, UNIX, etc. BT-Tymnet allows for these usernames to have additional password security as well. All hosts should have this option enabled, and passwords should be changed frequently. The password should always be a minimum of six digits, should include letters, numbers and at least one symbol character, and should not be associated in any way with the corresponding username. Many clients of BT-Tymnet have purchased the Tymnet II software and have individual sub-networks that are linked to the public network through gateways. Each subnet is personally configured and maintained through the use of a package of utilities provided by Tymnet. These utilities each perform a specific task and are highly important to the smooth operation of the network. These utilities may be accessed either directly from the host-end or remotely through the network by entering a corresponding username. Some of these utilities are: XRAY : a monitoring utility DDT : a debugging utility NETVAL : a database of username to host correspondence PROBE : a monitoring utility TMCS : a monitoring utility Under NO CIRCUMSTANCES should these utilities be left without a password on the company's subnet. These utilities should also never be named similarly to their given name. Should an intruder gain access to any of these utilities the integrity of your network will be at risk. For example: Allowing an outsider access to the XRAY utility, would give he or she the ability to monitor both incoming and outgoing data from the host using the "TA" command (display trace data table in ASCII). Use of certain XRAY commands are restricted by a security function that allows only certain usernames to execute commands on the basis of their existence in a "Goodguy" list, which can be displayed by any XRAY user. Should a user be of the highest privilege, (2), he or she can add or delete from the "Goodguy" list, reset connections, and display trace data on channels other than the default channel. Allowing a user access to DDT can result in complete disruption of the network. DDT allows the user the ability to write directly to the network controller "node code" and alter its configuration. Allowing a user access to NETVAL will allow the user to display all usernames active on the network and the corresponding host addresses. OTHER PROBLEMS EXAMPLE ONE On many networks users have the ability to connect to the packet assembler/disassembler (PAD) of the network dial-ups. This has led to significant problems in the past. In the mid-1980's two American hackers were exploring the German packet network DATEX-P. One connected to a host in Berlin and was immediately disconnected by the remote site. Before the hacker could react, the German host connected to the NUA corresponding to his Sprintnet PAD and sent him a login prompt. This alarmed the hacker greatly, as he assumed that the proprietors of the German host had somehow noticed his attempt to access their system. He contacted his partner and told him of the occurrence. The two concluded that since the NUA of the origination point is sent in the packet-header, the remote site must have been programed to recognize the NUA and then return the call. The fact that it had returned a call to a public PAD was intriguing to the pair, so they decided to attempt to recreate the event by calling each other. Both individuals connected to the network and one entered the NUA corresponding to the others PAD. A connection resulted and the two were able to interact with one another. They then decided that they would periodically meet in this fashion and discuss their findings from Germany. At the time of the next meeting, the connection did not occur as planned. One hacker quickly received a telephone call from the second who exclaimed rather excitedly that he had attempted to connect to his partner as planned, but accidentally connected to another PAD and intercepted a legitimate user typing his NUI. Further investigation proved that one could connect to public PADs during the idle period when the user was in network mode, prior to making a connection to a remote site. This discovery was intended to remain secret, because of its extremely dangerous applications. Nevertheless, word of this discovery soon reached the entire hacker community and what came to be known as "PAD to PAD" was born. The "PAD to PAD" technique became so wide-spread that hackers were soon writing software to intercept data and emulate hosts and capture login names and passwords from unsuspecting network users. Hackers were intercepting thousands of calls every day from users connecting to systems ranging from banking and credit to the Fortune 500 to government sites. After nearly two years of "PAD to PAD" Sprintnet became alerted to the crisis and disallowed all connections to public PADs. When Sprintnet expanded its service overseas they once again left access to the overseas PADs unrestricted. The problem went unnoticed again until their attention was brought to it by a hacker who called Sprintnet security and told them that they ought to fix it quickly before it became as wide-spread as before. The problem was resolved much quicker this time. This particular technique was not limited to Sprintnet. All networks using the Telenet software are at risk to this type of manipulation. This type of network manipulation was integral in the recent compromise of a large Bell Company's packet network in a much-publicized case. Certain foreign networks in countries such as Israel, England, Chile, Panama, Peru and Brazil are also at risk. EXAMPLE TWO In the late 1980's hackers stumbled onto a packet network owned and maintained by a large facilities maintenance company. This particular network had a huge flaw in its setup. It connected all calls placed through it as if they were placed with an NUI. This allowed hackers to place calls to addresses that refused collect connections on networks around the world. This became a popular method for hackers to access underground chat systems in Europe. Additionally, this network contained a score of computers belonging to a major automobile manufacturer. Most of these systems were highly insecure. The network also allowed unrestricted access to network debug ports. This particular network also had a toll-free number on an MCI exchange. At the time, MCI was having some difficulty getting their equipment to accept the ANI information to provide customers with a full call- detail report on their monthly statement. The hackers were well aware of this fact and made frequent use of the network with no fear of prosecution. Eventually MCI was able to fix their translation problem and were able to provide their clients with full call-detail reports. When this was learned, many hackers abandoned use of the network, but several others were later prosecuted for its usage when their number turned up on the bill. EXAMPLE THREE Until quite recently intimate knowledge of the utilities driving various packet-switched networks were known by an exclusive few. While investigating a network owned by an extremely large Cleveland-based conglomerate hackers came across a system where documentation on the usage of every utility was kept online. The hackers quickly downloaded all the information and it soon became somewhat wide-spread among the underground community. With less-skilled and more unscrupulous individuals in possession of this information many networks began experiencing disruptions and system integrity was quickly lost as hackers began monitoring data traffic. No information on the usage of packet networks or their utilities should ever be kept online. Hard copies should be kept in the possession of the network administrator, and when updated, obsolete versions must be destroyed. WHAT TO DO When a security violation stemming from a connection through the packet network is noticed, Network Security should be notified. Clients of BT-Tymnet should notify Steve Matthews at 408-922-7384. Clients of Sprintnet should notify Pat Sisson at 703-689-6913. Once changes have been enacted in the network to prevent further break-ins, the host computer should be checked thoroughly for any changes or damages, and all individual account passwords should be changed. CONCLUSION It is critical that the packet network be configured properly and that all measures are taken to ensure its security. Even the most secure host computer can be easily compromised if it is connected to an insecure packet network. ----------------------------------------------------------------------