haicen

There wasn't a huge amount of stuff available. The most concerning thing I found was an undocumented user with a visible password. I wrote a small write up at https://haicen.blogspot.com/2016/08/security-dvr-hacking.html. I have been super busy with life stuff, and haven't really had time to do much. I have a few ideas. I suspect there might be something going on with one of the open ports. I tried looking at it with wireshark and netcat, but didn't see anything happening. I might look at it some more soon. I couldn't get video to work at all in any browsers that aren't IE due to the reliance on ActiveX.

I have created a python script to generate dahua hashes. These hashes are frequently found in security camera DVR units. It is an MD5 hash that is compressed into 8 characters. The code is available at https://github.com/haicen/DahuaHashCreator I did this as more of a learning exercise, but other people may find it useful. These hashes are easily cracked using John the Ripper, as long as the hash is in the right format. For the DVR I had, the passwords could be a max of 6 characters long, so a warning will be generated if a password is specified that is longer than 6 characters, but it will output the hash anyway.

Thanks. I did that and got an answer.

I have a bit of an odd question that I'm hoping someone here can point me in the right direction to figure out. I have been looking at a DVR which I purchased for the express purpose of poking around on. I was able to gain access to it via telnet, and found some interesting things. I found the password hashes for the web portal. The passwords themselves are hashed using an algorithm detected by JTR as "dahua". Outside of the source code for the JTR module located at http://fossies.org/linux/john/src/dahua_fmt_plug.c I cannot find any information about how this algorithm works. I spent several hours using my google-fu, but I haven't found anything yet. Here is what I have so far from reading the source code from above: The password is hashed using MD5, then compressed using the compress method included above. I don't know C well enough to be able to translate the rest of it, but that seems to be 99% of the work. I am getting hashes in the correct format using the code posted below, but they aren't correct. The code from the JTR module expects a 16 character hash, but MD5 returns a 32 character hash. I am quite rusty on C/C++, but I'm having a really hard time understanding the flow of the C program of the JTR module, particularly with pointers, and memory allocations. I know my python file has some errors in it, because it wasn't until I started writing this that I realized it was only checking the first 16 characters of the hash, not the full 32. It doesn't matter because the compressor as written only reduces the length by 2 anyway. dahua_hash.py

I figured out the hashing algorithm used. It is dahua, which is easily cracked by JTR.

Its running busybox v1.16.1 Using the hashed password won't work. They aren't hashed or encrypted on the client side. In fact, they are sent in the clear every time the user visits a different page of the interface as well as being stored as a cookie.

Just as a followup, I was able to gain access to the device via telnet. Poking around the filesystem, I found a separate passwd file, which is different. This new passwd file contains the information for the web interface and local device login. I.E. the web viewing portal. Here is what I know: The admin combo is admin:123456. The passwords are not tied to a specific username. I created a few different user names with the same password. The hashes were constant. The password cannot be longer than 6 characters, special characters are allowed At this stage, I am attempting to determine what method is being used to hash these passwords. I have tried a few variations using 612345, 000000, 123455, etc, but do not see a pattern directly. format is pw - hash 123456 - nTBCS19C 5555 - QwZ3AbMB 000000 - qAj0oSP1 111111 - 9kwf1kHJ 222222 - z7a10QFR 612345 - gJJp8X7Q In the directory above this passwd file, there is a file called encrypt_info, but it only contains the MAC address of the device, a product number, and the following line: oem 000015 Since the password is limited to 6 characters, this oem value seems of interest. I suspect the values are base64 encoded, but I've tried playing around with a b64 encoder/decoder, and can't find anything that matches.

Thanks for the help.

Nevermind. I decided to do a quick google search for the hash, and as it turns out, it has already been cracked. I don't know why I didn't try that first.

I am doing a pure brute force attack. I am assuming since the password wasn't one of the usual defaults that it wouldn't be generated by a human. I don't have any details about what format the password is in.

I picked up a cctv system from newegg for $50. Partly because I wanted to be able to keep an eye on my apartment when I'm away, and partly to play around with. Specifically, it is a Rosewill RSCM-0704B042. The first thing I did was fire up nmap to see what ports were open. I see the following ports open: 23 (telnet),80 (web),554 (rtsp),8000 (web alt) ,49152 (unknown). My best guess for port 49152 is that it is for the custom viewing application. I tried to connect to the device via telnet with the usual password combos root/root, root/blank, root/toor, root/password, as well as the default password for the web interface admin/123456. None of these worked, which was surprising. My next step was to take a look at the firmware, so I pulled a copy from http://www.rosewill.com/media/downloadable/drivers/Shieldeye_PC-_CMS.zip to see if there was anything interesting. I unpacked the romfs and found etc/passwd files. There was a standard passwd, and "passwd-". I don't know what significance the "passwd-" has. I have included both hashes below. "passwd" root:$1$$64lU4r1qa6icjzK/sBmQo.:0:0::/root:/bin/sh "passwd-" root:ab8nBoH3mb8.g:0:0::/root:/bin/sh The first i immediately sent to jtr, but it has been running for >12 hours. I basically have 2 questions: Will jtr eventually crack the password? My assumption is that it will eventually be cracked. Is there a better tool for cracking the password? I am currently generating a rainbow table for 1-7 character lowercase alpha passwords. It has occurred to me that this probably isn't the correct keyspace to be searching.

You don't need a 5th quote because it is included in the underlying php code that handles the query. From the DVWA code, $id = $_REQUEST[ 'id' ]; // Check database $query = "SELECT first_name, last_name FROM users WHERE user_id = '$id';"; In this case, $id is equal to whatever you put into the text box. So if you take your example a' OR '1'='1 the query will look like this: $query = "SELECT first_name, last_name FROM users WHERE user_id = 'a' OR '1'='1';"; As you can see, when your SQLi statement is given in the textbox, the quotes will be balenced. If you added another quote, the line would be like this: $query = "SELECT first_name, last_name FROM users WHERE user_id = 'a' OR '1'='1'';"; This won't work because there is an odd number of single quotes, and will cause the php code to have an error. Another thing to note, is that -- is the default comment operator for sql. This will cause whatever happens after the -- to not be evaluated by sql. For example, if you're target is a username/password combo, you may only need to try injecting the username field. Your test string would be a' OR 1=1 -- this interrupts the rest of the query string, unless there is something else going on in php, this is what the sql statement looks like: SELECT <whatever> from <database> WHERE 'a' OR 1=1 Also, note that you don't have to use '1'='1 in the previous examples either. Your test string could be: a' OR 1=1 OR ' The SQL statement will be: SELECT <whatever> from <database> WHERE 'a' OR 1=1 OR '' <rest of query> The end result is the same. I prefer to use as few quotes as possible to reduce confusion on my end. Hope this helps.

I haven't quite given up yet. I have been comparing the contents of the folders before and after changing the password. The process I have been using is: tar the directory, output it to a writeable directory IE tar -c -f /var/etc1.tar etc change the password tar directory again IE tar -c -f /var/etc2.tar etc calculate md5 sum for both hashes Strangely, the two directories I expected to change /etc/ and /usr/www have not been modified. Can a minor change like a password be insignificant after being compressed to a tar file? Another interesting inconsistency is that the "WPS" default pin isn't really the default pin. The config.xml says it is 12345670, but it is something completely different. I don't even know how that could happen unless the developers never configured that option.

No, I have access to everything as root. I'm 99% sure that the tw user was actually commented out in the passwd and shadow files. I believe them to be correct since I am able to log in as root. Modifying the firmware wasn't exactly the direction I wanted to go with since that is not a practical method for gaining admin access to the router. I was hoping it would uncover clues as to where the password was stored. I assume the admin password cannot be stored inside the webproc file itself. Reverse engineering is cool, but it just isn't part of my toolbox.

I still don't understand writing to the binary. I installed bless, but it looks nothing like the disassembled output, and the addresses are different. I'm trying to understand this part: Alf@UNKNOWN:~/Downloads/PenTest$ cp webproc webproc-mypatch1 Alf@UNKNOWN:~/Downloads/PenTest$ radare2 -e -b 32 -a mips webproc-mypatch1 Warning: read (strtab) at 0x20 Warning: Cannot initialize strings table [0x00401b70]> oo+ File webproc-mypatch1 reopened in read-write mode [0x00401b70]> s 0x401fcc [0x00401fcc]> pd 1 ,=< 0x00401fcc 10400026 beqz v0, 0x00402068 [0x00401fcc]> wx 14400026 [0x00401fcc]> pd 1 ,=< 0x00401fcc 14400026 bnez v0, 0x00402068 [0x00401fcc]> wx 10 [0x00401fcc]> pd 1 ,=< 0x00401fcc 10400026 beqz v0, 0x00402068 [0x00401fcc]> wx 14 [0x00401fcc]> pd 1 ,=< 0x00401fcc 14400026 bnez v0, 0x00402068 [0x00401fcc]> exit I understand that wx 14400026 writes 14400026 to address 0x00401fcc. What does wx 14 do? it doesn't write 14 to 0x00401fcc, so I'm not understanding what that operation does. I've worked with asm instructions before, but it was on a terrible spartan fpga, and was much simpler. Never disassembled anything. The hashes have nothing to do with the admin console unfortunately. They are static across password changes. What I know about the hash itself is that it is MD5, salted with "TW". I can't get johnny to crack them. The only output I get is "Loaded 1 hash" followed by "No password hashes left to crack". I don't know if I've put the file in the wrong format or what. It is still a work in progress.