Easyjet hacked, 9 million customer records compromised.

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.

Why do I need Meterian? My code is secure.

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.

What do we mean by “stability”?

When you open one of our reports you will see three different sections. At the top you will find our security section, that will tell you whether any of your components is potentially exposing your system to hacking due to known vulnerabilities. At the bottom, you will find our licensing section, that will tell you if any of your components are using a non-business friendly license. But what about the middle section, stability?

This is a concept which we’ve been working on for a while, and now it’s in its early stages. At the moment, in regards to a component, it’s basically an indication of how up to date it is. The stability report will provide you also with an upgrade path to any component your software is directly using, giving you the knowledge to move forward to the next version if you choose to. But is this advisable? Well, in general, yes, mainly because a new version usually includes bug fixes for issues you are not even aware of, performance enhancements and, of course, vulnerability fixes.

But should you always upgrade? And to the latest version? Well, the decision to upgrade has to be evaluated by the development team. For platforms using semantic versioning (the mast majority on the planet these days), it’s usually considered safe to upgrade in certain conditions, but let’s pause for a moment to understand how this works.

A semantic version number is usually in the format MAJOR.MINOR.PATCH and each part can be independently incremented against the previous when:

  • MAJOR: an incompatible API change has been implemented
  • MINOR: a new functionality has been implemented but it’s backwards compatible
  • PATCH: backward compatible bug fixes have been implemented

So for example version 2.5.3 means major 2, minor 5, patch 3. Following on the previous explanation. 2.5.4 is a patch release, 2.6.1 is a minor release and 3.0.0 is a major release.

We need to appreciate that these are all conventions, and may be overlooked sometimes! Some platforms have a more “creative” ways to think about minor releases, and that’s the reason we usually suggest that only a patch upgrade is safe. Even in that situation, you should always have your test automation, CI, and QA team to validate your release.

Is that all for stability? Well, for the time being, yes, but please stay tuned as we do have something else cooking in the area!

 

What do we mean by “stability”?

How the wrong license can harm your business

legaldoc

 

Friendly disclaimer.

First and foremost, let me immediately start saying that this article is not legal advice, but it’s my attempt to explain in a simple way the problems connected to software licensing: in case of emergency, call a lawyer 🙂

The problem.

Many people think that because you can download a piece of software without paying a fee it means that such software is free. But if something is freely available, it does not mean that the same thing is free to use. Some development teams have the expectation that, when including a software component in their own customised system, it simply becomes “part of it” inheriting their licensing model: this is simply not true.

Imagine, for example, that you are building a new revolutionary car, all electric, and self-driving! You will need a lot of software to make that happen, and certainly, you do not want to code everything from scratch. So you start first assembling some basic components, an operating system (Linux), some basic tools (BusyBox), some software from other vendors and then you finally write your magic code. Sounds familiar? Anybody said “Tesla” in the audience? And what happens when a competitor discovers that you are using open source software with a certain license (GPL) and asks you to provide them with your code, the valuable code you wrote… well, they can lawfully do so and you will have to comply! And so that’s what happened, and forced Tesla to start releasing its software on public repositories. But please, without leaving the car making business, see also BMW who handed over its i3 car code to a random guy, who immediately published it on GitHub.

The restrictions.

It’s important to understand the restrictions you face when you decide to use an opensource component. Even one single component with the wrong license can impose a restriction on all your source code.

  1. you may be forced to release your code under the same license. If you use a component licensed for example under GPL or AGPL (or even LGPL in case of derivative work), all your software will have to be released with the same license.
  2. you may be forced to release to the public your source code. If you use a component licensed for example under MPL or GPL, you will have to provide all your code in a human-readable format upon request (distribution of obfuscated code is not compliant).
  3. you may not be allowed to distribute your software commercially. Licenses like the Oracle BCLA will prevent that, and you can easily be sued (and you will most certainly lose).

But wait, what about the code that does not have any license? For sure I can use it without problems, right? And the answer is again a resounding no! Under current law, copyright extends for the life of the author plus 70 years (and sometimes 120 years after its creation), and the creator (or his/her dynasty) can simply sue you for using it. Unless a piece of code includes a license, do not use it.

The risks.

If you decide to not comply with a license, or you are simply unaware of the problem (this would be the most common case) you face two main risks.

First, you are in actual violation of contractual obligations. This can lead to a long case in court that, if you are lucky, you settle outside court, with money transferred. There are a lot of examples of that, with payments that go up to $100K (please see an incomplete list here), so I really think you should not discount this risk, also because in some cases, firms preferred to file for bankruptcy in order to avoid bigger losses.

Second, you may be in violation of statutory law, a corporate liability that may become also a personal liability. Corporate Criminal Responsibility derived from copyright crimes can also be extended to labour law, in case it can be demonstrated that the responsible was not carrying out his duties properly.

Solutions.

First and foremost you need to be aware of the problem. If you read this article until this point, you now probably are, so we can safely assume you are onboard with this point.

Now, assuming your company is building software, you need to make sure that all components your development team is using, and end up being part of the final product, are accounted for in terms of licensing. Remember: one single component in your chain can influence the whole system.

You will need then to create policies to allow/disallow certain licenses to be used and enforce them across your development teams. The best solution would be an automated one, which automatically detects violations and blocks unwanted releases.

Meterian to the rescue!

Meterian, among others, provides an elegant mitigation for this problem, which is also affordable and efficient. By placing Meterian in your development pipeline you can have continuous reporting about the licenses used by your software so that you can make sure you are not exposed to the risks explained before. Please have a look at one of our reports.

When Meterian is included in your development pipeline, policies can also be enforced so that the presence of certain licenses will stop the build to progress further, preventing the product to be shipped to the final customers.

Make sure to get in touch if you want to learn more!

How the wrong license can harm your business

Time to update your boots!

Bootstrap v4.3.1 and v3.4.1 are out and available to patch an XSS vulnerability, CVE-2019-8331. For any users of the legacy 3.3.7, this will fix also other three XSS issues, namely CVE-2018-14040,  CVE-2018-14041 and CVE-2018-14042. Bootstrap now include a JavaScript sanitizer that will only allow whitelisted HTML elements in the data attribute of an element.

It’s available through all the channels: as NPM package, via CDNs and for old fashioned guys also as a direct download from Github. You do not have any excuses now, please upgrade!

 

Time to update your boots!

The problem with opensource components

While opensource components are basically indispensable in modern software development, they also must be handled with care. In this post, I will explain in the simplest possible way the problem with opensource components: I am going to use a metaphor that seems to resonate well with our customers, which however may not be necessarily accurate from an engineering point of view.

Building a house.

When you build a house a lot of work has to be done, starting from the planning all down to the actual building of the foundation, infrastructure, walls, ceilings, and roof. This work is different for every house and very specific so that it’s necessary to have a very solid process to make sure the standards of quality are high enough from a variety of point of views. There’s an enormous amount of attention on every aspect and it’s always supported by a strict set of practices and processes.

Now, when you build a house, there are a lot of things you do not necessarily want to create from scratch: items like windows and doors, for example, are components readily available on the market in a variety of shapes and sizes. You do not need to build them from scratch: that would require specific craftsmen and a sizeable amount of time. You simply shop for those components, find the right ones and integrate them into your house.

As we are a security company, let’s focus on security for a moment. Your team built the walls and the infrastructure, right? With a very strict process that guarantees you that everything is solid, unbreakable and durable. But what about windows and doors? You bought those components off the shelf: what do you know about their quality? Are the locks durable? Are the glasses really break proof or are they affected by some design flaw? How much of your house did you have to buy from other manufacturers? And how long ago was it? What’s the warranty, and did you stay warm this winter or were the windows drafty?

This is the problem with opensource components.

Building a software application.

In a modern development process, your development team is “building the house”: writing the code that contains the business logic of your application. They also need a lot of other code to do various ordinary tasks, like talking to a database, exposing an API, talking to other services, exchanging data using a machine-readable format like JSON or XML. The opensource community has already available off the shelf components you simply incorporate in the project, saving huge amounts of money and dramatically shortening the time to market: those are the “windows” and “doors”. Worse than in a building, however, off the shelf software components can be up to the 80% of the code shipped to production, making them a very critical asset to keep under control.

What we are finding when we meet potential customers is that they have a very strict process with regards to their code, often supported by a variety of tools in order to make sure that the business logic code is solid and secure. The same attention, however, is not extended to the opensource components used, which are simply bundled with the code shipped to production.

The opensource components are like the “doors” and the “windows” of your “house”: are they secure? Every day an average of 40 new vulnerabilities are discovered in external components, and new versions of those are often released monthly. It’s critical to keep the components used in your applications up to date and replace them immediately, to avoid something like what happened to Equifax, that simply did not update a vulnerable software component, Apache Struts.

graph-2

(source: vulndb)

Do you know how much of your base is opensource? Do you know when you updated it last? And do you know every noteworthy detail of the updates from those external components?

What can you do?

Our software, Meterian, does exactly that job. It will continuously check the opensource components used by your business logic so that you will not have any nasty surprises because of them. It takes 5 minutes to set it up in your process, and you can also simply run it on your codebase with no installation at all. You do not need to be a developer to run it and it produces also a clear report that is understandable and actionable right away.

We strongly encourage you to give it a try, or maybe just have a look at our reports for some common libraries like Alibaba/FastJson or Netflix/Zuul, both scoring a resounding 0 in security at the time of writing.

Keep your house safe, keep all external components under control.

Get an instant analysis of your first codebase for free.  See the risks immediately and know which components to remove or upgrade to secure your app. Sign up here to download the Meterian client today.

The problem with opensource components

Meet Meterian at the next Gerrit summit

gerritsummit

Meterian is happy to announce that it will be presenting at the next Gerrit summit in Paolo Alto, California, an innovative Jenkins based solution to ship software without vulnerabilities using Gerrit Code Review and Robot Comments.

What if fixing vulnerable components was something that can be completely automated? And what if it could fit nicely in the amazing review process used by Gerrit, leaving to the humans just the burden of the last click?

Well, we think that with Robot Comments now this is possible! Join us on Friday in the Cloudera Galactic HQ and see how!

Meet Meterian at the next Gerrit summit

New vulnerabilities in jackson-databind

The jackson-databind saga continues and today 4 new vulnerabilities have made their way into the NVD database. Still not “officially” confirmed, they are there to stay, as you can probably guess looking at the project bug report:

  • CVE-2018-14718: remote code execution via slf4j-ext
  • CVE-2018-14719: remote code execution via blaze-ds-opt
  • CVE-2018-14720: exfiltration/XXE with only JDK classes (some JDK versions)
  • CVE-2018-14721: exfiltration/SSRF with axis2-jaxws

Things are becoming quite tricky as the project is trying to keep up with four different main codebases (2.6.x, 2.7.x, 2.8.x, 2.9.x) plus the new development in progress. This is all about the ability to use the deserialisation mechanism of Jackson in order to perform mischiefs using, in a very creative way, some standard classes (see an example exploit documented a while ago on my personal blog) and all due to a blacklisting mechanism that continues to require updates.

You can also read a full account of the problem here, but for the time being, I would suggest using Gson instead, at least until a 3.x version of Jackson is out.

New vulnerabilities in jackson-databind

Meterian is part of Cylon cohort 8!

We are excited to announce that CyLon, a London based cybersecurity accelerator, and seed investment programme, selected Meterian as part of cohort 8! CyLon has already successfully accelerated 59 companies across hubs in London and Singapore since its launch in April 2015 and has a portfolio of international companies now valued at more than £200m.

We will be part of a selected group of startups covering a mix of security areas. We are joining CyLon for three months and we will receive an intensive programme of training and workshops delivered by industry specialists and experienced entrepreneurs, all in associations with CyLon’s unrivaled network of investors, buyers, and mentors across EMEA and the US.

On top of that, we will also have access to a fully-furnished office space, and for the next three months, we are looking forward to meeting you here at CyLon: please do not hesitate to book a meeting, we will be happy to share a proper coffee together!

 

 

Meterian is part of Cylon cohort 8!

SAST, DAST, RASP, IAST explained

If you are working in application security you certainly heard one or more of these terms, but what’s the real meaning behind the acronym? In this article, I will try to clarify this tongue twister list.

SAST: Static Application Security Testing

This family groups all the technologies dedicate to test the security of code at rest and will try to detect possible security issues, based on some strategies or policies.

This category can be further divided into three others:

  • SCA – Static Code Analyzers
    They scan the code, in source or binary format, looking for patterns that can lead to security issues, they can also enforce guidelines and policies. There’s a lot of choice of tools in this area, but I think you should always include Error Prone, praised by Doug Lea.
  • SDA – Static Dependency Analyzers (also known as SCAN)
    They scan the external component pulled along your code build looking for known vulnerabilities that can potentially expose the code to exploits later. It’s worth mentioning here that on average 80% of the code you ship it’s not your code but is somebody else’s code! Meterian, our host here, is, in fact, a SAST/SDA tool.
  • SIS – Sensitive Information Scanners
    They scan the repositories where the code is stored in search of sensitive information inadvertently stored in them that can subsequently be leaked. It might sound a trivial thing to check, but it’s just good security hygiene to have one of such scanners in place. The effective to use greatly depend on your SDLC process, but I would strongly suggest using one of them, such as for example GitLeaks.

DAST: Dynamic Application Security Testing

This family groups tools used to test an application in an operating state (but not in production) using automated black box testing. They also frequently include specific security tests where the system tries to feed the application with malign data to simulate common patterns of attack. They interact with exposed interfaces such as APIs, network protocols, web pages. One opensource incarnation of such system is the Ebay DAST Proxy, released to the opensource community in late 2016.

RASP: Run-time Application Self-Protection

This is a very interesting category of tools where an agent is embedded into the application so that it protects the system at runtime and it’s typically deployed directly in production. The most common scenario sees the RASP agent “melted” with the application code through code instrumentation so that it can directly analyze the application behavior, providing active protection. A RASP, after detecting and blocking the attack, can shut down a user session, stop executing the application, and sometimes it also offers the ability to deploy code fixes at runtime. It also provides detailed reports that can be fed to monitoring systems. Baidu, the Chinese multinational technology company specializing in Internet-related services and product, is actively maintaining OpenRASP, an opensource RASP solution that works on Java and PHP web platforms.

IAST: Interactive Application Security Testing

These family of tools usually combine the RASP and DAST approaches: when testing an agent is embedded in the application while the test system executes attacks. This is a fully automated process so that it can be embedded in a continuous delivery system and ensure that a certain level of checking is done at frequently, even at every release, and with no human intervention.

Conclusions

What shall we do? As repeated endlessly again and again in the literature, you will need a complete approach to security testing, so considering using any of these tools is a step in the right direction. As we saw, there’re also opensource solutions available, so we do not really have any excuse to avoid putting this together.

 

 

 

SAST, DAST, RASP, IAST explained