Uncategorized

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.

Vulnerability Focus: Ruby

, , , Leave a comment

After traversing the National Vulnerability Database for compelling open source security flaws this past month, we have identified the Ruby gem strong_password version 0.0.7 and mini_magick version 4.9.4 to have extensively critical security issues. Read on and spread the word about them with your application security community!

Meterian focuses on critical Ruby vulnerabilities this month. .

CVE-2019-13354

CVE-2019-13354 Ruby strong_password gem 0.0.7 is untrustworthy.

Vulnerability Score: Critical — 9.8 (CVSS v3.0)

Platform: Ruby

Affected versions: strong_password gem 0.0.6

Amber alert! A major vulnerability was found in the RubyGems repository earlier this month – the strong_password gem 0.0.6 was  hijacked, and the compromised version 0.0.7 was found to contain a security flaw, in which a code-execution backdoor has been installed to potentially give third-party attackers the ability to trigger arbitrary code execution (ACE) over the network.

In lay man’s terms, this simply translates to a stealthy backdoor which provides third-party attackers with complete remote access of the server of the Ruby application for which this gem has been installed; opportunistic attackers are then able to send malicious code to the command-and-control servers of the compromised system to execute a range of functions including Denial of Service (DoS) and privilege escalation (e.g. data exfiltration, password dumping).

This open-source security risk was identified by Tute Costa – he was performing a due diligence scanning for anomalies in the library’s changeset of the 25 gems he had upgraded for his Rails app project after realising he could not locate a changelog.md (a file logging all descriptions of changes for each version of an updated gem – think how Microsoft Word or Google Drive saves changes of edits made to documents) for strong_password 0.0.6 gem before it made its upgrade to version 0.0.7. He could not find the code for the updated version 0.0.7 of the strong_password gem and this discrepancy prompted Costa to cross-compare contents of the gem within his  rails app with that of the latest copy in Github.

This was where he discovered the updated version 0.0.7 gem does not belong to the original owner of the strong-password gem, but rather a pseudo account. He then dived into the code and figured out that new tweaks to the updated code for version 0.0.7 creates a loop within a new thread which fetches and executes code stored in a pastebin.com, but with an empty exception handler that ignores any error it potentially raises – this gives attackers remote code-execution (RCE) control  of the system as it will be able to bypass any error registered.

This strong_password gem is an entropy-based password strength checking installation for Ruby and ActiveModel. The previous version (0.0.6) had 39,955 downloads, whereas the compromised version 0.0.7, published on 25th June, raked in a total of 537 installations within three days before it was eventually yanked down on 28th June. Had this security flaw gone undetected and had these gem users decide to perform a bundle update on their APIs, over 30,000 web applications, libraries, servers, and system utilities could have been exposed to open-source security risks.

CVE-2019-13574

CVE-2019-13574  Ruby mini_magick version 4.9.4 has backdoor access to unwanted app server crashers. 

Vulnerability Score: Critical — 7.8 High (CVSS v3.0)

Platform: Ruby

Affected versions: mini_magick version 4.9.4

My oh my. Ruby open source gems are not looking too hot for application security this month! Harsh Jaiswal discovered a remote shell execution vulnerability  in mini_magick – a Ruby library interface that acts as a buffer between the ImageMagick / GraphicsMagick programs and your Ruby code by providing you with the tools and resources to transform and customize images for Ruby applications that is exploitable when using MiniMagick::Image.open with specially crafted URLs originating from unsanitised user input.

Similar to the aforementioned case of the strong_password gem, the vulnerability within this mini_magick gem allows attackers to perform arbitrary code execution (ACE) on servers; it essentially opens the path to access the image in ib/mini_magick/image.rb in the pre-4.9.4 version of the mini_magick gem. The image.open input (aka path to image) is passed to Kernel.open, which functions to accept the ‘|’ (pipe) character followed by a command. This use of Kernel.open represents a serious security risk as the pipe (‘|’) is a character that allows chain commands in the Linux terminal, which means the result of a single command could have further-reaching consequences. Therefore, when installed on an application, this compromised mini_magick version could open the door to  highly risky remote code execution on the hosting server.

This flawed version was downloaded over a million times, suggesting a large potential scale of impact for C2 backdoor attacks. Although a patch has been applied to version 4.9.4 of mini_magick, we believe the expansive list of gems using this flawed version means many developers and organisations might not be aware they have installed mini_magick due to the nature and ubiquity of open source work. Even if these gems do not necessarily use mini_magick in a way that exposes the program to the vulnerability, it is still well-advised to install the updated version of mini_magick 4.9.4 without the erroneous code. 

So there you have it! Go right on ahead to perform an update to secure your applications and software programs if they use these Ruby gems – you know it would give you peace of mind!

Alas, these 2 identified vulnerabilities are just two needles in a haystack; open source code can typically make up to 90% of most software programs, and this resulting pervasiveness of open source vulnerabilities means new security flaws are popping up like hotcakes. To better equip for your combat against exploitation by third-party attacks, it would be prudent to conscientiously scan for vulnerabilities in your software.

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

Vulnerability Focus: Ruby