5.3. Mobile NAC and Direct Attacks

You now know why companies look at Mobile NAC, but what does it actually protect against? Mobile NAC helps protect against the following:

  • Direct attacks

  • Wireless-related attacks

  • Malware

5.3.1. Exploiting Laptops with Direct Attacks

Whether it's war, boxing, football, or computer security, it's just plain easier and more effective to attack the weakest point. If a football team has a defensive line that can't stop the run, then run the ball right at them. If you're boxing and your opponent has a bad head cut, hit your opponent in the bad cut. If a company spends millions of dollars protecting its LAN but doesn't protect its laptops, attack its laptops.

Here are two important tactics to realize about hackers:

  • Tactic 1 — They will target companies specifically.

  • Tactic 2 — They don't care who their target is. If the target is vulnerable, they'll attack.

Regardless of the tactic, hackers will go for the weakest link first. Often, that weakest link is the mobile user. If the hackers' goal is to break into BigCompany, Inc., then the hacker can try many different means to break into that company. If the hacker can't break through BigCompany's LAN defenses, he or she can simply try to attack the company's laptops.

If hackers don't care whom they exploit, they will simply look for a vulnerable device and attack. Everyone has something valuable, or sometimes they just want to use the device as a means to attack other systems. The question to enterprises is "How can these devices actually be attacked, and how can Mobile NAC help?" With either tactic, the threat and the means to exploit can be the same. Figure 5-1 shows this threat.

Figure 5-1. Attacking the weakest point

If you are a hacker, the first step in attacking a device directly is to find a victim, or have the victim find you. This can be done a number of different ways:

  • An attacker scans the Internet or other public network for potential victims.

  • An attacker physically follows or sights a potential victim on a public network, such as a public Wi-Fi hotspot.

  • Victims are lured to visiting a web site where they can be attacked directly.

5.3.2. View a Web Page for Two Seconds and Get Hacked!

A novel way for hackers to find a victim is to have the victim find them. This can easily be done by having the victim simply visit a web page for less than two seconds. Literally, if a victim visits a malicious web page for two seconds, the victim's corporate laptop could be completely hacked if it is not protected while it is mobile.

Here are the steps to performing this attack:

  1. Create a malicious web site.

  2. Have a user view that web page.

  3. Exploit the victim's machine.

Figure 5-2. Exploitation as a result of visiting a web site

The steps sound simple — and they are. The reason the corporate system is vulnerable is because it is mobile and its security posture is deficient. Figure 5-2 shows the flow of how this exploit will work.

Let's start by creating the malicious web site. There are a number of ways to do this, but let's again use Metasploit to perform this exploit. As shown in Chapter 2, Metasploit is a framework that allows for many different exploits to be incorporated into the tool. To create this malicious web page, let's use an exploit that takes advantage of the Internet Explorer VML Rectfill vulnerability.

It is important to note that this is but one example of an Internet browser-based vulnerability. If you look at the patches released by Microsoft on a routine basis, you will find many critical patches and vulnerabilities relating to Internet Explorer. This exploit will take advantage of the vulnerability described as MS06-055. The following information regarding this vulnerability is available via Microsoft's web site at www.microsoft.com/technet/security/Bulletin/MS06-055.mspx:

VML Buffer Overrun Vulnerability — CVE-2006-4868:

A remote code execution vulnerability exists in the Vector Markup Language (VML) implementation in Microsoft Windows. An attacker could exploit the vulnerability by constructing a specially crafted web page or HTML e-mail that could potentially allow remote code execution if a user visited the web page or viewed the message. An attacker who successfully exploited this vulnerability could take complete control of an affected system.

Affected Software:

  • Microsoft Windows 2000 Service Pack 4

  • Microsoft Windows XP Service Pack 1

  • Microsoft Windows XP Service Pack 2

  • Microsoft Windows XP Professional x64 Edition

  • Microsoft Windows Server 2003 and Microsoft Windows Server 2003 Service Pack 1

  • Microsoft Windows Server 2003 for Itanium-based Systems and Microsoft Windows Server 2003 with SP1 for Itanium-based Systems

  • Microsoft Windows Server 2003 x64 Edition

  • Recommendation: Customers should apply the update immediately

There are a few key points to note about this vulnerability. First, it affects a lot of different systems. Second, it allows a hacker to take complete control of a system. The recommended fix for this problem is to apply Microsoft's patch for the vulnerability as soon as possible. In many companies, that patch gets applied once a laptop physically comes onto the corporate LAN or when a user decides to VPN into the corporate network. In many cases, that is simply too late.

NOTE

One reason companies do not patch devices while they are mobile is because they want to control the distribution of patches from a central location, as well as protect the integrity of the corporate image. A good Mobile NAC solution would provide this. The other reason is because their systems simply are physically incapable of patching outside the LAN. A good Mobile NAC solution will address this, as well.

Once in Metasploit, the exploit to use must be chosen, and then the payload must be selected. The payload is what will happen to the exploited system once it is exploited. Metasploit has many different payloads that are available. In this case, let's use the win32_reverse payload, which will open a shell between the exploited machine and the hacker. Once the exploit and payload are selected, the various options can be set and the exploit can be run. Figure 5-3 shows the use, set, and show commands in action.

All that's left to do now is set the various options and run the exploit. The exploit is run by typing the exploit command, and then Metasploit simply waits for connections, as shown in Figure 5-4.

At this point, Step 1 is complete. The malicious code has been created, and you can pretty much do whatever you want with this code. Figure 5-5 shows the HTML code for this exploit.

Figure 5-3. Selecting the payload

Figure 5-4. Typing "exploit" and waiting for connections

Now, you must get a victim to view the web page. This could be done by a user simply coming across the web page, or you could try to entice the user to view the web page. An e-mail is a great way to get a victim to visit the web page, especially if it is hidden as something else. Figure 5-6 shows an e-mail message where the URL provided actually goes to something other than what is being shown in the e-mail. This is a common phishing tactic.

Figure 5-5. Exploit HTML code

Figure 5-6. E-mail using a phishing tactic

NOTE

The malicious code can also be part of a legitimate web site. Recently, Monster.com visitors were exploited by malicious code placed on that web site.

All the victim needs to do is click on the link. Internet Explorer will be launched, the web page will be loaded, and in less than two seconds, the victim's system will be completely compromised. The site being accessed contains the malicious HTML code, and once it is loaded into the browser, the machine is hacked.

You'll recall that this exploit was configured to create a reverse shell to the hacker. This shell gets created by using the well-known tool Netcat. The hacker runs Netcat in listening mode, where it listens for incoming communications over port 4321, as configured in Metasploit. When the victim is exploited by viewing the malicious web site, the exploit communicates back to the hacker over port 4321, and a reverse shell is created. Figure 5-7 shows the Netcat command being run on the hacker's machine, and the reverse shell being created back on the victim's machine.

Figure 5-7. Netcat command being run on the hacker's machine

The c:Documents and SettingsDemoDesktop> prompt is actually on the victim's system. As easily as viewing a web page for two seconds, the victim has been exploited. Now that all the steps have been completed, the hacker can poke around the victim's machine and pretty much do whatever he or she wants. As a quick example, this hacker finds a TopSecret.txt document in the SecretData folder and views it, as shown in Figure 5-8.

Figure 5-8. Viewing the TopSecret.txt document

This is but one example of what a hacker could do with this exploit. Some other malicious acts could include the following:

  • Stealing VPN configuration information, so the hackers themselves could connect to the VPN.

  • Disabling antivirus and other security applications.

  • Installing a rootkit.

  • Installing a keylogger that will automatically capture every key typed by the user and e-mail this information back to the hacker on a routine basis. This data would include not only sensitive file data but also all typed usernames and passwords.

  • Turning the victim into a bot to be used in a bot network, where large numbers of other exploited systems are used to perform malicious acts.

  • Practically anything the hacker wants.

So, just how likely is it that such an attack will take place? Does it seem like kind of a long shot that this could actually happen? In actuality, as many as 1 in 10 URLs will attempt to do something bad to a user who simply visits the web page. That's 10 percent!

The "Ghost in the Browser, Analysis of Web-based Malware," is a great report that came out earlier this year. This report was created by Google, and it shows just how likely this type of attack can happen. Following are the key concepts of the report:

  • After an in-depth analysis of 4.5 million URLs, it was found that 450,000 URLs were engaging in drive-by downloads; 700,000 seemed to be malicious.

  • An exploit made possible by the missing patch MS07-009 is specifically mentioned in the report as an exploit that is used by malicious web sites to infect users.

  • The report specifically states that, while many antivirus engines rely on creating signatures from malware samples, adversaries can prevent detection by changing binaries more frequently than antivirus engines are updated with new signatures.

I reference this report in many of my presentations. This is great objective information that shows just how important Mobile NAC is to protecting devices as they are mobile.

The preceding example shows how a malicious web page could be created and, by using phishing techniques, a victim can be enticed to view the malicious web page. Let's take this a step further and see how many machines can be exploited in a short period of time with a variation of this exploit.

5.3.3. Protecting against AP Phishing and Evil Twin

Public Wi-Fi hotspots are everywhere, and they pose a tremendous threat for a lot of different reasons. One of the biggest threats is that mobile computers are connecting to wireless networks, and the users of these systems have no way to judge if these networks are real, or if they are malicious networks set up by people with ill intent. These types of attacks are known as AP Phishing and Evil Twin. These have received a great deal of press over the past few years, and there's good reason why.

Wireless hotspots are everywhere, and for most users, the process to connect to them is pretty much the same:

  1. Go the hotspot and start up the laptop.

  2. Launch Windows Zero Config (WZC) and see what wireless signals are present.

  3. Select the desired signal and connect.

  4. Open Internet Explorer (or another browser). If it's a free and open web site, then the user can start surfing the Internet. If it's a pay hotspot or if there are terms and conditions that must be agreed to, the user must enter information or click on a button displayed in the walled garden, then the user will be connected to the Internet.

A big threat surrounds Steps 2 and 3. The end user has no means to know if a wireless signal that is being broadcast is real or fake. The user can only go by the name that is being presented in the wireless program. This is a problem since hackers can create their own fake wireless networks with the names of commonly used public Wi-Fi hotspots. The users think they are real, connect, and can then be exploited.

There's a really cool program out there called Airsnarf, which is essentially a bunch of scripts that enable a laptop computer to "become" a public Wi-Fi hotspot. With this functionality, a hacker can take a laptop into a public place, turn it into a hotspot, and watch as people mistakenly connect to the fake Wi-Fi network. This trick would be incredibly successful if it were run in an airport, coffee shop, or other public area where users typically use their computers to connect wirelessly.

Airsnarf performs the following functionality:

  • Transmits any Service Set Identifier (SSID) that is configured in the program. For example, it can be configured to transmit as tmobile, concourse, Panera, and so on.

  • Accepts connections and establishes Layer 3 connectivity between the computer running Airsnarf and the computer connected via Wi-Fi.

  • Displays a web page that is served to the victim when the victim establishes the connection and launches a browser.

To configure the SSID to be broadcast, the airsnarf.cfg file simply needs to be modified. The following code shows the contents of an airsnarf.cfg file that will broadcast the signal as tmobile. To make the system look as if a different SSID is being broadcast, tmobile can simply be replaced with Panera, Concourse, Free WiFi, and so on. You should also note that there are variables to configure the IP network, gateway, and so on.

ROGUE_SSID="tmobile"
ROGUE_NET="192.168.1.0"
ROGUE_GW="192.168.1.1"
ROGUE_INTERFACE="wlan0"
#export ROGUE_SSID ROGUE_NET ROGUE_GW ROGUE_INTERFACE

Once properly configured, the airsnarf command can be executed. Figure 5-9 shows the airsnarf command being executed and the program waiting for connections to be established.

At this point, any computer within wireless range would see the tmobile signal being broadcast by this laptop. They would have no reason to think that it wasn't a real T-Mobile hotspot. Figure 5-10 shows how the signal would appear in WZC.

Figure 5-9. The airsnarf command being executed and the program waiting for connections to be established

Figure 5-10. How the signal would appear in WZC

A critical item to note is that the T-Mobile SSID being broadcast actually looks like it is coming from an access point. It is likely that you have heard about users being tricked into connecting to ad hoc networks, where the Wi-Fi signal is actually a peer-to-peer, or computer-to-computer, connection. These types of connections are quite easy for even basic users to differentiate. An example of an ad hoc network is shown in Figure 5-11. This ad hoc network is named elvis, although it could easily have been named tmobile or even free wifi.

With the fake T-Mobile SSID being broadcast, it is only a matter of time before users connect. Again, this would be really easy to do in a public place. So what's the big twist on the previous hack? Well, that takes us to the Step 4, opening up a browser and seeing what page the hotspot displays. Instead of serving up just any page, what if a malicious web page were displayed? That way, every single user who connected to the fake hotspot and opened a browser could become infected by simply viewing the web page that the hotspot is displaying. With this method, many, many laptops could become infected in a very short period of time.

Instead of creating a reverse shell, a hacker could choose a different payload. Perhaps the hacker would choose a payload that installs malware (such as a keylogger) onto the machine. All that the user wanted to do was connect to a well-known Wi-Fi hotspot, and in no time, the user's machine can be completely compromised. This is certainly crazy stuff!

Figure 5-11. Example of an ad hoc network

5.3.4. Using Mobile NAC to Protect against Attacks

The reason the machine in the previous example was open to exploitation is because it was vulnerable. The machine was vulnerable because of the following:

  • It did not receive and have installed the MS06-055 patch.

  • Though vulnerable, the system wasn't restricted and was able to get itself into trouble.

  • There weren't sufficient security technologies in place on the device to protect it while the system waited to receive the patch.

The absolute best way to protect against exploits is to entirely remove the vulnerability. This is different from relying on security software (such as antivirus software) to stop each individual exploit as it becomes available. This is one of the critical reasons why patching is so important. By installing a patch, the entire vulnerability is removed.

Having not received the MS06-055 patch is the reason behind why the machine was compromised. If the system had this patch, it wouldn't matter how many different exploits tried to take advantage of that vulnerability; they would have failed. The inability to patch devices while they are mobile is one of the biggest security deficiencies that companies have. I see this every single day. LAN-based NAC and LAN-based patching systems do nothing to address this problem.

Think back to the example mentioned in Chapter 2, the one related to the Fortune 500 company I worked with late last year. They had a LAN-based patching solution in place, such as WUSS, SMS, or Altiris. They stated that it didn't matter if they could patch while devices were mobile; their users would either physically come back to the LAN on a routine basis, or certainly VPN back into the corporate network to receive the patches. As you'll recall, that company was mistaken, as their systems had the following deficiencies:

  • Six Critical Microsoft patches were missing.

  • One Important Microsoft patch was missing.

  • Some missing Critical patches were new, and some were a few years old.

  • The antivirus definition files were out of date.

  • The systems had four SANS Top Ten Security Vulnerabilities, which are more than just missing patches.

NOTE

LAN-based systems are not effective at patching mobile devices, period! I see this every single time I run a vulnerability assessment for companies that only have these types of solutions.

While the patching part is important, so is the quarantining. With LAN-based NAC, the concept of quarantining exists so that devices with insufficient security postures are unable to access data, infect other resources, and get themselves into more trouble. The need for this important concept doesn't change simply because a laptop isn't on the LAN.

If the victim in the previous example were restricted, then he or she wouldn't have been exploited. Because the security posture was deficient, the victim shouldn't have been able to surf the Internet freely; the victim should have been restricted. This restriction could have taken place at two different layers:

  • Layer 7 (Application Layer) — Since there was a huge security defi-ciency in Internet Explorer, the user should have been restricted from using Internet Explorer until the patch was installed.

  • Layer 3 (Network Layer) — Because of the critical deficiency, the system should have only been able to go to networks and subnets that the company felt appropriate while in a deficient state.

This restriction and quarantining would have stopped the victim from being exploited. The laptop would only have been able to use Internet Explorer and get to the malicious web page if it had received the missing patch. Once patched, it wouldn't have mattered if the user viewed the page because the user was no longer vulnerable to any exploits relating to this vulnerability. Figure 5-12 illustrates the Layer 3 and Layer 7 restriction.

In addition to patching and restricting, it is still important to used layered security. Having an enterprise-grade personal firewall with intrusion prevention capabilities and zero day protection also would have helped prevent this attack. As discussed earlier, zero day protection protects against attacks that aren't yet known. So, if a Microsoft patch wasn't available yet or if a vulnerability wasn't yet known, zero day protection could help.

Figure 5-12. Layer 3 and 7 restriction

There are a couple of very good enterprise-grade personal firewalls on the market today. These differ vastly from the firewall that comes with Windows XP SP2. In fact, if the Windows XP SP2 firewall were running in the previous example, the victim still would have been hacked. That firewall is very simple and has basic functionality.

On the other hand, if IBM's Proventia client was running, the attack would have been stopped. That is because this firewall has advanced functionality and is more suitable for enterprises. (Proventia is the latest version of BlackICE and Real Secure Desktop Protector.) Figure 5-13 shows the Proventia client stopping the attack from taking place.

So, of these three ways to stop the attack from happening, which one is the best? The answer truly is that you must have all three. Nothing will catch everything, and layered security is important.

The big point to understand about this attack is that LAN-based NAC would have never been in the picture. Ask yourself these questions as they pertain to your own environment:

  • Do my laptops leave the corporate LAN?

  • Do my laptops work with data when they are outside of the LAN?

  • Do my mobile laptops surf the Internet?

  • Can I patch mobile laptops while they are mobile?

  • Can I restrict mobile laptops while they are mobile?

Figure 5-13. Proventia client stopping the attack from taking place

As you answer these questions, relate your answers to what you now know about Mobile NAC and LAN-based NAC. It should be clear to you how important Mobile NAC is in the overall security strategy.

NOTE

Enabling mobility can put the LAN at risk and, at the same time, LAN-based NAC solutions alone cannot sufficiently secure the LAN from mobile devices.

5.3.5. Why Proxy Settings Don't Offer Robust Security

In speaking with the companies that I do, I get to see some pretty novel solutions to addressing security concerns. Sometimes these solutions are revolutionary and make their way into the mainstream. More often than not, they address one particular problem while still leaving other problems present. That is the case with the enforcement of proxy settings.

I first heard about using this method a number of years ago. I was talking with a very large insurance company about its use of personal firewalls and other protective measures for mobile devices. The typical discussions were had with them, and they stated that they pretty much had everything covered. They noted how they prevented people from surfing the Internet by enforcing proxy settings. The only way that a user could ever surf the Internet was if the Internet traffic came through the proxy server on the LAN. That way, the company could control and monitor where users could go. In the company's eyes, that would alleviate the Internet threat. In the company's eyes, it was also a reason why it didn't feel the need to use an enterprise-grade personal firewall.

Over the past few years, I've actually come across one or two other companies that had the same exact line of thinking. While I do agree that enforcing the use of proxy settings does offer a level of security, I certainly would not say that it negates the use of a high-quality enterprise-grade personal firewall. To show you this point, let's look at how this concept works. Figure 5-14 provides a graphical representation.

If a user wants to surf the Internet with this solution, the user must establish a VPN tunnel back to the corporate LAN. That is the only way the LAN-based proxy server can be reached. This isn't a bad idea for controlling where users surf. If the proxy server were linked to Websense or some other web-filtering tool, it could provide a good level of control. This particular solution would not protect against a direct attack, however.

Here's another interesting point about this solution. If a user wants to connect to a public Wi-Fi hotspot, even a free one, this solution will often actually prevent the user from connecting. That is because to access many of these hotspots, the user must accept various terms and conditions. These terms and conditions are displayed as the walled garden page. If all browser-based traffic must pass through a LAN-based proxy server, then this walled garden page will never be displayed and the user will never achieve access. It's quite the Catch 22. What companies do is have the end user run a script to modify the browser proxy settings when the user attempts to connect, and then run another script to reenforce the proxy settings. This is shown in Figure 5-15.

Figure 5-14. Using proxy settings for security purposes

Figure 5-15. Laptops in a wireless hotspot environment

While this solution has good intentions, it has serious flaws. Providing no protection against direct attacks is a big one. Having the end user be able to modify the settings is another. This is a really good example of where knowing the threats can help point out where solutions can help and where they leave gaps.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.144.9.124