CVE-2023-36648: CVCN

Missing authentication in the internal data streaming system in ProLion CryptoSpike 3.0.15P2 allows remote unauthenticated users to read potentially sensitive information and deny service to users by directly reading and writing data in Apache Kafka (as consumer and producer).

Introduction

CryptoSpike leverages the Kafka system in order to communicate the events regarding file access on the NAS storage to the CryptoSpike sub-components involved in the elaboration. By using a Kafka client, it is possible to authenticate on Kafka without authentication from an attacker server and act in consumer or producer mode. In consumer mode it is possible to read from processed events all metadata of operations and files (filename and complete path on the network share, user identifier, date/time, etc.). In producer mode it is even possible to insert forged events that could lead to network shares’ users interdiction.

Steps to reproduce

The CryptoSpike system is deployed in Active monitoring mode with a configuration consisting of one Leader node and two Agents.

By using the tool “kcat” (also known as Kafka Cat) as client of Kafka service, connect to any one of the Kafka on the CryptoSpike servers in order to find the list of the Kafka "topics":

By connecting through kcat client as consumer without authentication to the Kafka topic local.cs.fct.file-events.0 on any one of the Kafka services (Leader or Agent), it is possible to capture information about files and storage users. Instead, by connecting as producer it is possible to insert multiple forged events that simulate the file writing of a file with an extension (.YOLO in the example) forbidden by one of the rules. In the next picture, on the left the connection as producer, on the right the connection as consumer:

The fake event written as producer is the following one:

{"eventType":"CREATE","filePath":"/test_FAKE2.YOLO","fileName":"test_FAKE2.YOLO","extension":"YOLO","displayFilePath":"\\[REDACTED IP].127\testshare\test_FAKE2.YOLO","filePathAfterRename":null,"userId":"S-1-5-21-3279977989-1286463912-761590908-500","userIdType":"WINDOWS","userIp":"[REDACTED IP].127","fileSystemObjectType":"FILE","fileProtocol":"SMB","fileProtocolVersion":"3.1","timestamp":1675681906.343000216,"timestampNano":343000216,"storagePlatform":"ONTAP","clusterId":402,"clusterName":"hq-stor","serverId":502,"serverName":"svm0_cifs","shareId":602,"shareName":"testshare","volumeId":552,"volumeName":"svm0_cifs_root","localAddress":"172.18.0.14","remoteAddress":"[REDACTED IP].55","policyName":"Prolion_CS_POLICY_ACTIVE_cifs","synchronous":true,"accessControlResult":"{"additionalInformation":{"configurationItemId":"1552","blockListItem":"yolo"},"blocked":true,"reason":"Extension matched.","accessControlType":"BLOCK_LIST","userIgnored":false,"audited":true}","accessControlType":"BLOCK_LIST","blocked":true,"userIgnored":false}

All the forged events written from the rogue producer are captured from the system and showed on the management interface of CryptoSpike:

After around one minute of time, the network share user indicated in the forged message is automatically blocked from CryptoSpike, despite this user never executed an operation on the NAS storage:

Note: to reproduce the test it is necessary:

• In case of CIFS shares, the Active Directory instance must be active, and the victim user ID must be known.
• More than 5 fake messages regarding the fake anomaly must be published to cause the blocking of the user.
• Each of these 5 messages must have a minimal variation from each one (all the timestamp fields can be set in a way that they are close together and to the current time)

Finally, by inserting as producer inside the Kafka topic a message that is not conforming to expected by CryptoSpike format, it is possible to block the entire system. For example, by sending a JSON with unexpected format ({ "TEST": “TEST” }) or a free text, the storage monitoring function of CryptoSpike is made unavailable. Being the Kafka instances running on the Leader and Agent nodes all synchronized, the unavailability of the service propagates to all the CryptoSpike Event Analyzer containers of the architecture.

cryptoleader:~$ check-services === UNDERREPLICATED SERVICES: 1 === REPLICAS MODE NAME 0/1 replicated application_services_event_analyzer

cryptoagent1:/prolion/scripts$ check-services === UNDERREPLICATED SERVICES: 1 === REPLICAS MODE NAME 0/1 replicated application_services_event_analyzer

cryptoagent2:/prolion/scripts$ check-services === UNDERREPLICATED SERVICES: 1 === REPLICAS MODE NAME 0/1 replicated application_services_event_analyzer