Implementations: The Achilles heel in cybersecurity

Heartbleed

There are many new technologies, controls, mechanisms, modules, libraries for protecting and securing assets and information. Usually these new technologies were created and developed by people with good skills in the field, however, one of the main problems is the implementation phase.

Believe it or not, most of the vulnerabilities, either published or zero-day, exist because of a bad or terrible implementation of something that is secure in escense.

Think about cryptography. In general, cryptographic standard algorithms are approved and validated by many cryptographers around the world but when it comes the implementation phase, the standard or algorithm is implemented by a group of peole working at the same company or sometimes by only one developer with limited training in security and/or cryptography.

One of these examples is WEP Security Protocol for Wireless communications. It has different vulnerabilities but particularly the vulnerability of the key stream is a consequence of a weakness in the implementation of the RC4 stream cipher, not the RC4 algorithm by itself.

The authentication mechanisms are other examples. As pentester and security analyst I have tested several different applications where the developers do not understand well enough the framework or the standard they are implementing and ended up exposing tokens, passwords or key information for resetting or, worst case, recovering the credentials (meaning they stored the information in a reversible way) or having other critical bugs on the authentication module.

Heartbleed is one more example. The OpenSSL library, used by thousands of products nowadays, in 2014 a serious vulnerability was detected in it which exposed, bit by bit, the secret keys used for the cyprographic operations regardless of whether those keys were to be used by RSA algorihtm, Elliptic Curves, Diffie-Hellman. The encryption algorithm was not the vulnerable element, it was that “something”, the library, was exposing the cryptographic keys. Obviously if you have the keys, you can encrypt and decrypt whatever you want anytime within the communication.

Recommendations:

The principal recommendation is to always analyze and validate any implemention involving any kind of physical, digital or logical security, by specialized security people with proper training and experience. They are aware of vulnerabilities, common mistakes, key points to take care of with such technology, scheme or protocol and this process could prevent a future exposure or compromise of the system and also its liabilities, penalties and reputational damage (which is very hard to recover from).

Other recommendations include:

  • Always review the security papers, documentation and best practices from the vendor or technology provider. They know how their technology must be used and implemented. Do not trust in a technology if it doesn’t have security documentation.
  • Always search for any vulnerability published in regard of the technology. For this purpose, here you have a few useful links:
  • Do a quick search on google using this sentence: [The technology] security issues. Review the first results to be aware of the most important security flaws in the technology you are about to implement.
  • Configure appropriately the logs. This is imperative for detecting any deviation, compromise or attack attempts to your infrastructure through the technology. Also do not forget to review those log files frequently, everyday if its possible.
  • Understand the protocols and other technologies around what you are going to implement. This will help you to have a clear picture of the data flow, components, actors, user-agents and any other element that your new module will touch during its operation. And this is important to know the possible attack vectors and to be preared with the corresponding contermeasures.
  • For the authentication mechanisms, you can use Multi Factor Authentication (MFA) or Authentication Services like Facebook Login or Google Sign-In, well implemented of course. Because of the steps they involve usually the libraries and services around these methodologies do a quick test and verification of everything and if it’s not well implemented it simply doesn’t work.

If hope you find this post useful for your new projects and feel free to post below any feedback you have in mind.