Again, browsing telnet, I see the word “ANPR” – Automatic Number Plate Recognition.

Most of these say “P372” and a Shodan search for that delivers the goods. The telnet prompt shows us P372, but nearly all of these also have HTTP open as well.

It’s safe to say a lot of these don’t have any authentication on telnet or HTTP.

Their default mechanism to report plates is by FTPing the data to a central server. The FTP server IP and credentials can be viewed through the configuration interface. The manual recommends that this FTP acount has read and write permissions using MS FTP, so once you have these credentials, it is likely you can tamper or upload fake records – and not just for this single camera, but likely any in the network. The manual also uses the example “ftp_boot” for both user and pass, and it seems a lot of people have taken this literally.

Credentials blanked by me

These ANPR cameras are used by local authorities and governments.

Pff.

Who is to blame here?

I think the mnaufacturer should make the system impossible to configure this badly, and provide a default configuration and documentation that prevents this kind of stuff.

But whoever installed these also needs to bear some responsibility. If I get a boiler fitted, I expect the installer to know what each pipe and wire does, and not just hide the ones he doesn’t understand…

It looks like Darius Freamon has already found this.

This one was found just browing “port:23 country:GB” results.

It appears that SD Advanced DVRs don’t always require a username and password to get into them  – “SD Advanced Closed IPTV -username“

Yeah. Let’s look at the manuals.

So that’s no username or password by default.

And an ini file with credentials of other devices. Great!

At least the manual doesn’t explicitly recommend you setup portfowarding as well…

It seems it’s not just this line made by Dedicated Micros – Ecosense does it as well. In fact, it’s pretty much every one they seem to make. 459 open DVRs in the UK alone.

I sometime search for “diagnostics” on Shodan – it gives interesting results. I noticed one telnet result with a menu system – a router. If we make the search more specific to that menu system “Easy Setup port:23“,  we get just over 200 routers running open telnet:

Not good.

I’ve noticed, whilst sat on the train, an AP called “MOXA”. A quick google shows that these guys are in the “industrial IoT” market. I suspect they have something to do with the CCTV on the train.

Off to Shodan for a search, limited to port 80.

~90 devices come back, nearly all MiiNePort E2. Very few have authentication turned on, many that do are using default credentials.

A quick glance through the user guide shows that there is a disturbingly easy to trigger reset process:

Also, there appears to be a utility called NPort which is used for discovering devices. It wouldn’t be the first time that a discovery protocol has been the downfall of one of these bridges.

About 360 devices are showing up for a search for “Envisalink“.

Turns out this is the IP interface for a large number of alarms across the US. No auth or user/user. No HTTPS.

A search for “Prismview Player” on Shodan yields ~200 results for what look like electronic billboards.

Again, no HTTPS. Their site suggests you use a Windows client to update the billboard itself, and the username/password is optional…

I’m going to start a new series of posts, highlighting interesting Shodan searches I have seen in the last few weeks. Then maybe myself, or someone else, can take a better look at the devices and see if they can spot any problems.

Note that some of the search queries may require you to have an account on Shodan.

Loxone Miniserver

The simple search term for Loxone brings back a lot of results:

What can we see?

1. These are all HTTP, FTP, telnet. Not HTTPS, SFTP/FTPS, or SSH. There is no excuse for running the non-secure versions of these protocols today.
2. There is a lot of port-forwarding here, opening up access to these boxes.
3. The spread of version numbers is wide, from 5.49.3.4 to 6.3.3.19 – likely that there is no automatic firmware update mechanism.
4. The “Server” header of “Loxone” is not one of the commonly available HTTP daemons. Rolling your own HTTP server generally means bugs galore.

You can download their software “Loxone Config” from their site. A very cursory glance over it shows the following:

• No use of HTTPS anywhere.
• There is a config facility which sends to broadcast on the local network – port 7070 – which isn’t authenticated or filtered in anyway.
• They run a “cloud” service, part of which maps the MAC address of the device to an IP address, allowing enumeration of valid MACs (dns.loxonecloud.com/504F94000000 for example).
• The firmware is distributed with the software, including what looks like the web pages for the interface.
• The software opens up a number of ports in the 7xxx range on the local machine

It’s worth having a dig around anyway.