fix(CVE-2023-5652): reduce false positives with differential timing detection#15954
Open
Eren-Akdag wants to merge 2 commits intoprojectdiscovery:mainfrom
Open
fix(CVE-2023-5652): reduce false positives with differential timing detection#15954Eren-Akdag wants to merge 2 commits intoprojectdiscovery:mainfrom
Eren-Akdag wants to merge 2 commits intoprojectdiscovery:mainfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Information
Problem
The original template uses a single
SLEEP(8)request and checksduration >= 8as the primary detection condition. On targets wherewp-admin/admin-ajax.phphas a naturally high baseline response time, occasional server-side latency spikes can push the response above 8 seconds withoutSLEEP(8)ever executing — producing a false positive.This endpoint always returns
HTTP 400, body0,Content-Type: text/htmlregardless of whether SQL injection occurs. This means the non-timing conditions (status_code,body,content_type) provide no exploitation signal on their own. The detection relies entirely onduration >= 8, making it vulnerable to server latency noise.Root Cause — Empirical Evidence
To confirm, identical requests were sent varying only the
SLEEPvalue, measuring response time for each:SLEEP(0)SLEEP(3)SLEEP(8)SLEEP(15)Timing does not scale with the
SLEEPvalue.SLEEP(15)andSLEEP(0)return in virtually identical time —SLEEPis not executing. Theduration >= 8condition was satisfied purely by server latency.Despite this, the original template fired a finding when the server spiked to ~13s:
Re-running the same scan seconds later with no change to the target:
Classic false positive — the finding does not reproduce reliably.
Fix — Differential Timing Detection
Instead of measuring absolute response time, this fix sends a
SLEEP(0)request first to establish a per-target baseline, then compares theSLEEP(8)response against it. The key matcher is:This requires the
SLEEP(8)request to take at least 6 seconds more than theSLEEP(0)baseline on the same endpoint. No amount of server latency can satisfy this condition unlessSLEEPactually executes, because both requests are subject to the same server conditions.duration_1duration_2d2 >= d1 + 64 >= 10→ ✗12 >= 10→ ✓8.5 >= 6.5→ ✓9 >= 15→ ✗The
duration_2 >= 8absolute check is retained as a secondary safety net for fast servers.Diff summary:
Template validation
Additional Details
False positive confirmed (original template, non-vulnerable host):
Fixed template — no finding on same host:
Differential check correctly blocked:
duration_2 (4.8s) >= duration_1 (4.3s) + 6→4.8 >= 10.3→ ✗Additional References