Instructure has engaged Securus Global to test the Canvas LMS product for security vulnerabilities. Instructure has also invited me to be an independent observer – participating in the process and independently reporting on the testing and Instructure’s response to any vulnerabilities identified. Part 1 of this series of posts described the concept. Part 2 gave a mid-term update, describing the process involved and initial results. In this post I’ll describe the full results of the security assessment. I’ll add my actual analysis in the final post.
The purpose of the testing was to validate and review the Canvas LMS design and implementation with respect to vulnerabilities that could be exploited by a motivated hacker. Securus employed security experts to ethically hack, both manually and with automated tools, a test environment to try and identify specific vulnerabilities, working from the perspective of both an unauthorized user and an authorized user. There was a range of exploits tested, but the basic idea is to find out if someone could access information or functionality that should be protected by system controls including role-based security.
Summary of Findings
The findings were presented to Instructure on November 29, 2011 in report form and with a conference call to discuss.
As described in my 2nd post:
The testing took place from approximately November 7 – 25, 2011. During this timeframe, Securus had full access to the test environment, including access to the LMS source code (not only the officially open source code, but also the closed source plugins where needed). Additionally, Securus requested and had access to certain system error log files. The source code and error logs could be useful to identify hidden attack pathways.
As expected, Securus did find a number of security vulnerabilities. Each vulnerability is rated by Securus in decreasing order of perceived risk as Critical, High, Moderate, or Low. This risk is based on assessment of the likelihood and consequence of particular vulnerabilities being exploited. As stated in the assessment report:
Securus Global follows the International Standards ISO 31000 and ISO 31010 for risk identification, classification and assessment.
Based on this ISO-based classification, the risk assessment found 10 vulnerabilities – 1 critical, 1 high, 4 moderate and 4 low severity – in the Canvas LMS system.
As of December 10, Instructure has already addressed and remediated 5 of these 10 vulnerabilities, including the critical and the high items. Additionally, 2 fixes have been developed and are scheduled to be put into production by the end of December, and 3 fixes remain open and under investigation. As mentioned in the part 2 post, the critical SQL Injection vulnerability was addressed and remediated within 1 day – see this security advisory for details.
The table below summarizes the results.
In the risk assessment report, Securus included details on each of the vulnerabilities discovered during testing. These details included a full description of the vulnerability, likelihood of exploitation, impact to the system, reproduction details, and recommendations to address the vulnerabilities. For security reasons, I am not going to describe these details publicly.
Nature of Vulnerabilities
As part of the review, Securus provided feedback to Instructure not just on the specific findings, but also on the pattern of findings. Keep in mind that Canvas LMS is open source, allowing testers access to system design and code. According to the Securus report:
It is our impression that CANVAS is generally a secure application and that the issues found can quickly be remediated. CANVAS is built upon a foundation of very widely used programming frameworks that have been subject to extensive security auditing.
During testing several issues were identified, including one critical vulnerability. Due to progressive reporting and status updates with Instructure the critical vulnerability identified was promptly remediated and released to users.
The remaining issues present a moderate risk to the integrity and confidentiality of the stored data which could lead to reputational damages and loss of confidence in the CANVAS system should they risk be realised. None of these issues are associated with major application flaws that are difficult to remediate.
It was not always straightforward, however, on how Instructure should fix each issue. The biggest challenge seemed to be balancing the need for security with the need for usability for Instructure’s customers. For example, on the Arbitrary File Upload vulnerability Instructure was initially hesitant to directly follow the recommended remediation of forcing all conversation file attachments to be downloaded by the browser rather than displayed in-line. The reason for the recommendation is to avoid phishing attacks, but there was a competing issue of customer expectations to see attachments in-line. After internal discussions, Instructure evaluated that users do not have the same expectations for in-line viewing conversation file attachments as they do for wiki pages and course modules; furthermore, the risk of phishing attacks in greater for conversations. Based on this internal discussion, Instructure is now in the midst of directly implementing the recommended change.
Although the report did not identify any major design flaws, there is one vulnerability that could lead to extensive changes to the Canvas code base. This involves the No Access Controls for Uploaded Files vulnerability, and according to Instructure the remediation will likely involve adding timeouts to the signed URLs. Simple changes, but extensively applied.
Next Steps
For the Canvas community, updates to the remaining security fixes will be provided through security advisories on the Instructure web site.
For me, I’ll add my analysis in a separate post, in order to allow the reported results to stand by themselves.
