Little-beak.com's gitlab server

nextcloud_version2.aux 15.8 KB
 drexl committed Aug 21, 2018 1 2 3 4 5 6 7 8 9 10 11 12 13 14 \relax \citation{site1} \@writefile{toc}{\contentsline {section}{\numberline {1}Executive Summary}{1}} \@writefile{toc}{\contentsline {subsection}{\numberline {1.1}Background}{1}} \citation{site2} \citation{man1} \@writefile{toc}{\contentsline {paragraph}{We have selected the open source project Nextcloud for our report. Originally, we had thought about exploring ownCloud, but apparently within a few months of this writing, co-founder and CEO Frank Karlitschek decided to leave ownCloud and fork into Nextcloud--followed, thereafter, by a majority of the core development team. At the start of this project, we had to decided which one of the two to choose, before settling on Nextcloud.}{2}} \@writefile{toc}{\contentsline {subsection}{\numberline {1.2}What is Nextcloud}{2}} \@writefile{toc}{\contentsline {paragraph}{Nextcloud, the next generation open source Enterprise File Sync and Share was started by ownCloud inventor Frank Karlitschek and a dozen experienced open source entrepreneurs and engineers to empower users to take back control over their data and communication. The company was launched in 2016 as a spin-off from Struktur AG, a leading web conferencing and financial planning software company since 1995, servicing customers like Deutsche Bank, Vodafone, BNP Paribas and many others, and turned profitable by the end of 2016. Nextcloud gives organizations fine-grained control over data access, facilitates file synchronization and sharing across devices, enables collaboration within and across organizational boundaries and lets users communicate through secure audio and video conferencing.}{2}} \@writefile{toc}{\contentsline {subsection}{\numberline {1.3}Summary of Tests, Findings \& Recommendations}{2}} \@writefile{toc}{\contentsline {paragraph}{Before we begin our tests, we will acknowledge currently known vulnerabilities. This serves two purposes:}{2}} \@writefile{toc}{\contentsline {paragraph}{First, we can limit our exploration for an already known vulnerability. Secondly, it will give us an idea of where adjacent vulnerabilities may lie.}{2}} \@writefile{toc}{\contentsline {paragraph}{As of the 8th, May 2017, Nextcloud server version 11.0.3, the known vulnerabilities according to the Nextcloud advistory, are shown in table \nobreakspace {}1\hbox {}.}{2}} \@writefile{toc}{\contentsline {paragraph}{Following is a list of common attacks, against a LAMP stack.}{2}}  drexl committed Aug 21, 2018 15 \@writefile{lot}{\contentsline {table}{\numberline {1}{\ignorespaces Vulnerabilities as of {August 21, 2018}}}{3}}  drexl committed Aug 21, 2018 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 \newlabel{tab: currentVulnerabilities}{{1}{3}} \citation{site4} \@writefile{toc}{\contentsline {paragraph}{We will go through, and carefully consider each attack vector.}{4}} \@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.1}Cross-site Request Forgery}{4}} \@writefile{toc}{\contentsline {paragraph}{An attack type that can be mitigated by the implementation of Same-site cookies. Nextcloud implements Same-site cookie, for example, in the /var/www/nextcloud/lib/base.php file, as well as the /var/www/nextcloud/core/ajax/update.php file.}{4}} \@writefile{toc}{\contentsline {paragraph}{The code from the base.php file demonstrates how Nextcloud creates Same-site cookies.}{4}} \@writefile{toc}{\contentsline {paragraph}{The update.php file exemplifies how Nextcloud implements error handling, verification, and updates the site, accordingly.}{4}} \@writefile{toc}{\contentsline {paragraph}{Browsers that support same-site cookies can be instructed in a way to only send a cookie if the request is originating from the original domain. This makes exploiting CSRF vulnerabilities from other domains a non-issue. Also timing attacks, such as enumerating whether a specific file or folder exists, are not feasible anymore. Nextcloud enforces the same-site cookies to be present on every request by enforcing this within the middleware.}{4}} \@writefile{toc}{\contentsline {paragraph}{At the moment, it doesn't appear that Nextcloud can do more to mitigate the security risks associated with CSRF type attacks, and the current safeguards are otherwise satisfactory.}{4}} \citation{man1} \@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.2}SQL Injection}{5}} \@writefile{toc}{\contentsline {paragraph}{The best protection against this type of attack vector is the usage of SQL prepared statements. As best we could, we found that Nextcloud's application only uses prepared statements within php's framework, and encourages application developers to do so as well. Here is an example that demonstrates how to create prepared statements, so there is less direct access to the database, via SQL.}{5}} \@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.3}Cross-site scripting (XSS)}{5}} \@writefile{toc}{\contentsline {paragraph}{Cross site scripting happens when user input is passed directly to templates. A potential attacker might be able to inject HTML/JavaScript into the page to steal the users session, log keyboard entries, even perform DDOS attacks on other websites or other malicious actions.}{5}} \@writefile{toc}{\contentsline {paragraph}{Nextcloud utilizes a Content-Security-Policy to enhance security, and prevent the usage of inline Javascript execution. Additionally, Nextcloud sanitizes it's templates (and JavaScript) which manipulate any DOM elements, to limit the potential for breaches.}{5}} \@writefile{toc}{\contentsline {paragraph}{According to the Nextcloud Developer's Manual, the best way to sanitize templates is to never use echo, print, and $<\%=$ commands, but instead use p(). Here is an example of vulnerable code:}{5}} \@writefile{toc}{\contentsline {paragraph}{We searched through the code for vulnerabilities of this type, in addition to, href attributes -- which can also open the door for XSS attacks, but found no weaknesses.}{5}} \@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.4}JavaScript vulnerabilities}{6}} \@writefile{toc}{\contentsline {paragraph}{We combed the code elements that allow manipulate HTML directly via JavaScript, which can lead to un-sanitized variables. Good and bad guidelines were offered in the developer manual to assist us in our search (See below):}{6}} \@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.5}Clickjacking}{6}} \@writefile{toc}{\contentsline {paragraph}{When determining how to search for Clickjacking, we had to understand how Nextcloud handles the threat of offering the user invisible x-frame to click. No one can prevent users from randomly click on whatever their hearts desire. However, Nextcloud sends the X-Frame-Options header to all template responses, which should eliminate the threat of tricking the user into exploiting x-frame vulnerabilities.}{6}} \@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.6}Code Execution/File inclusions}{6}} \@writefile{toc}{\contentsline {paragraph}{Code Execution means that an attacker can include a malicious PHP file that executes with unwanted consequences. We were unable to find a vulnerability with our manual intrusion attempts. Nextcloud further cautions to never allow users to upload files into a folder which is reachable from the URL.}{6}} \@writefile{toc}{\contentsline {paragraph}{We scanned through the application files, to try to find any examples where user-input was allowed through any of the following php functions:}{6}} \citation{man1} \@writefile{toc}{\contentsline {paragraph}{We were unsuccessful.}{7}} \@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.7}Directory Traversal/Auth Bypass/Privilege Escalations}{7}} \@writefile{toc}{\contentsline {paragraph}{Ad-hoc attempts to attack Nextcloud through Directory Traversal, AuthBypass, and privilege escalation were unsuccessful. Altering various URL inputs like "\textbackslash " and "/" did not expose any elements of the system.}{7}} \@writefile{toc}{\contentsline {paragraph}{We used the following code examples, as the basis for our scans of the Nextcloud code.}{7}} \@writefile{toc}{\contentsline {paragraph}{The better code replaces "/" "\textbackslash \textbackslash ", with the "/". This particular vulnerability was scanned with eyeballs, as it was not something that could be easily parsed with a text editor like vi.}{7}} \@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.8}Shell Injection}{7}} \@writefile{toc}{\contentsline {paragraph}{Since Nextcloud doesn't offer any type of core abilities that would allow PHP to execute shell commands, we consider this area a low risk. We did search through some elements that could conceivably use shell commands, but they did not. Unless someone codes a particular application that does so, there does not appear to be a threat from this vector.}{7}}  drexl committed Aug 21, 2018 48 49 50 \@writefile{toc}{\contentsline {subsubsection}{\numberline {1.3.9}Sensitive Data Exposure}{7}} \@writefile{toc}{\contentsline {paragraph}{Nextcloud does not store it's application location in a webroot directly, thus it cannot be accessed simply by using a web browser.}{7}} \citation{site3}  drexl committed Aug 21, 2018 51 52 53 54 55 56 \@writefile{toc}{\contentsline {subsection}{\numberline {1.4}Detailed Findings}{8}} \@writefile{toc}{\contentsline {paragraph}{In the end, we were unable to find any security vulnerabilities at this time. For an open source project, Nextcloud is mature, and well developed. With continued development, however, penetration testing will be required periodically. However, at the moment, it appears that Nextcloud has a robust security system in place, that should inspire confidence in it's users.}{8}} \@writefile{toc}{\contentsline {section}{\numberline {2}Methodology}{8}} \@writefile{toc}{\contentsline {paragraph}{The primary focus of our task was defining the methodology. We asked ourselves the followed questions:}{8}} \@writefile{toc}{\contentsline {subsection}{\numberline {2.1}Protocols \& adjacent technologies to be examined}{8}} \@writefile{toc}{\contentsline {paragraph}{In defining our scope, we consider all threats, from all attack vectors--across all relevant technologies, which would for this project, include the following areas:}{8}}  drexl committed Aug 21, 2018 57 \@writefile{toc}{\contentsline {paragraph}{Predominantly, however, the application under review will dive us deep into PHP.}{8}}  drexl committed Aug 21, 2018 58 59 60 61 62 63 64 65 66 67 68 \@writefile{toc}{\contentsline {subsection}{\numberline {2.2}Nextcloud Threat-model}{9}} \@writefile{toc}{\contentsline {paragraph}{We will, however, mostly focus our attention mostly on Nextcloud's threat model. Following is the model:}{9}} \@writefile{toc}{\contentsline {subsubsection}{\numberline {2.2.1}Administrator privileges}{9}} \@writefile{toc}{\contentsline {paragraph}{Nextcloud considers administrators ultimately trusted. It is for example expected behavior that a Nextcloud administrator can execute arbitrary code.}{9}} \@writefile{toc}{\contentsline {subsubsection}{\numberline {2.2.2}Encryption}{9}} \@writefile{toc}{\contentsline {paragraph}{Nextcloud can be configured to encrypt data at rest. In this scenario we do prevent against storage administrators mainly, we are aware that a Nextcloud administrator could still intercept the user password to manually decrypt the encryption key. We do thus only consider attack scenarios bounty-worthy if they include external parties.}{9}} \@writefile{toc}{\contentsline {subsubsection}{\numberline {2.2.3}Features intentionally marked as insecure}{9}} \@writefile{toc}{\contentsline {paragraph}{Some features in Nextcloud are intentionally marked as insecure and disabled by default (plus have a big warning above them). One example includes the preview providers such as the LibreOffice preview provider. At the moment we consider vulnerabilities in those disabled features as not bounty-worthy.}{9}} \@writefile{toc}{\contentsline {subsubsection}{\numberline {2.2.4}Attacks involving other Android apps on the device}{9}} \@writefile{toc}{\contentsline {paragraph}{We do consider attacks involving other Android apps on the device as minimal risk, also especially considering that the Nextcloud Android apps stores synced files locally accessible on the device. (since no Content Provider is yet implemented).}{9}} \@writefile{toc}{\contentsline {subsubsection}{\numberline {2.2.5}Denial of Service}{9}}  drexl committed Aug 21, 2018 69 \@writefile{toc}{\contentsline {paragraph}{Due to the usage of the PHP scripting language Nextcloud does consider Denial of Service not something that can at the moment be completely prevented. For this reason while we do fix and acknowledge specific Denial of Service attacks we do generally not consider DoS a bounty-worthy vulnerability.}{9}}  drexl committed Aug 21, 2018 70 71 72 73 74 75 76 77 78 79 80 81 \@writefile{toc}{\contentsline {subsubsection}{\numberline {2.2.6}Audit logging}{10}} \@writefile{toc}{\contentsline {paragraph}{The audit logging feature in Nextcloud is at the moment missing some logs for things like "Accessing previews of files", these will be added in a future release and known issues are tracked in our issue tracker.}{10}} \@writefile{toc}{\contentsline {subsubsection}{\numberline {2.2.7}Version disclosure}{10}} \@writefile{toc}{\contentsline {paragraph}{At the moment we consider version disclosure an accepted risk as an attacker can enumerate service versions using other means as well. (e.g. comparing behavior)}{10}} \@writefile{toc}{\contentsline {subsubsection}{\numberline {2.2.8}Content spoofing}{10}} \@writefile{toc}{\contentsline {paragraph}{Generally speaking we consider content spoofing not a bounty-worthy vulnerability.}{10}} \@writefile{toc}{\contentsline {subsubsection}{\numberline {2.2.9}User enumeration}{10}} \@writefile{toc}{\contentsline {paragraph}{We do not consider user enumeration a security risk as for convenience and for features such as Server-to-Server sharing this is an expected behavior.}{10}} \@writefile{toc}{\contentsline {subsubsection}{\numberline {2.2.10}Brute force of credentials}{10}} \@writefile{toc}{\contentsline {paragraph}{At the moment we do not consider brute-forcing of credentials or a missing password threshold eligible vulnerabilities. In the case of Nextcloud we currently expect people to protect their instance using measures such as fail2ban. We do have a native anti-bruteforce protection.}{10}} \@writefile{toc}{\contentsline {subsubsection}{\numberline {2.2.11}Server-side request forgery}{10}} \@writefile{toc}{\contentsline {paragraph}{Nextcloud ships with multiple features that perform sending requests to other hosts, we do consider this accepted behavior and advocate people to deploy Nextcloud into its own segregated network segment.}{10}}  drexl committed Aug 21, 2018 82 \@writefile{toc}{\contentsline {subsection}{\numberline {2.3}How we examined the client software}{10}}  drexl committed Aug 21, 2018 83 84 85 86 87 88 89 90 \bibcite{site1}{1} \bibcite{site2}{2} \bibcite{site3}{3} \bibcite{man1}{4} \bibcite{site4}{5} \@writefile{toc}{\contentsline {paragraph}{We used a two-pronged approach. First, we used manual penetration testing to try and "break" the system. Using the web as a source, we were able to find previously successful attack methods (against other systems), and try them against Nextcloud. This gave us examples of malicious javascript and php files that we could try. Additionally, it gave us an idea of how we could attempt to 'hack' Nextcloud. Lastly, we used methods learned throughout the course of how we could compromise Nextcloud.}{11}} \@writefile{toc}{\contentsline {paragraph}{The second phase involved digging into the source code, and searching for sloppy code that could lead to system breaches. We relied heavily on the Nextcloud Developer's manual--and to a lesser extent Nextcloud's Administrator Manual--for highlighting of best practices, as well as things to be avoided. The amount of code to read was copious. It's understandable why often times security analysis relies on automated software. However, nothing is as good as a few good eyeballs. Additionally, we found it rewarding to work with vi and bash, to allow us to quickly parse through code, that otherwise would have been more laborious without.}{11}} \@writefile{toc}{\contentsline {paragraph}{Lastly, we tried to balance our tests, against the Nextcloud threat model. It doesn't make sense to bother with things that they, themselves, deem outside of their scope, e.g. DoS attacks, for example.}{11}}