Interesting Shodan searches: PIP technologies ANPR cameras

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

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.

Interesting Shodan searches: Dedicated Micros DVRs

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 -usernameScreen Shot 2015-05-16 at 10.47.45 Screen Shot 2015-05-16 at 10.47.31

Yeah. Let’s look at the manuals.
Screen Shot 2015-05-16 at 16.28.54

So that’s no username or password by default.

Screen Shot 2015-05-16 at 16.30.23

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.

Interesting Shodan searches: Moxa ethernet->serial bridges

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.

Screen Shot 2015-04-30 at 18.45.50

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

Screen Shot 2015-04-30 at 18.47.31

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.

Why Nationwide’s SSL is broken on one of their domains

This is just here to explain clearly to Nationwide what is wrong with their SSL on the domain olb2.nationet.com

If you visit this site in Firefox 37.0.2, you are shown this warning:

Screen Shot 2015-04-27 at 16.26.39

The SSL handshake is failing. Firefox isn’t very descriptive here (should they be?).

The reason the SSL handshake is failing is because Nationwide’s server does not support a cipher which Firefox calls secure. Mozilla pulled support for a number of known insecure or weak ciphers last year, one of which is TLS_RSA_WITH_RC4_128_MD5. However, this is the most secure cipher the olb2.nationet.com site supports.

Qualys’ SSL Labs shows that the security here is poor, with the vast majority of properly configured, modern browsers failing to handshake with the server:

Screen Shot 2015-04-27 at 16.31.05

In addition to this, there are other issues that mean that they get a grade F – not good enough for a bank.

The issue here is not an out-of-date browser. It is an out-of-date server.

 

 

 

Interesting Shodan searches: Loxone Miniserver

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:

Screen Shot 2015-04-27 at 10.28.07

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.

Security review of new Anonabox

I recently received a new Anonabox – one with WiFi security – and have performed a very quick analysis of the security.

In summary, it’s nowhere near as bad as the first revision, but there are still so many mistakes and odd aspects to the configuration that I cannot possibly recommend anyone uses it.

Positive – all traffic is routed over Tor with no DNS leaks

Setting up Wireshark on the WAN side of the device shows that all traffic ends up on Tor. If the traffic cannot be routed over Tor, it is blocked.

This means the device is performing the key part of the advertised functionality (even if, personally, I feel that Tor is not a good solution for the man on the street).

Positive – the WiFi is secured

The device has a 24 character long WiFi password and uses WPA2.

This means that the WiFi side of the device is now secure.

In reality, this is an excessively lengthy password, and not allowing it to be changed is a serious negative. Lose the bit of paper they give you with the password, and it is game over.

Positive – the root account no longer has a default password of admin

Looking at /etc/shadow, they have removed a password from the root account:

This is better.

Negative – running an open web config interface on WLAN with no password

For whatever reason, only on the WLAN side (i.e. not LAN), you can connect to the OpenWRT web config interface using the IPv6 link local address.

Because the root password has been removed from the device, this means that the web interface now has no password whatsoever.

This means that anyone who uses the WiFi can reconfigure the device.

Negative – running ssh server on a random port (but no way of logging in)

On the WLAN side, again on the IPv6 link local address, dropbear (a small SSH sever) is running on a random port.

They have turned off password authentication, so only public key authentication could be used. There are no keys stored on the device, so there is no way to login.

Why then are they still running dropbear? Don’t run services you don’t need. A vuln in dropbear could be exploited.

Negative – serial console access gives a root console

There are three pins on the board that allow you to access a root console with no password.

A lot of embedded systems do this, but for a truly secure system, this should be entirely disabled, made output only, or at least secured with a password. I regularly see all three methods used on production boards. An end user is never going to use the serial console.

This also doesn’t align with the spin Anonabox are putting out – if you leave the device unattended you can no longer trust it.

Negative – use of public IP range for private network

There are reserved addresses for use behind NAT to avoid routing issues.

For whatever reason, Anonabox instead uses 126.0.1.0/24 and 126.0.2.0/24. This is a range used by Softbank.

This causes a number of issues – if you port scan your gateway, you in fact port scan a Softbank machine. If you want to access one of Softbank’s machines, who knows what will happen with the routing (because, as and end user, you cannot inspect the routing and firewalling).

Negative – no way of an end user to confirm Tor is in use

Most Tor routers and Tor software has a UI allowing a user to confirm that traffic is, in fact, going over Tor.

You have no way of telling if the Anonabox is working short of inspecting traffic. This isn’t good.

Negative – no means to change settings or update firmware

This is probably one of the biggest issues. If we ignore the open web interface mentioned above, you cannot change anything on the device without using a serial console. If you ignore the serial console (because most people won’t have the facility to use this), then you cannot change anything on the device.

  • Mistake in configuration e.g. firewalling – you are out of luck.
  • Serious vulnerability – no way of updating the firmware.
  • Lose your WiFi password – no way of finding it out.
  • Give your WiFi password to someone you no longer trust – no way of revoking access.

This is not a good thing even if they spin it as a plus. A competitor, Invizbox, have already put out two firmware updates in response to feedback.

Negative – strange, non-standard MAC address on WAN port

The MAC addresses of all the devices I have seen begin OC:EF:AF.

This doesn’t seem to be registered with the IEEE, making it a strange choice.

Beyond this though, plug this device into a corporate network, hotel, or anywhere else, and the network admins will instantly be able to tell you are using an Anonabox.

On a device that is being pitched as so secure, it should allow the MAC to be changed or even randomised each time it is plugged in.

Negative – openwrt leaks NTP requests so you can identify a router is connected

Again, for a privacy/anonymity device, you often want to hide the fact you are using it from your carrier. When the box is plugged in, it performs the default action of connecting to an openwrt NTP server. It’s obvious openwrt is in use – this should be blocked.

Negative – the config is all over the place

The whole thing is an openwrt router with some minor config changes. The changes that have been made seem amateurish and inconsistent. They are clearly not experts at this.

Conclusion

It kind of does what it should do, but does so many bits so badly that there is no way I would trust or recommend it.

It’s a given that manufacturers will make mistakes.

Anonabox have made mistakes.

One of those mistakes is making it impossible to fix the mistakes they have made.