Cross Site Scripting vulnerability in xdsoft.net Jodit Editor v.4.0.0-beta.86 allows a remote attacker to obtain sensitive information via the rich text editor component.

**Jodit Editor vulnerable to cross-site scripting**

High severity GitHub Reviewed Published Sep 19, 2023 to the GitHub Advisory Database • Updated Sep 21, 2023

GHSA-95xr-cq6h-vwr3: Jodit Editor vulnerable to cross-site scripting

Versions of the package blamer before 1.0.4 are vulnerable to Arbitrary Argument Injection via the blameByFile() API. The library does not sanitize for user input or validate the given file path conforms to a specific schema, nor does it properly pass command-line flags to the git binary using the double-dash POSIX characters (--) to communicate the end of options.

**Arbitrary Argument Injection Affecting blamer package, versions **<1.0.4****

**Threat Intelligence**

Exploit Maturity Proof of concept

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications

*   Snyk ID **SNYK-JS-BLAMER-5731318**
*   published **18 Sep 2023**
*   disclosed **22 Jun 2023**
*   credit **Liran Tal**

**How to fix?**

Upgrade blamer to version 1.0.4 or higher.

**Overview**

blamer is a tool for get information about author of code from version control system. Supports git and subversion.

Affected versions of this package are vulnerable to Arbitrary Argument Injection via the blameByFile() API. The library does not sanitize for user input or validate the given file path conforms to a specific schema, nor does it properly pass command-line flags to the git binary using the double-dash POSIX characters (--) to communicate the end of options.

**PoC**

    import Blamer from "blamer";
    const blamer = new Blamer.default("git");
    
    async function main() {
      const file = "--output=/tmp/r2d2";
      const result = await blamer.blameByFile(file);
      console.log("Blame json: %j", result);
    }
    
    main();

CVE-2023-26143: Snyk Vulnerability Database | Snyk

Microsoft on Monday said it took steps to correct a glaring security gaffe that led to the exposure of 38 terabytes of private data.
The leak was discovered on the company's AI GitHub repository and is said to have been inadvertently made public when publishing a bucket of open-source training data, Wiz said. It also included a disk backup of two former employees' workstations containing secrets

Data Safety / Cybersecurity

Microsoft on Monday said it took steps to correct a glaring security gaffe that led to the exposure of 38 terabytes of private data.

The leak was discovered on the company's AI GitHub repository and is said to have been inadvertently made public when publishing a bucket of open-source training data, Wiz said. It also included a disk backup of two former employees' workstations containing secrets, keys, passwords, and over 30,000 internal Teams messages.

The repository, named "robust-models-transfer," is no longer accessible. Prior to its takedown, it featured source code and machine learning models pertaining to a 2020 research paper titled "Do Adversarially Robust ImageNet Models Transfer Better?"

"The exposure came as the result of an overly permissive SAS token – an Azure feature that allows users to share data in a manner that is both hard to track and hard to revoke," Wiz said in a report. The issue was reported to Microsoft on June 22, 2023.

Specifically, the repository's README.md file instructed developers to download the models from an Azure Storage URL that accidentally also granted access to the entire storage account, thereby exposing additional private data.

"In addition to the overly permissive access scope, the token was also misconfigured to allow "full control" permissions instead of read-only," Wiz researchers Hillai Ben-Sasson and Ronny Greenberg said. "Meaning, not only could an attacker view all the files in the storage account, but they could delete and overwrite existing files as well."

In response to the findings, Microsoft said its investigation found no evidence of unauthorized exposure of customer data and that "no other internal services were put at risk because of this issue." It also emphasized that customers need not take any action on their part.

The Windows makers further noted that it revoked the SAS token and blocked all external access to the storage account. The problem was resolved two after responsible disclosure.

To mitigate such risks going forward, the company has expanded its secret scanning service to include any SAS token that may have overly permissive expirations or privileges. It said it also identified a bug in its scanning system that flagged the specific SAS URL in the repository as a false positive.

"Due to the lack of security and governance over Account SAS tokens, they should be considered as sensitive as the account key itself," the researchers said. "Therefore, it is highly recommended to avoid using Account SAS for external sharing. Token creation mistakes can easily go unnoticed and expose sensitive data."

UPCOMING WEBINAR

Identity is the New Endpoint: Mastering SaaS Security in the Modern Age

Dive deep into the future of SaaS security with Maor Bin, CEO of Adaptive Shield. Discover why identity is the new endpoint. Secure your spot now.

Supercharge Your Skills

This is not the first time misconfigured Azure storage accounts have come to light. In July 2022, JUMPSEC Labs highlighted a scenario in which a threat actor could take advantage of such accounts to gain access to an enterprise on-premise environment.

The development is the latest security blunder at Microsoft and comes nearly two weeks after the company revealed that hackers based in China were able to infiltrate the company's systems and steal a highly sensitive signing key by compromising an engineer's corporate account and likely accessing an crash dump of the consumer signing system.

"AI unlocks huge potential for tech companies. However, as data scientists and engineers race to bring new AI solutions to production, the massive amounts of data they handle require additional security checks and safeguards," Wiz CTO and co-founder Ami Luttwak said in a statement.

"This emerging technology requires large sets of data to train on. With many development teams needing to manipulate massive amounts of data, share it with their peers or collaborate on public open-source projects, cases like Microsoft's are increasingly hard to monitor and avoid."

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Microsoft AI Researchers Accidentally Expose 38 Terabytes of Confidential Data

Categories: Personal
Tags: metaverse

Tags:  meta

Tags:  Facebook

Tags:  VR

Tags:  AR

Tags:  XR

Tags:  reality

Tags:  virtual reality

Tags:  privacy

Tags:  safety

We take a look at the privacy implications of the Metaverse.



(Read more...)




The post The privacy perils of the Metaverse appeared first on Malwarebytes Labs.

A recently released report from New York University claims that the Metaverse, an all-in-one virtual online space, poses a potentially major risk to user privacy. This is because headsets and other similar devices can collect an incredible amount of personal, physical and biometric information. The user isn’t always aware of the collection, or how it could be used in ways they don’t expect.

It’s worth asking at this point: what is the Metaverse?

Most folks would think of Mark Zuckerberg and Meta, with a virtual reality headset thrown in for good measure. Others may associate it with “game hub” style online places to meet others taking place on their computer screens only. For some, mobile devices making use of augmented or mixed reality will be their first association.

The truth is that “Metaverse” can incorporate any or all of these different aspects. While some people hope for a world of entirely connected systems, the reality is that this is not going to happen for a very long time and may not happen at all. In fact, the Metaverse overall is not in the most robust of health, with proclamations of its demise across the web.

While it continues to struggle on, it’s still worth considering some of the potential privacy pitfalls waiting for any curious users. A good chunk of these come from the gaming space, and in particular advergaming (the art of displaying targeted adverts inside of virtual realms).

When playing a virtual reality game, the headset is an important part of gameplay. It typically contains several cameras (pointing both in and out), along with various sensors and microphones. These tools all help to track eye movements, interact with the digitally realised space around the user, and assist the game to keep track of what the player is doing.

While this is generally fine for an offline game with no data being sent elsewhere, once additional first or third-party systems are introduced this can become a risk. Is an ad network layered across the game? How does the network serve targeted ads? What is it tracking? Is player data sent to the advertisers, or does the game provider start building up a profile for non-gaming purposes? Is any of this disclosed?

This is just one basic example. Now consider that all of those eye movements, those motions, those biometrics are also up for grabs in terms of being able to build up pictures of users.

The research notes that Meta’s approach is more about harvesting user data (via profiles) for targeted ads. Apple, meanwhile, shifts its cost toward expensive high-end devices instead of purely advertising. Additionally, Apple does not collect eye-movement data whereas Meta “disclaims responsibility for the data practices of third-party developers with whom the company shares user data”.

Even so, Apple has not yet revealed what it intends to do with face-tracking and body-motion data. The researchers note that the specifics for the company's upcoming Vision Pro device does not yet have a detailed privacy policy.

This is just one small consideration of the upcoming data collection landscape where Metaverse is concerned. However, with the downsizing in expectation for these virtual worlds as a whole, these issues may not be as far reaching as they potentially could have been.

The report comes with numerous recommendations for safety features and privacy functionality, some of which have existed in video game/VR circles for some time now, though not always with success.

For example, Meta ran into several problems with regard to sexual harassment in virtual spaces. One of many issues was that a “bubble” around users in VR realms can prevent others from harassing or getting too close. Bafflingly, this wasn’t enabled in Meta as a default setting until the damage was already done.

Child safety is also another concern, given that headset use isolates the user and makes it harder for parents to see at a glance what their child may be doing.

Gaming platforms and consoles often come with a wide range of granular privacy and security controls. In VR, these controls aren’t always obvious and users may not know how to reach them. For example, hiding names, blurring faces, preventing the sending of data to unwanted third-parties and so on. These options should always be clear and evident to whoever happens to be using the device.

The full report is available to read here. Metaverse may not be the hot property it once was, but it's still worth learning about the possible dangers and privacy risks inherent in the headset.

**We don’t just report on threats—we remove them**

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

The privacy perils of the Metaverse

NATS nats-server 2.2.0 through 2.7.4 allows directory traversal because of an unintended path to a management action from a management account.

**NATS nats-server allows directory traversal via unintended path to a management action**

Critical severity GitHub Reviewed Published Sep 19, 2023 to the GitHub Advisory Database • Updated Sep 21, 2023

GHSA-vpjc-4jcv-jc29: NATS nats-server allows directory traversal via unintended path to a management action 

Cross-site Scripting (XSS) - DOM in GitHub repository librenms/librenms prior to 23.9.1.

**Cross site scripting in librenms**

High severity GitHub Reviewed Published Sep 19, 2023 to the GitHub Advisory Database • Updated Sep 21, 2023

GHSA-2q8c-gqf4-mg3v: Cross site scripting in librenms

CVE-2023-5060

An issue in the component /common/DownController.java of JFinalCMS v5.0.0 allows attackers to execute a directory traversal.

> source code: https://gitee.com/heyewei/JFinalcms
> 
> Official website : http://www.jrecms.com/product/201.html

**Analyze:**

The vulnerable file is in com/cms/controller/common/DownController.java

We can easily find that the file function concatenates the file name of the fileKey parameter as a string directly with the overall file path, without performing black and white list verification or security verification, which allows us to utilize/ Perform directory traversal

poc:

1  
2  
3  

    I set a test.txt in E:\test.txt.And this java sysytem is also set in E-disk.Windows: /../../../../../../../../../test.txtLinux:	/../../../../../../../../../etc/passwd

CVE-2023-41599: Directory traversal in JFinalCMS

**Release v2.9.22**

**Changelog****Go Version**

*   1.20.8 (updated out-of-cycle since Go 1.19 is now EOL)

**Dependencies**

*   github.com/nats-io/jwt/v2 v2.5.0
*   golang.org/x/crypto v0.12.0
*   golang.org/x/sys v0.11.0

**Improved**

Monitoring

*   CORS Allow-Origin passthrough for monitoring server (#4423) Thanks to @mdawar for the contribution!

JetStream

*   Improve consumer scaling reliability with filters and cluster restart (#4404)
*   Send event on lame duck mode (LDM) to avoid placing assets on shutting down nodes (#4405)
*   Skip filestore tombstones if downgrade from 2.10 occurs (#4452)
*   Adjust delivered and waiting count when consumer message delivery fails (#4472)

**Fixed**

Config

*   Allow empty configs and fix JSON compatibility (#4394, #4418)
*   Remove TLS OCSP debug log on reload (#4453)

Monitoring

*   Fix Content-Type header when /healthz is not 200 OK (#4437) Thanks to @mdawar for the contribution!
*   Fix server /connz idle time sorting (#4463) Thanks to @mdawar for the contribution!
*   Interface conversion bug which could cause a panic when calling /ipqueuesz endpoint (#4477)

Leafnode

*   Fix race condition which could affect propagating interest over leafnode connections (#4464)

JetStream

*   Fix possible deadlock in checking for drift in the usage reporting when storing a message (#4411)
*   Durable pull consumers could get cleaned up incorrectly on leader change (#4412)
*   Moving an R1 stream could sometimes lose all messages (#4413)
*   Prevent peer-remove of an R1 stream which could result in the stream becoming orphaned (#4420)
*   Ensure consumer ack pending is less than max ack pending on state restore (#4427)
*   Ensure to reset election timer when catching up (#4428) Thanks to @yuzhou-nj for the report!
*   Auto step-down Raft leader if an entry is missing on a catchup request (#4432)
*   Fix PurgeEx with keep having deletes in blocks (#4431)
*   Update global subject index when message blocks expire (#4439)
*   Ensure max messages per subject is respected after update (#4446) Thanks to @anthonyjacques20 for the report!
*   Ignore and remove empty message blocks on rebuild (#4447)
*   Fix possible accounting discrepancy on message write (#4455)
*   Fix potential message duplication from stream sources when downgrading from 2.10 (#4454)
*   Check for checksum violations for all records before sequence processing (#4465)
*   Fix message block accounting (#4473)

**Complete Changes**

v2.9.21...v2.9.22

**Release v2.9.21**

**Changelog****Go Version**

*   1.19.12

**Dependencies**

*   github.com/klauspost/compress v1.16.7
*   github.com/nats-io/nats.go v1.28.0
*   go.uber.org/automaxprocs v1.5.3
*   golang.org/x/crypto v0.11.0
*   golang.org/x/sys v0.10.0

**Added**

OCSP

*   Add fetch, cache, and verification of client CA's OCSP Response for NATS, WebSocket, and MQTT client mTLS connections (#4362, backported from 2.10)
*   Add bi-directional fetch, cache, and verification of CA OCSP Response for LEAF connections (#4362, backported from 2.10)

See ADR-38 OCSP Peer Verification

General

*   Add UTC log timestamp option (#4331, backported from 2.10)

**Improved**

JetStream

*   Don't error to server logs if message was deleted for consumer (#4328)
*   Improve publish performance for zero-interest subjects (#4359) Thanks to @antlad for reporting the issue!
*   Sync and reset message rejected count to ensure replicas don’t incorrectly discard messages (#4365, #4366)

**Fixed**

General

*   Leaking memory on usage of getHash() (#4329) Thanks to @VuongUranus for reporting the issue!
*   Server reload with highly active accounts and service imports could cause panic or dataloss (#4327)
*   Fix detection of an unusable configuration file (#4358)
    *   **NOTE: as a side effect of this fix, the server will no longer startup with an empty config file**
*   Fix a few system service imports going missing after configuration reload (#4360)

OCSP

*   Fix local-determination of issuer CA at startup (#4362)
*   Remove constraint that all (super)cluster node peers must be issued by the same CA (#4362)

Embedded

*   Don't require TLS for in-process client connection (#4323)

JetStream

*   Fix serializability guarantee for concurrent publish when using expected-last-subject-sequence (#4319)
*   Report correct consumer count in paged list response (#4339)
*   Fix not validating single token filtered consumer (#4338)
*   Fix stream recovery of message block with sequence gaps (#4344)
*   Fix panic when re-calculating first sequence of SimpleState info (#4346)
*   Fix stream store accounting drift (#4357)

**Complete Changes**

v2.9.20...v2.9.21

**Release v2.9.20**

**Changelog****Go Version**

*   1.19.11

**Added**

Windows

*   Backport 2.10 support for native Windows certificate store (#4268)

**Improved**

Accounts

*   Allow advisories to be exported/imported across accounts (#4302)

JetStream

*   Optimize consumer create time on streams with a large number of blocks (#4269)

**Fixed**

Gateways

*   Protect possible data race when reloading accounts (#4274)

Leafnodes

*   Prevent zombie subscriptions which could lead to silent data loss when using queue subscriptions (#4299)

WebSocket

*   Prevent reporting tls_required when tls_available is not set (#4264)

JetStream

*   Prevent corrupting streams actively being restored during health check (#4277) Thank you @vitush93 for the report!
*   Prevent encrypted data attempting to be decrypted with an empty key (#4301)

MQTT

*   Ensure republished messages from streams are received by MQTT subscriptions (#4303)

**Complete Changes**

v2.9.19...v2.9.20

**Release v2.9.19**

**Changelog****Go Version**

*   1.19.10

**Improved**

JetStream

*   Improve resource utilization when creating mirrors on very high-sequence streams (#4249)

**Fixed**

WebSocket

*   Ensure INFO properties are populated based on the WebSocket listener when enabled (#4255) Thanks to @Envek for reporting the issue!

**Complete Changes**

v2.9.18...v2.9.19

**Release v2.9.18**

**Changelog****Go Version**

*   1.19.10

**Dependency Updates**

*   golang.org/x/crypto v0.9.0 (#4236)
*   golang.org/x/sys v0.8.0 (#4236)
*   github.com/nats-io/nats.go v1.27.0 (#4239)

**Improved**

Monitoring

*   Optimize /statsz locking and sending in standalone mode (#4235)

JetStream

*   Apply ack floor check only for interest-based streams (#4206)
*   Improved efficiency and reduced CPU usage of the consumer ack floor check, particularly when the stream first sequence is a large number (#4226)
*   Improve clean-up phase of R1 consumers on server restart for name reuse (#4216)
*   Optimize “last message lookups” by subject (KV get operations) for small messages (#4232) Thanks to @jjthiessen for reporting the issue!
*   Only enable JetStream account updates in clustered mode (#4233) Thanks to @tpihl for reporting the issue!

**Fixed**

General

*   Fix a variety of potential panic scenarios (#4214) Thanks to @Zamony and @artemseleznev for the contribution!

Leadnode

*   Daisy chained leafnodes could have unreliable interest propagation (#4207)
*   Properly distribute requests to queue groups across leafnodes (#4231)

JetStream

*   Killed server on restart could render encrypted stream unrecoverable (#4210) Thanks to @BhatheyBalaji for the report!
*   Fix a few data races detected internal testing (#4211)
*   Process extended purge operations correctly when being replayed (#4212, #4213) Thanks to @MauriceVanVeen for the report and contribution!

**Complete Changes**

v2.9.17...v2.9.18

**Release v2.9.17**

**Changelog****Go Version**

*   1.19.9

**Dependency Updates**

*   github.com/klauspost/compress v1.16.5 (#4088)

**Improved**

Core

*   Additional optimizations to outbound queues, reducing memory footprint (#4084, #4093, #4139)
*   Use faster flate compression library for WebSocket transport compression (#4087)

Leafnodes

*   Optimize subscription interest propagation for large leafnode fleet (#4117, #4135)

Monitoring

*   Support sorting by RTT for /connz (#4157)

Resolver

*   Improve signaling for missing account lookups (#4151)

JetStream

*   Optimized determining if a stream snapshot is required (#4074)
*   Run periodic check for consumer “ack floor” drift on leader (#4086)
*   Optimize leadership transfer during a stream migration (#4104)
*   Improve how clustered consumer state is hydrated on startup (#4107)
*   Add operation type to panic messages for improved debugging (#4108)
*   Improve health check to repair stalled assets periodically (#4116, #4172)
*   Remove unnecessary filestore lock to improve I/O performance (#4123)
*   Various Raft leadership improvements (#4126, #4142, #4143, #4145)
*   Improve accuracy of account usage (#4131)
*   Clean up old Raft groups when streams are reset (#4177)

**Fixed**

General

*   Fix various names in comments (#4099) Thanks to @cuishuang for the contribution!
*   Fix various typos in comments (#4169) Thanks to @savion1024 for the contribution!
*   Update tests to reflect the server.Start() call no longer blocks (#4111) Thanks to @lheiskan for reporting the issue!
*   Fix race condition in config reload with gateway sublist check (#4127)
*   Track all remote servers in a NATS system with different domains (#4159)

Core

*   Fix premature closing in WebSocket transport due to outbound queue changes (#4084)
*   Fix subscription interest for config-based accounts during config reload (#4130)
*   Use monotonic time for measuring durations internally (#4132, #4154, #4163)

Monitoring

*   Service import reporting for /accountz when mapping to local subjects (#4158)

JetStream

*   Fix formatting of Raft debug log (#4090)
*   Prevent failure of /healthz in single server mode on failed snapshot restore (#4100)
*   Ensure a stream Raft node has fully stopped and resources freed (#4118)
*   Fix case where R1 streams are orphaned and can’t scale up (#4146)
*   Protect against out of bounds access on usage updates (#4164)
*   Fix state rebuild where the first block is truncated and missing index info (#4166)
*   Avoid stale KV reads on server restarted for replicated stores (#4171) Thanks to @yixinin for reporting the issue!
*   Prevent deadlock with usage report for accounts (#4176)

**Complete Changes**

v2.9.16...v2.9.17

**Release v2.9.16**

**Changelog****Go Version**

*   1.19.8

**Dependency Updates**

*   github.com/klauspost/compress v1.16.4
*   github.com/nats-io/jwt/v2 v2.4.1
*   github.com/nats-io/nkeys v0.4.4
*   golang.org/x/crypto v0.8.0
*   golang.org/x/sys v0.7.0

**Added**

Build

*   Nightly build of the “main” branch as a Docker image: synadia/nats-server:nightly-main (#3961, #3962, #3963, #3972, #4019, #4063)
*   Version control SHA in the Goreleaser build of the server (#3993). Thanks for the report @jzhoucliqr!  
    Monitoring
*   Add server name and route remote server name to /routez (#4054)

Resolver

*   Add “hard\_delete” option for stored JWTs (#3783). Thanks for the contribution @JulienVdG!

**Improved**

JetStream

*   Storage and Raft layer improvements to decrease p99 latency variance and memory pressure in high load environments (#3956, #3952, #3965, #3981, #3999, #4018, #4020, #4021, #4022, #4026, #4027, #4028, #4029, #4030, #4038, #4045, #4050, #4053)
*   Don’t show Raft warning for node that is closed (#3968)
*   Use pooled buffer for flushing encrypted message blocks (#3975)
*   Remove snapshotting of cores and maxprocs (#3979)
*   Improvements to interest-based streams to optimize when messages are deleted (#4006, #4007, #4012)
*   Better handling of concurrent stream and consumer creation of the same name (#4013)
*   Finer-grain locking during asset checking to reduce contention in the /healthz endpoint (#4031)
*   Encrypted file stores will now limit block sizes to improve performance (#4046)
*   Improve performance on storing messages with varying subjects and limits are imposed (#4048, #4057). Thanks for the report @kung-foo!

**Fixed**

Subjects

*   Ensure subjects containing percent (%) are escaped (#4040)

Accounts

*   Fix data race when setting up service import subscriptions (#4068)

Leaf

*   Fix leaf client connection failing on OCSP setups (#3964)
*   Fix case when allow/deny permissions on leaf connection could block legitimate interest (#4032)

Cluster

*   Route disconnect not detected by ping/pong (#4016). Thanks for the contribution @sandykellagher!

JetStream

*   Pull consumer not sending timeout error to clients for expired requests (#3942)
*   Prevent meta leader deadlock during deletion of orphaned streams during server startup (#3945)
*   Clear ack’ed messages when scaling workqueue or interest-based streams (#3960) Thanks for the report @Kaarel!
*   Remove messages from interest-based stream on consumer snapshot (#3970)
*   Fix potential panic in message block buffer pool (#3978)
*   Fixed an issue with consumer states growing and causing instability (#3980)
*   Improve handling of out-of-storage condition (#3985)
*   Address memory leak of unreachable Raft groups when JetStream becomes disabled (#3986)
*   Prevent Raft leader from being placed on server in lame-duck mode (#4002)
*   Remove potential race condition on sysRequest (#4017)
*   Fix FirstSeq not being updated with filestore when purging subject (#4041). Thanks for the contribution @MauriceVanVeen!
*   Fix Raft log debug reloading (#4047)
*   Ensure consumer recovers fully on restart before being eligible for leader (#4049)
*   Fix incorrect check between stream source/mirror with external streams (#4052)
*   Fix various conditions during Raft group recovery (#4056, #4058)

**Complete Changes**

v2.9.15...v2.9.16

**Release v2.9.15**

**Changelog****Go Version**

*   1.19.6: Both the release executables and Docker images are built with this Go release

**Added**

*   Monitoring
    *   Add raft query parameter to /jsz to include group info (#3915)
    *   Update /leafz to include leaf node remove server name and “spoke” flag (#3923, #3925)

**Changed**

*   Lower default value of jetstream.max_outstanding_catchup to prevent slow consumers between routes (#3922)
    *   **Note: The new value is now 64MB from 128MB. This is better optimized for 1 Gbit links, however if your links are 10 Gbit or higher, this value can be set back to 128MB if slow consumers were not previously observed.**

**Improved**

*   Refactor intra-process queue to reduce allocations (#3894)
*   JetStream
    *   Better system stability and recovery from corrupt metadata due to hard forced restarts (#3934)
    *   Optimize on-disk, per-subject info update (#3867)
    *   Limit concurrent blocking IO to improve stability under heavy IO loads (#3867)
    *   Improve message expiry calculation for large numbers of messages (#3867)
    *   Optimize when and how consumer num pending is calculated, significantly speeding up consumer info requests (#3877)
    *   Improve parallel consumer creation to prevent dropped messages (#3880)
    *   Properly warn on consumer state update state failures (#3892)
    *   Performance of consumer creation for certain configurations (#3901)
    *   Send current snapshot to followers when becoming meta-leader (#3904)
    *   Ensure preferred peer during stepdown is healthy (#3905)
    *   Optimized various store calls on stream state (#3910)
    *   Various performance and stability under heavy IO loads (#3922) (Thank you @matkam and @davidzhao for the report and the test harness!)

**Fixed**

*   Fix stack overflow panic in reverse entry check when inbox ends with wildcard (#3862)
*   Check if client connection name was already set when storing, preventing recursive memory growth (#3886)
*   Fix check for count of wildcard tokens in “partition” subject transform (#3887) (Thank you @MauriceVanVeen for the contribution!)
*   Fix panic if service export is nil (#3917) (Thank you @MauriceVanVeen for the report!)
*   JetStream
    *   Ensure per-subject info is updated when doing stream compact (#3860)
    *   Ensure account usage is updated in the filestore when extended version purge occurs (#3876)
    *   Prevent consumer deletes on restart, with non-fatal errors (#3881)
    *   Do not warn if consumer replicas is zero since it will be inherited from the stream (#3882)
    *   Named push consumers with inactive thresholds deleted when still active (#3884)
    *   Prevent spurious “Error storing entry to WAL” log messages (#3893, #3891)
    *   Clean up consumer redelivery state on stream purge (#3892)
    *   Clean up consumer ack pending if below stream ack floor (#3892)
    *   Update ack floors on messages being expired (#3892)
    *   Fix lost ack pending consumer state on partial stream purge (#3892)
    *   Snapshot and compact the consumer RAFT WAL, even when state changes do not occur, to prevent excessive disk usage (#3898)
    *   Fix KV accounting errors under heavy concurrent usage (#3900)
    *   Ensure new replicas respect MaxAge when a stream is scaled up (#3861)
    *   Snapshots would not compact after being applied (#3907)
    *   Fix filtered pending state calculation (#3910)
    *   Recover from a failed truncate on raft WAL (#3911)
    *   Fix JWT claims update if headers are passed (#3918)
*   MQTT
    *   Prevent use of wildcard characters with topics beginning with $, per the MQTT spec violation 4.7.2-1 (#3926) (Thank you @dominikh for the report!)

**Dependency Updates**

*   klauspost/compress - v1.16.0
*   nats-io/nats.go - v1.24.0
*   golang.org/x/crypto - v0.6.0
*   golang.org/x/sys - v0.5.0

**Complete Changes**

v2.9.14...v2.9.15

**Release v2.9.14**

**Changelog****Go Version**

*   1.19.5: Both the release executables and Docker images are built with this Go release

**Fixed**

*   JetStream
    *   Fix circumstance when an empty snapshot could be written (#3844)
    *   Fix possible panic and deadlock during a consumer filter subject update (#3845)
    *   Fix consumer snapshot logic (#3846)

**Complete Changes**

v2.9.12...v2.9.14

**Release v2.9.12**

**Changelog**

**NOTE: regressions were found in this release. Please skip this and go directly to the v2.9.14 release.**

**Go Version**

*   1.19.5: Both the release executables and Docker images are built with this Go release

**Added**

*   OS/Arch
    *   Add support for dragonfly BSD (#3804)

**Improved**

*   JetStream
    *   Use highwayhash to optimize difference tracking for stream, consumer, and cluster snapshots (#3780)
    *   Add small tolerance in lag for stream and consumer health checks (#3794)
    *   Various optimizations related to snapshots and memory usage (#3828, #3831, #3837) Thanks to @MauriceVanVeen for the collaboration on this issue.

**Fixed**

*   JetStream
    *   Update numCores and maxProcs if altered by container limits (#3796)
    *   Fix filtered state for all subjects when the first sequences are deleted (#3801)
    *   Updating a stream to direct gets would fail direct gets (#3806)
    *   Force consumer replicas to match for interest-based policy streams (#3817)
    *   Assign signal subscription to consumer when created (#3808)
    *   Properly process updates on a stream on restart (#3818)
    *   Select consumer peer(s) from active/online peers only on creation (#3821)
    *   Sourced streams that do not overlap subjects were incorrectly reported as a cycle (#3825)
    *   Fix for isGroupLeaderless when JS not available due to shutdown (#3830)
    *   Deadlock on data loss when holding mb lock (#3832)
    *   Fix consumer not getting messages after filter update (#3829)
    *   Fix current consumers not getting messages after purge (#3838) Thanks to @pcsegal for the report!

**Updated Dependencies**

*   github.com/klauspost/compress - v1.15.15
*   github.com/nats-io/nats.go - v1.23.0
*   golang.org/x/time - v0.3.0

**Complete Changes**

v2.9.11...v2.9.12

CVE-2022-28357: Releases · nats-io/nats-server

The victim shaming website operated by the cybercriminals behind 8Base -- currently one of the more active ransomware groups -- was until earlier today leaking quite a bit of information that the crime group probably did not intend to be made public. The leaked data suggests that at least some of website's code was written by a 36-year-old programmer residing in the capital city of Moldova.

The victim shaming website operated by the cybercriminals behind **8Base** — currently one of the more active ransomware groups — was until earlier today leaking quite a bit of information that the crime group probably did not intend to be made public. The leaked data suggests that at least some of website’s code was written by a 36-year-old programmer residing in the capital city of Moldova.

The 8Base ransomware group’s victim shaming website on the darknet.

8Base maintains a darknet website that is only reachable via Tor, a freely available global anonymity network. The site lists hundreds of victim organizations and companies — all allegedly hacking victims that refused to pay a ransom to keep their stolen data from being published.

The 8Base darknet site also has a built-in chat feature, presumably so that 8Base victims can communicate and negotiate with their extortionists. This chat feature, which runs on the Laravel web application framework, works fine as long as you are \*sending\* information to the site (i.e., by making a “POST” request).

However, if one were to try to fetch data from the same chat service (i.e., by making a “GET” request), the website until quite recently generated an extremely verbose error message:

The verbose error message when one tries to pull data from 8Base’s darknet site. Notice the link at the bottom of this image, which is generated when one hovers over the “View commit” message under the “Git” heading.

That error page revealed the true Internet address of the Tor hidden service that houses the 8Base website: 95.216.51\[.\]74, which according to DomainTools.com is a server in Finland that is tied to the Germany-based hosting giant Hetzner.

But that’s not the interesting part: Scrolling down the lengthy error message, we can see a link to a private Gitlab server called Jcube-group: **gitlab\[.\]com/jcube-group/clients/apex/8base-v2**. Digging further into this Gitlab account, we can find some curious data points available in the JCube Group’s public code repository.

For example, this “status.php” page, which was committed to JCube Group’s Gitlab repository roughly one month ago, includes code that makes several mentions of the term “KYC” (e.g. KYC\_UNVERIFIED, KYC\_VERIFIED, and KYC\_PENDING).

This is curious because a FAQ on the 8Base darknet site includes a section on “special offers for journalists and reporters,” which says the crime group is open to interviews but that journalists will need to prove their identity before any interview can take place. The 8base FAQ refers to this vetting process as “KYC,” which typically stands for “Know Your Customer.”

“We highly respect the work of journalists and consider information to be our priority,” the 8Base FAQ reads. “We have a special program for journalists which includes sharing information a few hours or even days before it is officially published on our news website and Telegram channel: you would need to go through a KYC procedure to apply. Journalists and reporters can contact us via our PR Telegram channel with any questions.”

The 8Base FAQ (left) and the KYC code in Kolev’s Gitlab account (right)

The 8Base darknet site also has a publicly accessible “admin” login page, which features an image of a commercial passenger plane parked at what appears to be an airport. Next to the airplane photo is a message that reads, “Welcome to 8Base. Admin Login to 8Base dashboard.”

The login page on the 8Base ransomware group’s darknet website.

Right-clicking on the 8Base admin page and selecting “View Source” produces the page’s HTML code. That code is virtually identical to a “login.blade.php” page that was authored and committed to JCube Group’s Gitlab repository roughly three weeks ago.

It appears the person responsible for the JCube Group’s code is a 36-year-old developer from Chisinau, Moldova named **Andrei Kolev**. Mr. Kolev’s LinkedIn page says he’s a full-stack developer at JCube Group, and that he’s currently looking for work. The homepage for Jcubegroup\[.\]com lists an address and phone number that Moldovan business records confirm is tied to Mr. Kolev.

The posts on the Twitter account for Mr. Kolev (@andrewkolev) are all written in Russian, and reference several now-defunct online businesses, including pluginspro\[.\]ru.

Reached for comment via LinkedIn, Mr. Kolev said he had no idea why the 8Base darknet site was pulling code from the “clients” directory of his private JCube Group Gitlab repository, or how the 8Base name was even included.

“I \[don’t have\] a clue, I don’t have that project in my repo,” Kolev explained. “They \[aren’t\] my clients. Actually we currently have just our own projects.”

Mr. Kolev shared a screenshot of his current projects, but very quickly after that deleted it. However, KrebsOnSecurity captured a copy of the image before it was removed:

A screenshot of Mr. Kolev’s current projects that he quickly deleted.

Within minutes of explaining why I was reaching out to Mr. Kolev and walking him through the process of finding this connection, the 8Base website was changed, and the error message that linked to the JCube Group private Gitlab repository no longer appeared. Instead, trying the same “GET” method described above caused the 8Base website to return a “405 Method Not Allowed” error page:

Mr. Kolev claimed he didn’t know anything about the now-removed error page on 8Base’s site that referenced his private Gitlab repo, and said he deleted the screenshot from our LinkedIn chat because it contained private information.

Ransomware groups are known to remotely hire developers for specific projects without disclosing exactly who they are or how the new hire’s code is intended to be used, and it is possible that one of Mr. Kolev’s clients is merely a front for 8Base. But despite 8Base’s statement that they are happy to correspond with journalists, KrebsOnSecurity is still waiting for a reply from the group via their Telegram channel.

The tip about the leaky 8Base website was provided by a reader who asked to remain anonymous. That reader, a legitimate security professional and researcher who goes by the handle @htmalgae on Twitter, said it is likely that whoever developed the 8Base website inadvertently left it in “development mode,” which is what caused the site to be so verbose with its error messages.

“If 8Base was running the app in production mode instead of development mode, this Tor de-anonymization would have never been possible,” @htmalgae said.

A recent blog post from **VMware/Carbon Black** called the 8Base ransomware group “a heavy hitter” that has remained relatively unknown despite the massive spike in activity in Summer of 2023.

“8Base is a Ransomware group that has been active since March 2022 with a significant spike in activity in June of 2023,” Carbon Black researchers wrote. “Describing themselves as ‘simple pen testers,’ their leak site provided victim details through Frequently Asked Questions and Rules sections as well as multiple ways to contact them. ”

According to VMware, what’s particularly interesting about 8Base’s communication style is the use of verbiage that is strikingly familiar to another known cybercriminal group: RansomHouse.

“The group utilizes encryption paired with ‘name-and-shame’ techniques to compel their victims to pay their ransoms,” VMware researchers wrote. “8Base has an opportunistic pattern of compromise with recent victims spanning across varied industries. Despite the high amount of compromises, the information regarding identities, methodology, and underlying motivation behind these incidents still remains a mystery.”

Tag

#git