Making Wickr Weaker

As part of Asterisk’s new mobile application security assessment service offering, we decided to use our acquired skills and research a high profile mobile app. Luckily, Malcom Turnbull helped us with the decision making process by confirming that he uses Wickr to keep his messages private.

For those who are not familiar with the app, it is a messaging platform that is prioritises privacy above all costs. The app has been through rigorous security assessments where the results are published on their website. Additionally, some of the research that was performed was presented at DEF CON 21.

This gave us an extra adrenaline boost knowing that the challenge was not going to be easy. To get to the juicy part, we reported two interesting vulnerabilities to Wickr that we found within version 2.5.2 (iOS) which was the most recent version at the time of initial contact (May 2015). It is important to note that we did not look at the Android version and so there may be applicable information or crossover to the Android app as well.

  • Vulnerability #1: Session Lock Authentication Bypass

Wickr has a built-in ‘Auto Lock’ feature that allows a user to set a time period before they are required to enter their password to the application. By default, the timeout value is 1 hour, however, a user can change that value to 5 seconds, which would appear to be an even more secure option. The screenshot below shows the ‘Auto Lock’ feature within Wickr’s settings view:

autolockOnce the app is moved into the background and then reopened (after the time set in the ‘Auto Lock’ functionality has exceeded), the user is required to re-enter their password to access the application. The ‘Session Lock’ view can be seen in the screenshot below:

sessionlock

‘SessionManager’ is the class that controls the session lock and implements various methods, for example:

• -(void)sucessfullyResumedSession
• -(BOOL)unlockSessionWithPass:(id)pass

It was observed that the ‘sucessfullyResumedSession’ method was called after the ‘unlockSessionWithPass’ method, under the condition that the password was confirmed to be correct. It was also observed that when ‘sucessfullyResumedSession’ is called, the ‘Session Lock’ view is removed and the user is granted normal access to the application including the sensitive data it holds.

With this in mind, if a reference to the current ‘SessionManager’ object is obtained, it is possible to invoke the ‘sucessfullyResumedSession’ method and therefore bypass the authentication requirement, gaining access to the user’s sensitive data.

The figure below demonstrates how the authentication can be bypassed, with the aid of Cycript on a jail broken device:

auth_bypass

The screenshot below shows the access gained from the steps above:

auth_bypass

  • Vulnerability #2: Persistent Sensitive Information Stored Unencrypted within the App’s Memory Space

Wickr’s authentication mechanism requires the user to input their password before gaining access to their sensitive information. It is assumed that once authentication is successful the password is no longer required for the application to function properly. This is thought to also be the case when the application enters the background as well as when the user is logged out completely.

While using the application it was observed that the password used for authentication remained in the application’s memory space in clear-text.
The authentication view is controlled by the ‘UserLogin’ class, which contains various properties, one of them, for example, is:

• UITextField* passBox

The ‘passBox’ property is used by the ‘UserLogin’ view controller to store the password entered by the user to authenticate. The following screenshot shows the ‘UserLogin’ view and the ‘passBox’ text field:

login

After the user authenticates successfully, the application seems to dereference the ‘UserLogin’ view controller, however, the data that the object holds was not overwritten. By writing the heap memory space of the application into a file and extracting strings from the file it is possible to recover the clear-text password. This process holds effective also when the user has explicitly logged off from the application with the application running inactive in the background.

The following figure shows the process of writing the heap memory into files by using heapdump on a jail broken device:

heapdump

For Proof-of-Concept purposes, a string that is known to be part of the password was searched within the written files. The highlighted portion is the legitimate password:

grep

For further details please refer to our advisories here and here.

Communication timeline:

  • 01/05/2015: Vulnerabilities were reported to Wickr
  • 08/05/2015: Asterisk requested reception to be confirmed
  • 08/05/2015: Wickr confirmed reception
  • 01/07/2015: Asterisk reminded Wickr of the disclosure date
  • 10/07/2015: Wickr confirmed the advisory reviewing process
  • 31/07/2015: Asterisk reminded Wickr of the disclosure date and offered additional week
  • 11/08/2015: Wickr confirmed that the advisory is still undergoing a review
  • 13/08/2015: Asterisk requested an update
  • 13/08/2015: Wickr acknowledged the bug  and offered $2000 reward
  • 13/08/2015: Asterisk sent banking details
  • 18/08/2015: Wickr requested to be given up to 6 more months to fix the issues
  • 18/08/2015: Asterisk asked to clarify the reasons for the requested additional time
  • 22/08/2015: Wickr responded with the reasons for the delay and clarified that only one bug (RAM) was acknowledged as the other one (authentication bypass) was already reported on the 16th of January, 2014
  • 24/08/2015: Asterisk notified Wickr that it forfeits the Bug Bounty Reward and will publish the advisories

 

Vulnerability Disclosure: Local Privilege Escalation through Trend Micro OfficeScan

Although we enjoy offensive work, we appreciate defensive work just as much. In this post we’ll discuss how we managed to escalate our privileges on a Windows host while performing a SOE assessment.

Focusing specifically on our assessment, we spotted that our client did not skip on the installation of an Anti-Virus program, in our case Trend Micro OfficeScan version 11.1. Normally these kind of programs run as a Windows service in the context of the most privileged user (SYSTEM). Looking closely at OfficeScan’s file permissions revealed that the executable file used to be loaded as the service upon system start-up was writeable by the ‘Everyone’ group.

The reason the file permissions were not secure is due to an installation feature. In short, during the installation process, administrators are asked if they want to install the Anti-Virus using a ‘normal’ or ‘high’ security setting. Administrators who chose the ‘normal’ setting unknowingly provide the option for normal users to escalate their privileges on the host.

Exploitation of this configuration is fairly simple and straight forward. For all intents and purposes the following 3 steps were followed:

  1. Reboot the Windows system into Safe Mode so that the OfficeScan processes are not running.
  2. Overwrite the ntrtscan.exe (Real Time Scan Service) executable with a malicious executable of your choosing. In our instance, we used a windows service template file and added a few commands which will attempt to create a new local user account and added it to the Local Administrators group.
  3. Reboot the Windows system. During start-up, the Real Time Scan Service executable is started, executing the malicious payload.

For further details please see our advisory or Trend Micro’s advisory.

Communication timeline:

  • 16/04/2015: Vulnerabilities were reported to Trend Micro
  • 16/04/2015: Trend Micro confirmed reception of advisory
  • 30/04/2015: Trend Micro did not confirm vulnerability
  • 05/05/2015: Asterisk asked for disclosure permission
  • 05/05/2015: Trend Micro confirmed reviewing the advisory
  • 14/05/2015: Trend Micro confirmed vulnerability and requested to hold disclosure until July, 10
  • 14/05/2015: Asterisk confirmed disclosure date
  • 04/06/2015: Trend Micro requested a change of disclosure date to August, 4
  • 10/06/2015: Asterisk confirmed updated disclosure date
  • 03/08/2015: Asterisk reminded Trend Micro of the disclosure date
  • 04/08/2015: Trend Micro requested a change of disclosure date to August, 7
  • 04/08/2015: Asterisk confirmed the updated disclosure date
  • 07/08/2015: Disclosed by both parties