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

Intra-Cloud App Disruption Risks

Automating application deployments into the ‘cloud’ is not always as simple as it should be. Depending on how you approach this problem, you may need to delegate access to components that may increase the risk of unauthorised changes. If you’re doing this in Amazon Web Services (AWS) you may have heard of CodeDeploy. CodeDeploy is one of the methods AWS has to push application code into their cloud environment. AWS has a number of mechanisms to control and limit what actions can be performed by administrators, and by compute-instances themselves. Unfortunately, not all of the AWS systems allow granular control, and may leave your applications exposed.

Auto Scaling is one of these AWS subsystems that can be used to assist with automating application deployments. Unfortunately, Auto Scaling’s access control mechanisms do not allow granular resource restriction. The risk introduced is, if you delegate Auto Scaling permissions to AWS resources, they can make changes to ALL of your Auto Scaling settings across your entire account.

The rest of this article will cover the following:

  • How CodeDeploy works;
  • What AWS Identity and Access Management (IAM) configurations are required;
  • How to deploy apps into AWS with CodeDeploy;
  • How to integrate load balancers into your deployment;
  • The risks this introduces; and,
  • How to manage these issues.

Continue reading Intra-Cloud App Disruption Risks

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…

Say ‘Hi’ to the SAMM Self Assessment Tool

Asterisk are happy to be releasing their first public beta of the SAMM Self Assessment Tool, or SSA. One of our favourite OWASP projects is the OpenSAMM project, and for those who haven’t seen OpenSAMM before, it is a framework to help organisations to evaluate their current software security practices, and build measurable targets and plans for improving these practices.

Part of OpenSAMM includes conducting assessments (you can’t manage what you can’t measure right?). The OpenSAMM methodology categorises these assessments as either Lightweight or Detailed. SSA aims to provide a very simple way to perform this Lightweight assessment, and compare your current status with some pre-canned target states. And literally, that’s it.

We’ve used this tool on a number of engagements to quickly gauge where an organisation is, and it’s certainly helped with figuring out the ‘current state’ of an organisations software security maturity.

There’s currently two different ways you can use SSA:

  1. You can visit https://ssa.asteriskinfosec.com.au/ and complete the checklist directly. You don’t even have to save your assessment anywhere if you don’t want. On the other hand, if you want to store your results, there’s a few ways to do that, such as in your cookies or online in a database. For online storage you need to Sign Up, either with a username and password (please don’t re-use your passwords folks), or you can sign in with a Google account too.
  2. Clone a copy of the Rails app and spin it up somewhere locally. We recognised quite early on that some organisations may feel uncomfortable with tracking this sort of information on the Internet, so, if you have the capability, sure, feel free to clone the repository locally and do what you wish.

SSA is being released under an MIT license, and our intent is to give it back to the OWASP community for further enhancements. We have a high level list of proposed features available on the GitHub page, but currently they’re being developed on a ‘When Christian Has Time and is Sober’ timescale. SSA forms part of our Toolkit, of which we’re slowly publishing other tools and utilities too. So watch this space!

As always, we’re really interested in your feedback, queries, concerns, issues. So feel free to send us queries via @asteriskinfosec or as Issues on the GitHub project.