|Like what you see? Get it in one document for easy printing!|
Use coupon code "certiguide" to save 20%!
|Test yourself better with 300 extra Security+ questions!|
|Get It Here!|
1.4.4 Man in the Middle
(Page 1 of 2)
The Man In The Middle attack, or
MITM for short, is another attack made possible by lax security in the
IP protocol. As we already know, a normal TCP/IP conversation takes
place between 2 hosts, and involves the sending, receiving and acknowledgment
of packets. An MITM attack can be compared to inserting a black box
in between the 2 hosts participating in the conversation.
If an attacker can place himself
in a position where he is on the network between the two hosts, it is
technically possible for the attacker to control what data is sent between
the hosts. The attackers machine does not have to be physically
between the two hosts
the other two machines just have to be convinced
to route packets destined for the other host through the attackers
Going back to the Freedom and Spirit
example above, assume now that Freedom and Spirit communicate with each
other, but instead of using a trusted internal network, they exchange
information across a public network. How does the attacker ensure
that all packets sent between the two hosts pass through their machine?
One way to do it would be for the
attacker to set up a machine with two network cards, then send out fake
ARP requests to force packet routing between those two hosts to go via
(Remember that ARP is used to link
IP addresses to MAC addresses; the attacker can take advantage of the
fact that nothing prevents someone from introducing ARP packets that
contain misleading information.) Once the attacker gets the packets
routed through his machine, he then takes the incoming packets from
Freedom, decodes them and checks the contents. If he sees something
he wants, for example a bank transaction he would like to divert, he
can rewrite the data in the packet, and send it off to Spirit. By the
same token, when packets come in from Spirit destined for Freedom, he
can change the contents of those. He can also pass packets through unchanged,
if he wishes.
Man In The Middle
In a Man-in-the-Middle (MITM) attack, an attacker intercepts packets in the conversation between two network hosts, inspecting and altering them on the fly.
Figure 11: A Man In The Middle needs to be there from the beginning to be successful.
The effect is somewhat
like the spoofing example presented above, however, this is far harder
to detect. While the spoofing attack relies on sending brand new
packets to a host, the MITM attack is actually changing data sent between
hosts on the fly. Therefore, should you ever audit the data to find
out why the bank transactions seem to have gone awry, youll see
that data was sent by Freedom and received by Spirit in the correct
order, it just got changed somehow.
Man In The Middle Explored
At this point, it may seem as though all hope is lost, and that no communication on a public network is safe. After all, wouldnt every so-called hacker be doing this? Well, fortunately not. As in practice, this technique is very difficult to implement.
First of all, we have the physical routing issue. As noted above, for this attack to work, an attacker must ensure that every single packet sent between the 2 hosts he is attacking is routed via his machine. Taking the Internet as an example, this is a huge technical issue.
First of all you would need to be at least somewhat physically close to the target machines no matter how hard you try, packets sent between 2 servers in London will not be easily diverted and routed via China.
Second, an attacker has TCP Sequence numbers to contend with. In a nutshell, every TCP/IP connection negotiates a TCP Sequence between both hosts. Subsequently, every TCP packet sent between them has a TCP Sequence number included in the packet header. This number is changed for every packet by a prearranged formula, decided on during the TCP handshake stage.
This allows both hosts to ensure they are receiving all the packets in a TCP conversation, and to ensure that the packets are being assembled in the correct order. In other words, the TCP Sequence number is responsible for the quality control of the protocol. If the sequence number of a packet is wildly out of sequence or just plain wrong, the packet is discarded (with a few additional checks). If an attacker is unable to break the TCP Sequence formula, they wont be able to initiate an MITM attack. Tools such as Nmap75, mentioned earlier, have options to check the TCP Sequence formula of the IP stack on a machine and inform you how difficult it would be to break it. This particular attack strategy is called TCP Sequence Prediction, and crackers have access to tools that do it, so the stronger your TCP/IP implementation in this regard, the better.
Third, speed is a major issue. Consider the speed with which packets are sent across a network, even a slow 10megabit link. While applications can quite happily send and receive data at this speed, it poses more of a problem for humans. To perform an MITM attack and change data on the fly through manual would be practically close to impossible, without it having a very noticeable impact on the speed of the connection between the two hosts. The only practical way to do it would be to write a custom application that searched for specific strings in packets and manipulated them to preset rules. This does of course introduce an element for error one wrongly interpreted packet could cause a change that triggers IDS alarms, and gets an attacker caught.
In addition, because the MITM attack
manipulates packets already created and sent, you are removing the luck
factor from a spoofing attack. For example, if you have correctly set
up the MITM attack you can be assured, that provided you stay within
the parameters of the data, any information you change will be readily
acceptable by the destination host. However with a spoof attack, you
are effectively working blind, as there is no guarantee that the target
host will accept your data.
|If you find CertiGuide.com useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider buying an inexpensive PDF equivalent of the CertiGuide to Security+ from StudyExam4Less.com. (Use coupon code "certiguide" by December 31, 2004 to save 20%!) Thanks for your support!|
Table Of Contents - Contact Us
CertiGuide for Security+ (http://www.CertiGuide.com/secplus/) on CertiGuide.com
Version 1.0 - Version Date: November 15, 2004
Adapted with permission from a work created by Tcat Houser et al.
CertiGuide.com Version © Copyright 2004 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.