[转载]Phishing On The Lower Level
文章作者：[email]overkill31@hotmail.com[/email]Notes: eth0 == Ethernet Card
eth0:1 == Ethernet card with extra IP address (for Phishing etc)
eth1 == Wireless Card
/24 == Subnet Mask of 255.255.255.0
My eth0 network: 192.168.13.0/24
Router: 192.168.13.1/24 00:09:5b:6c:6f:30
My Comp: 192.168.13.12 00:02:2D:6B:D2:76
Usual Target: 192.168.13.14 00:00:39:DB:26:B3
## NOTE ## ARP Cache TimeOut
is extremely short, e.g. Windows I think is 90
seconds by default. In 90 secs time, it asks for another ARP Request.
## DEFINITION ## RARP and ARP have two different uses. Reverse Address
Resolution Protocol, is used back in the day of Elvis and disk less 'dummy' computers
to get an IP, basically. RARP contained the data from the DataLink
Layer, packed it,
and sent it to the server hoping for a reply containing an IP Address. Address
Resolution Protocol is used to resolve IP Addresses into MAC Addresses. Media
Access Control (MAC) Addresses are “hardwired” into your NIC Card, used to
deliver a packet, as opposed to IP address which are used to route the packet. Network
Interface Card is used on the Physical Layer, can be Ethernet, Wireless, Fiber etc.
Introduction:
This paper, tutorial, report etc is not exactly supposed to be the most comprehensive
tutorial. If your having problems with this, its simple, understand the ARPing concept
and use Ethereal, oh and trialanderror.
Doing this, should not matter where your
testing from, no permanent damage can occur, as long as you can reboot the router
and can reboot all computers being affected, thats your failsafe.
Other than that, the
computers and routers themselves will resume normal operation on the next ARP.
I gathered all this information over a 72 hour period. I'm not the smartest person in
the world, but hopefully with these examples and explanations, you will be able to
understand the creation of ARP REQUESTS, ARP REPLIES, the use of Ethereal and
Nemesis.
A possible recommendation is the knowledge of the OSI layer, Packet Sniffing, *nix
Networking. However, if you have found this report, we can assume you know what
your doing.
Tools:
Ethereal: If this is not currently in your toolkit, or Tcpdump even, perhaps this tutorial
is not for you... Latest version is what I was working with, 0.10.9. An understanding
of packet sniffing and the options available in Ethereal will make it easier, but I
should be able to cover the defaults to setup. Also, I installed ethereal on both
computers, a lot of debugging was done. On both machines, Ethereal was run about
60 times until acceptable results were achieved.
Ethereal Options: Turn On: 'Update Packets in Real Time'
'Automatic Scrolling in Live Capture'
Ethereal Options: Turn Off: 'Enable MAC Name Translation'
'Enable Transport Name Translation'
Nemesis: 'aptget
install nemesis', or get it however you can. 1.4beta3 (Build 22) is
the version used in this report. I do not know about the usefulness on windows, an
email back about windows use would be great for the wider community.
OS:
Linux. All tests conducted on either Debian Unstable System 2.6.10, the attacking
computer, or Windows XP Pro SP2. A couple quick notes, Windows was fooling for
the ARP injecting attempts with minimal arguments, however, Linux was reporting
('ARP') incomplete address (in the destination MAC address) even though Windows
was allowing it.
ARPing Concept:
An already understanding of ARPing and packet routing would be great, but as
mentioned before its not needed, also mentions to 'Layers' usually means the OSI 7
Layer Model, however, the Windows TCP Stack often looks similar. The same
concepts should apply.
IP: Used to ROUTE the packet, not deliver it to the network card.
MAC: Used to DELIVER the packet, cannot be used for routing.
DNS: Used to FIND the IP, so it knows where to ROUTE packets to.
When you ping a host name, like google.com, it must first get the IP address to know
how to route packets. So the client has a conversation with the DNS servers port
53/UDP packets to eventually get google.com's IP address. Once it has the IP address
it is almost ready to send the ICMP Echo Request But once the packet gets there, it is
delivered to the MAC address not the IP address. So the client then sends a MAC
Broadcast to google.com's IP, which is an ARP Request, followed by and ARP Reply
from the relative owner. The ICMP Echo Request packet now has its destination IP
and destination MAC address, the packet is then sent onto the Internet.
## EXAMPLE ##
Example 1.
192.168.13.40 PINGS 192.168.13.50
So 192.168.13.40 sends out an ARP REQUEST to MAC address ff:ff:ff:ff:ff:ff and IP
address 192.168.13.50, saying 'Hi Guys, I'm 192.168.13.40 and I want to know what
the MAC address of 192.168.13.50 is. If your 192.168.13.50 send me your MAC
address'. 192.168.13.50 then send backs 'Hey, I'm 192.168.13.50 and this is my MAC
address 00:00:3b:22:22:22'. RFC 826 outlines the rules for this.
## NOTE ## A MAC Addy of ff:ff:ff:ff:ff:ff is broadcast. All devices on the switch
will get the packet because the Data Link Layer is lower than the Network Layer.
Presto, done. 192.168.13.40 adds it to its ARP cache, and can then send the ICMP
Echo Request packet with all the required fields.
All this happens on the DataLink
Layer (for MAC Addy delivery) and Network
Layer (for Routing). This is all covered in depth in other courses....
Usefulness:
## NOTE ## This is a dirty method (broadcasting ARP packets), dirty, very very
dirty.
During the previous example, 192.168.13.40 had to send a ARP Request packet, then
received an ARP Reply. Lets say, for example, we were broadcasting ARP Reply's.
Lets say we could 'somehow' generate the ARP Reply's. If our packet got there before
192.168.13.50's ARP Reply, 192.168.13.40 would use our ARP Reply instead, and
cache it.
Apply this, if we told 192.168.13.40 that the MAC address of 192.168.13.50 is
actually 00:00:3b:44:44:44, when 192.168.13.40 sends the packet, the
routers/switches use 192.168.13.50 IP to route the packet there, but then the router
says 'Hey, which one of you guys (plugged into the network card) has the MAC
address of 00:00:3b:44:44:44' 192.168.13.1 (router) checks its list, and either A)
Delivers it to the right Port IF the MAC address exists and the router know it, or B)
(The Router may send a packet similar to NACK) the packet get disregarded and no
connection is made with 192.168.13.50.
Now, option B is a great option if you want to take down the network. Via
continuously send ARP Reply packets; 'The MAC Addy of 192.168.13.1 is
00:00:3b:55:55:55' and lets assume 00:00:3b:55:55:55 does not exist on the network,
then whoever (in Windows every 90 odd seconds) sends an ARP Request for the
MAC Address of 192.168.13.1 your ARP Reply packets 99% of the time arrive before
192.168.13.1's. And because the router 192.168.13.1 is the default gateway, any
packets going out, will get dropped by the switch not knowing where the MAC
address lives.
Lets take the option A concept, and apply a little Phishing Attack. Once again, if we
we're broadcasting ARP Reply's for 192.168.13.1 (router) saying its MAC address is
00:00:3b:55:55:55, BUT this time, lets say the device 192.168.13.50 has that MAC
address... AND its running a default Apache Web Server. If the network
Administrator needed to login to the router and typed in the IP 192.168.13.1 his
computer 192.168.13.40, 192.168.13.40 picks up the ARP Replies, lets assume (quite
confidently) that 192.168.13.40 now thinks the MAC Address of 192.168.13.1 is
00:00:3b:55:55:55, (when really its something different and 192.168.13.50 has the
MAC address 00:00:3b:55:55:55), 192.168.13.40 is going to get all its information
from MAC address 00:00:3b:55:55:55, with the IP 192.168.13.1. So now all the
packets from 192.168.13.40 are going to 192.168.13.50 INSTEAD of 192.168.13.1.
According to the Administrator, everything LOOKS right (FireFox's toolbar says
[url]http://192.168.13.1/start.htm[/url]). However, at the Network Layer and Application Layer,
192.168.13.50's Apache Web Server is going to look at the TCP Packets, realise it has
the correct MAC Address but not the correct IP Address, because the IP is not the IP
of the machine AND/OR apache does not listen to that interface.
So, on 192.168.13.50 we create another interface (well IP on that interface). This will
trick Apache and other services into thinking not only is this computer supposed to
accept packets to MAC address 00:00:3b:55:55:55 but also the IP 192.168.13.1.
So, we create the device eth0:1 and give it the IP 192.168.13.1/24. But thats all, we do
not want it to start saying 'HEY IM 192.168.13.1, HI GUYS' because then the
network will go, 'Well 192.168.13.1 your twin brother is also online. Wait, nope
neither of you are now... :)' So basic Static IP is needed.
So now, we need to replicate the routers config, assuming it can be configured via
HTTP, and place it into 192.168.13.50's default apache site. HTTP is not the only
protocol we could attack. IMAP or POP3 email accounts will often send you the
username and password without too many problems, other protocols like FTP, Telnet
and NetBIOS. However, you may come across problems where Public and Private
Keys are being played with. I.E. SSH/SSL etc etc.
Now. Thats the theory .... This took me about 72hrs to get working to my satisfaction.
But I still have a lot of work to do...
The PoC:
Nemesis: Have it installed and waiting. Pretty easy to do in Debian.
nemesis arp S
192.168.13.50 r
D
192.168.13.12
Source MAC: 00:00:3b:22:22:22 <ARP
Injecting Machine
Destination MAC: ff:ff:ff:ff:ff:ff <BROADCAST
MAC Addy
Saying: 192.168.13.50 MAC Addy is 00:00:3b:22:22:22
nemesis arp S
192.168.13.50 r
D
192.168.13.12 h
00:00:3b:55:55:55
Source MAC: 00:00:3b:22:22:22
Destination MAC: ff:ff:ff:ff:ff:ff
Saying: 192.168.13.50 MAC Addy is 00:00:3b:55:55:55
## NOTE ## The last command is probably the command your looking for... But
others will still work.
Use Ethereal to watch the creation of packets... This is not an Ethereal tutorial, so you
gotta use your head when capturing packets...
Once thats done, its time to automate the broadcast's. I'm using BASH scripting,
because I do not know C or any other decent language (I only know VB :(). So this
will run the nemesis command once.
#!/bin/bash
nemesis arp S
192.168.13.50 r
D
192.168.13.12 h
00:00:3b:55:55:55
Save as, say 'arpinj' and type './arpinj'
Also, you may need to 'chmod XXX arpinj' to 755 or 777 to make sure permission
error wont happen. Nemesis will only run as root, so Everyone else needs Read +
Execute permission.
Running ./arpinj will run that command once, however, adding it to a loop I found
from a Google search (yes I ripped it, but it works.) as follows;
#!/bin/bash
LIMIT=29 # Upper limit
a=0
while [ $a le
"$LIMIT" ]
do
a=$(($a+1))
nemesis arp S
192.168.13.40 D
192.168.13.12 r
h
00:00:39:db:26:b3 m
00:00:39:db:26:b3
done
EOFThis
will send the packet 30 times... And on my system, that means it runs for 1
second, sending 30 ARP Replies.
If you need to create the interface eth0:1, a simple command of:
ifconfig eth0:1 192.168.13.1
This will allow Apache Web Server to Listen to that IP Address. By Default, this is all
you need in apache2 and perhaps apache.
Protection:
IDS. Intrusion Detection System's will notify or at least log the 10fold
increase in
ARP Reply's. To my disappointment, I was unable to include any form of Snort Logs,
if this report is updated, it shall be included.
Conclusion:
As you can see, this attack is quite simple, and has been used before, and will again.
This is just another example which shows that even a 'Secured' network whether it be
Ethernet, Wireless etc can still be compromised.
These examples can be used for malicious use, however, if you do manage to 'bring
down' or 'destroy' an active network. Understand this. If you can do it to others. They
can do the same to you.
More research into Intrusion Detection System's will be needed. However, I'm sure
the ARP Injecting Technique will have a relative signature that will detect the
attempts.
页:
[1]