A security issue exists in D-Link D-View 8 v2.0.2.89 and prior that could allow an attacker to manipulate the probe inventory of the D-View service.
An unauthenticated remote attacker can register a host of his/her choice as a Probe server by sending a 'probe-online' task to the Core server.
The attacker can create many bogus, attacker-controlled Probe servers on the Core server, polluting the D-View 8 web UI and the underlying MongoDB collection DView8 Probe.
If an attacker-controlled Probe server is used by D-View 8 users, bogus device information can be sent to and stored on the Core server.
A 'probe-online' task is sent by a Probe server to the Core server periodically to indicate its online status.
The attacker can fetch tasks destinated to existing, legitimate Probe servers.
D-View 8 tasks are stored in the DView8 Task MongoDB collection.
A Probe server periodically fetches a task destinated to it with matching criteria like probeId, taskStatus and time.
If the attacker knows the probeId of a legitimate Probe server, s/he can fetch a task for the legitimate Probe before it does by fetching more frequently.
It does so by sending a 'request task' task to the Core server with the probeId of the legitimate Probe server in it.
The probeId used in D-View 8 is in the form of probe-
if the Probe server is on a different host than the Core server.
If the Probe server and the Core server are on the same host, the probeId is in the form of LocalProbe-.
An attacker on the same LAN as a legitimate Probe server can determine its probeId as the attacker can learn about the Probe server's MAC address via ARP. D-View 8 tasks can contain sensitive information such as login credentials.
This task is initiated when a user logged into the D-View 8 Web server performs a manual network discovery or when a schedule to perform network discovery is run.
The task is sent to a Probe server asking it to scan for network devices so that they can be managed by D-View 8.
This task is initiated when a user logged into the D-View 8 Web server tries to connect to a discovered device.
If the attacker fetches a task before the legitimate Probe server does, the task is not performed by the legitimate Probe server because the taskStatus has been updated after the fetch, resulting in a denial-of-service.
Fetch tasks for an existing, legitimate Probe server // // User may need to initiate the 'tool-cli' and/or 'add-discovery' // task multiple times for the PoC to see those tasks as it competes // with a legitimate Probe server.
The probeId should be probe- where is the // MAC address of the Probe server set up above.
i.e., probe-11-22-33-44-55-66 python3 dview8 probe server.
This Cyber News was published on www.tenable.com. Publication date: Thu, 28 Dec 2023 15:40:06 +0000