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

Information Security Root Causes

We do a lot of technical security testing at Asterisk, and this often brings up healthy discourse on the root cause of issues found. After thinking about this for a while I came up with a few themes which I think probably capture the majority of security issues. In fact, I think the following issues are possibly the root-cause problems that most information security professionals are trying to manage when protecting their organisation’s information. This management of issues is an important factor, as most people can’t manage threat agents. Unless you’re a government or other high-level entity, it’s unlikely you will be able to take action against attackers sitting somewhere on the other side of the world. These issues are not mutually-exclusive, but I do like the way it feels like a fairly manageable set of problems to solve.

Most of the issues we deal with as information security professionals come down to:

  1. Insecure software
  2. Misconfigured software
  3. People-related issues*
  4. Physical security issues

Surprised? Not really.

*nb: It’s important to note that these root-causes are often interrelated. Insecure or misconfigured software certainly relates to people-issues as well as other underlying issues. This interrelationship is important, but the distinction can be useful in breaking down how to address these problems.

Let us try and analyse these causes. Most of the layers of defence that organisations are applying to try and protect their assets are there to reduce attack surface area. In the case of web-based technology, we have firewalls, IDS / IPS, WAF and other related technical controls attempting to manage and reduce the likelihood that insecure or misconfigured software is exploited. If the layers of defence, and the system itself, have addressed insecure software issues, misconfiguration issues and was physically secure, it’s likely that any further exploitation is related to weak passwords, or passwords being disclosed through alternative system breaches (Take the LinkedIn breach for example).

Weak passwords are an example of a security issue that relates to both insecure software and people-related issues. More secure software may force users to use long, difficult to remember passwords. Unfortunately, if the credential is written down, or shared with someone else, then it doesn’t matter if it’s a strong password. In these particular instances, educating the user of better password practices may help.

Of the above issues, the people-related ones are often the more difficult to manage. Social engineering has proven itself an effective tool in an attacker’s arsenal over and over again, and even if you train your people, it’s difficult to reduce the exposure the same as you would with other issues. Whether this is due to the difficulty of educating the masses to social engineering, or that many information security professionals aren’t as good at addressing people-issues compared to technical-issues we can’t really say.

This list is not all that different from MITRE’s Common Attack Pattern Enumeration and Classification (CAPEC) ‘Domains of Attack’. Below is our root-causes, with the various CAPEC domains:

Root-cause CAPEC Domain
Insecure software Communications
Software
Supply Chain*
Misconfigured software Communications
Software
Supply Chain*
People-related issues Social Engineering
Supply Chain*
Physical security issues Communication (partially)
Hardware
Physical Security
Social Engineering
Supply Chain*

*nb: Supply chain relates to insecure or misconfigured software, people related issues or physical security weaknesses further up the supply chain.

Okay, so if we have these root causes, what can we do about them? Our subsequent blog posts will look at each of these root causes in further detail.

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…

TrueCrypt Fallout: Early hours

It may appear that 2014 is shaping up as ‘Year of the Crypto Catastrophe’. Closely following Heartbleed we are now monitoring the unfolding and curious events surrounding the sudden shutdown of the TrueCrypt project.

TrueCrypt (or TC) has long been a ‘go to’ open source encryption solution to provide a quick solution for protecting data.

Whilst details are very sketchy, it would appear that the TC binaries have been updated to only allow reading from TC volumes, with a warning that TC is no longer safe.

Asterisk’s recommendations at this point are:

  • Do not download or update TC right now! (version 7.1a seems to be the most recent version released before the current incident)
  • Determine your organisation’s current exposure: assess usage of TC, search for any TC volumes in your fleet (note that TC volumes can be hidden)
  • Take steps to ensure any data secured by TC is backed up in a manner which ensures you can recover the contents
  • Assess your data encryption requirements: why are you using crypto, what are you protecting data from (casual observer, laptop/drive theft, targeted information theft), what platforms & what functionality is required?
  • Assess alternate solutions, and prepare a strategy to move
  • Determine the appropriate trigger and time frame for your organisation to change encryption solution

Until more concrete facts emerge, we have captured some of the timeline of this very intriguing story as it unfolded.

Approximately 5 hours ago (3:30am West Australian Time) this tweet landed:

https://twitter.com/FredericJacobs/status/471735604883890176

thegrugq then provides an archive of the page:

https://twitter.com/thegrugq/status/471741930271809536

Some information about the new binary that is available on the TC website lands:

https://twitter.com/runasand/status/471741572909133824

Speculation about what’s going on starts to happen:

https://twitter.com/matthew_d_green/status/471741836722073600

and investigation around what actually got uploaded starts:

https://twitter.com/cynicalsecurity/status/471742274742013952

The investigation continues:

https://twitter.com/DefuseSec/status/471742363212083200

Another diff:

https://twitter.com/cynicalsecurity/status/471743401361436674

Confirmation that the new binaries were signed by the real PGP key:

https://twitter.com/hdmoore/status/471744014069145600

https://twitter.com/hdmoore/status/471744014069145600

What happens when you try to install the new TC:

truecrypt-9-runasand-2

https://twitter.com/runasand/status/471744625690951681

xabean links to github to better highlight the changes:

https://twitter.com/xabean/status/471746558703448064

Archer has some great advice:

https://twitter.com/ArchrOnSecurity/status/471751244609257472

News articles begin:

http://www.pcworld.com/article/2241300/truecrypt-now-encouraging-users-to-use-microsofts-bitlocker.html

Confirmation on the new functionality:

https://twitter.com/runasand/status/471771828130963456

Luckily, thegrugq already gave us information about TC alternatives:

http://grugq.tumblr.com/post/60464139008/alternative-truecrypt-implementations

https://twitter.com/McGrewSecurity/status/471789973398507522

and now the speculation has started:

https://gist.github.com/ValdikSS/c13a82ca4a2d8b7e87ff

With an interesting  line in the new 7.2 code pointed out by a guy on IRC:

https://github.com/warewolf/truecrypt/compare/master…7.2#diff-889688bf127e7a198f80cbcec61c9571L16

Now, this is still early days, so we’re expecting this news to change as more information starts to surface.

 

UPDATE:

KrebsonSecurity did an interview with Matthew Green (the guy who is heading the audit project for TrueCrypt) and had some additional information.  He still plans to continue the audit.

http://krebsonsecurity.com/2014/05/true-goodbye-using-truecrypt-is-not-secure/

UPDATE 2:

And looks like this is the best explanation we are going to have around the TrueCrypt situation:

https://twitter.com/stevebarnhart/status/472192457145597952

https://twitter.com/matthew_d_green/status/472193658842673152

https://twitter.com/stevebarnhart/status/472193800874758144

https://twitter.com/matthew_d_green/status/472194641136087040

https://twitter.com/stevebarnhart/status/472195239005147136

https://twitter.com/matthew_d_green/status/472198235679764481

https://twitter.com/stevebarnhart/status/472198615579234304

https://twitter.com/matthew_d_green/status/472198897058590721

https://twitter.com/stevebarnhart/status/472200184433483776

https://twitter.com/stevebarnhart/status/472200478345150464