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

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 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 to – 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 ( 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 and 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.


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.

Missing TLS ciphers when running Burp Suite

I’ve just started testing a new product. The traffic was redirected to the transparent Burp Proxy by altering the DNS response, but the traffic wasn’t showing up in the HTTP history.

It was then I saw the “Alerts” tab was orange, and this message was showing:

The client failed to negotiate an SSL connection to no cipher suites in common

This is an embedded device – they often have a much more limited set of ciphers supported. Unfortunately Burp gave no hint of which suite was being request.

Crack open Wireshark, and we see

Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA

And indeed, this wasn’t listed on the SSL ciphers in Burp.

Turns out this cipher is controlled by export restrictions and not distributed with the normal JRE.

To resolve this, firstly, make sure you have Oracle JRE installed. Follow the instructions I have posted before. 8 seems to be the best version – 9 still causes a lot of quirks. OpenJDK just doesn’t cut it with Burp unfortunately.

The google for “JCE 8″ (or whichever version you have). You will get to a download for the Java Cryptography Extensions:

Download the zip, and unzip it to:


Replace the 8 with your version. It will overwrite two files, back them up if you think you need to.

Restart Burp and you should now be able to intercept traffic.

Re-use of SSH keys across thousands of devices

John Matherly, of Shodan fame, posted a blog to /r/netsec (comments are relatively interesting) last week showing how he had used the Shodan Python API combined with “facets” to find the most common SSH fingerprints.

I’m a heavy user of Shodan, but largely via the web front-end. I thought I’d take this as an opportunity to get the API working. It’s very easy. All instructions are under Ubuntu 14.04, but will likely work for any Ubuntu like distro.

First make sure you have easy_install which is part of setuptools – you will likely have this already if you have built anything big in Python:

Next, install the Shodan API itself:

Simple – we should be done now.

You need to sign up to Shodan and get an API key. If you use Shodan regularly, I would suggest getting a paid-for plan (it’s very good value), but a free account will have access to the API, albeit with limitations.

Let’s test it with a simple search first:

This should throw a huge list of results back for any hosts in the UK (country code GB which I always forget) with port 22 open:

Now this is interesting and useful, but Shodan has a very neat bit of functionality called “facets”. The simplest way of explaining these is that it allows me to group the results and show you the top by count.

For example, we could find the top ports open across the UK:

Which gives us the following results:

As expected, we have the common ports of 80 (http), 443 (https), 22 (ssh), 25 (SMTP), 8080 (http or http proxy), and 21 (telnet). What’s the top port 7547 though?

This is TR-069 or CWMP (CPE WAN management protocol), a http based protocol that allows the remote management of customer premises equipment i.e. lets your ISP remotely control your router. It’s open on a worryingly large number of routers and suffers from a number of vulnerabilities, most notably the “Misfortune Cookie“.

Anyway, facets also let us group by more esoteric fields, such as the SSH fingerprint presented each time you try to connect via SSH. This is the focus of John’s blog post.

I’ve restricted this to the UK – I know the lay of the land better, and dealing with any issues found is a little easier both from a communication and legal standpoint.

The results are as follows:

Those top three are very, very common! How has this happened?

Let’s plug the top one back into Shodan via the web front-end:

Shodan results

What can we tell from those organisations and hostnames? These are all devices on consumer broadband connections. Routers, NAS, other devices with SSH open.

So what is the issue here? Why are these duplicate SSH fingerprints an issue?

The SSH fingerprint is a hash of the public key used by the router for SSH communication. It provides a human-readable way of checking that you are connecting to the host you are expecting to connect to. If it has a different public key, you should nearly always get a different fingerprint.

SSH keys should be unique per device. The first time they boot, they should use a source of entropy to generate unique keys. The reason so many devices have the same keys is that the keys are stored in firmware and are not changed.

Having the same fingerprint means it is no longer possible for you to authenticate the device you are connecting to. Is it your router, or another person with the same router? Who knows!

It also, worryingly, means that there is a private key that could be used to impersonate and possibly even access these devices. This key may be stored in the firmware of these devices and recovered. This has happened in the real-world.

It is worthwhile noting, that even with the public/private keypair, you still need to MITM a SSH conversation to be able to decrypt it. SSH uses Diffie-Hellmann key exchange to ensure Perfect Forward Secrecy. The session keys are forgotten and the conversation can never be decrypted.

But above all, the biggest question is why is SSH open on so many broadband connections? Routers shouldn’t have SSH open like this. If they are NAS or similar behind the router and using UPnP to forward ports, why are routers still allowing this? If SSH is open by default, it would suggest that there is at least one account that can login by default. If the SSH keys are the same across all devices, how are we to know that the login credentials differ from device to device?

Quick and easy fake WiFi access point in Kali

I’m working on a project at the moment that requires me to observe traffic from an iOS/Android app to various external IPs.

The easiest way to do this is to setup a fake WiFi access point and use Wireshark to sniff the traffic. This is very easy in Kali Linux.

1. Connect the Kali box to the Internet

On my machine, this is as simple as connecting to my WiFi network “DoingAJob5G” using the built-in wireless card on my x220. I use the GUI provided with Kali.

Using ifconfig I can see that this adapter is called wlan0.

You could use wired Ethernet, then in all likelihood this will be eth0 instead.

2. Connect an external WiFi adapter that is supported by hostapd

I’m using a USB TP-LINK TL-WN722N which is using an Atheros AR9271 chipset. These are cheap (£8-£10), powerful and reliable.

I suspect many USB WiFi adapters are compatible with hostapd, unfortunately I can’t see a clear source documenting which ones.

Check it works by connecting to any network using Kali’s GUI. This will save you hassle later if there are any driver or hardware issues.

3. Bring up the new wireless interface.

Use ifconfig -a to see the new wireless interface name:

Bring this up as the gateway for your new wireless network. I am using simply to avoid any chance of confusion with my internal NATed network.

4. Configure and run DHCP and DNS services

DHCP assigns IP addresses when clients connect, and DNS provides resolution of names to IPs.

Most wireless clients expect DHCP by default, so it is convenient to run a DHCP server. You can manually set IP addresses, but it’s really easier to do DHCP.

Running our own DNS server means that we can easily intercept and alter DNS queries, which can assist in setting up man-in-the-middle attacks.

A piece of software called dnsmasq does both DHCP and DNS and is very simple to setup.

First, install dnsmasq:

Next, create a config file dnsmasq.conf as follows:

This is about as simple as it gets. Only listen on wlan3, our additional wireless adapter. Hand out DHCP addresses from DHCP option 3 is the gateway, DHCP option 6 is the DNS server – both of these should be set to our wlan3 IP of server specifies upstream DNS servers that will handle most DNS queries – I have provided Google’s DNS server of Finally, log DNS queries and DHCP requests – this just makes it easier to check everything is working.

We also want to create a file fakehosts.conf to allow us to spoof certain DNS requests:

This will cause the dnsmasq DNS server to respond with to any request for

We then need to bring dnsmasq up. I want it to run with output to stderr, so this is done as follows:

5. Configure and run hostapd

Next, we need to get our wireless adapter to run as a access point.

hostapd allows us to do this.

Install hostapd:

Create a config file hostapd.conf:

Again – really simple. Use our additional wireless adapter wlan3 with the nl80211 drivers (which seem to cover pretty much all modern adapters than can be APs), set the SSID to Kali-MITM and set the channel to 1. There is no encryption etc. but I really don’t need or want it for sniffing traffic.

Then start hostapd:

6. Setup routing for the access point

You want a very simple setup at the moment – act as a basic NAT gateway between wlan3 and wlan0.

Without going into any detail, the following commands will set this up:

At this stage, you should now be able to connect to Kali-MITM, get an IP address, and start using the Internet.