Predictable session IDs enable session hijacking in ntop ntopng

An issue was discovered in ntopng 3.4 before 3.4.180617. The PRNG involved in the generation of session IDs is not seeded at program startup. This results in deterministic session IDs being allocated for active user sessions. An attacker with foreknowledge of the operating system and standard library in use by the host running the service and the username of the user whose session they're targeting can abuse the deterministic random number generation in order to hijack the user's session, thus escalating their access.

ntop ntopng:

• Branch 3.4 is affected from 3.4 through versions before 3.4.180617.
• 3.4.180617 is the confirmed fixed boundary used for this entry.
• One public exploit entry uses the build-suffixed notation < 3.4.180617-4560, while the CNA/NVD boundary identifies branch 3.4 before 3.4.180617. The status of parallel or later branches is not established and should not be inferred.

The flaw is in ntopng's session ID generation: the PRNG used to create session values is not seeded when the program starts, making IDs assigned to active user sessions deterministic. An attacker must know the operating system, standard library, and target username to model or predict the random sequence. Public exploit material shows the relevant web flow using user and session cookies with the /lua/network_load.lua endpoint; this supports detection and analysis but does not establish that every deployment has identical validation behavior. The reviewed patch adds startup randomization in HTTPserver.cpp using gettimeofday and srand to randomize values returned by rand(). Other implementation details of session validation beyond the public description remain unconfirmed.

The flaw is reachable over the network through the ntopng web interface; the supplied assessment indicates that no account and no user interaction are required. Exploitation depends on prior knowledge of the host operating system, standard library, and target username, together with the ability to predict the PRNG sequence, so it is not an arbitrary unauthenticated bypass. A public exploit and proof of concept are available and demonstrate modeling rand() output and testing the corresponding session value. The reviewed sources confirm remote, unauthenticated session hijacking and privilege escalation; they do not establish the status of exploitation in production environments.

Successful exploitation lets an attacker impersonate the target user and submit requests under that user's session. The direct result is loss of confidentiality and integrity for data or functions within the compromised account's permissions. If the account is privileged, the attacker may obtain substantially broader access than a normal user. Availability impact is possible if the account can perform disruptive actions, but the technical sources do not describe a specific denial-of-service path.

An attacker who hijacks a session can access ntopng as the target user without obtaining that user's password. Possible consequences include disclosure of network-monitoring data and unauthorized actions available to the compromised account. If the targeted session belongs to a privileged user, the exposure can extend beyond the capabilities of a normal account. The actual business effect depends on the user's permissions, deployment architecture, and interface exposure; the reviewed evidence does not identify a specific breach or outage.

1. Upgrade affected ntopng installations to exactly 3.4.180617, the fixed release identified by the public patch and exploit references.
2. After deployment, verify the version of the running process and reconcile it with the asset inventory to confirm that the patched service is actually in use.
3. Because the weakness affects active session generation, follow the organization's session-management procedure after the upgrade, such as requiring reauthentication if operational policy permits.
4. Until upgrading is possible, restrict the ntopng web interface to trusted networks and apply network-layer access controls as defense in depth. The reviewed disclosure specifies upgrading as the mitigation and does not document a separate temporary workaround.
5. Do not treat a fix in branch 3.4 as proof that every parallel or later branch is unaffected; verify each branch independently.

1. Inventory every ntopng deployment, record the exact running version, and identify installations in the affected branch.
2. Determine which ntopng web interfaces are reachable from untrusted networks, especially installations exposed directly to the Internet or other user-controlled segments.
3. Where access logs preserve URI and cookie fields, review requests to /lua/network_load.lua that include both user and session, especially repeated or unusual attempts. This is precautionary monitoring derived from the public proof of concept, not a confirmed IOC.
4. Correlate successful requests with normal account activity and investigate unexpected use of sessions associated with affected accounts. Absence of suspicious log entries does not prove that a deployment is safe.
5. After remediation, verify the version of the running process and repeat the inventory check rather than relying only on the downloaded package version.