Security analysis of Teampass • December 2014
Security analysis of Teampass
Ville Sebastian Olsson 20146404
KAIST
seo@kth.se
Abstract
The purpose of this paper is to evaulate the security of Teampass, a collaborative passwords manager. This is
done by studying the encryption algorithm, hashing algorithm, investigating potential web vulnerabilities,
query handling and the use of password attachments. No serious vulnerabilities related to encryption
and hashing were found, although some properties were addressed. The feature of uploading attachments
was found to be coupled with serious vulnerabilities that allow an attacker to view the contents of any
attachment, unless the file permissions have been manually adjusted.
I.
Introduction
asswords have become increasingly
ubiquitous among Internet users. As the
number of online login services has increased over the years, so has the number of
passwords that the user needs to keep track
on. At some point, remembering several dozen
passwords becomes unsustainable.
P
Some users alleviate the act of remembering passwords by reusing the same password
for multiple sites, or by picking short simple
passwords that are easy to remember. Both
are widely considered bad practices from a
security standpoint. [1] [2]
Password managers have arisen as a proposed answer to this problem. A password
manager is an application that typically features a way for the user to store all his
or her passwords in one place which itself
is password-protected by a single password
known as the master password. Some password managers are collaborative in the sense
that they are designed to be used by a group
rather than by a single person. This may be
done by having the group access the application through a web interface.
This paper is about a particular collaborative password managed named Teampass.
Teampass proclaims itself to be suitable in a
business environment [4] and, unlike many
commercial alternatives, is released as free and
open source software [3].
Considering the role of a password manager, by now one should have concluded that
it is crucial for Teampass to be devoid of any
vulnerabilities that threaten the confidentiality
of the stored passwords. For instance, if all the
passwords belonging to a company were to be
leaked, it could have disasterous consequences.
For this reason, one who is using or is planning
to use Teampass may be curious about whether
it is secure enough to be used.
II.
Background
Like any other PHP-powered web application,
Teampass is installed on a web server and accessed with a browser. The application makes
use of a MySQL database which, among other
things, is used to store the passwords.
When visiting the webpage for Teampass
for the first time, the user is presented with a
login screen. This is where the user authenticates herself by entering her master username
and password.
1
Security analysis of Teampass • December 2014
• a brief review of the source code
• a review of the currently known vulnerabilities
• penetration testing of the web interface
• related work by other analyses of password managers
V.
Figure 1: A portion of the login screen.
Once logged in, the user is granted access to
a share of the total set of passwords, depending
on her role. For organizational purposes, the
administrator may choose to place passwords
into (possibly nested) password folders. These
can also be used for access control: whether or
not a user has access to a folder depends on
the user’s role. A role is a property assigned
to every user and determines which folders
the user has access to. For a more detailed
description of how access control works, refer
to [4].
III.
Problem statement
The aim of this paper is to give an assessment
of the state of security in version 2.1.21 of Teampass, which was the latest version at the time
this study began. In particular, this paper focuses on
• encryption and decryption of the stored
passwords
• user authentication with the master password
• vulnerabilites in the web interface
• discussing the future outlook of the application.
IV.
Method
To achieve its goal, this paper has based its
results on
2
Related work
A recent work by Zhiwei Li et al. [5] attempts
to give an overview of the general security of
today’s password managers. This is done by
analyzing five password managers, Teampass
not being one of them. Their conclusions have
served as a source of hints of what to look for
when analyzing Teampass.
As for Teampass specifically, there does not
appear to exist any publications that involve it.
However, the project includes a GitHub page
where issues – including security issues – are
posted by the community. There are also various vulnerability databases on the web that
host reports about Teampass vulnerabilities,
e.g. the National Vulnerability Database [7].
VI.
Results
This section presents the findings of the analysis.
I.
Password encryption
The PHP functions encrypt and decrypt are
used for encrypting and decrypting the stored
passwords.
In Figure 2, encrypt is shown to be using
the Rijndael cipher with blocksize 256 bits, cipher mode CTR and a pseudorandom initialization vector. The main developer repeatedly
refers to this cipher as AES-256 [9] but this
must be a misunderstanding since the 256 in
MCRYPT RIJNDAEL 256 is the block size [10] and
AES always has a block size of 128. This does
not necessarily make the encryption less secure,
but a few things should be noted:
• Rijndael-256 has most likely not been subject to cryptanalysis as much as AES, so
Security analysis of Teampass • December 2014
function encrypt($decrypted, $personalSalt = "") {
if (!empty($personalSalt)) {
$staticSalt = $personalSalt;
} else {
$staticSalt = SALT;
}
$pbkdf2Salt = getBits(64);
$key = strHashPbkdf2($staticSalt, $pbkdf2Salt, ITCOUNT, 16, ’sha256’, 32);
$iv = mcrypt_create_iv(mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, ’ctr’), MCRYPT_RAND);
if (strlen($ivBase64 = rtrim(base64_encode($iv), ’=’)) != 43) {
return false;
}
$encrypted = mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $key, $decrypted, ’ctr’, $iv);
$mac = hash_hmac(’sha256’, $encrypted, $staticSalt);
return base64_encode($ivBase64 . $encrypted . $mac . $pbkdf2Salt);
}
Figure 2: Encryption function (comments removed).
Rijndael-256 might contain undiscovered
vulnerabilities.
• A larger block size could introduce weaknesses. For example, the cipher Block
TEA is vulnerable to differential cryptanalysis while the smaller equivalent
XTEA is not. [11, p. 24]
• On the other hand, with a smaller block
size, the probability of getting ciphertext
collisions increases. Cipher modes such
as CBC rely on the property that collisions do not occur. [12] However, 128 bits
is widely considered to be large enough
for essentially all purposes.
• The creators of Rijndael themselves state
that “[the] added flexibility [of larger
block sizes] may allow to extend attacks
by one or more rounds.” [13]
These things considered, it is recommended
that AES (MCRYPT RIJDAEL 128) is used instead
so that the application complies to encryption
standards. Nevertheless, considering the fact
that this encryption function used ECB in previous versions [14], this is a vast improvement.
II.
User authentication
On logging in, the master password belonging
to the Teampass user is hashed and compared
with the hash stored in the database. Figure 3
shows that the hash function used is bCrypt, a
Blowfish-based key derivation function which
is reasonably slow, adaptable and has a good
reputation as a password hashing algorithm
[15]. By default bCrypt is called with a cost
of 13 which is high enough, if not too high.
Executing bCrypt with this cost takes around
0.6 seconds on a standard laptop.
This is clearly a huge improvement over
previous versions, where the master password
was encrypted rather than hashed. It should
be noted however that the function uses the
PRNG mt rand, a generator which suffers from
seed poisoning vulnerabilities [16]. However,
it is only used as a fallback for the more secure
alternative openssl random pseudo bytes. To
further prevent the use of mt rand, I suggest adding /dev/urandom as a third possible
source of randomness.
However, the best solution is arguably to
use a library that provides bCrypt instead of
relying on a custom implementation. That way,
the author does not need to think about maintaining the implementation of bCrypt as new
vulnerabilities in bCrypt are found. There
exist a few libraries for this purpose; PHPPasswordLib [17] is an example.
3
Security analysis of Teampass • December 2014
function bCrypt($password, $cost) {
$salt = sprintf(’$2y$%02d$’, $cost);
if (function_exists(’openssl_random_pseudo_bytes’)) {
$salt .= bin2hex(openssl_random_pseudo_bytes(11));
} else {
$chars=’./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789’;
for ($i=0; $i<22; $i++) {
$salt.=$chars[mt_rand(0, 63)];
}
}
return crypt($password, $salt);
}
Figure 3: Hash function.
III.
Web vulnerabilities
While it is true that hashes and ciphers should
be devoid of vulnerabilities, the weakest link
of security in this case arguably lies in the web
interface. The reason is that the attack surface
is considerably large, as suggested by Li [5,
p. 5].
Two common types of vulnerabilities found
in web application are XSS and CSRF. Versions
of Teampass prior to 2.1.20 appear to have been
exploitable by XSS. [19] These appear to have
been fixed since then, although it is possible
that vulnerabilities are still present. As for
CSRF, no vulnerabilities appear to be known
at this date.
These two kinds of vulnerabilities have
been shown by Li to be prevalent in password
managers, e.g. LastPass. Li suggests the use
of a strong CSP policy to mitigate XSS attacks.
[5, p. 16] In addition, CSRF protection with
tokens should be included in every webpage
and form. [5, p. 16]
Although the variable $pre is shown to be
set to a (safe) prefix string in the source code,
concatenating it to an SQL query is still an
unnerving act, especially since this is a global
variable. Particularily, if there was a way for
an attacker to modify the value of the variable
during execution, this would still be a source
of injection attacks. It could also happen that
the variable is accidently modified due to a
bug. This pattern of concatenating queries is
repeated several times in the source code.
It is therefore advisable to at least sanitize
the variable at the moment it is used in any
query. This could for example be done using
a prefix function that both verifies that the
variable contains a valid prefix and prepends
it to the base table name:
$rows=DB::query(
"SELECT id,pw FROM ".prefix("users"));
V.
Password attachments
The security of handling SQL queries in the
web interface has improved significantly since
previous versions, which partly suffered from
SQL injection vulnerabilities [18].
A minor issue remains, however: query
concatenation. Consider the query:
Teampass supports uploading files as attachments to a password. Like passwords, these
may contain sensitive data, such as a CSV file
listing the salaries for every employee.
When uploading a file, it is by default uploaded into the uploads directory on the server
and renamed to a 32-character hexadecimal
string. As a side effect, this file can then be
accessed from the browser like so:
$rows=DB::query(
"SELECT id,pw FROM ".$pre."users");
https://example.com/teampass/upload
/76a7138f887afc86fe1c385be86b79c0
IV.
4
Query handling
Security analysis of Teampass • December 2014
The file will be shown in plaintext in the user’s
browser. Worse, the user does not even need
to be logged in to view the file. The user can
even browse
https://example.com/teampass/upload/
to view a list of links to every uploaded file, as
shown in Figure 4.
• Rename the URL every time the file is
viewed in a browser.
• Turn on encryption of attachments by default. This entails that the files cannot
be viewed in a meaningful format in the
browser, however.
• Forbid access to the resource, unless the
user is logged in and is authorized to
view the associated password.
• Implement separate access control for
dealing with viewing and uploading attachments.
VI.
Figure 4: Accessing the upload folder.
This means that it is trivial for an attacker
to view all the uploaded files of any server that
uses Teampass, unless access to these URLs
has been manually restricted after installing
Teampass. To mitigate this, Teampass should
at the very least display a warning to alert the
users (and the server administrator) that the
folder permissions are too permissive. Also,
there exists an option for enabling encryption
for files, but it is not turned on by default.
However, even if access to the upload folder
is made restricted (but not the files), this only
solves part of the problem. If an attacker is
standing behind the back of a Teampass user
while the user is viewing the file through the
browser, it is easy for the attacker to discreetly
take a photo of the screen including the URL.
Once the attacker has the URL, she can access
the file without even being logged in. This is a
likely scenario in a business environment if the
CEO works closely with employees that cannot
be trusted.
There are a few proposed solutions to this
problem:
• Make Teampass forbid access to the resource by URL altogether.
Future outlook
Teampass is somewhat unique in that it is free
and open source, in contrast to many commercial alternatives. This means that it is easier
for black hat hackers to spot vulnerabilities,
but also that it is easier for white hat hackers and security analysts in the community to
spot them first. By Linus’ law [20] and given
enough time and support from the community, this application has potential to become
more secure and popularand popular than its
alternatives.
The addition of new features for convenience’s sake is a predictable source of new
vulnerabilities. Other password managers
have convenience feature such as “auto-fill”,
“auto-login” and “bookmarklets” that Teampass lacks. This may be a good thing since
these features have been shown to be subject to
serious vulnerabilities. [5, p. 7] If features like
these will one day be added to Teampass, it is
suggested to not do so until the relevant security papers on the matter have been carefully
studied.
For instance, seeing that the recent Teampass 2.1.22 features a way of accessing passwords through an API [8], this has expanded
the attack surface of the application. It is recommended to be conservative about adding
new features until the ramifications in regard
to security have been analyzed, maybe in the
form of a peer-reviewing process.
The main source of vulnerabilities will most
likely continue to be web-based since new fea5
Security analysis of Teampass • December 2014
tures are typically tightly integrated with the
web interface. As the number of features will
grow, so will the attack surface. Unfortuately,
the more complex the application becomes, the
more difficult it becomes to do an in-depth
analysis. One can only hope that the increased
number of security analysts in the community
will make up for this.
VII.
References
[2]
[3]
6
[4]
Laumaillé, Nils. Teampass A Collaborative Passwords Manager [Internet].
Cited 2014 Dec 10.
Available from:
http://www.teampass.net/
[5]
Zhiwei Li, Warren He, Devdatta Akhawe,
Dawn Song. The Emperor’s New Password Manager: Security Analysis of Webbased Password Managers. July 7, 2014.
[6]
GitHub,
Issues
page
[Internet].
Cited 2014 Dec 12.
Available from:
https://github.com/nilsteampassnet/TeamPass/issues
[7]
National Vulnerability Database. Vulnerability Summary for CVE-20143774 [Internet].
Available from:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE2014-3774
[8]
Laumaillé,
Nils.
Teampass A
Collaborative
Passwords
Manager [Internet].
Available from:
http://teampass.net/features/teampassapi.html
[9]
Laumaillé, Nils.
Available from:
http://teampass.net/definition/aboutdata-encryption.html
Conclusion
Most of the serious known vulnerabilities existed before version 2.1.20, such as cross-site
scripting and SQL injection. Both encryption
and hashing are adequate, but there exist serious vulnerabilities related to uploading attachments that should be fixed as soon as possible.
This paper has presented some common
types of vulnerabilties, but in order to truly
assess the security of the application, a more
thorough investigation by an expericenced security analyst may be needed.
In conclusion, I still deem Teampass to be
moderately safe for use by businesses. This
presumes, however, that attachments are not
uploaded and that the installed version is kept
up to date. In addition, it is strongly recommended to use two-factor authentication with
Google Authenticator in order to add an extra
layer of security.
[1]
2014 Dec 10.
Available from:
https://github.com/nilsteampassnet/TeamPass
Office of Privacy and Information Assurance.
Why You Should
Use Different Passwords [Internet].
Cited 2014 Dec 9.
Available from:
https://security.illinois.edu/content/whyyou-should-use-different-passwords
Sieber, Tina. How To Create A Good
Password That You Will Not Forget [Internet]. Cited 2014 Dec 9. Available from:
http://www.makeuseof.com/tag/createstrong-password-forget/
Laumaillé, Nils.
words Manager
Collaborative Pass[Internet].
Cited
[10] Maurits van der Schee. Available from:
http://www.leaseweblabs.com/2014/02/aesphp-mcrypt-key-padding/
Cited 2014
[11] Vikram Reddy Andem.
Dec 17. A Cryptanalysis of the Tiny
Encryption Algorithm Available from:
http://www.leaseweblabs.com/2014/02/aesphp-mcrypt-key-padding/
Dennis.
Cited
[12] Stack Exchange:
2014 Dec 18.
Available from:
http://crypto.stackexchange.com/a/6018
[13] Joan Daemen, Vincent Rijmen AES Proposal: Rijndael, document version 2.
March 9, 1999.
[14] GitHub:
slimm609.
Cited
2014 Dec 18.
Available from:
https://github.com/nilsteampassnet/TeamPass/issues/227
Security analysis of Teampass • December 2014
[15] Stack Exchange:
Thomas Pornin.
Cited 2014 Dec 18.
Available from:
http://security.stackexchange.com/a/6415
https://github.com/ircmaxell/PHPPasswordLib
[18] GitHub, TeamPass.
Available from:
https://github.com/nilsteampassnet/TeamPass/issues/585
[16] Stefan Esser.
mt srand and not so
random numbers.
Available from:
[19] US-CERT.
Available
http://www.suspekt.org/2008/08/17/mt srand- from:
https://www.usand-not-so-random-numbers/
cert.gov/ncas/bulletins/SB14-223
GitHub, PHP[17] Ferrara, Anthony.
PasswordLib: A library for generating
and validating passwords. Available from:
[20] Raymond,
Eric
S.
Linus’
Law.
Available
from:
https://www.princeton.edu/ achaney/tmve/wiki100k/docs/L
7