Fingerprinting Acunetix

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Fingerprinting Acunetix

Not applicable

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

1 accepted solution

Accepted Solutions

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.

View solution in original post

7 REPLIES 7

L4 Transporter

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.

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

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

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.

SRA, thank you for your speedy reply. As the Acunetix CTO stated "All editions are making a request to the following URL before starting the scan:http://{website}/acunetix-wvs-test-for-some-inexistent-file"


OK, I re-ran an experiment scan after our firewall guy hit "session" in the rule: same results.


What can we do from here - any ideas?


Thanks again,

Dovid

The session vs. transaction option only matters when you have multiple conditions in the signature, and you want all of those be within a single transaction, or they can occur across transactions in a session. Have you taken a packet capture of the session to check if the patterns are indeed exactly the same as you used in the signature.

Pardon me for the late reply, please; yes, we took a packet capture and have uploaded this capture to our ticket (ticket #: 00149001). Please let me know if this will suffice for now, or if there is anything else we can provide you with in helping us develop a filter to test against this scanner.

Thank you so much,

Dovid

  • 1 accepted solution
  • 5483 Views
  • 7 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!