ATutor is a web-based Learning Management System that has been in existence for a number of years and according to the information found on the vendor website, it is used by thousands of organizations. Given the relatively large user base, we decided to take a look under the hood. This was made easier in part due to the fact that ATutor is open source so anybody can perform a source code audit. This module will cover the in-depth analysis and exploitation of multiple vulnerabilities in ATutor 2.2.1. The first vulnerability we will investigate is a SQL injection that can be used to disclose sensitive information from the ATutor backend database. Once disclosed, this information can be used to effectively subvert the authentication mechanism. Finally, once privileged access is gained, we will exploit a post-authentication file upload vulnerability that leads to remote code execution.
3.2 Getting Started
Revert the ATutor virtual machine from your student control panel. You will find the credentials for the ATutor server and application accounts in your course materials. ATutor provides you with 3 levels of access:
For the purposes of this module, we will be attacking the vulnerable ATutor instance from an unauthenticated perspective, so we will not need credentials. In latter parts of the module, we will however use the appropriate credentials in order to ease the exploit development process.
3.3 Initial Vulnerability Discovery
As is always the case when we have access to the source code, we first like to just look around and get a feel for the application. How is it organized? Can we identify any coding style that can help us with string searches against the code base? Is there anything else that can help us streamline and minimize the amount of time we need to properly investigate our target?
As we were doing that, we realized that it was fairly easy to identify all publicly accessible ATutorwebpages. More specifically, all pages that do not require authentication contain the
3.4 A Brief Review of Blind SQL Injections
Before we continue, we will briefly review how traditional blind SQL injections work. As mentioned before, in a blind SQLi attack, no data is actually transferred via the web application as the result of the injected payload. The attacker is therefore not able to see the result of an attack in-band. This leaves the attacker with only one choice: inject queries that ask a series of YES and NO questions (boolean queries) to the database and construct the sought information based on the answers to those questions. The way the information can be inferred depends on the type of blind injection we are dealing with. Blind SQL injections can be classified as boolean-based or time-based.
3.5 Digging Deeper
During our source code analysis, we identified a couple of instances in which the ATutor developers used a sanitization function against user input from a GET parameter. A quick look at the PHP documentation verifies that this function should indeed escape our single tick payload, yet it didn’t.
3.6 Data Exfiltration
Before developing a method that we can use to extract arbitrary data from the database, we must keep in mind that our payloads have to avoid using restricted characters. As a reminder, here is that chunk of code again.
3.7 Subverting the ATutor Authentication
So far, we worked out a way to retrieve arbitrary information from the vulnerable ATutor database, and while that is a good first step, we need to see how we can use that information. An obvious choice would be to retrieve user credentials, but considering that modern applications rarely store plain-text credentials (sadly, it still happens), we would only be able to retrieve password hashes. This is also the case with ATutor, so even with password hashes in hand, we would still need to perform a bruteforce attack in order to possibly retrieve any cleartext account password.
3.8 Authentication Gone Bad
In the previous section, we saw that the ATutor authentication mechanism appears to hinge on a single parameter whose value is assumed to be secret. If that value can be discovered however, the assumptions of the authentication mechanism fall apart.
In fact, since the token is under our control, it turns out that our target value can be trivially calculated.
3.9 Bypassing File Upload Restrictions
While we managed to gain authenticated privileged access to the ATutor web application interface so far in this module, we are still not finished. As attackers, we try to gain full operating system access and fortunately for us, ATutor contains additional vulnerabilities that allow us to do so.
One of the more direct ways of compromising the host operating system, once we have managed to gain access to a web application interface, is to find and misuse file upload weaknesses. Such weaknesses could allow us to upload malicious files to the webserver, access them through a web browser, and thereby gain command execution ability. As this is a rather well-known attack vector, most developers write sufficient validation routines that prevent misuse of this functionality. In most cases, this means that certain file extensions will be blacklisted (depending on the technology in use) and that the upload locations on the file system are outside of the web root directory.
3.10 Gaining Remote Code Execution
Now that we have a basic understanding of this file upload vulnerability, let’s attempt to exploit it.
You likely noticed that the file is extracted under the /var/content directory. This is the defaultdirectory that is used by ATutor for all user-managed content files and presents a problem for us. Even if we can upload arbitrary PHP files, we will not be able to reach this directory from the web interface as it is not located within the web directory.
In this module, we first discovered and then later exploited a pre-authenticated blind Boolean SQL injection vulnerability in the ATutor web application.
We then deeply analyzed the ATutor authentication mechanism and discovered a flaw that, when combined with the blind SQL injection, allowed us to gain privileged access to the web application.
Finally, by leveraging this level of access, we discovered and exploited a file upload vulnerability that provided us with remote code execution.