Uncategorized

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?

The new social network from Trump may violate the AGPL license.

bbossola, , , Leave a comment

It looks that everybody can misread a license, even a former President of the United States. The Software Freedom Conservancy (SFC) concluded that Trump’s new social network, “Truth Social”, violates the terms of the AGPL license. It looks like the code of the system is simply a copy of Mastodon, an existing open-source social network licensed under the AGPLv3 license. That license is a (very infectious) copyleft license, it specifically states that every user is entitled to receive the complete source code of the system. “Truth Social” is not compliant on this aspect, and also violates the license calling their software “proprietary”.

“…an entire open-source platform was just copied with no regard to the license…”

This is a very common mistake: nowadays software is built by hundreds of open-source components and license compliance is a very complex task, you can read an explanation in this article. However, in this instance and based on the SFC analysis, an entire open-source licensed platform was just copied and reused, with no regard to the license.

So what are the options for Truth Social at this time? I believe they can: 

  • release the derived system under a compatible open-source license, most possibly the AGPLv3 itself, and make their code publicly available
  • obtain a license for commercial use from the Mastodon contributors, but I doubt this will be possible, also given Mastodon view on Gab, another right-wing social
  • rewrite everything from scratch and relaunch

Of course, they may also fight this in court, but having seen some of the evidence from Mastodon, I doubt this is going to be a successful choice. It will be interesting to follow how this will evolve.

*** UPDATE ***

The Gab team, threatened by legal action, decided to release the source code publicly!
https://uk.pcmag.com/social-media/137421/trumps-social-media-site-quietly-admits-its-based-on-mastodon

The new social network from Trump may violate the AGPL license.

Update to terms and privacy policy

viviandufourLeave a comment

We have updated our terms and conditions and privacy policy as our business grows to serve more customers across the software industry in financial, cybersecurity, e-commerce, health, IT and telecommunications sectors.  We look forward to welcoming more customers who want to secure their open source software supply chain as part of secure app development. Software developers, security officers, quality assurance and legal compliance professionals can benefit from easy to read reports to streamline their decision making processes.

Get in touch to book a demo! 

Update to terms and privacy policy

Making the most of Christmas, Part 2

viviandufour, , , , , , Leave a comment

11 min read

In the second of our three part blog series as we lead up to Christmas, the Meterian Team shares with you shortcuts to make the most out of what you already have.  

A library, component, piece of code is reusable when it can be re-used in different parts of the same or different project with minimal to no need of code modifications. 

Scanning for, identifying, and patching open source dependencies in an application’s codebase is known as dependency management. This is a critical part of modern software development since nearly 100% of codebases are made up of open source components. These dependencies can be directly used by your application or indirectly used through transitive relationships. You can imagine the number of connected components if your software codebase has hundreds of modules.

Many vulnerabilities remain, leaving software applications unsecured

In our analysis of 1310 website applications,  the most popular component with a security vulnerability was jQuery.  Out of 332 javascript components used across all the web apps,  81% of the components had a security vulnerability.  All of these vulnerabilities could be easily removed by simply upgrading to jQuery 3.5.1.  It’s great that software is reusable, but beware of the invisible stakeholder who preys on out-of-date components’ security holes.  Like fresh food, software components also have a “best before” date.  To get the most out of them before they go bad and become easy pickings for malicious bot-scripts of hackers, keep your code’s dependencies up to date. This is best done programmatically rather than manually.

Neither software development nor cybersecurity teams can keep up with all the changes and fixes required to keep the code performant and secure. Therefore, knowing how to leverage the right tools to detect and patch in a timely manner can make a difference in preventing a cyber breach spoiling a company’s business and reputation. In a Ponemon study last year:

  • 60% of respondents said their organisations suffered a breach due to an unpatched known vulnerability where the patch was not applied
  • 62% were unaware that their organisations were vulnerable prior to the data breach
  • 52% of respondents said their organisations were at disadvantage in responding to vulnerabilities because they use manual processes

Earlier this year another Ponemon report highlighted the need for a programmatic approach to managing vulnerabilities as unpatched known vulnerabilities remain a significant risk: “Over six months, an average of 28% of vulnerabilities remain unmitigated, and organizations have a backlog of 57,555 identified vulnerabilities.” Remember, even just one vulnerability exploited could lead to a cyber breach. Furthermore, 60% of open source programs audited had a vulnerability that’s already been patched.

For this blog, we present the top 3 most popular components found from our survey of 1310 web applications past their “best before” date. Below are recommended substitutions for an alternative or updated component that is vulnerability free so you can #BoostOpenSourceSecurity in your software applications:

  • jQuery 1.12.4  -> Please update to jQuery 3.5.1
 1 high level threat:  Affected versions of jquery interpret text/javascript responses from cross-origin ajax requests, and automatically execute the contents in jQuery.globalEval, even when the ajax request doesn't contain the dataType option. 
 Recommendation: Update to version 3.0.0 or later.
  • handlebars.js 4.0.11 ->  Update handlebars module to version >=4.6.0
 1 high level threat: Versions of handlebars prior to 3.0.8 or 4.5.3 are vulnerable to prototype pollution. It is possible to add or modify properties to the Object prototype through a malicious template. This may allow attackers to crash the application or execute Arbitrary Code in specific conditions.
 1 medium level threat: Affected versions of handlebars are vulnerable to Denial of Service. The package's parser may be forced into an endless loop while processing specially-crafted templates. This may allow attackers to exhaust system resources leading to Denial of Service.. Recommendation: Upgrade to version 4.4.5 or later.
  • Twitter-bootstrap 3.x.x (3.3.7)  -> update to the next safe version 3.4.1
 1 high level threat: XSS in data-template, data-content and data-title properties of tooltip/popover
 1 medium level threat: In Bootstrap before 3.4.0,  XSS  (cross site scripting) is possible in the affix configuration target property.

Remains of the day

At the end of the day, updating your application’s dependencies is easy if you know what to look out for, when to apply the update, and have an automated workflow to help you do this consistently and at scale.  Finding the right combination of open source components to help speed and secure your development is one example of how “Necessity is the mother of invention.” Meterian speeds up the task of keeping your open source dependencies up to date easily and continuously so developers can focus on the main course of innovating securely.

In the spirit of giving this Christmas and to fuel the creative cooks out there (perhaps you or that important person in your life who always makes sure a delicious meal is ready for you at dinner time!), here’s how to use leftover Christmas veg to make two speedy suppers:

Linguine with with cavolo nero and bacon

Serves: 4
Prep time: 10 minutes
Cooking time: 20 minutes

Ingredients
400g linguine
olive oil
6 slices smoked streaky bacon, cut into 1cm or bite size pieces
1 tbsp olive oil
2 shallots, finely chopped
2 garlic cloves, crushed
300g cavolo nero, hard stalks removed, and roughly chopped (shortcut: blitz the shallots, garlic and cavolo nero leaves in food processor until finely chopped)
75ml double cream (optional)
2 egg yolks
¼ nutmeg, freshly grated
50g parmesan cheese, finely grated
salt & freshly ground black pepper 

Tip: No cavolo nero?  Don’t get stuck in a rut.  Try any slightly bitter green veg, such as brussels sprouts, broccoli, broccolini, gai lan, or rapini.  All lend a lovely nutty flavour balanced with the delightful pungence of parmesan cheese and black pepper.

 Instructions
 Cook the linguine in a pan of boiling, salted water following the pack instructions. Meanwhile, heat some olive oil in a large frying pan, and cook the bacon for a couple of minutes. Add the shallots and garlic cloves, and finely chopped cavolo nero to stir-fry with the bacon.  After 3-4 minutes,  take off the heat.
Mix the cream and egg yolks with with the nutmeg, ⅔ of the cheese and some black pepper.
Put the bacon and veg stir fry back on the heat, add a little of the pasta cooking water and simmer down to 2 tbsp.
Drain the cooked pasta, and add the pasta to the pan with the cavolo nero-bacon and cream mixture. Next add the remaining grated parmesan cheese, and season with more salt and pepper to taste. 
Cod, Chorizo and Potato Stew

Serves: 4
Preparation time:10 minutes
Cooking time:30 minutes

Ingredients
110g chorizo, cut into 2cm slices
1 onion, sliced
1 garlic clove, crushed
4 potatoes
1 can of chopped tomatoes (220-250g)
500ml fish stock
600g frozen cod fillets, defrosted and cut into 3 - 4cm chunks
20g flat leaf parsley, chopped

Instructions
1. Heat a large pan over a medium heat and cook the chorizo for 2 - 3 minutes, then remove from the pan and set aside. Drain all but 1 tbsp of fat from the pan and use to cook the onion and garlic over a medium heat for 6 - 8 minutes until soft. Peel potatoes and cut into 3cm chunks.  Put the potatoes in the pan with the chorizo and cook for 3 minutes.
2. Add the tomatoes and fish stock, bring to the boil and simmer for 10 - 12 minutes until the potatoes are tender. Stir in the cooked chorizo. You can freeze the stew at this stage, letting it cool to room temperature first.
3. If cooking from frozen, defrost the stew overnight in the fridge or in a microwave, then reheat. Add the cod to the stew and simmer for 4 - 5 minutes until just cooked. Season and serve immediately, scattered with parsley.

“The evening’s the best part of the day. You’ve done your day’s work. Now you can put your feet up and enjoy it.”

― Kazuo Ishiguro, The Remains of the Day

The tools that boost your efficiency when your coding project has a handful developers may need to be very different from the software that keeps your project humming when you have 1,000 or more. We’ve designed Meterian to evolve with your application security tech stack as your software engineering and digital transformation needs evolve. If your open source dependency management system is not humming smoothly with your software development life cycle, or your open source components are decaying and reducing their life time value for the organisation, consider reusing and securing your software components with Meterian. Get in touch today.

Making the most of Christmas, Part 2

Making the Most of Christmas

viviandufour, Leave a comment

Recipes, ingredients and ideas to make your fuel (food and software!) go further.

In this three part blog series as we lead up to Christmas, the Meterian Team will share with you their work and christmas holiday hacks of life.  First and foremost, let’s get our coding projects secured so we can have some peace of mind over the holidays.

Five things to do this December and then forgeddaboutit until 2021

1. Sign up to Meterian free trial (5 mins)

2. Run your Security, Stability, Licence check and get to know your components (20 mins)

3. Triage: Automatically fix out of date components, set exclusions or identify issues to discuss a mitigation plan. (30 mins)

4. Schedule your action plan (20mins)

5. Automate it to run continuously with your favourite CI, GitHub Action, or BitBucket Pipe so your software dependencies are checked without you needing to be interrupted during any of your Christmas socials. 

This last step will require you to put in some time and effort.  Our customers have done this in minutes to several hours over 2 days.  The best part is that once it’s done and you’ve got it running automatically, you can just leave it running and put your feet up.  Or perhaps run off and be there for someone else who needs you.  Boost your apps’ open source security — Enjoy!

Making the Most of Christmas

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

Easyjet hacked, 9 million customer records compromised.

bbossola1 Comment

Easyjet today admitted it was hacked by a “highly sophisticated cyber-attack”. 9 million customer records were compromised, where email addresses and travel details had been stolen. Also 2,208 customers credit card details were stolen.

“Are we surprised? Honestly, we are not.”

Are we surprised? Honestly, we are not. A quick surface scan of the Easyjet website reveals that it is using at least two out of date and vulnerable components: jquery 1.11.2 and angularjs 1.4

jQuery is a popular package used to simplify manipulation of HTML via Javascript. Version 1.11.2 of the package was popular in 2014, when the Ebola pandemic started. Yes, the previous pandemic, not this one. Still, for some reason, somebody thought it was a good idea to keep using it in 2020. But hey, what if I like legacy? Well, there are a few problems related to such library version, but among all of them, I think the most relevant one is CVE-2015-9251. This vulnerability allows an attacker to cause the execution of arbitrary code using a cross-site scripting (XSS) attack.

Angularjs is another popular web framework used to simplify web development. Version 1.4 of this framework was mainstream in 2015, when we had a nuclear deal with Iran and Barack Obama was at the White House. Sweet. But even if we do really miss those times, you do not necessarily want to use such version of angular because of multiple XSS, DOS and security bypass issues that can easily exploited.

“We can see what’s on the frontend.
But what is the situation in the backend systems?”

Do we think that any of those two components can be the culprit of this hack? Well, we do not know. But remember: a system like the EasyJet.com is always composed of a frontend (the website itself) and a backend system, which contains the real business logic of the services (and usually your data).

So, if in the fronted we can see components outdated and vulnerable, what do we think the situation could be on the backend? Well, actually, we think it could be worse. As the frontend is usually easy to change and in fact changes frequently (think about new offers or new branding) the backend is usually a much more stable environment that changes less frequently. So it would be reasonable to expect a similar or worse situation on the backend code, with some outdated and vulnerable components. And this is scary.

“You should always know and assess your
risks due to opensource components”

However, this is also something any development team should always actively look into. Making sure that your opensource components are up to date and not vulnerable is a fundamental step in the development process. Meterian can help you do that (actually, it can do that for you and your team). Check out our one minute video that explains how meterian works:

And if at this point you want to learn more, please take a look at these two articles:

Remember also that you can check your website yourself with our online web scanner, and Meterian has also a free plan that you can start using today. Why wait?

Stay safe. Stay connected. Stay endless.

Easyjet hacked, 9 million customer records compromised.

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

Why do I need Meterian? My code is secure.

bbossola1 Comment

This is really a good question, that many potential prospects are asking us. For most of the time the answer is easy: we can point them to hacks to the likes of Equifax, British Airways, Carphone Warehouse and so on. But what if someone believes they’re already protected?

We are already checking our code!

Yes, some of us already have a SAST solution in place, like SonarCube or Fortify, and we think we are fully protected. Some of us instead use opensource alternatives, like Spotbugs or PMD, and we also feel okay. These tools will continuously scan your developers’ source code and make sure that it’s not including any pattern that could be exploited by a malicious hacker.

On top of that, we have already secure coding in place: we use peer reviews and pair programming, so that all our code is severely scrutinized. We use a set of agreed secure coding practices, we follow detailed checklists, and we have developers trained continuously on these matters. And yes, that’s good!

But not everything is written from scratch…

When developers code, they do not write everything from scratch. Have you ever been surprised at how little time it took a piece to be delivered? Maybe, just once. And you ask how did that happen? Your developers, rightly so, dipped into the big pool of opensource and pulled a component that was able to accelerate their development, providing ready to use building blocks so that they could concentrate only on the business logic.

Those opensource components are so widely used, that in your final packaged product, up to 80% of the code is made of those components. Only a mere 20% is the carefully crafted code by your developers, where your internal practices and existing tools make a difference. But who’s checking the security of those opensource components? Well, it so happens that many people across the world checks them. This allows the components to evolve quickly. When a problem is found, either a bug or a security problem, it’s rapidly fixed and a new version of the component is released. When this becomes a security problem, often the issue is publicly reported in specific mailing lists or newsrooms dedicated to security.

How do you know an opensource component needs to be updated?

The core problem is, how do you know about all this? How does your team become aware that a certain component they use is now vulnerable, and that they need to update to a new version? How do they make sure that the code they do not write, which could account for 80% of your product, is also secure? Do you maintain a team the does these things? A team that painfully scrutinises multiple news sources, makes sure that your application does not contain a vulnerable or out of date component, alerting your developers accordingly?

This is where SCA (Software Composition Analysis) like Meterian enters the scene. These products are a natural complement to tools like SonarQube or PMD, as they check the code your team did not write. Typically running along with your build system, they will prevent your product to go live if a vulnerable component is discovered and will provide your developers the information they need to fix the problem immediately (and, in some occasions automatically). You will be able to secure 80% of the code your development teams produce without investing a fortune, without further head count, and with a minimal integration effort.

So, if you do not have a solution for your opensource components in place, it won’t hurt taking a look at Meterian: it’s an all round affordable system that will give you peace of mind about the code that developers do not write. And, by the way, it also checks component licences, but this is for another blog post 🙂

Why do I need Meterian? My code is secure.