Security Audit of Seafile’s Private Cloud Storage platform

Offensive Technologies Report

Jeroen Schutrupjeroen.schutrup@os3.nl

Siem Hermanssiem.hermans@os3.nl

May 27, 2016

Abstract

Public cloud storage platforms offer a great deal offlexibility which has caused many companies to in-clude this paradigm in their IT strategy. However,as the dependence of companies on cloud storagerises, concerns regarding the safety of these plat-forms emerge. As such, an increasing amount ofcompanies is investing in privately hosted storagesolutions like Seafile. Still, due to the public in-terfaces provided by these products, potential se-curity vulnerabilities remain present. This paperpresents a security audit of Seafiles private cloudstorage solution. It identifies common attack vec-tors and vulnerabilities of comparable products andexamines the exploitability of Seafile in its currentstate. All identified vulnerabilities are documentedand weighted to indicate their effective risk. Lastly,advice is given for future improvements of the plat-form with regards to security. Although Seafile asa platform has made great advancements regardingsecurity in recent years, this audit reveals severalhigh risk vulnerabilities ranging from denial of ser-vice exploits to the ability to gain unprivileged ac-cess to a wide range of stored data. Moving for-ward, it is advised to perform a thorough revisionof the current code base to eliminate the uncoveredvulnerabilities.

Keywords – Private Cloud Storage, Security Au-dit, vulnerabilities, Seafile

1 Introduction

According to predictions of Gartner in 2012 [1], athird of all data would be stored in the cloud by2016. This trend has generally held true as moreand more companies started adopting cloud stor-age platforms as either a backup for their data or

even as a primary storage solution. Cloud storagehas rapidly evolved from being a promising busi-ness concept to a mainstream strategy. However,as with any publicly provided third party service,these platforms are potentially vulnerable to secu-rity incidents [2], data breaches [3], and other ma-licious activities. This means that as of right now,many companies are still anxious to migrate theirdata due to sovereignty, security and privacy is-sues [4, 5]. These concerns have caused an influxin the popularity of privately hosted, on-premisecloud solutions which essentially allow a companyto provide similar services as commercial platformslike Dropbox and Google Drive, but selectively to agroup of users whilst maintaining centralized con-trol over the data. As such, data privacy and pro-tection can be maintained. Prime examples of plat-forms which provide these functionalities nowadaysare ownCloud and Seafile. Most notably, ownCloud[6] has been gaining a lot of traction and sees anincreasing amount of production deployments [7].However, similar competing products like Seafileare up and coming.

This new interest in private cloud solutions raisesquestions regarding the effective security of theseplatforms. Although, by using a private cloud stor-age platform, corporate data is not stored with athird party anymore, the data is still commonlybeing provided to end users via a series of publicinterfaces. The security of ownCloud, as a resultof its popularity, has been researched in the pastmultiple times. However, at the time of writing weare not aware of any security audits with regardto Seafile. This is alarming, as a series of serioussecurity flaws have been reported in the past yearsregarding the platform [8]. These issues concernInitialization Vector (IV) reuse in Seafile’s data en-cryption and bad password salting. As such we areinterested in the exploitability of the freely avail-

1

able Community Edition of Seafile’s private cloudstorage platform.

This report aims to present a broad yet completesecurity audit of the web access interface of Seafilesprivate cloud storage solution. Prior to the auditwe define a pragmatic approach which aims to iden-tify the most successful areas of discovering a vul-nerability. In the process we take a look at recentsecurity flaws reported for private cloud solutionsin general and relate relevant issues to Seafile. Thefollowing contributions have been identified:

• Exploration of common and recent securityflaws regarding popular private cloud storagesolutions.

• Presentation of identified security flaws re-garding Seafile specifically accompanied with arisk assessment and exploitability evaluation.

• Advices regarding vulnerability mitigation anda general security advice regarding Seafilemoving forward.

2 Research Questions

The aim of this project is to provide an answer tothe following main research question:

What is the current state of security re-garding Seafile’s private cloud storage so-lution?

Several sub-questions have been posed to limit thescope of this research:

• Are vulnerability trends of major competingprivate cloud solutions like ownCloud applica-ble to Seafile?

• What is the status of security vulnerabili-ties found in the past and what are currentlyknown vulnerabilities?

Further scoping of the project is discussed in moredetail in section 6.

3 Related Work

The security of cloud environments in general hasbeen researched in the past multiple times. Fol-lowing the popularity of these storage as a service(StaaS) platforms, a large series of vulnerabilitiesare being uncovered and the amount of viable at-tack vectors are increasing. In order to structurethese vulnerabilities, Dotter et al. [9] present acloud platform attack and risk assessment taxon-omy specifically catered towards cloud platforms.Their taxonomy divides cloud attacks by identi-fying the source of the attack, the attack vector,the target, corporate impact, and potential defense

measures against the attack. This classification islargely similar to the slimmed down risk assess-ment method of the Open Web Application Secu-rity Project (OWASP) in which vulnerabilities areidentified and prioritized following a standard for-mat. Due to the positive reputation of the OWASP,any vulnerabilities uncovered during the course ofthis project will be assessed by taking the lattermethodology as a starting point.

Competing cloud storage platformsDue to the potential risks of storing corporate datawithin the public cloud, many security conciouscompanies are anxious to store their data with athird party. Following these concerns, private cloudstorage solutions have become increasingly popularamong Enterprises. As a result of its popularity,the security of ownCloud has been researched in thepast multiple times. The main points of interest areusually general security concerns regarding cloudplatforms or the security of the service’s web front-end. Rexha et al. [10] for example present a gen-eral overview of common security issues regardingcloud storage platforms. Conclusively they iden-tify the client-side data synchronization function-ality as the most critical attack vector. Xu et al.[11] perform a penetration test based on commonvulnerabilities as identified in the OWASP Top Tenproject. This project aims to identify the most crit-ical web application security flaws [12] of currenttimes. Following this list they performed a seriesof Man in the Middle (MitM) and SQL injection at-tacks on an ownCloud deployment in a lab environ-ment. Although they are succesful in their MitMattempts, the success of their attacks hinges on theabsence of a properly implemented certificate. Fur-thermore, all SQL injection attempts failed. Dueto its active community and open source nature ofthe project, ownCloud is actively being monitoredby the community which in return results in a largeamount of Common Vulnerabilities and Exposures(CVE) publications.

Issue tracker & vulnerability trendsBesides the commonly researched ownCloud,Seafile is gaining in popularity. However, at thetime of writing, no security evaluations of the plat-form have been performed. This is likely causeddue to the fact that there aren’t many known pro-duction deployments. Still, interest is growing asSheng et al. [13] propose a model for deploy-ing Seafile in college and University environments.Their research repeatedly commends Seafile for its’high security’ but fails to present technical motiva-tion as to why this level of security is reached. Theissue tracker on GitHub for Seafile’s cloud solutioneven disputes this security claim as in the past fiveyears 55 security issues in ranging levels of severityhave been reported.

2

ownCloud is the prime competitor of Seafile’s plat-form and employs a similar concept. As such, thisreport inventarises the past and present vulnera-bilities relevant to ownCloud. The aim is to findcommonalities in vulnerabilities. Potentially thesevulnerabilities can be projected on Seafile. Thisevaluation is presented in the following section.

4 Private cloud vulnerabilitytrends

This section describes recently reported vulnerabil-ities with regards to the comparable private cloudstorage solution ownCloud. By exploring theseflaws we aim to discover trends in vulnerabilities forthis type of platform, if any. The presented datamay show promising areas for further research withregards to Seafile.

4.1 Data set

For this preliminary research the publicly availableNational Vulnerability Database of the NationalInstitute of Standards and Technology (NIST)[14]has been used. All reported vulnerabilities from2013 onwards for ownCloud have been extracted.Subsequently this data was combined with the vul-nerability severity scores of CVEDetails[15]. Thefollowing sections visualize and discuss the findings.

4.2 Vulnerabilities & severity

From 2013 onwards, ownCloud has been foundprone to 87 security vulnerabilities. As presented infigure 1, the majority of these security flaws con-cerned Cross Site Scripting (XSS) attacks. How-ever, further analysis in figure 2 reveals a relativelylow impact regarding XSS flaws. The same holdstrue for attacks which attempt to bypass protec-tion. While the least amount of vulnerabilities con-cerned directory traversal, these flaws do have asignificant impact. Lastly, both code execution at-tacks and information obtaining attempts are fre-quently reported and share the characteristic thattheir impact is generally high. As these are the twoform the most promising areas of research they arediscussed in more detail in the section below.

4.3 Further analysis

Code execution & obtaining informationOf the fourteen remote code execution flaws in own-Cloud, twelve have a low complexity and can causeconsiderable impact. Four of these vulnerabilitiesare able to completely compromise a target sys-tem. Further investigation reveals that two of thesebugs are directly caused by using an external li-brary containing the vulnerability. Another flaw isintroduced by using third party extensions to the

Byp

ass

prot

ectio

n

XS

S

CS

RF

Den

ial O

fS

ervi

ce

Dire

ctor

ytr

aver

sal

Exe

cute

code

Obt

ain

info

rmat

ion

No.

of C

VE

s

0

5

10

15

20

25

CVE Type

Figure 1: ownCloud CVEs from 2013 onwards. Numberof CVEs per type.

● ●

●

●

●

●

2

4

6

8

10

CV

E S

core

Bypassprotection

XSS CSRF

DenialOf

ServiceDirectorytraversal

Executecode

Obtaininformation

CVE Type

Figure 2: ownCloud CVEs from 2013 onwards. Severityper CVE type.

ownCloud platform. Bugs present in the product’sown code base only causes partial access.

When trying to obtain information, all but twohave a low access complexity. Contrary to code ex-ecution flaws, these bugs are almost all due to inap-propriate parameter checking, using bad random-ness, or applying cryptography in a wrong manner.While having a considerable impact on data confi-dentiality most of these flaws are tough to discover.

Miscellaneous flawsRegarding Denial of Service (DoS) vulnerabilities,nearly half of them are caused by flaws in exter-nal libraries. All remaining bugs are caused byinsufficient parameter checking of which some ofthem are also related to directory traversal flaws.

3

For restriction bypasses, using external libraries oradd-ons is also causing a considerable amount ofsecurity flaws.

Further researchConclusively, vulnerabilities reported for ownCloudover the past years reveal that the usage of thirdparty libraries and extensions generally introducesa plethora of security flaws. Secondly, the usage ofbad sources for randomness or incorrectly applyingcryptography (TLS verification, bad hashing algo-rithms) causes issues as well. Last of all, incor-rect parameter checking in the web client and APIof ownCloud introduced a lot of options for per-forming code execution attacks or allowing an at-tacker to obtain information. These three areas areconsidered to be interesting for further explorationduring this research, as they are very frequentlyreported, have a high impact on either confiden-tiality, integrity or the availability of the system,while the access complexity is very low.

5 Seafile Service overview

In order to set the stage for Seafile’s platform, thissection will delve briefly into the primary functionsof the product and its internals. Additionally, thevariety of installation methods provided by Seafileare discussed.

5.1 Core platform functionality

Due to the popularity of cloud computing as awhole, the term ’cloud storage’ has become anoverloaded and ambiguous concept which nowa-days covers a broad range of technologies rangingfrom object storage architectures like Amazon S3 tofile hosting and synchronization services like Drop-box. Seafile and ownCloud both fall into the lat-ter category by providing a storage platform whichin its core functionality can be compared to com-mercial products like Dropbox or Google Drive.These services are primarily catered towards en-abling end users to interface with their private datain a straightforward manner. In order to facilitatethis functionality, the end user can generally uti-lize dedicated external clients or a web interface toaccess the server. As is the case with Seafile. Toclarify, figure 3 presents an overview of the compo-nents which make up the Seafile platform [16].

From a technical perspective the server consists ofthree primary components, namely the Seafile Dae-mon, the Ccnet server and the ’Seahub’ front-end.The Seafile Daemon is responsible for handling fileuploads, downloads and synchronization requestsfrom external clients. As such, the data daemonforms the core of the platform. Additionally, thisdaemon allows users to create and organize ’li-

Figure 3: Overview of the Seafile server components

braries’. These libraries function as a top level datacontainer for each user’s personal set of files andfolders. The data daemon maintains a modificationhistory for each library. The Ccnet component isan RPC service daemon which allows for internalcommunication between the components. Lastly,the web interface, ’Seahub’ forms the primary ac-cess point to the server. This component allows anend user to access their data which is stored on thecentralized Seafile server. The interface is built ontop of the poular Python framework ’Django’ andby default Seahub is hosted on ’gunicorn’: a sim-ple Python HTTP server. As the image illustrates,dedicated (mobile) external clients are available aswell. These are referenced in more detail in section10. All of the core components rely on their owndatabases which are being handled by a MariaDBinstance.

5.2 Installation methods

Interestingly enough, Seafile provides two distinctinstallation methods. The first method is a sim-ple installation script which is included in their in-stallation package. This script allows one to au-tomatically deploy the previously mentioned corecomponents of Seafile. However, Seafile also pro-vides a separate installation script on their GitHubpage [17] which claims to automatically set up aproduction ready Seafile Server. The simple scriptmerely provides guidance in installing an insecureinstance of Seafile Server without HTTPS enabled.The secure version on the other hand also con-tains an Nginx webserver with self signed certifi-cates and a Memchached instance which allows forbetter scalability of the server. In the latter in-stance, all requests to the Seafile environment areproxied through Nginx by running Seahub in fast-cgi mode behind the web server.

It is important to note that this security audit fo-cuses primarily on the supposedly secure instanceof Seafile, as we feel that the default instructionsare mainly catered towards setting up a develop-

4

ment environment. Still, the discrepancy betweenthe installation methods is noteworthy and will bediscussed further in section 8.

6 Methodology

This section discusses the methodology of theproject and reviews the scoping of the audit. Theassessment framework presented in this section de-fines the overall scope of the security audit.

6.1 Environment

To perform the audit, a privately hosted Seafile en-vironment has been deployed in a VirtualBox vir-tual machine using the so-called secure installationscript provided by Seafile. The machine is hostedin a private environment. During the experimenta-tion phase, no personally identifiable data is han-dled. As such, no ethical concerns are present.

6.2 Assessment framework

As depicted in figure 3, a full deployment ofSeafile’s Private Cloud storage environment con-sists of many interconnected components and ex-tension modules. In order to effectively delimit thescope of the project, this audit will exclusively ex-amine the server component of the platform and inparticular its web front-end which allows end usersto interface with their data. The preliminary re-search in section 4 evaluated ownCloud CVEs andidentified a series of areas which are interesting forfurther research. Most importantly, the usage ofthird party libraries, bad sources for randomnessand incorrect parameter checking by the applica-tion are areas of interest. Additional care will betaken when evaluating these areas.

The identified vulnerability areas are largely cov-ered by the OWASP Top Ten. As such, this projectwill utilize the most recent OWASP Top Ten from2013 as a framework for assessing the security of theplatform. Doing so also allows us, at a later stage,to identify the risk of any uncovered vulnerabilitiesfollowing a broadly accepted scoring methodology.Listed below are the web application security riskswhich this audit will review:

A1 - Injection

A2 - Broken Authentication and Session Man-agement

A3 - Cross-Site Scripting (XSS)

A4 - Insecure Direct Object References

A5 - Security Misconfiguration

A6 - Sensitive Data Exposure

A7 - Missing Function Level Access Control

A8 - Cross-Site Request Forgery (CSRF)

A9 - Using Components with Known Vulner-abilities

A10 - Unvalidated Redirects and Forwards

With regards to performing the actual audit, theOWASP website [12] provides detailed guidelinesand procedures for determining whether a systemor application is susceptible to the security flawslisted above. Throughout the course of this au-dit, these guidelines will be taken into considerationwhilst evaluating the Seafile platform. Additionallythis audit takes existing security vulnerabilities asreported on the GitHub issue tracker into consid-eration. These issues will be correlated to the vul-nerabilities as identified by the OWASP as much aspossible. In the past a series of reported securityvulnerabilities have been closed on the Github issuetracker without any apparent solution. Thereforethis audit will also describe non-results regardingthese issues as they remain relevant.

Important to note is that this audit seeks to out-line the security of Seafile’s Private Cloud stor-age platform as best as possible within the avail-able timeframe. In principle, all the security riskslisted above have been timeboxed equally. How-ever, when interesting results were found in a par-ticular area, more time was spent. Due to the lim-ited time available, no definitive statement regard-ing the security of Seafile in any of these areas canbe made. As such, all conclusions regarding the se-curity of Seafile will be based on the findings duringthe audit.

7 Results

This section presents the findings as a result of per-forming the described method in section 6. Therisks of each vulnerability will be analyzed in thesecond part of this section. Simultaneously, a briefdemonstration is provided for the identified vulner-ability which exhibits its practical applicability.

7.1 OWASP & trends

This section will describe all results with regard toOWASP and the aforementioned observed vulner-ability trends.

7.1.1 A1 - Injection

The application API was tested for SQL injec-tion vulnerabilities using SQLmap. Amongst oth-ers, the password field for opening a password-protected shared file was tested, as well as the li-brary ID in the URI for opening a library itself.Also, the HTTP headers like the CSRF token andsession ID were tested. Neither of these fields were

5

Alg. Iter. Salt* Hash*

PBKDF2 1000 07719cfd[. . . ] acc905bf[. . . ]

* 256-bit

Table 1: Password storage format

found vulnerable for SQL injection. Since Seafileuses Object Relational Mapping (ORM) includedwith the Django framework, which is used by lotsof applications and has been subject by lots of pen-tests, it was very unlikely beforehand to find anyvulnerabilities in this section of the application.

7.1.2 A2 - Authentication and Sessions

Authentication and session management is split upin a number of elements. First, password hashingand policies will be discussed, after which the sub-ject will be changed to session management.

Password storageAccording to GitHub issues [18, 19, 20], Seafile al-legedly applied weak password hashing. Besidesusing SHA-1 to store user passwords, a static saltwas used for every user. Most interesting however,was that passwords were hashed in the wrong way.When salting passwords, the salt should be hashedbefore the the password is. In prior versions ofSeafile, this was done the other way around, effec-tively diminishing the added complexity of using asalt. In more recent versions, 1000 iterations of thePBKDF2 algorithm is used, storing a unique one-way password hash, derived from a per-user uniquesalt and a password as input. These elements arestored per user in the database, as depicted in ta-ble 1. Additional research is required to guaran-tee the cryptographic strength of this new hashingmethodology. This is discussed in more detail in10.

Password policyBy default, Seafile enforces so-called complex pass-words. On user creation, a one time password isgenerated either by the Javascript Math.random(),or by the administrator. This password is notbound by any complexity requirements. The cre-dentials are then mailed in clear-text to the user.On the first successful logon attempt the user isobliged to create a new password, which shouldconsist out of at least eight characters containingat least a special-character, number and uppercaseletter.

Session managementSession ID’s consist of 32 character alphanumericcase insensitive strings. Upon visiting the web por-tal unauthenticated, the server passes a Set-CookieHTTP header to the client, containing a session ID.From this moment on, the client embeds this iden-tifier in the Cookie HTTP header. After logging in,

the session ID is rotated. Only the new session IDis usable to visit the authenticated parts of Seafile.Using the old Session ID results in a redirect to thelogin page. Furthermore, Session IDs have a nineday timeout period. After logging out, the SessionID is properly deactivated by the webserver.

When using the API, a 64 bit hexadecimal APItoken is obtained using the auth-token API call.Based on a combination of the user, platform, andIP address the API returns an (existing) API token,depending on whether the user already obtained anAPI token from this platform before. If no APItoken for this user/platform combination exists, aSHA1 HMAC is obtained from a generated UUIDas displayed in listing 1. Although revoking API to-kens obtained by authenticating with mobile appsfor iOS/Android is working correctly, we found noway of withdrawing API tokens that were addedby using curl. Also, API tokens don’t have anytimeout mechanism employed.

def generate key ( s e l f ) :unique = str ( uuid . uuid4 ( ) )return hmac . new( unique , digestmod=sha1 )

↪→ . h exd ige s t ( )

Listing 1: API Token generation (excerpt fromauth/tokens.py)

7.1.3 A3 - Cross-Site Scripting

Besides storing data, Seafile allows a user to cre-ate a Wiki page within the web interface. TheWiki pages, usernames and attributes like tele-phone number or department, file, folder and li-brary names, notifications and groups were ex-tensively tested for XSS vulnerabilities. This re-sulted in two findings. First is the registrationof new users. Although it’s disabled by default,it’s possible to register with an e-mail address like"<script>alert(1)</script>"@os3.nl. Oncesaved in the database, it causes the administratorsto be unable to list any existing users. The issue isresolved once the user’s record is manually removedfrom the database.

The Wiki pages are, from a theoretical perspectivealso vulnerable for Cross-site Scripting. Althoughall HTML tags shipped with user-input is properlysanitized and escaped, it’s possible to display animage or URL pointing to an external source, usingthe Markdown editor for Wiki pages. However,the input ending up in the img src and a href

tags is not properly escaped and therefore mayinclude HTML tags and JavaScript code. We werenot able to exploit this flaw, as the markdown.js

plugin does not provide escaping of parentheses.This causes any entered JavaScript to miss theclosing parentheses as shown in listing 2.

6

<img src=” j a v a s c r i p t : a l e r t (1 ”>

Listing 2: Wiki page XSS result

7.1.4 A4 - Direct object referencing

Although directory traversal was not found appli-cable, we were able to find two API calls whereparameters were not sufficiently checked. A ma-jor flaw exists enabling any authenticated user topublish arbitrary libraries to a public URL. This iscaused by the share/ajax/get-download-link/

URI which performs insufficient authorizationchecking. In listing 3 a Proof of Concept (PoC)is demonstrated in which an authenticated usersets the repo id to a library which doesn’t belongto the authenticated user account. The applica-tion willingly presents a download link which isopen for everyone with network access to the Seafileserver. From this URL, the library can be exploredand any file could be downloaded. If the targetedlibrary is encrypted, metadata like filenames arestill visible in plain, and the encrypted files canbe downloaded as well. This leaking of metadatainformation regarding encrypted libraries has beenreported nearly three years ago in a GitHub issue[8] and remains to be fixed.

$ cu r l [ . . . ] ht tps : // s e a f i l e . t e s t i n g . local /↪→ share / ajax /get−download−l i n k / −−data↪→ ”use passwd=0&repo id=a34c48dd−4e9f↪→ −4a32−98c0−1e54 f f 502697&p=%2F&type=d↪→ ”

{” token” : ”2364921741” , ” download l ink ” : ”↪→ https : // s e a f i l e . t e s t i n g . l o c a l /d↪→ /2364921741/”}

Listing 3: Sharing an arbitrary library, opening it upto the internet.

A second vulnerability concerned a minor flaw inthe Wiki pages. After enabling the Wiki for thecurrently logged in user, an existing library can beselected to be used for the Wiki pages. The li-brary ID for this request can be forged to point toanother user’s library. Although editing or view-ing files is not possible, a user now does have theability to create arbitrary files in the destinationlibrary without the consent of the library’s owner.

7.1.5 A5 - Security misconfiguration

With regard to security misconfigurations this sec-tion will cover used local OS changes and applica-tion specific settings.

InstallationAs discussed in section 5.5.1, Seafile is divided inseveral components. The Ccnet RPC daemon ismerely offering functionality for local processes,

hence it’s only available locally. Nginx is proxy-ing all HTTP traffic to the Seahub deamon, whichtherefore doesn’t have any sockets open to the in-ternet. Nginx correctly redirects all HTTP con-nection attempts to port 443. Furthermore, it alsofunctions as a broker to the Seafile daemon throughthe /seafhttp URI. However, the Seafile daemon,which takes care of chunked traffic, also directlyexposed by listening on port 8082. Supporting ser-vices like databases and caching daemons are onlyavailable to processes on the local host. During theinstallation a new user is created under which Cc-net, Seahub and Seafile are ran. This user only haswrite access in /opt and /var/tmp. Furthermore,the installation script generates a random passwordwhich is set for the administrator. No default pass-words are enabled after the installation.

Application and configurationSince password and session management has pre-viously been discussed, this paragraph won’t dis-cuss these components. Under no circumstances wefound any error logging served to the client. Userregistration is disabled by default, so unauthenti-cated users are unable to post any content to theapplication, except for the URI obtaining an APItoken or session ID.

7.1.6 A6 - Sensitive data exposure

Except for using SHA1 to obfuscate API tokenUUID’s, Seafile uses a safe set of encryption andhashing algorithms. As discussed in section 7.1.2,passwords are stored in a safe manner. The nextparagraphs will cover encryption of stored files,and subsequently file ID randomness. This sectionwill conclude by discussing encryption used by thechunk upload/download component of Seafile.

File Storage EncryptionSeafile offers the ability to create encrypted li-braries. All files in such a library will be encryptedusing the same key. Upon entering the passwordwhen accessing an encrypted library, a key is gen-erated. Also, a magic string is generated based ona concatenated string based on the library ID andthe password. This will later be used to verify theentered password.

Files stored on disk are encrypted using AES-256CBC. However, the source code also contains meth-ods to encrypt and decrypt data using AES-128 inECB mode for backwards compatibility, implyingthat there are still Seafile servers in the wild usingpoor encryption.

Furthermore, Seafile has allegedly been reusing Ini-tialization Vectors (IVs) in the past [8]. Althoughthe issue was reported three years ago, it’s still notfixed. Therefore, an attacker is able to leveragea known plaintext attack to guess the encryption

7

key. Furthermore, patterns may be discovered inencrypted data.

Network securityFile uploads to the Seafile server are forced to per-form a TLS handshake before connecting. How-ever, the server doesn’t send an HTTP StrictTransport Security (HSTS) header, enabling an at-tacker to redirect requests over plain HTTP.

With regards to Nginx, the default selfsigned certificate which is generated when in-stalling the Seafile server includes support forTLS FALLBACK SCSV. This parameter preventsa client from forcefully renegotiating weak(er)cipher suites, thus effectively preventing SSL/TLSdowngrade attacks.

Figure 4: Entropy of the share ID values as generatedby Seafile

File ID randomnessOne of the areas of interest identified in section 4was the use of bad randomness generators. Whensharing files to unauthorized users, Seafile auto-matically generates a random URI on which thefile is made available. They random string of theURI consists of 10 alphanumeric characters whichtheoretically means that it would be possible to tra-verse all shared files by repeatedly requesting therandom strings. We evaluated whether this mech-anism uses an invalid source of randomness. How-ever, as depicted in figure 4, nearly all measure-ments are proven to be random. The dataset ofshared files consists of approximately 450.000 en-tries. Within this amount of entries, eight doublevalues were found. The idea is that if any patternsare visible in the plot it would not be required totraverse the whole keyspace. However, due to thelow amount of double entries, no consistent patternwas determined.

7.1.7 A7 - Missing function level accesscontrol

With regard to the web interface and the API, noserious flaws were found in terms of missing ac-cess control. Also no URIs were found to leak in-formation. Seahub has implemented various ratelimiting functionalities to prevent a large numberof subsequent access attempts. The login pagepresents captcha’s when it detects a successive se-ries of failed login attempts. Additionally, the APIrate limits access attempts as shown in listing 4.

$ whi l e read l i n e ; do cu r l −d ”username=↪→ j schutrup@os3 . n l&password=$ l i n e ”↪→ https : // s e a f i l e . t e s t i n g . l o c a l / api2 /↪→ auth−token/ −k ; done <./password . l s t

{” n o n f i e l d e r r o r s ” : [ ” Unable to l o g i n with↪→ provided c r e d e n t i a l s . ” ]}{”↪→ n o n f i e l d e r r o r s ” : [ ” Unable to l o g i n↪→ with provided c r e d e n t i a l s . ” ]}{”↪→ d e t a i l ” : ” Request was t h r o t t l e d .↪→ Expected av a i l a b l e in 60 .0 seconds↪→ . ”}

Listing 4: Authentication rate limiting on web API

However, when sharing a library or file and set-ting a password to prevent unauthorized access, itis possible to perform a brute-force attack to thepassword field1 without any form of rate limiting.This effectively enables an unauthorized attackerto gain access to the repository given that enoughresources are available.

7.1.8 A8 - Cross-Site request forgery(CSRF)

Seahub is built on top of Django and this frame-work performs CSRF header checking by defaultfor all PUT and POST requests. Although it ispossible for a method to opt-out for CSRF check-ing, this is not the case in any of the views. Nooccurrences of the opt-out method were detectedin the source code.

7.1.9 A9 - Using components with knownvulnerabilities

Another area of interest identified in section 4 wasthe use of third party libraries. Contrary to own-Cloud, Seafile does not feature a plug-in platformin which third party extensions can be loaded. Thisinherently provides some level of security. Ad-ditionally, both variants of the installation scriptdownload the latest libraries that are applicablefor the provided architecture. Except for the djan-gorest framework, no reported vulnerabilities werefound for used libaries. The djangorest v3.3.2framework used by Seafile is one version behind,and has a reported bug concerning a missing CSRFheader when using the HTML renderer for the API.

1https://seafile.testing.local/d/<ID>/

8

However, this renderer is not used by Seafile, limit-ing the exploitability for this security flaw. For alllibraries, Seafile is of course vulnerable for Zero-dayvulnerabilities.

7.1.10 A10 - Unvalidated redirects and for-wards

We found no methods of redirecting visitors of thetrusted URI to an untrusted website.

7.2 Vulnerability indexing

This section discusses the identified and exploitablevulnerabilities during this research and presentsa rating for each. The OWASP risk assessmentmethod [21] served as a framework to classify andscore the vulnerabilities. Due to the nature of thisreport we are primarily interested in the technicalimpact of the vulnerabilities. As such, the businessimpact analysis of the assessment methodology hasbeen omitted.

7.2.1 User registration input may causeDoS for admin panel

For this vulnerability, refer to Table 2 and Ap-pendice A. Due to a bug in the administrator’sview for listing registered users, the table contain-ing the users may be displayed empty if a user’semail address contains XSS-like input. Althoughuser registration is disabled by default, deploy-ments with registration enabled may suffer fromthis bug since user administration in the usual fash-ion is not possible if the database contains such auser. The bug may be resolved by performing moreextensive input sanitation for the registration form.Additionally, it would be advisable to reassess theDjango HTML view itself, since invalid user inputshould under no circumstance affect other users ofthe platform.

Details with regard to this vulnerability are to befound in appendix A. Naturally, the risk of this vul-nerability is highly influenced by whether the userregistration panel is publicly accessible via the In-ternet. It should be noted that the vulnerabilityfactors rating is inflated, as user registration is dis-abled by default. Additionally, the exploit may po-tentially be traceable to an IP address.

7.2.2 Insufficient parameter checking

For this vulnerability, refer to Table 3 and Ap-pendice B. Due to insufficient access control vali-dation, users with an activated account on a Seafileinstallation are able to share arbitrary libraries.Also, they are able to use another user’s libraryfor creating a Wiki without the consent of that li-brary’s owner.

Sharing librariesAs can be seen in appendix B, a malicious userwith the possession of another user’s library ID caneasily request a share URL, enabling anonymousvisitors of this URL to download an entire library.As this library ID is included in the URL of anyusers web interface by default, copying and pastinga link to the library would be enough to reveal theID.

If such a library is encrypted, metadata like filenames are still readable in plain-text, and files,although encrypted, may be downloaded as well.The owner of the library will not be notified when-ever this vulnerability is exploited. Also, as de-picted in the appendix, he is not able to see hislibrary is shared. The user abusing this flaw,will see the library to be appended to its list ofshared libraries. In order to fix this vulnerabil-ity, the /share/ajax/get-download-link/ shouldperform sufficient permission checking. Only theowner of the library should be able to publicly shareit. Due to the nature of this vulnerability, a basiclevel of access to the platform is required.

The vulnerability factors rating of this vulnerabil-ity are slightly skewed due to the fact that thisexploit requires an activated user account on theplatform. With regards to the technical impact,this exploit is non-disruptive. Data is only accessedand no risk of corruption exists. However, poten-tially all data can be disclosed which is detrimentalfor the confidentiality. Also, it is possible to tracethis exploit back to the attacker as a user accountis required on the platform.

Create arbitrary filesA similar flaw in the Seafile web API can lead tothe creation of arbitrary *.md files in another user’slibrary. Due to not performing the ownership checkon a library when enabling the Wiki for a user, anyuser is potentially able to pollute any other user’slibrary. Once again, as these files only contain text,no real techincal impact can be identified.

7.2.3 Brute forcing password of shared li-brary

For this vulnerability, refer to Table 4. The pass-word field for opening a password-protected sharedlibrary is not protected with any kind of rate-limiting. Since the URI for opening a shared libraryis accessible to anonymous Internet users, and nopassword policy is being enforced for this field, thisvulnerability is easily exploitable by a large groupof users. When successful, a complete library maybecome available to anonymous users without theconsent of the repository’s owner. Furthermore, be-sides the general HTTP access logs, no explicit log-ging of access attempts are being performed, leav-

9

User registration input may cause DoS for admin panel A3

Description: Leveraging arbitrary Cross Site Scripting (XSS) code in the user reg-istration panel causes the administrator panel to fail rendering.

Threat Agent Factors Rating

Skill level Some technical skills 3Opportunity No access or resources required 9Motive Low or no reward 1Size Anonymous Internet users (Depending on web panel access rights) 9

Overall rating: 5.5

Vulnerability Factors Rating

Ease of discovery Automated tools available 9Ease of exploit Automated tools available 9Awareness Obvious 6Intrusion detection Logged without review 8

Overall rating: 8

Technical Impact Rating

Loss of confidentiality Minimal non-sensitive data disclosed 2Loss of integrity Minimal slightly corrupt data 1Loss of availability Extensive secondary services interrupted 5Loss of acountability Possibly traceable 7

Overall rating: 3.75

Table 2: Risk evaluation: User registration input may cause DoS for admin panel

Unprivileged public sharing of arbitrary user library A4

Description: Insufficient authorization checking when publicly sharing libraries al-lows for unauthorized access to files.

Threat Agent Factors Rating

Skill level Network and programming skills 6Opportunity Some access or resources required 7Motive High reward 9Size Authenticated users 6

Overall rating: 7

Vulnerability Factors Rating

Ease of discovery Easy 7Ease of exploit Difficult 3Awareness Unknown 6Intrusion detection Not logged 9

Overall rating: 6,25

Technical Impact Rating

Loss of confidentiality All data disclosed 9Loss of integrity Minimal seriously corrupt data 1Loss of availability Minimal secondary services interrupted 1Loss of acountability Possibly traceable 7

Overall rating: 4.5

Table 3: Risk evaluation: Unprivileged public sharing of arbitrary user library

10

Brute forcing password of shared library A7

Description: Shared, password protected libraries are susceptible to an onlinebrute-force attack due to the lack of rate limiting on the credentialverification.

Threat Agent Factors Rating

Skill level Some technical skills 3Opportunity No access or resources required 9Motive Possible reward 4Size Anonymous Internet users 9

Overall rating: 6.5

Vulnerability Factors Rating

Ease of discovery Easy 5Ease of exploit Automated tools available 9Awareness Unknown 1Intrusion detection Logged without review 8

Overall rating: 5.75

Technical Impact Rating

Loss of confidentiality All data disclosed 9Loss of integrity Minimal slightly corrupt data 1Loss of availability Minimal primary services interrupted 5Loss of acountability Possibly traceable 7

Overall rating: 5.5

Table 4: Risk evaluation: Brute forcing password of shared library

ing the data owner unnoticed. As rate limiting isalready being performed on the login page, it’s ad-vised to enable it as well for opening a password-protected shared library.

Once again, the effective risk of this vulnerabilityis highly influenced by whether the user registra-tion panel is publicly accessible via the Internet.The risk evaluation assumes that Internet accessis possible. Therefore, the overall ratings may beinflated. With regards to the technical impact, aslight risk of data corruption is present as bruteforcing the library requires a large amount of re-quests to the web server. As such, a slight risk of aDoS causing data corruption is present. Addition-ally, the exploit may potentially be traceable to anIP address.

8 Discussion

Judging by the reported security issues in the past,the initial hypothesis when going into the secu-rity audit was that the security of Seafiles plat-form as a whole would be below par. Surprisinglyenough however, the contrary was true. A largeseries of the previously reported vulnerabilities inthe product have been patched, are deemed lessvulnerable than initially thought or are not appli-cable anymore. Additionally, the developers imple-mented a plethora of general security measures like

captchas, periodic renewal of administrative cre-dentials and rights management. Also the server-side configuration of Seafile seems well thought outwith correct file permissions, strong certificates andjust enough communication between components.Of course, this is assuming that the secure installscript is used. For a large part the security ofSeafiles web front-end is provided by the tried andtested Django framework which allows the devel-opers to leverage commonly used cryptographic li-braries and built-in security measures such as CrossSite Request Forgery protection and SQL injectionprotection.

However, as presented in the results, not all of thereported issues were rectified which is worrying.Two of the GitHub issues regarding the reuse ofInitialization Vectors and the possibility of retriev-ing metadata from an encrypted library are stillpresent after nearly three years. It isn’t unreason-able to expect that these issues would be resolvedby now. Additionally, reviewing the source codereveals that at points sloppy coding creates (signif-icant) vulnerabilities. For example the brute forc-ing vulnerability of the password field. While therest of the web application performs correct ratelimiting, a single field was missed. Lastly, the factthat the included installer in the downloaded pack-age by default is not a secure version while a secureversion is available hurts the security of the averageSeafile deployment as a whole.

11

Common vulnerabilitiesIn the preliminary research we evaluated commonvulnerabilities for other private cloud storage so-lutions. Due to its popularity we were only ableto find a significant amount of reported vulnera-bilities for ownCloud. Naturally, as both platformsprovide a web interface, the identified common vul-nerabilities also apply to some extent to Seafile’splatform. All areas of interest have been coveredin detail in section 7. During the audit we sawthat the libraries used by Seafile did not have anyreported vulnerabilities in this instance. However,this raises questions about whether these librariesare really secure or whether they are simply notthoroughly checked. ownCloud for example uses adifferent set of libraries which have been examinedmultiple times in the past by various independentreviewers. Also, incorrectly applying cryptographyhas also been found in Seafile as the issue with thereuse of Initialization vectors is still present. Lastly,incorrect parameter checking in the web client alsoallows for performing the brute force attack.

9 Conclusion

In this paper, we have evaluated the overall secu-rity of Seafile’s Private Cloud storage platform byperforming a scoped security audit. More specifi-cally we assessed the security of the web front-end’Seahub’. The product has been evaluated by test-ing for its susceptibility to common vulnerabilitiesas described in the OWASP Top Ten. Additionally,unresolved security issues reported in the past andvulnerability trends examined at competitor own-Cloud have been taken into account. We present aseries of vulnerabilities ranging in severity. Finallythe vulnerabilities have been scored following theOWASP Risk Rating Methodology.

Our results indicate that the Seafile as a stor-age platform has matured significantly in recentyears due to the implementation of tried and testedframeworks. Still, this report presents a seriesof security vulnerabilities caused primarily due tosloppy coding. Most notably a high risk vul-nerability which allows for the unprivileged pub-lic sharing of any arbitrary user library. Due tothe limited resources and access rights requiredthis vulnerability has been classified as high risk.Furthermore, shared, password protected librarieshave been found to be susceptible to online brute-force attacks due to the lack of rate limiting onthe credential field. Less severe is a vulnerabilitythat allows for disrupting the administrator’s work-flow by performing a Cross Site Scripting attack.Lastly, some previously reported vulnerabilities inthe platform are still present.

Moving forward we advise a full code base review

for Seafile, as a large amount of the uncovered vul-nerabilities can be fixed by consistently applyingsecurity policies in the code. Additionally we sug-gest shrinking the overall code base, as the currentredundancy increases the potential for error.

Considering the time frame and limitations im-posed by the scope of this audit, we conclude thatSeafile’s private cloud platform is susceptible tovarious attacks. These flaws can largely be at-tributed to invalid implementations of the frame-work and general coding mistakes.

10 Future Work

This report primarily focuses on the server compo-nents and modules of Seafile’s private cloud solu-tion. Seafile also provides a plethora of methodsto interface with the cloud platform from an enduser perspective. At the time of writing there areofficial client applications available for the majormobile operating systems Android and iOS. Addi-tionally desktop clients are available for Windows,Mac and Linux. A quick look through the issuetracker of these projects reveals that there is stillwork to be done regarding security [22, 23, 24].

Furthermore this audit only evaluated the securityof Seafile’s free and open source ’Community Edi-tion’. However, as previously mentioned a Pro Edi-tion of the platform is available which includes ad-ditional security sensitive features like Role BasedAccount Management, fine-grained folder permis-sions and authentication to Active Directory (AD)servers [25]. Additionally, this version includes sup-port for custom storage back-ends such as Ceph orAmazon Web Services (AWS) S3 which may be sus-ceptible to security vulnerabilities themselves. Dueto the overall impopularity of Seafile as a whole itmay be interesting to perform a similar securityaudit on its commercial variant. The methodologyused in this report could potentially be taken as astarting point.

Also, the strength of Seafile’s crypto implementa-tion has been debated in the past [8]. As this doc-ument aims to present a broad audit of the plat-form only a brief look at the randomness generatorhas been taken. A detailed investigation into theseclaims is required to rule out this potential vulner-ability. Therefore we suggest a full code review ofthe back-end services. These are mainly written inC and may be susceptible to buffer overflows.

At last, it may be rewarding to further look into thevulnerability concerning the administrator panelDenial of Service. Although we were unable to findproof of possible code execution, there might bepotential to do so.

12

References

[1] Gartner. Gartner Says That ConsumersWill Store More Than a Third of TheirDigital Content in the Cloud by 2016.2012. url: http : / / www . gartner .

com/newsroom/id/2060215 (visited on04/17/2016).

[2] Kuyoro So. “Cloud computing securityissues and challenges”. In: InternationalJournal of Computer Networks 3.5 (2011).

[3] Balachandra Reddy Kandukuri, V Ra-makrishna Paturi, and Atanu Rakshit.“Cloud security issues”. In: Services Com-puting, 2009. SCC’09. IEEE InternationalConference on. IEEE. 2009, pp. 517–520.

[4] Raghu Yeluri et al. “Building trust andcompliance in the cloud for services”. In:SRII Global Conference (SRII), 2012 An-nual. IEEE. 2012, pp. 379–390.

[5] Ronald L Krutz and Russell Dean Vines.Cloud security: A comprehensive guide tosecure cloud computing. Wiley Publishing,2010.

[6] ownCloud Private cloud storage solution.https://doc.owncloud.org/. (Visitedon 05/09/2016).

[7] Ben Martini and Kim-Kwang RaymondChoo. “Cloud storage forensics: ownCloudas a case study”. In: Digital Investigation10.4 (2013), pp. 287–299.

[8] Edward Faulkner. Encrypted libraries leaklots of information Issue #350 hai-wen/seafile. 2013. url: https://github.com/haiwen/seafile/issues/350 (vis-ited on 04/17/2016).

[9] Nina Viktoria Julia Dotter and Kim-Kwang Raymond Choo. “Cloud Attackand Risk Assessment Taxonomy”. In:IEEE Cloud Computing 1 (2015), pp. 14–20.

[10] Blerim Rexha, Blerta Likaj, and HaxhiLajqi. “Assuring security in private cloudsusing ownCloud”. In: ijacit. com (2012).

[11] Wenjuan Xu, Brian Groves, and WillsonKwok. “Penetration testing on cloud—case study with owncloud”. In: GlobalJournal of Information Technology 5.2(2016), pp. 87–94.

[12] John Steven & Jim Manico. OWASP Top10. 2013. url: https://www.owasp.org/index.php/Top_10_2013-Top_10 (vis-ited on 05/09/2016).

[13] YANG Sheng et al. “Research and Appli-cation of Private Cloud Storage Platformin High Schools Based on Seafile”. In: In-telligent Networks and Intelligent Systems(ICINIS), 2013 6th International Confer-ence on. IEEE. 2013, pp. 25–28.

[14] National Institute of Standards and Tech-nology. National Vulnerability Database.2016. url: http://nvd.nist.gov/ (vis-ited on 05/09/2016).

[15] MITRE. CVE Details. 2016. url: http:/ / cvedetails . com/ (visited on05/09/2016).

[16] Danile Pan and Jonathan Xu. SeafileServer Component Overview. http :

/ / manual . seafile . com / overview /

components . html. (Visited on05/18/2016).

[17] Seafile DE. Script collection to setupproduction-ready Seafile server installa-tions with HTTPS. 2015. url: https://github.com/seafile/seafile-server-

installer (visited on 05/16/2016).

[18] Peter Heinricht. Seafile Issue #386.2014. url: https : / / github . com /

haiwen / ccnet / issues / 35 (visited on05/16/2016).

[19] Felix von Leitner. Seafile Issue #587.2014. url: https : / / github . com /

haiwen/seafile/issues/587 (visited on05/16/2016).

[20] antares2001. Seafile Issue #386. 2013.url: https : / / github . com / haiwen /

seafile / issues / 386 (visited on05/16/2016).

[21] John Steven & Jim Manico. OWASP RiskRating Methodology. 2013. url: https :

//www.owasp.org/index.php/OWASP_

Risk _ Rating _ Methodology (visited on05/09/2016).

[22] Nils Hesse. Encrypted files are saved inplaintext for cache - Issue 52 - hai-wen/seadroid. 2014. url: https : / /

github.com/haiwen/seadroid/issues/

52 (visited on 05/16/2016).

[23] antares2001. Seafile does not log outusers on password change (seafile usermanagement and ldap). - issue 416 -haiwen/seafile-client. 2015. url: https:

/ / github . com / haiwen / seafile -

client / issues / 416 (visited on05/16/2016).

13

[24] Chilledfire. Disable weak ciphers explicitlypull request 556 - haiwen/seafile-client.2015. url: https : / / github . com /

haiwen/seafile-client/pull/556 (vis-ited on 05/16/2016).

[25] Seafile. Feature Comparison of SeafileCommunity and Professional versions.2016. url: https://www.seafile.com/en/product/private_server/ (visitedon 05/16/2016).

14

Appendix A – Register User

Figure A5: Register a new user

Figure A6: After registering, administrator lists all users

15

Appendix B – Share Library

$ curl --cookie "csrftoken=DyJ6haoOjmNNxMmZxvjmhpuYQHoI1J5d; sessionid=od3coy4dn2sg3c1

hnpn3j55xi7fvzntl" -e https://seafile.testing.local/ -k https://seafile.testing.local/

share/ajax/get-download-link/ -H "X-CSRFToken: DyJ6haoOjmNNxMmZxvjmhpuYQHoI1J5d" -H "

X-Requested-With: XMLHttpRequest" -X POST --data "use_passwd=0&repo_id=a34c48dd-4e9f-

4a32-98c0-1e54ff502697&p=%2F&type=d"

{"token": "2364921741", "download_link": "https://seafile.testing.local/d/2364921741/"}

Listing 1: Share admin his repository (200library) by exploiting the /share/ajax/get-download-link/ URI

Figure B7: The owner of the library (admin) cannot see his library (200library) is shared to a public URI byviewing his libraries

16

Figure B8: The owner of the library (admin) cannot see his library (200library) is shared to a public URI byviewing his shared libraries

Figure B9: The user who exploited the bug (test) can see he shared admin his library

17