Urgent and Critical: Remote Code Execution in Apache Log4j needs immediate upgrade

Updated: 31 Dec 2021

5 minute read

This is a call to arms. All enterprise software maintainers of software using Java libraries need to check if their systems are affected by the newly discovered Apache Log4j vulnerability since its announcement on Dec 9, 2021. Since then several security vulnerabilities in the wild have been discovered.

CVE-2021-44832

Vulnerability Score: 6.6 (CVSS: 3.0 / AV: N / AC: L / PR: N / UI: N / S: C / C: H / I: H / A: H)
Platform: Java
Component: org.apache.logging.log4j:log4j-core
Affected versions: 2.0-alpha7 to 2.17.0 inclusive, except 2.3.2 and 2.12.4.
Fixed in version: 2.17.1

CVE-2021-44228

Vulnerability Score: 10.0 (CVSS: 3.0 / AV: N / AC: L / PR: N / UI: N / S: C / C: H / I: H / A: H)
Platform: Java
Component: org.apache.logging.log4j:log4j-core
Affected versions: all versions before 2.14.1, inclusive
Fixed in version: 2.15.0 but upgrade to 2.17.0 is required because of CVE-2021-45105

CVE-2021-45046

Vulnerability Score: 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) (updated 18/12/2021)
Platform: Java
Component: org.apache.logging.log4j:log4j-core
Affected versions: all versions up to 2.15.0, excluding 2.12.2
Fixed in version: 2.16.0 but upgrade to 2.17.0 is required because of CVE-2021-45105

CVE-2021-45105

Vulnerability Score: 7.5 (CVSS: 3.0 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
Platform: Java
Component: org.apache.logging.log4j:log4j-core
Affected versions: all versions from 2.0-beta9 to 2.16.0, inclusive
Fixed in version: 2.17.0


Which systems does this affect?

Apache Log4j is probably the most common library used for logging in the Java ecosystem with over 400,000 downloads from its GitHub project. It is used in Java applications to log system and user activities, so there’s a serious possibility your Java software is using it. It is used, internally, by many other Apache frameworks such as Apache Flink, Apache Druid, Apache Flume, Apache Solr, Apache Flink, Apache Kafka, Apache Dubbo. It is also actively used in many other open source projects, like Redis, ElasticSearch, Elastic Logstash, Ghidra and many others.

Among all these open source components, one needs a special mention: Apache Struts. Yes, it is actively using Log4j. There exists a potential to trigger high-impact attacks against a wide variety of apps and services, similar to the scale witnessed in 2017. At that time, due to the vulnerability exploited in the Equifax megahack, 140 million customers’ data in North America and UK were breached. The latest version of Apache Struts, 2.5.28, uses by default Log4j version 2.12.21, which is vulnerable to this attack. This time, however, the scope for damage could be even wider, as Apache Struts is one of many Apache frameworks that use Log4j. 

The Java ecosystem is in very broad use in enterprise systems and web apps and many mainstream services are likely to be vulnerable. Therefore, software maintainers and developers should pay close attention to this vulnerability. 

This has been preliminary filed as CVE-2021-44228, and a subsequent vulnerability was also flagged, now filed under CVE-2021-45046.


Why does this threat demand an urgent patch?

This vulnerability allows the attacker to remotely execute code on your system, with the ability to gain complete control of the underlying servers.

This is actively exploited on the internet now and there is already a simple POC (proof of concept) available on the internet that explains how to do it. 

From https://www.wired.com/story/log4j-flaw-hacking-internet/:

“All an attacker has to do to exploit the flaw is strategically send a malicious code string that eventually gets logged by Log4j version 2.0 or higher. The exploit lets an attacker load arbitrary Java code on a server, allowing them to take control.  […]Minecraft screenshots circulating on forums appear to show players exploiting the vulnerability from the Minecraft chat function. On Friday, some Twitter users began changing their display names to code strings that could trigger the exploit. Another user changed his iPhone name to do the same and submitted the finding to Apple. Researchers told WIRED that the approach could also potentially work using email.”

If you maintain an enterprise system using Java software, you would need to update all affected applications, whether they are maintained directly by your organisation or your supplier organisation.

Within 2 days of the 2017 vulnerability being announced, several systems around the world were breached by exploiting the software weakness.  We do not want more cyber breaches of such scale and all need to react quickly to patch vulnerable systems.


How can I check if my system is affected?

If you maintain any software using Java libraries, check if you are using Apache Log4j.  Meterian BOSS scanner can be used to scan your codebase to identify all dependent software libraries.  If it is using Log4j, it will find the affected vulnerable versions and provide more information on how to mitigate this risk.

If you are a developer and you have access to the code, you can simply execute this command from your terminal:

$ mvn dependency:tree | grep log4j-core | grep compile
[INFO] +- org.apache.logging.log4j:log4j-core:jar:2.12.1:compile

If you see any response lines, check the version: if it’s below 2.16.0 (as in the above example) you may be affected.


My system has the vulnerable log4j library — how can I mitigate the risk?

There is a patched version of the library that resolves the issue.  Released by Apache Software Foundation, the solution is to immediately upgrade log4j to the latest log4j version 2.16.0.  The fixed version is available via Maven

If the library is coming from a transitive dependency (it’s not one of your direct dependencies, but a dependency of them) you can just include an override in your root pom.xml (or where applicable) and retest that it’s not there anymore with the command shown before:

    <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-core</artifactId>
        <version>2.16.0</version>
    </dependency>

A set of mitigations, specific to the version you are using, are also available on the Apache Log4j website. The Apache Struts team provided specific advice on how to handle the issue.

If you are using an external product that runs with Java, you can also protect your systems by launching the JVM with this special parameter:

-Dlog4j2.formatMsgNoLookups=true

This is useful for tools like Jenkins, where you have control of the installation but you do not have control of the code, but please note that this does not protect against the latest CVE.


What can I do to proactively protect from such vulnerabilities?

We always suggest you regularly scan your software code bases. 


Are Meterian applications affected by the log4j vulnerability?

No. We have verified our applications and none are using log4j.  We maintain a continuous monitoring system to ensure our development operations are up to date with the latest known vulnerabilities in software components.   

Related references

Urgent and Critical: Remote Code Execution in Apache Log4j needs immediate upgrade

Is it a good idea to have vulnerable opensource components in my application?

This may seem to be a trivial question or something more like a joke. Why would one keep a vulnerable component in his tech stack? That said, from time to time, we meet people who simply answer “well, this is not an issue”.

Surprisingly, some are part of the technology leadership, or even the security chapter. Often their answer is usually along the lines of: “Well, you should know there’s a difference between vulnerable and exploitable: the fact that a component is vulnerable does not automatically mean that it’s possible to exploit it”.

There’s a difference between vulnerable and exploitable…”

Yes, that is perfectly correct. We know it, as we do our own analysis as part of our routine.

Do you know what the problem is? You are probably not involved in the project and you are not a developer. I can bet that you are not continuously monitoring and assessing the code that your developers are daily pushing. Are you? Because at the speed innovation is going these days, there’s no guarantee that even tomorrow one of your developers will push a line of code that will enable the exploit. Yes, these exploits may be quite complex but also may be very easy to enable. It’s possible that an application including a vulnerable component is not exploitable today, but what about tomorrow? Your software is changing continuously.

“…but developers push new code daily, software is changing continuously.”

Do you know why Struts in Equifax was hacked? Because of a log message. A simple log message that echoes the content of a header, only that such content contained OGNL code, crafted by an attacker.

Do you know how jackson-databind remote code execution can be exploited? It’s just one configuration property away: enable polymorphic JSON deserialization and you are on.An apparently innocuous JSON message can feed now code to your server to be remotely executed.

So, in your position, I would not sit too complacent on the fact that you have vulnerable components that today cannot be exploited because of the current application code. That code changes continuously, daily, and unless you have in place an incredibly strict validation process, you are at risk, and you are putting your customers at risk. I do not believe such risk is acceptable.

“Most of the times the fix is just one patch away.”

Furthermore, most of the time fixes are just a patch away. We are not talking about a four-week refactoring session, but probably more like a one minute change and a run of the normal test regression suites, And if you had a system in place to continuously check your components against known vulnerabilities, you would have caught such an issue and patched it a while ago.

This is not a commercial plug for Meterian. Yes. this is our bread and butter, and we think we provide tons of value for the money. But some of our competitors do that as well. Maybe you are already using one of them in your company, and that’s great. Plug that in and set your customers free from this risk.

Nobody likes to be hacked.

Is it a good idea to have vulnerable opensource components in my application?

Meterian Spotlight: A quick look at Honda’s open source software supply chain

Photo of front view of white honda car with headlights on at dusk
Photo by Douglas Bagg on Unsplash

Earlier this month, Honda announced it has suffered a cyber attack on its network.  It was affecting its operations around the world: their manufacturing plants have shut down, customer service work has been forced to stop, and their internal communication systems were affected.  Additionally, systems outside of Japan were affected due to a “virus” that spread through the network.  No further details on the root cause of the attack yet, but at Meterian we have done a quick surface scan of their websites honda.com and www.honda.co.uk.  Similar issues were found on both.  We’ll focus our blog post on Honda UK’s site.

From the summary report above, we see their website’s security scored 0 From the summary report above, we see their website’s security scored 0 out of 100 because it has 19 vulnerabilities, including jquery 1.4.2 which is vulnerable and outdated.  Honda.co.uk’s basic cybersecurity hygiene could be improved by making sure to not launch the website with vulnerable and old components — jquery 1.4.2 is from 2010.  Similar issues were found after analysing honda.com.

Although we don’t know if these two components’ weaknesses contributed to the hack of Honda’s systems, while investigations are private, we know every software application is part of a company’s digital estate.  Altogether, front end systems (like websites and mobile apps) and back end systems (like databases, servers, APIs that store or access a company’s customer data, intellectual property — the real business logic of the services) make up the digital estate.  Any security hole is a vulnerable entry point for cyber criminals to exploit and gain unauthorized access to information or systems to cause damage.  Last year in 2019, over 40GB of Honda’s data were breached, exposing details about internal systems and devices on their network. Cyber criminals have strategically targeted Honda again.  

There are many strategies to build up an organization’s cyber resilience, including cybersecurity cultural awareness among employees and operational and software development best practices.  Meterian helps customers reduce the time to detect, mitigate and resolve issues in applications’ software supply chain. These known vulnerabilities are easy to fix with Meterian because:

1. Safe coding practices can be easily adopted into the software development lifecycle  

2. Automated controls fit directly into the software development workflow for continuous monitoring

3. Meterian can be set up to run continuously and prevent such vulnerabilities from going live 

Most importantly, developers are empowered to recognise and address the issue early with information at their fingertips.  As stewards of software, they can automatically cyber-proof their apps with Meterian so the business can run continuously and avert giving unwanted prying eyes unauthorized access to systems and data.

To this day, Equifax’s mistake for not fixing a known security hole in its software application’s open source component still has consequences since the 2017 mega breach they suffered.  See TechRadar’s lackluster review of Equifax’s identity theft protection service, which they did not include in their article “Best identity theft protection for 2020.”   

Good practices in cybersecurity can help protect a company’s reputation and growth.  As we’ve also seen following the EasyJet hack incident revealed in May, business productivity and customer satisfaction can be adversely affected due to any cyber hack incident.  You can read our recent analysis on easyjet.com’s website.  

To see if your own public assets have open source vulnerabilities that anyone could find out about (and exploit to enter your systems), try our webscanner or project scanner.

Meterian Spotlight: A quick look at Honda’s open source software supply chain

A recent Scala vulnerability emerges

Last month a new vulnerability was discovered that affects several versions of http4s, a prominent Scala HTTP library for client and server applications. The vulnerability is of a high severity nature hence it poses substantial risks.  Therefore be sure to read on and find out what these risks are and how to safely resolve them.

CVE-2020-5280

Vulnerability Score: 7.5

Platform: Scala

Component: http4s versions

  • 0.8.0 – 0.18.25
  • 0.19.0
  • 0.20.0 – 0.20.19
  • 0.21.0 – 0.21.1

Http4s allows Scala developers to create native client and server applications while favouring the pure functional side of the programming language.

In versions prior to 0.18.26, 0.20.20 and 0.21.2, the library has been found to be prone to local file inclusion (LFI) vulnerabilities caused by an erroneous URI normalization process that takes place when requests are performed. URI normalization is a very common process.  For example, browsers and web crawlers use it to modify and standardise URIs in order to determine whether two syntactically different ones are equivalent.

In vulnerable http4s versions, a malicious request could allow a potential attacker to gain access to resources on the server filesystem. This is known as a local file inclusion attack and it can lead to remote code execution (RCE) vulnerabilities.

File inclusions are part of every advanced server side scripting language on the web. In addition to keeping web application’s code tidy and maintainable, they are also used to parse files (e.g. configuration files) from the file system to be evaluated in the application’s code. Issues arise when these are not properly implemented, thus making the system vulnerable to exploits.

A typical exploit scenario could be the following. Assume you modularise your app so that required modules are defined in separate files, which are included and interpreted through a function that allows to specify the path to said modules. If the appropriate security checks are not present, the attacker could specify the path to sensitive files (e.g. the passwd file which stores passwords on Unix systems) or even worse, inject malicious code on the server and specify the path to successfully perform arbitrary remote code execution. A relatively trivial way to do so could be by abusing the web app’s upload functionality to upload an image containing this malicious code in its source.

How to fix this issue?

The recommended course is to upgrade:

  • v0.18.26 (compatible with the 0.18.x series)
  • v0.20.20 (compatible with the 0.20.x series)
  • v0.21.2 (compatible with the 0.21.x series)

If you can not perform an upgrade due to compatibility issues, it is advised to temporarily replace FileService.scala, ResourceService.scala and WebjarService.scala in your project with their non-vulnerable versions from the appropriate release series specified above.

As they say, prevention is better than cure. Don’t delay! Take remedial actions as specified above now. Integrate your system with Meterian to be informed when similar vulnerabilities arise and eliminate possible threats!

A recent Scala vulnerability emerges

jQuery, Javascript vulnerability of the month

Artwork by Marco Sciortino

Here we are! Guess what’s vulnerable again?
On April 10th 2020 it was made public that a vulnerability has been exploited in the most popular Javascript library ever implemented: jQuery 3.4.1.

Why is jQuery 3.4.1 vulnerable?

Vulnerability score: 5
Platform: Javascript
Components: jQuery, all versions before 3.5.0

When jQuery is invoked, it reads the HTML document and returns requested fragments of it.
Now, while reading the document it might find that the one or more requested fragments are not in the correct format, so it tries to translate them. Although most of the times the translation is correctly performed, it’s been demonstrated that in particular cases the conversion (or parsing) could lead to an XSS cross-site scripting vulnerability.

An XSS cross-site scripting is a type of code vulnerability that allows attackers to insert malicious code into the web pages viewed by other users. It might be exploited to steal information such as access tokens or other sensitive information. This is what a criminal or Black Hat hacker would do.

This is what a criminal or Black Hat hacker would do. White Hat hackers, on the other hand, would behave ethically and use their software White Hat hackers, on the other hand, would behave ethically. Using their software engineering knowledge, White Hat hackers would show how to exploit a vulnerability: publish useful information about it to make sure both users and owners of the vulnerable library could take actions to prevent attacks.

What actions are required to safely update?

The first thing to know is that all the old versions of jQuery have some sort of vulnerability.  Up until April 10th, version 3.4.1 was the only safe version available.  Fortunately, the new minor release 3.5.0 has been published to fix the XSS security vulnerability.

As suggested in the jQuery release note, updating to this latest version might break your code as, to prevent the abuse of this vulnerability, the HTML element phrase is no longer converted.
Therefore, a code review might be in order.

There is a lot of time-consuming effort involved in staying on track with all the latest code vulnerabilities as they are discovered but, fortunately, Meterian can help you with that.

When added to the CI/CD pipeline of any application, Meterian will automatically detect such vulnerabilities, or even fix them for you, and it will help you avoid the risk of an attack before it becomes a problem.

Beat open source vulnerabilities with Meterian.

jQuery, Javascript vulnerability of the month

Vulnerability Focus: Javascript

Welcome back to Meterian’s next Vulnerability Focus report edition. This week we are talking about Javascript vulnerabilities which need to be addressed. Both have been published in recent months and have a medium severity threat. The first vulnerability could result in a cross-site scripting attack whilst the second is to do with a cryptographic issue. There are over 1.6 billion websites in the world, and JavaScript is used on 95% of them, be sure to check if you could be affected.

  • CVE-2019-12043: there is a vulnerability in remarkable 1.7.1 affecting the unknown processing in the library lib/parser_inline.js of the component URL Handler. Manipulation of this component can lead to cross-site-scripting.
  • CVE-2019-9155: OpenPGP.js has a cryptographic issue which could allow attackers to conduct an invalid curve attack and gain the victim’s ECDH private key

CVE-2019-12043

Vulnerability Score: 6.1

Platform: Javascript

Components: remarkable version 1.7.1

Read up Javascript users! This vulnerability was posted last year in 2019, yet because of the significant amount of people using Javascript for their web apps, we thought it would be useful to inform people who might not have had time to address the issue. 

This vulnerability has been found in remarkable 1.7.1 and is considered problematic. The component mishandles URL filtering, which allows attackers to trigger an XSS attack via unprintable characters.

Cross site scripting is an injection of malicious code into a trusted web app. As described above, this happens when the user input is not sufficiently validated either on the client or server side. The scripts injected will have malware which then allows the hacker to do a series of exploits. What is more concerning is that the attack could then alter the appearance of the web app and also commence attacks on users visiting that site.

An image of a computer with three people huddled around it, pointing at the screen.
https://unsplash.com/photos/2FPjlAyMQTA

The solution for this vulnerability is to replace remarkable 1.7.1 with versions 1.7.4 to 2.0.0.

CVE-2019-9155

Vulnerability Score: 5.9

Platform: Javascript openpgp

Components: openpgp versions up to 4.2.0 included

This Javascript vulnerability was published in September 2019 and has a medium severity score of 5.9. 

The vulnerability is a cryptographic issue in OpenPGP.js up to and including 4.2.0. This is a library in Javascript and therefore can be used on nearly any device. Users do not have to install a gpg on their machines in order to use this library, and therefore it can be reused in other projects that have browser extensions or server apps. Its main function is to sign, encrypt, decrypt and verify any kind of text, specifically emails. 

The problem allows hackers, who can provide forged messages and get feedback on whether decryption of these messages succeeded, to eventually figure out and extract the victim’s private key.

An image of a key.
https://unsplash.com/photos/Nel8STCcWy8

To avoid this type of attack in the future, developers should identify sensitive data and encrypt them, even if stored on a hard drive. There should also be an effort to ensure the data cannot be overwritten by overwriting sensitive memory locations straight after the data is no longer needed in memory. 

In regards to this specific vulnerability, it is suggested to upgrade openpgp to version 4.3.0 or above. 

That is it from us…for now! Make sure to spread the word on these Javascript vulnerabilities in order to help protect your apps or the apps you develop. Read also our post about javascript vulnerabilities and remote code execution

As you all know, open-source vulnerabilities are discovered daily, so you can expect us to be back with new vulnerabilities very soon!

Knowing is half the battle. The other half is doing. Let Meterian help your dev team stay in the know and on top of the latest updates to secure your apps continuously. Sign up here to download the Meterian client today. You’ll get an instant analysis of your first project for free.  See the risks immediately and know which components to remove or upgrade to secure your app.

Vulnerability Focus: Javascript

Attention! New .NET Vulnerabilities

4min read

Image of dark room with an open door. Label on the left saying 'Vulnerabilities .NET'

Greetings App Sec community! Meterian is back with some .NET vulnerabilities which need some attention. Both these vulnerabilities are of a medium to high threat nature, so make sure to give this a read, it’ll be worth your while. The first case deals with a cross-site scripting vulnerability, whilst the second can cause a core denial of service issue. Don’t let hackers use this as a backdoor to your systems and networks. Stay protected people!

  • CVE-2019-1301: .NET Core suffers from a denial of service vulnerability when it improperly handles web requests.
  • CVE-2019-12562: There is stored cross-site scripting vulnerability in DotNetNuke (DNN) versions before 9.4.0, allowing attackers to store and embed malicious script into the administration notification page.

CVE-2019-1301

Vulnerability Score: 7.5/HIGH

Platform: .NET

Components: 

Affected Versions: 

  • .NET Core  / Microsoft.NetCore.App: 2.1.0-2.1.12 or 2.2.0-2.2.6
  • System.Net.Sockets: 4.3.0

The first .NET vulnerability we bring to your urgent attention is a denial of service vulnerability which occurs when .NET Core improperly handles web requests. The affected versions are in any .NET Core based application running on .NET Core 2.1.0 to 2.1.12 or 2.2.0 to 2.2.6, and System.Net.Sockets 4.3.0. This is regarded as a high threat to security and should be tended to immediately.

How can you confirm if your .NET application is affected? Run the dotnet –info command to see the list of the versions you have installed. You will then see output as shown below:

Lines of code which show the if your .NET application is affected.
https://github.com/dotnet/announcements/issues/121

If you see that you have a version of .NET Core which is less than 2.1.13 or less than 2.2.7, then unfortunately you are vulnerable. The same applies if you are using the meta-package “Microsoft.NETCore.App”, with the same version range. Please note that this also applies to the package System.Net.Sockets version 4.3.0.

What is .NET Core? It is an open source, development platform which is maintained by Microsoft and the .NET community on GitHub. It can be used to build device, cloud and IoT applications. 

Why is this vulnerability such a threat? Firstly, the attacker who is successful in the exploit of this vulnerability would use the denial of service against the .NET Core web application. Not only can this vulnerability be exploited remotely, but also without authentication of the user-cum-attacker. A denial of service attack (DoS) is focused on making a resource unavailable for the purpose of its design. The unavailability of a resource can come in many forms: manipulating network packets, programming, logical or resource handling vulnerabilities. Sometimes the attacker may execute arbitrary code to access critical information or execute commands on the server. Generally, this type of attack would cause response delays, large-scale losses, interruption to services and therefore an impact on availability. 

So how can you fix this issue? It is recommended to install the latest version of .NET Core but it depends on the versions which you have already installed. You may need to update if you have either version 2.1 (upgrade at least to 2.1.13) or 2.2 (upgrade at least to 2.2.7). If you are using the meta-package, upgrade the meta-package following the same version numbering. Also, if you are using System.Net.Sockets, please upgrade to version 4.3.1

CVE-2019-12562

Vulnerability Score: 6.1/MEDIUM

Platform: .NET

Component: DotNetNuke

Affected Versions: up to 9.4.0

You read right.  DotNetNuke (DNN) has a cross-site scripting vulnerability before versions 9.4.0 which is allowing remote attackers to store and embed malicious script into the admin notification page. The success of this exploit occurs when an admin user visits a notification page with stored cross-site scripting. 

A little information on DNN. First of all, it is a program that runs on Microsoft ASP.NET. It is also a framework, meaning it is a program designed to be extended. When you install DNN it can allow the creation of thousands of individual portals. These portals can then display pages and the pages display modules. More importantly, DNN is an open source web content management system meaning many businesses around the world rely on it for organisational purposes. DNNSoftware.com has over 1million registered members since 2013 and is used on nearly 750,000 websites globally. This might illuminate how many people could be affected by this vulnerability and why this needs urgent attention to avoid getting hacked.

The severity of this vulnerability is emphasized through the fact that stored cross site-scripting is the most dangerous type of cross-site scripting. The exploit could be used to perform any action that has administrator privileges. This includes: managing content, adding users, uploading backdoors to the server and more. 

Once this vulnerability had been detected it was reported to the DNN Software Security Department who have fixed the problem and released a patch. Users should update to the latest version 9.4.0 of DNN to avoid any security holes within their systems and networks. 

That is it from us…for now! Make sure to spread the word on these .NET vulnerabilities in order to help protect your apps or the apps you develop. But as you all know, open-source vulnerabilities are discovered daily, so you can expect us to be back with new vulnerabilities very soon!

Knowing is half the battle. The other half is doing. Let Meterian help your dev team stay in the know and on top of the latest updates to secure your apps continuously.  Sign up here to download the Meterian client today.  You’ll get an instant analysis of your first project for free.  See the risks immediately and know which components to remove or upgrade to secure your app.

Attention! New .NET Vulnerabilities

Love Your Developer: How to maintain & secure your open source components?

6min read

Happy Valentine’s Day! Meterian is feeling the love, so we want to share it by telling you the best way your business can love their developers! In this article we highlight the benefits and costs of using open-source software.  We’re also going the extra mile to give you tips on how to secure and maintain these components without slowing down your developers – the guardians of your business’ software that can propel you ahead of competitors.  

Here’s a little history lesson for you to begin with! Back in the 1940s-70s, software innovated at a slow pace. It wasn’t even regarded as a valuable asset in the working environment. The 1980s came and we see how software copyright was introduced, commencing a period where there was a boom in software innovation and a burst in software companies.  As the decades went on, people started to realise the value of open source software.

In 2000, the use of open source projects as well as components, began to grow significantly. Market research has predicted the global market size to grow from USD 11.40 billion in 2017 to USD 32.95 billion by 2022. Open source software has lowered development costs and accelerated innovation by reducing time to market. Now we see that companies who innovate early are 67% more likely to outperform.

Benefits of open source software 

Sometimes taking advantage of free resources is better. For example, in 2010 the use of open source was so common, it became a table stake. All companies were using it, otherwise they would fall at a disadvantage to their competitors. Open source solutions speed up software/hardware solutions, save money, provide flexibility and help companies stay on top of technological developments. This is supported by a survey which found 53% of companies have an open source program or plan to establish one in the near future

Developers are able to become creative and help solve problems in the software space when using open source solutions. It is the consumer and producer relationship that makes open source software thrive. As a result, there is more software availability for all users without having to reinvent the wheel. This in turn helps organizations. Recent research from Harvard Business School has shown that open source contributing companies capture up to 100% more productive value from open source than companies that do not contribute back. It creates a snowball effect: the more companies use it, the more the community is able to survey, criticize and praise it. Therefore, this strengthens the quality of the software used, including its security, usability and stability.

Open source software also comes with management benefits. Organizations tend to struggle when managing huge volumes of structured and unstructured data. This is where open source solutions can help! It helps to simplify business processes, as well as saving resources for things which are not needed for the success of a business. Essentially, it provides more flexibility for the company.

Taking a look at customer value is important. Due to the flexibility of open source software solutions, companies are able to customize to suit the needs of their particular customers. For example when you integrate two pieces of software. This requires less time than if the company were to write the integration software from scratch themselves. Therefore, it benefits both the company and their customers as well. Customers might even be willing to pay more for better solutions if they see this software is meeting their needs so efficiently and rapidly. It is all about viewing open source software as a resource and a powerful motivator.  

Costs 

When it comes to the law, open source solutions can sometimes be restricted to certain countries. For example, GitHub made headlines when it made it difficult for developers in Cuba, Iran, North Korea and Syria to access private repository services. There have been changes for open source licences in response to these types of situations, as it should be allowed to continue to expand and not interfere with international rules on software access. So companies should always know what licences are tied to the software they are using to avoid an IP breach. Read our past blog post on how the wrong licence can harm your business, if you haven’t already!

Moreover, open source components are attractive to cyber attackers. Firstly, open source vulnerabilities within components are discovered daily. Secondly, traditional testing tools and methods are ineffective in identification and therefore few companies understand the components being used in their applications. This lack of awareness leaves organizations increasingly exposed to an attack. For example Hollywood Presbyterian Hospital in California suffered a ransomware attack due to an outdated JBoss server software. The attacker uploaded malware to the out-of-date server without any interaction with a victim. This resulted in delayed patient care and the hospital had to pay $17,000 to recover access to files and the network.

A further cost or strain is the need to constantly maintain, test and secure these components. For example, in 2018 Sonatype released its fourth annual State of the Software Supply Chain Report and showed how software developers had downloaded more than 300 billion open source components in the past 12 months, 1 in 8 of those components having contained known security vulnerabilities.

Not catching these security bugs early on in the development process can lead to very costly and damaging outcomes.

How to maintain and secure open source components?

Firstly, you can start by making an inventory of all your open source components used when developing software. This inventory must include all the components, versions in use and the download locations for each project. Software bill of materials (SBoM) would be this inventory.

There is also a need to map out any known security vulnerabilities. The National Vulnerability Database (NVD) is a great place to provide information on publicly disclosed vulnerabilities in open source software. However, make sure you do not use this as your sole source for vulnerability information, as sometimes not all vulnerabilities are reported and the format of NVD records make it difficult to see which versions have been affected.   Meterian uses several sources in addition to the NVD.

Open source solutions are a brilliant resource. But to maintain its benefits there needs to be an effort to secure the open source components to lower the risk of them being vulnerable to cyber attacks. For example, a study conducted by Kula et al. on migrations of 4600 GitHub projects showed that 81.5% of them do not update their direct library dependencies, sometimes even in cases when they have been affected by publicly known vulnerabilities. This emphasizes the lack of awareness about security vulnerabilities within open source software. For this reason, to secure your open source components there is an urgency to upgrade software and keep on top of the known vulnerabilities.

https://www.pexels.com/photo/close-up-photography-of-yellow-green-red-and-brown-plastic-cones-on-white-lined-surface-163064/

Security is a community effort. There is a testing process for each project that is open to everyone. Developers using open source software are able to judge. This community of users are constantly evaluating and testing the security of certain components. Following this, there will be feedback on issues that have been found. For this reason, building open source software is safer than proprietary software because more people can test and contribute to its security. At the same time, there must be care about the code contributions accepted. A governance process and reviews in regards to any open source contribution should be made.

Constant vigilance is key. More than 3,600 new open source vulnerabilities are discovered every year and a significant amount appear daily.  Developers need to make sure their use of open source software is secure. Asking questions such as, is the code I am using good? Does it have any bugs? Due to vulnerabilities being identified on a daily basis–some have more high risk than others–there needs to be a practice within organizations to monitor or test each time the software changes. 

Meterian helps businesses get the most out of their software investments

Open source software has been changing how our world works, giving us a sustainable ecosystem that can work for everyone as long as it is looked after.

Meterian can automatically inventory your open source components and analyse them to check if they are up-to-date or have any publicly disclosed security and licence risks. Get started on building a proactive defence for your customer data and software IP.  Love your developers and let them innovate freely while using Meterian to secure your open source components. We can block insecure code before it goes live.  It will save you and your developers time and money, allowing your business to be less vulnerable to cyber attacks.  

Check if there are any open source security holes in your company’s website that puts your business at risk of a data or IP breach before it’s too late.

Try our free webscanner today.

Love Your Developer: How to maintain & secure your open source components?

Read up on more Node.Js Vulnerabilities!

It’s that time of the week again folks. Meterian has two new Node.Js vulnerabilities to inform you on. Both are ranked a severity score of 7.5 and therefore considered to be of urgent attention. The first vulnerability concerns the bson-objectid package and the second the csv-parse module. Act fast and don’t let these vulnerabilities sit within your software/networks, or you could be at serious risk of a cyber attack. 

  • CVE-2019-19729: There is an issue discovered in the bson-objectid package version 1.3.0 for Node.js. Hackers could generate a malformed objectid, resulting in objects in arbitrary forms to bypass formatting if they have a valid bsontype.
  • CVE-2019-17592: The csv-parse module before version 4.4.6 for Node.js is vulnerable to Regular Expression Denial of Service. An attacker can cause a program to spend an unnecessary amount of time processing.

CVE-2019-19729

Vulnerability Score: 7.5 /HIGH

Platform: Node.js

Component: bson-objectid

Affected Versions: up to 1.3.0

Read up Node.js users you’ll want to know about this vulnerability! This was discovered on the 12th December 2019 by user Xiaofen9 on Github who noticed that ObjectID() allows an attacker to generate a malformed objectid by inserting an additional property to his user-input.

What is bson-objectid? This component allows you to create and parse ObjectIDs without using bigger components, such as other fully-fledged bson libraries.

The problem is that in certain conditions the input object will not be checked and will be returned early. This means that objects in arbitrary (potentially malicious) forms can completely bypass formatting and validation.

https://github.com/williamkapke/bson-objectid/issues/30

So what can hackers do? The manipulation with an unknown input leads to a privilege escalation vulnerability and could lead to an impact on confidentiality, integrity, and availability.

But what does a privilege escalation vulnerability actually entail? It is when a malicious user gains access to the privileges of another user account in a target system. This allows hackers to use these privileges to steal confidential data, run administrative demands or deploy malware.

What can you do to fix this? Unfortunately, at this time of writing there is still no remedy to this vulnerability. However, we recommend to cease using this component or switch to a full bson library like bson.

CVE-2019-17592

Vulnerability Score: 7.5/ HIGH

Platform: Node.js

Component: csv-parse module

Affected Versions: up to 4.4.5

Oh yes…we are not done yet. Here is another Node.js vulnerability for you all! This was discovered on the 14th of October and given a high score of 7.5 by NVD. The affected module is csv-parse which is a CSV module. This project is a parser which converts CSV text inputs into objects. It uses the Node.js stream.Transform API and provides a simple callback-based API. Released for the first time in 2010, it is very easy to use and helps the big community that uses it with large data sets. 

The problem is that before version 4.4.6 for Node.js is vulnerable to Regular Expression Denial of Service. A cast option is available in the module, it defines multiple functions to transform values based on their type. When such option is active and an integer cast is required, the corresponding __isInt() function uses a malformed regular expression that processes large inputs extremely slowly.

Why is Regular Expression Denial Service a backdoor for hackers? The attacker will insert in the file a malicious string which they know would take a very long time to evaluate. This means the attacker can make the user spend an excessive amount of time processing, resulting in the user’s executed commands to slow down or become unresponsive. Thus,  the availability of the system degrades. To make things worse, the exploit can be easily and remotely executed depicting clearly why this vulnerability is classified as problematic.

An image of a coffee shop. A barista making coffee with a speech bubble saying '*making coffee slowly*' and a woman at the till looking impatient with a speech bubble saying "My coffee is taking forever".

The best thing to do to avoid getting caught out by such exploit, is to upgrade to version 4.4.6 and above. 

That is it from us…for now! Make sure to spread the word on these critically-rated Node.js vulnerabilities in order to help protect your apps/the apps you develop. But as you all know, open-source vulnerabilities are discovered daily, so you can expect us to be back with new vulnerabilities very soon!

Knowing is half the battle. The other half is doing. Let Meterian help your dev team stay in the know and on top of the latest updates to secure your apps continuously.  Sign up here to download the Meterian client today.  You’ll get an instant analysis of your first project for free.  See the risks immediately and know which components to remove or upgrade to secure your app.

Read up on more Node.Js Vulnerabilities!

The Healthcare Sector: A Major Target for Cyber Attacks

An image of a doctor with his hands crossed.
https://unsplash.com/photos/hIgeoQjS_iE

The healthcare sector is seeing a progressiveness when innovating its medical practices. Forbes estimated digital health tech catering to out-of-hospital settings would grow by 30% to exceed $25 billion market globally by the end of 2019.

Alas, with the growth of innovation in this sector, there also comes the risk of cyber attacks. The healthcare sector in particular seems to be a major target for cyber criminals. Why is this? What is the financial impact? And most importantly what can be done?

Why do cyber criminals target the healthcare sector?

There are many reasons why the healthcare sector is a target:

  • One of the main reasons has to do with the financial worth of the masses of patient information hospitals store. With the introduction of GDPR (May 2018) it has never been so crucial for hospitals and businesses to keep patient data secure.
  • Medical devices tend to be easy entry points for cyber attackers. Due to these devices only being used for medical practices, cyber security is not within the design of the product. Although these devices will not store patient data, hackers can launch an attack on the server which holds important information. For example, a vulnerability was discovered in the work of insulin pumps of Johnson & Johnson. This vulnerability could have allowed attackers to get control of the device via Wi-Fi and provoke an overdose of insulin in the patient’s blood.
  • Medical staff are accessing data remotely on different devices and networks, which provides another entry point for attackers. The problem is that if one device is hacked, this might leave the rest of the organisation vulnerable.
  • Despite the healthcare sector progressively innovating its practices, staff are still reluctant to disrupt working practices with the introduction of new technology. This creates weaknesses in the healthcare organisation’s IT systems because it produces outdated software that allows entry points for cyber criminals.
  • The result of costly budgets, lack of resources and time constraints make it hard for healthcare staff to be fully educated in cybersecurity practices.
  • The vast amount of devices used in a hospital makes it hard for IT specialists to protect the entire hardware network against attacks.
  • A very serious reason why the healthcare sector is targeted is also to do with international espionage. For example:
  • John Riggi, a former ex-FBI cyber specialist: Hospitals are “being targeted by hostile nation-states for theft of intellectual property related to medical research, innovations, cancer studies, population health studies, research of medicine and clinical trials, and also potentially for conversion for military use such as biological weapons”
  • They might target hospitals to acquire the medical details of business leaders, politicians or military figures. An example is seen when the Singaporean government health database was hacked in 2018. Prime Minister Lee Hsien Loong was amongst the 1.5 million whose personal data was stolen from the database.
  • Another problem is if hackers target hospitals near military installations this could give sensitive records of military personnel and worse, insight into where troops might be deployed.

Popular cyber attacks within the healthcare sector

The most popular attacks to the healthcare sector have shown to be: 

  1. Ransomware attacks

Ransomware is a type of malware that will infect systems and files, making them inaccessible until someone pays a ransom. For the healthcare system, this slows down processes and often forces hospitals to turn to pen and paper. A recent example of this was seen last November with the ransomware attack on French hospitals in Rouen. More worryingly, the 2017 Healthcare Cybersecurity Report suggested ransomware attacks on the healthcare sector will quadruple by 2020 and ransom-takers are using more sophisticated tactics to hack into systems, as 350 different variants of ransomware were observed in 2018 compared to 241 in previous years.

Often these attacks will affect machines through: phishing emails with malicious attachments, a user clicking on a malicious link, or viewing an advertisement containing malware. But an entry point that is often disregarded is ransomware via an outdated component or software. For example Hollywood Presbyterian Hospital in California suffered a ransomware attack due to an outdated JBoss server software. The attacker uploaded malware to the out-of-date server without any interaction with a victim. This resulted in delayed patient care and the hospital had to pay $17,000 to recover access to files and the network. What was interesting was that the attackers had used an open source tool, JexBoss, to search the internet for a vulnerable JBoss server and networks which had been infected. Organisations that handle healthcare data have to make sure to update their systems as the majority of healthcare ransomware attacks are malware related.

A picture of a computer with some code on the screen.
https://unsplash.com/photos/OqtafYT5kTw

What is a JBoss Server? This is an open source application server program used for developing and deploying enterprise java applications, services and web portals. JBoss released its last version (7.1.1) in 2012, as it then switched its name to Wildfly in its next release. So if you are running an application server with the name JBoss, it is out of date and has been for a very long time.

  1. Data breaches

Data breaches can occur for many different types of reasons, from credential stealing malware to insider threats to lost devices. The reason why data breaches are so common within the healthcare sector is because Personal Health Information (PHI) is more valuable on the black market than financial or Personally Identifiable Information (PII). 

But why is PHI more valuable that PII? The average cost of a data breach for a non-healthcare related agency is $158 per stolen record. Yet, for the healthcare sector the average cost is $355. According to Infosec Institute, PII can sell on the black market for $1-2 but PHI has been said to be worth up to $363

This shows the value of patient data financially. However, PHI can be valuable also to target victims with fraud scams by taking advantage of their medical conditions. Cyber criminals have also been known to use stolen patient data to access prescriptions for their own use or resale. 

With the enforcement of GDPR since May 2018, securing patient and medical records has never been so important.

  1. Insider Threats

Did you know the healthcare sector is the only industry for which the biggest threat to data breaches come from internal sources? According to the 2019 Verizon Insider Threat Report, 46% of healthcare organisations were affected by insider threats

Insider threats have shown to stem from a lack of cybersecurity training amongst staff or employees maliciously giving away access codes or them purposefully selling PHI or PII for profit. For example, Anthem a Medical Insurance company learned in 2017 that an employee had been misusing and stealing Medicaid member data — up to 18,000 of PHI — as early as July 2016. This demonstrates the cautiousness there needs to be within the staffing of the healthcare sector to ensure people are not misusing PHI. 

  1. Business email compromise

Business email compromise is when hackers use spoof emails to compromise an account by tricking the employee to transfer money to a fake account. Normally, the fraudsters pretend to be a person of authority within the company to seem as if they might be asking a legitimate request. This has been successful because fraudsters tend to do a lot of research on their targets and will make sure to convincingly impersonate the individual whilst only sending the email to select few people. 

For example, in 2015 a local medical center reported that they had received a call from a pharmacy to confirm a large order of prescription drugs amounting to over $50,000. After a thorough investigation they discovered that the medical center had not placed that order. The pharmacy had called to check because the shipping address of the medical center didn’t match their records, yet all of the other credentials provided had been correct, such as:

  • The Drug Enforcement Agency ID number
  • Doctor licences
  • Pharmaceutical certificates

This clearly demonstrates how cyber crime is becoming more sophisticated.

The Financial Impact

Data breaches are particularly strenuous on the healthcare sector because they take longer to deal with an attack due to a lack of financial resources or trained personnel. To make matters worse, by 2020 security breaches are said to cost the healthcare sector 6 trillion dollars. A study conducted by Mid-Horizon found that hackers can very easily access domain level administrative privileges of most healthcare applications. 

The financial damage the WannaCry attack placed on the NHS in 2017 was significant. The Department of Health said the attack cost the NHS £92 million due to a third of hospital trusts and 8% of GP practices had affected computers. The hack forced 200,000 computers to lock out their users with red-lettered error messages demanding a ransom in Bitcoins. 

This is all the more reason the healthcare sector need to prioritise their cybersecurity as these sorts of attacks could have crippling consequences. 

A picture of some doctors/nurses walking down a white corridor.
https://unsplash.com/photos/Pd4lRfKo16U

What can be done? 

On a national level, there are some countries that set a good example. After the cyber siege in 2007, the Estonian government created a cybersecurity strategy built into their law enforcement. After one of their reports found that 11,000 cybersecurity incidents happened in 2018, Estonia introduced a blockchain technology to have more control over electronic patient records. This meant there was a time-stamped record of anyone in contact with/adding/omitting information. Conversely, patients use electronic identification cards to access their health information and can decide who they share the information with.

Although many security executives think that their programs are providing sufficient protection, these programs might not be securing the actual patient or member data. There needs to be an understanding between compliance-driven strategy which is when programs do not stand up to the test of the attackers and security-driven strategy when programs are designed to deal with attackers and the threats they create. This means a refocus on the actual risks of the healthcare infrastructure:

  • Where is the patient data?
  • Where does it live? 
  • How is it stored?
  • How is it protected?
  • Are these protections sufficient?

Therefore when new technologies are in place there can also be a focus on:

  • If the technologies are fully supported 
  • If the technologies are deployed across the organisation’s entire enterprise
  • That the technologies have no limited capacities
  • That the technologies are never unmonitored

Both patient care and business continuity are important to healthcare organisations.  As hospitals and caregivers rely on technology to deliver greater gains for more timely care and more efficient business processes, they must ensure their systems are secure and stable for everyday operations. This requires a cyber resilient approach that addresses people and processes, as well as the technology used. Read Meterian’s blog post on how your organization  can become more cyber resilient.

The Healthcare Sector: A Major Target for Cyber Attacks