This week Raxis Chief Technology Officer Brian Tant continues his video series about the most common vulnerabilities our team has discovered as they’ve performed thousands of penetration tests across the US over the years.
In this video Brian highlights the unique challenges wireless security brings to the table and breaks down which type of encryption you may want to consider to enhance your wireless security posture and protect your network.
Brian explains the pros and cons of WPA2 Personal Encryption, WPA2 Enterprise Encryption, and Certificate-based Authentication and discusses which one the Raxis team recommends to bolster your security.
Hopefully, you’ve watched the video and have a better understanding about which type of network encryption is most secure. If you still have questions or want to learn more about protecting your corporate network, please reach out.
The Raxis team brings years of hacking and penetration testing experience to the table. We can use that experience to improve your skills and make your environment more secure.
Download our list of Top 10 Cyber Attacks to learn more about ways to secure your company.
In Raxis penetration tests, we often discover IKE VPNs that allow Aggressive Mode handshakes, even though this vulnerability was identified more than 16 years ago in 2002. In this post we’ll look at why Aggressive Mode continues to be a vulnerability, how it can be exploited, and how network administrators can mitigate this risk to protect their networks and remediate this finding on their penetration tests.
What is an IKE VPN?
Before we get into the security details, here are a few definitions:
Virtual Private Network (VPN) is a network used to securely connect remote users to a private, internal network.
Internet Protocol Security (IPSec) is a standard protocol used for VPN security.
Security Association (SA) is a security policy between entities to define communication. This relationship between the entities is represented by a key.
Internet Key Exchange (IKE) is an automatic process that negotiates an agreed IPSec Security Association between a remote user and a VPN.
The IKE protocol ensures security for SA communication without the pre-configuration that would otherwise be required. This protocol used by a majority of VPNs including those manufactured by Cisco, Microsoft, Palo Alto, SonicWALL, WatchGuard, and Juniper. The IKE negotiation usually runs on UDP port 500 and can be detected by vulnerability scans.There are two versions of the IKE protocol:
IKEv2 was introduced in 2005 and can only be used with route-based VPNs.
IKEv1 was introduced in 1998 and continues to be used in situations where IKEv2 would not be feasible.
Pre-Shared Keys (PSK)
Many IKE VPNs use a pre-shared key (PSK) for authentication. The same PSK must be configured on every IPSec peer. The peers authenticate by computing and sending a keyed hash of data that includes the PSK. When the receiving peer (the VPN) is able to create the same hash independently using the PSK it has, confirming that the initiator (the client) has the same PSK, it authenticates the initiating peer.
While PSKs are easy to configure, every peer must have the same PSK, weakening security.
VPNs often offer other options that increase security but also increase the difficulty of client configuration.
RSA signatures are more secure because they use a Certificate Authority (CA) to generate a unique digital certificate. These certificates are used much like PSKs, but the peers’ RSA signatures are unique.
RSA encryption uses public and private keys on all peers so that each side of the transaction can deny the exchange if the encryption does not match.
In this post, we are discussing the first phase of IKEv1 transmissions. IKEv1 has two phases:
Establish a secure communications channel. This is initiated by the client, and the VPN responds to the method the client requested based on the methods its configuration allows.
Use the previously established channel to encrypt and transport data. All communication at this point is expected to be secure based on the authentication that occurred in the first phase. This phase is referred to as Quick Mode.
There are two methods of key exchange available for use in the first IKEv1 phase:
Main Mode uses a six-way handshake where parameters are exchanged in multiple rounds with encrypted authentication information.
Aggressive Mode uses a three-way handshake where the VPN sends the hashed PSK to the client in a single unencrypted message. This is the method usually used for remote access VPNs or in situations where both peers have dynamic external IP addresses.
The vulnerability we discuss in this article applies to weaknesses in Aggressive Mode. While Aggressive Mode is faster than Main Mode, it is less secure because it reveals the unencrypted authentication hash (the PSK). Aggressive Mode is used more often because Main Mode has the added complexity of requiring clients connecting to the VPN to have static IP addresses or to have certificates installed.
Exploiting Aggressive Mode
Raxis considers Aggressive Mode a moderate risk finding, as it would take a great deal of effort to exploit the vulnerability to the point of gaining internal network access. However, exploitation has been proven possible in published examples. The NIST listing for CVE-2002-1623 describes the vulnerability in detail.A useful tool when testing for IKE Aggressive Mode vulnerabilities is ike-scan, a command-line tool developed by Roy Hills for discovering, fingerprinting, and testing IPSec VPN systems. When setting up an IKE VPN, ike-scan is a great tool to use to verify that everything is configured as expected. When Aggressive Mode is supported by the VPN, the tool can be used to obtain the PSK, often without a valid group name (ID), which can in turn be passed to a hash cracking tool.If you use Kali Linux, ike-scan is included in the build: We can use the following command to download the PSK from an IKE VPN that allows Aggressive Mode:
ike-scan -A [IKE-IP-Address] --id=AnyID -PTestkey
Here is an example of the command successfully retrieving a PSK:The tool also comes with psk-crack, a tool that allows various options for cracking the discovered PSK.Because Aggressive Mode allows us to download the PSK, we can attempt to crack it offline for extended periods without alerting the VPN owner. Hashcat also provides options for cracking IKE PSKs. This is an example Hashcat command for cracking an IKE PSK that uses an MD5 hash:
Another useful tool is IKEForce, which is a tool created specifically for enumerating group names and conducting XAUTH brute-force attacks. IKEForce includes specific features for attacking IKE VPNs that are configured with added protections.
What VPN Administrators Can Do to Protect Themselves
As Aggressive Mode is an exploitable vulnerability, IKE VPNs that support Aggressive Mode will continue to appear as findings on penetration tests, and they continue to be a threat that possibly can be exploited by a determined attacker.We recommend that VPN administrators take one or more of the following actions to protect their networks. In addition, the above actions, when documented, should satisfy any remediation burden associated with a prior penetration test or other security assessment.
Disable Aggressive Mode and only allow Main Mode when possible. Consider using certificates to authenticate clients that have dynamic IP addresses so that Main Mode can be used instead of Aggressive Mode.
Use a very complex, unique PSK, and change it on a regular basis. A strong PSK, like a strong password, can protect the VPN by thwarting attackers from cracking the PSK.
Change default or easily guessable group names (IDs) to complex group names that are not easily guessed. The more complex the group name, the more difficult of a time an attacker will have accessing the VPN.
Keep your VPN fully updated and follow vendor security recommendations. Ensuring software is up to date is one of the best ways stay on top of vulnerability management.
Ask any penetration tester at Raxis, and they’ll tell you that we see insecure transmission of private data, often in the form of usernames and passwords, on many of the web application and external penetration tests we perform. There are a number of easily discoverable issues in play that can assist an attacker in gaining access to private information and internal systems. These vulnerabilities are a part of A3-Sensitive Data Exposure in OWASP’s 2017 Top 10 list.
Encrypting Data in Transit
Say you’re on a public Wi-Fi network at a coffee shop or a hotel, or even a private network that’s been compromised in a previous attack. An attacker on the same network can sniff traffic as it’s sent across the network or even outside of the network to the Internet. This is called a Man in the Middle (MitM) attack. Users on the network have no way to know that an attacker is monitoring their network traffic in this way.
To mimic a MitM attack, I used Wireshark to capture the network traffic from my own computer. First, I logged in to a website that does not use encryption. This site uses HTTP to send the credentials in cleartext, which you can see listed in the captured POST request below:
Now, let’s see what happens when I submit my credentials over an encrypted HTTPS connection:
Even though I can sniff all network traffic between my computer and the website, I can not read the data itself. Private data such as user credentials, session tokens, and credit card numbers should always be encrypted in transit using HTTPS to protect users from man in the middle attacks.
Encoding is Not Encryption
We often run into websites that use Base64 or another form of encoding to protect data. It’s important to note that while encoding can be used to protect data from accidental manipulation or to make data easier to send and store, it does not offer any additional security than if the encoded data was to be left in cleartext. The fundamental difference between encoding and encryption is that while encoding is intentionally designed to be performed without the use of a key or secret, encryption is designed to protect the data from being accessed without such a key or secret.
In the example below, I used a free base64 decoding website to decode a base64 value. Feel free to use this website to see how easily you can decode this base64-encoded value:
RHJpbmsgWW91ciBPdmFsdGluZQ==
SSL Certificates
Now that you understand that sending private data in cleartext (or base64) is a bad idea and you’ve decided to use HTTPS for your site, you still need a valid SSL certificate before your site is secure. Without a valid SSL certificate, browsers will warn that your site is not secure as my browser did for this Nessus site that I run on my computer.
While errors like this can be acceptable on a private computer where I know what the site is and where I’m running it, it is not acceptable for an external website or an internal corporate network. An attacker trying to trick you into using a malicious site might use an invalid certificate such as the one above to trick you into using their site. Without a valid certificate, you cannot be sure whether the site is genuine and safe or not.
As a comparison, here is a site that uses a valid SSL certificate. The browser checks the certificate and validates that it’s secure.
The browser also allows you to view the certificate yourself, should you want more detailed information about the issuer, subject, or public key. You can view all the details of why the browser declares the certificate as secure.
It’s issued by a trusted Certificate Authority (CA), in this case a free CA called Let’s Encrypt
It hasn’t expired yet
It uses a strong encryption algorithm for the public key
This brings up a few common issues we see that make certificates insecure:
The certificate is expired. Many companies don’t have a master list of certificates and their expiration dates, which can lead to forgotten certificates that don’t get replaced until a penetration test or customer complaint highlights the issue.
The certificates is for the wrong website. Occasionally, companies many forward domain names to the server that uses the certificate or change existing ones without updating the certificate itself. Since the certificate wasn’t issued for the additional or modified domains, it is not a valid certificate for those domains.
The certificate is self-signed. While it’s generally okay to self-sign certificates for fully internal sites provided the signing authority has been added to the trusted certificate store for all devices on the network, all external-facing sites should use an SSL certificate signed by a trusted Certificate Authority (CA).
The dangers with untrusted self-signed certificates are:
An attacker could create their own self-signed certificate that looks nearly identical to the legitimate one.
Many users will refuse to use the site because of the security errors browsers will show.
Users who are willing to use the site will become accustomed to using sites with certificate errors, making them more likely to ignore these errors on a malicious site.
Encryption Ciphers and Protocols
Now that your webpages are being served over HTTPS with a valid certificate, let’s think about the strength of the encryption itself. Think of Julius Caesar using the now famous Caesar Cipher to encrypt secret military messages. Centuries later, it’s best not to use that cipher because it was cracked and is now common knowledge. If you’re interested in the history of encryption, Simon Singh’s The Code Book is a great read.
For the purposes of securing a website, we need to use complex encryption protocols and ciphers. Because attackers are always looking for flaws in these protections, we must always keep one step ahead and be sure to avoid using any weaker ciphers or protocols. SSLScan is a free tool that runs on Linux, Windows and macOS. Here is an SSLScan for https://raxis.com/. For a free online tool that can assess the ciphers and protocols on external facing sites, check out Qualys’ SSL Server Test. SSLScan shows all protocols and ciphers that the site accepts. Weak protocols and ciphers, if they were enabled for the site, would be listed in yellow or red.
Two types of protocols are commonly used: SSL (Secure Sockets Layer) and TLS (Transport Layer Security). All versions of SSL have been compromised and should not be used. There are multiple known exploits that attackers can use to gain access to your data or cause a denial of service attack if the data is transmitted using SSL. At the time of writing, the recommended protocol is TLSv1.2, although TLSv1.1 can be secure if configured correctly. TLSv1.3 is currently being drafted, so be sure to keep an eye out for that in the future. We always recommend removing weak protocols, such as SSLv2, SSLv3, and TLSv1.0, because SSL/TLS implementations support a downgrade process that allows an attacker to bypass a server’s secure protocols in favor of less secure protocols.
Each protocol provides many cipher suites, some more secure than others. Weak ciphers must be explicitly disabled on the server to ensure that cryptographically strong ciphers are used when transmitting private data. In the example above, https://raxis.com/ only uses strong ciphers and protocols.
What Web Developers Can Do to Protect Their Sites
There are a number of things that web developers and administrators can do to keep their sites secure and their users safe.
Ensure that all private data, including credentials, session tokens, credit cards, medical data, and so on are encrypted in transit by enforcing the use of HTTPS.
All resources on a page must be encrypted for the page to be considered secure. This means that graphics, scripts, and other behind-the-scenes files should be served over HTTPS as well.
Use only certificates issued by a trusted Certificate Authority (CA).
Replace certificates before they expire. Keep track of your company’s certificates using a tool, such as Venafi’s TLS Protect. This tool can even automatically replace expiring certificates.
Use the TLSv1.2 protocol and disable older protocols where possible. If your site needs to support browser versions released prior to 2013, enable TLSv1.1, as these older versions do not support TLSv1.2. See Can I Use to see which browsers supports support TLSv1.2.
Disable weak ciphers within your protocols’ cipher suites. Test thoroughly before making changes in production to ensure that your site doesn’t have outages. OWASP’s Transport Layer Protection Cheat Sheet is a great resource.
Annual penetration tests can help you your web applications and external network continue to provide strong encryption to your users. Raxis’ Baseline Security Assessment can also help you keep a monthly watch for any issues.
What Users Can Do to Protect Themselves
While it’s up to website administrators to keep websites secure, users of these sites can keep themselves safe by being vigilant. Watch your browser. Never enter private data such as passwords, credit card numbers, and medical information if the website you’re using:
Starts with http://
Starts with https:// but shows a security error
Close your browser if you see a security error when you are already logged in. Your private data could be sniffed by an attacker every time you submit a form or click a link.
When on public Wi-Fi, such as free Wi-Fi offered in hotels or restaurants, use a VPN such as privateinternetaccess to ensure your private information is encrypted in transit.
