Welcome Visitor #
Showing posts with label CEH - Hacking. Show all posts
Showing posts with label CEH - Hacking. Show all posts
Sunday, June 20, 2010
Understanding Man-In-The-Middle Attacks - Part 4: SSL Hijacking
12:04 AM | 
Posted by
Ramy
Taking a look at SSL spoofing, discussing some theory behind SSL connections and what makes them in/secure.
Introduction
So far we have discussed ARP cache poisoning, DNS spoofing, and session hijacking on our tour of common man-in-the-middle attacks. In this article we are going to examine SSL spoofing, which is inherently one of the most potent MITM attacks because it allows for exploitation of services that people assume to be secure. I will begin by discussing some theory behind SSL connections and what makes them secure, and then follow by showing how that can be exploited. As always, the last section of the article is reserved for detection and prevention tips.
SSL and HTTPS
Secure Socket Layers (SSL), or Transport Layer Security (TLS) in its more modern implementation, are protocols designed to provide security for network communication by means of encryption. This protocol is most commonly associated with other protocols to provide a secure implementation of the service that protocol provides. Examples of this include SMTPS, IMAPS, and most commonly HTTPS. The ultimate goal is to create secure channels over insecure networks.
In this article we will focus on attacking SSL over HTTP, known as HTTPS, because it is the most common use of SSL. You may not realize it but you probably use HTTPS daily. Most popular e-mail services and online banking applications rely on HTTPS to ensure that communications between your web browser and their servers in encrypted. If it weren’t for this technology then anybody with a packet sniffer on your network could intercept usernames, passwords, and anything else that would normally be hidden.
The process used by HTTPS to ensure data is secure centers around the distribution of certificates between the server, the client, and a trusted third party. As an example let’s say that a user is trying to connect to a Gmail e-mail account. This involves a few distinct steps, which are briefly simplified in Figure 1.
Figure 1: The HTTPS Communication Process
The process outlined in Figure 1 is by no means detailed, but basically works out as follows:
1.The client browser connects to http://mail.google.com on port 80 using HTTP.
2.The server redirects the client HTTPS version of this site using an HTTP code 302 redirect.
3.The client connects to https://mail.google.com on port 443.
4.The server provides a certificate to the client containing its digital signature. This certificate is used to verify the identity of the site.
5.The client takes this certificate and verifies it against its list of trusted certificate authorities.
6.Encrypted communication ensues.
If the certificate validation process fails then that means the website has failed to verify its identity. At that point the user is typically presented with a certificate validation error and they can choose to proceed at their own risk, because they may or may not actually be communicating with the website they think they are talking to.
Defeating HTTPS
This process was considered highly secure up until several years ago when an attack was published that allowed for successful hijacking of the communication process. This process doesn’t involve defeating SSL itself, but rather, defeating the “bridge” between non-encrypted and encrypted communications.
Moxie Marlinspike, a well known security researcher hypothesized that in most cases, SSL is never encountered directly. That is, most of the time an SSL connection is initiated through HTTPS it is because someone was redirected to an HTTPS via an HTTP 302 response code or they click on a link that directs them to an HTTPS site, such as a login button. The idea is that if you attack the transition from an unsecured connection to a secure one, in this case from HTTP to HTTPS, you are attacking the bridge and can man-in-the-middle an SSL connection before it even occurs. In order to do this effectively, Moxie created the SSLstrip tool, which we will use here.
The process is fairly straightforward and is reminiscent of some of the attacks we’ve completed in previous articles. It is outlined in Figure 2.
Figure 2: Hijacking HTTPS Communication
The process outlined in Figure 2 works like this:
1.Traffic between the client and web server is intercepted.
2.When an HTTPS URL is encountered sslstrip replaces it with an HTTP link and keeps a mapping of the changes.
3.The attacking machine supplies certificates to the web server and impersonates the client.
4.Traffic is received back from the secure website and provided back to the client.
The process works quite well and as far as the server is concerned it is still receiving the SSL traffic it wants to, it doesn’t know the difference. The only visible difference in the user experience is that the traffic will not be flagged as HTTPS in the browser, so a cognizant user will be able to notice that something is amiss.
Using SSLStrip
The program that makes all of this happen is called SSLstrip and is available from here. This program only runs on Linux so you can download and install it yourself, or if you don’t want to deal with the hassle of installing it yourself you can download and run Backtrack 4 which has it preinstalled.
Once you have access to SSLstrip there are a few perquisite tasks that must be done. First of all, the Linux distribution you are using must be configured for IP forwarding. To do this, enter the command echo "1" > /proc/sys/net/ipv4/ip_forward into a shell.
Figure 3: Enabling IP Forwarding
Once this has been done, we have to force all HTTP traffic that is intercepted to be routed to the port that SSLstrip will be listening on. This is done by modifying the iptables firewall configuration. This is done by using the command iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port.
Figure 4: Configuring IPTables to properly route HTTP traffic
Of course, you will replacewith a random port of your choice. After these items have been configured we can run sslstrip and configure it to listen on the port specified with the command sslstrip -l .
Figure 5: Using sslstrip
The last step in this process is to configure ARP spoofing to intercept the traffic of the target host. We did this using Cain and Abel in Windows previously, but in this case we will use the arpspoof utility, which is built into Backtrack 4. The command to do this is arpspoof -i-t .
Figure 6: Configuring ARP Spoofing
Using this command you would substitutefor the network interface you are performing these actions on (eth0, eth1, etc), for the IP address of the target client, and for the IP address of the gateway router the target is using.
Once completed you should be actively hijacking any SSL connections being established. From here you can fire up a packet sniffer and collect passwords, personally identifiable information, credit card numbers, etc from the traffic.
Defending Against SSL Hijacking
As discussed previously, SSL hijacking in this manner is virtually undetectable from there server side of the equation because as far as the server is concerned this is just normal communication with a client. It has no idea that it is communicating to a client by proxy. Luckily, there are a few things that can be done from the client’s perspective to detect and prevent these types of attacks.
Ensure Secure Connections Use HTTPS - When you perform the attack described here it strips the secure aspect of the connection away, which is visible in the browser. This means that if you log into your online banking and notice that it is just a standard HTTP connection there is a good chance something is wrong. Whatever browser you choose to use, you should ensure you know how to distinguish secure connections from insecure ones.
Save Online Banking for Home - The chance of somebody intercepting your traffic on your home network is much less than on your work network. This isn’t because your home computer is more secure (let’s face it, its probably less secure), but the simple matter of fact is that if you only have one or two computers at home, the most you have to worry about in terms of session hijacking is if your 14 year old son starts watching hacking videos on YouTube. On a corporate network you don’t know what is going on down the hall or in the branch office 200 miles away, so the potential attack sources multiply. One of the biggest targets for session hijacking is online banking, but this principal applies to anything.
Secure your internal machines - Not to beat a dead horse, but once again, attacks like these are most commonly executed from inside the network. If your network devices are secure then there is less of a chance of those compromised hosts being used to launch a session hijacking attack.
Wrap Up
This form of MITM attack is one of the deadliest because it takes what we think is a secure connection and makes it completely insecure. If you consider how many secure sites you visit each day and then consider the potential impact if all of those connections were insecure and that data fell into the wrong hands then you will truly understand the potential impact this could have on you or your organization.
Read more...
Introduction
So far we have discussed ARP cache poisoning, DNS spoofing, and session hijacking on our tour of common man-in-the-middle attacks. In this article we are going to examine SSL spoofing, which is inherently one of the most potent MITM attacks because it allows for exploitation of services that people assume to be secure. I will begin by discussing some theory behind SSL connections and what makes them secure, and then follow by showing how that can be exploited. As always, the last section of the article is reserved for detection and prevention tips.
SSL and HTTPS
Secure Socket Layers (SSL), or Transport Layer Security (TLS) in its more modern implementation, are protocols designed to provide security for network communication by means of encryption. This protocol is most commonly associated with other protocols to provide a secure implementation of the service that protocol provides. Examples of this include SMTPS, IMAPS, and most commonly HTTPS. The ultimate goal is to create secure channels over insecure networks.
In this article we will focus on attacking SSL over HTTP, known as HTTPS, because it is the most common use of SSL. You may not realize it but you probably use HTTPS daily. Most popular e-mail services and online banking applications rely on HTTPS to ensure that communications between your web browser and their servers in encrypted. If it weren’t for this technology then anybody with a packet sniffer on your network could intercept usernames, passwords, and anything else that would normally be hidden.
The process used by HTTPS to ensure data is secure centers around the distribution of certificates between the server, the client, and a trusted third party. As an example let’s say that a user is trying to connect to a Gmail e-mail account. This involves a few distinct steps, which are briefly simplified in Figure 1.
Figure 1: The HTTPS Communication Process
The process outlined in Figure 1 is by no means detailed, but basically works out as follows:
1.The client browser connects to http://mail.google.com on port 80 using HTTP.
2.The server redirects the client HTTPS version of this site using an HTTP code 302 redirect.
3.The client connects to https://mail.google.com on port 443.
4.The server provides a certificate to the client containing its digital signature. This certificate is used to verify the identity of the site.
5.The client takes this certificate and verifies it against its list of trusted certificate authorities.
6.Encrypted communication ensues.
If the certificate validation process fails then that means the website has failed to verify its identity. At that point the user is typically presented with a certificate validation error and they can choose to proceed at their own risk, because they may or may not actually be communicating with the website they think they are talking to.
Defeating HTTPS
This process was considered highly secure up until several years ago when an attack was published that allowed for successful hijacking of the communication process. This process doesn’t involve defeating SSL itself, but rather, defeating the “bridge” between non-encrypted and encrypted communications.
Moxie Marlinspike, a well known security researcher hypothesized that in most cases, SSL is never encountered directly. That is, most of the time an SSL connection is initiated through HTTPS it is because someone was redirected to an HTTPS via an HTTP 302 response code or they click on a link that directs them to an HTTPS site, such as a login button. The idea is that if you attack the transition from an unsecured connection to a secure one, in this case from HTTP to HTTPS, you are attacking the bridge and can man-in-the-middle an SSL connection before it even occurs. In order to do this effectively, Moxie created the SSLstrip tool, which we will use here.
The process is fairly straightforward and is reminiscent of some of the attacks we’ve completed in previous articles. It is outlined in Figure 2.
Figure 2: Hijacking HTTPS Communication
The process outlined in Figure 2 works like this:
1.Traffic between the client and web server is intercepted.
2.When an HTTPS URL is encountered sslstrip replaces it with an HTTP link and keeps a mapping of the changes.
3.The attacking machine supplies certificates to the web server and impersonates the client.
4.Traffic is received back from the secure website and provided back to the client.
The process works quite well and as far as the server is concerned it is still receiving the SSL traffic it wants to, it doesn’t know the difference. The only visible difference in the user experience is that the traffic will not be flagged as HTTPS in the browser, so a cognizant user will be able to notice that something is amiss.
Using SSLStrip
The program that makes all of this happen is called SSLstrip and is available from here. This program only runs on Linux so you can download and install it yourself, or if you don’t want to deal with the hassle of installing it yourself you can download and run Backtrack 4 which has it preinstalled.
Once you have access to SSLstrip there are a few perquisite tasks that must be done. First of all, the Linux distribution you are using must be configured for IP forwarding. To do this, enter the command echo "1" > /proc/sys/net/ipv4/ip_forward into a shell.
Figure 3: Enabling IP Forwarding
Once this has been done, we have to force all HTTP traffic that is intercepted to be routed to the port that SSLstrip will be listening on. This is done by modifying the iptables firewall configuration. This is done by using the command iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port
Figure 4: Configuring IPTables to properly route HTTP traffic
Of course, you will replace
Figure 5: Using sslstrip
The last step in this process is to configure ARP spoofing to intercept the traffic of the target host. We did this using Cain and Abel in Windows previously, but in this case we will use the arpspoof utility, which is built into Backtrack 4. The command to do this is arpspoof -i
Figure 6: Configuring ARP Spoofing
Using this command you would substitute
Once completed you should be actively hijacking any SSL connections being established. From here you can fire up a packet sniffer and collect passwords, personally identifiable information, credit card numbers, etc from the traffic.
Defending Against SSL Hijacking
As discussed previously, SSL hijacking in this manner is virtually undetectable from there server side of the equation because as far as the server is concerned this is just normal communication with a client. It has no idea that it is communicating to a client by proxy. Luckily, there are a few things that can be done from the client’s perspective to detect and prevent these types of attacks.
Ensure Secure Connections Use HTTPS - When you perform the attack described here it strips the secure aspect of the connection away, which is visible in the browser. This means that if you log into your online banking and notice that it is just a standard HTTP connection there is a good chance something is wrong. Whatever browser you choose to use, you should ensure you know how to distinguish secure connections from insecure ones.
Save Online Banking for Home - The chance of somebody intercepting your traffic on your home network is much less than on your work network. This isn’t because your home computer is more secure (let’s face it, its probably less secure), but the simple matter of fact is that if you only have one or two computers at home, the most you have to worry about in terms of session hijacking is if your 14 year old son starts watching hacking videos on YouTube. On a corporate network you don’t know what is going on down the hall or in the branch office 200 miles away, so the potential attack sources multiply. One of the biggest targets for session hijacking is online banking, but this principal applies to anything.
Secure your internal machines - Not to beat a dead horse, but once again, attacks like these are most commonly executed from inside the network. If your network devices are secure then there is less of a chance of those compromised hosts being used to launch a session hijacking attack.
Wrap Up
This form of MITM attack is one of the deadliest because it takes what we think is a secure connection and makes it completely insecure. If you consider how many secure sites you visit each day and then consider the potential impact if all of those connections were insecure and that data fell into the wrong hands then you will truly understand the potential impact this could have on you or your organization.
Read more...
Labels:
CEH - Hacking
Saturday, June 19, 2010
Understanding Man-In-The-Middle Attacks - Part 3: Session Hijacking
11:46 PM |
Posted by
Ramy
Taking a look at session hijacking; the theory behind it and a demonstration of it in practice, discussing its detection and prevention tips.
Introduction
In the first two articles of this series on man-in-the-middle attacks we examined ARP cache poisoning and DNS spoofing. As we have demonstrated with those examples, MITM attacks are incredibly effective and increasingly hard to detect. In the third part of this article we will examine session hijacking, which is no different. As with the previous two articles I will describe the theory behind session hijacking, demonstrate the technique in practice, and discuss detection and prevention tips.
Session Hijacking
The term session hijacking is thrown around frequently and encompasses a variety of different attacks. In general, any attack that involves the exploitation of a session between devices is session hijacking. When we refer to a session, we are talking about a connection between devices in which there is state. That is, there is an established dialogue in which a connection has been formally set up, the connection is maintained, and a defined process must be used to terminate the connection. When we talk about sessions theoretically it’s a bit confusing, so it may help to think of a session in a more practical sense.
In this article we will be talking about session hijacking through cookie stealing, which involves HTTP sessions. If you think about some of the common websites you visit that require login credentials, those are great examples of session-oriented connections. You must be authenticated by the website with your username and password to formally set up the session, the website maintains some form of session tracking to ensure you are still logged in and are allowed to access resources (often done with a cookie), and when the session is ending the credentials are cleared and the session ends. This is a very specific example of a session and even though we do not always realize it, sessions are occurring constantly and most communications rely on some form of session or state-based activity.
Figure 1: A normal session
As we have seen in previous attacks, nothing that goes across the network is safe and session data is no different. The principle behind most forms of session hijacking is that if you can intercept certain portions of the session establishment, you can use that data to impersonate one of the parties involved in the communication so that you may access session information. In the case of our earlier example, this means that if we were to capture the cookie that is used to maintain the session state between your browser and the website you are logging into, we could present that cookie to the web server and impersonate your connection. If that sounds too good to be true from an attackers standpoint, well….it is.
Figure 2: Session Hijacking
Now that we have a little bit of theory in the books, let us delve into a practical example.
Stealing Cookies with Hamster and Ferret
In our practical scenario we will be performing a session hijacking attack by intercepting the communication of a user logging into his Gmail account. Using this intercepted communication we will impersonate that user and access the account from our attacking machine.
In order to perform this attack we will be using two tools straight out of the pet store, named Hamster and Ferret. Both tools can be downloaded from here. These are both command-line tools so the hamster folder can be extracted to an easy to get to location.
Alternatively, you can download and use Backtrack 4. BT4 is a Linux live-CD distribution designed specifically for hacking and penetration testing that comes with a myriad of preinstalled and precompiled tools, with Hamster/Ferret being two of them. You can download BT4 from here. You will then find Hamster in the /pentest/sniffers/hamster folder. The screenshot examples used in the rest of this tutorial are taken from BT4.
The first step involved in this form of session hijacking is to capture the traffic of the victim user as he browses Facebook. This traffic can actually be captured using any packet sniffing application such as TCPDump or Wireshark, but in order to capture the right packets you will need to employ a technique such as ARP cache poisoning (discussed in the first article in this series).
Figure 3: Capturing traffic of the user browsing to Gmail
Once you have captured the traffic of the victim user browsing to Gmail you will need to save the captured file into the Hamster directory. For the purposes of this example, we have named our file victim_gmail.pcap. When that file is in place, we will use Ferret to process the file. This is done by browsing to the Hamster folder and running the command, ferret –r victim_gmail.pcap. Ferret will process the file and create a hamster.txt file that may be used by Hamster for the actual hijacking of the session.
Figure 4: Processing the capture file with Ferret
With our HTTP data intercepted and prepared for use, we can use Hamster to actually execute the attack. Hamster itself actually runs as a proxy that provides an interface for browsing and using stolen session cookies. In order to start the Hamster proxy you can simply execute Hamster with no command line options.
Figure 5: Starting Hamster
Once executed, you will need to open your browser and configure its proxy settings to match those provided to you by the Hamster output. By default, this means that you would configure your proxy settings to use the local loopback address 127.0.0.1 on port 1234. You can access these settings in Internet Explorer by selecting Tools, Internet Options, Connections, LAN Settings, and placing a checkbox in the Use a proxy server for your LAN box.
Figure 6: Configuring proxy settings for use with Hamster
Now that the proxy settings have been applied you can access the Hamster console in your browser by browsing to http://hamster. Hamster will use the file created by Ferret to produce a list of IP addresses for whom session information has be intercepted and display those IP address in the right pane of the browser. Our file we’ve created only contains a single IP address of the victim, so if we click that the left pane will be populated with the sessions available for hijacking.
Figure 7: The Hamster GUI
We see that facebook.com is listed, and if you click that link you will be pleased to be presented with a new window that has you logged in to the victims Facebook account!
Figure 8: Successfully hijacked Gmail account!
Defending Against Session Hijacking
There are many different forms of session hijacking so the defenses for them can vary. Just like the other MITM attacks we’ve evaluated, session hijacking is difficult to detect and even more difficult to defend against because it’s a mostly passive attack. Unless the malicious user performs some type of obvious action when he accesses the session being hijacked, you may never know that they were there. Here are a few things you can do to better defend against session hijacking:
Save Online Banking for Home - The chance of somebody intercepting your traffic on your home network is much less than on your work network. This isn’t because your home computer is more secure (let’s face it, its probably less secure), but the simple matter of fact is that if you only have one or two computers at home, the most you have to worry about in terms of session hijacking is if your 14 year old son starts watching hacking videos on YouTube. On a corporate network you don’t know what is going on down the hall or in the branch office 200 miles away, so the potential attack sources multiply. One of the biggest targets for session hijacking is online banking, but this principal applies to anything.
Be Cognizant - Smart attackers will not leave any evidence that they have been in one of your secure accounts but even the most seasoned hackers make mistakes. Being aware when you are logged into session-based services can help you determine if somebody else is walking in your shadow. Keep an eye out for things that seem out of place, and pay attention to “Last Logon Time” fields to ensure everything matches up.
Secure your internal machines - Once again, attacks like these are most commonly executed from inside the network. If your network devices are secure then there is less of a chance of those compromised hosts being used to launch a session hijacking attack.
Wrap Up
We have now covered three very lethal MITM attack types which could all have very grave consequences if successfully carried out against a victim. Using session hijacking someone with malicious intentions could access a user’s online banking, e-mail, or even a sensitive intranet application. In the next article in this series we will look at another lethal MITM attack, SSL spoofing.
Read more...
Introduction
In the first two articles of this series on man-in-the-middle attacks we examined ARP cache poisoning and DNS spoofing. As we have demonstrated with those examples, MITM attacks are incredibly effective and increasingly hard to detect. In the third part of this article we will examine session hijacking, which is no different. As with the previous two articles I will describe the theory behind session hijacking, demonstrate the technique in practice, and discuss detection and prevention tips.
Session Hijacking
The term session hijacking is thrown around frequently and encompasses a variety of different attacks. In general, any attack that involves the exploitation of a session between devices is session hijacking. When we refer to a session, we are talking about a connection between devices in which there is state. That is, there is an established dialogue in which a connection has been formally set up, the connection is maintained, and a defined process must be used to terminate the connection. When we talk about sessions theoretically it’s a bit confusing, so it may help to think of a session in a more practical sense.
In this article we will be talking about session hijacking through cookie stealing, which involves HTTP sessions. If you think about some of the common websites you visit that require login credentials, those are great examples of session-oriented connections. You must be authenticated by the website with your username and password to formally set up the session, the website maintains some form of session tracking to ensure you are still logged in and are allowed to access resources (often done with a cookie), and when the session is ending the credentials are cleared and the session ends. This is a very specific example of a session and even though we do not always realize it, sessions are occurring constantly and most communications rely on some form of session or state-based activity.
Figure 1: A normal session
As we have seen in previous attacks, nothing that goes across the network is safe and session data is no different. The principle behind most forms of session hijacking is that if you can intercept certain portions of the session establishment, you can use that data to impersonate one of the parties involved in the communication so that you may access session information. In the case of our earlier example, this means that if we were to capture the cookie that is used to maintain the session state between your browser and the website you are logging into, we could present that cookie to the web server and impersonate your connection. If that sounds too good to be true from an attackers standpoint, well….it is.
Figure 2: Session Hijacking
Now that we have a little bit of theory in the books, let us delve into a practical example.
Stealing Cookies with Hamster and Ferret
In our practical scenario we will be performing a session hijacking attack by intercepting the communication of a user logging into his Gmail account. Using this intercepted communication we will impersonate that user and access the account from our attacking machine.
In order to perform this attack we will be using two tools straight out of the pet store, named Hamster and Ferret. Both tools can be downloaded from here. These are both command-line tools so the hamster folder can be extracted to an easy to get to location.
Alternatively, you can download and use Backtrack 4. BT4 is a Linux live-CD distribution designed specifically for hacking and penetration testing that comes with a myriad of preinstalled and precompiled tools, with Hamster/Ferret being two of them. You can download BT4 from here. You will then find Hamster in the /pentest/sniffers/hamster folder. The screenshot examples used in the rest of this tutorial are taken from BT4.
The first step involved in this form of session hijacking is to capture the traffic of the victim user as he browses Facebook. This traffic can actually be captured using any packet sniffing application such as TCPDump or Wireshark, but in order to capture the right packets you will need to employ a technique such as ARP cache poisoning (discussed in the first article in this series).
Figure 3: Capturing traffic of the user browsing to Gmail
Once you have captured the traffic of the victim user browsing to Gmail you will need to save the captured file into the Hamster directory. For the purposes of this example, we have named our file victim_gmail.pcap. When that file is in place, we will use Ferret to process the file. This is done by browsing to the Hamster folder and running the command, ferret –r victim_gmail.pcap. Ferret will process the file and create a hamster.txt file that may be used by Hamster for the actual hijacking of the session.
Figure 4: Processing the capture file with Ferret
With our HTTP data intercepted and prepared for use, we can use Hamster to actually execute the attack. Hamster itself actually runs as a proxy that provides an interface for browsing and using stolen session cookies. In order to start the Hamster proxy you can simply execute Hamster with no command line options.
Figure 5: Starting Hamster
Once executed, you will need to open your browser and configure its proxy settings to match those provided to you by the Hamster output. By default, this means that you would configure your proxy settings to use the local loopback address 127.0.0.1 on port 1234. You can access these settings in Internet Explorer by selecting Tools, Internet Options, Connections, LAN Settings, and placing a checkbox in the Use a proxy server for your LAN box.
Figure 6: Configuring proxy settings for use with Hamster
Now that the proxy settings have been applied you can access the Hamster console in your browser by browsing to http://hamster. Hamster will use the file created by Ferret to produce a list of IP addresses for whom session information has be intercepted and display those IP address in the right pane of the browser. Our file we’ve created only contains a single IP address of the victim, so if we click that the left pane will be populated with the sessions available for hijacking.
Figure 7: The Hamster GUI
We see that facebook.com is listed, and if you click that link you will be pleased to be presented with a new window that has you logged in to the victims Facebook account!
Figure 8: Successfully hijacked Gmail account!
Defending Against Session Hijacking
There are many different forms of session hijacking so the defenses for them can vary. Just like the other MITM attacks we’ve evaluated, session hijacking is difficult to detect and even more difficult to defend against because it’s a mostly passive attack. Unless the malicious user performs some type of obvious action when he accesses the session being hijacked, you may never know that they were there. Here are a few things you can do to better defend against session hijacking:
Save Online Banking for Home - The chance of somebody intercepting your traffic on your home network is much less than on your work network. This isn’t because your home computer is more secure (let’s face it, its probably less secure), but the simple matter of fact is that if you only have one or two computers at home, the most you have to worry about in terms of session hijacking is if your 14 year old son starts watching hacking videos on YouTube. On a corporate network you don’t know what is going on down the hall or in the branch office 200 miles away, so the potential attack sources multiply. One of the biggest targets for session hijacking is online banking, but this principal applies to anything.
Be Cognizant - Smart attackers will not leave any evidence that they have been in one of your secure accounts but even the most seasoned hackers make mistakes. Being aware when you are logged into session-based services can help you determine if somebody else is walking in your shadow. Keep an eye out for things that seem out of place, and pay attention to “Last Logon Time” fields to ensure everything matches up.
Secure your internal machines - Once again, attacks like these are most commonly executed from inside the network. If your network devices are secure then there is less of a chance of those compromised hosts being used to launch a session hijacking attack.
Wrap Up
We have now covered three very lethal MITM attack types which could all have very grave consequences if successfully carried out against a victim. Using session hijacking someone with malicious intentions could access a user’s online banking, e-mail, or even a sensitive intranet application. In the next article in this series we will look at another lethal MITM attack, SSL spoofing.
Read more...
Labels:
CEH - Hacking
Understanding Man-In-The-Middle Attacks – Part2: DNS Spoofing
11:40 PM |
Posted by
Ramy
Continuing our look at man-in-the-middle attacks, focusing this time on another type of MITM attack called DNS spoofing.
Introduction
In the first installment of this series we reviewed normal ARP communication and how the ARP cache of a device can be poisoned in order to redirect machines network traffic through a another machine with possible malicious intent. This seemingly advanced man-in-the-middle (MITM) attack known as ARP Cache Poisoning is done easily with the right software. In this article we will discuss a similar type of MITM attack called DNS Spoofing. If you have not read the previous article on ARP Cache Poisoning then I would recommend doing so now, as this article builds upon techniques learned in that article.
DNS Spoofing
DNS spoofing is a MITM technique used to supply false DNS information to a host so that when they attempt to browse, for example, www.bankofamerica.com at the IP address XXX.XX.XX.XX they are actually sent to a fake www.bankofamerica.com residing at IP address YYY.YY.YY.YY which an attacker has created in order to steal online banking credentials and account information from unsuspecting users. This is actually done quite easily and here we will see how it works, how it is done, and how to defend against it.
Normal DNS Communication
The Domain Naming System (DNS) protocol as defined in RFC 1034/1035 is what some consider one of the most important protocols in use by the Internet. This is because DNS is the proverbial molasses that holds the bread together. In a nutshell, whenever you type in a web address such as http://www.google.com into your browser, a DNS request is made to a DNS server in order to find out what IP address that name resolves to. This is because routers and the devices that interconnect the Internet do not understand google.com, they only understand addresses such as 74.125.95.103.
A DNS server itself works by storing a database of entries (called resource records) of IP address to DNS name mappings, communicating those resource records to clients, and communicating those resource records to other DNS servers. The architecture of DNS servers throughout enterprises and the Internet is something that can be a bit complicated. As a matter of fact, there are whole books dedicated to DNS architecture. We will not cover architectural aspects or even all of the different types of DNS traffic (you can review the various DNS related RFC’s here), but we will look at a basic DNS transaction, seen in Figure 1.
Figure 1: A DNS Query and Response
DNS functions in a query/response type format. A client wishing to resolve a DNS name to an IP address sends a query to a DNS server, and the server sends the requested information in its response. From the clients’ perspective, the only two packets that are seen are this query and response.
Figure 2: DNS Query and Response Packets
This scenario gets a slight bit more complex when you consider DNS recursion. Due to the hierarchical nature of the DNS structure of the Internet, DNS servers need the ability to communicate with each other in order to locate answers for the queries submitted by clients. After all, it might be fair to expect our internal DNS server to know the name to IP address mapping of our local intranet server, but we can’t expect it to know the IP address correlated with Google or Dell. This is where recursion comes into play. Recursion is when one DNS server queries another DNS server on behalf of a client who has made a request. Basically, this turns a DNS server into a client itself, seen in Figure 3.
Figure 3: A DNS Query and Response Using Recursion
Spoofing DNS
There is more than one way to skin a cat and there is definitely more than one method available for performing DNS spoofing. We will be using a technique called DNS ID spoofing.
Every DNS query that is sent out over the network contains a uniquely generated identification number that’s purpose is to identify queries and responses and tie them together. This means that if our attacking computer can intercept a DNS query sent out from a target device, all we have to do is create a fake packet that contains that identification number in order for that packet to be accepted by that target.
We will complete this process doing two steps with a single tool. First, we will ARP cache poison the target device to reroute its traffic through our attacking host so that we can intercept the DNS request, and then we will actually send the spoofed packet. The goal of this scenario is to get users on the target network to visit our malicious website rather than the website they are attempting to access. A depiction of this attack is seen in Figure 4.
Figure 4: The DNS Spoofing Attack Using the DNS ID Spoofing Method
There are a few different tools available that can be used to perform DNS spoofing. We will be using Ettercap, which has both Windows and Linux versions. You can download Ettercap from here. If you do a bit of research on this website you will find that Ettercap has a great deal of functionality beyond DNS spoofing and is commonly used in many types of MITM attacks.
If you are installing Ettercap on a Windows machine you will notice it has a GUI which works great, but for this example we will be using the command-line interface.
Prior to executing Ettercap, a bit of configuration is required. Ettercap at its core is a packet sniffer which utilizes various plug-in to do the various attacks it can perform. The dns_spoof plug-in is what will be doing the attack in this example, so we have to modify the configuration file associated with that plug-in. On a windows system, this file can be located at C:\Program Files (x86)\EttercapNG\share\etter.dns, and at /usr/share/ettercap/etter.dns. This file is fairly simple and contains the DNS records you wish to spoof. For our purposes, we would like any user attempting to go to yahoo.com to be directed to a host on the local network, so we will add the entry highlighted in Figure 5.
Figure 5: Adding a spoofed DNS record to etter.dns
These entries basically tell the dns_spoof plug-in that when it sees a DNS query for yahoo.com or www.yahoo.com (for an A type resource record) it should supply the IP address 172.16.16.100 in response. In a realistic scenario the device at 172.16.16.100 would be running some form of web server software that would present the user with the fake website.
Once the file is configured and saved we are free to execute the command string that will launch the attack. The command string uses the following options:
-T – Specifies the use of the text-based interface
-q – Runs commands in quiet mode so that captured packets are not output to the screen
-P dns_spoof – Specifies the use of the dns_spoof plug-in
-M arp – Initiates a MITM Arp poisoning attack to intercept packets between hosts
// // - Specifies the entire network as the targets of the attack
The final command string for our purposes would be:
Ettercap.exe –T –q –P dns_spoof –M arp // //
Running the command would begin the two phased attack, first poisoning the ARP cache of the devices on the network and then transmitting the fake DNS query responses.
Figure 6: Ettercap actively listening for DNS queries
Once initiated, anybody attempting to access www.yahoo.com is redirected to our malicious site.
Figure 7: The result of the DNS spoofing attempt from the users perspective
Defending Against DNS Spoofing
DNS spoofing is difficult to defend against due to the attacks being mostly passive by nature. Typically, you will never know your DNS is being spoofed until it has happened. What you get is a webpage that is different than what you are expecting. In very targeted attacks it is very possible that you may never know that you have been tricked into enter your credentials into a false site until you receive a call from you bank wondering why you have just purchased a new boat off the shore of Greece. That being said, there are still a few things that can be done to defend against these types of attacks:
Secure your internal machines: Attacks like these are most commonly executed from inside the network. If your network devices are secure then there is less of a chance of those compromised hosts being used to launch a spoofing attack.
Don’t rely on DNS for secure systems: On highly sensitive and secure systems that you typically won’t be browsing the Internet on its often a best practice to not use DNS. If you have software that relies on hostnames to function then those can be specified manually in the devices hosts file.
Use IDS: An intrusion detection system, when placed and deployed correctly, can typically pick up on most forms of ARP cache poisoning and DNS spoofing.
Use DNSSEC: DNSSEC is a newer alternative to DNS that uses digitally signed DNS records to ensure the validity of a query response. DNSSEC is not yet in wide deployment but has been widely accepted as “the future of DNS”. This is so much so that the United States DOD has mandated that all MIL and GOV domains begin using DNSSEC within the next year. You can read more about DNSSEC here.
Wrap Up
DNS Spoofing is a very lethal form of a MITM attack when paired with the right skill level and malicious intent. Using this technique we can utilize phishing techniques to deceptively steal credentials, install malware with a drive-by exploit, or even cause a denial of service condition. In the next article in this series we will look at “pass the hash” attacks and how they can be used to login to Windows-based computers without known credentials.
Read more...
Introduction
In the first installment of this series we reviewed normal ARP communication and how the ARP cache of a device can be poisoned in order to redirect machines network traffic through a another machine with possible malicious intent. This seemingly advanced man-in-the-middle (MITM) attack known as ARP Cache Poisoning is done easily with the right software. In this article we will discuss a similar type of MITM attack called DNS Spoofing. If you have not read the previous article on ARP Cache Poisoning then I would recommend doing so now, as this article builds upon techniques learned in that article.
DNS Spoofing
DNS spoofing is a MITM technique used to supply false DNS information to a host so that when they attempt to browse, for example, www.bankofamerica.com at the IP address XXX.XX.XX.XX they are actually sent to a fake www.bankofamerica.com residing at IP address YYY.YY.YY.YY which an attacker has created in order to steal online banking credentials and account information from unsuspecting users. This is actually done quite easily and here we will see how it works, how it is done, and how to defend against it.
Normal DNS Communication
The Domain Naming System (DNS) protocol as defined in RFC 1034/1035 is what some consider one of the most important protocols in use by the Internet. This is because DNS is the proverbial molasses that holds the bread together. In a nutshell, whenever you type in a web address such as http://www.google.com into your browser, a DNS request is made to a DNS server in order to find out what IP address that name resolves to. This is because routers and the devices that interconnect the Internet do not understand google.com, they only understand addresses such as 74.125.95.103.
A DNS server itself works by storing a database of entries (called resource records) of IP address to DNS name mappings, communicating those resource records to clients, and communicating those resource records to other DNS servers. The architecture of DNS servers throughout enterprises and the Internet is something that can be a bit complicated. As a matter of fact, there are whole books dedicated to DNS architecture. We will not cover architectural aspects or even all of the different types of DNS traffic (you can review the various DNS related RFC’s here), but we will look at a basic DNS transaction, seen in Figure 1.
Figure 1: A DNS Query and Response
DNS functions in a query/response type format. A client wishing to resolve a DNS name to an IP address sends a query to a DNS server, and the server sends the requested information in its response. From the clients’ perspective, the only two packets that are seen are this query and response.
Figure 2: DNS Query and Response Packets
This scenario gets a slight bit more complex when you consider DNS recursion. Due to the hierarchical nature of the DNS structure of the Internet, DNS servers need the ability to communicate with each other in order to locate answers for the queries submitted by clients. After all, it might be fair to expect our internal DNS server to know the name to IP address mapping of our local intranet server, but we can’t expect it to know the IP address correlated with Google or Dell. This is where recursion comes into play. Recursion is when one DNS server queries another DNS server on behalf of a client who has made a request. Basically, this turns a DNS server into a client itself, seen in Figure 3.
Figure 3: A DNS Query and Response Using Recursion
Spoofing DNS
There is more than one way to skin a cat and there is definitely more than one method available for performing DNS spoofing. We will be using a technique called DNS ID spoofing.
Every DNS query that is sent out over the network contains a uniquely generated identification number that’s purpose is to identify queries and responses and tie them together. This means that if our attacking computer can intercept a DNS query sent out from a target device, all we have to do is create a fake packet that contains that identification number in order for that packet to be accepted by that target.
We will complete this process doing two steps with a single tool. First, we will ARP cache poison the target device to reroute its traffic through our attacking host so that we can intercept the DNS request, and then we will actually send the spoofed packet. The goal of this scenario is to get users on the target network to visit our malicious website rather than the website they are attempting to access. A depiction of this attack is seen in Figure 4.
Figure 4: The DNS Spoofing Attack Using the DNS ID Spoofing Method
There are a few different tools available that can be used to perform DNS spoofing. We will be using Ettercap, which has both Windows and Linux versions. You can download Ettercap from here. If you do a bit of research on this website you will find that Ettercap has a great deal of functionality beyond DNS spoofing and is commonly used in many types of MITM attacks.
If you are installing Ettercap on a Windows machine you will notice it has a GUI which works great, but for this example we will be using the command-line interface.
Prior to executing Ettercap, a bit of configuration is required. Ettercap at its core is a packet sniffer which utilizes various plug-in to do the various attacks it can perform. The dns_spoof plug-in is what will be doing the attack in this example, so we have to modify the configuration file associated with that plug-in. On a windows system, this file can be located at C:\Program Files (x86)\EttercapNG\share\etter.dns, and at /usr/share/ettercap/etter.dns. This file is fairly simple and contains the DNS records you wish to spoof. For our purposes, we would like any user attempting to go to yahoo.com to be directed to a host on the local network, so we will add the entry highlighted in Figure 5.
Figure 5: Adding a spoofed DNS record to etter.dns
These entries basically tell the dns_spoof plug-in that when it sees a DNS query for yahoo.com or www.yahoo.com (for an A type resource record) it should supply the IP address 172.16.16.100 in response. In a realistic scenario the device at 172.16.16.100 would be running some form of web server software that would present the user with the fake website.
Once the file is configured and saved we are free to execute the command string that will launch the attack. The command string uses the following options:
-T – Specifies the use of the text-based interface
-q – Runs commands in quiet mode so that captured packets are not output to the screen
-P dns_spoof – Specifies the use of the dns_spoof plug-in
-M arp – Initiates a MITM Arp poisoning attack to intercept packets between hosts
// // - Specifies the entire network as the targets of the attack
The final command string for our purposes would be:
Ettercap.exe –T –q –P dns_spoof –M arp // //
Running the command would begin the two phased attack, first poisoning the ARP cache of the devices on the network and then transmitting the fake DNS query responses.
Figure 6: Ettercap actively listening for DNS queries
Once initiated, anybody attempting to access www.yahoo.com is redirected to our malicious site.
Figure 7: The result of the DNS spoofing attempt from the users perspective
Defending Against DNS Spoofing
DNS spoofing is difficult to defend against due to the attacks being mostly passive by nature. Typically, you will never know your DNS is being spoofed until it has happened. What you get is a webpage that is different than what you are expecting. In very targeted attacks it is very possible that you may never know that you have been tricked into enter your credentials into a false site until you receive a call from you bank wondering why you have just purchased a new boat off the shore of Greece. That being said, there are still a few things that can be done to defend against these types of attacks:
Secure your internal machines: Attacks like these are most commonly executed from inside the network. If your network devices are secure then there is less of a chance of those compromised hosts being used to launch a spoofing attack.
Don’t rely on DNS for secure systems: On highly sensitive and secure systems that you typically won’t be browsing the Internet on its often a best practice to not use DNS. If you have software that relies on hostnames to function then those can be specified manually in the devices hosts file.
Use IDS: An intrusion detection system, when placed and deployed correctly, can typically pick up on most forms of ARP cache poisoning and DNS spoofing.
Use DNSSEC: DNSSEC is a newer alternative to DNS that uses digitally signed DNS records to ensure the validity of a query response. DNSSEC is not yet in wide deployment but has been widely accepted as “the future of DNS”. This is so much so that the United States DOD has mandated that all MIL and GOV domains begin using DNSSEC within the next year. You can read more about DNSSEC here.
Wrap Up
DNS Spoofing is a very lethal form of a MITM attack when paired with the right skill level and malicious intent. Using this technique we can utilize phishing techniques to deceptively steal credentials, install malware with a drive-by exploit, or even cause a denial of service condition. In the next article in this series we will look at “pass the hash” attacks and how they can be used to login to Windows-based computers without known credentials.
Read more...
Labels:
CEH - Hacking
Understanding Man-in-the-Middle Attacks – ARP Cache Poisoning (Part 1)
11:18 PM |
Posted by
Ramy
The first part of an article series on some of the most widely used forms of MITM attacks, including ARP Cache Poisoning, DNS Spoofing, HTTP session hijacking, passing the hash and more.
Introduction
One of the most prevalent network attacks used against individuals and large organizations alike are man-in-the-middle (MITM) attacks. Considered an active eavesdropping attack, MITM works by establishing connections to victim machines and relaying messages between them. In cases like these, one victim believes it is communicating directly with another victim, when in reality the communication flows through the host performing the attack. The end result is that the attacking host can not only intercept sensitive data, but can also inject and manipulate a data stream to gain further control of its victims.
In this series of articles we will examine some of the most widely used forms of MITM attacks including ARP cache poisoning, DNS spoofing, HTTP session hijacking, passing the hash, and more. As you will mostly find in the real world, most victim machines are Windows-based hosts. That being the case, this series of articles will focus entirely on MITM exploitation of hosts running versions of Windows. When possible, attacks will also be performed from Windows based hosts. In cases when there are no tools available for the attack being presented we will be utilizing Backtrack Linux 4, downloadable as a live-CD or a virtual machine from here.
ARP Cache Poisoning
In the first article of this series we will take a look at ARP cache poisoning. One of the oldest forms of modern MITM attack, ARP cache poisoning (sometimes also known as ARP Poison Routing) allows an attacker on the same subnet as its victims to eavesdrop on all network traffic between the victims. I’ve deliberately chosen this as the first attack to examine because it is one of the simplest to execute but is considered one of the most effective once implemented by attackers.
Normal ARP Communication
The ARP protocol was designed out of necessity to facilitate the translation of addresses between the second and third layers of the OSI model. The second layer, or data-link layer, uses MAC addresses so that hardware devices can communicate to each other directly on a small scale. The third layer, or network layer, uses IP addresses (most commonly) to create large scalable networks that can communicate across the globe. The data link layer deals directly with devices connected together where as the network layer deals with devices that are directly connected AND indirectly connected. Each layer has its own addressing scheme, and they must work together in order to make network communication happen. For this very reason, ARP was created with RFC 826, “An Ethernet Address Resolution Protocol”.
Figure 1: The ARP Communication Process
The nitty gritty of ARP operation is centered around two packets, an ARP request and an ARP reply. The purpose of the request and reply are to locate the hardware MAC address associated with a given IP address so that traffic can reach its destination on a network. The request packet is sent to every device on the network segment and says “Hey, my IP address is XX.XX.XX.XX, and my MAC address is XX:XX:XX:XX:XX:XX. I need to send something to whoever has the IP address XX.XX.XX.XX, but I don’t know what their hardware address is. Will whoever has this IP address please respond back with their MAC address?” The response would come in the ARP reply packet and effectively provide this answer, “Hey transmitting device. I am who you are looking for with the IP address of XX.XX.XX.XX. My MAC address is XX:XX:XX:XX:XX:XX.” Once this is completed the transmitting device will update its ARP cache table and the devices are able to communicate with one another.
Poisoning the Cache
ARP cache poisoning takes advantage of the insecure nature of the ARP protocol. Unlike protocols such as DNS that can be configured to only accept secured dynamic updates, devices using ARP will accept updates at any time. This means that any device can send an ARP reply packet to another host and force that host to update its ARP cache with the new value. Sending an ARP reply when no request has been generated is called sending a gratuitous ARP. When malicious intent is present the result of a few well placed gratuitous ARP packets used in this manner can result in hosts who think they are communicating with one host, but in reality are communicating with a listening attacker.
Figure 2: Intercepting Communication with ARP Cache Poisoning
Using Cain & Abel
Let us take the given scenario and take it from theory to reality. There are a few different tools that will perform the necessary steps to poison the ARP cache of victim machines. We will use the popular security tool Cain & Abel from Oxid.it. Cain & Abel does quite a few things beyond ARP cache poisoning and is a very useful tool to have in your arsenal. The installation of the tool is pretty clear cut so I won’t go through that here.
Before beginning you need to collect some additional information. This includes the network interface you wish you to use for the attack, and the two IP addresses of your communicating victims.
When you first open Cain & Abel, you will notice a series of tabs near the top of the window. For our purposes, we’ll be working in the Sniffer tab. When you click this tab, you will see an empty table. In order to fill this table you will need to activate the program’s built-in sniffer and scan your network for hosts.
Figure 3: Cain and Abel’s Sniffer Tab
Click the second icon on the toolbar, which resembles a network card. The first time you do this you will be asked to select the interface you wish to sniff. This interface should be the one that is connected to the network you will be performing your ARP cache poisoning on. Once you’ve selected this interface, click OK to activate Cain & Abel’s built-in sniffer. At this point the toolbar icon resembling a network card should be depressed. If it isn’t, do so now. To build a list of available hosts on your network, click the icon that resembles a plus (+) symbol on the main toolbar, and click OK.
Figure 4: Scanning for Hosts
The once-empty grid should now be filled with a list of all the hosts on your attached network, along with their MAC addresses, IP addresses, and vendor identifying information. This is the list you will work from when setting up your ARP cache poisoning.
At the bottom of the program window, you will see a set of tabs that will take you to other windows under the Sniffer heading. Now that you have built your host list, you will be working from the APR tab. Switch to the APR window by clicking the tab.
Once in the APR window, you are presented with two empty tables: an upper and a lower one. Once you set them up, the upper table will show the devices involved in your ARP cache poisoning, and the lower table will show all communication between your poisoned machines.
Continue setting up your ARP poisoning by clicking the icon resembling the plus (+) symbol on the program’s standard toolbar. The window that appears has two selection columns side by side. On the left side, you will see a list of all available hosts on your network. Click the IP address of one of your victims. This will result in the right window showing a list of all hosts in the network, omitting the IP address you just selected. In the right window, click the IP address of the other victim, and click OK.
Figure 5: Selecting Victim Hosts for Poisoning
The IP addresses of both devices should now be listed in the upper table in the main application window. To complete the process, click the yellow-and-black radiation symbol on the standard toolbar. This will activate Cain & Abel’s ARP cache poisoning features and allow your analyzing system to be the middleman for all communications between the two victims. If you are curious to see what is happening behind the scenes try installing Wireshark and listen to the interface when you enable poisoning. You will see a flurry of ARP traffic to both hosts and immediately begin seeing the communication between them.
Figure 6: ARP Traffic Injection
When you are finished, simply click the yellow-and-black radiation symbol again to stop ARP cache poisoning.
Defending Against ARP Cache Poisoning
Looking at ARP cache poisoning from the defenders standpoint we are at a bit of a disadvantage. The ARP process happens in the background with very little ability to be controlled directly by us. There is no catch all solution, but proactive and reactive stances can be taken if you are concerned about ARP cache poisoning on your network.
Securing the LAN
ARP Cache Poisoning is only a viable attack technique when attempting to intercept traffic between two hosts on the same local area network. The only reason you would have to fear this is if a local device on your network has been compromised, a trusted user has malicious intent, or someone has managed to plug an un-trusted device into the network. Although we too often focus the entirety of our security efforts on the network perimeter, defending against internal threats and having a good internal security posture can help eliminate the fear of the attack mentioned here.
Hard Coding the ARP Cache
One way to protect against the unsecured dynamic nature of ARP requests and replies is to make the process a little less…dynamic. This is an option because Windows-based hosts allow for the addition of static entries into the ARP cache. You can view the ARP cache of a Windows host by opening a command prompt and type the command arp –a.
Figure 7: Viewing the ARP Cache
You can add entries to this list by using the command, arp –s.
In cases where your network configuration does not change often, it is entirely feasible to make a listing of static ARP entries and deploy them to clients via an automated script. This will ensure that devices will always rely on their local ARP cache rather than relying on ARP requests and replies.
Monitoring ARP Traffic with a Third Party Program
The last option for defending against ARP cache poisoning is a reactive approach that involves monitoring the network traffic of hosts. This can be done with a few different intrusion detection systems (such as Snort) or through downloadable utilities designed specifically for this purpose (such as xARP). This may be feasible when you are only concerned about a single host, but can be a bit cumbersome to deal with when concerned with entire network segments.
Wrap Up
ARP Cache Poisoning is a great introduction into the world of passive man-in-the-middle attacks because it’s very simple to execute, is a very real threat on modern networks, and is difficult to detect and defend against. In the next article in this series we will focus on name resolution and the concept of DNS spoofing.
Read more...
Introduction
One of the most prevalent network attacks used against individuals and large organizations alike are man-in-the-middle (MITM) attacks. Considered an active eavesdropping attack, MITM works by establishing connections to victim machines and relaying messages between them. In cases like these, one victim believes it is communicating directly with another victim, when in reality the communication flows through the host performing the attack. The end result is that the attacking host can not only intercept sensitive data, but can also inject and manipulate a data stream to gain further control of its victims.
In this series of articles we will examine some of the most widely used forms of MITM attacks including ARP cache poisoning, DNS spoofing, HTTP session hijacking, passing the hash, and more. As you will mostly find in the real world, most victim machines are Windows-based hosts. That being the case, this series of articles will focus entirely on MITM exploitation of hosts running versions of Windows. When possible, attacks will also be performed from Windows based hosts. In cases when there are no tools available for the attack being presented we will be utilizing Backtrack Linux 4, downloadable as a live-CD or a virtual machine from here.
ARP Cache Poisoning
In the first article of this series we will take a look at ARP cache poisoning. One of the oldest forms of modern MITM attack, ARP cache poisoning (sometimes also known as ARP Poison Routing) allows an attacker on the same subnet as its victims to eavesdrop on all network traffic between the victims. I’ve deliberately chosen this as the first attack to examine because it is one of the simplest to execute but is considered one of the most effective once implemented by attackers.
Normal ARP Communication
The ARP protocol was designed out of necessity to facilitate the translation of addresses between the second and third layers of the OSI model. The second layer, or data-link layer, uses MAC addresses so that hardware devices can communicate to each other directly on a small scale. The third layer, or network layer, uses IP addresses (most commonly) to create large scalable networks that can communicate across the globe. The data link layer deals directly with devices connected together where as the network layer deals with devices that are directly connected AND indirectly connected. Each layer has its own addressing scheme, and they must work together in order to make network communication happen. For this very reason, ARP was created with RFC 826, “An Ethernet Address Resolution Protocol”.
Figure 1: The ARP Communication Process
The nitty gritty of ARP operation is centered around two packets, an ARP request and an ARP reply. The purpose of the request and reply are to locate the hardware MAC address associated with a given IP address so that traffic can reach its destination on a network. The request packet is sent to every device on the network segment and says “Hey, my IP address is XX.XX.XX.XX, and my MAC address is XX:XX:XX:XX:XX:XX. I need to send something to whoever has the IP address XX.XX.XX.XX, but I don’t know what their hardware address is. Will whoever has this IP address please respond back with their MAC address?” The response would come in the ARP reply packet and effectively provide this answer, “Hey transmitting device. I am who you are looking for with the IP address of XX.XX.XX.XX. My MAC address is XX:XX:XX:XX:XX:XX.” Once this is completed the transmitting device will update its ARP cache table and the devices are able to communicate with one another.
Poisoning the Cache
ARP cache poisoning takes advantage of the insecure nature of the ARP protocol. Unlike protocols such as DNS that can be configured to only accept secured dynamic updates, devices using ARP will accept updates at any time. This means that any device can send an ARP reply packet to another host and force that host to update its ARP cache with the new value. Sending an ARP reply when no request has been generated is called sending a gratuitous ARP. When malicious intent is present the result of a few well placed gratuitous ARP packets used in this manner can result in hosts who think they are communicating with one host, but in reality are communicating with a listening attacker.
Figure 2: Intercepting Communication with ARP Cache Poisoning
Using Cain & Abel
Let us take the given scenario and take it from theory to reality. There are a few different tools that will perform the necessary steps to poison the ARP cache of victim machines. We will use the popular security tool Cain & Abel from Oxid.it. Cain & Abel does quite a few things beyond ARP cache poisoning and is a very useful tool to have in your arsenal. The installation of the tool is pretty clear cut so I won’t go through that here.
Before beginning you need to collect some additional information. This includes the network interface you wish you to use for the attack, and the two IP addresses of your communicating victims.
When you first open Cain & Abel, you will notice a series of tabs near the top of the window. For our purposes, we’ll be working in the Sniffer tab. When you click this tab, you will see an empty table. In order to fill this table you will need to activate the program’s built-in sniffer and scan your network for hosts.
Figure 3: Cain and Abel’s Sniffer Tab
Click the second icon on the toolbar, which resembles a network card. The first time you do this you will be asked to select the interface you wish to sniff. This interface should be the one that is connected to the network you will be performing your ARP cache poisoning on. Once you’ve selected this interface, click OK to activate Cain & Abel’s built-in sniffer. At this point the toolbar icon resembling a network card should be depressed. If it isn’t, do so now. To build a list of available hosts on your network, click the icon that resembles a plus (+) symbol on the main toolbar, and click OK.
Figure 4: Scanning for Hosts
The once-empty grid should now be filled with a list of all the hosts on your attached network, along with their MAC addresses, IP addresses, and vendor identifying information. This is the list you will work from when setting up your ARP cache poisoning.
At the bottom of the program window, you will see a set of tabs that will take you to other windows under the Sniffer heading. Now that you have built your host list, you will be working from the APR tab. Switch to the APR window by clicking the tab.
Once in the APR window, you are presented with two empty tables: an upper and a lower one. Once you set them up, the upper table will show the devices involved in your ARP cache poisoning, and the lower table will show all communication between your poisoned machines.
Continue setting up your ARP poisoning by clicking the icon resembling the plus (+) symbol on the program’s standard toolbar. The window that appears has two selection columns side by side. On the left side, you will see a list of all available hosts on your network. Click the IP address of one of your victims. This will result in the right window showing a list of all hosts in the network, omitting the IP address you just selected. In the right window, click the IP address of the other victim, and click OK.
Figure 5: Selecting Victim Hosts for Poisoning
The IP addresses of both devices should now be listed in the upper table in the main application window. To complete the process, click the yellow-and-black radiation symbol on the standard toolbar. This will activate Cain & Abel’s ARP cache poisoning features and allow your analyzing system to be the middleman for all communications between the two victims. If you are curious to see what is happening behind the scenes try installing Wireshark and listen to the interface when you enable poisoning. You will see a flurry of ARP traffic to both hosts and immediately begin seeing the communication between them.
Figure 6: ARP Traffic Injection
When you are finished, simply click the yellow-and-black radiation symbol again to stop ARP cache poisoning.
Defending Against ARP Cache Poisoning
Looking at ARP cache poisoning from the defenders standpoint we are at a bit of a disadvantage. The ARP process happens in the background with very little ability to be controlled directly by us. There is no catch all solution, but proactive and reactive stances can be taken if you are concerned about ARP cache poisoning on your network.
Securing the LAN
ARP Cache Poisoning is only a viable attack technique when attempting to intercept traffic between two hosts on the same local area network. The only reason you would have to fear this is if a local device on your network has been compromised, a trusted user has malicious intent, or someone has managed to plug an un-trusted device into the network. Although we too often focus the entirety of our security efforts on the network perimeter, defending against internal threats and having a good internal security posture can help eliminate the fear of the attack mentioned here.
Hard Coding the ARP Cache
One way to protect against the unsecured dynamic nature of ARP requests and replies is to make the process a little less…dynamic. This is an option because Windows-based hosts allow for the addition of static entries into the ARP cache. You can view the ARP cache of a Windows host by opening a command prompt and type the command arp –a.
Figure 7: Viewing the ARP Cache
You can add entries to this list by using the command, arp –s
In cases where your network configuration does not change often, it is entirely feasible to make a listing of static ARP entries and deploy them to clients via an automated script. This will ensure that devices will always rely on their local ARP cache rather than relying on ARP requests and replies.
Monitoring ARP Traffic with a Third Party Program
The last option for defending against ARP cache poisoning is a reactive approach that involves monitoring the network traffic of hosts. This can be done with a few different intrusion detection systems (such as Snort) or through downloadable utilities designed specifically for this purpose (such as xARP). This may be feasible when you are only concerned about a single host, but can be a bit cumbersome to deal with when concerned with entire network segments.
Wrap Up
ARP Cache Poisoning is a great introduction into the world of passive man-in-the-middle attacks because it’s very simple to execute, is a very real threat on modern networks, and is difficult to detect and defend against. In the next article in this series we will focus on name resolution and the concept of DNS spoofing.
Read more...
Labels:
CEH - Hacking
Friday, June 4, 2010
Assets, Threats, and Vulnerabilities
10:39 PM |
Posted by
Ramy
Objectives:
Recall essential terminology
List the elements of security
As with any new technology topic, terminology is used that must be learned to better understand the field. To be a security professional, you need to understand the relationship between threats, assets, and vulnerabilities.
Risk is the probability or likelihood of the occurrence or realization of a threat. There are three basic elements of risk: assets, threats, and vulnerabilities. Let’s discuss each of these.
An asset is any item of economic value owned by an individual or corporation. Assets can be real — such as routers, servers, hard drives, and laptops — or assets can be virtual, such as formulas, databases, spreadsheets, trade secrets, and processing time. Regardless of the type of asset discussed, if the asset is lost, damaged, or compromised, there can be an economic cost to the organization.
A threat is any agent, condition, or circumstance that could potentially cause harm, loss, damage, or compromise to an IT asset or data asset. From a security professional’s perspective, threats can be categorized as events that can affect the confidentiality, integrity, or availability of the organization’s assets. These threats can result in destruction, disclosure, modification, corruption of data, or denial of service. Some examples of the types of threats an organization can face include the following:
Unauthorized Access
If userids and passwords to the organization’s infrastructure are obtained and confidential information is compromised and unauthorized, access is granted to the unauthorized user who obtained the userids and passwords.
Stolen/Lost/Damaged/Modified Data
A critical threat can occur if the information is lost, damaged, or unavailable to legitimate users.
Disclosure of Confidential Information
Anytimethere is a disclosure of confidential information, it can be a critical threat to an organization if that disclosure causes loss of revenue, causes potential liabilities, or provides a competitive advantage to an adversary.
Hacker Attacks
An insider or outsider who is unauthorized and purposely attacks an organization’s components, systems, or data.
Cyber Terrorism
Attackers whotarget critical, national infrastructures such as water plants, electric plants, gas plants, oil refineries, gasoline refineries, nuclear power plants, waste management plants, and so on.
Viruses and Malware
An entirecategory of software tools that are malicious and are designed to damage or destroy a system or data.
Denial of Service (DoS) or Distributed Denial of Service Attacks
An attack against availability that isdesigned to bring the network and/or access to a particular TCP/IP host/server to its knees by flooding it with useless traffic. Many DoSattacks, such as the Ping of Death and Teardrop, exploit limitations in the TCP/IP protocols. Like malware, hackers constantly develop new DoS attacks, so they form a continuous threat.
Natural Disasters, Weather, or Catastrophic Damage
Hurricanes, such as Katrina that hit New Orleans in 2005, storms, weather outages, fire, flood, earthquakes, and other natural events compose an ongoing threat.
If the organization is vulnerable to any of these threats, there is an increased risk of successful attack.
A vulnerability is a weakness in the system design, implementation, software or code, or the lack of a mechanism. A specific vulnerability might manifest as anything from a weakness in system design to the implementation of an operational procedure. Vulnerabilities might be eliminated or reduced by the correct implementation of safeguards and security countermeasures.
Vulnerabilities and weaknesses are common with software mainly because there isn’t any perfect software or code in existence. Vulnerabilities in software can be found in each of the following:
Firmware
This software is usually stored in ROM and loaded during system power up.
Operating System
This operating system software is loaded in workstations and servers.
Configuration Files
The configuration file and configuration setup for the device.
Application Software
The application or executable file that is run on a workstation or server.
Software Patch
This is a small piece of software or code snippet that the vendor or developer of the software typically releases as software updates, software maintenance, and known software vulnerabilities or weaknesses.
Vulnerabilities are not the only concern the ethical hacker will have. Exploits are a big concern, as they are a common mechanism used to gain access. That’s discussed next.
Defining an Exploit
An exploit refers to a piece of software, tool, or technique that takes advantage of a vulnerability that leads to privilege escalation, loss of integrity, or denial of service on a computer system. Exploits are dangerous because all software has vulnerabilities; hackers and perpetrators know that there are vulnerabilities and seek to take advantage of them. Although most organizations attempt to find and fix vulnerabilities, some organizations lack sufficient funds for securing their networks. Even those that do are burdened with the fact that there is a window between when a vulnerability is discovered and when a patch is available to prevent the exploit. The more critical the server, the slower it is typically patched. Management might be afraid of interrupting the server or afraid that the patch might affect stability or performance. Finally, the time required to deploy and install the software patch on production servers and workstations exposes an organization’s IT infrastructure to an additional period of risk.
Read more...
Recall essential terminology
List the elements of security
As with any new technology topic, terminology is used that must be learned to better understand the field. To be a security professional, you need to understand the relationship between threats, assets, and vulnerabilities.
Risk is the probability or likelihood of the occurrence or realization of a threat. There are three basic elements of risk: assets, threats, and vulnerabilities. Let’s discuss each of these.
An asset is any item of economic value owned by an individual or corporation. Assets can be real — such as routers, servers, hard drives, and laptops — or assets can be virtual, such as formulas, databases, spreadsheets, trade secrets, and processing time. Regardless of the type of asset discussed, if the asset is lost, damaged, or compromised, there can be an economic cost to the organization.
A threat is any agent, condition, or circumstance that could potentially cause harm, loss, damage, or compromise to an IT asset or data asset. From a security professional’s perspective, threats can be categorized as events that can affect the confidentiality, integrity, or availability of the organization’s assets. These threats can result in destruction, disclosure, modification, corruption of data, or denial of service. Some examples of the types of threats an organization can face include the following:
Unauthorized Access
If userids and passwords to the organization’s infrastructure are obtained and confidential information is compromised and unauthorized, access is granted to the unauthorized user who obtained the userids and passwords.
Stolen/Lost/Damaged/Modified Data
A critical threat can occur if the information is lost, damaged, or unavailable to legitimate users.
Disclosure of Confidential Information
Anytimethere is a disclosure of confidential information, it can be a critical threat to an organization if that disclosure causes loss of revenue, causes potential liabilities, or provides a competitive advantage to an adversary.
Hacker Attacks
An insider or outsider who is unauthorized and purposely attacks an organization’s components, systems, or data.
Cyber Terrorism
Attackers whotarget critical, national infrastructures such as water plants, electric plants, gas plants, oil refineries, gasoline refineries, nuclear power plants, waste management plants, and so on.
Viruses and Malware
An entirecategory of software tools that are malicious and are designed to damage or destroy a system or data.
Denial of Service (DoS) or Distributed Denial of Service Attacks
An attack against availability that isdesigned to bring the network and/or access to a particular TCP/IP host/server to its knees by flooding it with useless traffic. Many DoSattacks, such as the Ping of Death and Teardrop, exploit limitations in the TCP/IP protocols. Like malware, hackers constantly develop new DoS attacks, so they form a continuous threat.
Natural Disasters, Weather, or Catastrophic Damage
Hurricanes, such as Katrina that hit New Orleans in 2005, storms, weather outages, fire, flood, earthquakes, and other natural events compose an ongoing threat.
If the organization is vulnerable to any of these threats, there is an increased risk of successful attack.
A vulnerability is a weakness in the system design, implementation, software or code, or the lack of a mechanism. A specific vulnerability might manifest as anything from a weakness in system design to the implementation of an operational procedure. Vulnerabilities might be eliminated or reduced by the correct implementation of safeguards and security countermeasures.
Vulnerabilities and weaknesses are common with software mainly because there isn’t any perfect software or code in existence. Vulnerabilities in software can be found in each of the following:
Firmware
This software is usually stored in ROM and loaded during system power up.
Operating System
This operating system software is loaded in workstations and servers.
Configuration Files
The configuration file and configuration setup for the device.
Application Software
The application or executable file that is run on a workstation or server.
Software Patch
This is a small piece of software or code snippet that the vendor or developer of the software typically releases as software updates, software maintenance, and known software vulnerabilities or weaknesses.
Vulnerabilities are not the only concern the ethical hacker will have. Exploits are a big concern, as they are a common mechanism used to gain access. That’s discussed next.
Defining an Exploit
An exploit refers to a piece of software, tool, or technique that takes advantage of a vulnerability that leads to privilege escalation, loss of integrity, or denial of service on a computer system. Exploits are dangerous because all software has vulnerabilities; hackers and perpetrators know that there are vulnerabilities and seek to take advantage of them. Although most organizations attempt to find and fix vulnerabilities, some organizations lack sufficient funds for securing their networks. Even those that do are burdened with the fact that there is a window between when a vulnerability is discovered and when a patch is available to prevent the exploit. The more critical the server, the slower it is typically patched. Management might be afraid of interrupting the server or afraid that the patch might affect stability or performance. Finally, the time required to deploy and install the software patch on production servers and workstations exposes an organization’s IT infrastructure to an additional period of risk.
Read more...
Labels:
CEH - Hacking
Goals of Security
10:36 PM |
Posted by
Ramy
Objective:
Understand the security triangle, also known as CIA (confidentiality, integrity, and availability).
There are many ways in which security can be achieved, but it’s universally agreed that the security triad of confidentiality, integrity, and availability (CIA) form the basic building blocks of any good security initiative.
Confidentiality addresses the secrecy and privacy of information. Physical examples of confidentiality include locked doors, armed guards, and fences. Logical examples of confidentiality can be seen in passwords, encryption, and firewalls. In the logical world, confidentiality must protect data in storage and in transit. For a real-life example of the failure of confidentiality, look no further than the recent news reports that have exposed how several large-scale breaches in confidentiality were the result of corporations, such as Time Warner and City National Bank, misplacing or losing backup tapes with customer accounts, names, and credit information. The simple act of encrypting thebackup tapes could have prevented or mitigated the damage.
Integrity is the second piece of the CIA security triad. Integrity provides for the correctness of information. It allows users of information to have confidence in its correctness. Correctness doesn’t mean that the data is accurate, just that it hasn’t been modified in storage or transit. Integrity can apply to paper or electronic documents. It is much easier to verify the integrity of a paper document than an electronic one. Integrity in electronic documents and data is much more difficult to protect than in paper ones. Integrity must be protected in two modes: storage and transit.
Information in storage can be protected if you use access and audit controls. Cryptography can also protect information in storage through the use of hashing algorithms. Real-life examples of this technology can be seen in programs such as Tripwire, MD5Sum, and Windows File Protection (WFP). Integrity in transit can be ensured primarily by the protocols used to transport the data. These security controls include hashing and cryptography.
Availability is the third leg of the CIA triad. Availability simply means that when a legitimate user needs the information, it should be available. As an example, access to a backup facility 24x7 does not help if there are no updated backups from which to restore. Backups are one of the ways that availability is ensured. Backups provide a copy of critical information should files and data be destroyed or equipment fail. Failover equipment is another way to ensure availability. Systems such as redundant array of inexpensive disks (RAID) and subscription services such as redundant sites (hot, cold, and warm) are two other examples. Disaster recovery is tied closely to availability, as it’s all about getting critical systems up and running quickly. Denial of service (DoS) is an attack against availability. Although these attacks might not give access to the attacker, they dodeny legitimate users the access they require.
Read more...
Understand the security triangle, also known as CIA (confidentiality, integrity, and availability).
There are many ways in which security can be achieved, but it’s universally agreed that the security triad of confidentiality, integrity, and availability (CIA) form the basic building blocks of any good security initiative.
Confidentiality addresses the secrecy and privacy of information. Physical examples of confidentiality include locked doors, armed guards, and fences. Logical examples of confidentiality can be seen in passwords, encryption, and firewalls. In the logical world, confidentiality must protect data in storage and in transit. For a real-life example of the failure of confidentiality, look no further than the recent news reports that have exposed how several large-scale breaches in confidentiality were the result of corporations, such as Time Warner and City National Bank, misplacing or losing backup tapes with customer accounts, names, and credit information. The simple act of encrypting thebackup tapes could have prevented or mitigated the damage.
Integrity is the second piece of the CIA security triad. Integrity provides for the correctness of information. It allows users of information to have confidence in its correctness. Correctness doesn’t mean that the data is accurate, just that it hasn’t been modified in storage or transit. Integrity can apply to paper or electronic documents. It is much easier to verify the integrity of a paper document than an electronic one. Integrity in electronic documents and data is much more difficult to protect than in paper ones. Integrity must be protected in two modes: storage and transit.
Information in storage can be protected if you use access and audit controls. Cryptography can also protect information in storage through the use of hashing algorithms. Real-life examples of this technology can be seen in programs such as Tripwire, MD5Sum, and Windows File Protection (WFP). Integrity in transit can be ensured primarily by the protocols used to transport the data. These security controls include hashing and cryptography.
Availability is the third leg of the CIA triad. Availability simply means that when a legitimate user needs the information, it should be available. As an example, access to a backup facility 24x7 does not help if there are no updated backups from which to restore. Backups are one of the ways that availability is ensured. Backups provide a copy of critical information should files and data be destroyed or equipment fail. Failover equipment is another way to ensure availability. Systems such as redundant array of inexpensive disks (RAID) and subscription services such as redundant sites (hot, cold, and warm) are two other examples. Disaster recovery is tied closely to availability, as it’s all about getting critical systems up and running quickly. Denial of service (DoS) is an attack against availability. Although these attacks might not give access to the attacker, they dodeny legitimate users the access they require.
Read more...
Labels:
CEH - Hacking
Ethical Hacking Basics
10:24 PM |
Posted by
Ramy
Introduction
This lesson introduces you to the world of ethical hacking. Ethical hacking is a form of legal hacking that is done with the permission of an organization to help increase its security. This lesson discusses many of the business aspects of penetration (pen) testing. Information about how to perform a pen test, what types can be performed, what are the legal requirements, and what type of report should be delivered are all basic items that you will need to know before you perform any type of security testing. However, first, you need to review some security basics. This lesson starts with a discussion of confidentiality, integrity, and availability. Finally, the lesson finishes up with the history of hacking and a discussion of some of the pertinent laws.
NOTE
Nothing learned in this class is intended to teach or encourage the use of security tools or methodologies for illegal or unethical purposes. Always act in a responsible manner. Make sure that you have written permission from the proper individuals before you use any of the tools or techniques described within. Always obtain permission before installing any of these tools on a network.
Security Fundamentals
Security is about finding a balance, as all systems have limits. No one person or company has unlimited funds to secure everything, and we cannot always take the most secure approach. One way to secure a system from network attack is to unplug it and make it a standalone system. Although this system would be relatively secure from Internet-based attackers, its usability would be substantially reduced. The opposite approach of plugging it in directly to the Internet without any firewall, antivirus, or security patches would make it extremely vulnerable, yet highly accessible. So, here again, you see that the job of security professionals is to find a balance somewhere between security and usability. Figure 1.1 demonstrates this concept.
To find this balance, you need to know what the goals of the organization are, what security is, and how to measure the threats to security. The next section discusses the goals of security.
Read more...
This lesson introduces you to the world of ethical hacking. Ethical hacking is a form of legal hacking that is done with the permission of an organization to help increase its security. This lesson discusses many of the business aspects of penetration (pen) testing. Information about how to perform a pen test, what types can be performed, what are the legal requirements, and what type of report should be delivered are all basic items that you will need to know before you perform any type of security testing. However, first, you need to review some security basics. This lesson starts with a discussion of confidentiality, integrity, and availability. Finally, the lesson finishes up with the history of hacking and a discussion of some of the pertinent laws.
NOTE
Nothing learned in this class is intended to teach or encourage the use of security tools or methodologies for illegal or unethical purposes. Always act in a responsible manner. Make sure that you have written permission from the proper individuals before you use any of the tools or techniques described within. Always obtain permission before installing any of these tools on a network.
Security Fundamentals
Security is about finding a balance, as all systems have limits. No one person or company has unlimited funds to secure everything, and we cannot always take the most secure approach. One way to secure a system from network attack is to unplug it and make it a standalone system. Although this system would be relatively secure from Internet-based attackers, its usability would be substantially reduced. The opposite approach of plugging it in directly to the Internet without any firewall, antivirus, or security patches would make it extremely vulnerable, yet highly accessible. So, here again, you see that the job of security professionals is to find a balance somewhere between security and usability. Figure 1.1 demonstrates this concept.
To find this balance, you need to know what the goals of the organization are, what security is, and how to measure the threats to security. The next section discusses the goals of security.
Read more...
Labels:
CEH - Hacking
Subscribe to:
Posts (Atom)
