This report presents the results of our first principles vulnerability assessment of the OAuth portal for MyProxy.
No design flaws were found in version 1.0.5 of the MyProxy OAuth portal. Two implementation defects were found that could lead to vulnerabilities, both in the registration servlet component:
Two minor missing functionality bugs, one in the approver tool and one in the authorization login page, were also identified.
The rest of this report is divided as follows. The first section discusses these vulnerabilities in more detail. The next sections present details of the vulnerability assessment showing the artifacts of the architectural, resource, privilege and component analyses. The final two sections discuss recommendations, including fixes to the missing functionality bugs, and provide some insight into factors that prevented problems in MyProxy's OAuth portal.
The registration servlet allows anyone to add a potential but not yet
authorized client to the
data stores—sending an email to the designated operator with each
submission—potentially allowing an attacker to
fill unbounded amounts of storage on the server side with bogus entries, as
prospective clients never expire.
Cleanup from such an attack could prove cumbersome, depending on how easy it is to distinguish between legitimate entries that had not yet been approved and bogus entries submitted by the attacker. The command line approver tool has no functionality for removing an entry from the data stores and is not suited for displaying large numbers of entries; the clean up would need to be performed with manual SQL queries or file system traversal commands.
Standard techniques for protecting forms from abuse—for instance, captchas, images containing letters and numbers that are difficult to discern by automated means—should suffice to mitigate this issue. The command line client should also be augmented with the ability to remove an entry from the store of potential clients, and with better filtering capabilities for large data stores.
Because science gateways must be manually approved, such an attack could not succeed without failure on the part of the operator to notice the attempted script injection. The probability of this depends entirely on who is able to approve gateways—if the operator does not have a strong technical background they may respond to social engineering pressure to approve a malicious registration entry.
The registration servlet should validate and sanitize all of the fields on the registration form. Further, anything included in a web page that came from an outside source should always be properly escaped.
The OAuth portal for MyProxy consists of a single Tomcat webapp, a package format used by Tomcat which includes servlets—Java classes, each of which provides the functionality for a single "page" of the webapp—along with Java libraries, web page templates, and general webapp configuration files. Site administrators must provide further configuration after the webapp is unpacked, pointing it to a configuration file that specifies the MyProxy server to be used, the locations of log files and email message templates, and the data stores used for communication between servlets. Tomcat must also be correctly configured to use SSL in order for the OAuth portal webapp to be be used. A command line tool to change the approval status of client science gateways is also provided but is not strictly necessary.
The OAuth portal acts as a front-end to a MyProxy server, allowing a client party (in this case, a science gateway) access to the credentials a user has stored on the MyProxy server without requiring that client have access to the user's MyProxy login information. The portal follows the OAuth 1.0a protocol, allowing the user and the science gateway to safely collude in such a way that the user supplies their login information only to the portal, the portal performs a MyProxy GET operation, and, if this operation is successful, the portal then allows the client to retrieve that MyProxy certificate in question.
The MyProxy server itself does not need to be aware of the OAuth portal, and behaves a described at http://research.cs.wisc.edu/mist/papers/myproxy_vuln_assess.html. Tomcat itself is a widely-used open source server for Java servlets, developed by the Apache Software Foundation; it can function as a stand-alone web server or can be integrated with Apache or another web server. Tomcat insulates the OAuth portal from concerns over handling HTTP requests or compartmentalizing unrelated sessions. This assessment did not look for vulnerabilities in MyProxy, Tomcat, or the Java runtime.
The MyProxy OAuth server uses the RSA-SHA1 OAuth signature method, which uses pre-exchanged public keys to assure message integrity. Additionally, all OAuth traffic is sent over HTTPS. The sequence of OAuth messages is shown in Figure 1. Each request from the client science gateway to the OAuth portal identifies itself with the gateway's client ID (called the consumer key in official OAuth terminology, though this name is misleading in the presence of RSA keys), is signed with the client's private key, and expects to receive a token (a nonce generated by the OAuth portal) in response. The user's web browser communicates with both the science gateway and the OAuth portal; switching between these parties occurs when one party forwards the browser to the other party. Other interactions between the user and the science gateway, including whatever interactions triggers the beginning of an OAuth session, are not part of the protocol and left to the discretion of the science gateway in question.
An OAuth session that has not yet been successfully authenticated is identified with a temporary token. The user's browser is forwarded to the OAuth portal's authentication address with this token as a parameter; there the user is served a login page displaying information about the client that has requested access to the user's credentials. If the user then logs in successfully—accomplished by sending the provided username and password to the MyProxy server—the user's browser will be redirected back to the callback address provided by the gateway when it began the OAuth session, to which will be added the temp token and an additional verification code. By providing this verifier the gateway may exchange its temporary token for an access token, which can in turn be exchanged for the user's MyProxy certificate. In the current implementation, each access token may only be redeemed at most once.
Figure 1. A user grants a science gateway access to MyProxy credentials via OAuth.
The OAuth portal webapp also provides a registration servlet for science gateways: this is simply a form which accepts the gateway's public key (which is checked for validity) and relevant information about the site in question. After registration, science gateways must be approved manually by an operator. A simple command line tool is provided that will list science gateways that have registered and allow an operator to approve or deny their OAuth client status.
Besides physical resources such as CPU and network bandwidth, the various servlets that comprise the MyProxy OAuth portal also requires access to a file system in order to read configuration information and write logs. The servlets further require access to data stores, which may be backed by the file system, an SQL database, or simply shared memory. The data stores and the servlets that use them are shown in Figure 2; the numbered arrows indicate which servlet is responsible for which steps in the OAuth protocol as shown in Figure 1. Not shown are system resources used by Tomcat and the Java runtime, including the private key and certificate chains needed for SSL, as well as the common configuration and log files, which are respectively read and written by each servlet.
The OAuth portal relies on three data stores to facilitate interaction among
the servlets. The
clients store, contains the registration
information provided to the registration servlet, but does not indicate whether
a science gateway is an approved client, the task of the
Each servlet that participates in the OAuth exchange first verifies that the
client it is communicating with is approved.
transactions store manages the shared state for
transactions; it is the only store that is reasonable to keep solely in memory.
The other two must be backed by a database or by the file system, and
unauthorized users must be prohibited from accessing them.
Figure 2. Relationships between servlets and data stores, with references to OAuth message numbers (Figure 1).
The OAuth portal for MyProxy runs as an unprivileged user, typically a dedicated user for Tomcat webapps. It needs read and write access to the file system or database resources that back the various transaction stores, along with a directory in which it writes its own log files (independent from Tomcat's logging facilities). It further requires read access to the system SSL certificates and the private key corresponding to the webapp's own certificate, along with configuration files that point to these resources and establish templates for automated email messages sent by the system. Aside from the system-wide SSL certificate chain, these would typically all be stored within a single directory.
The user who runs the approver tool must be able to read the OAuth portal
configuration files and data stores, as well as write to the
data store and to a log file.
The OAuth portal has no special access to the certificates protected by the MyProxy server and makes no access decisions beyond following the OAuth 1.0a protocol and rejecting sessions that behave erroneously. The science gateway registration process requires operator intervention before a science gateway is recognized as a valid client.
If the OAuth portal is running on a system with many other Tomcat webapps, a vulnerability in one webapp may allow others to be attacked: for instance, unrestricted directory traversal in some other webapp could expose the OAuth portal's private key, allowing it to be spoofed by a phishing site. This can be prevented by running the OAuth portal from its own dedicated Tomcat instance, ideally on a dedicated (virtual) host. This instance of Tomcat should not be run as the same user as that used for any other instance of Tomcat that shares resources with this system.
This section describes some of the techniques used to perform the component analysis where vulnerabilities are searched for using the prior analysis and looking at implementation details for bugs.
Reviewed the design of the OAuth portal. The design is a straightforward OAuth 1.0a implementation; OAuth 1.0a fixes a design flaw that was discovered in OAuth 1.0. No vulnerabilities were found in the design, and OAuth 1.0a has withstood much scrutiny from the security community.
Checked how SQL queries are constructed in the event that an SQL database is used as the backend for a transaction store. No vulnerabilities related to SQL queries were found
clientstable, and selections are never made based on this data.
Data stores may, rather than using an SQL database, be backed by the file system—in fact, this is the suggested configuration. No vulnerabilities were found in this configuration, either.
A standard OAuth session only takes as input the MyProxy username and password, and these are not echoed back in any output pages. The use of registration information as an injection vector, as previously discussed, was the only vulnerability of this sort that was found.
Checked for race conditions whereby two OAuth sessions might interfere with each other. The design of the data store implementations protects against these cases (as noted above for the file system version); Tomcat handles each use of a servlet separately, freeing the portal internals from concerns over shared state apart from the data stores.
Loading another web page in an HTML frame gives the loading page scriptable access to the framed page, which can be exploited in a variety of ways. The OAuth portal uses X-Frame-Options: Deny to forbid this and avoid any such vulnerabilities.
One omission of functionality was discovered, however: the "Cancel" button on the login page directs to a URL which does not yield a valid web page.
The MyProxy protocol is text based, with each request consisting of a linebreak-separated series of parameter specifications. An injection attack could alter the meaning of the MyProxy GET command intended to be sent. No such attacks were found.
The OAuth portal stores minimal information about each in-progress OAuth exchange, and it times out exchanges that take too much time. While no server is, on its own, immune to denial of service attacks, the MyProxy OAuth portal was not found to enable these attacks.
The command line approver application is not part of the OAuth portal webapp, and approvals could be made without it; nevertheless it is described in the documentation as the standard approval method. It presents information that was given to the registration servlet only after a potential client is selected, and this information is printed prior to instructions for the operator; it does not rely on any properties of the registration information. No vulnerabilities were found in this tool.
One bug was found in the approver tool: it seems unable to change the status of a gateway from approved to not approved, despite offering that option. It is still possible to revoke the approval status of a gateway by manually editing the data store (e.g., by editing an XML file if the data store is backed by the file system).
The cancel button on the login form, as well the approval revocation functionality of the approver tool, should be fixed/added.
The final step of the OAuth protocol redirects the user's web browser to a destination specified by the OAuth client (in this case, a science gateway) at the beginning of the exchange. If the OAuth client has a bug that allows this destination to be set arbitrarily, an attacker may be able to craft links that launch a legitimate OAuth exchange that subsequently redirects users to a phishing site.
In order to help science gateways protect their users from such attacks, the portal could offer whitelist functionality during the client registration process. It is common in OAuth implementations to allow the whitelisting of specific URLs, a URL pattern, or an entire domain (only safe if this domain does not provide a general purpose redirect URL). The MyProxy OAuth portal does not currently offer such functionality.
The OAuth portal itself presents a small attack surface, but it is built on Tomcat and the Java Runtime, and vulnerabilities in either could become vulnerabilities in the OAuth portal. It is highly recommended that both be kept up to date on any system running this software. Other webapps running in the same Tomcat instance, or in other Tomcat instances running as the same user and connected via networked storage, would present an additional attack surface that cannot be properly accounted for. It is highly recommended that these situations be avoided.
This section describes some thoughts on why only two vulnerabilities were found.
The code base is under 19,000 lines of Java code, written almost entirely by a single author.
The OAuth portal webapp performs only two tasks: it accepts registration for science gateways (which must then be reviewed by a human using a verbose, simple, single-purpose command line interface), and it handles OAuth requests. In both cases it aborts if it encounters any input irregularity. It makes no decisions about authorization aside from recognizing client science gateways based on their possession of the correct OAuth consumer key.
The individual servlets that make up the webapp communicate with other OAuth parties (the client science gateways and the user) via the standard OAuth interface. Only one of these servlets ever contacts the MyProxy service, and it does so directly rather than relying on any MyProxy client programs. Servlets share information via a well-defined data store model that may be backed by the file system, an SQL database, or shared memory, but they do not freely access any of those resources.
OAuth for MyProxy requires no special permissions to run beyond those required to read and write its own state directories and write to its log directories. Typically it will be run as a special user assigned to Tomcat, and Tomcat installations do not default to running as root.
Being implemented as a handful of servlets inside a Tomcat webapp frees the OAuth for MyProxy implementation from the lower level concerns involved in the handling of requests as they arrive. It instead relies on the Tomcat implementation to run a separate instance of the servlet for each incoming connection, and Tomcat in turn relies on the correctness of Java.
Being written in Java also essentially rules out large classes of vulnerabilities (for instance, buffer overflows) as compared to C, as Java provides much stronger memory safety. But, as the recommendation section notes, such dependence does make site operators responsible for ensuring that Tomcat and the Java runtime are kept up to date.
All communication to and from the MyProxy server is encrypted using the TLS protocol and the client always authenticates the server. The remainder of the communication is all web traffic, which the webapp requires be sent over HTTPS. This prevents exposure of sensitive data.
The data stores used by the webapp never contain sensitive information, and MyProxy certificates in particular are not cached; each access token may only be exchanged for a MyProxy certificate at most once. The OAuth protocol prevents the reuse of intermediate tokens, limiting their value if the contents of the transaction data store were to be disclosed.