Fingerprinting Acunetix

[wolkenfeld]

Dear PAN Developers,

Several times now a developer on our side has reported to us from monitoring tools he manages that people have scanned our critical applications with a freely available Web Application Vulnerability scanner from Acunetix.

Our CSO contacted the CTO of Acunetix asking how can we could fingerprint their scanner so as to protect our applications from it. Their CTO wrote this:

"About blocking the attack: I don't know exactly what edition was used to scan your website. Some of our editions send the following header with each request: Acunetix-Scanning-agreement:Third Party Scanning PROHIBITED Check if you can see this header and block based on that.However, if they are using a Consultant edition, this header is not sent.

All editions are making a request to the following URL before starting the scan: http://{website}/acunetix-wvs-test-for-some-inexistent-file. So, you can also look for that."

Please let me know if, based on this information, you can create for us a method by which to finger print and (dynamically) filter traffic from this scanner in the future. Our current countermeasure - waking up our network engineers and having them manually add the source IP of the scanner (which varies with each attack) - is time consuming...

Thank you so much

Dovid

[SRA]

You can build a custom vulnerability or app signature to identify this traffic. To match on patterns in http request headers, you can use the http-req-headers context, and for matching patterns in URL you can use http-req-uri-path context.

[wolkenfeld]

Thank you SRA, I have communicated your response to our firewall manager; we'll be in touch...

[wolkenfeld]

SRA, we tried your suggestion but met with only limited success.  Here's the experiment we did:

Our firewall guy created a custom application which identified the initial connection attempt by Acunetix based on the signatures that the Acunetix CTO gave us.

I then downloaded a free, community edition of Acunetix, version 8, and ran a scan against a URL which resides behind our firewall.

The result was this: Palo Alto firewall noticed the signature present in the first couple of packets and, so, blocked those packets. Subsequent packets (from the same source IP), which lacked these signatures, were not identified as part of the banned application and were allowed through.

Is there some we can create a DDoS trigger that can block the originating IP? Etc. What can we do about this? Please advise.

Thank you again,

Dovid

[SRA · Accepted solution]

The entire session should be blocked, not just a few packets; unless the remaining packets are part of a different session. Also, from your original post it seems like the patterns don't appear in the session in all the editions of their product. Can you confirm from a packet capture that the patterns (either a header or URI) are indeed present in the session.