BeatOpenSourceVulns

Alerting a financial services firm to existential security threats and enabling fast, effective remediation

viviandufour, , , Leave a comment
  • Location: UK
  • Industry: Financial Services
  • Customers: Fortune 500 clients around the world
Skyward view from the ground and 4-6 tall buildings pointing up
Credit: Samson-ZGjBuikp_ from Unsplash

A Race Against Malicious Actors

The breaking news in December 2021 of the zero-day vulnerability in the Java logger Log4j 2, known as Log4Shell, sent shockwaves through organisations around the world. Over the last 20 years Log4j has been used globally in billions of software developments and applications for logging incidents. This meant that until the vulnerability could be mitigated, the doors were open to millions of organisations. Attackers could break into systems, steal passwords and logins, extract data, and infect networks with malicious software causing untold damage. The issue was also a major threat to corporate reputations, especially where trust and confidentiality was key, such as in the financial services sector.

In the early hours an alert notification about the Log4j critical vulnerability reached one major financial services organisation based in the UK, with Fortune 500 clients around the world. On hearing the news, the Director of DevOps and Engineering cross-checked other sources for corroboration, including social media, and contacted the organisation’s Lead Technical Security Officer. It was clear that, unchecked, this could be a major problem, but how big an issue would depend on how widely Log4j 2 was embedded into systems used and being developed throughout the corporation.

Often in the race to innovate and implement systems quickly, documentation may not be as comprehensively kept and updated as ideally required. In its absence, it can be difficult for an organisation to discover how widely Log4j is integrated within its application estate, let alone know if it has been previously patched. 

The race was on against the malicious actors poised to automate exploitation of Log4J vulnerabilities, with major impacts for the corporation and potentially for millions of customers around the world.

Mobilising the IT & Security Workforce with Meterian

The organisation moved rapidly by using Meterian’s out-of-the-box reports to enable it to identify where Log4J vulnerabilities were to be found across its application estate, and hence the size of the potential problem. Only then could it be possible to build a remediation plan to mitigate the risks of all the Log4J vulnerabilities.

By 10am, the list of projects utilising the Meterian solution could be seen via the Meterian Dashboard and automated scanning initiated. Scanning the software bills of materials of the affected projects, an indication of the potential impact of Log4J was emerging which could give direction and scope on the follow-up actions. Other projects which had not yet begun to use Meterian as part of their regular processes, found that Meterian’s simplicity of use meant that they could also quickly scan their projects for vulnerabilities.

Working methodically and forensically with the organisation’s development teams across multiple locations, by 5pm it was possible to present to senior management a concise summary of the situation, showing areas of the business at risk; those projects which had already been remediated; and those still needing work. A comprehensive communication plan was then invoked to alert the business to remaining vulnerabilities.

The following Meterian tools were used:

  • Meterian Sentinel notification alerts: an always-on security messaging service which sends notification alerts, emails, or Slack IMs to account administrators about new public vulnerabilities found in open source components used by their projects.
  • Meterian Boost Open Source Security (BOSS) Scanner: which gives instant visibility to the application’s open source dependencies with automated discovery, risk scoring, continuous scanning, and actionable security insights.
  • Meterian Account Dashboard: insight reports show dependent components and related Critical/High/Medium/Low vulnerabilities within the remit of a particular account.

The Meterian toolset alerts key employees to security issues and vulnerabilities; the breadth of the issue for the organisation’s application estate; and the projects impacted. The CISO is then armed with all the information needed to mobilise an effective action plan and comprehensive remediation.

Visibility and Control of Vulnerable Components

Log4J created great upheaval in IT teams across the industry, but for this business unit at this global Financial Services organisation, Meterian tools rapidly delivered a complete view of projects that were susceptible to attack. In comparison, other business units were not able to gather such insights so quickly because there was no single comprehensive reference point which was easy to access and use.

Meterian enabled a speedy time to resolution: 2 hours to implement remediation on projects identified using Meterian as having the Log4J vulnerability.

Meterian freed up employee time from finding the vulnerabilities, enabling them to focus on isolating the application estate from risk and implementing remediations. The Log4J threat demonstrated that critical incident prevention is possible with a more automated, secure-by-design approach. Additional or external staff were not required as existing employees could use smart tools on their application estate, and on a more regular basis to save time and remove headaches.  

Through using Meterian the organisation benefits from:

  • Prompt alerts and early warnings of vulnerabilities in the open source software supply chain
  • Enhanced protection against threats
  • Increased confidence in people and tools working together to protect from organisational risk
  • Decreased stress that vulnerabilities will cause major damage and reputational harm
  • Reduction in “known unknown” risks and number of security fires 

Cultivating Cyber Resilience Consistently and Responsively

The organisation is using the effective response enabled by Meterian as a case study to demonstrate that regulatory and compliance requirements can be met with easy-to-use continuous scanning tools that provide immediate visibility and quicken the development of secure code.

The proven partnership with Meterian will extend and facilitate their further innovation in automation, analytics and cyberresilience, through even more responsive and secure development.

Visit our homepage to learn more about how Meterian can secure your businesses’ open source components—keeping cyber hackers out and your intellectual property in.

Alerting a financial services firm to existential security threats and enabling fast, effective remediation

Visibility is vital if we are to improve safety and trust in open source

viviandufour, , , , Leave a comment
Image shows an observation deck, but the panorama is veiled behind white light or mist showing blank skies. Do we know or see what we are building in our digital world?

Photo by Kate Trysh on Unsplash

Recent high profile cyber security incidents have reinforced the importance of cleaning up the open-source software supply chain. From Heartbleed to the Apache Software Foundation’s Log4j vulnerability, these highly publicised incidents have exposed the threats associated with the software supply chain.

Open source security vulnerabilities are nothing new. Heartbleed was a security bug in the OpenSSL cryptography library that affected many systems. Similarly, Log4Shell is a severe vulnerability, however in the case of Log4j the number of affected systems could well run into potentially billions. Many cybersecurity experts have characterised Log4Shell as the single biggest, most critical vulnerability of the last decade.

These incidents have brought into sharp focus the risks and galvanised a range of responses at national and international level. It even prompted the White House to convene an Open Source Software Security Summit in January that was attended by leaders from global technology companies including Google, Meta, Apple, and Cisco. Members of the open source community were also represented at the summit, as well as US government agencies, including the Cybersecurity and Infrastructure Security Agency, the National Security Council and the National Institute of Standards and Technology.

The gathering may have been precipitated by the Log4Shell vulnerability, but the wider context was clear. How do we ensure source code, build, and distribution integrity to achieve effective open source security management?

Open source under the microscope

Technology companies have been using open source for years as it speeds up innovation and time to market. Indeed, most major software developments include open source software – including software used by the national security community.

Open source software brings unique value, but it also has unique security challenges. It is used extensively, however, the responsibility of ongoing security maintenance is carried out by a community of dedicated volunteers. These security incidents have demonstrated that the use of open source is so ubiquitous that no company can blindly continue in the mode of business as usual. Recent research showed that 73% of applications scanned have at least one vulnerability[1]. These can be buried deep in the open source software supply chain that software-driven businesses rely on for basic functionality and security to accelerate their time to market.

The known unknown

The concept of known knowns, known unknowns and unknown unknowns has been widely used as a risk assessment methodology. When it comes to cybersecurity and the voracity of threat actors to exploit vulnerabilities, it is a useful analogy.

Let’s take Apache Log4J as an example. Companies often create products by assembling open source and commercial software components. Almost all software will have some form of ability to journal activity and Log4j is a very common component used for this.

How do you quickly patch what you don’t know you have?

Java logger Log4j 2 – A zero-day vulnerability

Log4J was originally released in 2001, and over the last 20 years it has been used in billions of software developments and applications across the world. For logging incidents within software, Log4j is used by everything from the humble 404 error message, gaming software such as Minecraft, and Cloud providers such as iCloud and Amazon Web Services, as well as for all manner of software and security tools.2 On 9 December 2021, the zero-day vulnerability in the Java logger Log4j 2, known as Log4Shell, sent shockwaves across organisations as security teams scrambled to patch the flaw. If left unfixed, attackers can break into systems, steal passwords and logins, extract data, and infect networks with malicious software causing untold damage, not least to brand reputations.

However, herein lies the problem. How do you quickly patch what you don’t know you have?

Often in the race to innovate, the first thing sacrificed is up-to-date documentation. Without it how does a company know if Log4J is integrated within its application estate, let alone know if it has been previously patched.

Improving safety and trust when speed is of the essence

If we are to increase safety and trust in software, we must improve transparency and visibility across the entire software supply chain. Companies should have the ability to automatically identify open source components in order to monitor and manage security risk from publicly disclosed vulnerabilities. A software bill of materials (SBOM) should be a minimum for any project or development. Without such visibility of all component parts, security teams cannot manage risk and will be unaware, and potentially exposed, to dangers lurking in their software.

Case study – Full Visibility within an Hour

To give an example; one of the largest UK based financial services company with millions of customers across the world discovered it had Log4J embedded within dozens of in-house developed software projects. Having seen the first reports of the vulnerability at the start of the business day, within an hour the security team had identified projects using Log4j and were able to start work on follow up activities. By the end of the day, the entire business had a concise list of projects at risk, some of which were already remediated.

How was this achieved?

The company had automated tooling integrated into their software development environment with comprehensive component security. This enabled them to quickly identify those software projects which depended on the affected log4j component.

This visibility allowed the company to devise remediation plans to mitigate the risks of the vulnerability in Log4J. The company was able to target valuable resources across multiple locations to ensure fixes were applied quickly to critical business applications within just a couple of hours. While they were implementing an action plan based on the organisation’s use of Log4j, some of its competitors without such comprehensive tools were still in the information gathering stage.

Innovating securely

As organisations continue to innovate at pace in order to reduce time to market, the reliance on open source software continues to increase. However, when the security of a widely-used open source component or application is compromised, every company, every country, and every community is impacted.

The White House has taken an important first step in trying to identify the challenges present in the open source software supply chain and encourage the sharing of ideas on ways to mitigate risk and enhance resilience. Organisations can and should take advantage of the many benefits that open source software can deliver, but they must not do it blindly. Ensuring you know the exact make-up of your technology stack including all the component parts is an important first step. Choosing discovery tools that have the widest comprehensive coverage is important, and so too is the flexibility to grade alerts so that only the most pressing threats are highlighted. This avoids ‘alert fatigue’ and enables security teams to focus resource where it matters most, putting organisations in a good position to act fast when vulnerabilities are discovered.

Hackers faced with stronger security defences will continue to turn their attention to the weaker underbelly of the software supply chain. Now is the time for organisations to implement integrated and automated tooling to gain comprehensive risk control of components in their open-source software supply chain. Only by increasing visibility, coverage of known unknowns and transparency can companies stay one step ahead.

1 Meterian research from aggregated and anonymised data of 2044 scanned software applications in 2020.

2 “What is Log4j? A cybersecurity expert explains the latest internet vulnerability”, The Conversation, Dec 21, 2022, https://theconversation.com/what-is-log4j-a-cybersecurity-expert-explains-the-latest-internet-vulnerability-how-bad-it-is-and-whats-at-stake-173896

Visibility is vital if we are to improve safety and trust in open source

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

viviandufour, , , , Leave a comment

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

Rust— the new language shaking up the open source programming world

bbossolaLeave a comment

Rust is a relatively “new” software language across all the available ones at this time and rising in popularity among developers. Having been voted ‘most loved’ language for the past five years1, it is no wonder that Rust is gaining more attention. Read on to hear why we think Rust is worth your time.

Why a developer should consider Rust

Rust is a system language, along the lines of C and C++, but at the same times it incorporates many of the features of higher level languages, such as:

  • A reliable memory management (without a garbage collector)
  • An extremely low overhead
  • The use of static typing
  • A build design that prioritises performance (at the level of C and C++)
  • The use of a modern package management ecosystem

Remember Go? Rust will almost be faster than Go in run-time benchmarks because it has superior fine-grained control over how concurrency works in terms of threads and shared resources2. 

Additionally, Rust is being considered for use in the Linux Kernel3 by Linus himself, which is no small feat. Rust also supports WebAssembly4, just in case you fancy writing some web stuff 🙂

Rust has also become the ideal candidate for  IoT application development. Labeled as fast, reliable, and secure by Smart Device Management organisation Dwello5 who switched to Rust for their IoT platform. As they build IoT applications, developers have many programming languages to choose from. Some popular options are Java, C, JavaScript and Python. C and C++ are especially popular for device-run code. Another, less popular, option today is Rust, but that is likely to change. Let’s start with the characteristics of any programming language that makes it a good candidate for IoT development.

Application performance is a top priority, especially for code running on devices with minimal CPU and memory resources.  Developers can develop highly performant applications with C and C++, but at a cost. C and C++ developers know all too well the risks and challenges of dealing with bugs related to memory management such as unhandled null pointers and failing to deallocate unused memory.

Another component of a good IoT development language is developer productivity. Productivity is often a byproduct of skills, tools, and programming language abstractions and patterns. Popular programming languages are well supported by development environments. Additionally, developers acquire build tools and skills with time and experience; as a result, language abstractions and patterns are a key consideration with regards to developer productivity.

For those looking for both application performance and developer productivity, Rust is an increasingly popular option. The IoT market size is expected to grow from $250.72 billion in 2019 to $1,463.19 billion by 20276. Clearly, this is an area of the tech world that is only set to expand in influence. Meterian prioritises remaining at the forefront of innovation and supporting languages that have a vital role in ever advancing tech trends.

Why Meterian has decided to add Rust to its supported languages

First of all, Rust is big in open source, so it’s a natural continuation in our mission to support open source. Although security is extremely important in the Rust philosophy, there are vulnerable packages appearing in the wild. The GitHub advisory database7 does not have an entry for Rust (although some advisories do surface here and there) and the NVD database contains only a portion of all the vulnerable Rust components. Meterian is ingesting not only the NVD and other official security Rust databases, but it’s also actively monitoring many Rust open source projects at their source. Our ongoing efforts for getting the optimal coverage of all known vulnerabilities for open source dependencies extends our mission to Rust developers so we can maximise preventative care for Rust coding projects. 

Rust is important to pay attention to because on average every single rust open source project we scanned contains at least 1 vulnerable component that often could be patched.

Sizing up the risks in the Rust ecosystem

Screenshot from: https://www.rust-lang.org/

Rust, like all other modern languages, has an ecosystem of components, called “crates”, that are available from the open source community, which is accessible at crates.io. Although as a Rust developer you will always prefer writing some code from scratch (at the end of the day, this is a system language), it’s highly likely you won’t be reinventing the wheel. As shown on the screenshot from May 6th, over 60,000 crates with over 6.8 billion downloads, this is a significant size.

There’s a good chance that, if you never checked, you have been using a crate affected by a publicly disclosed vulnerability. Unless you are in application security and unless you spend half of your time reading bulletin boards, advisories, mailing lists, you won’t know about it. However, hackers do. They keep an eye on these vulnerabilities and routinely develop automated attacks to exploit them. In fact, hackers have it nailed to a T. The vulnerabilities are made public on open source vulnerability databases, the code is open source, they already have a botnet to run them (maybe even your Amazon Alexa or Google Play). All of a sudden, your shiny new service written with the latest cutting edge technology is vulnerable, and it can be used to exfiltrate confidential user data from your backend!

Let’s assume, for example, that you are using hyper, an HTTP library:

Screenshot taken from: https://www.rust-lang.org/

Since hyper is a relatively low-level library, it’s meant to be a building block for other libraries and applications. It may be a transitive dependency, a crate that is pulled in your code as the result  of another crate that is used. In particular version 0.12.34 of hyper has an interesting vulnerability: it allows an attacker to remotely execute code on the machine where your code is running. Check out this Common Vulnerabilities and Exposures ID CVE-2020-35863 for more details.  This security vulnerability would allow the attacker, for example, to install a very simple bot on your server, open an undetected tunnel and start pulling data from your proprietary system.

This is the beauty of a tool that detects the problem automatically and informs you promptly. We prioritise your time so that you can focus on the solution to remediate the issue, maximising productivity whilst maintaining high standards of open source security. 

What can Meterian do for you?

Sign up for a free account to see how our invisible security platform can work seamlessly in your software development life cycle (SDLC) and auto-remediate vulnerable components.

1 https: //insights.stackoverflow.com/survey/2020#overview

2 Howarth, Jesse. “Why Discord is switching from Go to Rust”. Discord, 4 Feb 2020, https: //blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f

3 Salter, Jim. “Linus Torvalds weighs in on Rust language in the Linux kernel”. Arstechnica, 25 March 2021, https: //arstechnica.com/gadgets/2021/03/linus-torvalds-weighs-in-on-rust-language-in-the-linux-kernel/

4 “Why Rust?”, https: //www.rust-lang.org/what/wasm

5 Hiner, Jeff. “We Rewrote Our IoT Platform in Rust and Got Away With It”. Medium, 31 July 2019, https: //medium.com/dwelo-r-d/we-rewrote-our-iot-platform-in-rust-and-got-away-with-it-2c8867c61b67

6 Fortune Business Insights, https: //www.globenewswire.com/en/news-release/2021/04/08/2206579/0/en/Global-IoT-Market-to-be-Worth-USD-1-463-19-Billion-by-2027-at-24-9-CAGR-Demand-for-Real-time-Insights-to-Spur-Growth-says-Fortune-Business-Insights.html

7 https: //github.com/advisories

Rust— the new language shaking up the open source programming world

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

viviandufour, , , , , , Leave a comment
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

Nana Insaidoo, , , Leave a comment

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

Marco Sciortino, , , , Leave a comment
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

Victoria C., , , , Leave a comment

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

The Automotive Industry: Cyber Hacks. A Growing Threat.

Victoria C., , , , , Leave a comment

5min read

The inside of a car, looking out into the motorway.
https://unsplash.com/photos/MyjVReZ5GLQ

There is no question that the automotive industry is one undergoing constant innovation and digital transformation. Nowadays, people expect to stay connected when commuting in their vehicles at all times and locations. Modern cars will have built-in navigation systems, Wi-Fi access, as well as in-vehicle infotainment systems (a combination of entertainment and information delivery to drivers). Alas, with the rise of new technologies, comes the rise of new hacks and gateways for cyber criminals to penetrate car systems. 

Yet, it is also true that these cyberattacks are not just occurring out of new technologies, there is still clearly a lack of scrutiny over vulnerable open-source components within a company’s software code. This is confirmed by a 2019 survey by Synopsys and SAE International on current cybersecurity practices which found 62% of professionals interviewed believe malicious attacks on software and open source components are bound to occur in 2020 within the automotive industry. Clearly, these security holes are major contributors as to why malicious actors have been so successful in penetrating systems and networks. 

This article intends to enlighten readers on the problems which certain hacks can cause to the automotive industry and its customers, as well as insight into ways this industry could prevent future exploits as part of their digital transformation. 

What can go wrong?

Cyberattacks to the automotive industry can have health, financial and reputational consequences. Take the examples below:

  1. A scary reality is if the hackers access the brakes or steering wheel. We have already seen an example of this in April 2019, where a hacker broke into two GPS tracking apps (ProTrack and iTrack). This resulted in access to personal data, the monitoring of the vehicle location and the ability to stop the engine altogether. This type of hack could cause serious accidents and therefore threatens the health and safety of the passenger.
  1. Automakers also have to take care of cybersecurity within their designs or else they could suffer severe financial repercussions. For example, a global automaker recalled around 1.4 million cars in 2015 due to cybersecurity risks, resulting in the potential cost of the OEM (Original Equipment Manufacturer) of nearly $600 million. The impact here is not only financial loss, but the automaker loses a certain amount of credibility as a provider, further damaging their business.
  1. Losing control of a web or mobile app also has its downfalls. Ransomware attacks or data breaches could expose a lot of sensitive data, as well as stop systems from running. As automotive companies compile a significant amount of this customer data, they become a plausible target for hackers. For example, in April 2019, Toyota announced a breach had exposed the data of up to 3.1 million customers. This disrupts the business, causes financial problems and most certainly diminishes the reputation of the company. Additionally, the leaking of software IP can also be damaging to a business, as it can give information to hackers for future exploits.

Cybersecurity is like a seatbelt

A driver with a seatbelt.
https://unsplash.com/photos/stLYAO8Vx1E

Until 1966, cars were often made without seat belts. But now, it would never cross the mind of any manufacturer to not include seatbelts in the design of a car, as it would be a major risk to the health and safety of the passenger. Here we can make a parallel with cybersecurity. In the same way there is a blatant risk of not wearing a seatbelt due to the possibility of a car accident, there is also a major risk of letting software-driven devices run without having secured their entire software supply chain to de-risk the possibility of a cyber attack via a vulnerable software component.  Everyone should wear a seatbelt in a car, so why does the automotive industry not treat cybersecurity with the same mentality? 

It is suggested the automotive industry lacks a standard approach for dealing with cybersecurity. This problem can stem from the relationship between OEMs and suppliers. Currently, contractual arrangements often do not allow OEMs to test the end-to-end cybersecurity of a vehicle platform made up of parts from different suppliers. Subsequently, this makes it hard to achieve strong cyber security when automotive software is developed and tested. 

Businesses within the car industry, may feel that they haven’t got the time to focus on cybersecurity. Too many companies will not feel the urgency until they have experienced a cyber attack themselves. For that reason, there seems to be a shortage in cybersecurity professionals globally. A Cybersecurity Workforce study has interviewed over 3200 security professionals around the world and found that the number of unfilled positions has risen from 2.93 million in 2018 to 4.07million in November 2019.

How to improve cybersecurity in a constantly evolving industry?

For manufacturers and suppliers in the automotive industry, there is a need to prioritise cybersecurity as part of the automobile’s e-safety. Collaborators in the automobile value chain must take into consideration the digital life cycle of the vehicle’s software as part of the vehicle’s holistic life cycle. Therefore producers of intelligent cars (or their electronic subcomponents) powered with software must include these 4 pillars:

  1. A good baseline: understanding the relevant legislation in the OEM markets and making sure to uphold all the existing cybersecurity standards involved. This will help all parties deliver secure software.
  1. Enforce a security-by-design culture within the engineering process. This should focus on secure development practices, software testing and new supplier-audit processes that include cybersecurity issues. Here there should also be testing or evaluating the components within code, to check for vulnerabilities.
  1. Monitor the cybersecurity of cars on the road. This means having a clear view of a vehicle’s configuration and setting up a security operations center for cars. Here the center could use correlation and artificial intelligence to detect adverse events and respond efficiently. The use of new technologies adds to how the industry needs to digitally transform to address cybersecurity effectively.
  1. Ensure software updates to vehicles pass security and safety tests. This should be run by the OEM through a software-engineering approach. This shows automakers are testing and securing changes to the vehicle as part of their continuous maintenance.
A car in a factory, being constructed by machines.
https://unsplash.com/photos/jHZ70nRk7Ns

For other business providers working within the automotive industry it is also important to adapt to changing technologies so that your cybersecurity is up to date. For example, there are many companies now promoting different ways to own a car through web and mobile apps and shared-platforms such as Turo, Drover or Avis. Here criminals could target the business because of the abundance of sensitive customer data. This could be supported when Verizon’s Data Breach Investigation report saw 60% of the time, web apps are the unlocked doors that hackers use to access user data or bring your business to a stand still. These are some tips to protect your apps:

  1. Make sure to secure vulnerabilities within your business code – more than 40% of cyberattacks originate in software servers, vehicle mobile apps and the infotainment system combined. Addressing software vulnerabilities should be a consistent practice as they are discovered daily and hackers exploit them automatically using bots and programs. The scale of vulnerabilities which a company could obtain over time is seen through the example of Uber who have 1,345 resolved bug reports and have paid out over $2.3 million. To understand the scale, Uber has received up to 111 bug reports in the past 90 days.
  1. Implement a cyber resilient culture within your business. To go through digital transformation, companies need to adapt to the growing sophistication of cyber criminals. This means there needs to be qualified teams with expertise ready and prepared to respond to malicious actors. Clearly this is something which needs to be implemented with more rigour in the automotive industry, as FleetNews’ recent survey of 500 businesses in the sector found that 65% did not have a cyber security team. 
  1. Look into the future. When investing in new technologies, understand how this will impact your business models, operational processes and the user experience. Successful transformations also depend on how firms manage digital transformation process through leadership and governance (not solely its implementation). If businesses don’t keep up with evolving technologies, how will they be able to keep up with the growing sophistication of hackers? Research by Accenture has highlighted the advantage which digital transformation provides to companies: early innovators are 67% more likely to outperform compared to 18% for market share protectors.

Let Meterian be your seat belt

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 as your business goes through digital transformation. Try our FREE web scanner today to get a preview of what kind of potential vulnerabilities are in your website.  We can provide more in-depth analyses for all your software code bases. Get in touch today.

The Automotive Industry: Cyber Hacks. A Growing Threat.

Attention! New .NET Vulnerabilities

Victoria C., , , , , , Leave a comment

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