![]() ![]()
We’ve encountered our first minor set-back. Unfortunately all we see is all fields filled in with the “” value. Ideally when we reload the FTP page we will see the result of the Linux “whoami” command in the username field. Setup_ftp -a ‘server_address’ -p ‘port’ -u ”`whoami`” -p ‘password’ So we are expecting the server to run something like this (note that those are not double quotes – they are two adjacent single quotes): The last single quote is included to match the existing closing single quote. That is why we include the single quote first. Normally quoting arguments with single quotes prevents that behavior and forces the backticks to be interpreted literally. The `whoami` attempts to run “whoami” and fill in the value. The shell evaluates anything inside of backticks (`) as a command and executes it and then places the resulting output text in place of the original backtick-quotes text. Therefore, by including the single quote we break out of that. Setup_ftp -a ‘server_address’ -p ‘port’ -u ‘username’ -p ‘password’ The idea behind this is that I imagine that behind the scenes the server is passing the arguments from the form to a command as such: Next I tried setting the Username field to have the value ‘`whoami`’. I imagine this is because the JavaScript that fills in the form values was broken by the inserted ‘ character. Interesting! All of the field values have been replaced with “”. Does this mean the server refused to accept our input? Let’s reload the FTP settings page to see if it stored the value we sent: Now lets try putting that special character in the URL and see if the server checks for it: #Set up a wansview w3 on ip cam pro update#Is it also performed server side? Using the Chrome developer panel, I was able to see that when you click “Save” the form is submitted using a GET request ( which is bad – GET shouldn’t be used to update parameters on the server…) to this URL: The check on characters in performed client-side using JavaScript. Probing for command injection vulnerabilitiesįirst, lets try setting the values of various parameters in the interface to characters that have special meanings in the shell: This was not fruitful as the device appears to only listen on port 80. It was also worth scanning to see what ports the device was listening on in case the device was running a known vulnerable service. Looking through the various configuration pages revealed several pages that may be worth probing for command injection vulnerabilities. #Set up a wansview w3 on ip cam pro android#Once the initial set up using an Android or iPhone is complete the camera presents a web interface on the local network that can be used to configure the device. I imagine the issue is present on other Wansview cameras in the same family as well as clones. #Set up a wansview w3 on ip cam pro password#The text on the product description page mentioned that the device wouldn’t work if your WiFi password contained the characters & or ‘ – this was a clear indication that the product may not be properly parameterizing values. In addition to adding another camera to my smart home setup (shout out to Home Assistant) I could have fun trying to hack the camera since cheap Internet of Things devices are notoriously insecure. The cost of IP cameras has come down significantly and when I noticed one for sale on Amazon for 30 dollars I decided it was worth a purchase. #Set up a wansview w3 on ip cam pro code#TLDR: Jump to the exploit code if you just want to get root on your camera. ![]() As long as you have a some amount of familiarity with Linux and common tools you should be able to follow along. There are much more advanced toolkits available but this post details a “starting-from-scratch” approach that I took in order to re-familiarize myself with penetration testing. This post is an introduction to penetration testing an IoT device. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |