The DG834 series are vulnerable to password bypass and several shell command injection exploits. (I did report this to Netgear at least 10 years ago).
If vulnerable, the following url should display the router's nvram settings without asking for a password (if you've logged in recently and not logged out, you won't be asked for a password anyway):-
(Sky supplied DG834GT routers with the most recent sky firmware on them aren't vulnerable to the password bypass as they removed the ca directory when they redesigned their UI.)
It seems some people still use these old routers, and router exploit malware is apparently on the rise, so here is a temporary patch to at least address the password bypass vulnerability (tested on a DG834N using the Vivaldi and Internet Explorer browsers, but may work on other models in the range).
If it causes any issues, rebooting the router will get rid of it completely.
http://routerlogin.net/ca/setup.cgi?PATH=/bin:/sbin:/usr/bin:/usr/sbin;mkdir\x20/tmp/w2;cd\x20/tmp/w2;ln\x20-s\x20/www/??????*\x20.;ln\x20-s\x20/www/.*\x20.;killall\x20mini_httpd;mini_httpd\x20-d\x20/tmp/w2\x20-r\x20\x22MEL\x22\x20-c\x20\x27**.cgi\x27\x20-f\x20indexca.htm\x20-t\x20300\x26rm\x20$0&todo=ping_test&next_file=diagping.htm&c4_IPAddr=1%26(/bin/echo%3E/tmp/mel+${QUERY_STRING%25%25%26to*}%26%26/bin/sh+/tmp/mel)+%3E/dev/null+2%3E/dev/null
The router won't send any response, so wait a few seconds for the http server to restart, then log in to the router to make sure the UI is working, click on the logout link in the router's ui, then try the link at the top of the page to test if it is still vulnerable, it should respond with the pink 404 not found page.
There are still a number of shell exploit vulnerabilities in setup.cgi, so always logout after you use the router's web interface. Also if you are using the default password, change it.
The password issue exists because there is no .htpasswd file in the /www/ca directory, it should be a link to /etc/htpasswd. I think the ca directory is used by the easy setup software supplied with the router.
Building new firmware with .httpasswd in /www.eng/ca/, /www.fre/ca/ etc should at least fix the password vulnerability.
The URL above works by injecting and running the script I've embedded in the query string onto the router, which makes a copy of the current www directory (using links) in the router's /tmp directory, omitting all sub directories including "ca" and restarts its http server using the replacement directory.
It would also be possible to modify this hack to survive a reboot.
The second link won't work with some browsers, such as MS Edge, and it is possible that some affected models may not include busybox's support of the variable manipulation used in the fix.
Use at your own risk and all that.
Friday, 8 June 2018
Monday, 4 January 2016
KKMoon 805 IP Camera Webviewer
I recently purchased a Kkmoon 805 720p IP Camera off ebay. It's software indicates that it is based on a Texas Instruments DM365 processor.
It supports connection via P2P and RTSP. Log in uses basic authentication, it does not support HTTPS, so passwords are sent unencrypted and unfortunately its firmware doesn't appear to restrict the number of unsuccessful attempts to log in either.
I've found the RTSP steam can be viewed without a password anyway.
The following URLs worked for me using VLC media player:
rtsp://user:pass@IPAddress:554/0 (720p stream, averages ~15fps, user and pass can be anything)
rtsp://user:pass@IPAddress:554/1 (480p stream.. " " ")
The following URLs also worked with VLC in Linux and android, but not in Windows:
rtsp://IPAddress/camera-media/profile0 (720p)
rtsp://IPAddress/camera-media/profile1 (480p)
rtsp://IPAddress/camera-media/profile2 (opened both streams in the vlc plugin)
To download a still from the camera:-
http://IPAddress/snapshot/image0.jpg (320px x 240px).
P2P allows the camera to be remotely accessible over the net with minimal configuration, it doesn't need port forwarding set up, or uPnP enabled, or DDNS. Unfortunately, if you don't want to allow P2P access, there's no option to disable P2P, other than blocking internet access for it in the router's firewall.
The Android app I'm using is P2PCam_HD installed from Google Play, although I'm not sure if that is the official app for this camera, as I didn't install the one from the CD/website.
Image quality is acceptable, but not fantastic, and deteriorates badly in low light, until it flips out the IR-cut filter and switches to black & white. Night vision lit by the IR emitters is fairly good. Sound quality is poor, and I've yet to manage to access an audio stream other than by the P2P apps.
A nice feature is that it can record to a micro-SD card in 720p (or 480/320 if preferred).
It is supposed to be able to send an email when it detects motion, but I've been unable to get email to work with any email service I've tried, other than for sending the test email.
EDIT: I was able to receive emails by running a local smtp server with the SSL option unticked, StartTLS doesn't seem to be implemented, and I'm guessing its SSL support is obsolete due to the SSL vulnerabilities.
Another very annoying issue is occasionally when viewing the RTSP stream directly, with a programme like VLC or an ONVIF recorder, the camera will pan or tilt on its own accord, and sooner or later the connection will drop with the camera firmware seeming to partially crash and reset itself, although it doesn't lose the time. So far this hasn't happened when monitoring the stream using its P2P apps, or recording to a micro SD card while not being monitored.
The random pan/tilt issue seems to occur much less frequently when the camera has been up and running without a reboot for more than six days.
The camera's positioning to presets doesn't seem to be reliably accurate, I suspect they might be getting corrupted along with the camera's track of its current position due to the crashes.
There is nothing under the hole marked "Reset" in the bottom of the generic case. I removed the bottom from mine and found a pin hole under one of the sticky labels above a button on the rather diminutive circuit board for the various connectors. The pin hole is about ½" behind the camera mount screw and ¼" toward the side with the network port.
The official software is hosted here:- http://down.54it.cn
The browser interface requires the installation of an activex plug-in, requiring Internet Explorer, so I've created a web page that also works in Firefox (32 bit version only) with the VLC plugin included with VLC Media Player to display the RTSP stream. IP address and port are stored as cookies. If you have one of these I've hosted it here, or you can use it directly from this page:-
Unfortunately, Firefox will be dropping support of all NPAPI plugins, and the VLC NPAPI plugin is not one of the few permitted to run in the 64 bit version, so the 32 bit versions of both firefox and vlc is required. It
Edit: I've modified my javascript to get it working in Internet Explorer (both 32 and 64 bit).KKMoon 805 IP Camera Webviewer
![]()
Presets
Goto
Set
User Password(anything will do) Alt Url (linx only)
It supports connection via P2P and RTSP. Log in uses basic authentication, it does not support HTTPS, so passwords are sent unencrypted and unfortunately its firmware doesn't appear to restrict the number of unsuccessful attempts to log in either.
I've found the RTSP steam can be viewed without a password anyway.
The following URLs worked for me using VLC media player:
rtsp://user:pass@IPAddress:554/0 (720p stream, averages ~15fps, user and pass can be anything)
rtsp://user:pass@IPAddress:554/1 (480p stream.. " " ")
The following URLs also worked with VLC in Linux and android, but not in Windows:
rtsp://IPAddress/camera-media/profile0 (720p)
rtsp://IPAddress/camera-media/profile1 (480p)
rtsp://IPAddress/camera-media/profile2 (opened both streams in the vlc plugin)
To download a still from the camera:-
http://IPAddress/snapshot/image0.jpg (320px x 240px).
P2P allows the camera to be remotely accessible over the net with minimal configuration, it doesn't need port forwarding set up, or uPnP enabled, or DDNS. Unfortunately, if you don't want to allow P2P access, there's no option to disable P2P, other than blocking internet access for it in the router's firewall.
The Android app I'm using is P2PCam_HD installed from Google Play, although I'm not sure if that is the official app for this camera, as I didn't install the one from the CD/website.
Image quality is acceptable, but not fantastic, and deteriorates badly in low light, until it flips out the IR-cut filter and switches to black & white. Night vision lit by the IR emitters is fairly good. Sound quality is poor, and I've yet to manage to access an audio stream other than by the P2P apps.
A nice feature is that it can record to a micro-SD card in 720p (or 480/320 if preferred).
It is supposed to be able to send an email when it detects motion, but I've been unable to get email to work with any email service I've tried, other than for sending the test email.
EDIT: I was able to receive emails by running a local smtp server with the SSL option unticked, StartTLS doesn't seem to be implemented, and I'm guessing its SSL support is obsolete due to the SSL vulnerabilities.
Another very annoying issue is occasionally when viewing the RTSP stream directly, with a programme like VLC or an ONVIF recorder, the camera will pan or tilt on its own accord, and sooner or later the connection will drop with the camera firmware seeming to partially crash and reset itself, although it doesn't lose the time. So far this hasn't happened when monitoring the stream using its P2P apps, or recording to a micro SD card while not being monitored.
The random pan/tilt issue seems to occur much less frequently when the camera has been up and running without a reboot for more than six days.
The camera's positioning to presets doesn't seem to be reliably accurate, I suspect they might be getting corrupted along with the camera's track of its current position due to the crashes.
There is nothing under the hole marked "Reset" in the bottom of the generic case. I removed the bottom from mine and found a pin hole under one of the sticky labels above a button on the rather diminutive circuit board for the various connectors. The pin hole is about ½" behind the camera mount screw and ¼" toward the side with the network port.
The official software is hosted here:- http://down.54it.cn
The browser interface requires the installation of an activex plug-in, requiring Internet Explorer, so I've created a web page that also works in Firefox (32 bit version only) with the VLC plugin included with VLC Media Player to display the RTSP stream. IP address and port are stored as cookies. If you have one of these I've hosted it here, or you can use it directly from this page:-
Unfortunately, Firefox will be dropping support of all NPAPI plugins, and the VLC NPAPI plugin is not one of the few permitted to run in the 64 bit version, so the 32 bit versions of both firefox and vlc is required. It
Edit: I've modified my javascript to get it working in Internet Explorer (both 32 and 64 bit).
720p
480
Camera IP
:
IRCut Colour Sensitivity= Mirror=
White Balance = Flicker=
ExposureTime=
User Password(anything will do) Alt Url (linx only)
Tuesday, 16 November 2010
Repairing a Ford Focus or Mondeo Keyfob Remote
A few months back my father was having trouble with the remote control central locking on his Ford Focus, a new battery in the keyfob didn't help, so I gave the contacts a quick clean with some isopropyl alcohol and all seemed well, until about a month later when it stopped working again. Initially I suspected the cheap 8 for a pound lithium battery I'd used, but realised it was probably a faulty switch after a further replacement only lasted a week, by which time the doors had also started to occasionally relock themselves.
A replacement remote keyfob from Ford, is quite expensive, so he was keen for me to try and fix it.
To get the key apart, use a small screwdriver inserted into the slot at the back to pry the remote section out of the key yoke. The two halves of the remote section then simply unclip.
Should you decide to order a new remote from Ford, you'll find the part number on the remote section just below the slot. The RFID chip, which deactivates the immobiliser appears to be located in the half containing the battery, so if you don't have the two keys required to reprogram the immobiliser to accept the RFID in a new remote, swapping the battery compartment over would probably work.
The plastic cover over the PCB is held in place by a couple of plastic pegs, which have had their ends melted to stop them pulling back through the holes. Rather than cut the melted ends off , I squeezed them around with a pair of tweezers reducing the diameter enough to pop through the hole.
By now I'm wearing an anti-static strap, rather than risking zapping the electronics. They only cost about 2 quid from somewhere like dealextreme, but don't buy "wireless" ones, as they are a con, and don't work.
Gently pop the top peg out of the slot in the PCB to release it.
With the PCB removed, you can see the three miniature switches.
Testing my dad's ones with a meter revealed that the lock button had a partial short, enough to slowly drain the battery, but not normally quite enough to trigger the doors to lock
The cause was corrosion inside the switch, the debris from which, was creating the short. It must have got moisture in, although my dad is certain that the key has never got wet. The key for his previous Focus went through the wash cycle on at least one occasion that I know of, but never developed a fault, the seal on this one clearly isn't so good.
The switches come apart quite easily, by using a jeweller's screwdriver to pop off their metal shells. They are a miniature leaf switch, one leaf acts as a contact, the other increases the force required to operate it. The one shown on the left was black, but cleaned up quite well
As a temporary fix, I unclipped the metal shells, scraped off the worst of the corrosion from the contacts and the silver plated leaf on each switch with a jeweller's screwdriver, and cleaned them with isopropyl alcohol. This restored the remote to full working order, if you are lucky that might be all that is needed, but because of the very poor condition of the lock switch, I decided to source some replacements.
The switches are 2 x 6 mm KSR subminiature tactile switches made by C&K. From measuring the pressure required to operate the originals, I reckoned the 4.5N KSR251GLFS is the best match. You might even find you could swap the leaf switch and buttons over, rather than unsoldering the base, providing you can get the contacts in the switch base nice and clean.
I'm afraid I don't have any pictures of soldering the replacement switches in, as I passed the job on to my brother; he's vastly better at soldering fiddly smt components than me. He tells me that he used a craft knife to separate the solder joints while heating it with his iron.
When you come to soldering the new switches on the solder pads on the switch are gull-winded so should draw the solder in, the tricky bit is having a steady hand so as not to move them, or if you are clumsy like me, you might find it easier to solder them if you use a plastic spring clip to hold them in place.
After reassembling and testing the key, you should fix the PCB and its cover firmly in place, as even a small amount of play can cause the battery contacts to bend and eventually lose contact with the pads on the PCB when pressing the buttons.. So I'd suggest gluing it in place, or as I have, to make it easy should I ever need to take it apart again, I stuck a small thin square of foam rubber (I used a strip of stick on rubber feet, but something like draft excluder might be thin enough) on the PCB cover so that it presses on the centre of the battery.
The key is now working fine, and cost less than a tenner to fix, with a few spare switches left over, should it ever fail again.
A replacement remote keyfob from Ford, is quite expensive, so he was keen for me to try and fix it.
To get the key apart, use a small screwdriver inserted into the slot at the back to pry the remote section out of the key yoke. The two halves of the remote section then simply unclip.Should you decide to order a new remote from Ford, you'll find the part number on the remote section just below the slot. The RFID chip, which deactivates the immobiliser appears to be located in the half containing the battery, so if you don't have the two keys required to reprogram the immobiliser to accept the RFID in a new remote, swapping the battery compartment over would probably work.
 |
By now I'm wearing an anti-static strap, rather than risking zapping the electronics. They only cost about 2 quid from somewhere like dealextreme, but don't buy "wireless" ones, as they are a con, and don't work.
Gently pop the top peg out of the slot in the PCB to release it.
With the PCB removed, you can see the three miniature switches.Testing my dad's ones with a meter revealed that the lock button had a partial short, enough to slowly drain the battery, but not normally quite enough to trigger the doors to lock
The cause was corrosion inside the switch, the debris from which, was creating the short. It must have got moisture in, although my dad is certain that the key has never got wet. The key for his previous Focus went through the wash cycle on at least one occasion that I know of, but never developed a fault, the seal on this one clearly isn't so good.
The switches come apart quite easily, by using a jeweller's screwdriver to pop off their metal shells. They are a miniature leaf switch, one leaf acts as a contact, the other increases the force required to operate it. The one shown on the left was black, but cleaned up quite wellAs a temporary fix, I unclipped the metal shells, scraped off the worst of the corrosion from the contacts and the silver plated leaf on each switch with a jeweller's screwdriver, and cleaned them with isopropyl alcohol. This restored the remote to full working order, if you are lucky that might be all that is needed, but because of the very poor condition of the lock switch, I decided to source some replacements.
The switches are 2 x 6 mm KSR subminiature tactile switches made by C&K. From measuring the pressure required to operate the originals, I reckoned the 4.5N KSR251GLFS is the best match. You might even find you could swap the leaf switch and buttons over, rather than unsoldering the base, providing you can get the contacts in the switch base nice and clean.
I'm afraid I don't have any pictures of soldering the replacement switches in, as I passed the job on to my brother; he's vastly better at soldering fiddly smt components than me. He tells me that he used a craft knife to separate the solder joints while heating it with his iron.When you come to soldering the new switches on the solder pads on the switch are gull-winded so should draw the solder in, the tricky bit is having a steady hand so as not to move them, or if you are clumsy like me, you might find it easier to solder them if you use a plastic spring clip to hold them in place.
After reassembling and testing the key, you should fix the PCB and its cover firmly in place, as even a small amount of play can cause the battery contacts to bend and eventually lose contact with the pads on the PCB when pressing the buttons.. So I'd suggest gluing it in place, or as I have, to make it easy should I ever need to take it apart again, I stuck a small thin square of foam rubber (I used a strip of stick on rubber feet, but something like draft excluder might be thin enough) on the PCB cover so that it presses on the centre of the battery.
The key is now working fine, and cost less than a tenner to fix, with a few spare switches left over, should it ever fail again.
Friday, 16 May 2008
Nebuad's opt-out
I thought I'd have a quick look at one of Phorm's rivals, Nebuad.
Apparently much like Phorm, Nebuad uses a cookie based opt-out. Opting out or back-in is achieved by requesting a URL, in response to which Nebuad's server sends your browser its opt-out, or opt-in cookies...
Surprisingly, the opt-in /opt-out pages are indexed by google: http://www.google.co.uk/search?num=100&hl=en&q=site%3Anebuad.com+optin&meta=.
The above search no longer works try http://www.google.co.uk/search?num=100&hl=en&q=site%3Anebuad.com+optout+OR+optin_done&btnG=Search&meta=.
Also cookie "h" is no longer set.
WARNING: if your ISP uses Nebuad and you've already opted-out, then opening the second search result shown in google (www.nebuad.com/privacy/optin_done.php) will almost certainly opt you back in.
WARNING: I've just noticed that Firefox has a page pre-fetch feature which might result in the opt-in page being accessed and the cookie changed just by clicking on the google search above (depends on which link appears first I think)- if you click on the link above, please make sure you opt-out afterwards.
Nebuad's opt-in/opt page can be found here:- www.nebuad.com/company/optout.php
Opting in creates 2 sets of 5 cookies, "o","u","c","h","w", one set in "a.faireagle.com", and the other in the "b.faireagle.com" subdomain. Opting out sets "o"="9" and deletes the other cookies.
o = 0 appears to indicate opted in.
o = 9 indicates opted out.
My guess is "o" might be a set of binary flags eg
bit #0 = 1 - don't track
bit #3 = 1 - don't show targetted adverts.
'c' is the name of an adserver.
'h' and 'u' are set to matching 14 digit numbers.
'w' is another 14 digit number, which appears to count upwards (could be a date and time perhaps?).
Different sets of numbers are generated for the a and b subdomains.
If you look at the bottom of the opt-in page you'll see the actual opt-in urls passed using a couple of <script> tags right at the very bottom after the closing html tag, the browser will request these urls and the server will set the cookies in the response and close the connection (no actual javascript is returned by the response).
<script language="JavaScript" src="http://a.faireagle.com/a?t=o&track=yes&noads=none"></script>
<script language="JavaScript" src="http://b.faireagle.com/a?t=o&track=yes&noads=none"></script>
And for the opt-out page.
<script language="JavaScript" src="http://a.faireagle.com/a?t=o&track=no&noads=all"></script>
<script language="JavaScript" src="http://b.faireagle.com/a?t=o&track=no&noads=all"></script>
There does not appear to be any measures in place to prevent an "evil" website from opting you back-in using the same method - try clicking on Google's cached optin_done link and check for faireagle.com cookies.
Apparently much like Phorm, Nebuad uses a cookie based opt-out. Opting out or back-in is achieved by requesting a URL, in response to which Nebuad's server sends your browser its opt-out, or opt-in cookies...
Surprisingly, the opt-in /opt-out pages are indexed by google: http://www.google.co.uk/search?num=100&hl=en&q=site%3Anebuad.com+optin&meta=.
The above search no longer works try http://www.google.co.uk/search?num=100&hl=en&q=site%3Anebuad.com+optout+OR+optin_done&btnG=Search&meta=.
Also cookie "h" is no longer set.
WARNING: if your ISP uses Nebuad and you've already opted-out, then opening the second search result shown in google (www.nebuad.com/privacy/optin_done.php) will almost certainly opt you back in.
WARNING: I've just noticed that Firefox has a page pre-fetch feature which might result in the opt-in page being accessed and the cookie changed just by clicking on the google search above (depends on which link appears first I think)- if you click on the link above, please make sure you opt-out afterwards.
Nebuad's opt-in/opt page can be found here:- www.nebuad.com/company/optout.php
Opting in creates 2 sets of 5 cookies, "o","u","c","h","w", one set in "a.faireagle.com", and the other in the "b.faireagle.com" subdomain. Opting out sets "o"="9" and deletes the other cookies.
o = 0 appears to indicate opted in.
o = 9 indicates opted out.
My guess is "o" might be a set of binary flags eg
bit #0 = 1 - don't track
bit #3 = 1 - don't show targetted adverts.
'c' is the name of an adserver.
'h' and 'u' are set to matching 14 digit numbers.
'w' is another 14 digit number, which appears to count upwards (could be a date and time perhaps?).
Different sets of numbers are generated for the a and b subdomains.
If you look at the bottom of the opt-in page you'll see the actual opt-in urls passed using a couple of <script> tags right at the very bottom after the closing html tag, the browser will request these urls and the server will set the cookies in the response and close the connection (no actual javascript is returned by the response).
<script language="JavaScript" src="http://a.faireagle.com/a?t=o&track=yes&noads=none"></script>
<script language="JavaScript" src="http://b.faireagle.com/a?t=o&track=yes&noads=none"></script>
And for the opt-out page.
<script language="JavaScript" src="http://a.faireagle.com/a?t=o&track=no&noads=all"></script>
<script language="JavaScript" src="http://b.faireagle.com/a?t=o&track=no&noads=all"></script>
There does not appear to be any measures in place to prevent an "evil" website from opting you back-in using the same method - try clicking on Google's cached optin_done link and check for faireagle.com cookies.
Thursday, 24 April 2008
Phorm Webwise diagram
 |
Phorm's system will intercept requests that don't contain their "webwise" tracking cookie and send them through a series of redirects to access and transfer the unique identity number they allocate to you from your webwise.net master cookie to a tracking cookie they'll create for each site you visit.
This cookie will expire after three days, until then your browser will send this cookie with future requests for the site and their system will strip the cookie from each request and use it to identify your profile as it analyses your http traffic - including the search parameters you enter into major search engines, and the content of the pages you view.
Dr Richard Clayton has updated his paper on Phorm webwise, after Phorm managed to recall more of the detail of their system twisty-little-passages-all-alike.
It now seem that an additonal redirect will occur if a webwise.net cookie isn't present to determine if the user is blocking webwise.net cookies, in which case the user's IP address will be blacklisted for 30 minutes to avoid infinite loops.
It seems logical to me that they would use a similar approach to determine if the user is blocking cookies for the actual site he is visiting, either by setting a test cookie with the first redirect if no cookies are present in the initial request, or by using an additional redirect.
A poster on Badphorm has pointed out that because phorm's system redirects the browser to a third party domain (webwise.net), the webwise.net cookie is in fact a third party cookie.
As reported in that thread Opera will correctly (according to rfc2965) block (neither send not accept) all cookies after a redirect to a third party domain occurs if the "accept only cookies from the site I visit" option has been enabled by the user. It will continue to block cookies until a user action occurs where the user can verify the domain requested -such as clicking on a link on the page (even if subsequently redirected back to the original URL).
This will also result in the genuine website not being sent its cookies after a Phorm redirect, which will cause problems for users of Opera that block third party cookies.
Subscribe to:
Posts (Atom)