Two days ago an example of bad code popped up in the security community when a programmer was reviewing 7Zip's code to see if it would suit his needs. 7Zip is a free open source software for compression and packing/unpacking of ZIP and GZIP formats.
While reviewing the open source code he bumped into a weak random generator that generates an IV used to encrypt files. By doing so it lowers the effectiveness of the encryption algorithm significantly which could result in an easier path to decrypt the secured files.
IV or Initialisation vector is used to kick start the encryption process and it needs to be random and unpredictable. In this case the IV was limited to 8 instead of the 16 bytes normally required for strong encryption (AES).
This bad coding was discovered because the source of the program was readily available for anyone, so called open source. You could argue that a company for profit would not dare to put this type of ‘bad’ coding out let alone disclose its sources. This in my humble opinion only masks the real problem. 7zip is used in various open and closed source (commercial) software products to decrypt files and inspect them. 7zip could be embedded for example in your Antivirus scanner or other product, potentially putting these software products and thus your data at risk.
NPM Hijacking
Imagine you're the owner of a nice piece of code to solve an issue, and published this online to help out others, but you don't have any time to invest in maintaining the code. What would you do? Delete your code while knowing many others rely on your work? Or would you simply hand it over to someone else that seems trustworthy? In this case, the owner and maintainer dominictarr went for the last option, he has written a piece of code used by many NPM users.
Unfortunately, the new maintainer of the code decided to lock dominic out from his code repository (which is understandable, but the way could be debatable), to then proceed by injecting code with unclear and malicious intentions, and removing it a couple of days later.
To check if you are affected by this piece of code a user suggested to run:
So what does this mean to you?
The primary learning from this (and previous) incidents is that it is not the bad coding examples itself that are the root cause of such problems, but the lack of awareness about the existence of bad code and that you could be using subject to this malicious code from others inside your products without even knowing it.
Bad code such as these could be just sitting in your application from the get-go which you might have simply missed when reviewing the source code before deciding to use it in your own or already launched product.
Here's something to be aware of and a few misconceptions when using what you perceive as ‘good open-source code’ that could potentially ‘turn’ malicious:
“I'm using open source code in my products. So what do I do about this issue?”
- Code reviews should be part of the process for anyone developing their own software. This should always include a review of pieces of code written by others that your software will rely on. Using open source is great, because it gives you the possibility to at least review the code and determine if it suits your needs, test the code by reviewing or even rewriting pieces of code. Making sure it matches with your own information security guidelines.
- Mirror repositories and implement version pinning to secure yourself from (un)intentional code injections like these when you build your new version and deploy it into 'the wild'. Manual version pinning might seem tempting as it has almost no additional costs, yet this could become quite complex to maintain and could put you at even greater risk.
- Maintain a strong relation with your suppliers that are part of your core processes. This relates to either customer-vendor or customer-open source community engagement. As the above NPM case demonstrated, a lack of having a financial interest for the open source developer may lead the original maintainer to leave this piece of code ‘unmaintained’ while you are still relying on it. Motivating someone to take a critical look at their own (and open source) coding helps improve the overall quality and might ease development for your own products by having the maintainer adding logic or closing important patch holes.
“I'm using closed software so I am safe right?”
Unfortunately you are not.
You only have someone else to try and blame it on. Closed source software does not provide you with any tools to review the code yourself. In the meanwhile your product could still be out there and have been breached because of this third party code, leaking valuable (and even sensitive) customer data. Having a company creating software for you does not relieve you from any (financial) damage that might occur because of malicious code. You are the data processor which, this means you cannot hide behind your supplier in this scenario.
With open source coding you can decide to develop your own patch to mitigate a certain risk, without having to wait till a new patch is released or having to accept risk in the meantime.
“I'm using cloud products only, so there's nothing for me to worry about…”
Did you know that most Cloud and SaaS products are built on open source and closed source tooling contains thousands lines of code..? This means a breach could be happening in these situations.
The ‘good thing’ here is you are definitely not the only one who will be affected. When having the data processor agreement in place between you and your cloud/SaaS provider, you are relieved from a certain level of responsibility and some financial impact that may follow from this malicious code. Yet you are still the party leaking your customers data from an end-user perspective. So when not clearly communicating the issue in time with your customers, this could backfire on you in the end, damaging your brand.
In other words:
Accept and prepare for (unintentional) bad code, hacks, social engineering, or dissatisfied (ex-) employees. One of these scenarios might occur at some point. Mitigate by limiting the risk, clearly plan your communication and define steps to secure forensic data.
It all starts with awareness. So let us help you to be more aware and prepared. Schedule a session with us or register for one of our Security Awareness trainings, an IT Security Assessment or Nomios Security Cleanups.
