mqtt_fuzz
mqtt_fuzz copied to clipboard
F-Secure
Add support for MQTT auth mechanisms
Add support for MQTT over SSL auth mechanisms (usr/pwd, certfiles). Currently, there isn't any way to specify any username/password combination nor any certfile/keyfile.
Hi @poxyran , I'm currently using wireshark to capture packets, and using an MQTT client to connect using username and password, e.g. using hbmqtt:
hbmqtt_sub --url mqtt://username:[email protected]:1883 -t info/#
Then I put the captured MQTT connect packet into a new binary file in validcases/connect
Not sure how to do the certfile/keyfile based way though.
The current design of the fuzzer just sends packets without regard to any state machine. Authentication mechanisms that require state at the fuzz tool end, or that require cryptographic algorithms to be run in the authentication phase, would require major new development compared to the current system or (like above) to use a different tool for performing authentication.
OK, I guess that there isn't any possible workaround for this than modifying the fuzzer in the right way to make auth possible.
And in addition to the extra work related to the state machine, generally speaking, fuzzing objects that are authenticated or integrity protected requires a flow where the signing/integrity protection is applied to a fuzzed object. If you take a signed/integrity protected object and fuzz that, it will be rejected before the fuzzed data has any opportunity to exercise the actual protocol parser. To some extent, this also applies to compressed objects - apply compression after fuzzing, not before.
For non-TLS username/password authentication, I've created this patch https://github.com/akorevaar/mqtt_fuzz/commit/22b65c5f7fb66a0413770dc5f50a8c613889aa64
If the auth is done first, and the subsequent packets aren't encrypted, then this could be extended to cover any auth packets. But if there is encryption of packets then I agree with @anttivs .