0

Using ZAP OWASP 2.13.0 and found a so-called "Remote command injection". But either in report or in Alerts the URL + query the URL does not contain attack string. Open the query in Request editor, the query is still correct.

Did the scan twice so maybe it's not temporary traffic jam. But I cannot reproduce it with manual test.

enter image description here

In scan, the request returns 200. But in my manual test with attack string, if not encoded:

GET /path?subscriptionId=200853000105614&subscriptionIdType=MSISDN|timeout /T 15 HTTP/1.1

The response body is html, not JSON though:

<html><body><h1>400 Bad request</h1>
Your browser sent an invalid request.
</body></html>

If encoded:

GET /path?subscriptionIdType=MSISDN%7Ctimeout%20%2FT%2015

It returns proper JSON with correct error message.

But in either case it's 400, not 200.

So:

  • anyone knows how the real query should be? I only see the attack string, but putting it into the query(encoded or not) does not return 200; I see 400 error which is expected.
  • Anyway to associate the alert with the query in History tab or Active Scan tab so I see what happened indeed?

BTW the application is based on an distroless image so I think running timeout on it will lead to executable not found error. Verified already, as there's no shell.

And, timeout /T is for Windows right? But the image is Linux based.

WesternGun
  • 103
  • 5

1 Answers1

2

Some of the ZAP attacks which rely on time based attacks are prone to false positives. This is because ZAP makes lots of requests and can put the target under heavy load, enough load to cause the responses to be delayed enough to make it look like the attacks have worked. This is being worked on and we hope to have these rules fixed before too long.

Note that ZAP supports "technologies" - if you know the target system is Linux then you can configure ZAP to ignore attacks focused on the other OSs like Windows and MacOS. This will speed up the scan and reduce false positives.

v-g
  • 316
  • 1
  • 7
Simon Bennetts
  • 1,490
  • 8
  • 10
  • OK I will test again without Windows specific commands and comment here. You mean it's actually correct query without attack string? So why it is listed as alert if nothing was appended. – WesternGun Aug 15 '23 at 12:22
  • There are 2 questions: 1) how requests in Alerts associated with real requests in output/history? By some ID? 2) how responses are associated with the request? By some correlation id header or? That's the only way I can think of. 1) I cannot find, and by what you said, 2) is not in place...? – WesternGun Aug 15 '23 at 12:39
  • I removed Windows and MacOS from Technology and this alert disappears. So it's fine now. Seems an unnecessary attack from the beginning. Thanks for the answer. – WesternGun Aug 15 '23 at 13:05
  • When you select the alert the corresponding request and response are selected in the respective tabs. The active scan requests are not shown in the History - ZAP makes so many of them that any manual requests would get lost. It looks like the payload is partly in the URL, there might be a bug where its not getting encoded correctly so the rest might be getting lost? I'll have a look when I get a chance.. – Simon Bennetts Aug 15 '23 at 13:35
  • Strangely now when I switch Windows and MacOS back on, I cannot reproduce the original issue anymore. This alerts along with some others disappeared. – WesternGun Aug 16 '23 at 07:05