Danielyan Consulting Ltd Registered in England. Reg. No: 08713348

www.danielyan.com Director & Principal Consultant: Edgar Ter Danielyan FBCS CITP

DANIELYAN CONSULTING LTD

PENETRATION TESTING & SECURITY ENGINEERING SINCE 2013

www.danielyan.com

Penetration Test Report PREPARED FOR: Clinical Informatics Research Unit DATE: 19 March 2021

2

Contents About Danielyan Consulting .................................................... 3Executive Summary ............................................................. 4Scope ......................................................................... 4Objectives .................................................................... 4Note on Security Assurance .................................................... 5Indicative Level of Assurance ................................................. 6CWE Top 25 Most Dangerous Software Weaknesses ................................. 7OWASP Top 10 Web Application Security Risks ................................... 8Findings and Recommendations .................................................. 9Critical findings ............................................................ 10None. ...................................................................... 10

High risk findings ........................................................... 11H-01. Insecure and/or compromised passwords are accepted ................... 11

Medium risk findings ......................................................... 12M-01. User enumeration using forgotten password reset mechanism ............ 12M-02. Vulnerable jquery in use ............................................. 13M-03. Secure flag missing .................................................. 14

Good practice recommendations ................................................ 15GP-01. Server header ....................................................... 15GP-02. Path-relative CSS imports ........................................... 16

3

About Danielyan Consulting Danielyan Consulting is a specialist provider of cyber security assurance services including penetration testing, security engineering and incident response since 2013. We provide security engineering and penetration testing consultancy to help you build, test and operate secure applications and infrastructure fit for the Digital Age. Danielyan Consulting was established in 2013 by Edgar Ter Danielyan, FBCS CITP, who previously held senior technology security roles at Microsoft, Skype, Citigroup, Deloitte, the Institute of Cancer Research and the Royal Bank of Scotland, among other organisations, for over 20 years. For more information about our services please visit www.danielyan.com

4

Executive Summary Following Web application penetration testing of the targets in scope we are pleased to submit this report documenting our findings and recommendations for your consideration. Following re-testing of the identified findings we are pleased to confirm that all high risk and medium risk findings have been addressed. A certificate of testing is attached for third-party assurance purposes.

Scope The scope of this engagement was agreed as follows: Test instance of the EDGE 2 application: https://edge-pen-test.uksouth.cloudapp.azure.com/ Contexts: user, administrator

Objectives The objective of this engagement was to identify any misconfiguration, security weaknesses or software vulnerabilities that may affect the secure operation of the application/infrastructure tested and to make recommendations to address them as appropriate in accordance with risk and good practice.

5

Note on Security Assurance Please note that no testing or assessment can guarantee totally secure operation of the application/infrastructure in all circumstances or identification of all possible vulnerabilities or weaknesses present, in particular due to external dependencies, changes in and trust relationships between internal and external software components and underlying infrastructure. A penetration test is a point in time statement of discovered security weaknesses - it gives a starting point for remediation activities but in itself is not a guarantee of security, absence of vulnerabilities or a solution to identified security weaknesses. The findings and recommendations contained in this report should be addressed as part of a comprehensive security management programme, including appropriate secure software development lifecycle processes such as those described in the Building Security In Maturity Model (BSIMM) Software Security Framework. Development and release of secure applications is an iterative and continuous process due to constantly changing security threats and vulnerabilities in underlying software. Secure development processes and practices should be embedded into software development lifecycle to be in position to release consistently secure code - penetration testing is a necessary part of such practices but is only effective when performed alongside other key processes recommended by the BSIMM Software Security Framework. For more information about BSIMM please visit www.bsimm.com

6

Indicative Level of Assurance The levels of assurance below are intended to give a high level relative indication of the position of the application or infrastructure tested in terms of its overall security posture, ‘0’ being lack of any assurance and ‘5’ being maximum possible security assurance: 5 Application/infrastructure has no identified vulnerabilities;

its security architecture has been reviewed and is adequate.

4 Application/infrastructure has no identified vulnerabilities but we have not reviewed its security architecture.

3 Application/infrastructure has no critical or high-risk vulnerabilities, but we have not reviewed its security architecture.

2 Application/infrastructure contains vulnerabilities that may allow compromise in some circumstances.

1 Application/infrastructure has been partly compromised.

0 Application/infrastructure has been completely compromised. Please note definition of compromise in the above indicator is a wide one and is based on our professional judgment taking into account other applications or infrastructure tested as well as industry and user expectations. Assurance level ‘5’ is very rarely reached; most tested applications or infrastructure fall under levels ‘1’, ‘2’ or ‘3’.

7

CWE Top 25 Most Dangerous Software Weaknesses The 2020 Common Weakness Enumeration (CWE™) Top 25 Most Dangerous Software Weaknesses (CWE Top 25) is a demonstrative list of the most common and impactful issues experienced over the previous two calendar years. These weaknesses are dangerous because they are often easy to find, exploit, and can allow adversaries to completely take over a system, steal data, or prevent an application from working. The CWE Top 25 is a valuable community resource that can help developers, testers, and users — as well as project managers, security researchers, and educators — provide insight into the most severe and current security weaknesses. Rank ID Description [1] CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') [2] CWE-787 Out-of-bounds Write [3] CWE-20 Improper Input Validation [4] CWE-125 Out-of-bounds Read [5] CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer [6] CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') [7] CWE-200 Exposure of Sensitive Information to an Unauthorized Actor [8] CWE-416 Use After Free [9] CWE-352 Cross-Site Request Forgery (CSRF) [10] CWE-78 Improper Neutralization of Special Elements used in an OS Command [11] CWE-190 Integer Overflow or Wraparound [12] CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') [13] CWE-476 NULL Pointer Dereference [14] CWE-287 Improper Authentication [15] CWE-434 Unrestricted Upload of File with Dangerous Type [16] CWE-732 Incorrect Permission Assignment for Critical Resource [17] CWE-94 Improper Control of Generation of Code ('Code Injection') [18] CWE-522 Insufficiently Protected Credentials [19] CWE-611 Improper Restriction of XML External Entity Reference [20] CWE-798 Use of Hard-coded Credentials [21] CWE-502 Deserialization of Untrusted Data [22] CWE-269 Improper Privilege Management [23] CWE-400 Uncontrolled Resource Consumption [24] CWE-306 Missing Authentication for Critical Function [25] CWE-862 Missing Authorization Source: cwe.mitre.org

8

OWASP Top 10 Web Application Security Risks 1. Injection. Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. 2. Broken Authentication. Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently. 3. Sensitive Data Exposure. Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser. 4. XML External Entities (XXE). Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks. 5. Broken Access Control. Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc. 6. Security Misconfiguration. Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion. 7. Cross-Site Scripting (XSS). XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites. 8. Insecure Deserialization. Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks. 9. Using Components with Known Vulnerabilities. Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts. 10. Insufficient Logging & Monitoring. Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring. Source: www.owasp.org

9

Findings and Recommendations Findings presented below are risk-rated and prioritised to assist in relative prioritisation of their remediation activities as follows: Priority Risk Indicative CVSS 3.0 base scores 1 Critical 9-10 2 High 7-8.9 3 Medium 4-6.9 A CVSS 3.0 base score is a product of two sets of metrics: the Exploitability metrics and the Impact metrics. The Exploitability metrics reflect the ease and technical means by which the vulnerability can be exploited. That is, they represent characteristics of the thing that is vulnerable (the vulnerable component). On the other hand, the Impact metrics reflect the direct consequence of a successful exploit, and represent the consequence to the thing that suffers the impact (the impacted component). The base score can be further modified by two other metric groups: the Temporal metric group reflects the characteristics of a vulnerability that may change over time but not across user environments. For example, the presence of a simple-to-use exploit kit would increase the CVSS score, while the creation of an official patch would decrease it. The Environmental metric group represents the characteristics of a vulnerability that are relevant and unique to a particular user's environment. These metrics allow the scoring analyst to incorporate security controls which may mitigate any consequences, as well as promote or demote the importance of a vulnerable system according to her business risk. It is therefore important to note that the CVSS 3.0 scores are indicative and are subject to change over time and in light of new information. Low risk findings, if any, are not reported since they do not constitute a material or significant risk and do not affect assurance level obtained. It is important to note that actual risk of a particular finding will depend on a number of time- and context-dependent factors at the time of any attack as well as presence of other weaknesses or vulnerabilities, knowledge of the attacker, any attack mitigation controls and mechanisms, and therefore actual risk of a particular finding will change over time and may be different in different environments. It is recommended that all findings be addressed in order of risk and re-tested to confirm their remediation. Contents of any reports issued by Danielyan Consulting Ltd are at absolute professional discretion of Danielyan Consulting Ltd in accordance with the agreed scope and our terms and conditions of business. In particular the risk assessment, rating or description of any findings, issues or recommendations are at absolute discretion of Danielyan Consulting Ltd.

10

Critical findings

None.

11

High risk findings

H-01. Insecure and/or compromised passwords are accepted The application performs some password validation but fails to stop the use of widely known and published insecure and/or compromised passwords such as ‘Password1’. The application does not support two factor authentication (2FA), which further increases the risk of unauthorised access using weak or compromised passwords. The application allows user enumeration (as documented in finding M-01) which may allow attackers to confirm registered accounts and target them accordingly. The combined impact of the above factors indicates in our opinion a high risk of potential unauthorised access in some circumstances. Recommendations 1. It is recommended to implement more effective password validation, specifically including checks for previously compromised published passwords, by using appropriate APIs such as the following: https://haveibeenpwned.com/API/v3 https://auth0.com/docs/attack-protection/breached-password-detection 2. It is recommended to implement 2FA to address the fundamental insecurity of password authentication over insecure networks. The following NHS policy and practice may be relevant to this finding: “The NHSmail Password Policy was updated in line with guidance from the National Cyber Security Centre (NCSC) and a new micro-service was launched to dynamically identify and block the use of common and compromised passwords using global intelligence. At the time of writing, we now stop around 100,000 weak passwords from being registered against NHSmail.” Source: https://digital.nhs.uk/blog/transformation-blog/2020/nhsmail-automation-delivers-improved-security-and-resilience “6.1.3. Password blacklisting Password blacklisting shall be used where appropriate to prevent the use of commonly used passwords. Password blacklisting shall be used where appropriate to prevent the reuse of recent previously used passwords. The password blacklist shall be updated on a regular basis based on published password breaches.” Source: https://www.whatdotheyknow.com/request/627162/response/1501784/attach/9/Password%20Policy%20Redacted.pdf Status: Finding addressed.

12

Medium risk findings

M-01. User enumeration using forgotten password reset mechanism /Account/ForgottenPassword returns “Success” if a valid username was specified for password reset and “Failed” if not. This vulnerability can be used to establish which accounts are registered and therefore which accounts can be targeted for further attacks, such as social engineering or password guessing. Additionally, the RequestVerificationToken is not properly validated or required.

Recommendation Ensure exactly the same response is returned regardless of whether the specified account exists or not and that CSRF tokens are required and validated. Status: Finding addressed.

13

M-02. Vulnerable jquery in use The following resources contain vulnerable Jquery version 1.11.0 which contains multiple vulnerabilities: /Content/squished/combinedAll_1AF3077533D97982EA00CAE007235680.js /Content/squished/combinedLogin_D5EB4C82B924E156163B4E4F4169AC47.js CVE-2015-9251: 3rd party CORS request may execute CVE-2015-9251: parseHTML() executes scripts in event handlers CVE-2019-11358: jQuery before 3.4.0 mishandles jQuery.extend(true, {}, ...) because of Object.prototype pollution CVE-2020-11022: Regex in its jQuery.htmlPrefilter sometimes may introduce XSS CVE-2020-11023: Regex in its jQuery.htmlPrefilter sometimes may introduce XSS Recommendation It is recommended to maintain all Javascript frameworks and libraries at current stable versions to address known vulnerabilities as a matter of good practice even if specific vulnerabilities are not directly applicable. Status: Finding addressed.

14

M-03. Secure flag missing The following cookies are missing the Secure flag, which in some circumstances may allow their transmission over insecure HTTP transport and expose them to unauthorised disclosure. .ASPXAUTH ASP.NET_SessionId __RequestVerificationToken Recommendation Ensure all cookies have the Secure flag set to use HTTPS only. Status: Finding addressed.

15

Good practice recommendations

GP-01. Server header The server header exposes the version of the IIS used: Server: Microsoft-IIS/8.5 It is recommended to disable the “Server:” header in IIS which is disclosing IIS version (8.5) as a matter of good practice.

16

GP-02. Path-relative CSS imports The following resources load path-relative CSS imports which in some rare cases may lead to application vulnerabilities: /Project/Details ../../Content/font-awesome/css/font-awesome.min.css /Site/Details ../../Content/font-awesome/css/font-awesome.min.css It is recommended to avoid using path-relative resources (“../../”) including CSS. For more information please refer to the following: https://portswigger.net/research/detecting-and-exploiting-path-relative-stylesheet-import-prssi-vulnerabilities