Coffee Break // Home Pen-Testing 001 // Cyber News 011

A café lungo with a few ounces of half-caf is my brew today. The flavor lacks a bit of body, but it came out nice and foamy which (if I’m being honest) was my main goal in combining the two.

//

Pen-testing progress.

Last night I had a couple of hours to spend more time learning pen-testing techniques with my authorized attempts to gain access to my family’s security system.

I had left off having determined that at least some of the security devices in question were accessible via the local network.

I spent some time doing a bit of research on the manufacturer of those devices in question, and performed a more detailed network scan of the specific IP address that was related to that company.

At this point in time, I was fairly certain that the device in question was a Network Video Recorder, the brains of the camera system and the place where all of the footage was being recorded to an SSD or HDD. I learned that most models of NVR from this manufacturer are designed to stream their video to a paired app over Wi-Fi.

Now that I know what I’m looking for… how do I get access to it?

I installed and toyed with the app in question for a few minutes, but quickly determined that there wasn’t really anything I could licitly do with it—after all, the manufacturer of the security cameras was not a participant in this pen-test.
If I was an actual attacker, I probably wouldn’t hesitate to set up an account with the app and see if I could brute force the username/password combination, or experiment with trying to capture the hash of an accounts password over the network.
However, I felt that anything that could potentially interact with the manufacturer’s servers would be unethical: while I feel perfectly comfortable searching for vulnerabilities in the products that my family owns and has authorized me to test, I have no authorization from the manufacturers of those products to test the security of their user account system or server infrastructure. I’m pen-testing my network; not theirs.

Since that attack vector was off the table, I uninstalled the app and returned my focus to the local network. Scanning the target IP with nmap again, I determined that it did in face have an open port that was configured to stream video from the cameras.

Ok, we’re back in the game. How do we gain access to that stream?

Many media players, like the popular VLC media player allow users to control video streams and save them as files, or stream them straight to the application. If I could find the MRL (think like a web address) of the stream, I could potentially get that video sent to VLC player on my computer.

But how to find the MRL? Enter Cameradar. A CLI tool built specifically for that purpose. Cameradar scans the target IP range for video surveillance cameras, and tries a library of default credentials and MRL/URL variations to find the camera’s log-on information and stream MRL.

A look at Cameradar in action…

With the NVR’s stream MRL in hand, I plugged it into VLC Media player… but there was an issue:

The stream was password protected. I mentioned Cameradar could attempt to crack username/passwords—this is true, but it does not come with an extensive dictionary or username/password combinations to try. Maybe 12 dozen at most.

Still that might have been enough to gain access here, except for one key detail that I’m aware of:

This NVR is not using default credentials.

For my pen-test this is a roadblock, but for the security of my family’s network, this is excellent. One of the most commonly overlooked vulnerabilities when laymen set up their home networks is a failure to change default credentials. Here my family has been smart enough to change their credentials away from easily guessable defaults.

I may still be able to break into this stream with a good script for a dictionary attack, but for the moment at least my efforts are thwarted.

Next time I come back to this project, I’ll research a few more ways to try and exploit the stream, and then turn my attention to the other unsecured devices on the network—even if they aren’t something I can leverage to compromise the vulnerability of the whole network, I can at least harden them specifically against attack.

//

In the news.

Something I want to discuss from earlier in the week, is the debates surrounding ICE reporting apps. Apple and Google have come under some degree of fire for complying with government requests to remove apps like ICEBlock, an app for alerting other users of local sightings of ICE employees and operations.
The governments argument is that apps dedicated to that purpose have the potential to promote violence against federal employees and facilitate attacks against them. There may be some truth to that, but some are questioning if this is an exaggeration or double-standard..
After all, other apps (including Google’s own Google Maps) include the ability to report LE speed traps and so forth.

Should those apps also be taken down, or have those features removed? Or is it ethically legal and acceptable to alert other people to the presence of LE officials.

Now there can be no doubt that Apple and Google have every right to remove content from their store fronts if they deem it potentially hazardous or problematic in any way. Even if they apply a double standard to their content, I think that’s there right.
Still, I feel like this story brings up some downstream questions. What will happen if the next time an administration demands Google and Apple to take down an app, they refuse?