swapped colors on snapshot taken via --hik_weak and some ideas

[avikowy]

when scanned host match both conditions - cve-2017-7921 and weak password 2 snapshots are generated, for snapshot triggered by cve colors are ok, but same camera snapshot made made as filename IP_PORT_login_password.jpg have disorted colors. is that happen everywhere or i have bad config (currently using ubuntu lxc container on proxmox)

how you download snapshots for hikvision with known password when url below doesnt work? how about this? http://login:password@IP:PORT/ISAPI/Streaming/channels/101/picture

i noticed jpegs generated with --hik_weak have quality set to 75 while i guess downloaded with http://IP:PORT/onvif-http/snapshot?auth=YWRtaW46MTEK in url are quality 80 so i guess its untouched.

some thoughts:

idea1. usualy there is more than one camera behind nat or in same subnet but many times while some are vulnerable some dont, how about to add option which will check already discovered password on vuln cam against others found on same ip/subnet, if password wasnt already changed by "visitors" there is high probability it will match to all other cameras/nvr used in same network.

idea2. with help of zoomeye ([almost] free alternative to shodan) users can generate list of ip:port targets for scan, noticed hikvision cameras usually set port forward via upnp on ports: 80-88,8080-8088 (depend of amount of cameras), by using filter https://www.zoomeye.org/searchResult?q=iconhash%3A%20%2289b932fcc47cf4ca3faadb0cfdef89cf%22%20%2Bservice%3A%22http%22 a search of favicon which is used by hikvision at login page, it will also return all clones from gray market since these are runnin with borrowed fw.

to narrow results only to vulnerable fw versions i use "Last-Modified" variable from http header. versions proven vulnerable to cve-2017-7921: "Last-Modified: Tue, 17 May 2016 10:22:58 GMT" "Last-Modified: Thu, 24 Mar 2016 05:58:21 GMT" "Last-Modified: Thu, 19 Mar 2015 09:24:20 GMT" there is 6 maybe 7 more which can be easily extracted using curl -H which will save headers then grep by "Last-Modified"

idea3. since scanner randomize targets result file will be also filled with random unsorted ip addresses, maybe nothing but i use something like this on result file to get rid of duplicates: cat results.csv |grep -v 2021- |cut --delimiter=, -f1,2,3,4 |sort -V |uniq result will contain only ip,port,login,password so can really help in batch import into vms (sort -V will gill give "natural" order of ip addresses - eg 35. before 105. etc)

idea4. it would be nice if not vulnerable targets (but confirmed to be an ip camera could be saved into separate log file for example not_vulnerable.csv for further research. who knows if such db will not be useful in future. now all targets which were not cracked are just skipped.

issue(5) for cve-2021-36260 i think there is no timeout (or does not work) and in case when remote host accepts connection but does not close - process will hang forever waiting for something - if multiple targets will keep connection opened scan speed will drasticaly drop.

question(6) is there any way to resume scan (there is paused.conf file - i think from masscan so probably only that part could be resumed)

[jorhelp]

Very good ideas, and I'm going to do some work on them. On the color issue: this color distortion is pervasive and I have this problem on Both Kali and Mac. I didn't use an url to get a snapshot, because I found that it wasn't universal and didn't work with some versions of the camera. Actually, I used RTSP to get the video stream (for both Hikvision and Dahua) and took a frame from it as a snapshot, which could be the reason for the color distortion.

[avikowy]

i think it could increase scan speed if scanner will try to recognise if current tested target is camera at all then based on banner more details could be used for identification, imho using favicon.ico hash is most accurate to detect hikvision products, also how about etag for particular fw version third section is common for different cameras, then if fw version is known no need to torture webserver eg for cve-2021-36260 if its known as not vulnerable, same as trying weak passwords, most of cams have set temporary login block after 5 failed auth

[jorhelp]

Very good advice, I agree with you very much. I will make some attempts on the dev branch and merge it into the master branch when it is stable.

[avikowy]

btw there is a little trap which can give false results for example there is 8 ip cameras and nvr behind nat, by default each camera is trying to set port forwarding via upnp for itself. i saw several times after power outage when all cams went back online at same port another camera appeared, its just depend which one will boot up faster and send request to router, also for port 8000, its possible for example we see cam1 on port 80 and we can assume at port 8000 there will be same camera but no, on port 8000 there is another one and if device on port 80 was already visited by botnet and pass has been changed - that password will not work on ivms at port 8000

[avikowy]

figured out color disortion, red and blue channels are swapped. can be fixed using irfan: image> swap colors > RGB - BGR

[jorhelp]

👍🏻 RTSP reads frames in BGR channel, however, PIL.Image saves images in RGB channel. Master branch has been updated.