Following a legal threat from █████, Proack has decided to remove their name from this article. While we worked in good faith to responsibly disclose the vulnerabilities discussed below, and held the release of this article until fixes were implemented, █████ still decided to threaten us with legal action if we publicized the vulnerabilities we found.
Continuing with our research projects (see Insecure Use of Unique Identifiers) this year, one of our team members decided to purchase a █████ smart bulb starter kit. As always we got curious so we decided to spend some time looking at the IoT devices and the Android application to see if we could uncover any exciting ways to tinker with the smart bulbs or passively identify any glaring vulnerabilities. A week long research project ensued.
Who is █████? They are a manufacturer of smart home devices such as bulbs, cameras, electrical plugs, door sensors, etc., which are sold all across the world.
Why are we still publishing? Like with all our previous posts, we want to bring public awareness to similar types of vulnerabilities that may exist in everyday applications. Without proper security validation, vulnerabilities such as these can easily go unchecked, exposing users to unwelcome risk. In this case, someone can turn the electrical devices in your house on or off, or watch and listen to you on the █████ security camera (creepy). Remember what happened to Ring?
The Problems
Problem 1 (Fixed) – Like any good penetration tester, one of the first things you look at is authentication. Using the █████ Android mobile app, we logged in and out, changed our password, and set a new one using the Forgot Password feature. Insert problem. Users receive an email with a randomly generated link to a reset password form; however, the subsequent POST request, which includes the user’s account (email address) and their new password, is made to an API endpoint without any form of validation. By simply changing the account field to any email address of your choice, you could change that user’s password and hijack their account. User sessions that already exists are not terminated and users do not receive an email that their password was changed. This attack would 1) go undetected and 2) even if the victim changes their password, the hacker would still have access to the victim’s account.
Resetting the password for our test account. No authentication is required to call this endpoint. 
Error message received when a password change is attempted for a non-existent account.
Problem 2 (Fixed) – Right out the gate, we noticed that the █████ Android mobile application trusts any TLS certificate that it is presented with. While we typically find this in applications that are still in early development stages, there are the odd few that make it to production and into the Google Play store. This allowed us to intercept all web traffic made from the app without loading a trusted certificate. As a result, if a █████ user is ever on an insecure network, and a man-in-the-middle scenario exists, any app traffic from █████ can be intercepted and access can be stolen. Worst of all, the victim won’t even know it happened.
Pointing the mobile device to a proxy server. The trusted CA has been disabled as part of this test 
All requests made from the █████ Android application are easily intercepted and viewable in the web proxy
Test Environment:
Mobile device: OnePlus Two
Android version: 10
Android build: 1.1.44 / 1.1.61
Remediation:
As of July 19, 2020, █████ has indicated that the above vulnerabilities have been addressed. Upgrade to the latest Android/iOS application and you should be good to go.
Disclosure timeline:
█████ does not have a bug bounty program or a method to disclose vulnerabilities responsibly; however, our findings were reported as per industry best practices:
- March 26, 2020: Emailed █████ support team indicating several vulnerabilities were found.
- March 26, 2020: Received a response from █████ requesting we share the details of our findings with their development team.
- March 27, 2020: Email sent to █████ with the details of our findings.
- May 4, 2020: Sent a follow up email requesting an update. No response
- June 2, 2020: Sent a follow up email requesting an update. No response.
- June 18, 2020: Sent a follow up email requesting an update, indicating 90 days has almost elapsed and we have not received a response.
- June 18, 2020: Response received from █████ requesting we resend the details of our findings.
- June 19, 2020: Re-shared findings with █████.
- June 23, 2020: █████ requested a meeting to discuss the vulnerabilities and our research and provided an update as to the remediation efforts that were underway. We agreed to extend our disclosure by two weeks to provide sufficient time to remediate the vulnerabilities.
- June 25, 2020: █████ notified us that remediation for Problem #1 (account hijacking) is in place.
- July 1, 2020: █████ threatened legal action if we publicized our findings.
- July 1, 2020: Offered to █████ the opportunity to provide their own comments to the blog post. No feedback.
- July 19, 2020: █████ notified us that remediation for Problem #2 (insecure TLS certificate validation) is in place.
- July 20, 2020: Public release with █████‘s name removed.