1

I want to test a specific device connected to different networks using fuzzing. For each network interface, there are different services listening using different protocols, with open specification.

As i can not fuzz every network interface using every protocol, i want to find criteria to choose the protocol that either

  1. has the highest probability of finding vulnerabilities or
  2. will be the easiest to reach a high code coverage

For 2. i thought about e.g. message size, as the shorter the message, the more messages i can test in a reasonable time, but do you know other criteria or scientific research on this topic?

Thank you for helping.

lalu
  • 145
  • 8

1 Answers1

1

I think you're going to often find that your criteria is constrained by several factors, which actually limit what you can test.

The tools you have access to, and the licences you're operating under (terms of service, DMCA, etc.) can limit the scope in some cases. Any fuzzing that requires destructive interfere with another user is probably out, as well as any which could be seen as an attack on a service provider. So fuzzing a connection with a cloud service is somewhat risky.

Then you have local protocols like SSH, a web server, SMTP, etc. on a router/IoT device. Those services can be fuzzed with relatively low risk. There are many tools focused on web protocols so if your device has a web interface focusing on the OWASP top 10 may be a good starting point.

For more physical connections such as a JTAG or other hardware debug port, you may find some interesting unpublished functionality. If you have the adapters and the tools to debug JTAG that may be a good use of time.

Overall fuzzing is highly dependent on the target, the scope of the engagement, and the experience of the investigator.

Daisetsu
  • 5,110
  • 1
  • 14
  • 24
  • Thank you, this is already helping me in terms of which popular protocols i should prefer. However i am looking for a more general approach (if there is one) for example comparing one protocol, which has shorter message fields but does not give many replies vs. a protocol that is e.g. using JSON with many different fields as file format but does have lots of replies where it is easier to determine wether something broke. I am looking for these general criteria, however as you suggest there might not be (m)any. Is this what you were saying with your last sentence? – lalu Feb 08 '19 at 17:06
  • 1
    Yes. It's hard to reduce a protocols potential for vulnerability down to just a few parameters. If you find any research on that though, I would be very interested. – Daisetsu Feb 08 '19 at 17:08