mrdeep1
commented
6 days ago The shell that you are using to run the coap-client is parsing the input parameters and updating them as is appropriate before passing to the program (coap-client) to act upon.
So
coap-client -m get coap://127.0.0.1/`id`becomes (which is what the coap-client executable sees)
coap-client -m get coap://127.0.0.1/uid=1000(grumpz)ant then sends uid=1000(grumpz) over the wire to the server as the Uri=Path.
No issues here with command line injection - it is the shell's interpretation of what you passed to it on the command line.
If you use the -v7 option for coap-client, you will actually see what the coap-client is sending over the wire
Environment]
Problem Description
I noticed that I able to achieve OS Command Injection by using
backticksand the associated shell command in the URI inside the coap:// scheme when issuing GET requests using the coap-client, where I am using the latest version of libCoap 4.3.5.Expected Behavior
I was expecting the client to return 4.04 which it did, but further confirmation shows that the shell commands are executing based on the coap server logs.
Actual Behavior
I am seeing the output of the shell command appended in the URI inside the coap:// scheme when issuing GET requests which is executing the command.
Steps to reproduce
For a proof of concept, I spun up a californium CoAP hello world server locally, and proceeded to use the coap-client to issue a request to the server:
coap-client -m get coap://127.0.0.1/
idAs expected, the coap-client returned a 4.04 response, but when we check the server logs of the CoAP server, which returned the logs:
We are able to confirm that we are successfully executing shell commands as a result. Further testing, we tried to execute another coap-client request using the command:
coap-client -m get coap://127.0.0.1/
cat /etc/passwdAs expected, the coap-client returned a 4.04 response, but when we check the server logs of the CoAP server, which returned the logs: