GitLab Community and Enterprise Edition Vulnerability

/in /by

Overview:

  GitLab is web-based Git repository manager that includes additional features to handle all stages of the DevOps lifecycle including continuous integration and delivery, issue tracking, monitoring, and integration with many other applications. GitLab is built on several technologies including Ruby, Rails, Go, and Redis and is available as a free Community Edition or a paid Enterprise Edition.

  A stored cross-site scripting vulnerability has been reported in the Community edition and Enterprise edition of GitLab. The vulnerability is due to insufficient input sanitization of ipynb files.

  A remote, authenticated attacker can exploit these vulnerabilities with crafted requests to the target server. Successful exploitation could result in arbitrary script execution in the target user’s browser.

  Vendor Homepage

CVE Reference:

  This vulnerability has been assigned the Common Vulnerabilities and Exposures (CVE) identifier CVE-2021-39906.

  CVE Listing

Common Vulnerability Scoring System (CVSS):

  The overall CVSS score is 6.7 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L/E:P/RL:O/RC:C).

  Base score is 7.4 (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L), based on the following metrics:
    • Attack vector is network.
    • Attack complexity is low.
    • Privileges required is low.
    • User interaction is none.
    • Scope is changed.
    • Impact of this vulnerability on data confidentiality is low.
    • Impact of this vulnerability on data integrity is low.
    • Impact of this vulnerability on data availability is low.
  Temporal score is 6.7 (E:P/RL:O/RC:C), based on the following metrics:
    • The exploit code maturity level of this vulnerability is proof of concept.
    • The remediation level of this vulnerability is official fix.
    • The report confidence level of this vulnerability is confirmed.

  CVSS Calculator Metrics

Technical Overview:

  A stored cross-site scripting vulnerability exists in GitLab. The vulnerability is due to insufficient Jupyter notebook rendering sanitization. The HTML output of a command can contain SVG data with a use element referencing a GitLab icons SVG file on the GitLab server. The attribute sanitization does not normalize the path. The path to a valid SVG file can be used with a relative path to a crafted SVG appended that passes the sanitization check in isUrlAllowed(). The crafted SVG must be hosted in a repository on the same GitLab host.

  In the crafted SVG file, a foreignObject element can be used to inject arbitrary HTML after GitLab sanitization is performed. The SVG specification mentions that a referenced SVG XML should be cloned for use element processing, without an exclusion for foreignObject elements. However, the only browser engine that honours the cloning of foreignObject elements is Gecko. As a result, this XSS can only be triggered on Firefox browsers. The SVG Working Group has discussed removing foreignObject from the elements to clone from use referenced SVG files, but this is not yet written into the specification.

  A remote, authenticated attacker can exploit this vulnerability by creating crafted SVG and IPYNB files on the target server. Successful exploitation results in arbitrary script execution in the target user’s browser.

  Scalable Vector Graphics (SVG) 2, 5.6.1. The use-element shadow tree
  SVG Working Group GitHub repository, and Issue

Triggering the Problem:

  • The target system must have the vulnerable product installed and running.
  • The attacker must have network connectivity to the affected ports.
  • The attacker must have authorized access to a user with permissions to create files in a project.

Triggering Conditions:

  The attacker will authenticate to the target system. Once authenticated, the attacker will create a malicious SVG and IPYNB file.

Attack Delivery:

  The following application protocols can be used to deliver an attack that exploits this vulnerability:
    • HTTP
    • HTTPS

SonicWall’s, (IPS) Intrusion Prevention System, provides protection against this threat:

  • IPS: 705 GitLab ipynb Stored XSS 1

  • IPS: 18693 GitLab ipynb Stored XSS 2

  Please note that if your web service/server is accessible over HTTPS, then enabling of Server DPI-SSL is necessary for the above signature to detect exploits targeting this vulnerability.

Remediation Details:

  The risks posed by this vulnerability can be mitigated or eliminated by:
    • Updating the product by obtaining a new revision or applying the vendor supplied patch.
    • Filtering attack traffic using the signatures above.
  The vendor has released the following advisory regarding this vulnerability:
  Vendor Advisory

Open source stealer malware, Mercurial, for "educational purposes" spotted in the wild

/in /by

The SonicWall Capture Labs threat research team has come across data theft malware derived from the Mercurial password stealer family.  This malware is open source and readily available on github for “educational purposes only”.  Because it is open source, it can be easily customized and deployed with little programming expertise necessary.  The malware is written in C# and is trivial to decompile.

 

Infection Cycle:

 

Upon infection, the malware copies itself to %APPDATA\Local\Temp\.  It also adds itself to the registry so that it is started after each reboot:

 

It scans the system for browser profile information:

 

In addition to searching for browser data, it also searches for Minecraft launch profile files and Discord Level DB files:

 

It contains a very basic level of antidebugging:

 

Any information that is gathered from the system is sent via an HTTP POST request to the operator:

 

SonicWall Capture Labs provides protection against this threat via the following signature:

  • GAV: Blitzed.N (Trojan)

This threat is also detected by SonicWall Capture ATP w/RTDMI and the Capture Client endpoint solutions.

Everything Old Is New Again: Remote Access Comes Full Circle

/0 Comments/in /by

The shift to Zero-Trust Network Architecture is recent — but not the ideas behind it.

As an old timer who’s been in the Remote Access (RA) space since the mid-’90s, I see the current wave of evolution in SASE/SDP/ZTA more of a devolution. It takes us back to providing RA as a service (RaaS), replacing dedicated i386 appliances with virtual images akin to the early days of micro services on Unix. For example, this is how Aventail, a pioneer in RaaS, launched — as a service; the appliance came some years later.

When the RaaS (again, service is right there in the name) revolution first hit — way before the SSL VPN reboot — I was building huge NT 3.51 clusters with a spaghetti of US Robotics Courier modems hanging out the back. This service was offered to customers as the Common Office environment bundle and built on the premise that we could not trust incoming user traffic.

Over the proceeding 25+ years, much has changed. But the core principle of distrust remains. One of my favorite vintage marketing tag lines simplifies this message of zero trust to “Detect – Protect – Connect.”

With the 2000s came the SSL VPN revolution, which at its heart messaged “VPN is dead” and “clientless remote access rules.” We’re seeing this again today with SASE/SDP messaging, but what does it really mean?

It comes down to crypto, packet encapsulation and routing — aka “when do I route direct,” “when do I proxy” and “when do I backhaul tunnel.” These are all questions of trust. There is no one-size-fits-all answer to this; thus, to build a highly resilient and scalable service, you must do all three and often together within a single session using JIT logic.

Injecting a bit of humor, let’s look at this piece of Aventail marketing I pulled from the web. (The internet forgets nothing!)

Image Describing A new Reference Architecture – The Inverted Network

FYI: Aventail lives on today — it is the SSL VPN startup company SonicWall purchased in 2007, which has evolved into today’s SonicWall SMA 1000 series.

With no change to the core of the slide, just updating the terminology buzzwords to current standard, we can see ZTA ideals have been around for a lot longer than you may think.

So why, then, if solution architects like me have been singing the praises of a Zero Trust Architecture (ZTA) approach for 20 years, has there been such a slow adoption? Well, unpicking a flat network is hard work, and often in a large enterprise, you just don’t know who needs access to exactly which apps and data. However, you have to start somewhere — and with many years of experience, we’ve learned a thing or two about the best way to peel that particular onion.

COVID has changed this landscape, and today I see what was considered a “good enough” remote access implementation no longer cutting it. RA overhaul projects are again in the CIO’s Top 3, the common driver being ZTA to support the home worker revolution. So the chickens have finally come home to roost, and my years of banging the drum of inverted networks and shrunken perimeters becoming the mainstay have paid off.

Image Describing Access Control Engine

A final thought: A modern RAS needs more than just a complex ACL table to be a robust, reliable ZTA service. The ACE (Access Control Engine) at the core of the SonicWall SMA 1000 may be what your security team is pushing for, but as a CIO, that alone will not help you appease the business or provide a highly reliable, most critical service.

Business continuity thinking has replaced disaster recovery thinking to achieve service uptimes of nearly 100%. This needs consideration for parallel live infra demarcations with a roll forward N+1 strategy, SPOG central configuration change scheduling, mix-mode physical and virtual termination nodes salt-and-peppered between private and public datacenters, redundant app-data paths … which all come from experience.