Cyberattacks on SATCOM Infrastructure: Part 1

Hesam Seyed Mousavi, June 12, 2022

Introduction

This blog post introduces our most recent whitepaper detailing original research into two SATCOM terminals manufactured by Addvalue Technologies, Ltd.: the Wideye iSavi and Wideye SABRE Ranger 5000.

Source: erproject

blog.mousavi.fr

We identified numerous serious security vulnerabilities in both devices, including broken or backdoored authentication mechanisms, rudimentary data parsing errors allowing for complete device compromise over the network, completely inadequate firmware security, and sensitive information disclosure, including the leaking of terminal GPS coordinates. These issues were present in all reviewed firmware versions, including the currently available release.

Research Goals

The primary goal of this research was to determine the security posture of these two SATCOM terminals, whose application spans multiple industries. By taking the results of this research in isolation, IOActive hopes to gain insight into the current state of security in the SATCOM industry. Additionally, by comparing the research results with the conclusions drawn from the research we conducted in 2014 and 2018, it is possible to assess how much progress toward improved security has been made in that time.

Furthermore, given the bleak outlook of the findings of this research, IOActive hopes that the publication of this information will increase awareness of these issues and make the necessity of immediate corrective action very clear.

Research Targets

Wideye iSavi Portable SATCOM Terminal

The Wideye iSavi is a portable satellite terminal operating over the Inmarsat iSatHub and BGAN services, offering voice, text, and Internet connectivity to devices connecting to the iSavi via a built-in WiFi access point. It is designed for general consumer use as per the Wideye documentation, allowing maintained connectivity for those outside the range of coverage of traditional ground-based Internet infrastructure. It may or may not be configured to be accessible over the broader Internet and can be managed remotely via a web interface or other means.

Wideye SABRE Ranger 5000

The Wideye SABRE Ranger 5000, built on technology similar to the iSavi, is a BGAN Machine-to-Machine (M2M) satellite terminal. It is designed to operate and stay connected to the Internet without interruption and is commonly configured for accessibility over the wider Internet, to allow for remote management. It is intended for industrial use, with the Wideye brochure [1] suggesting its use in the following industries:

Firmware Images

Despite the varied uses, investigation into the two devices indicated that very similar firmware runs on each. As such, all vulnerabilities identified during this research effect both the iSavi and the Ranger, with the impact varying somewhat for each vulnerability based on the use-case of each device.

Firmware versions analyzed during this research include:

iSavi

  • R01.0.0: The version which was pre-installed on the iSavi originally purchased for the research in 2019
  • R01.0.1 and R02.0.0: Firmware versions available for download from the vendor website [2] over the course of research beginning in 2019
  • R02.0.2: Current firmware version available for download from the vendor website as of the publication of this blog post

SABRE Ranger 5000

  • R01.0.0: The version which was pre-installed on the iSavi originally purchased for the research in 2019
  • R01.0.3: Current firmware version available for download from the vendor website as of the publication of this blog post

 

Cyberattacks on SATCOM Infrastructure: Understanding the Threat

Before elaborating on the vulnerabilities discovered during this research, it is important to understand what kind of threat is posed by any given attack, and how to think about that attack’s impact.

Attack Vectors

Since we will be looking at SATCOM terminals, it is important to understand the paths available to an attacker for potential device access. Figure 2 comes from the SABRE Ranger M2M (an older SABRE Ranger model) marketing brochure [3] and lays out the architecture of SATCOM terminal communication nicely. The layout for the iSavi differs slightly, in that its internal network is established over WiFi, but the diagram is still accurate at a high level.

External Network

Both the Ranger and the iSavi have the capability to be made accessible over the Internet, with or without a static IP address. This feature is more likely to be enabled on the Ranger, as its stated purpose includes remote access of resources to which it is connected.

Internal Network

Both the Ranger and the iSavi support some means of connecting the devices to a local IP network, which will then allow for routing of data between those devices and the Internet. For the iSavi, this is a WiFi access point. The Ranger includes two Ethernet ports which serve the same purpose.

Other Interfaces

While the iSavi’s functionality is limited to network connectivity, the Ranger also includes various physical interfaces for industrial equipment, including GPIO, analog, serial, and ModBus. While these interfaces could potentially be subject to vulnerabilities, exploitation via these interfaces would require physical access to the equipment, and as such are of lower impact than those attacks which can be performed remotely/semi-remotely. However, it is important to consider the impact that the compromise of this device might have on connected equipment; Figure 3 is from the Ranger 5000 brochure12 and provides an example of the kinds of equipment that would be under attacker control in such a scenario.

Attack Scenarios

The whitepaper lays out several plausible attack scenarios for the SABRE Ranger 5000 and the iSavi, taking into account the intended applications of each device and leveraging one or more of the vulnerabilities identified during this research. These scenarios include potential disruption of Emergency Services operations for the iSavi, and an undetected attack on critical Oil and Gas infrastructure for the SABRE Ranger 5000. In both cases, a reasonable case for a risk to human safety can be made.

 

Findings Overview

Finding Description Severity Impacts AT Shell Buffer Overflow A failure to properly handle data being sent to the device over the network results in the ability of an unauthenticated attacker to fully compromise the device over both internal and external networks. Critical A, C, I Web Admin AT Command Overflow A failure to properly handle data being sent to the device via the web management interface results in the ability of an authenticated attacker to fully compromise the device over both internal and external networks. High A, C, I Remote Web Administration Bypass Poorly designed access controls allow an attacker to access “remote management” features of a Ranger or iSavi device over the Internet, even when remote management has been disabled by the user. High A, C, I Hardcoded / Backdoored Web Credentials The web administration interface used by iSavi and Ranger devices contains several undocumented, hardcoded username/password pairs which can be used to access the management interface. One user, called root, has full privileges, and can make arbitrary changes to device configuration. High A, C, I Hardcoded / Backdoored Operating System Credentials The credentials for the operating system (VxWorks) command line interface exposed via Telnet are hardcoded and can be recovered via reverse engineering. Once these credentials are obtained, an attacker can access the operating system at the highest privilege level, executing arbitrary code over the network. High A, C, I Unauthenticated Firmware Updates No mechanism whatsoever is in place to verify that a firmware update being supplied to the device is coming from a trusted source. An attacker with the ability to upload new firmware (achievable via many of the identified vulnerabilities) can make malicious changes to the firmware image and run arbitrary code on the device. High A, C, I Services Bound on All Interfaces All network services, including those likely intended only for local network utilities or management, are listening on all interfaces, including those exposed to external networks, potentially including the wider Internet. Medium C, I AT Command Authentication Brute-Force The authentication mechanism used by the device’s AT server (which allows for some control over the device) has no protections against brute-forcing, allowing an attacker to attempt to brute-force the authentication until successful without hinderance. Medium
iSavi Records GPS Coordinates as Events The iSavi records GPS coordinates periodically and logs them for viewing via the web interface. As established, this web interfaced may be accessed remotely by a malicious party, revealing the location of the iSavi and its user. Medium C Weak Firmware Obfuscation Wideye use a trivially reversable form of obfuscation to deter analysis of firmware images. Medium C Remote Address Cross-site Scripting A web page returning an error when attempting remote management via the web interface is susceptible to cross-site scripting, allowing execution of arbitrary JavaScript when a crafted link is visited by a legitimate user. Medium
Debug Information Included in Firmware Images The firmware images provided by Wideye for the Ranger and iSavi devices include detailed debugging information, making it substantially easier for an attacker to reverse engineer the firmware and identify exploitable vulnerabilities. Low C Locally Exposed Telnet for WiFi Management A separate management system is exposed via Telnet for configuring WiFi when connected to the local network of the device. Telnet is an insecure protocol, making it possible for an attacker to intercept the username and password for this system when accessed by the main host. Low C, I

Conclusion

The stated goal of this research was to assess the security posture of two SATCOM terminals, the iSavi and SABRE Ranger 5000 from Wideye. Our assessment found the security of both devices to be extremely poor and cause for serious concern to the various industries which may make use of these products, including Oil and Gas, Agriculture, Utilities, Mining, and any remote work which must rely on satellite connectivity due to location or circumstance.

Taking these results in isolation, our assessment gives clear indication that neither the Availability, Integrity, nor Confidentiality of either the iSavi or Ranger 5000 is protected from compromise. These devices are affected by numerous vulnerabilities which are well established in the industry, with proposed fixes and well-known best practices in some cases for several decades. In other cases, the devices have been made less secure by design, with the introduction of several sets of hardcoded “backdoor” credentials—a practice understood to be insecure in all industries.

The results indicate that those devices exposed to the wider Internet, a possible configuration for the Ranger 5000 (whose marketed purpose is remote management of industrial assets), are at especially high risk. However, even if the devices are not exposed directly to the Internet, many vulnerable services are unnecessarily exposed to the satellite network, which still provides ample opportunity for attack from within that network.

Users of these devices can take steps to mitigate some of these issues, such as enabling the device’s firewall and heavily restricting access to only those IPs explicitly known to be trusted. This is not a panacea and does not fully protect these devices. The final responsibility for securing the iSavi and Ranger 5000 lies with the vendor, who is the only entity in a position to meaningfully correct the issues identified in this paper.

Taken in the wider context of the SATCOM industry and IOActive’s previous research in this field, the results of this research are a uneasy indication that the SATCOM industry has not heeded the many warnings of researchers and security professionals over the last decade, maintaining an unacceptable attitude toward security inappropriate in the face of the threat landscape of the modern age. As SATCOM technology becomes more advanced and is relied on more heavily by a variety of sectors, the security of this industry will only become more vital. It is in the hands of SATCOM vendors to rapidly modernize their approach and attitude toward security.

Research Approach: Technical Details
This research consisted of two primary approaches: a dynamic approach, directly interacting
with the running iSavi and Ranger systems, and a static approach, reverse engineering
firmware images which are publicly available from Wideye and other vendors. For many of the
identified vulnerabilities, these approached were used in conjunction to identify and confirm
possible vulnerabilities. As such, their usage will be intermixed as appropriate in the following
section.
Network Scanning
In order to better understand the system from a network perspective, the devices were
configured as they would be in a standard deployment and connected to via local network.
Initial network scanning was conducted with Nmap, with the following two hosts identified as
up and running the following services:


192.168.1.35
Port Service Description
23 Telnet VxWorks kernel shell, requires authentication
80 HTTP Wideye management web interface, requires authentication
5060 SIP SIP server, allowing voice calls to be made using the satellite connection
9998 AT AT command shell, accepts AT commands for controlling the device, some
commands require authentication
192.168.1.36
Port Service Description
23 Telnet Limited command shell allowing for device WiFi interface configuration, requires

authentication
80 Web Web interface offering the same functionality as the Telnet interface, requires the

same authentication as the Telnet interface


Firmware Collection and De-obfuscation
IOActive attempted to locate publicly available firmware images, to determine the risk of an
attacker acquiring and reverse engineering such images in order to develop exploits against
either of these devices. We identified several sources for a current firmware image, including
the Wideye website20 as well as the Inmarsat website’s BGAN software listing.21 Attempts
were made to acquire outdated firmware images from the same and other sources (older

Figure 6. Firmware File Entropy Graph

software versions can sometimes be helpful for reverse engineering) via URL manipulation
and the use of search engines, but no source of outdated firmware images was found.
The firmware images which were available appeared to encrypted at first glance, with no
discernibly meaningful content. However, examining the entropy of the firmware files with
binwalk -E generated an entropy graph not indicative of standard encryption techniques.



By reversing engineering the firmware from a R01.0.1 device, IOActive was able to recover the
obfuscation method. Rather than encryption, firmware images are subjected to weak
obfuscation; it can best be described as a 4-bit substitution cipher. A lookup table is used to
substitute every 4-bits with another number. The logic responsible for de-obfuscating firmware
update files in the existing firmware can be seen below, in Binary Ninja.

Figure 7. Firmware De-obfuscation Function

Using this knowledge, IOActive was able to de-obfuscate the R01.0.2 and the R02.0.0 iSavi
firmware images. Being able to de-obfuscate the firmware images will allow an attacker to
search for more vulnerabilities. IOActive also confirmed that this same obfuscation technique
is still used on the most recent R02.0.2 iSavi firmware images currently available for
download, as well as the most recent (R01.0.3) Ranger 5000 firmware images, and was able
to de-obfuscate those as well.
The following script will de-obfuscate the individual files within the compressed firmware
update:


#!/usr/bin/env python3
import argparse
parser = argparse.ArgumentParser()
parser.add_argument(“src”, type=argparse.FileType(“rb”))
parser.add_argument(“dst”, type=argparse.FileType(“wb”))
args = parser.parse_args()
LOOKUP_TABLE = [9,3,1,6,0xD,0xB,8,5,2,0xE,0xC,7,0xF,4,0xA,0]
def decrypt_byte(byte):
return (LOOKUP_TABLE[byte & 0xf]) | (LOOKUP_TABLE[byte >> 4] <<
4)
tmp = bytearray(1000)
while True:
count = args.src.readinto(tmp)
if count == 0:
break
for i in range(count):
tmp[i] = decrypt_byte(tmp[i])
args.dst.write(tmp[:count])


Finding Weak Firmware Obfuscation
Fix(es) Wideye should use standard encryption algorithms, such as AES, to protect
the confidentiality of firmware updates. In addition, firmware updates should
be cryptographically signed in order to confirm the authenticity and integrity of
the updates.


Mitigation(s) None
With the firmware images de-obfuscated, it was possible to begin reverse engineering them.
Wideye has compiled debug builds into the firmware and include the DWARF debug
information. This information is very useful for reverse engineering, as it provides names of
symbols and type information.

Figure 8. Example of Symbols in Binary Ninja
This extra information substantially decreases the difficulty of reverse engineering a complex
firmware image. There is no reason why a production firmware image should include this
information, as its purpose is to aid in development.
Finding Debug Information Included in Firmware Images
Fix(es) Before building the firmware image, the binaries should be stripped of any
debug information.


Mitigation(s) None
A firmware update for the iSavi device is a ZIP file with a number of obfuscated files inside it,
as discussed above. The ZIP file and the files within it do not contain any integrity checks. An
attacker with adequate access to update the firmware (achievable via several of the findings
identified during this research) could load malicious firmware onto the device to gain
persistent, low-level access.
To test this, a modified firmware file was created. This was done by extracting the ZIP file for a
valid update, de-obfuscating the contained files, modifying a file, re-obfuscating, and re-
zipping. To this end, the above script used for de-obfuscation was adapted to also allow
alteration of data in the other direction:


#!/usr/bin/env python3
import argparse
parser = argparse.ArgumentParser()
parser.add_argument(“mode”)
parser.add_argument(“src”, type=argparse.FileType(“rb”))
parser.add_argument(“dst”, type=argparse.FileType(“wb”))
args = parser.parse_args()
LOOKUP_TABLE_DEC = [9, 3, 1, 6, 0xD, 0xB, 8, 5, 2, 0xE, 0xC, 7, 0xF,4, 0xA, 0]
LOOKUP_TABLE_ENC = [0xF, 2, 8, 1, 0xD, 7, 3, 0xB, 6, 0, 0xE, 5, 0xA,
4, 9, 0xC]
def decrypt_byte(byte, lut):
return (lut[byte & 0xf]) | (lut[byte >> 4] << 4)
tmp = bytearray(1000)
while True:
count = args.src.readinto(tmp)
if count == 0:
break
for i in range(count):
if args.mode == “decrypt”:
tmp[i] = decrypt_byte(tmp[i], LOOKUP_TABLE_DEC)
elif args.mode == “encrypt”:
tmp[i] = decrypt_byte(tmp[i], LOOKUP_TABLE_ENC)
else:
sys.exit(-1)
args.dst.write(tmp[:count])


For this test, the hashed password used for Telnet VxWorks shell access on the device was
modified. Once the firmware update was complete, it was confirmed that the device was using
the modified Telnet password which allowed for further system access.

Figure 9. Modified Firmware Telnet Access

Finding Unauthenticated Firmware Update
Fix(es) Firmware should be cryptographically authenticated to prevent modification.
Mitigation(s) Activating the device’s firewall and blocking incoming connections will help to
reduce the exposure of this issue.

Network Services
Networking Configuration
After an initial Nmap scan, the network services, and overall network configuration, of the
devices were analyzed. After gaining access to the VxWorks shell on the iSavi (via malicious
firmware update, discussed above) and the Ranger (via backdoor shell password, discussed
below), it was possible to gather more detailed information about listening services with the
netstat command.

The network services running on the devices appear to be bound on all interfaces. This makes
them available on both the local WiFi network and the satellite network. This exposes these
services with their vulnerabilities to the satellite network. Depending on the configuration of the
carrier and if the end user has purchased a static/public IP, these services may be accessible
over the public Internet or to other satellite devices.

Figure 10. Netstat Output


One interesting side-effect of this is the SIP server running port 5060 is also bound on all
interfaces. This opens the possibility of a remote user connecting to the SIP port and using the
iSavi device to place a call, thus impersonating the owner of the iSavi.
Finding Services Bound on All Interfaces
Fix(es) Wideye should update the firmware to only bind the administration services
on all interfaces if remote administration is configured; everything else should
only be bound on the local WiFi interface. Since the option for remote
administration is not normally available for the iSavi, nothing should be bound
to all interfaces.
Mitigation(s) Activating the device’s firewall and blocking incoming connections will help to
reduce the exposure of this issue.


VxWorks Kernel Shell
After network configuration had been investigated, each of the individual listening services was
examined. One of the more interesting was the Telnet login prompt on port 23. The string
VxWorks login: was printed to the screen when connecting. Based on IOActive’s
experience with VxWorks systems, as well as on Ruben’s previous research where hardcoded
“backdoor” credentials were present for VxWorks shells exposed on other SATCOM terminals,
it was likely a similar situation might be discovered here.


Reverse engineering of the section of the iSavi firmware responsible for the VxWorks kernel
shell, the following authentication initialization function was identified:

Figure 11. iSavi Auth Init

And similarly for the Ranger 5000:

Figure 12. Ranger 5000 Auth Init

The calls to loginUserAdd appear to be adding a new user, passing in a username and
possible password or password hash. Attempting to authenticate with those strings directly
was not successful, and so they were assumed to be hashes. This was further corroborated by
base64 decoding these strings, which produced 32 bytes of data—the length of a sha256
hash. Further reverse engineering identified the function responsible for checking if a
password was valid on login attempt, with the following logic:

Figure 13. SHA256 and base64 Password Handling


Indeed, these were base64-encoded SHA256 hashes. To confirm that the loginUserAdd
function was in fact registering these hardcoded credentials to allow authentication, we took
advantage of the total lack of firmware update security (discussed above) and replaced the
suspected password hash for the “avi” user on the iSavi device with a hash corresponding to a
password we controlled. After software update, it was possible to authenticate using our
replaced credentials.
Furthermore, with the backdoor credentials extracted from the publicly available firmware for
both the Ranger 5000 and iSavi, we then attempted cracking these hashes offline. The
credentials for the Ranger 5000 were cracked immediately, due to their extreme simplicity:
username addvalue, password addvalue. As mentioned, these credentials are hardcoded
into the firmware running on every Ranger 5000 device, and cannot be removed or disabled.
They can be used to access the VxWorks kernel shell and gain full and arbitrary control of the
device over the network, including over the Internet, if the device is configured to be
accessible in this way.
Our dedicated password cracking infrastructure is currently attempting to crack the credentials
for the iSavi account, though a password has not been recovered at the time of this paper’s
publication.


Finding Hardcoded/Backdoored Operating System Credentials
Fix(es) Every account available on the device should be visible and have
configurable, strong passwords. The hardcoded accounts should preferably
be removed entirely. If a method of accessing the devices is necessary for
remote management or device recovery, this access should require either a
unique key or take advantage of public key cryptography to properly
authenticate a connection.
Mitigation(s) Activating the device’s firewall and blocking incoming connections will help to
reduce the exposure of this issue.


AT Command Shell
The service running on port 9998 was investigated next. It proved to be an AT command shell,
allowing for certain management actions to be taken with valid authentication using the
AT_ICLCK command (using the same credentials as the web interface). A brute-force attack
on this mechanism was conducted to determine if any protections were in place. It was
determined that it does not have anti-brute-force protections when trying to authenticate via
the AT_ICLCK command. As a result, it is possible for a potential attacker to perform an
authentication brute-force attack.


Finding AT Command Authentication Brute-Force
Fix(es) Add anti-brute-force protections to the AT command shell and integrate the
protections with the web admin interface so an attacker cannot utilize both
interfaces to speed up brute- force attacks.
Mitigation(s) Activating the device’s firewall and blocking incoming connections will help to
reduce the exposure of this issue.
During investigation into the AT command shell running on port 9998, it was determined that
this interface is vulnerable to a basic overflow. Sending any AT command 66 bytes in length or
greater will case the device to crash and reboot. This appears to be a buffer overflow and
should allow for remote code execution. The AT shell does require authentication before
performing any significant commands, but in this case, the overflow appears to occur during
the parsing of the AT command and before the requirement of authentication. So, no
authentication is necessary to trigger this vulnerability.

Publication Date: April 5, 2022 [26] ©2022 IOActive, Inc. All Rights Reserved.
Finding Hardcoded/Backdoored Operating System Credentials
Fix(es) Every account available on the device should be visible and have
configurable, strong passwords. The hardcoded accounts should preferably
be removed entirely. If a method of accessing the devices is necessary for
remote management or device recovery, this access should require either a
unique key or take advantage of public key cryptography to properly
authenticate a connection.


Mitigation(s) Activating the device’s firewall and blocking incoming connections will help to
reduce the exposure of this issue.


AT Command Shell
The service running on port 9998 was investigated next. It proved to be an AT command shell,
allowing for certain management actions to be taken with valid authentication using the
AT_ICLCK command (using the same credentials as the web interface). A brute-force attack
on this mechanism was conducted to determine if any protections were in place. It was
determined that it does not have anti-brute-force protections when trying to authenticate via
the AT_ICLCK command. As a result, it is possible for a potential attacker to perform an
authentication brute-force attack.


Finding AT Command Authentication Brute-Force
Fix(es) Add anti-brute-force protections to the AT command shell and integrate the
protections with the web admin interface so an attacker cannot utilize both
interfaces to speed up brute- force attacks.


Mitigation(s) Activating the device’s firewall and blocking incoming connections will help to
reduce the exposure of this issue.


During investigation into the AT command shell running on port 9998, it was determined that
this interface is vulnerable to a basic overflow. Sending any AT command 66 bytes in length or
greater will case the device to crash and reboot. This appears to be a buffer overflow and
should allow for remote code execution. The AT shell does require authentication before
performing any significant commands, but in this case, the overflow appears to occur during
the parsing of the AT command and before the requirement of authentication. So, no
authentication is necessary to trigger this vulnerability.

Figure 14. AT Overflow Crash

Publication Date: April 5, 2022 [27] ©2022 IOActive, Inc. All Rights Reserved.
Finding AT Shell Buffer Overflow
Fix(es) Add additional data verification to detect long AT commands and reject
commands that are too long.
Mitigation(s) Activating the device’s firewall and blocking incoming connections will help to
reduce the exposure of this issue.
A bug related to this was also identified in the web interface. iSavi’s web administrative page
makes POST requests to /app with an action of atcmd. The body of the POST contains the AT
command to run. Sending a long AT command causes the iSavi to crash and reboot. This
appears to be a buffer overflow and may allow for remote code execution. The web
administrative page does have the potential to be accessed remotely, and the flag restricting
access to the local network can be bypassed. Access to this command does require
authentication, although the iSavi authentication scheme can by bypassed.
The following request will cause the device to become unresponsive:


POST
/app/?sessionid=833F4C1A0E2DD1B6AA31760F63CAF32F&action=atcmd&timesta
mp=15
215068446770.06416846104994112 HTTP/1.1
Host: 192.168.1.35
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:57.0)
Gecko/20100101 Firefox/57.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://192.168.1.35/app/menu/?sm=PIN
Content-Length: 71
Content-Type: text/plain;charset=UTF-8
DNT: 1
Connection: close
atcmd=AT_AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AA


Finding Web Admin AT Command Overflow
Fix(es) Add additional data validation checks to prevent a large atcmd from
overflowing buffers.


Mitigation(s) Activating the device’s firewall and blocking incoming connections will help to
reduce the exposure of this issue.


WiFi Configuration Telnet and Web Interface
When a user is connected over the local WiFi, there are two hosts listening: 192.168.1.35 and
192.168.1.36. The .35 host acts as a gateway and as the host for the web interface. The .36
host seems to be used for configuring the WiFi. This is done by the .35 host using Telnet to
transfer the configuration. As Telnet is not a secure protocol, the endpoint can be arp-spoofed
to intercept the login and gain credentials to the device. This allows an attacker to interact with
the Telnet shell which does have a limited command set that only seems to allow for WiFi
configuration.

Figure 15. WiFi Configuration Telnet


Using the arpspoof Linux utility, IOActive was able to spoof the WiFi host and intercept Telnet
traffic. When the WiFi settings are changed, the main host logs into the WiFi host to upload the
configuration. Sniffing this traffic allowed for viewing the plaintext credentials, which were then
used to access the device. The same credentials can be used to access the web interface,
offering the same functionality and information.