In the wake of the massive Capital One data breach incited by a misconfigured web app firewall, we are throwing in a .NET open source library vulnerability that demonstrates the pervasiveness of privilege escalation attacks across web apps for good measure.
It is a perilous time for ServiceStack users, a widely-used .NET based library. The problem lies with the ServiceStack ecosystem, where a JavaScript-based Cross-Site Scripting (XSS) vulnerability could allow attackers to inject client-side code or scripts into web browsers viewed by other users. This means that said script is activated when it is read by an unsuspecting user’s web browser or web application. The web page or application then acts as an attack vector that delivers the malicious script to the user’s browser.
A web page or application is made vulnerable to XSS if it executes unsanitized user input for web servers to generate output – this user input must then be parsed by the victim’s browser to potentially compromise the system. We will note that though XSS attacks are possible across many languages (e.g. VBScript, ActiveX, Flash, CSS), they are, however, most common in JavaScript (as with this vulnerability) as this language is most commonly used as a client-side scripting language to support a bulk of web browsing experiences.
In the context of this vulnerability within ServiceStack Framework 4.5.14, the flawed component is the query code used to execute the GET request. And with the web browser’s lack of server-side validation serving as the attack vector, this means that browser encoding is bypassed which could then compromise unsuspecting users’ browsers upon opening a crafted URL. The resulting impact is that a potentially malicious JavaScript code (aka unsanitized user input) would be reflected in the server response during execution for web browser output generation.
Such cross-site scripting vulnerabilities are often used by attackers for privilege escalation issues, especially to bypass access controls when two web pages are of the same origin (i.e. two URLs sharing the same protocol, port (if specified), and host).
This unauthorised access could then lead to security breaches such as data theft and password dumping. It is thus imperative that affected frameworks immediately download the patched version in 5.2 or later to avoid sensitive data violations.
With JavaScript being a key programming language that supports web development, it is imperative that we keep our guard up against unwanted intrusions to ensure seamless and secure provision of web services. We certainly hope this detailed analysis of this .NET vulnerability has galvanized you into taking active measures to avoid systemic data breaches. Until next time!
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.
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 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 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.
