The iSEC Partners Security Advisory - 2012-003-verizon states: The Verizon Wireless Network Extender is a low-power cellular base station. It is given or sold to subscribers by mobile network operators, and works like a small cell tower, using a home Internet connection to interface with the provider network. When in range, a mobile phone will connect to a femtocell as if it were a standard cell tower. Two versions of the Network Extender were tested: the Samsung SCS-26UC4 and SCS-2U01. The Network Extender is susceptible to a number of vulnerabilities that allow console access to the device as root, using a custom HDMI cable. Exploiting these vulnerabilities can lead to a total compromise of the device, including running custom code and eavesdropping on voice, text and data communication. An additional vulnerability exists in the CDMA authentication code that allows cloning of a subscriber's phone.
SCS-26UC4 Root Exploit:
-----------------------
The older hardware version of the Network Extender is designated "SCS-26UC4".
It is possible to exploit a built-in delay of the Uboot bootloader to obtain console access. To be able to exploit this vulnerability, a special console cable must be created with an HDMI connector to connect to the device. Once it is possible to view boot output, the following steps will present a root shell:
1) While viewing the boot output, a prompt will display:
"Press any key to interrupt boot"
2) Type "sys" and press <enter>
3) Disable the watchdog by typing:
setenv watchdog_off 1
4) Update the ramboot environment variable by typing:
setenv ramboot version\;echo\;setenv\ bootargs\ mem=64M\ console=ttyS0\,57600n8\ root=/dev/ram0\ init=/bin/sh\;mdocboot
5) Type "boot" and press <enter> to boot the kernel and obtain a root shell.
SCS-2U01 Root Exploit:
----------------------
The newer hardware version of the Network Extender is designated "SCS-2U01".
It is possible to obtain console access to the SCS-2U01 even though the Uboot delay has been removed, using the SysReq (System Request) interrupt. The actual key combination used to send a SysReq is dependent on the terminal emulator program used on the connected computer. If successfully applied, this command will halt boot process and drop the user to a login prompt, where it is possible to login as the root user. As with the previous exploit, it is first necessary to create a console cable to be able to view and send commands to the device.
1) While viewing the boot output, wait until the device attempts to extract the RFS.
2) Enter <SysReq> i(1)
3) All running processes will be terminated and a login prompt will display
4) Log in with the root username and password to obtain a root shell.
(Note: This password is the same for all systems and is freely available on the Internet)
Lack of CAVE Authentication:
----------------------------
The Network Extender does not appear to use Cellular Authentication and Voice Encryption (CAVE). For cellular phone authentication, the device appears to only use the ESN and MIN. These numbers can usually be obtained with physical access to a phone, or by sniffing registration packets as they transit the Network Extender. Combining the above root access flaws with a lack of proper authentication, it is possible to run custom code on the Network Extender that will obtain the ESN and MIN from any phone within range. Using these numbers, a phone can be cloned without direct physical access and without a user's knowledge, although association to the Network Extender is required.
Fix Information:
----------------
It may not be possible to completely secure this device from unauthorized use. However, it is certainly possible to harden the device and make it more difficult to exploit. A detailed analysis should be performed on all aspects of the device, including hardware design.
Proposed fixes:
---------------
1) The Uboot delay flaw in the SCS-26UC4 has been addressed in the upgrade to the SCS-2U01. Depending on the expected operational lifetime of the SCS-26UC4, it may be appropriate to apply a fix to these devices or to plan to remove them from the network.
2) The SysReq vulnerability can be fixed by disabling the kernel variable:
/proc/sys/kernel/sysrq = 0.
Note: this change should be made in the kernel at compile time, rather than set via sysctl variables.
3) CAVE Authentication should be implemented on the Network Extender.
4) Change the root password; the current password has been published on the Internet for some time. The new root password should be extremely strong and beyond the reach of even projected password cracking ability. For example, a 40-character alphanumeric lowercase/uppercase string with symbols would be more suitable.
5) Consider adding an increased system monitoring capability or tamper protections that will provide the ability to detect possible exploitation attempts. For example, monitoring certain device errors or user logins may provide information on potential break-in attempts.
The fixes proposed above will mitigate the specific vulnerabilities discovered, but may not greatly increase the overall security of the system. Hardening the device can only go so far, as the system architecture itself is flawed. Because users are in physical possession of the device, it may not be possible to harden the Network Extender to the extent where it cannot be effectively exploited while also allowing it to be usable and serviceable. As long as data from the cellular handset transiting the Network Extender is available in plaintext, it will be vulnerable - even if communication is secured between the
Network Extender and the internal Verizon network.
Require registration of subscribers phones to specific femtocells, and enforce this on Verizon's core network. Subscribers should only be able to connect to femtocells they have been securely registered with. This prevents attackers from deploying rogue femtocells to capture arbitrary subscribers in an area. However it may still be possible for attackers to bypass the registration by isolating a subscriber from the core network and simulating phone calls or text messages and receiving responses from the device.
Encrypting the communication between the handset and the carrier network end-to-end would make it much safer from eavesdroppers anywhere along the network path, including at the Network Extender. If this model of secure communication were applied to all voice, text and data traffic on the handset,
the Network Extender architecture could be made significantly more secure.
In this scenario, if a determined attacker were able to compromise a hardened device, data loss would be much less severe, since the data is encrypted and equivalent to what the attacker could see by sniffing their own network. This does not preclude other attacks that can be performed on encrypted data, but is a stronger and defensible architecture given the current system design.
iSEC Partners stated they contacted Verizon on December 7th, 2012 and Samsung on January 3rd, 2013 for a coordinated disclosure of these vulnerabilities. |