Encryption on the wired and wireless
Who’s listening to your communications and how?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Related Stories: Cybersecurity for Executives | Network Security | Encryption
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
My last post in this series on Cybersecurity for Executives was about encryption at rest, which refers to encrypting data where it is stored. We also have to encrypt data when it’s moving from one location to another. If we fail to encrypt data transferred over a wired or wireless network, someone could easily intercept and read that data. Encrypting data as it moves between systems is referred to as encryption in transit.
How attackers can steal data on the network
I explained network ports and protocols in a previous post. When two systems send data back and forth, they need to send data to the right location and speak the same language. I wrote about IP, TCP, and UDP protocols. These protocols facilitate communications when computers such as web servers, database servers, and end-user systems talk to each other. At a very high level, when your computer sends a request to a website to retrieve a web page, the request is passed to a device called a router on your local network. The router knows how to get your request from the local network to the correct web server, usually via the Internet. When network devices route your request over the Internet, it typically passes through various network devices which are owned and maintained by different people and organizations. If devices transmit your data as plain text (unencrypted), then software on any of those devices could read your data.
Another way to get access to your data as it traverses the Internet is when an attacker tricks your computer into believing that the attacker’s computer is the router. Then when you send a request, it goes to the attacker’s machine instead of the correct router. The attacker then forwards it to the router. As the packets pass through the attacker device, any unencrypted traffic may be read by the attacker as you make web requests. The attacker may also trick the user into clicking on and accepting an invalid encryption certificate, which then also allows the attacker to read encrypted data. The name for this type of packet rerouting and snooping is called a Man-in-the-Middle attack or MITM. The attacker machine sits between two legitimate sources spying on the data going back and forth.
YOUR COMPUTER >> ATTACKER >> YOUR ROUTER
When IOT (Internet of things) devices exchange data, they may use other types of protocols like Bluetooth, Zigbee, or MQTT. These protocols are designed to be light and fast for small devices. Even though these protocols aren’t flowing over your typical network router, this data in transit still needs to be encrypted. Criminals can buy devices that intercept this type of wireless traffic and read or manipulate it. If you also connect these devices to your wireless and wired networks, potentially attackers could route traffic between the two different types of networks to hide nefarious activity. Authenticating and encrypting traffic between IOT devices helps prevent rogue traffic or devices on these IOT networks.
The same goes for cellular communications and Wi-Fi networks. Different pentesting and attacker tools and devices are designed to intercept this type of traffic when attackers find vulnerabilities and poorly designed networks. Older Wi-Fi routers operate like a network device called a hub that sends data for every device to every other device on the network. Wired networks communicate via devices called a switch that only sends data to the target destination. Some newer Wi-Fi devices try to prevent sniffing by acting more like a switch but leveraging technologies that do not take into account newer network protocols like IPv6. One device used to intercept traffic on Wi-Fi networks is called a Wi-Fi pineapple.
Another thing to consider is how much of your data is exposed when using different types of encryption that operates at different layers in a network. As packets traverse a network, different types of devices add data to the packet as they pass through. This additional data referred to as packet headers tell network devices how to route your traffic to the correct destination. Sometimes all the packet data is encapsulated in an encrypted tunnel. Other times only the payload (the data only and not the headers) is encrypted, and some of the information included in the headers are still exposed. Exposing any data, like which domain names your system is visiting, may provide the attacker with useful information. Any exposed packet headers could be manipulated by an attacker to include commands sent to malware or to exfiltrate data. If you use SSL or TLS, data in the payload is encrypted, but not the full packet. Attackers can still see and manipulate some of the packet headers. DNS traffic may also be exposed. If you use an IPSEC VPN, the entire packet flows through an encrypted, authenticated tunnel.
These aspects of network communications show that it’s essential not only to encrypt data. You also need to understand how much what data may still be exposed depending on the encryption implementation. Unfortunately, that’s not the only thing you need to worry about when implementing encryption in transit.
Protect Private Keys
As with encryption at rest, encryption in transit uses keys to encrypt and decrypt data. Those keys need to be protected. An attacker who can get the key can decrypt the data. When you set up encryption in transit for your website, sometimes you have to generate a private and public key to get what is known as a TLS (formerly SSL) certificate. Protect the keys you use to make that request carefully. Do not let anyone check them into your source control system where you maintain your code, for example. Store secrets like encryption keys securely, typically in a secure vault designed to store secrets. Different people may manage the keys and the applications that use them. The people managing any of your encryption keys should have security training, so they understand how to handle and manage these keys properly. Companies like Venafi offer products that help with the management of these keys.
When generating encryption Keys for an IOT device, a TPM (tamper-proof module) can store private keys. A TPM is typically hardware manufactured into the device to store keys. A file can be stolen and transferred. Something built into the hardware, not so much. If someone tries to tamper with or remove the keys, the TPM should prevent that. The keys never leave the TPM. Of course, you don’t want to simply trust the acronym TPM but look for independent third-party verification of the implementation by a trusted source who understands the technology.
A private key can be created automatically on a device. No one manufacturing the device ever needs to see the private key. The public key can be securely stored to identify a device uniquely, presuming there is no way for someone to swap the public key and device. The key exchange with other systems should never expose a private key used in asymmetric encryption that can uniquely identify a specific device.
With the rise of SAAS (software as a service), in may cases, IOT vendors are sending data to the cloud. You also want to understand how those devices authenticate and encrypt your data in transit. A MAC address is an identifier consisting of numbers and letters associated with the network card in your devices. It identifies your network card on the network, and thereby your device that contains the network card. Some companies use weak mechanisms like the MAC address or some other easily obtainable piece of information to identify a device.
Pentesters and attackers have ways of obtaining the MAC address on the most common protocol used for network communications — IPV4. On the newer version, IPv6, the protocol changed, and your MAC address appears in the clear in traffic sent over the network. Even if your IOT device leverages encryption on an IPv6 network, an attacker can easily spoof an IOT device using a MAC address for identification. An intermediary could pretend to have your MAC address and communicate with the SAAS provider and then imitate SAAS provider communications to your device to intercept the traffic. The attacker may be able to steal your encryption keys in the process as well as any data.
Cellular communications
What about cellular communications? Cellular communications typically use a protocol called SS7 (Signaling System Number 7). Some companies are updating their systems to flow over traditional networking protocols like IPv4 and TCP used when you are browsing the web from your computer. If your voice and data communications from your cellphone are not encrypted, anyone with access to those SS7 or other cellular networks could listen to your communications.
In theory, it’s harder for people to get access to those SS7 and other telecom networks, so your communications are harder to tap. However, it can happen, and far too many people underestimate the reach of governments, spies, and organized crime. Governments and organized crime groups may offer insiders a significant amount of money to capture sensitive data. More recently, a report talks about how a vulnerability on phones was leveraged to access SS7 networks.
The first step to securing your communications involves your cellular provider. When is the last time a company vetted their cellular provider? Did you ask them how they secure their networks, vet employees, segregate duties, and separate employees from cellular communications? The other problem is when you travel to other countries or areas where the cell provider partners with other companies to provide service? Then you are at the mercy of whatever network your phone is connected. You can turn off roaming on your phone, but that limits communications. I have heard FBI agents and security professionals say they use burner phones in other countries. These are phones you use once and throw away. Also, they may use alternate forms of communication.
The next thing you need to worry about is your device. Who manufactured your phone? What hardware and software did they put into it? If you use the phone and the default software to send messages, is it encrypted? What vulnerabilities could expose your communications?
The hardware and software on your device provide the encryption on cellular networks. Ideally, that hardware or software securely encrypts your text messages and calls when sending them over the network. Otherwise, anyone in the cellular network can read them. Insiders at mobile phone companies have been persuaded to collect traffic. Additionally, people can buy cell towers and other devices to intercept and listen in on traffic. If you connect your device to a Wi-Fi network, all the prior information about Wi-Fi applies for any data transmitted via that network.
A mechanism needs to exist for each device involved in the communication to obtain the appropriate keys to perform encryption. Software on each device needs to be able to handle this key exchange securely. That’s why if you send an iMessage between two Apple devices, the traffic is encrypted. If you send a standard text message from an iPhone to an Android device, Apple doesn’t have control of the Android software and sends the message in cleartext.
Applications like Signal are designed to send and receive communications that are encrypted and secure, regardless of what phone or network you are using. Bruce Schneier is a renowned encryption expert endorses this product, and it is in use by multiple governments. Anyone can download this application and use it for free. Both people involved in the communication needs to use it for end-to-end encryption.
Algorithms
Just as with encryption at rest, the encryption process needs to use a secure algorithm. For example, when you are using your web browser to visit a web site, you may see HTTPS:// in the address bar. For example, click on this link and look at the address in your browser.
When you see that prefix on an address, it means that the browser is encrypting the traffic it is sending to the webserver. However, seeing HTTPS in the web browser address bar doesn’t tell you the version of the protocol used to encrypt the data. Websites used to use a protocol called SSL (Secure Socket Layer), and different versions of SSL exist. SSL evolved into a new standard. Now websites should be using TLS (Transport Layer Security) and preferably the most recent version of TLS (currently 1.2). Older versions of SSL and TLS are subject to attacks like HeartBleed, Beast, and Poodle which disclose data. Major browsers are going to stop allowing older versions of TLS in 2020. TLS 1.3 is in development at this time and promises security improvements.
When you visit a web site that is serving an HTTPS page, your browser negotiates with the webserver to find a compatible encryption protocol and version. Attackers figured out how to manipulate this process in various ways to trick browsers into using an older protocol when the configuration on a web server does not correctly implement encryption. Once the communications are flowing over an older protocol, attackers can use whatever attacks exist for that protocol. In most browsers and on some servers, you can change the settings to disallow old encryption protocols.
SSL originally came about when e-commerce was new, and people were looking for a way to trust vendors and perform transactions online. When you want to encrypt traffic on your website, you need to obtain something called a TLS or SSL certificate from a third party. The certificate from the third party, known as a certificate authority (CA) is supposed to validate that your website certificate and the connection is legitimate. It also provides encryption in transit.
You’ll have to go through various steps to get and install a certificate. In the past, those steps involved a lot of manual actions. This request process includes generating a private key which needs to be maintained securely. Then you exchange information with a public certificate authority to get a public certificate validated by them, and you install that on your web server. People can look at your certificate information when they go to your website and see the vendor who issued the certificate.
Anyone who has had the pleasure of manually configuring SSL and TLS certificates can tell you it is tedious, even more so in the past. Over the years, some companies like Digicert have simplified the process, but it still takes several steps. I used to write blog posts on how to get and install TLS certificates for myself to remember the steps since I only did it once or twice per year.
After you get a certificate and install it, you have to remember to renew it when it expires. Companies have experienced incidents where they spent hours trying to figure out why systems were suddenly failing, only to find out hours later it was due to an expired SSL or TLS certificate. In some cases, the company lost thousands or millions of dollars while systems were down. Make sure you monitor certificates for expirations or automate the process.
Sometimes developers don’t use TLS or SSL for encryption in transit. They instead encrypt data with algorithms intended for encryption at rest. Then the encrypted data is sent via an unencrypted network channel, but the data inside the payload of the packets is encrypted. Using protocols not designed for encryption in transit may not be as efficient, and it also lacks some of the server validation provided by TLS. How do you know you are sending the data to the correct recipient? As mentioned already, you also need to understand how much of each packet is encrypted.
The other problem is that this typically requires the same key to reside on both sides of the communication to perform symmetric encryption. How will the key get to both ends of the communication and where and how will it be stored? That’s the complication. TLS solves this with a combination of public and private keys for asymmetric encryption to transport a shared key used for symmetric encryption. I explained those types of encryption in my last post. Protocols like TLS facilitate key exchange because cryptographers designed them for encryption in transit.
Additional details exist surrounding the proper implementation of encryption so you’ll want to make sure your developers receive proper training. Different software libraries manage encryption in transit, and some are more secure than others. As a result of the rash of different SSL vulnerabilities like Heartbleed, and Poodle, AWS created their own TLS library called S2N to use on their platform. It’s open-source which allows anyone can inspect and use the code.
When using cloud platforms like AWS, Azure, and Google, some of the details of encryption can be handed off to the cloud provider. At this time, you can request a TLS certificate from AWS directly and associate it with AWS resources. It is possible to automate the entire process though it takes a bit of effort. Once you have a certificate installed, it renews automatically. Azure integrates with two external vendors — Digicert and GlobalSign. Google has managed certificates in pre-release. You can also manage the process of getting a certificate yourself on any of these platforms.
On the one hand, having the cloud provider manage your TLS certificate potentially exposes your private key to that vendor. This point is where properly, vetting becomes essential. Ensure that you understand how the vendor manages private keys and that you can trust the vendor. Review how they hire, monitor, and vet employees and what access they receive. Determine who has access to the keys by reviewing third-party audits.
On the other hand, you may find the cloud provider does a better job of managing keys than you. They may automate everything such that no human ever has access to the keys. The automation and standardization offer security benefits as well. I perform cloud penetration tests. When I discover a company is using the AWS content delivery network (CDN) called CloudFront with an AWS TLS certificate, I know testing likely won’t turn up any significant problems. I still check, but since the configuration is automated and standardized, it’s probably ok. I do find companies aren’t enforcing the use of TLS 1.2 in the CDN configuration, but that part of the configuration is the customer’s responsibility. I am sure AWS will soon update the default to TLS 1.2 as browsers stop supporting TLS 1.1.
Termination
When considering network in transit understand where the encryption terminates. For example, a load balancer in front of a number of web servers will try to distribute the load to optimize your website performance. Sometimes the encryption terminates at the load balancer. The traffic between the load balancer and the web server is unencrypted. Is that ok? There are legitimate reasons for doing this, however now anyone who can access the traffic between your load balancer and the web server can sniff and view the traffic. How much do you trust your cloud provider? Have you asked them who can access that data and how?
Browser >[encrypted] > Load Balancer > [unencrypted] > Webserver
I explained what a three-tier architecture is and why in other blog posts. What about traffic from your webserver to your application server, and your application server to your database server. Should that be encrypted? Who might access it on the network? How about network traffic between APIs (application programming interfaces) and containers? What about Serverless functions that run without a developer configuring any machine or operating system and run software that connects to other resources on the network? Which data is encrypted or not as data flows through your networks?
Any time data is sent from one device or compute resource to another, and it may be exposed. Organizations first need to understand what data they have, where it is stored, and where it flows as I explained previously. Remember to protect voice and IOT communications as well as traditional networking between computers. Remember the traffic between systems within your internal network between servers, network devices, databases, functions, and containers. Try to encrypt as much as possible. The risk associated with plaintext data depends on the sensitivity and value of the data. Ensure your teams implement encryption in transit everywhere possible and according to best practices to prevent interception, downgraded encryption algorithms, and compromised encryption keys.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2019
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
