• Nth Generation

Encryption is so easy, that a caveman could do it!

Updated: Jun 18


I recently worked on a penetration test and discovered that a depreciated encryption method was being used. I often find this in MOST of my penetration tests that are usually haphazardly put in place such as:

  • Manufacturer certificates are being used displaying the "Not Secure" logo

  • Old encryption algorithms are being used

  • Management consoles with bad/old certificates

  • Sending files with deprecated encryption ciphers

  • Should you use 128/256-bit or 1024/2048-bit encryption?

…and the list could keep going! The core of the problem is that encryption is hard, and you must understand it to use it properly. If I had to put a complexity level on this issue, I would say it’s harder than walking, but not as complicated as flying a space shuttle. It is closer to walking than the space shuttle. But you do need to understand the rules of the road, and this is where I want to help. Here are some basic steps you can take when working with encryption:

Step One – Networking encryption is missing.

First, you must realize that in today's world, all connectivity in transit should be encrypted. There should never be anything sent in the clear. You can start with DNS over TCP, up to Active Directory LDAP on TCP ports 389 over to LDAPS on ports 636, and beyond. No matter what you are transferring over the wire, it should be encrypted, and the OSI model has a helper called TLS. You can put TLS on everything.

Most companies don’t have a working knowledge of how each crown jewel system communicates, and if those communications are encrypted, or to what level. I often see important data such as Structured Query Language (SQL) connections authenticating in the clear. I also see NT File System (NTFS) communications out in the clear transferring files. Server Message Block (SMB) is often in the clear which does many things for a Windows network. Each of these services are highly hackable, and easily compromised using Man in the Middle (MiTM) techniques. Server Network Management Protocol (SNMP) is often unencrypted, iLO and iDRAC are unencrypted, and the list goes on.

Free tools to compromise and MiTM these open communications are:

  1. Responder -- https://github.com/SpiderLabs/Responder

  2. Metasploit -- https://www.metasploit.com/

  3. Varonis -- Commercial tool to find those crown jewels.

Step Two – File encryption is lacking.

Next, you need to sit back and understand that files and databases should be encrypted at rest. Is that encryption taking place on your Storage Area Network (SAN), or is it taking place at a disk-level? No matter what you decide, it needs to be encrypted, and that encryption should be done automatically.

I often talk to customers about SAN encryption. Most SAN systems have this functionality and should be easy to implement. Ask your SAN vendor or manufacturer how to accomplish this task and get it done. If you want to encrypt desktops/laptops/servers think about Bitlocker on Windows. This technology has come a long way, and it's integrated into Active Directory to store the encryption keys and manage the deployment through Group Policy Objects (GPO). Get it done!

Tools:

Step Three – Understand that encryption ciphers have an “end-of-life".

It’s true! When you deploy technology, you cannot rely on old encryption ciphers to get the job done. Just because you used the Data Encryption Standard (DES) back in the day, doesn't mean you can use it today. Here is a list of used ciphers that are broken, but are probably still in use:

  1. DES – Data Encryption Standard broke in 1999 a. Used in NTLMv1 and MSChapv2

  2. SHA1 – Secure Hash Algorithm 1 was broken in 2011 a. Used in Asymmetric Encryption and Symmetric Encryption

  3. RC4 – Rivest Cipher 4 was broken in 2015 a. Used in Asymmetric Encryption and Symmetric Encryption

I mention these three because I find them everywhere. Websites use SHA1 and RC4 in almost every penetration test I perform. These often include SSL versions 1, 2, and 3, as well as TLS 1.0 and TLS 1.1.

Just recently, I found SHA1 in a major bank's deployment of merchant services systems. Meaning when a customer scans checks and inputs that data into the bank's merchant system, the data is transferred using SHA1.

This week I had my CPA finish up my taxes, and they sent me the files in RC4 128-bit encryption which is old and compromised. DES is allowed almost everywhere, and I see DES encrypting data on corporate systems including banking software. My advice is to keep up with what's happening in cryptology, and if you need help, email your vCISO!

Tools to use to navigate these risks:

  1. vCISO – Virtual Chief Information Security Officer. An expert who keeps up to date on security design and has the experience to identify bad crypto design and deployments.

  2. CSO Online – I find many notices on end-of-life encryption on this website. This is just one of many tools you can access online.

  3. Education – Go back to school! Things may be different since you went to college. Maybe invest into yourself and your career and go to SANS Institute and take that class you always wanted to take. I guarantee they will mention something about crypto.

Step Four – Put certificates to good use.

In every penetration test I perform I see certificate issues such as:

  • Management portals with default certificates are being used

  • Websites without HTTP Strict Transport Security (HSTS) are being used

  • Certificates with weak ciphers and depreciated crypto algorithm

  • Expired certificates, or certificates about to expire without a plan on recertification.

  • Confusion between an internal Certificate Authority (CA) and an external CA.

The biggest fail I see when encrypting websites are SSL versions 1, 2, and 3. Many companies don't realize that SSL is dead. If you are encrypting web traffic using SSL, this is a mistake. You should be using TLS for everything, and that should be TLS 1.2 or higher. The Heartbleed security bug first exposed both SSL and TLS as broken in the implementation of OpenSSL, and later all of SSL was depreciated. If you are deploying anything using a webserver you need to stop and ask yourself, “Can it run TLS 1.2 or higher?”

You may not know this, but you can deploy your own CA for free. If you did deploy one in your enterprise, you could make your own certificates and use your CA to authorize everything in your domain inside your company.

Things you could use your CA to do:

  1. Make certificates for all network port connections using 802.1X a. Benefit: Nobody can connect to your network port without a cert. No vendor can come into your conference room and just plug in and get access. b. Benefit: Expire vendor certificates so they cannot reconnect to the network after their job is done.

  2. CA cert all your management portals using your CA a. Benefit: No more default certificates installed on your management portals, and MiTM gets harder. b. Benefit: CIS top 20 best practice to remove default configurations.

  3. Use certificates to secure your intranet portal a. Benefit: Now all internal documents, chats, files and data traveling around that portal is secured at managed level, not default.

  4. Certificates to manage Virtual Private Networking (VPN) a. Benefit: Only allow trusted certificates to connect to your VPN. b. Benefit: Expire certificates for vendors at a preset date and time.

I know there are more, but you’ll see what happens! Once you start securing your connections, clouds, management portals with these certs you can start controlling access and data.

Step Five – Get in front of the problem.

Security should be your first priority! Get your local cybersecurity expert to join your team and help you with that deployment. Don't go into a new deployment telling your team you want cybersecurity and implement something that is already cryptographically broken. Instead, put your vCISO's expertise to work and have them look at the crypto and ensure you are using the best tools to secure your data. Crypto isn't hard; it just might not be what you do best. Get someone on your team that can help you with that goal.

Conclusion

Encryption can be hard, but it doesn’t need to be that way. Get some help when you are in a crypto need and use these ideas I have laid out as an action plan to move your encrypted communications forward. The CIS top 20 has a section on encryption at rest, and encryption in transit. Together with that documentation, and my suggestions you will be well on your way to make your communications secure.As a Cybersecurity Consultant, I hope this information will help your organization manage encryption problems, and secure your data more effectively. Encryption can seem daunting, but with the right algorithms, technology and consultants your encryption story can be a success.

Jerry Craft Senior Security Consultant & CISO

For more information about Nth Generation's vCISO services visit: https://www.security.nth.com/vciso

Nth_Generation_Logo_Color_White-Text.png

© Nth Generation, 2014-2020. All Rights Reserved. Privacy Policy | Legal Terms