‍

‍

Sensitive Data Exposure

When we hear news about data breaches, it’s almost always sensitive data exposure! Personal information, credit cards numbers, emails, passwords, health records, etc., are extremely valuable for attackers because it can be sold for lots of money in the black market/deep web. Attackers can use that information to commit frauds, open bank accounts, elaborate social engineering, among others. The impact can also be massive for companies who suffer data leaks, as fines are applied (GDPR), loss of trust by clients and reputation drops. This type of attack has multiple consequences for both people and companies, so be extremely careful!

‍

How does the attack work?

According to Trustwave, in 2020 54% of the attacks came from internal networks and for Utilities, 83% of attacks from corporate/internal network. Many companies believe internal website, don’t require HTTPS considering no employee will cause harm. While companies should expect this to be true, we know it isn’t always the case. Employees always have credentials to access network, now imagine having an HR website that uses HTTP to transfer information. By evaluating the traffic as a man-in-the-middle one is able capture credentials in clear text (if not properly handled) and perform unimaginable things, as popular saying: the sky is the limit!

‍

‍

How can we protect ourselves?

There are some measures that can help protect our clients from having their client’s sensitive data exposed, such as:

• Coding best practices: obviously this is the first item on our list, right? As we have tons of lines of code, the chance to have a major vulnerability increases. That’s why developers must be aware of coding best practices. While programming, they can apply those practices to mitigate risks right in the root cause.
• Don’t store credentials on source code: In 2017, Uber suffered a popular data leak. Do you know why? They stored a credential on source code on GitHub! Besides that, Uber didn’t use multifactor authentication on its GitHub account! And what happened? A hacker accessed one of the Uber’s AWS S3 buckets and collected tons of data. If you’re curious about this, you can read the full news here.
• Cryptography: Always apply cryptography while using sensitive data at rest/transit with secure protocols such as TLS with perfect forward secrecy (PFS) ciphers, among others. Also, you can use some hash functions with salt to store passwords for example are: Argon2, scrypt, bcrypt or PBKDF2. DO NOT use deprecated algorithms such as SHA1, MD5, 3DES, etc. Also, avoid trying to reinvent the wheel to create some new security algorithm, existing ones are fully and extensively tested by mathematicians, computers, and some ethical hackers.
• Salt is random data applied into a hash function of a password for example to increase its security against dictionary attacks and brute-forcing. Imagine the following: Pedro and Maria have the same password “admin123”, the hash function of this password will be the same and it’s easily “crackable”. If the application generates a salt for each of them when storing it, the output (hash) will be completely different for both and difficult to crack!
  ‍

‍

• Least privilege: According to NIST, the principle of least privilege is “that users and programs should only have the necessary privileges to complete their tasks.” This topic is self-explanatory, right? You just have the least privilege to do something, if you really need to do something. Example? A regular user at Celfocus doesn’t need root permissions to execute or install files on production machines.
• Threat modelling: According to RedHat, using a threat model you can have a good preventive mechanism to deal and fix vulnerabilities, “Threat modelling is a systematic approach for developing resilient software.” By doing this, you can save time and effort with vulnerabilities that may appear during the application's production lifecycle.
• HSTS: Do you know what’s HSTS? It stands for HTTP Strict Transport Security, and it’s a policy mechanism that tells browsers that the website can only be accessed using HTTPS. This means that the first time that one of your clients connects to your web site it will receive this note that your site will always use HTTPS, so that Downgrade attacks to HTTP stop working. Basically, your site will share this information in a Response Header: Strict-Transport-Security: max-age=<expire-time>; preload

For more details you access this link from Mozilla. If you want to test your website HSTS Header, you can go to HSTSPreload and try it for free!

You can see below what our own site is sending to our customers:

‍

‍

• Disable caching: According to OWASP, it’s recommended to disable caching on forms that may contain sensitive data to end-users. One way to prevent caching is using the header below, it prevents critical information being stored on the disk. One example of attack for cache control iss the Web Cache Poisoning, which you can find more details here.
  Cache-Control: no-cache, no-store
  Expires: 0
  Pragma: no-cache
  
  Because this header provides multiple configurations, you can access this link so you can learn more about each one of them.
• Self-reflection: Stop and think, do you really need to store that data? Are you sure? If not, do not store sensitive data unnecessarily, it’s less risky. “Data that is not retained cannot be stolen.”

‍

Conclusion

Sensitive data exposure appears as the third type of vulnerability in the OWASP TOP 10. It deals with the way we store and manipulate sensitive data in transit and at rest. By implementing a simple header such as HSTS we can mitigate some risks while browsing a website. Hashing passwords with salt (just to enforce, I said WITH salt) can also help against password cracking, keep that in mind! Finally, don’t forget to implement SSL/TLS, aka HTTPS, to protect against eavesdroppers. Your personal information can be valuable for hackers, don’t forget that! The less they know about you, less they can do!

‍

Article by David Santos Silva.