Wickr Inc - When honesty disappears behind the VCP Mountain

Wickr Inc Secret Messenger - Bug Bounty Program Vulnerabilities by Design

Today we would like to talk about the security of the american secret messenger called "Wickr - Secret Messenger". The company of the product is located in the united states and encrypts messaging context with high military grades. The software is build to secure the customer against local and remote attacks but as well forensic methods of law enforcment agencies. In the development team is filled with people like jeff moss and dan kaminsky, which are assisting the process with there expertise. On January 15th, 2014, Wickr announced it is offering a  $100,000 usd bug bounty for those who find vulnerabilities that significantly impact users. After we received the invitiation to the program, we decided to participate due to a longer period of time.

During our active security research we identified several security vulnerabilities (19) in the official wickr software core and mobile applications. The following short list shows which issues (7) was disclosed first during the first participate in the official program.

• Wickr (Windows & Mobile Applications) - Remote Denial of Service Vulnerability
• Wickr (Mobile Applications) - Audio Memo Function Surveillance Vulnerability
• Wickr (Mobile Applications) - Online Offline Mode Messenger Exception Privacy Vulnerability
• Wickr (Mobile Applications) - Auth Bypass Vulnerability
• Wickr (Windows & Mobile Applications) - Blocklist Issue
• Wickr (Mobile Applications) - Input to Define Vulnerability
• Wickr (Mobile Applications) - Local Copy Message Context Issue

We began with the audits during 2013-2014 and setup a full unique environment for the wickr software and application testings. Therefore we used an ipad, an android phone, and iphone and a windows computer. All systems was setup with a clean copy of the newst wickr software version. To log errors we was using the several mobile and windows programs like debuggers, isyslog, error protocols, mobile debug software, windows debugger and immunity. All our bugs was reported after the discovery process to the official bug bounty contact of the wickr company in 2014.

Wickr (Windows & Mobile Applications) - Remote Denial of Service Vulnerability
The first issue that we would like to demonstrate is a denial of service vulnerability that has been discovered in the official Wickr TSM v2.2.1 (MSI) windows software and mobile application (Android & iOS). The issue allows local and remote attackers to crash or shutdown the software client by usage of special crafted symbole path payloads.

The wickr v2.2.1 (msi) software crashs with unhandled exception in the `CFLite.dll` by the `qsqlcipher_wickr.dll` when processing to include special crafted symbole strings as password or name. The issue occurs after the input of the payload to the `change name friend contacts`-, `the wickr password auth`- and the `friends > add friends` input fields. Attackers are able to change the name value of the own profile (payload) to crash the wickr client. Local attackers can include the payload to the input fields to crash/shutdown the application with unhandled exception. The issue occurs because the charset validation of the parse mechanism is not able to interpret the character submitted via form to the database management system of wickr. By processing to open a form or message with the payload, the software crashs or shutsdown permanently. Due to the disclose we nuked us ourself out of the network several times and used the issue as joke to improve our good mornings greetings to other involved security researchers. After saving the context to your account, it could happen that the software needs to be reset to default for further usage. In the moment another users sees the name list the client crashs as well. Thus can happen on sharing, team conversations or the basic setup.

The security risk of the denial of service vulnerability was estimated as medium with a cvss (common vulnerability scoring system) count of 3.3. Exploitation of the DoS vulnerability requires a low privileged application user account and no or low user interaction. Successful exploitation of the vulnerability results in an application crash or permanent service shutdown. Affected of the issue were the following modules with the marked inputs and parameters.

Vulnerable Module(s):
[+] friend contacts
[+] wickr password auth
[+] friends

Vulnerbale Input(s):
[+] add friends (name)
[+] wickr password auth
[+] change friend (update name)

Vulnerable Parameter(s):
[+] name (value input)
[+] password (vale input)

Affected Libraries:
[+] qsqlcipher_wickr.dll
[+] CFLite.dll

Manual steps to reproduce the vulnerability ...
1. Download Wickr v2.2.1 for windows to your windows 8 box (mywickr.info/download.php?p=4)
2. Install the wickr windows version of the software to your windows 8 box
3. Create an new account and include the payload to the password input field
Note: After the payload has been processed to the auth, the software crashs. You should attach a debugger ago.
4. Successful reproduce of the first issue!
5. We register a new account with regular values
6. Open the friends > add friends section and include the payload to the search input value
Note: After the payload has been processed to add the friend, the software crashs. You should attach a debugger ago.
7. Successful reproduce of the second issue!
8. We open the software again and login. Switch to the existing friends contacts and edit the profile
9. Include in the name values the payload and save the settings
Note: After the payload has been processed to change to the name, the software crashs. You should attach a debugger ago.
10. Successful reproduce of the third issue!
11. Now interact with another account to trigger the issue remotly. Depends on the visible values to the specific wickr user accounts.

PoC: Open Test Link

After looking closely at the vulnerability, we also got a bad feeling because each attacker can crash another client without a lot of interaction. The skype software client had about some years ago the same issue in case of handling special crafted character via messenger application. Every time you inserted the payload to any skype input the software crashed or influenced the connected users, which were also able to see the malicious included string. The libraries of the program was not able to interpret the conditions and thus resulted in an uncaught exception that results in a permanent crash of the software.

Wickr (Windows & Mobile Applications) - Blocklist Issue on Update
The second issue is a security and privacy vulnerability in the official Wickr v2.3.3 software for Apple iOS, Google Android and Windows.

During the tests of the iOS application we saw several times the problem that messages wasn`t able to arrive. We was checking the block and allow list but there was no entry. We tried to figure out what was the problem and had the luck to identify the problem.

In the iOS application block-list it is possible to glitch by preparing an block input in connection with the local siri app. In some cases it is possible to mark the input text of the block list module. After the input markup the attacker is able to insert the text and uses in the same moment the `iOS timer app` or `Siri app`. The context gets saved in the profile values but the profile does not become visible to the account owner itself. The inserted entry is invisible and the local user can not see that the account is blocked. To ensure the issues works we included at the end the account to the allow list and we was again able to receive messages.

Local attackers with privileged account can invisible block accounts in multi device user accounts of wickr in iOS. The first device blocks the account invisible and the second account can not review the context or see the blocked list context itself. The input field can be merged inside through the define module. After including through the message context define module input the blocklist the entry becomes invisible.

The security risk of the local glitch issue in the block list is low with a cvss (common vulnerability scoring system) count of 2.1. Exploitation of the issue requires local low privileged application user account without interaction. Successful exploitation can result in a denial of service issue be blocking messages to other people via design issue in connection with an app glitch.

Vulnerable Module(s):
[+] Block List

Manual steps to reproduce the local vulnerability ...
1. Install the wickr v2.3.3 iOS app to your apple device (iphone or ipad)
2. Open the application and switch to the Settings > Block List module
3. Include a user random exisiting test user account of enable multi device account to the block list
Note: Only include the context, do not save by click on OK!
4. Select the text of the input context
Note: Do not save by click on OK!
5. Now, press the home button of the iphone (siri) and hold in the same moment the OK button
6. We press now the power button on top and logon again to the mobile device as user
7. Open the running application were the blocklist is running in the task
8. The block-list is empty!
9. Go to another device and login through the multi device user account enable function
10. Write a message to the account
11. The message gets blocked
12. We go to the blocklist which is empty at both accounts
13. Successful reproduce of the local issue!

How does it feel for an user of wickr to write somebody that is invisible blocked to the account profile. Even if you know about the issue the only trick to remove the illegal behavoir is to reinstall the software. The data of the profile is saved within the mobile which results on read each time in the message delivery block by the active list. To demonstrate a part of the impact we linked here the official reproduce video of our enviroment base.

Wickr (Mobile Applications) - Audio Memo Function Surveillance Vulnerability & Dump Information
On fourth position of our releases is a security and privacy issue that has been discovered in the official Wickr Inc - Wickr mobile application v2.3.3 for apple iOS or android mobile. The bug affects both mobile application versions and allows a local attacker to exploit remotly the vulnerable audio memos function.

The vulnerability is located in the vulnerable `audio memo function` of the `wickr messenger interface`. The privacy issue can be exploited by a local attackers in connection with a hardware/software combination next to the recordings button push. The bug allows to send zero recorded messenges through an account to another remote account by usage of siri/google-now (iphone/samsung). During the testings we recorded 17 to 25 seconds sound memos and compromised the view of the interface display to zero or with swapping counter (misconfiguration). In the next step the local user answers during a conversation by usage of his local phone. The invisible 0 seconds message is get delivered with about 17 to 25 seconds recodings. The attacker uses next to clicking the recording button the siri function to save the information temporarily next to a hardware interaction through local software. It does not matter which interaction you use to compromise the view and recordings because all interaction next to the active process can result in such a security problematic.

In the security concept of wickr it is not allowed to store unauthorized unvisible information or not counted audio information thats can be send with the same wrong context in the interface to another wickr user. The user which has send the information has no review about the real count of the recorded audio information after manipulation. For luck a limitation (30 seconds) is inside because otherwise the mobile could be used for active live surveillance with the space of the mobile. The local user can see a recorded message with the count 0 but has already recorded content inside to a max limit of 30 seconds through wickr mobile application.

In case of a 0 seconds recording the software itself does not improve the counter correctly because of the confusing interaction with the device. The issue is mainly that the sync with the interaction makes the software that slow that the count is not covering the correct recording time. After the zero voice message is recorded the software crashs after some time cause of a memory lack next to processing the counter information of the recordings. A person with access to a mobile phone could use the software of a mobile in a restricted mode to trigger this interaction automatically. The attack vector is located on the application-side.

The security risk of the local vulnerability is estimated as high with a cvss (common vulnerability scoring system) count of 6.6. The privacy issue can be exploited by local attackers without user interaction or enabled multi device account. Successful exploitation of the security and privacy issue results in unauthorized recordings of audio information via manipulated timer count.

Request Method(s):
[+] Local

Vulnerable Module(s):
[+] Audio Memo Service - Interface Messenger

Required Service(s):
[+] Siri - iOS
[+] Google Now - Android

Affected Module(s):
[+] Timer Count - Audio Memo Recording Interface Messenger

Wickr (Mobile Applications) - Online Offline Mode Messenger Exception Privacy Vulnerability
A fifth issue is security vulnerability that has been discovered in the official wickr v2.3.3 mobile web application for apple iOS. The security issue allows local attackers to access restricted information inside of the application context by usage of a malicious interaction.

The vulnerability is located in the `iOS Apps Slide Bar Menu` when processing to manipulate the application via exception-handling. The a issue has been discovered inside of the audio memo function. A side effect of the issue that has been reported [#1](VL) is that the information can be streamed through to a persistent exception to keep the service logged in. As result of the interaction trick a persistent limitation exception has been droped thats streams information visible through an account that has been disconnected.

The secure app requires a login after the connection has been closed when processing to use it. By usage of an basic software exception and closing the online connection (mobile/wifi/umts) the service is able to stream inner secure context and exceptions of the software to outside the secured layer. If all notification and push messages are disabled, the user will see arriving messages in the bar of wickr with updates or an exception message by event through the slide bar menu of iOS. By usage of the slidebar in iOS the information in the application becomes visible to the local attacker. The exception pops up behind the authorized software login. After the connection close the information has no restriction to become visible by the user that reaches the exception through the service outside to display. In the security concept of wickr they disallowed to use a security exception in conenction with an connection lack to compromise the application and review information to the slidebar menu preview. The persistent exception can be will be displayed in the app, even if the app has been shut down or the connection has been closed. The interaction can be
triggered with all messages on push that gets delivered out of the software process itself. The vulnerability is not located at iOS after talking to the product service team because of the exception must be represented in the layer of status. Not on interaction, that can result in unexcepted behavoir on the controls.

The attack vector is located on the application-side of the service. The security risk of the local vulnerability is estimated as medium with a cvss (common vulnerability scoring system) count of 5.3. The privacy issue can be exploited by local attackers without user interaction or enabled multi device account. Successful exploitation of the security privacy issue results in unauthorized access to information through a glitch combo that manipulates the wickr app iOS slidebar preview.

Vulnerable Product(s):
[+] Wickr iOS Application

Vulnerable Module(s):
[+] Wickr Context in Slidebar Menu (iOS)

Wickr Mobile Applications - Local Copy Message Context & Message Menu Permission Context Issue
A proper vulnerability has been discovered in the official Wickr v2.3.3 mobile web-application. The issue allows local attackers to bypass the software/server auth of the wickr software to copy local context.

The issue allows a local attacker to merge the input field copy menu ahead to the wickr logon service. During the tests a disconnect is required to ensure that the data of the safe process can be copied outside later. The local attacker opens a new message and switch to the find input field. Inside he includes the names of the persons to add to a chat conversation. After adding the users to the header to start a conversation, he clicks select > define and uses in the same moment siri. Then the evader logs out the user account of the application by a disconnect of the wifi/online connection. After the disconnect he opens the process of wickr and have the glitches message menu inside the logon
and ahead of the auth. The local attacker now press some seconds the copy button and release it (the menu bar becomes invisible). After that he switches back to a local notepad and paste the information behind the login into a file.

In the video demonstration the local attacker login to an account manipulates it and then disconnects. After the disconnect the application usage requires an auth by the wickr server. The attacker opens the app task and copies the information of the internal software module through a merge ahead to the logon inside of a file. The issue is since yet only locally exploitable. Maybe other section with input and the same functions could allow to result in the same behavoir. The security risk of the local command/path inject vulnerability is estimated as medium with a cvss (common vulnerability scoring system) count of 6.0. Exploitation of the issue requires a local low privileged application user account without user interaction.

Successful exploitation via merge and disconnect results in the bypass of a security restriction. The Wickr software does not allow to copy context of the software after a disconnect. The issue allows to merge the message menu inside of the software ahead to the wickr auth. The result is a basic bypass of the regular auth mechanism like in the video demonstrated.

Manual steps to reproduce the vulnerability ...
1. Install the wickr app to your iOS device
2. Open the wickr app
3. Go to the top right to "New Conversation" (Chat Message) Button
4. Include some accounts of your list or include manually plain account names
5. Select the input of the inserted context, copy and then mark the text to highlight
6. Press now the home button of the iphone to get siri and next to it you press also the define function of the selected message context
7. Now push the power button and then disconnect from outside the wifi/online connection
Note: Now the server needs to authorize to use the software again because the information is stored at the wickr db
8. As next step the attacker opens the iphone login to the process of wickr after the disconnect
9. Ahead to the login to access the account are the message menu of the chat user input frozen
Note: Wihtout having a server connection it is not possible to access the profile to get information
10. Press 3 seconds the copy button and leave the wickr software login
11. Open the ios notepad and paste the copied information to a plainfile
12. All inputs of the chat user account which are include TO: will become visible
13. Successful reproduce of the vulnerability!

Wickr v2.3.3 iOS - Combo for Local Protection Auth Bypass Vulnerability
A privacy issue in connection with a security issue has been discovered in the official wickr v2.3.3 mobile web application for apple iOS. The security issue allows local attackers to merge inputs with inputs from outside the task to take control of the running software inputs.

Application inputs can be displayed in the slidebar main context menu within iOS. In the running tasks there is a function, allowing keyboard to get integrated to a running process. In case of our issue we used a little trick to merge the keyboard inside of the running closed/non-logged-in wickr task. The application configuration has not disallowed to run a keyboard on inputs in the basic wickr software task. During the updates the iOS allowed users to perform using the keyboard outside the task by processing the slide.

First we logged out by closing the mask but still with running task. We opened the never lock input and marged the field to get the connection of the keyboard with the task. After that we merged the keyboard by a slide up inside the wickr task. Thus allows an attacker to perform using the keyboard in the non logged in wickr task. Processing to use the copy and past shortcuts we was able to gain of the encrypted input the plain password back to login. The task was copied with the keyboard and then moved to the note app for paste unecrpyted. Like demonstrated in the video the keyboard can be easily triggered.

After we identified the issue we asked apple about the impact and they confirmed that thus is a behavoir produced by the software. As far as the software disallows to merge the keyboard to the process like other applications thus would not be possible. Means that that problematic is not located in the apple ios configuration but its located in the wickr context and interaction settings. The attacker switches during the manipulation by a glitch out of the service and includes new context through the slidebar preview of iOS in the wickr application. Thus finally leads to a successful attack against the target ios device using wickr. In a video demonstration the local attacker shows how to merge an input form to the slidebar menu and interact by usage of siri without required auth. During the exploitation the online connection needs to be closed, activated to use siri, deactivated to access and merge in the slidebar preview of the wickr application task. The input is possible to write and the keyboard can be merged into the logged off service to compromise the local account by reseting the never lock mechanism.

The attack vector is located on the application-side of the service. The security risk of the local vulnerability is estimated as high with a cvss (common vulnerability scoring system) count of 7.0. The vulnerability requires local application access with low privileged user account and without user interaction. The vulnerability is located on the application side of the wickr app service and can be exploited in apple iOS only. Successful exploitation of the local issue allows an attacker to unauthorized execute functions inside of the wickr application.

Affected Input Form(s): (Merge!)
[+] Settings > Account > Reset Now Button
[+] Settings > ID Connections > Tap to Input > Phone & eMail
[+] Settings > Blocklist > Add User Input
[+] Settings > Auto Lock > Never Lock? Input

Required Service(s): (To Provoke Wickr Glitch)
[+] Siri

Required Device Button(s):
[+] Connection Wifi/UMTs

Lets look over the Updates!
The first denial of service issue was patched after our report arrived by preparing a better validation and parse mechanism to interpret the saved or send context through the wickr dbms. The second block list bug was resolved by a better and faster sync time and the recognize of interaction due to thus event types. All invisible saved blocked accounts become visible yet with the next login after save. The third report was resolved by a restriction define menu inside the add mask form. The fourth audio loop vulnerability that we discovered to demonstrate surveillance was resolved after one year by a re-check of the counter with the saved data. A new exception has as well been implemented to cover such incidents. The fifth "Online Offline Mode Messenger Exception Privacy Vulnerability" was resolved by several unknown updates on keyboard in task preview of active upcoming exceptions in application tasks. the last two issues was resolved by unknown updates as well during the year 2014 until 2015.

What about the fair Bug Bounty on success?
After reporting all thus vulnerabilities with large separate PDF files and extended information the wickr team was processing with the old VCP & management of the company. During the reporting the VCP left the company because of internal troubles that permanently continue. After some time we came back and asked wickr inc about the issues, after they was confirmed as valid with one duplicate. For that they told us to come back to us after all the updates are implemented. Nobody was aware of our security reports at thus time, but they was already getting resolved. Then the new representatives answered us after several requests, that they do not have any access to the reports, that we send to the official program because of internal changes. During the last 2 years, we was watching activly all the points, were we mentioned as first the vulnerabilities. All issues has been resolved until today, even the auth bypass that allowed us to read the local wickr password of the input. As far as we know nobody was able since today to read the plain input of the password without using a method to dump the data ago. In the last conversation we was asking wickr about to leave them an access to a storage were they would be able to download all data again. Since today we do still wait for the bug bounty rewards and did not receive any correct responsible answers by wickr inc itself, so we decided to uncover all thus details to the public.

At the end we would like to inform all bug bounty hunter and security researchers out there (which are not next to the defcon drinking beer to receive only a 2.000$ reward), that thus program is more fake then responsible. We did already see the same behavoir in the scene with an israelian security company connected to wickr. So, if you ask yourself about how trusted is the wickr inc 100k$ bug bounty program, you can read here the plain truth about how it runs in reality, when you have success and full score on the board by reading the master-password ;)

Bugs are most noticeable, when the bug bounty is reached, but in thus case they mainly do not want to pay off or recognize for reasons of company policy. Does not matter if the VCP confirmed the zero-day bugs ahead. At this point, we would like to draw your attention to the fact that you do not commit the same mistake by participating in such a program that does not keep self-imposed rules. Alone the fact that the VCP with all the confidental data has disappeared, should be cleaned up with our network seriously. Until today, Wickr would like to receive more new bugs from our research team which are valid and would like to pay for them. We hope that wickr inc does become responsible one day to receive the other 20 tracked zero-day vulnerabilities, which are still valid since today in queue. A good person named "Marc Rogers" one of the cloud-flare heads recommented in the public to request there responsibility on the resolved after reading there reply in a social network some month ago.

Note: The above demonstrated issues has nothing to deal with the functionality of the ios, android or windows application. All mobile bugs was exploitable in both versions and all software issues was as well located in the clients.

UPDATE: 2016-12-23