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 describes the concept. In this post, I’ll give a mid-term update, describing the process involved and initial results. In the next post I’ll describe the full results of the security testing. I’ll try to keep my actual analysis in the final post, after I have objectively described the process and results.
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 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 functionality including role-based security.
There are two particular viewpoints that have led to my interest in this independent observer role.
- No enterprise software platform is perfect and you should always expect some vulnerabilities. The issue should not just be on whether there are vulnerabilities, but perhaps more importantly, on how a company or organization responds to a security vulnerability or incident.
- I have called for transparency from LMS vendors and open source communities, arguing that they should share information from their third-party security audits and tests.
Two aspects of the Canvas LMS are particularly relevant for this discussion.
- Canvas is a Software-as-a-Service (SaaS) platform, also known as multi-tenant platform. In this setup, Canvas is run “in the cloud” where all paying customers share the same instance of the LMS. This is the same model as Amazon, Facebook, iTunesU, as well as many of the newer LMS solutions. Because of this model, there is one deployment of software in production that customers share.
- Canvas is a commercially open source. Instructure controls and updates the code base, but the source code is freely available and can be downloaded or used by non-paying customers. Additionally, paying customers obviously have full access to see the source code.
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.
Each identified vulnerability was rated by Securus as Critical, High, Moderate, Low or Informational Purposes – in decreasing order of risk severity. Instructure uses a different system of Highly Critical, Less Critical, etc in their security advisories, but I will keep my descriptions based on the severity levels identified by Securus.
During the testing, we had conference calls roughly once a week, where I was able to participate and hear the results-to-date, questions, and general discussion. In addition to the verbal updates by phone, Securus provided an interim written update on November 16th that identified several vulnerabilities that had been identified. The draft final report was delivered on November 28th, and the final report should be published shortly.
My descriptions lag the actual testing dates to avoid publicizing vulnerabilities before there are remediations – while I am interested in transparency, there is no need to increase risk by reporting on issues that have not been addressed.
The mid-term results provided on November 16th did identify several vulnerabilities. These vulnerabilities were described in more detail in the final report, which I’ll cover in a future report, but there is one issue that is worth relating ahead of time.
The testing “identified a SQL injection attack vector in the file re-ordering capability, available in the users file area and the course/group file areas” (from the subsequent security advisory posted by Instructure). This issue was deemed by both Securus and Instructure to be Critical severity that could lead to manipulation of data, exposure of sensitive information, and privilege escalation (users gaining access to a more information and functionality than should be allowed based on their role).
Due to the critical nature of the SQL injection vulnerability, Instructure took the step of developing a fix, testing and deploying to the production server and open source code base approximately 24 hours after the mid-term report.
The mid-term update also identified three other vulnerabilities which appear to be Moderate or Low severity. I’ll describe the actual vulnerabilities and remediations in a future post.
Update: Fixed dates of testing period