Essential info on the “Essential 8”

A few days ago the Australian Signals Directorate released the new version of their document Strategies to Mitigate Cyber Security Incidents. This is the third version of this excellent guide and there are a number of obvious changes from the previous version in 2014. This year (unlike the 2014 release) ASD have chosen not to provide a summary of the key changes, so I did a quick side-by-side comparison. This post summarises the changes.

The obvious changes

There are three significant changes that have been made to this version of the document:

  1. The Top 4 is still around (and mostly the same), but now we also have the Essential 8
  2. The previous “Top 35” list of strategies is now grouped into strategies for: prevention of malware delivery and execution, limiting the extent of cyber security incidents, detecting cyber security incidents, recovering data and system availability, and preventing malicious insiders.
  3. The title has changed. The 2014 release was titled “Strategies to Mitigate Targeted Cyber Intrusions” – the new version is “Strategies to Mitigate Cyber Security Incidents”

My take on these high level changes is that the ASD seems to be aiming for the guidelines to be more widely applicable. Instead of just talking about targeted attacks, the advice is now more relevant to a wider range of cyber security incidents.
With a more cynical hat on, perhaps they are also coming to accept that no amount of guidance is going to be truly effective in preventing a targeted cyber intrusion from a well-resourced adversary.

What’s gone

The following items from the Top 35 list no longer seem to be present:

  • 19 – Web domain whitelisting for all domains
  • 32 – Block attempts to access websites by their IP address
  • 34 – Gateway blacklisting

These seem to be fair exclusions. Web domain whitelisting is a nice idea in theory, but invasive and difficult to maintain. Blocking attempts to access websites by IP address never really seemed like it would make much difference – getting a DNS record for a C&C server is hardly a difficult task.

What’s changed

The following strategies have been significantly changed, updated or merged:

  • The previous guidance / intent of “Workstation inspection of Microsoft Office files” (29) has been transformed into a new (better) strategy for protecting against malicious Office files – “Configure Microsoft Office macro settings”
  • The previous guidance for “Workstation and server configuration management” (21) has been given a more general heading of “Operating system hardening”. This new strategy also incorporates previous guidance for “Restrict access to Server Message Block (SMB) and NetBIOS” (27).
  • “Enforce a strong passphrase policy” (25) is now incorporated into a much broader “Protect authentication credentials”.
  • The verbosely-titled strategies “Centralised and time-synchronised logging of successful and failed computer events” (15) and “Centralised and time-synchronised logging of allowed and blocked network activity” (16) have been rolled up into “Continuous incident detection and response”
  • Elements of “Centralised and time-synchronised logging of successful and failed computer events” (15) have also made their way into the new strategy for “Endpoint detection and response software”.

These updates, changes and merges all seem to make a lot of sense. Personally, I would have taken this even further – I think there are more opportunities to reduce the overall number of strategies by rolling-up similar or related guidance. For example, in the strategies to prevent malware delivery and execution section we have “User application hardening” and “Configure Microsoft Office macro settings” – I would argue that the latter is a subset of the former.

What’s new

Perhaps the most interesting aspect of this year’s version of the document are the new entries to the list:

  • “Hunt to discover incidents” (Mitigation strategies to prevent malware delivery and execution). This is an excellent recommendation, and it is almost baffling that this wasn’t explicitly required in previous years.
  • “Personnel management” (Mitigation strategy specific to preventing malicious insiders)

And the following three new entries under “Mitigation strategies to recover data and system availability”:

  • “Daily backups”
  • “Business continuity and disaster recovery plans”
  • “System recovery capabilities”

These last three really underline ASD’s apparent change in thinking for this year’s release – instead of just being about ‘keeping the bad guys out’, this new guide better aligns to a ‘Prevent – Detect – Respond – Recover’ incident response approach.

Closing thoughts

  1. It is great that ASD produce this guide and make it publicly available. I believe that the guidance is sound and mostly I would agree with the assigned ratings for effectiveness, impact, cost, etc.
  2. I am not a huge fan of the new groupings for the strategies. I think that this may be confusing for casual readers and non-industry types. I am concerned that a customer might work their way down the “prevent” list from top to bottom, while completely ignoring the essential strategies from “limit” and “detect”. It would be nice for ASD to release the recommendations in a format that facilitated sorting by different attributes.
  3. It is good to see the guidance updated in a way that addresses changes to the threat landscape, changes to current attack patterns, changes to defensive technologies (and technology capabilities).

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

Bash bug will leave you shell shocked.

A vulnerability has been found in the Bash Unix shell. The vulnerability arises from a bug in the way that Bash processes environment variables. If an attacker is able to pass environment variable content to a network service that calls bash, they may be able to achieve arbitrary remote code execution on the target system.

This has potentially severe implications for any network service that runs bash as an interpreter.

  • CGI scripts on web servers can be leveraged to achieve remote code execution through HTTP requests.
  • Systems running SSH may also be vulnerable. By leveraging AcceptEnv, TERM or SSH_ORIGINAL_COMMAND environment variables, remote code execution may be achieved on affected systems.
  • Other network services may also be impacted (e.g. SMTP servers)

This has widespread severe security implications, as potentially any Linux/Unix system can be compromised remotely.

WHAT CAN YOU DO:

  • Upgrade bash on all Linux/Unix systems immediately
  • Temporarily firewall any Internet-facing SSH servers or web servers running shell-based CGI scripts until the bash patch can be applied.
  • For appliances, software appliances and embedded systems, contact the vendor to seek advice about patching.
  • Cry softly into your pillow
  • Run away from your job
  • Hit the pub.

More to follow…