Kasa Camera Vulnerability Discovery: Responsible Disclosures

When APIs Say Too Much: Discovering the Security Vulnerability

As a Midwesterner and hobby farmer I spend a lot of time solving problems. A few months ago I encountered a problem where a live 2-month-old cucumber plant just suddenly had no leaves. A wander around my greenhouse helped me discover that something was knocking things over and taking bites out of various plants, leaving all the cucumber plants with no leaves. What on earth did this? Well I wanted to set up a camera and find out.

Upon my return from the electronics store I started to look at the Kasa camera I had selected and decided I would set it up and capture whatever is eating my plants. Upon installation I realized the mobile application was connecting directly over the network to the camera, and if I wasn’t on the network I still could see the images from my camera on the mobile app. As a security professional, this concerned me.

I looked at the application request methods and given the potential sensitivity of the data in the system I wanted to ensure the data transfer was encrypted. As noted in the just published Consumer Reports (CR) Home Security Camera Buyers Guide, Kasa’s mobile application does use SSL, however since the CR analysis looked only at the public facing documentation, it did not highlight the fact that the SSL certificate isn’t pinned, so it was easy to open it up and look at the transactions. I also found that the authentication is simply BASE64 encoded username:password being passed under SSL. Security best practices dictate that the application should hash under the SSL rather than encoding and reiterated the value of pinning the certificate.

Of equal concern to me was that the authentication to the web platform, not the direct connection to the camera, was giving very verbose API error messages. Since I used my email address as my username, as most do on this platform, a simple set of requests would allow for enumeration of the user accounts on the platform. As someone who works to battle automated cyber attacks (bots) and keep automated attacks at bay, I know that having verbose API error messages on authentication endpoints leads to Account Take Over (ATO) attacks. For example:

• Sending a bad username yields {“error_code”:-20600,”msg”:”Account not found”}
• Sending a bad password yields {“error_code”:-20601,”msg”:”Password incorrect”}

Now, it is possible for an attacker to enumerate usernames based on email lists. Once the known good username list is established, the password attack can begin. ATO happens much more easily when an attacker can easily understand what a good username is and what the matching password is. This would lead to a Credential Stuffing attack to guess the passwords, otherwise the attacker would need to put in the good username and take over the account via a password reset mechanism.

When developers create applications they have to be very mindful about what the application might say to anyone that uses it. If there is a SQL error in the application, the error message shouldn’t reflect what exactly went wrong. Similarly, in authentication, error messages can tell us exactly what broke or it can just tell us something is broken and that is all. Being very verbose with error messages is a bad plan. I typically teach developers to keep the error messages generic (something went wrong, try again). I suggest a single error page and in the blocks of code that could reveal an error, point to that generic page.

Notification of Kasa Security Vulnerability

Following responsible disclosure practices, I reached out to the folks at TP-LINK, Kasa’s parent company, on March 5^th, 2020 to let them know I had discovered several security concerns in one of their Kasa model security cameras. They responded quickly and wanted more information. I shot a video of the things I was worried about and they said they would work on it. They responded quickly and wanted more information. I shot a video of the things I was worried about and they said they would work on it.

On June 11^th, TP-LINK responded with information regarding the certificate pinning and BASE64 encoding that included a new Firmware Version for the KASA camera as well as a new mobile application.

As of this writing, however, they haven’t fixed the information disclosure on their platform, and ATO with Credential Stuffing is still a possible outcome. Their APIs are telling the attacker how to be more efficient and helping the attacker figure out valid username and password combinations.

In case you are wondering, at this point, I figured out what was eating my cucumbers.

Yeah, like the Groundhog Phil.

As developers use APIs to build platforms that allow for more rapid feature release so their users can have amazing and memorable experiences, an equal amount of emphasis must be placed on ensuring users can utilize the application safely and securely.  APIs make things easier, just make sure they do not become attack vectors against your platform. As a consumer, when you entrust sensitive data to a 3^rd party, you need to know if they are going to be good stewards of the data.  I would have liked to have known the limitations of the security of this particular camera before buying it.  As I assumed there are a few that are doing it well and some that aren’t a recent Consumer Reports Article would have helped me make a more informed decision.

Findings

• Authentication to the web platform, not the direct connection to the camera, was giving very verbose API error messages. These can be used by attackers for ATO and credential stuffing.
• Authentication is BASE64 encoded username:password being passed under SSL, where best practices recommend the application hash under the SSL rather than encoding and reiterated the value of pinning the certificate.

Disclosure Timeline

March 2, 2020 – Begin trying to find the right person to contact

March 5, 2020 – Emailed TP-LINK, Kasa’s parent company, about the findings

March 6, 2020 – TP-LINK security responded asking for more details

March 7, 2020 – Sent TP-LINK a video outlining the issues in detail

March 8, 2020 – TP-LINK replies they are working on fixes

March 20, 2020 – TP-LINK updates progress and asks if we plan on going public with the information, we informed them that we intended to discuss this openly after 90 days from the first report had expired.

March 22, 2020 – TP-LINK states they have quite a bit to fix on the platform and will need to address the ATO vulnerability later

March 31, 2020 – TP-LINK states they will push a fix at the end of April

June 4, 2020 – 90-day disclosure period ends

June 11, 2020 – TP-LINK responded with information regarding the certificate pinning and BASE64 encoding that included a new Firmware Version for the KASA camera as well as a new mobile application. ATO and Credential stuffing vulnerability have not been fixed.

June 15, 2020 – TP-LINK states the ATO/Credential Stuffing Vulnerability will be fixed later but it will take time.

July 9, 2020 – Public disclosure

*Working with TP-LINK, the security vulnerabilities brought forward have been addressed and corrected by placing limitations on the numbers of incorrect attempts on a user account and by creating an error messaging system that leads to no further user account or password enumeration.

Thank you, TP-LINK, for making your products safer for your users.