risk

Cyber resilience is critical for innovation and economic sustainability

viviandufour, , , , Leave a comment

The events of the last few years have highlighted the world’s vulnerabilities and shown the importance of building resilience into organisations, supply chains and the global economy. COVID-19 and the war in Ukraine have exposed issues we’d chosen to ignore, thought we’d fixed forever or hadn’t even considered before. Growth is no longer guaranteed. The global economy’s increasing reliance on technology to enable the world to function extends the attack surface and opens up new cyber security threats.

The need for cyber security to protect sustainable growth

Governments are struggling with plans for sustainable economic growth against a background of conflict, continuing supply chain problems, climate change, rising prices and interest rate increases. Typical sustainable development goals include; economic growth measured by GDP; business innovation and infrastructure renewal; creating sustainable cities and communities; and responsible consumption of products.

From smart cities, to renewable energy, financial infrastructures and driverless transport, cutting-edge technology is at the heart of our drive for sustainable growth. This provides exciting opportunities but has also exposed existing systems’ weaknesses and created new vulnerabilities to malicious actors. Sustainable development goals are all put at risk by the increased threat from cyber attacks.

Organisations have become familiar with safety and security measures which protect their physical environment such as installing early warning sensors, security cameras, fire safety equipment and intruder alarms. There’s a need for a cultural shift for executives, investors, employees and regulators to recognise the increasing importance of cyber security. The war in Ukraine has brought into sharp relief the importance of having both strong physical and cyber defences. Cyber resilience is absolutely necessary for modern civilisation to survive and flourish. 

How big is the cyber threat?

Recent research and headlines point to cyber crime being very big business indeed. One study showed cyber criminals raking in $1.5 trillion every year. To put that in context that’s exactly the same amount proposed for the US Congress’ bipartisan package to help Ukraine and finance federal agencies for the second half of 2022. Another study from Cybersecurity Ventures expects global cybercrime costs to reach $10.5 trillion annually by 2025. This led Steve Morgan, Editor-in-Chief at Cybercrime Magazine to comment, “This represents the greatest transfer of economic wealth in history, risks the incentives for innovation and investment, is exponentially larger than the damage inflicted from natural disasters in a year, and will be more profitable than the global trade of all major illegal drugs combined.”

Innovation is a growing target for cyber criminals

Innovation and invention are seen as good things for businesses and the wider economy. They power economic growth and prosperity around the world but by their very nature they can open the door to cyber criminals. Innovation is all about new technologies, products and ways of working. The cloud gaming sector is a prime example of an industry that has attracted the attentions of hackers, due to its  constant growth, developing new platforms and introducing new products almost daily. As the industry transitions to cloud infrastructures, the market size was estimated at $609.67 million in 2021, and is expected to grow to $7.382 billion by the end of 2028 according to research by Brandessence. Change, as in this case, often comes at dizzying speed. This means that procedures, controls, security and monitoring may lag behind. Ripping up the rule book to innovate can have huge positives but organisations need to watch for the negatives too. Indeed, some of the largest cyber security incidents in 2022 were targeted at the gaming sector, with breaches reported by such behemoths as Rockstar, Roblox and NVIDIA, to name just a few. 

Rapidly expanding sectors and businesses naturally also attract huge investment. This makes them even more attractive for wily cyber criminals as the rewards from attacks can be particularly lucrative. Another pertinent example is the renewable energy sector. This growing industry promises great things for our hopes of preserving the world we live in. Massive investment means it is also shaping up to be a very attractive market for cyber criminals. 

Jim Guinn, global managing director for cyber security in energy, chemicals, utilities and mining at Accenture has noted, “The cybersecurity conversation in the renewable energy engineering and construction business is almost nonexistent today.” It is imperative that such industries underpin their expansion with the appropriate focus on defence against cyber attacks.

Protecting your software stack

The way today’s technology solutions are created using a jigsaw puzzle of multiple pieces including published APIs, integration with proprietary products, cloud applications from different vendors, open source components all combined with in-house developments means that many organisations are unsure about their complete Software Bills of Materials (SBOMs). This means vulnerabilities are literally built into critical systems introducing undocumented threat vectors which can be used by hackers to gain access to proprietary systems and data.

This lack of knowledge about an organisation’s SBOMs means that even when a bug or vulnerability is identified in the open source community and patches created, the business can be completely unaware  of the fact that it needs to take remedial action. There are many examples of this type of oversight resulting in huge costs and disruption for business.

Secure by default – building resilience

In 2023, developers and publishers of software must focus on Secure by Default principles if systems are to avoid the kind of failures due to poor security posture and an over reliance on end-users to act in a secure manner. The user experience is an integral part of the security features of a system, because if security makes software inconvenient to use, end-users will simply find a workaround. If security isn’t second nature then it’s no security at all.  The UK Government has introduced tough new regulations in the Telecommunications (Security) Act which includes the requirement to have a deep understanding of security risks, including those within the supply chain. This builds on the premise that ‘edge’ devices such as radio masts, internet equipment, or wifi routers supplied to customers should be protected from cyber attack. 

NCSC Technical Director Dr Ian Levy made the point: “We increasingly rely on our telecoms networks for our daily lives, our economy and the essential services we all use. These new regulations will ensure that the security and resilience of those networks, and the equipment that underpins them, is appropriate for the future.”

Online risks spill over into the physical world

Increasingly, online services are impacting people in the real world.  A high profile example is the fall out from the 2017 Equifax data breach, which it is estimated to have cost the company at least $1.38 billion, with some sources suggesting the final bill could be closer to $2 billion. The root cause of the data breach was the failure to patch a known open source web application security flaw. This left the cyber doorway open for criminals to enter and cause havoc. Over 140 million U.S. consumers’ data was affected, putting them at risk of future financial instability—being unable to rent housing, being denied a loan, having to pay higher interest rates on credit cards or mortgages, and greater difficulty in getting a job, not to mention the distress and anxiety identity theft causes.

A more recent example, described as the biggest hack in history that affected telco Optus, led to one in three Australians at risk of identity theft or fraud. As a result, 10,000 victims have had their personal details published online and millions of people are scrambling to change their online driving licenses.  T-Mobile data breach that affected 37 million accounts was detected in January 2023 but the weakness in the API had been exploited since November 2022.

Automating Development & Security Operations (DevSecOps)

As software development accelerates and the attacks of malicious actors continue to increase in speed and intensity, organisations must ensure their security operations are equipped to respond equally fast. Preventative strategies can be built into the development workflow to ensure that DevSecOps processes are efficient and maintain the appropriate vigilance without wasting human resources.  Such processes become operationally effective if for every critical patch released, the security and development teams are ready with normal business practice to identify the threat, confirm its presence in their application software estate and remediate as quickly as possible as part of business as usual.  Without DevSecOps, such operations can take days to weeks, but forward thinking teams will have worked this out so such incidents take minutes to hours, thus preventing unauthorised access or infiltration of malware via an open source vulnerability.

With some 64% of companies impacted in 2021 by supply chain attacks, mostly due to increased reliance on open source software components, organisations must be scrupulous about checking that underlying dependencies are safe from vulnerabilities. A further study showed such attacks were up 300% compared to the preceding year.  Businesses that prepare thoroughly against such risks will be well rewarded.  Not only are they underpinning their own operations, ensuring that their business can continue to grow and innovate without hindrance from malicious attacks, they protect their reputation by providing reliable products and services to their customers. In turn, customers know that they can trust their supplier, building loyalty in the business that transcends a purely transactional relationship. 

Ensuring that technology works as it should has long been a given. Now it is an expectation that tech works securely, protecting personally identifiable information, while still providing a great user experience, so that people can get on with their lives, knowing that their trusted suppliers are looking after their data securely. It is a challenge for the entire technology industry, but one on which our very way of life depends.

Visit www.meterian.io to learn how Meterian can help secure your businesses’ open source components to reduce the threats of cyber attacks.

Cyber resilience is critical for innovation and economic sustainability

Want Cyber Insurance? Better get patching!

viviandufour, , , Leave a comment
Image from https://unsplash.com/photos/bq31L0jQAjU

Want Cyber Insurance? Better get patching!

Managing the technology stack and known vulnerabilities is becoming a key criteria for  cyber insurance pay outs

Open source software has once again made the headlines following warnings to organisations about the release of a new version of OpenSSL. Released on 1st November 2022, the new version patched vulnerabilities in version 3.0 and above of the nearly ubiquitously used cryptographic library for encrypting communications on the Internet.

The OpenSSL Project team took the unusual step of pre-warning organisations five days ahead of the 1st November release date that a critical update was being issued to address the vulnerabilities. This came as a surprise to many as the OpenSSL library rarely has critical vulnerabilities, but due to its popularity and widespread use, organisations were advised to be cautious and to prepare. 

Based on the assessment by the OpenSSL team, the vulnerabilities can be exploited and trigger data leakage or remote code execution. It is hard to predict the potential damage and risk of these vulnerabilities, which is why it’s vital for organisations to act swiftly, determine any use of the affected OpenSSL and patch immediately if they are exposed to the vulnerabilities. However, as these vulnerabilities were classified as “high severity” and not critical as initially thought, widespread exploitation is not expected. 

Open Source the foundation of modern software

The benefits of open source software are numerous and well known, so let’s be clear open source is not the problem – our ability to learn from the past is. 

There have been a couple of big open source incidents in the last year that have sent shock waves through the cyber security world. Firstly, the vulnerability in the widely deployed Log4J component, and now this new vulnerability in OpenSSL. This is only the second such flaw ever found in the open source encryption project. The first was Heartbleed.

The December 2021 zero-day vulnerability in the Java logger Log4J, known as Log4Shell, was characterised by many security experts as the single biggest, most critical vulnerability of the last decade. If left unpatched, attackers can hack into systems, steal passwords and logins, extract data, and infect networks with malicious software causing untold damage, not least to brand reputations. 

Unfortunately, a situation that specialty insurer Crum & Forster, owned by Fairfax, know all too well after falling victim to the hacking group known as RansomHouse. Despite widespread news coverage of the Log4shell vulnerability, which was revealed in December 2021, it appears the insurer was still vulnerable. 

The breach at Crum & Forster was first discovered on 22nd July 2022. The hacking group were able to exploit an unpatched system, resulting in a total of 1.7 gigabytes of sensitive data being released, including medical information, insurance policies, employee data, and customer lists. 

Crum & Forster are by no means an isolated case, there are many examples over the years of companies falling victim to known vulnerabilities. 

History repeating itself

The Heartbleed vulnerability, discovered in 2014, impacted hundreds of thousands of web and email servers worldwide. Among the many systems confirmed to be affected were large organisations such as Yahoo, Eventbrite, and even the FBI’s own website. Many of the big companies confirmed to be affected were able to get their ducks in a row and patch before anything severe happened. 

Others weren’t so quick off the mark and hackers were able to exploit the vulnerability in several cases. The Canadian Revenue Agency was one of the many victims that suffered a breach as hackers exploited the Heartbleed vulnerability. The breach resulted in the theft of hundreds of social ID numbers in a six-hour period before the Canadian Revenue Agency realised and removed public access to its online services. 

In the aftermath of a breach, companies are quick to express that lessons will be learnt. Unfortunately, in a case of history repeating itself, the Canadian Revenue Agency was once again hitting the headlines. In 2017, just 3 years after Heartbleed, the company had to shut down its website for filing federal taxes due to falling victim to the open source Apache Struts2 vulnerability. 

Fail to patch, plan to fail 

Several years on from when Heartbleed was discovered and a patch issued, there are still servers harbouring the Heartbleed vulnerability. In November 2020, a security researcher at the SANS Internet Storms Centre discovered that over 200,00 machines are still vulnerable to Heartbleed. The news cycle may have moved on but that doesn’t mean unpatched vulnerabilities have disappeared. 

Too many headlines are showing that hacks have one thing in common, they are caused by a known vulnerability within an open source component. 

A well know example is the Equifax data breach in 2017, which remains one of the largest cybercrimes related to identity theft. The private records of 147.9 million Americans along with 15.2 million British citizens and approximately 19,000 Canadian citizens were compromised in the breach. 

A key security patch for open source software Apache Struts was released by the Apache Software Foundation on 7 March 2017 after a security exploit was found. All users of the framework were urged to patch immediately. 

For one reason or another, the patching process within Equifax completely broke down, resulting in vulnerable systems being left open to compromise. Subsequent scans conducted by the Equifax IT department to identify any vulnerable systems appears to have failed and, as the saying goes, the rest is history. 

The cost of downplaying security

Recent estimates suggest the 2017 Equifax data breach cost the company at least $1.38 billion, with some sources suggesting the final bill could be closer to $2 billion. The root cause of the data breach was the failure to patch a known open-source web application security flaw. The company effectively left the door open for cyber criminals to walk in and wreak havoc.

In the aftermath of the breach Equifax was condemned for its lax security posture, shambolic emergency response and poor leadership, which led to many senior executives being accused of corruption. The Equifax breach investigation highlighted several security lapses that allowed attackers to enter, allegedly secure, systems and exfiltrate terabytes of data. 

More than five years on, the Equifax data breach remains a cautionary tale in failing to manage cyber security risk effectively and lacking the tools and processes to implement a robust vulnerability and patch management regime.  

Cyber Insurance: prove it or risk losing it

Cybercrime has become a highly lucrative operation; it is not going away and is only set to worsen as companies continue to engage digital technology. Many have taken out cyber insurance to insulate themselves from the punishing costs of cyber-attacks and data breaches. 

However, companies across the world are likely to face increases in the cost of insurance as the number of claims increase year on year. According to research conducted by FitchRatings, US claims volume has risen 100 percent annually over the past three years. 

In part as a result, the cost of cyber insurance has risen steeply in 2022 in both the US and the UK. According to Marsh, the UK cyber insurance market experienced a pricing increase of 102% year-over-year in the first quarter of 2022.

As a result of rising claim costs, the insurance industry is tightening their qualifying requirements and limiting their coverage. Cyber insurers now require organisations to provide information about their security controls if they want coverage. This can include technical, procedural, and human controls. 

Keeping track of your open source exposure

Software Bill of Materials (SBoMs) are an emerging approach to keeping track of your software dependencies, both open source and commercial. SBOMs provide the ingredients list to understanding what code exists within the applications that your business relies upon. 

Only by understanding what exists inside applications can organisations evaluate their exposure to risk. Used effectively, SBOMs enable companies to evaluate and target remediation efforts. But most importantly, companies won’t be blindsided when the next big open source vulnerability is announced. 

Known vulnerabilities are your responsibility 

Many cyber insurers have tightened their standards and are no longer paying out for breaches that have resulted from a known vulnerability. This should serve as a sharp wakeup call to boardrooms that deploy technology, with little thought to the security implications. If companies want to ensure they continue to receive all the benefits of their policy, it’s vital that they have a rigorous patch management system. Corporates may have short memories when it comes to known vulnerabilities but, as the evidence shows, cyber criminals do not. 

Companies must increase visibility and transparency of the components in their open-source software and applications if they are to stay one step ahead of cyber criminals. Without continuous management of your governance, risk, and compliance of open source your company is walking a tight rope, without a safety net. Those that fail to learn from history are doomed to repeat it.

Want Cyber Insurance? Better get patching!

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

An introduction to the world of SBOMs

viviandufour, , , Leave a comment 
3 minute read

We are sure many of you have been hearing about SBOMs. Nowadays, software include some components with code written by your own developers, but 80-90% of the code is typically from third-party developers. How can you know who produced what and when it absolutely needs to be replaced? Since Meterian has been managing SBOMs for awhile, we’re happy to share our know-how so you can consider a comprehensive strategy to manage your open source software supply chain. 

Photo by Raymond Rasmusson on Unsplash

What is an SBOM?

SBOM is an acronym that means Software Bill Of Materials. The concept originates from the manufacturing industry, where a bill of materials lists dependent components in machinery. A SBOM lists all third-party components present in your application. A good SBOM also lists the licences used by each component and, when possible, the specific copyright attribution. An excellent SBOM can also provide further information, such as possible relationships between those components to better understand any supply chain risk. You may have encountered SBOMs in the past, known as “third party notice” documents created to manage legal requirements, such as the one in the image below. 

Altova Third Party Software License Notice

However, modern SBOMs are “machine-readable”.  They follow a strict specification that can be understood by a computer. 

What machine-readable formats are used to publish SBOMs?

The most commonly used formats to define a SBOM are:

  • CycloneDX, a lightweight open-source standard designed for use in application security context and supply chain component analysis. This originated from within the OWASP community.
  • SPDX, an open source format with origins in the Linux Foundation, slightly more complex, and recently approved as ISO/IEC standard in version 2.2.1 as ISO IEC 5962:2021.
  • SWID, another ISO/IEC industry standard used by various commercial software publishers.

All these formats support a variety of use cases, but the first two (CycloneDX and SPDX) are the most versatile. Due to SPDX’s complexity, we think CycloneDX has an edge at this time, but only time can tell which of these formats will be the winner. To learn more about these formats you can also read the official NTIA publication, which drills down into the matter.

Why are SBOMs important? And how are they useful?

As a consumer of software, the main reason why you want to have access to the SBOMs of the systems you are using is to manage risks. When a very commonly used software component becomes vulnerable: how do you know what you need to patch and which subsystems are at risk? This is exactly what happened with the recent Log4Shell debacle. The logging library called Log4j, was suddenly exploitable with a very simple and repeatable attack. How do you know where it is? Which one of the systems you are using is suddenly at risk?  With a correctly managed archive of SBOMs, getting this information reduces to a very simple lookup task. Without it, it can be a real nuisance —a time consuming information hunt that disrupts everyone’s work flow.

As a producer of software, instead, you want to preserve and maintain an archive of all the SBOMs of the system you produce so that you can create and distribute timely patches to your customers. Having a systematic and comprehensive analysis of your most commonly used software packages would be useful indeed. Some companies were very fast in releasing patches to their customers, while others were extremely slow, mostly because they did not have the information.  You probably want to be in the first group of companies 🙂

Governments are also mandating the need for use of SBOMs, realising that software security needs to be regulated.  The U.S. Executive Order 14028 that mandates all federal agencies to require SBOMs from their suppliers.  This not only impacts the companies that have direct sales to the US government but also their own software suppliers.  As so many systems and devices have been connecting to the Internet to send and receive information, consequently our digital world relies on a software supply chain.  This “ripple effect” will be significant for many industries. 

It’s important to consider how software products you produce can meet basic security requirements and how the associated software security information is produced and managed in your organisation.   Similar legislation has already been proposed in Europe since the publication of  “Guidelines for securing the IoT” by ENISA (hint: SBOMs are required) and the ETSI EN 303 645 global standard for consumer IoT security, which is based on the UK government’s Code of Practice.  See also the recently published Product Security and Telecommunications Infrastructure (PSTI) Bill and more to come from the UK government to improve the UK’s cyber resilience.

How should SBOMs be handled?

Very carefully :), because an SBOM contains the full list of the “ingredients” of your system or application. While open-source projects happily share this information to the world, the same does not apply to private companies. In fact, a malicious actor that gets hold of the SBOM of your system can then check if you are using any vulnerable components. There are public vulnerability databases, such as the NVD, which are very popular. Someone can simply browse in there and compose a list of possible attacks, try them, and maybe get lucky.  Probably 9 out of 10 vulnerabilities affecting components in your system won’t be exploitable, but having the ability to go through the whole list, certainly makes the task of finding an exploit much easier. 

There’s no need to keep SBOMs a complete secret, however, as long as a few simple principles are kept in check:

  • SBOMs need to be shared securely,
  • they need to be accessed only by the authorised parties, across organisational boundaries, and
  • they should not be tampered with.

In summary, it is essential to produce a precise SBOM, and it is just as vital to share it and maintain it securely with the correct (trusted) third parties.  

Why bother with SBOMs now?

In summary, it is essential to produce a precise SBOM, and it is just as vital to share it and maintain it securely with the correct (trusted) third parties.  In our hyper connected world, comprehensive coverage of components is important for preventative strategies and threat detection in supply chain attacks.  Therefore, implementing SBOM management proactively now will be worth something to your organisation when the next critical vulnerability appears and stand your organisation in good stead. All good collections are worth organising. How valuable is your collection of software?

Photo by Susan Q Yin on Unsplash

Get started with SBOMs

The need for SBOMs is already high. Level up your open source software security and implement this requirement. Check out the SBOM capabilities in Meterian-X platform’s approach to DevSecOps.

An introduction to the world of SBOMs

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

bbossola, , , Leave a comment

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?

Read up on more Node.Js Vulnerabilities!

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

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

Victoria C., , , , , , Leave a comment
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

New Python Vulnerabilities!

Victoria C., , , , Leave a comment
Image of thief climbing out of laptop shining flashlight on Python icon, titled Vulnerability Focus: Python.

In honour of Meterian introducing Python into their beta production, here are two Python vulnerabilities which you should look out for. We don’t like it when systems or computers behave in unexpected ways. It’s worse when such outcomes result in a cyber security incident. This month’s Python vulnerabilities can cause unexpected behaviours which hackers could exploit to compromise the integrity of your system in unpredictable ways. Don’t waste any time as you could be affected, so read on and learn how to avoid these risks.

  • CVE-2019-18874: through python-psutil versions 5.6.5 there are risks of double free consequences. Attackers could use this issue to cause psutil to crash, therefore a denial of service, and possibly execute arbitrary code.
  • CVE-2019-17626: ReportLab through 3.5.31 allows remote code execution because of toColor(eval(arg)) in colors.py. This vulnerability could affect confidentiality, integrity, and availability within your software/network.

CVE-2019-18874

Vulnerability Score: 7.5 / HIGH

Platform: Python

Component: python-psutil

Affected Versions: up to 5.6.5 inclusive

Indeed…Python has a vulnerability within the package python-psutil. This was discovered on the 11th November 2019 by Riccardo Schirone who noticed that the psutil incorrectly handled certain reference counting operations. 

Python-psutil, is a Python package which provides convenient functions for accessing system process data. It is a cross-platform library for retrieving information on running processes and system utilization in Python. It is mainly used for system monitoring, profiling and limiting process resources and management of running processes. Psutil supports a range of platforms: Linux, Windows, macOS, FreeBSD, OpenBSD, NetBSD, Sun Solaris and AIX.

How does this vulnerability happen? It was caused by incorrect reference counting handling within for/while loops that convert system data into said Python objects. If an error occurred, the reference counter would be dropped twice.   In this case, the computer system’s memory storage is mishandled. Essentially, a double free releases the same area of memory twice.  

How can hackers take advantage of the system? They could use this vulnerability to cause the psutil program to crash which could lead to a denial of service and potentially the execution of arbitrary code. This execution of arbitrary code will provide the attacker with the ability to execute any command of their choice in a target machine or process. Like landmines, this vulnerability is unpredictable and hard to spot. The idea is that the hacker is waiting for the system to trip up in order for the “landmine” (malicious code) to set off and infect the users’ system.

Image of an area with signs saying 'Danger!!!Mines!!!'
https://flickr.com/photos/anzclusters/3404799066/

To remedy this vulnerability, please upgrade to version 5.6.6 or higher of python-psutil. Upgrade fast Python users, you don’t want to be at risk of a cyber attack.

CVE-2019-17626

Vulnerability Score: 9.8 / CRITICAL

Platform: Python

Component: reportlab 

Affected Versions: up to 3.5.31 inclusive

Yes that’s right! We have one more Python vulnerability to inform you on. This one is found within ReportLab up to 3.5.31 and it has allowed remote code execution because of toColor(eval(arg)) in colors.py. This vulnerability was found on the 10th October 2019 and has been classified as critical. The issue is affecting the function toColor of the file colors.py. 

An image displaying the lines of code which show where the vulnerability was found.
https://bitbucket.org/rptlab/reportlab/issues/199/eval-in-colorspy-leads-to-remote-code

ReportLab is an open source engine for creating data-driven PDF documents and custom vector graphics. So it is free, hence open-source and widely used to generate reports in Python. The package sees more than 50,000 downloads per month, it is embedded in many products and was even selected to power the print/export feature for Wikipedia. So you can understand now why this vulnerability is critical and urgently needed to be fixed by users.

The issue with this vulnerability is that the manipulation of the input value to <span color=” can lead to a privilege escalation vulnerability. Not only can this attack be initiated remotely but it will impact a user’s confidentiality, integrity and availability. To make matters worse, it has been said that the price of this exploit be around USD $0-$5k since last stated on 16/10/19.

An image of 3 eggs, 2 white one brown. The first egg has a bubble which says in remarks to the brown egg 'Hey how'd you get in here?' and the brown egg has another bubble which says "Oh no they found me". This image represents the vulnerability discussed.
https://www.pexels.com/photo/eggs-in-tray-on-white-surface-1556707/

To remedy this vulnerability, please upgrade to version 3.5.32 or higher.  This is different from the recommendation of NVD which suggests to upgrade to version 3.5.26 or higher.  NVD also references the incorrect CWE, which should be corrected to CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code (‘Eval Injection’).  Based on Meterian’s analysis, we only see the remediation implemented in versions 3.5.32 or later.  You can verify the code here. 

Spread the word on these critically-rated, easy-to-exploit Python vulnerabilities in order to help the app sec community defend against unwanted exploits. 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.

New Python Vulnerabilities!