We are happy to report that now Meterian supports pnpm, a new fast and more efficient alternative to npm. It’s comparably faster, especially when installing packages, compared to npm and it also saves a lot of disk space as it used symlinks to represent modules. Pnpm also supports very well monorepos using workspaces, and it has built-in support for multiple packages in a repository.
Pnpm support is available out of the box now in GitHub Actions, Azure DevOps, Bitbucket Pipes and of course using either the thin CLI or the dockerized CLI, so that you can continue to be informed about any vulnerable, out of date, or non-business friendly node module in your dependencies.
We can all admit that as dreary as 2020 has been, it has at least been consistent in its dreariness. One organisation that can definitely vouch for this is music streaming giant Spotify. In true 2020 style, Spotify wrapped up the end of the year with a data breach on November 12th1 in which customers’ private account details were exposed.
Now, we may wonder why a hacker would be interested in Spotify accounts. Sadly, it’s not because they want to steal music inspiration from us. The details of targeted private accounts include customer display names, passwords, genders and D.O.B.’s which were leaked to various Spotify business partners. Speaking of business partners, we must also note that a Spotify breach does not solely expose Spotify users but may also put customers on connected devices or platforms at risk. The interconnectedness of our information sharing means that a problem for Spotify could be a problem for us all. This information is harvested by malicious actors to perform credential stuffing attacks, in which stolen passwords are used to uncover more stolen passwords for other sites and applications.
Moreover, this would not be the last experience Spotify had of data breaches in 2020. A week later, a cyber criminal under the guise ‘Daniel’ infiltrated celebrity Spotify accounts including Dua Lipa and Lana Del Rey2. Although in this case it was not customers PII that was exposed, it still casts a shadow on Spotify’s claim of prioritising “protecting privacy and maintaining user’s trust” as outlined in an official statement released on the 9th December 20203.
Enter now: Meterian web scanner, which we’ve used to perform a quick surface scan of http://www.spotify.com to identify what security, stability and licensing risks of open source components are within the website’s codebase. Here we can see that Spotify currently has a security score of 0 out of 100, with 1 known vulnerable component – jquery 2.1.3 which has at least one high and several medium threats as confirmed by NVD4. Although we do not know for sure what the unlocked route of entry was in Spotify’s case, this open source entry may well have been it. Subsequently, there is nothing stopping cyber criminals from using this chink in the armour to perpetrate similar breaches in the future.
Although the vulnerability was discovered on November 12th, Spotify disclosed that it was present within the system from as far back as April. This means that more than 320 million user’s personal data was at risk for at least 7 months prior. Having carried out our own analysis in a matter of minutes, we immediately notice that the vulnerable component in use is actually more than three years out of date! We hope their web and mobile apps get greater scrutiny with regards to the maintenance of their open source dependencies. At Meterian we have developed a security platform that automatically identifies known vulnerabilities in software applications’ open source supply chain. To give our customers the best chance of resolving such issues, the platform can be easily integrated in software development teams’ DevOps process. The continuous nature of DevSecOps empowers development teams to be the first line of defence as they code applications.
Open source components have become fundamental components of applications that are relied upon for basic functionality and security. Since over 90% of applications consist of open source components nowadays, securing this part of a business’ IT and software has become an area that requires greater scrutiny in quality and maintenance.
Meterian helps ensure software applications’ open source supply chain is free from any known vulnerabilities that could compromise the application’s security and stability. Is it worth risking to damage the firm’s reputation and competitive edge in the market?
Curious to see what we can automatically report on your software applications? Detect known vulnerabilities in your open source software supply chain before your own applications become an Achilles heel. Get in touch and see how Meterian can make your company’s application security defence more robust.
1 Whittaker, Zack. “Spotify resets passwords after a security bug exposed users’ private account information.” Tech Crunch, 10 Dec 2020, https:// techcrunch.com/2020/12/10/spotify-resets-user-passwords-after-a-bug-exposed-private-account-information/
2 “Dua Lipa and other Spotify artists’ pages hacked by Taylor Swift ‘fan’”. BBC News, 2 Dec 2020, https:// bbc.co.uk/news/technology-55158317.
4 U.S. Department of Commerce. “National Vulnerability Database.” https:// nvd.nist.gov/vuln/search/results?adv_search=true&cpe_version=cpe%3A%2Fa%3Ajquery%3Ajquery%3A2.1.3
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.
Here we are! Guess what’s vulnerable again? On April 10th 2020 it was made public that a vulnerability has been exploited in the most popular Javascript library ever implemented: jQuery 3.4.1.
Why is jQuery 3.4.1 vulnerable?
Vulnerability score: 5 Platform: Javascript Components: jQuery, all versions before 3.5.0
When jQuery is invoked, it reads the HTML document and returns requested fragments of it. Now, while reading the document it might find that the one or more requested fragments are not in the correct format, so it tries to translate them. Although most of the times the translation is correctly performed, it’s been demonstrated that in particular cases the conversion (or parsing) could lead to an XSS cross-site scripting vulnerability.
An XSS cross-site scripting is a type of code vulnerability that allows attackers to insert malicious code into the web pages viewed by other users. It might be exploited to steal information such as access tokens or other sensitive information. This is what a criminal or Black Hat hacker would do.
This is what a criminal or Black Hat hacker would do. White Hat hackers, on the other hand, would behave ethically and use their software White Hat hackers, on the other hand, would behave ethically. Using their software engineering knowledge, White Hat hackers would show how to exploit a vulnerability: publish useful information about it to make sure both users and owners of the vulnerable library could take actions to prevent attacks.
What actions are required to safely update?
The first thing to know is that all the old versions of jQuery have some sort of vulnerability. Up until April 10th, version 3.4.1 was the only safe version available. Fortunately, the new minor release 3.5.0 has been published to fix the XSS security vulnerability.
As suggested in the jQuery release note, updating to this latest version might break your code as, to prevent the abuse of this vulnerability, the HTML element phrase is no longer converted. Therefore, a code review might be in order.
There is a lot of time-consuming effort involved in staying on track with all the latest code vulnerabilities as they are discovered but, fortunately, Meterian can help you with that.
When added to the CI/CD pipeline of any application, Meterian will automatically detect such vulnerabilities, or even fix them for you, and it will help you avoid the risk of an attack before it becomes a problem.
Welcome back to Meterian’s next Vulnerability Focus report edition. This week we are talking about Javascript vulnerabilities which need to be addressed. Both have been published in recent months and have a medium severity threat. The first vulnerability could result in a cross-site scripting attack whilst the second is to do with a cryptographic issue. There are over 1.6 billion websites in the world, and JavaScript is used on 95% of them, be sure to check if you could be affected.
CVE-2019-12043: there is a vulnerability in remarkable 1.7.1 affecting the unknown processing in the library lib/parser_inline.js of the component URL Handler. Manipulation of this component can lead to cross-site-scripting.
CVE-2019-9155: OpenPGP.js has a cryptographic issue which could allow attackers to conduct an invalid curve attack and gain the victim’s ECDH private key
Read up Javascript users! This vulnerability was posted last year in 2019, yet because of the significant amount of people using Javascript for their web apps, we thought it would be useful to inform people who might not have had time to address the issue.
This vulnerability has been found in remarkable 1.7.1 and is considered problematic. The component mishandles URL filtering, which allows attackers to trigger an XSS attack via unprintable characters.
Cross site scripting is an injection of malicious code into a trusted web app. As described above, this happens when the user input is not sufficiently validated either on the client or server side. The scripts injected will have malware which then allows the hacker to do a series of exploits. What is more concerning is that the attack could then alter the appearance of the web app and also commence attacks on users visiting that site.
This Javascript vulnerability was published in September 2019 and has a medium severity score of 5.9.
The vulnerability is a cryptographic issue in OpenPGP.js up to and including 4.2.0. This is a library in Javascript and therefore can be used on nearly any device. Users do not have to install a gpg on their machines in order to use this library, and therefore it can be reused in other projects that have browser extensions or server apps. Its main function is to sign, encrypt, decrypt and verify any kind of text, specifically emails.
The problem allows hackers, who can provide forged messages and get feedback on whether decryption of these messages succeeded, to eventually figure out and extract the victim’s private key.
To avoid this type of attack in the future, developers should identify sensitive data and encrypt them, even if stored on a hard drive. There should also be an effort to ensure the data cannot be overwritten by overwriting sensitive memory locations straight after the data is no longer needed in memory.
In regards to this specific vulnerability, it is suggested to upgrade openpgp to version 4.3.0 or above.
That is it from us…for now! Make sure to spread the word on these Javascript vulnerabilities in order to help protect your apps or the apps you develop. Read also our post about javascript vulnerabilities and remote code execution.
As you all know, open-source vulnerabilities are discovered daily, so you can expect us to be back with new vulnerabilities very soon!
Knowing is half the battle. The other half is doing. Let Meterian help your dev team stay in the know and on top of the latest updates to secure your apps continuously. Sign up here to download the Meterian client today. You’ll get an instant analysis of your first project for free. See the risks immediately and know which components to remove or upgrade to secure your app.
It’s that time of the week again folks. Meterian has two new Node.Js vulnerabilities to inform you on. Both are ranked a severity score of 7.5 and therefore considered to be of urgent attention. The first vulnerability concerns the bson-objectid package and the second the csv-parse module. Act fast and don’t let these vulnerabilities sit within your software/networks, or you could be at serious risk of a cyber attack.
CVE-2019-19729: There is an issue discovered in the bson-objectid package version 1.3.0 for Node.js. Hackers could generate a malformed objectid, resulting in objects in arbitrary forms to bypass formatting if they have a valid bsontype.
CVE-2019-17592: The csv-parse module before version 4.4.6 for Node.js is vulnerable to Regular Expression Denial of Service. An attacker can cause a program to spend an unnecessary amount of time processing.
Read up Node.js users you’ll want to know about this vulnerability! This was discovered on the 12th December 2019 by user Xiaofen9 on Github who noticed that ObjectID() allows an attacker to generate a malformed objectid by inserting an additional property to his user-input.
What is bson-objectid? This component allows you to create and parse ObjectIDs without using bigger components, such as other fully-fledged bson libraries.
The problem is that in certain conditions the input object will not be checked and will be returned early. This means that objects in arbitrary (potentially malicious) forms can completely bypass formatting and validation.
But what does a privilege escalation vulnerability actually entail? It is when a malicious user gains access to the privileges of another user account in a target system. This allows hackers to use these privileges to steal confidential data, run administrative demands or deploy malware.
What can you do to fix this? Unfortunately, at this time of writing there is still no remedy to this vulnerability. However, we recommend to cease using this component or switch to a full bson library like bson.
Oh yes…we are not done yet. Here is another Node.js vulnerability for you all! This was discovered on the 14th of October and given a high score of 7.5 by NVD. The affected module is csv-parse which is a CSV module. This project is a parser which converts CSV text inputs into objects. It uses the Node.js stream.Transform API and provides a simple callback-based API. Released for the first time in 2010, it is very easy to use and helps the big community that uses it with large data sets.
Why is Regular Expression Denial Service a backdoor for hackers? The attacker will insert in the file a malicious string which they know would take a very long time to evaluate. This means the attacker can make the user spend an excessive amount of time processing, resulting in the user’s executed commands to slow down or become unresponsive. Thus, the availability of the system degrades. To make things worse, the exploit can be easily and remotely executed depicting clearly why this vulnerability is classified as problematic.
The best thing to do to avoid getting caught out by such exploit, is to upgrade to version 4.4.6 and above.
That is it from us…for now! Make sure to spread the word on these critically-rated Node.js vulnerabilities in order to help protect your apps/the apps you develop. But as you all know, open-source vulnerabilities are discovered daily, so you can expect us to be back with new vulnerabilities very soon!
Knowing is half the battle. The other half is doing. Let Meterian help your dev team stay in the know and on top of the latest updates to secure your apps continuously. Sign up here to download the Meterian client today. You’ll get an instant analysis of your first project for free. See the risks immediately and know which components to remove or upgrade to secure your app.
Attention to all Java users! Yes, we are back with a brand new set of Java vulnerabilities that I know you would like to get some juicy info on. During September 2019, two Java vulnerabilities have been discovered within the Apereo CAS versions before 6.1.0-RC5 and the Apache Tapestry versions between 5.4.0 to 5.4.3. The former open source vulnerability has been given a score of 8.1 whilst the later a higher score of 9.8 in regards to severity. So hurry, read up and don’t waste any time. You could be affected!
CVE-2019-10754 Apereo CAS (org.apereo.cas:*) components could allow a remote authenticated malicious user to obtain sensitive information, caused by the use of weak RandomStringUtils PRNG algorithm.
CVE-2019-0195 Manipulating classpath asset file URLs, an attacker could guess the path to a known file in the classpath and have it downloaded.
That’s right folks! Java has another vulnerability. Due to multiple classes using Apereo CAS (before the release of 6.1.0-RC5) and making use of apache commons-lang3 RandomStringUtils for token and ID generation, this has made them predictable and resulted in a cryptography weakness.
For example, org.apereo.cas:cas-server-support-simple-mfa is a package that allows Apereo CAS to act as a multifactor authentication provider by itself. This generates tokens and allows them to be sent to end-users via pre-defined communication channels such as email or text message. Please also note that this vulnerability affects multiple components of the Apereo CAS framework.
So what is the threat? Well, the affected versions of this package are vulnerable to Insecure Randomness, as it relies on apache commons-lang3 RandomStringUtil which can produce predictable results. So, this could allow an attacker to generate their own unique Ticket ID due to insufficient randomness. In other words, the attacker could guess the encryptionSecret used within GenerateJwtCommand and allow them to impersonate a user. This also means the attacker will have access to sensitive information caused by the use of the weak RandomStringUtils PRNG algorithm.
But don’t fret. There is a solution. It has been recommended to upgrade org.apereo.cas to version 6.1.0-RC5 or higher.
Java users, don’t give cyber criminals the chance to access your data. Act fast and upgrade org.apereo.cas!
We are not done yet folks! We have one more Java vulnerability to inform you guys on. Within the Apache Tapestry versions 5.4.0 to 5.4.3, the manipulating classpath asset file URLs allow an attacker to guess the path of a known file in the classpath and, as a result, download it. This was discovered on the 16/09/19 by Thiago H. de Paula Figueiredo.
The Apache Tapestry is an open-source framework for creating web applications in Java or other JVM languages. It also complements and builds upon standard Java Servlet API and works in any application server. Apache Tapestry has a long history. It has the oldest code, dating all the way back to 2000. This has resulted in many releases; developers now concentrate on Tapestry 5 as opposed to 3 and 4.
What is tapestry.hmac-passphrase you say? This symbol is used to configure hash-based message authentication of Tapestry data stored in forms, or in the URL. In other words, your application is less secure and therefore more vulnerable to denial-of-service attacks. Especially when this symbol is not configured.
With various techniques, an attacker could guess the path to a known file in the classpath and have it downloaded. If the attacker found the file with the value of the tapestry.hmac-passphrase configuration symbol, then they could use it to craft a Java deserialization attack, thus running a malicious injected Java code.
The recommended mitigation for this vulnerability has been suggested to upgrade to Tapestry 5.4.5, which is a drop-in replacement for any 5.4.x version.
That is it from us…for now! Make sure to spread the word on these critically-rated Java vulnerabilities in order to help the app sec community defend against unwanted exploits. But as you all know, open-source vulnerabilities are discovered daily, so we recommend you regularly scan your code repositories for new known vulnerabilities. Don’t get caught off guard!
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.
This week’s edition is all about remote code execution attacks. We have a cross-site scripting (XSS) vulnerability in the ever popular http-file-server which could lead to the execution of arbitrary JavaScript code in an unsuspecting victim’s browser. On the other hand, we have a RubyGem exposure whose sheer magnitude led to the discovery of a potential cryptocurrency mining scheme.
CVE-2019-15224 A code-execution backdoor in rest-client version 1.6.13 could lead to privilege escalation attacks
CVE-2019-5458 A cross-site scripting (XSS) vulnerability in all versions of http-file-server, a third-party Node.JS module
A malicious code-execution backdoor has just been located in version 1.6.13 of rest-client – a popular HTTP and REST (REpresentational State Transfer) client software package for Ruby. In essence, REST is an architectural style that standardizes modes of communication among different computer systems on the web. To delve a bit deeper, RESTful systems are stateless, and they separate concerns from client-side and server-side – the Ruby rest-client oversees requests sent to the server in order to retrieve or modify data stored on the server.
In this compromised version, the injected code within the gem would fetch malicious code from pastebin.com and send it to the attacker’s server to retrieve sensitive information from the client’s host machine. Kudos to Jussi Kuljonen for catching this vulnerability and promptly notifying the GitHub community on 19 August 2019. Aside from that, he also pointed out that rest-client version 1.6.10 leading up to version 1.6.13, which have since been yanked, were also compromised.
Remote Code Execution Exploit of Ruby Gem rest-client library
This is dangerous territory for users of said gem, as third-party attackers could exploit this vulnerability to perform remote code execution for personal gains. This could be in the form of privilege escalation attacks, whereby attackers could execute malicious code on the host’s server to access credentials of services used by a hosting site (i.e. database, payment service provider).
It should be noted this 1.6.13 version is considerably dated, as the latest rest-client version is 2.1.0.rc1. This raised suspicions among the DevOps community that this incident might have been a targeted attack.
This discovery then instigated a wider instigation which revealed that the same code was found in almost a dozen other gems: bitcoin_vanity, blockchain_wallet, omniauth_amazon, cron_parser, coin_base, lita_coin, awesome-bot, doge-coin, and capistrano-colors. It has been established that the attacker(s) wanted to exploit the infected hosts to covertly mine cryptocurrency.
In terms of scope of impact, the rest-client version 1.6.13, which sparked the uncovering of this malicious plot, has had 1061 downloads. On the other hand, the total download count for all the compromised gems is a little over 3500. Regardless, the chaos ceases here as all affected gems have been removed by the RubyGems team – the compromised accounts of developers have also been locked for good measure.
As for the availability of a fix, version 1.6.14 (identical to the unaffected v1.6.9) has been released to replace all compromised versions in the legacy 1.6.x series. To check your apps’ depencies, versions <= 1.6.9 or >= 1.6.14 are unaffected. If your version of the rest-client gems falls in between, you are advised to download the patch immediately. Don’t say you haven’t been warned!
Look alive, all you http-file-server and min-http-server users! A cross-site scripting (XSS) vulnerability has been found in these third-party Node.JS modules. The HTTP File Server (HFS) is a web server used for the publishing and sharing of files.
By definition, XSS is a type of cybersecurity vulnerability that enables attackers to inject client-side scripts into web pages viewed by unsuspecting users. Implications of XSS vary in range (i.e. petty nuisance to critical security risk), depending on the nature of the data stored on the vulnerable site’s server and the strength of the security mitigation measures adopted by the site’s network.
In this instance, this cross-site scripting (XSS) vulnerability is the attack vector – it enables hackers with access to the server-file system to inject malicious Javascript-based scripts in the file name, so that these scripts will be automatically executed on the victim’s browser when files are listed. In technical jargon, this is known as improper neutralization of input during web page generation. The occurrence of this XSS vulnerability is due to the unsanitized and invalid HTML input in the module filenames – it allows any injected and stored scripts within the server to be executed in the client’s browser.
The http-file-server has unfortunately been declared dead, and no known fixes have been made available to HFS users. The good news is that the project has been yanked to prevent further exploits such as hijacking of user sessions or phishing to steal user credentials. Credits to An Nguyen for disclosing these easily exploitable vulnerabilities to the DevSecOps community!
To end things, we will leave you with some helpful tips on cross-site scripting prevention methods. One should check that user input has been sanitized and that potentially executable characters have been properly encoded to avoid having them interpreted as executable code. It is also worth validating input as it stops users from adding special characters into webpage data entry fields by refusing the request – this mitigates the impact should an attacker discover such an XSS vulnerability. We suggest you bookmark this useful resource: Cross Site Scripting Prevention Cheat Sheet, too!
Found this useful? 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.
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.
Ship software without vulnerabilities. 