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

Vulnerability Disclosure: SQL Injection in Flash Page Flip

During an engagement for one of our clients we came across Flash Page Flip and found that it is vulnerable to SQL Injection. As per our responsible disclosure policy, the creators of Flash Page Flip were contacted to advise them of the issue.

90 days have passed since our initial communication, and we have received no further response. SQL injection is not a new topic. To be more precise, it is a 20th century bug which is supposed to be long gone. The reason we decided to pursue this vulnerability officially (CVE-2015-1556 and CVE-2015-1557) is due to the apparently wide spread use of this application.

googlin

The lack of input validation was noticed across the majority of Flash Page Flip’s code and affected multiple pages such as:

  • NewMember.php
  • GetUserData.php
  • SaveUserData.php
  • DeleteUserData.php
  • /xml/Pages.php

In other instances weak input sanitisation functionality was implemented, before the SQL query was sent to the backend database. Some of the affected pages are listed below:

  • /admin/EditSubCat.php
  • /admin/ViewPage.php
  • /admin/AddMag.php
  • /admin/AddCat.php
  • /admin/EditCat.php

Exploitation of this vulnerability could allow attackers to extract the data used by Flash Page Flip which may be considered not sensitive. However, Flash Page Flip could also be used as a plugin to other CMS platforms and therefore may share the same database, as it happened during our engagement. In this case, SQL Injection may result in exposure to more sensitive CMS data, including credentials.

The full advisory can be found here.

Communication timeline:

  • 27th Jan 2015 – Contacted vendor with initial disclosure
  • 10th Feb 2015 – Contacted vendor with CVE identifiers
  • 29th Apr 2015 – Vulnerability published

Fuzzing and Sqlmap inside CSRF-protected locations (Part 2)

– @dave_au

This is part 2 of a post on fuzzing and sqlmap’ing inside web applications with CSRF protection. In part 1 I provided a walkthough for setting up a Session Handling Rule and macro in Burp suite for use with Burp’s Intruder. In this part, I will walkthrough a slightly different scenario where we use Burp as a CSRF-protection-bypass harness for sqlmap.

Sqlmap inside CSRF

A lot of the process from part 1 of the post is common to part 2. I will only run through the key differences.

Again, you’ll need to define a Session Handling Rule, containing a macro sequence that Burp will use to login to the application, and navigate to the page that you need.

The first real difference is in the definition of scope for the session handling rule. Instead of setting the scope to “Intruder” and “Include all URLs”, you’ll need to set the scope to be “Proxy” and a custom scope containing the URL that you are going to be sqlmapping.

screenshot11

There is a note to “use with caution” on the tool selection for Proxy. It is not too hard to see why – if you scoped the rule too loosely for Proxy, each request could trigger a whole new session login. And then I guess the session login could trigger a session login, and then the universe would collapse into itself. Bad news. You have been warned.

Once the session handling rule is in place, find an in-scope request that you made previously, and construct it into a sqlmap command line.

screenshot12

screenshot13

In this example, I’m attempting an injection into a RESTful URL, so I’ve manually specified the injection point with “*”. I’ve included a cookie parameter that defines the required cookies, but the actual values of the cookies is irrelevant, since Burp will replace these based on the macro.
If it was a POST, you would need to include a similar –data parameter to sqlmap, where Burp would replace any CSRF tokens from hidden form fields. Finally, we have specified a proxy for sqlmap to use (Burp).

Running sqlmap, we start to see it doing it’s thing in the Burp Proxy window.

Screenshot a

That’s pretty much all there is to it.

One catch for the Session Handling Rule / macro configuration is that there isn’t a lot of evidence in the Burp tool (Intruder, Proxy, …) that anything is happening. If you are not getting the results that you would expect, the first thing to check is the Sessions Tracer, which can be found in the Session Handling Rules section. Clicking the “Open sessions tracer” button opens the Session Handling Tracer window. If a session handling rule is triggered, the actions for that rule will start to show up in the Tracer window. You can step through a macro, request by request, to see that everything is in order.

screenshot b

Conclusion

In this two part post, I’ve walked through setting up Burp Suite to do fuzzing inside CSRF-protected applications, both with Burp’s own Intruder tool and using an external tool (sqlmap).

Fuzzing and sqlmap inside CSRF-protected locations (Part 1)

– @dave_au

Hi all, David here. I was recently testing a web app for a client written in ASP.NET MVC. The developers are pretty switched on, and had used RequestValidation throughout the application in order to prevent CSRF. Further to this, in several locations, if there was a RequestValidation failure, they were destroying the current session and dropping the user back to the login form. Brutal.

I didn’t think that there would be any injection issues in the app, but I needed to test all the same and this presented an interesting challenge – how to fuzz or sqlmap on target parameters within the CSRF-protected pages of the application.

If I opted for a manual approach, the process would look like this:

  1. Login to the application
  2. Navigate to the page under test
  3. Switch Burp proxy to intercept
  4. Submit and intercept the request
  5. Alter the parameter under test in Burp, then release the request
  6. Observe results
  7. Goto 1

This would be incredibly slow and inefficient, and wouldn’t really provide a way of using external tools.

I scratched my head for a while and did some reading on Buby, Burp Extender and Sqlmap tamper scripting until I finally came across an article from Carstein at 128nops which led me to further reading by Dafydd on the Portswigger Web Security Blog. Turns out that Burp suite can do exactly what I needed, out of the box, so I thought I’d put together a step-by-step for how I solved the problem.

Fuzzing (with Intruder) inside CSRF

Note: Intruder has built-in recursive grep functionality that can be used in some circumstances to take the CSRF token from one response and use it in the following request (&c.)[1]. This wasn’t much good to me, since the session was being destroyed if CSRF validation failed.

In Burp terminology, you need to create a Session Handling Rule to make Intruder perform a sequence of actions (login, navigate to page under test) before each request.

Go to the “Options” tab, and select the “Sessions” sub-tab. “Session Handling Rules” is right at the top.

screenshot1

Click the “Add” button to create a new Session Handling Rule. The Session Handling Rule editor window opens. Give the rule a meaningful name, then click the “Add” button for “Rule Actions” and select “Run a macro” from the drop-down.

screenshot2

This opens the Session Handling Action Editor window…

screenshot3

In this window, click the “Add” button next to “Select macro:”. This opens the Macro Editor and Macro Recorder windows (shown a further on). Now that Burp is set up and waiting to record the sequence, switch over to your web browser. In a new window / session (making sure to delete any leftover session cookies), navigate to the login page, login, then navigate to the page within the application where you want to be doing fuzz testing. Once you are there, switch back over to Burp. The Macro Recorder should show the intercepted requests.

screenshot4

Select the requests that you want to use in the macro and click “OK”. This will close the Macro Recorder window.

screenshot5

In the Macro Editor window, give the macro a meaningful name and look through the “Cookies received”, “Derived Parameters” and “Preset Parameters” columns to check that Burp has analysed the sequence correctly. When you’re happy, you can test the macro out by clicking the “Test Macro” button. If everything looks alright, click “OK” to close the Macro Editor window.

screenshot6

Almost there.

Back in the Session Handling Action Editor window, you should be OK to leave the other options for updating parameters and cookies as-is. Click “OK” to exit out of here.

Now, back in the Session Handling Rule Editor window, you’ll see your macro listed in the Rule Actions…

screenshot7

Before you close this window, switch over to the “Scope” tab and alter the scope for the rule to be just for Intruder and “Include all URLs”. (If you want to be more specific, you could specify the URL that you wanted the rule to apply to, but I just put it in scope for all of Intruder, and remember to turn the rule off when I’m not using it. This becomes more important in Part 2 of this post.) Then close the Session Handling Rule Editor window.

screenshot8

Your session handling rule is now defined.

Next, go back over to Burp’s proxy and send the request that you want to fuzz over to Intruder in the usual way.

screenshot9

In Intruder’s “Position” tab, you’ll want to clear all of the injection points except for the one that you want to specifically fuzz test. Session cookies and any CSRF tokens (in cookies or hidden form fields) will be populated automatically by Intruder from the macro sequence.

screenshot10

Set your payloads and other options as required. If the application is sensitive to multiple concurrent sessions for the same user, you will need to reduce the number of threads to 1 in the “Options” tab.

Then start Intruder. You will almost certainly notice that Intruder runs slowly; this is to be expected when you consider that it is going through a new login sequence for each request.

To fuzz different parameters on the same page, just go back into “Positions” and choose the next target.

To fuzz parameters on a different page, you will probably need to go back into your Session Handling Rule and edit your macro (or define a new macro) that logs in and navigates to the new target page.

In part 2 of this post, I’ll step through a slightly different scenario where we use an external tool (sqlmap), proxied through Burp, with a Session Handling rule running on Burp’s Proxy.