cybergibbons

Part of the issue here is you don't need to port forward for the device to be at risk. Another part is that it isn't just this DVR, so many of them have issues. This site explains how similar attacks have been happening against routers: http://malware.dontneedcoffee.com/2015/05/an-exploit-kit-dedicated-to-csrf.html It's quite advanced, but it is actually happening. And it's not teenagers you are going to need to worry about, it's organised crime from other parts of the world. As an aside, which DVR brands do you all trust? I've got budget to buy higher end gear and want to have a crack at something good.

It's a lot easier to find this out now than engineer codes. The thing with engineer codes is that they are a built-in part of the system, known and accepted by many. The problems in the DVR aren't exactly in the manual.

It's been viewed by tens of thousands already, so the cat is out of the bag. The solution has a few aspects: 1. Don't trust very cheap gear, especially if it has no firmware updates. 2. Make sure you change passwords from defaults. 3. Don't port forward to the device from the open internet 4. If remote access is required, use a VPN. 5. Segregate it from the rest of your network on a VLAN or subnet. 6. Block outbound traffic so it can't create a reverse shell. 7. If it has HTTPS, enable it.

So, if you port-forward, it's obvious - Shodan will find the unit, and because it has a distinctive HTTP header, can be found. We can see 44k of them by this means. But if I add the following HTML to a web page: <IMG SRC="http://192.168.1.201/shell?[commandfor reverse shell]">, and you visit that site, the DVR will connect back to me, so I can control it. That's just for one IP. so I'd use JavaScript and essentially check all likely internal IPs. This is because it is lacking cross-site request forgery protection. It's not a lack of functionality or spec really, unless they write "No backdoors! No hardcoded passwords!". Even some fairly expensive DVRs have some issues: http://www.theregister.co.uk/2016/02/18/blank_519070_the_pin_to_enter_to_pwn_80k_online_security_cams/ Hikvision have had problems in the past: https://community.rapid7.com/community/metasploit/blog/2014/11/19/r7-2014-18-hikvision-dvr-devices--multiple-vulnerabilities They were responsive when I spoke to them about issues with IP cameras though.

I'd be very surprised if this wasn't being used already. It took less than a few hours to find the issue, and we've certainly seen attacks of this type carried out against home and business routers.

They should. It's essentially the same as letting someone come into your business and plug in a computer to the network.

If you are very strict about it, then it can be safe. When you are on the VPN connecting to the DVR, you must not browse any other sites, otherwise the attack could be carried out against it. All outbound access from the DVR needs to be blocked.

There's absolutely no requirement to use a password on this. I can make it connect back to my server and control it just by entering a URL on it. Or I could get you to visit a site with the URL on it.

I looked at a cheap DVR and found some really quite serious issues. If you port-forward to this, an attacker - and not a skilled one - can take complete control of the device and do what they want on your network. https://www.pentestpartners.com/blog/pwning-cctv-cameras/ I wouldn't trust any DVR to be honest. Expect more like this in the near future.

Most of the systems use 2-FSK, so pick a signal that approximately matched the bit-rate of that and toggle between the two. So you end up with: FSK signal modulated at 9600Hz or something - this interferes with the signal itself Switch that on and off at 0.05s (i.e. 20Hz) - this stops the jamming detection being triggered, but is often enough to interfere. Might have to up the frequency a bit here for some systems. The problem is that with the 2-way RF gear, they have two types of jamming detection: 1. Signal strength or RSSI based - this is what the standard describes and is all that 1-way can do. 2. Pings - send a message to detector, if it doesn't come back, get worried. The Enforcer will almost certainly do both. There's loads of interesting stuff you can do with jamming, but probably not for discussion in public.

The spec is any 31s out of 60s. Drive a jammer with a 50% duty cycle, period of about 0.05s, and the jamming detection won't go off, but nothing will get through.

The one I've seen a few times is cheap baby monitors that transmit a continuous signal in 868MHz, they are quite obvious. But lots of other stuff is much harder to track down. The standard says that for grade 1 and 2, it's 31s out of 60s to signal jamming, 3 and 4, 11s out of 20s. Many of them also detect if messages are dropped, but only if they have 2-way RF.

I think so. It's just setting a frequency range, and it does the rest of it pretty much automatically. Problem is, once you've found there is another signal, what do you do?

A thing you plug into your computer, it receives a wide-ish bit of the spectrum (5MHz-100Mhz, typically), and you can show it on your screen as a spectrum or waterfall: http://nansupport.com/images/rfexplorer/heatmap-800x349.png Difference between the RF Explorer and SDR is that the RF Explorer sweeps - starts at 858MHz and slowly goes up to 878MHz, whereas an SDR can receive the whole 20MHz instantly. Just means you can miss things.

https://www.coolcomponents.co.uk/rf-explorer-3g-combo.html They are good for the money. Fragile though - power switch and USB has broken on mine and it's always been taken care of. It will pick up most accidental sources of jamming, but miss intentional because of the slow sweep speed. A SDR is better to pick up intentional jamming.

Some of the outputs are pre-set to mirror other signals in the alarm.

The biggest problem by far is the small key compared to the code size, so I've kind of stopped looking into this one.

The same is true for encryption in some wireless systems. The receiver in the panel doesn't have the overhead to deal with a key per detector, so it just uses a single system wide key. That means all detectors, ever, use the same key...

Thanks. With a) it seems that the main issue is that customers could reset the panel when the ARC doesn't want them to. b) I suspect exactly the same algorithm is used in the panel as in the program. I think the algorithm was written for whatever 8-bit processor was used in those days. Might as well show the algorithm used, the only bit of it that needs to be secrete is the vector at the top which I have changed. I don't know if you know any programming or python, but it's really simple. # Taken from the data in the exe vector = [3,3,5,5,8,1,3,9,8,0,5,9,3,9,4,1,1,0,9,4,3,0,2,2,8,4,3,2,8,4,9,4,1,3,3,3,3,8,5,3,0,2,4,3,2,1,8,9,0,5,4,3,9,5,8,3,9,9,1,0,0,9,9,3,3,8,2, 1,4,9,1,4,9,2,9,0,9,5,3,9,5,3,3,5,9,1,0,2,9,3,2,1,2,9,8,0,4,9,4,2,3,9,4,0,1,8,5,3,3,9,9,1,0,5,9,3,8,9,4,8,4,2,3,1,0,3,9,4,8,2,0,4,3,3, 1,0,5,2,8,3,3,5,2,8,3,2,9,5,2,1,2,4,4,3,0,4,2,3,4,1,8,2,9,1,0,5,1,8,2,4,3,5,1,0,3,8,5,3,2,1,1,3,9,3,2,3,5,8,3,9,0,3,2,3,5,3,8,4,0,3,9, 1,9,3,0,2,9,3,8,1,4,2,8,4,0,1,9,1,0,1,2,1,3,5,3,3,9,0,2,1,4,1,2,3,4,3,4,9,5,3,5,9,3,1,3,9,4,0,3,2,3,3,4,4,2,1] def generate_reset(quote, version): i = 0 tens = 0 reset = [] while i <= 4 : j = 0 result = 0 while j <= 4: offset = (version + tens + quote[j]) % 256 result = result + vector[offset] tens = tens + 10 j = j + 1 reset.append(result%10) i = i + 1 return reset print(generate_reset(quote = [0,0,0,0,2], version=131)) Notice that there is no multiplication, division, or anything fancy. The % symbol means "modulus" which most people know as "remainder". So "% 256" means "divide by 256 and give me the remainder". You normally get this for free in a microcontroller - an 8-bit number is limited to 256 values, so it just wraps round anyway. Panel firmware would contain it - in fact, now that I know certain panels have it, I can find the long string of characters called "vector" in some of them. The problem with panel firmware is that it is very hard for me to work out what is data and what is code. In x86 exes, there are normally a lot more hints available to me. I can also easily run an x86 exe and step through the running code to see how it works. With a microcontroller in an alarm, I can't easily do this.

Tunstall are someone who Menvier took over who Cooper took over? If you can point me towards a program to generate them...

Precisely Joe. This is just an easy target to show that.

It's all part of learning. Nothing lost for a few hours work.

So I wonder what drove the standard to require that and where the 5-digit Technistore code fits in to this? There must have been some reason behind it being 5-digit - it's rarely seen as a code length. It's a combination of the long code and short key. The key allows 256 distinct mappings between the quote code and reset code. That means that 12345 quote can only map to at most 256 of the 100,000 possible output values. 999,744 of the outputs are not possible - our keyspace has been reduced hugely. Notice I say "at most 256". It is possible for 12345 to map to 98765 using one or more keys. In fact, 12345 could map to 98765 using all 256 keys, but then we wouldn't need to find out they key at all. So if you tell me the reset code and I know the quote code, it is highly likely that I can just guess the key. For a very limited number of quote/reset pairs, I get 2 possible keys (in fact, there are two combinations with 4). So more than 99% of the time, I just need a single quote/reset pair to work out the key. So normally I get something like: 12345/74643 - only possible key is 123 (99.25% of the time) Sometimes I get this: 23654/34234 - two possible keys 232 and 154 (about .75% of the time) 98747/37265 - one possible key 232 (about 99.25% of the time) It would be really unlikely to get this: 23654/34234 - two possible keys 232 and 154 (about .75% of the time) 91737/72764 - two possible keys 078 and 154 (about .75% of the time) (we know the key is 154 as it is the only common one) Vanishly small chance of this happening: 23654/34234 - two possible keys 232 and 154 (about .75% of the time) 73748/38377 - two possible keys 232 and 154 (about .75% of the time) 98747/37265 - one possible key 232 (about 99.25% of the time) I've just tested these by running every single possible combination of key and input code against the algorithm. Not in any detail - have started looking at Texecom. Not aware of Tunstall.