2015-03-31: Insecure Configuration of SCADA Equipment in AGA CNG Filling Stations
2014-12-03: Multiple Vulnerabilities in Kabona SCADA Devices
2014-11-29: Multiple Vulnerabilities in Telenor Group Consumer CPE Router
2013-09-25: UPnP-sårbarheter i Net1:s M-90 modem

2015-03-31: Insecure Configuration of SCADA Equipment in AGA CNG Filling Stations

AGA Gas AB operates a number of filling stations around Sweden for biogas powered vehicles. The dispensers ("pumps") for compressed natural gas (CNG) at these stations are NPS brand, model STD11.

CNG dispensers are typically more complicated than ordinary petrol pumps, since they are working with a high-pressure medium, and have to be able to compensate for widely changing ambient temperature, detect leaks, and so on. This is necessary both for safe operation and to charge the customer correctly.

The STD11 dispenser is constructed around a Siemens Simatic S7-1200 programmable logic controller (PLC), which uses input data from temperature, pressure and mass-flow sensors to control the various gas valves. The dispenser also interfaces to a number of different Point-of-Sale systems, so that the customer can be correctly charged.

As of mid-March 2015, it appears that all AGA-operated STD11 dispensers have their Simatic PLC units connected to the Internet, exposing various services.

1) Exposed Configuration Web Interface

The PLC units expose their standard Simatic web interface to the Internet. If you don't log in with an administrative password, this is a read-only view, but it still exposes detailed internal information, like hardware configuration, internal network configuration, diagnostic logs, software versions, etc, which generally should not be published.

2) Exposed S7Comm Interface

Approximately half of the dispenser PLCs also expose an S7Comm interface on TCP port 102. S7Comm is a proprietary Siemens protocol for communication with Simatic CPUs, that most definitely should not be allowed on the Internet. This is a high-risk misconfiguration.

3) Client-side Authentication in Javascript

The PLCs also contain a "user application" called "CNG Dispenser". This is a subsection of the PLC's web interface which run a custom web application, presumably to serve business needs.

The application is password protected; the user is first directed to a login page which prompts the user for a username and a password.

However, if we look at the HTML source code for the login page, we find this Javascript snippet:

function check(form)/*function to check userid & password*/
   /*the following code checkes whether the entered userid and password are matching*/
   if(form.userid.value == "aga" && form.pswrd.value == "1234")
    {'index2.html')/*opens the target page while Id & password matches*/
     alert("Error Password or Username")/*displays error message*/

We see that the username ("aga") and password ("1234") are hard-coded into the HTML source code, and if these are entered correctly, the user is redirected to the "protected" page index2.html, apparently without any further authentication taking place.

Actually visiting the page index2.html without proper authorization is probably illegal under Swedish legislation. Thus we can not investigate this further. However, AGA representatives claim that index2.html does not reveal sensitive information or allow destructive actions to be performed.

Update: After extended attempts to notify AGA AB about these shortcomings, contact was finally established via AGA's parent company Linde Group on 2015-03-18. As of 2015-03-20 the STD11 dispensers are no longer reachable from the Internet.

2014-12-03: Multiple Vulnerabilities in Kabona SCADA Devices

A number of vulnerabilities have been uncovered in various Kabona building control systems. Hundreds of these devices are exposed on the Internet, making it possible to cause widespread physical damage to critical infrastructure.

We urge all users of Kabona systems to immediately detach them from the network.

The disclosure of the vulnerabilities will take place in two steps. On November 3, 2014, the public will be informed that there are severe vulnerabilites in these devices, but without any technical details given. On December 3, 2014, the full details will be released.


Kabona has a range of products for building control, all built around the Kabona WDC device, which is an embedded PC platform running Linux. Typically, the WDC is connected directly to the Internet, and communicates with internal building systems, like climate control, access control systems, fire alarms and lighting, over Modbus or Mbus.

The main selling point of Kabona systems is that service technicians can access and adjust control parameters remotely, without having to physically go to the building. For e.g. property owners with multiple geographically distributed buildings, this is an obvious feature.

However, there are severe problems with Kabona's software implementation.

1) Lack of encryption

We have been unable to find a single WDC where the web interface is protected by encryption - all information, including passwords, is transferred in cleartext.

2) Insufficient authentication

The WDC has an interesting authentication system. Upon connecting to the web interface, the user is asked for a username and password, plus a requested access level. On the surface, this looks pretty normal, but actually the username is only used for logging purposes. It is not verified in any way, and is not used for authentication. Instead, the WDC has a number of passwords defined, with each permitting a specific access level.

Additionally, the WDC may have a "guest login" feature active, which allows a visitor to get read-only access to the web interface by entering an arbitrary username and password, and selecting "Guest" as the requested access level.

Depending on firmware version, a WDC can manage session state in two different ways, both flawed.

2.1) Predictable session cookies

In older firmware versions, all session state information is recorded in two cookies, wdcuser and wdclevel. The wdcuser cookie simply records the username entered in the login form, while wdclevel specifies the granted access level. For instance, a visitor who logs in with guest access and enters "foobar" as username, will get the two cookies wdcuser=foobar and wdclevel=guest.

But since cookies are stored client-side and are easy to manipulate, this means an attacker can simply set two cookies - wdcuser=arbitrary, wdclevel=system - and get immediate system level access to a WDC running an affected firmware version. This gives the ability to operate any building system equipment that is connected to the WDC, and also gives full administrative access to the WDC itself, which allows the attacker to e.g. lock out all legitimate users from the system by changing all web interface passwords.

2.2) Predictable session cookies II

In newer firmware versions, the cookie handling has changed slightly; the wdclevel cookie has been replaced by a cookie called wdccred, which contains a hash of the granted access level. (Specifically, it's hashed with the classic Unix DES-crypt hash, which is very weak.)

We can only speculate why this change was introduced, but a reasonable guess is that it was an attempt to fix vulnerability 2.1. However, the change does exactly nothing to improve the situation - instead of setting the cookie wdclevel=system, the attacker can simply set wdccred=0EKmVdxgF3GAY instead ("0EKmVdxgF3GAY" being the crypt:ed version of the string "system". It should be noted that any value can be used for the salt.).

As far as we can determine, every WDC reachable on the Internet suffers from either vulnerability 2.1 or 2.2.

3) Cleartext passwords

The WDC stores web interface passwords in cleartext and displays all defined passwords on the login configuration page. This is bad security practice.

As a side comment, the passwords on the devices we have been allowed to examine have been of significantly low quality. Also, since there are no personal accounts in the system, it is in practice almost impossible to keep track of exactly which individuals have access to the system.

4) Lack of CSRF protection

The WDC web interface lacks CSRF protection. This means that even if vulnerabilities 2.1 and 2.2 are fixed, the web interface can be remote controlled by malicious javascript on any web page.

5) Bad network configuration

The exact set of open ports varies between WDC installations, but a portscan of a typical WDC can look like this:

  7/udp  open  echo
  13/udp open  daytime
  37/udp open  time

  7/tcp   open  echo
  13/tcp  open  daytime
  22/tcp  open  ssh
  23/tcp  open  telnet
  37/tcp  open  time
  80/tcp  open  http
  502/tcp open  modbus

It is remarkable that this WDC runs the legacy services on ports 7, 13 and 37 - especially the UDP versions of them, which can be abused for dDOS attacks.

Of special interest is port 502, which is used for Modbus/TCP. The process listening on this port appears to be a proprietary implementation of a Modbus controller. It is hard to understand why this is exposed to the Internet.

6) Bad web server configuration

The Boa web server used by the WDC is configured with

  ScriptAlias /cgi-bin/ /usr/local/bin/

This means that any binary in /usr/local/bin can be launched by a remote attacker, as can be illustrated by visiting the URL

http://[WDC IP]/cgi-bin/wget

which results in a web page containing the error message

  Try `wget --help' for more options.

We have not investigated to which extent this can be used for malicious purposes, but this configuration is most certainly not a good idea.

7) OS level accounts with unchangable passwords

The passwords used by the web interface have no relation to the user accounts defined in the underlying operating system. The passwords for the OS level user accounts can not be modified through the web interface.

In all WDC:s we have examined there is a non-privileged account "cdw", with the password "2lkopp", and the root account has the password "kabonIT". Since most or all WDC:s are reachable on telnet or ssh, this means an attacker can simply login to them using these apparently static passwords and gain root privileges.

It should also be noted that it is a mistake to use traditional Unix DES-crypt to hash the passwords in /etc/shadow.

2014-11-29: Multiple Vulnerabilities in Telenor Group Consumer CPE Routers

A number of vulnerabilities have been uncovered in various routers issued by Internet service providers in the Telenor group to consumer end users in Sweden.

The disclosure of the vulnerabilities will take place in two steps. On October 29, 2014, the public will be informed that there are severe vulnerabilites in these routers, but without any technical details given. On November 29, 2014, the full details will be released.

1) ZyXEL P-2601HN-F1, firmware level 3.00(BLR.5)

This router is issued by Bredbandsbolaget and Glocalnet. The vulnerabilities below have been confirmed in Bredbandsbolaget routers; we suspect that they also are present in Glocalnet routers, but this has not been verified.

1.1) Administrative interfaces exposed to Internet

We have found approximately 16000 of these routers in Sweden with administrative interfaces on ports 23, 80 and 7676 exposed on the external WAN interface and reachable from the general Internet.

Approximately half of these are located on the Telenor network AS2119, with about 7500 having IP addresses resolving to host names and the rest resolving to host names.

The other half of the routers are located on Skanova network AS3301. Since Skanova resells network capacity to multiple operators, we can't trace these routers to specific Internet service providers. However, since the AS3301 routers run the same software version as the ones in AS2119, we assume that most or all of them actually belong to Bredbandsbolaget or Glocalnet.

Having administrative interfaces exposed to the general Internet is bad practice. We assume that this is a misconfiguration issue, rather than an intentional policy. The affected IP addresses are available on request.

(It should be noted that actually logging in on the port 23 and 80 interfaces only seems to be possible from a specific hardcoded network range.)

1.2) Remote root vulnerability

This router runs a remote management service (CWMP, also known as TR069) on port 7676 on the external WAN interface. The router software component that provides this service is ZyXEL RomPager, version 4.34. This version of RomPager has a remote root vulnerability, publicly disclosed in April 2013). We have verified that the vulnerability is indeed present on Bredbandsbolaget routers.

Together with the misconfiguration issue describe in section 1.1, this means that between 8000 and 16000 Telenor group routers are remotely root exploitable from anywhere on the Internet.

1.3) Local root vulnerability

A command injection vulnerability in the dyDns.cgi page in the router's web interface lets any authenticated user run OS commands as root.

Specifically, the value passed in the "sysDNSHost" parameter is inserted verbatim into a shell command line executed as root, making it trivial to inject OS commands.

Since the routers are locked down by the service provider, end users are not supposed to have root access to them.

1.4) Static default passwords

Rather than setting unique, random passwords for each router, all routers are shipped with the credentials "user:1234" for user level access to the router's web interface.

This is bad practice, and means that unless the end user has taken active action to change the default password, anybody with access to the local network can access the router's web interface and modify router settings. Since end users only have limited access privilege, only the most basic settings can be changed, like which DNS server to use.

However, note that because of the vulnerability in section 1.3, anybody with access to the web interface can actually get root level access to the router.

1.5) Weak administrative passwords

Apart from the "user" account previously mentioned, the router turns out to have three additional accounts; "root", "Kundservice" and "Kung". Since these are ordinary Linux level users, the hashes for these accounts are present in /etc/shadow.

While the "root" and "Kundservice" accounts appear to have passwords of decent quality (i.e. we have not yet been able to crack them), the "Kung" account turns out to have the password "5lot".

Using the "Kung" account, one can access privileged settings in the web interface, and it is also possible to access a CLI configuration interface via telnet.

It is quite remarkable that a hidden privileged account has an extremely weak, four-letter password.

1.6) CSRF vulnerabilities

The web interface lacks any form of protection against Cross-Site Request Forgery (CSRF) attacks.

This means that if a user visits a malicious remote web page, it is possible for javascript code from the malicious page, running in the user's browser, to construct and submit HTTP requests to the router's web interface and trigger configuration changes.

A typical CSRF attack relies on the victim user to already have an authenticated session against the target system, but since we in this case already know the default passwords for the "user" and "Kung" accounts, it is quite easy for an attacker to include an initial login step in the attack.

By using a CSRF attack it is possible to e.g. change the router's DNS settings to point at a malicious DNS server. This is a typical first step for e.g bank frauds. We have a trivial proof-of-concept attack that demonstrates this scenario.

By targeting the local root vulnerability in section 1.3 it is also possible to get remote root access to the router, download a pre-compiled tcpdump binary and snoop on all network traffic passing through the router. We have a proof-of-concept also for this scenario.

(It should be noted that the remote root access gained here is not dependent on vulnerabilities 1.1 and 1.2 - this is a wholly separate issue.)

1.7) Predictable session cookies

The session cookie sent to the browser upon successful authentication is predictable; it only contains the client's IP address. This means it is possible for an attacker to spoof a valid session cookie.

2) Zyxel P-2812HNU-F1, firmware level 3.10(TUL5)

This router is supplied by Bredbandsbolaget, and has many of the same problems as the 2601.

2.1) Local root vulnerability

Similar to 1.3, but in this case the vulnerable field is sysDomainName in the general.cgi page.

2.2) Static default passwords

Same as 1.4.

2.3) Weak administrative passwords

Same as 1.5, with the addition that this router also has a "supervisor" account with password "1234".

2.4) CSRF vulnerabilities

Same as 1.6.

3) Zyxel P-2602HWL-D1A, firmware level 3.80(BLP.6)

This router is supplied by Bredbandsbolaget.

3.1) Static default passwords

Same as 1.4.

3.2) Weak administrative passwords

Same as 1.5

3.3) CSRF vulnerabilities

While this router includes CSRF protection in the form of a dynamically changing CSRF token included in each page in the web interface, the implementation is flawed.

For the CSRF protection to be effective, the value of the CSRF token needs to be unpredictable. However, this router always generates the same sequence of CSRF tokens after reboot. (Our unverified hypothesis is that the CSRF tokens are generated by a pseudo-random number generator that is seeded with a static value at boot.)

Since the router's web interface is typically seldom used, the CSRF token value normally doesn't progress very far between reboots, and it is a simple matter of trial-and-error to find a valid CSRF token value.

2013-09-25: UPnP-sårbarheter i Net1:s M-90 modem

Net1 är en leverantör av trådlösa kommunikationstjänster som använder NMT 450-frekvensen. Tack vare systemets stora yttäckning fungerar tjänsterna ofta bättre än konkurrenternas 3G-system utanför tätorterna.

Net1 tillhandahåller ett antal olika modeller av modem för sina kunder. Minst en av dessa modeller, "MiFi M-90", har två allvarliga säkerhetshål som gör att angripare kan avlyssna och ta över användarens datatrafik.

Båda sårbarheterna berör modemets stöd för UPnP (Universal Plug and Play), som kortfattat är en standard för hur konsumentelektronikenheter ska kunna upptäcka varandra på det lokala nätverket och kommunicera med varandra. Till exempel kan en mediaspelare automatiskt upptäcka vilka lagringsenheter som finns på nätverket och öppna rätt portar i brandväggen för att kunna strömma video från Internet.

Det första problemet ("Sårbarhet 1") med MiFi M-90 är att modemet inte bara lyssnar efter UPnP-trafik på det lokala nätverket, utan även godtar UPnP-trafik som kommer från Internet. Det gör att en angripare var som helst i världen kan kringgå modemets brandvägg och komma åt enheter på det interna nätverket.

CERT, det nationella amerikanska IT-säkerhetsorganet, har utfärdat en särskild "Vulnerability Note" angående den här typen av säkerhetshål, där man kan hitta mer information.

Det andra problemet ("Sårbarhet 2") är allvarligare. Den version av UPnP-programvara som modemet använder är "Portable SDK for UPnP devices 1.3.1", som har multipla allvarliga säkerhetshål som gör att en angripare var som helst på Internet kan ta fullständig kontroll över modemet ("root-rättigheter") och till exempel avlyssna trafiken som passerar genom det och skicka användaren till illasinnade websidor.

(Det är värt att notera att liknande attacker faktiskt utförs i stor skala.)

CERT har utfärdat en Vulnerability Note även för denna typ av säkerhetshål.


Not 1: "MiFi M-90" är Net1s försäljningsnamn för Cellient MX200SWE CDMA-1xEVDO Mobile Hot Spot.

Not 2: Sårbarhet 1 och 2 berör M-90-modem med mjukvaruversion "01.06.54 Jun-19-2013 00:32:44".

Tidslinje för ärendet:

2013-07-16: Net1 får en detaljerad rapport om problemen.

2013-08-07: Net1 tillhandahåller en testversion av modemmjukvaran som visar sig lösa sårbarhet 2, men inte sårbarhet 1.

2013-08-20: Net1 tillhandahåller en ny testversion av modemmjukvaran där UPnP-funktionaliteten är helt onåbar, både från Internet och från det lokala nätverket.

2013-09-12: Net1 släpper en ny version av modemmjukvaran, "01.07.66 Sep-14-2013 05:14:56", återigen med UPnP-funktionaliteten helt onåbar, och uppmanar alla sina kunder via e-post att uppdatera sina modem, dock utan att nämna säkerhetsproblemen; se skärmavbildning nedan.

2013-09-25: Denna notis publiceras.