Written by Jan Otte, Wednesday 17 October 2018

This article main topic is about v2 factory settings and default use case, also discussing a few LAN attacks on high-level.

When you get a cellular router from Advantech CZ, the default settings fall into one of the three cases:

1. Router is pre-configured exactly to your needs.
2. V2 router - with default v2 router generation configuration.
3. V3 router - with default v3 generation configuration.

As for the first possibility - router pre-configured exactly to your needs: as described in the first article, there are several ways how to get there. The configuration can be done in the factory (usually done for bigger quantities or for OEM routers or connected with some costs) or in other various ways - your own UM, configuration update, script or a tool - refer to the first article.

Now we are getting to the topic of the default configuration. You may ask why there is a difference between the v2 and v3 line. Part of the answer is obvious - there are some features in v3 routers that are missing in v2 routers. However, that is only the simple part.

We should return to the services (fragment of the table shown in the first article):

As you can see, there are differences between the v2 and v3. In general it could be said that the v2 has by default some non-encrypted services enabled. Why is that so?

We need to have a look at the default use case for the router to understand that.

The v2 routers were introduced quite some time ago. They are fulfilling a number of roles and are used in a number of use cases. However, there are some common attributes in the most common used cases:

1. The router is installed for communication from LAN to WAN, where WAN is cellular operator's network.
2. The devices on the LA' side are in controlled environment.
3. The primary purpose of the router is to allow data transfer from the devices on LAN side to somewhere else.

Actually, the LAN side here does not need to be Ethernet. It could be devices connected over RS232 or RS485 (serial lines) or something different. The mentioned data transfer was usually not simply transferring IP packets between the device (LAN side) and SCADA server (VPN tunnel over WAN side to an endpoint in SCADA's local LAN). The usual case is that the router acts as an active point in the communication - it translates protocols, aggregates data (stores, retransmits etc.) and usually does not expose the LAN devices or their communication to the outside world as they are.

Also, the communication between the device and the router was usually done over non-encrypted channel. That is understandable on a serial line and on a private (physical) location where all the communication endpoints are installed and controlled by the deployer (system engineer who deploys and configures the whole system).

As long as all the devices are completely controlled by the deployer, the scenario can work even on Ethernet. This scenario is usually called Sealed LAN or Trusted network. Which means that the LAN environment is sealed - there are no trespassers. There is nobody traveling with a notebook connecting to a WiFi that is linked with LAN. If that would happen, the LAN could be no longer considered a sealed LAN.

In this environment, the unencrypted connections are tolerated. Actually, many of the ancient equipment can talk only over the unencrypted channels. The important thing is, however, that the user must be aware on her actions. If she uses the router in a different scenario, she must change the default settings! If the LAN is not sealed and she did not change the settings and uses HTTP to log in to the router (from the LAN side)... it could be dangerous as there could be someone in the middle.

Actually... man in the middle (in well configured LAN networks) is not much probable.

Why not? What about the famous man-in-the-middle attack I hear you asking.

Now a little secret - it is a tad bit more complicated. (I know, you read this one a little bit often here and - you are going to keep reading it as here we are not pulling your leg).

While we will revisit the man-in-the-middle attack in more details in one of the later articles, we just focus on the most important thing now - to get the man-in-the-middle attack successful you need to become the man in the middle in the first place.

In the Internet world (a connection LAN-to-Internet), it could be a quite frequent scenario.

Not in the pure LAN though.

Why? There are a few possibilities for the attacker. While we do not have the place to go thoroughly through all the variants and peculiarities, let's visit the most common (on LAN):

• ARP cache poisoning
  • This attack tries to manipulate ARP cache of a victim. In short, on local segment of Ethernet network, destination is represented by MAC address. ARP cache is used to remember neighboring machines so your machine (and the switches along the way) know where to send the packets. If a machine is allowed (by network equipment) to push its MAC address to a victim's ARP cache and replace, e.g. a router's IP address entry (poison the ARP cache), it could become the man-in-the-middle (if it then sends either the original or adjusted packets to the intended destination - the router).
  • Well designed and well implemented corporate network using the right network elements can detect, alert and block this attack. Also, given there are no trespassers, it would need a fixed machine configured to initiate this kind of attack. In a good network, it would usually not take long for admins to start noticing the alarms from the network equipment. The fact the network does not need to count with trespassers makes the configuration to withstand this type of attack much simpler.
• Promiscuous mode (a machine listens to all traffic)
  • Any network interface can enter so-called promiscuous mode which means that it's network stack want to get all packets for processing, not just the packets destined for that interface. This way allows also seeing the packets not destined for the device and thus possibly intercept passwords for some services. The promiscuous mode itself is (in a simple LAN scenario without other elements) not enough to qualify as a man-in-the-middle type of attack however it can lead to such attack in more complicated (LAN to Internet) scenarios. As an example, listening to DNS requests may be enough to start substituting fake DNS replies and thus this attack can upgrade to a real man-in-the-middle scenario.
  • The right configuration (applied from the network design) with decent network equipment can safely narrow the surface for this type of attack - effectively to 0 in controlled networks. To give you a hunch - what good is for a network interface to enter promiscuous mode if the nearest switch does not send all packets to all ports?

So to sum up - if you have the right network design, equipment and configuration, your packets are traveling just between you and the destination. Unless some of the network elements is mis-configured or compromised or unless the network cease to be sealed, the man-in-the-middle attack does not happen. Consecutively, the right network can be secure even for the unencrypted communication.

But you should note that all the elements must be in place. One element missing opens up a hole for attacker. But here comes another factor of the most used v2 scenario - where is the attacker coming from? A wired network in a locked building with no access simply does not give any access point.

The most important thing to remember from the above is that the v2 routers are pre-configured for a sealed LAN scenarios. If your scenario does not fall in this category, you should change the configuration.

How? For example to match the v3 default configuration (regarding the login services).

As the matter of fact, the upcoming Conel OS 6.2.0 is going to change the v2 defaults. As a result of a several inquiries and repeated need to explain the situation, we have decided to close the unencrypted login services on v2 by default and thus unite the v2 and v3 default configuration a bit.

Nevertheless, the point of these articles is to increase the security awareness of the reader so while this article was about soon-non-existing default configuration differences of v2 routers, I hope it got you thinking about what  you have read.

Next time we are going to continue with configuring router access ways including passwordless login and also touch the sensitive SNMP topic.