The End is Nigh?

We are not usually in the business of making bold predictions about future developments in cyber security. But recent internal discussions about WannaCry and Petya/Nyetya have got us all thinking about an entirely plausible and frankly terrifying possibility for where crypto malware could go next.

Here’s the short version:
DeathStar + basic crypto malware variant = complete encryption of the entire AD environment.

DeathStar is an extension to the Empire post-exploitation framework that was released by byt3bl33d3r in May 2017. It builds on previous tools like BloodHound to identify and automate privilege escalation within Active Directory. Basically, “push button, receive domain admin”.

DeathStar (and BloodHound) don’t rely on exploiting any actual vulnerabilities. Rather DeathStar leverages Active Directory configuration and allocation of privilege in order to find and exploit a path of domain joined systems that can be travelled, one hop at a time, in order to eventually obtain DA privileges. The BloodHound github page probably explains this approach most succinctly:
“BloodHound uses graph theory to reveal hidden relationships and attack paths in an Active Directory environment.”

Our predicted scenario plays out something like this:
1. Despite your organisation’s best efforts with security education and awareness, a low privileged user opens a malicious executable email attachment.
2. The attachment first runs DeathStar, which eventually obtains domain admin privileges.
3. Once DA has been obtained, the payload reaches out to every domain-joined Windows system and executes a crypto malware payload, as DA, on every host simultaneously.

Taking this one step further…
Couple this attack with a basic password spraying attack against Remote Desktop Services or Citrix  (or even OWA followed up with Ruler) and you remove the need for any phishing or other user interaction. One minute you’re fine – the next minute every machine on your AD has crypto malware.

So what can be done?

  1. Excellent, frequent, offline and offsite backups. Definitely NOT on local, online, domain-joined backup servers.
  2. Proactively test your Active Directory with tools like Bloodhound and DeathStar. If you can prevent these tools from achieving DA through derivative administrator relationships, chances are good that the predicted malware won’t be able to either.
  3. Use cloud-based / SaaS services where possible.
  4. Follow ‘best practice’ advice like the Top 35 / Essential 8 provided by ASD. Specifically: patch OS and applications, implement application whitelisting, use 2FA for all remote access (including OWA), limit the allocation of administrative rights, and monitor the shit out of your environment.

If this prediction eventuates it could have staggering consequences for individual organisations and possibly for the global economy. We don’t want this to happen, but it just seems like the next logical step in the evolution of crypto malware. Hopefully by highlighting the possibility we can get ahead of the curve before the risk is realised.

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 ConnX ESP HR Management System (CVE-2015-4043)

During an engagement for one of our clients we came across ConnX‘s ESP HR Management System and found that it was vulnerable to SQL Injection. In line with our responsible disclosure policy, the vendor of ConnX was contacted to advise them of the issue and they were advised that this information would be published in 90 days.

We have received an acknowledgement from ConnX in regards to this issue stating:

… we are now releasing a version of ConnX where the issue that you brought to my attention has been addressed.

90 days have now passed from our initial disclosure to ConnX, and we are publishing details of the issue.

ConnX‘s ESP HR Management system is an application designed to aid payroll management of staff in organisations. We have identified that the input validation in the username parameter of the login page was not implemented correctly as noted below:

  • Location: /frmLogin.aspx
  • Parameter: ctl00$cphMainContent$txtUserName

Exploitation of this vulnerability would allow attackers to extract the data used by the ESP HR Management System. This information includes sensitive employee personal details.

The full advisory can be found here.

Communication timeline:

  • 2015-03-25: ConnX contacted with details of vulnerability
  • 2015-04-20: ConnX replied with details about mitigation
  • 2015-06-30: Publication of vulnerability