PolyDMAEdge Assessment · 2019-08-30 · 3 Cross-SiteScriptingVulnerabilities OWASP-A3 NotIdentified 4 InsecureDirectObjectReferences OWASP-A4 NotIdentified 5 SecurityMisconfiguration

Copyright©2019Praetorian.Allrightsreserved.

Poly

July 16, 2019

Poly DMA EdgeAssessment

Copyright © 2019 Praetorian. All Rights Reserved.


ASSESSMENT TEAMAND CONTRIBUTORS

Donovan PowersAndrew Cook

PRAETORIAN

401 Congress Ave.Suite 1540Austin, TX 78701

Tel +1.512.410.0350Fax +1.512.410.0356

www.praetorian.com

TABLE OF CONTENTS

Executive Summary 1

Assumptions and Constraints . . . . . . . . . . . . . . . . . . . . . . . . 1

Objectives & Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Effective Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Major Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Strategic Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 5

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Current State Analysis 8

Web Application Assessment . . . . . . . . . . . . . . . . . . . . . . . . 10

Summary of Weaknesses . . . . . . . . . . . . . . . . . . . . . . . . 10

Medium Risk Findings . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Low Risk Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Informational Risk Findings . . . . . . . . . . . . . . . . . . . . . . . 22

OWASP Top 10 Comparison . . . . . . . . . . . . . . . . . . . . . . . 26

SANS Top 25 Comparison . . . . . . . . . . . . . . . . . . . . . . . . 27

Appendices 29

Appendix A: Penetration Testing Tools . . . . . . . . . . . . . . . . . . 29

Appendix B: Risk Rating Scale . . . . . . . . . . . . . . . . . . . . . . . 30

Appendix C: Project Team . . . . . . . . . . . . . . . . . . . . . . . . . 32

Appendix D: Contact Information . . . . . . . . . . . . . . . . . . . . . 32


Executive Summary | 1

Executive SummaryPoly engaged Praetorian to perform a security assessment to enumerate possible attack vectors,

evaluate existing security controls, and provide recommendations for improvement. Based on the

evidence collected from the security assessment, Praetorian has concluded that gaps in security

coverage do exist for Poly. Specifically, Praetorian identified the ability to forge web socket commu-

nications with the application, and several configurations which were not in line with best practices.

Areas of improvement have been identified, and Poly should formulate a remediation plan for miti-

gating the findings discovered during the security assessment.

After the initial assessment, Poly remediated vulnerabilities identified in this report. Praetorian

then performed a retest of the remediated vulnerabilities to ensure they were properly patched.

Praetorian would like to thank Poly for this opportunity to help the organization evaluate its current

security posture.

ASSUMPTIONS AND CONSTRAINTSThe project scope, as defined in the Statement of Work, outlines the depth of these evaluation

activities. The security assessment was conducted in a manner designed to be as thorough as

possible without causing interruption of services. However, given the nature of the security tests,

system availability can be, and sometimes is, affected.

Manual penetration testing was performed to provide in-depth analysis and validate automated

scan results. Nevertheless, some listed vulnerabilities may be false positives. Similarly, existing

vulnerabilities may not have been reported due to limitations in testing tools, the necessity of

a time-boxed testing approach, any deltas between the environment that was assessed and the

production environment, and/or the removal of critical components from scope.

Praetorian believes that the statements made in this document provide an accurate assessment in

line with the Statement of Work. As the environment changes, and new vulnerabilities and risks are

discovered and made public, an organization’s overall security posture will change. Such changes

may affect the validity of this assessment report. Therefore, the findings described in this report

represent only a “snapshot” in time.

WWW . P R A E T O R I A N . C O M



Praetorian’s tactical and strategic recommendations reflect best practices that will work for most

organizations. Any change to a system, application, or process can have unintended consequences

and lead to service disruptions. Changes should always be rolled out carefully, in small batches,

and tested thoroughly before full deployment. Special attention should be paid to unique use cases

or circumstances of your organization that might be impacted by the included recommendations.

OBJECTIVES & SCOPEThe engagement was scoped in the Statement of Work 2019-01-2002. The assessment began on

March 03, 2019 and concluded on March 17, 2019. The retest assessment began on July 09, 2019

and concluded on July 12, 2019. The security assessment followed Praetorian’s comprehensive

methodology to provide a black-box analysis of the Polycom RealPresence DMA. The shortcomings

identified during the assessment were used to formulate recommendations and mitigation strategies

for improving the overall security posture of Poly. Specific scoping parameters for each phase of

the assessment are described in detail below.

RealPresence DMA Server Praetorian tested version 10.0.0_P4_Build_9182 of Poly’s RealPres-

ence DMA server. The DMA server allows for point to point video and audio calls between clients

across firewalls and other network boundaries. The system has interfaces intended to listen for

traffic in a client’s DMZ and internal interfaces for routing those calls and sending calls out. The

server provides an API that allows users to perform various actions related to account management,

conference room management, and call management among other features. The server also pro-

vides a web interface for admins to perform various configuration tasks. Praetorian conducted a

Black box assessment with no access to information about the system that was not publicly available.

Praetorian was also instructed by Polycom to not spend testing time performing reverse engineering

of the software to discover additional information. The scope of this assessment was only the DMA

system and did not include any other components that integrate with the DMA system. As such,

some functionality and work flows could not be completely tested.




EFFECTIVE CONTROLSStrong security is achieved through an alliance of a well-designed architecture, secure coding prac-

tices, quality infrastructure, proper configuration, and/or multiple layers of defense. Praetorian

believes it is equally important to identify and call out positive aspects of Poly’s security noted dur-

ing the assessment. Poly has instituted the following security controls that enhance the strength of

the environment:

Strict File Upload Controls: Praetorian identified several areas within the application which al-

lowed file upload and download, such as custom certificate installation, configuration backup and

restoration, and log retrieval. File upload can introduce a wide variety of attack paths such as path

traversal, overwriting of key systems files, or malicious file upload. In line with best practices, user

supplied file names were not trusted and were discarded at the time of upload. Additionally, in

most places the server validated the file contents to ensure it matched the expected file type.

Highly Configurable Authentication Controls: The DMA Edge allowed customers to specificy

the security requirements for several important authentication controls. Specifically, the software

allowed admins to set password length and complexity requirements and configure account lockout

attempts and lockout length. Often times simple authentication brute force attacks can result in

system compromise; allowing users to enable authentication security measures can go a long way

to preventing these types of attacks.




MAJOR FINDINGSMajor findings represent a high-level overview of systemic issues identified within the environment

and/or high risk vulnerabilities that warrant expedited attention. Praetorian believes that major

findings represent the most important issues and that Poly should prioritize its remediation efforts

accordingly. The major findings below are from the initial assessment; Praetorian confirmed the

major findings were remediated during the retest.

CORS Arbitrary Origin Trusted: Praetorian identified that the CORS policy for the application

allowed any arbitrary origin. While this is required for APIs designed to communicate with a variety

of platforms, the use of web sockets on an application with an open CORS policy can lead to web

socket hijacking as detailed in this report. Attackers can initiate a socket connection to the site on

a users behalf without their knowledge and perform actions without their knowledge.




STRATEGIC RECOMMENDATIONSStrategic initiatives are actions that should be taken to secure Poly’s environment that can have wide-

reaching effects. These types of recommendations often require extensive planning and execution.

That said, some initiatives are not complex and can quickly reduce risk, improve security policies,

and/or support defense-in-depth procedures. The strategic recommendations below are from the

initial assessment; some recommendations may no longer apply based on the results of the retest.

Risk management is key to a successful security strategy. An appropriate risk management strategy

usually entails a blend of the following:

Strategy Description

Risk Mitigation Mitigate risk through remediation and countermeasures

Risk Transfer Transfer risk contractually to a 3rd party, or insurance provider

Risk Avoidance Avoid risk by eliminating vulnerable functionality or services

Risk Acceptance Accept risk based on understanding of exposure and appetite for risk

Process Recommendations

Conduct white-box security analysis: While black-box analysis, such as penetration

testing, is a powerful security activity that can clearly demonstrate risk through zero-

knowledge proof-of-concept exploits, black-box testing also has several major drawbacks. Forgoing

a knowledge transfer session and disallowing access to the code base increases an outside firm’s

ramp-up time and decreases the chances of vulnerability identification. Other activities, such as

requirement reviews, threat modeling, architectural analysis, and code reviews, typically provide

greater insight into an application’s design and implementation security shortcomings. Should Poly

choose to perform additional security analysis against the product, Praetorian recommends a more

open, white-box analysis approach.




Technology Recommendations

Create separate CORS policy for web admin interface: While the API functionality

requires an open CORS policy such that a wide variety of clients can communicate with

the API, the web interface doesn’t require this functionality. Praetorian recommends that Polycom

introduce a separate CORS policy for the web interface such that only requests originating from the

web interface can communicate with the admin interface functionality. This would prevent the web

socket high jacking issue outlined in this report.




CONCLUSIONPraetorian previously concluded that gaps in security coverage existed. Areas of improvement have

been identified and Poly has followed a remediation plan for mitigating the findings discovered dur-

ing the security assessment. The grade below is a representation of Poly’s current risk. Praetorian

calculates grades based on the “Existing Vulnerability Measure” (EVM) formula described in the

reference below 1. EVM is used to quantify the collective risk of the findings identified during this

assessment. The grade leverages EVM to benchmark risk posture against Praetorian’s dataset of

previous assessments, taking into account the project’s ASVS level.

Service Security Grade

DMA Good BDMA (Retest) Excellent AThe following table describes the security posture of each grade level.

Grade Security Criteria Description

A ExcellentThe EVM of the assessed components placed within the top 5-10% of

Praetorian’s client-base. The overall security posture was found to be

excellent with a minimal amount of low and informational risk findings.

B GoodThe EVM of the assessed components was above average when

benchmarked against Praetorian’s client-base. Only a handful of

low/informational risk shortcomings were identified in the testing period.

C Fair

The EVM of the assessed components was aligned closely to the average

EVM of Praetorian’s client-base. The current solutions protect some areas of

the target from security issues, but moderate changes are required to

elevate the discussed areas to acceptable standards.

D PoorThe EVM of the assessed components fell below the average EVM, with

significant security deficiencies present. Immediate attention should be

given to the discussed issues to address exposures identified.

F Inadequate

Serious security deficiencies were present in the assessed components and

the EVM placed within the bottom 5-10% of Praetorian’s client-base.

Shortcomings were identified throughout most of the security controls

examined and improved security will require significant resources.

1https://dl.acm.org/citation.cfm?id=1179505



Current State Analysis | 8

Current State AnalysisPraetorian analyzed the current state of security of the environment between the dates of March

03, 2019, and March 17, 2019. During the assessment, Praetorian identified 0 critical-risk issues,

0 high-risk issues, 1 medium-risk issue, 3 low-risk issues, and 2 informational issues.

FindingsCategory

Critical High Med Low InfoTotal

None 0 0 0 0 0 0

Architecture 0 0 0 0 1 1

Authentication 0 0 0 1 0 1

Session Management 0 0 0 1 0 1

Access Control 0 0 0 0 0 0

Malicious Input Handling 0 0 0 0 0 0

Cryptography 0 0 0 0 0 0

Error Handling and Logging 0 0 0 0 0 0

Data Protection 0 0 0 0 1 1

Communications 0 0 0 1 0 1

HTTP Security Configuration 0 0 0 0 0 0

Malicious Controls 0 0 0 0 0 0

Business Logic 0 0 0 0 0 0

File And Resources 0 0 1 0 0 1

Mobile 0 0 0 0 0 0

Web Services 0 0 0 0 0 0

Configuration 0 0 0 0 0 0

Internet of Things 0 0 0 0 0 0

Total 0 0 1 3 2 6




Additionally, following the original assessment, Praetorian performed a retest between the dates of

July 09, 2019 and July 12, 2019. Praetorian determined that 0 critical-risk issues, 0 high-risk issues,

0 medium-risk issues, 0 low-risk issues, and 1 informational issue remain.

FindingsCategory

Critical High Med Low InfoTotal

None 0 0 0 0 0 0

Architecture 0 0 0 0 1 1

Authentication 0 0 0 0 0 0

Session Management 0 0 0 0 0 0

Access Control 0 0 0 0 0 0

Malicious Input Handling 0 0 0 0 0 0

Cryptography 0 0 0 0 0 0

Error Handling and Logging 0 0 0 0 0 0

Data Protection 0 0 0 0 0 0

Communications 0 0 0 0 0 0

HTTP Security Configuration 0 0 0 0 0 0

Malicious Controls 0 0 0 0 0 0

Business Logic 0 0 0 0 0 0

File And Resources 0 0 0 0 0 0

Mobile 0 0 0 0 0 0

Web Services 0 0 0 0 0 0

Configuration 0 0 0 0 0 0

Internet of Things 0 0 0 0 0 0

Total 0 0 0 0 1 1




WEB APPLICATION ASSESSMENTDuring the web application security assessment, Praetorian identified vulnerabilities within the appli-

cation. Praetorian examined all identified vulnerabilities to determine whether they can be exploited

by an attacker to compromise targeted systems and/or used to gain access to sensitive information.

Summary of WeaknessesThe detailed findings section describes potential vulnerabilities, the likelihood or difficulty of ex-

ploitation, the relative level of impact on Poly’s business, and Praetorian’s recommendations. Vul-

nerabilities are arranged in order of business impact, with the critical-impact issues appearing first.

The following findings have the potential to impact the confidentiality, integrity, and/or availability

of Poly assets.

Critical Risk Findings

• NONE

High Risk Findings

• NONE

Medium Risk Findings

• CROSS-SITE WEBSOCKET HIJACKING - FIXED

Low Risk Findings

• CURRENT PASSWORD NOT REQUIRED TO CHANGE PASSWORD - FIXED• HTTPONLY FLAG NOT SET - FIXED• MISSING HTTP STRICT TRANSPORT SECURITY HEADER - FIXED

Informational Risk Findings

• SENSITIVE DATA PASSED IN URL - FIXED• SENSITIVE INFORMATION IN CLIENT SIDE STORAGE - ACCEPTED RISK AT THIS TIME

W WW . P R A E T O R I A N . C O M



Medium Risk Findings

Cross-Site WebSocketHijackingAccess Vector (Av) (3) External

Attack Feasibility (Af) (3) Demonstrated

Authentication (Au) (3) None

Compromise Impact (Ci) (2) Partial

Business Value (Bv) (2) System

Status

Fixed

Praetorian confirmed that the application was checking the origin header of handshake requests.

Validating the origin header of handshake requests mitigates this vulnerability.

Vulnerability Description

Because WebSockets are not restrained by the same-origin policy, an attacker can easily initiate a

WebSocket request (i.e. the handshake/upgrade process) from a malicious webpage targeting the

ws:// or wss:// endpoint URL of the attacked application. Due to the fact that this request is a

regular HTTP(S) request, browsers send the cookies and HTTP-Authentication headers along, even

cross-site.

Impact

An attacker could trick a user into initiating a WebSocket connection on their behalf allowing them

to have full read/write communication with the WebSocket service while authenticated as the victim.

The attacker could then read and modify the user’s information.

System Impacted

DMA web interface - Internal Management Services Interface




Verification and Attack Information

Praetorian identified this vulnerability while testing the handshake between a user’s browser and the

application to initiate a WebSocket communication channel. Praetorian noticed that the application

was not properly validating the origin of the request used to initiate the handshake. Using this,

Praetorian could hijack a user’s WebSocket session. Evidence is shown below.

Figure 1: Initiating a WebSocket handshake using a malicious domain origin.




Figure 2: The handshake was successful, and a WebSocket communication channelwas opened.

POC exploit html which would open a socket on an attacker’s behalf when a user opened the page.

<html >

<body >

<script src="https ://cdn.jsdelivr.net/npm/sockjs -client@1/dist/sockjs.min.js"></

script >

<script >

history.pushState ( ' ' , ' ' , '/ ') ;

ws = new SockJS ( ' https ://192.168.10.137:8443/ dma/sockjs ') ;

ws.onopen = function () {

ws.send ( '{\" msg \":\" connect \",\" version \":\"1\" ,\" support \":[\"1\" ,\" pre2

\",\" pre1 \"]} ') ;

}

</script >

<h1>CSWSH Test </h1>

</body >

</html >




Recommendation

To secure web socket communications, the application should check the Origin header of the

WebSocket handshake request on the server. Additionally, the application should implement CSRF

tokens for each user session, send them with the handshake request, and verify them on the server.

References

Cross-Site WebSocket Hijacking

Security Testing of WebSockets

Cross-Site Request Forgery

Category WASC CWE SANS Top 25 OWASP Top 10

Configuration Management — CWE-345 — —


https://www.christian-schneider.net/CrossSiteWebSocketHijacking.html

https://www.theseus.fi/bitstream/handle/10024/113390/Harri+Kuosmanen+-+Masters+thesis+-+Security+Testing+of+WebSockets+-+Final.pdf?sequence=1

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

http://cwe.mitre.org/top25/#CWE-345



Low Risk Findings

Current Password NotRequired to ChangePasswordAccess Vector (Av) (3) External

Attack Feasibility (Af) (3) Demonstrated

Authentication (Au) (2) User



Status

Fixed

Praetorian confirmed that the current password was required to change the password of an admin;

however, Praetorian noted that admins could change the password of any account without its

current password. This is an intended feature and not a significant security risk.


When setting a new password for a user, the application did not require knowledge of the original

password, or the use of another form of authentication.

Impact

By not verifying the password change via reconfirmation of the authenticity of the user requesting

the change, the application leaves the door open for a session hijacker or session rider to compro-

mise a user’s account and gain indefinite access with knowledge of the newly changed password.

System Impacted






Praetorian discovered this vulnerability while examining the application’s account management fea-

tures. Praetorian monitored the HTTP requests sent during the change password process, and

noticed that the current password was not required. Example evidence is shown below.

Figure 3: Sample request to change a user’s password that did not require the currentpassword.

Recommendation

The password change feature should force the user to provide the original password in addition to

the new password.

References

OWASP: Testing for weak password change or reset functionalities


Authentication WASC-1 — — OWASP-A2


https://www.owasp.org/index.php/Testing_for_weak_password_change_or_reset_functionalities_%28OTG-AUTHN-009%29

http://projects.webappsec.org/w/page/13246975/Threat%20Classification%20Taxonomy%20Cross%20Reference%20View

https://www.owasp.org/index.php/Top_10_2013-A2



HttpOnly Flag Not SetAccess Vector (Av) (3) External

Attack Feasibility (Af) (2) Not Demonstrated




Status

Fixed

Praetorian confirmed the removal of cookies without the HttpOnly attribute.


If the HttpOnly attribute is set on a cookie, then the cookie’s value cannot be read or set by client-

side JavaScript. This measure can prevent certain client-side attacks, such as cross-site scripting,

from easily accessing sensitive cookies.

Impact

If an attacker was able to stage a cross-site scripting attack, they could read and steal sensitive

cookies via JavaScript.

Cookies Impacted

DMA API - JSESSIONID - Internal Management Services Interface


During an application walkthrough, Praetorian noted that the HttpOnly flag was not set for the

cookies listed above. Example evidence is shown below.




Figure 4: The ’HttpOnly’ flag was not set for the JSESSIONID cookie.

Recommendation

As part of best practice, set the HttpOnly flag on all cookies. Unless client-side scripts specifically

require read or write access to a cookie’s value, the HttpOnly flag should be set on the cookie with

the Set-Cookie directive.

References

OWASP: Testing for Cookies Attributes

OWASP: XSS Prevention Cheat Sheet - Use HTTPOnly cookie flag


Session Management — — — OWASP-A2


https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#Bonus_Rule_.231:_Use_HTTPOnly_cookie_flag




Missing HTTP StrictTransport Security HeaderAccess Vector (Av) (2) Adjacent





Status

Fixed

Praetorian confirmed the addition of a Strict-Transport-Security header.


The HTTP Strict Transport Security (HSTS) policy header defines a time window in which a browser

must connect to the server over HTTPS. Although absence of the HSTS policy header does not

immediately indicate a vulnerability, its inclusion is an important component in ensuring the applica-

tion’s security as the header works in concert with other security mechanisms to prevent a variety

of attacks. In general, the benefits of adding the HSTS policy header far outweigh the costs of its

implementation.

Impact

If an attacker has a way to manipulate the route of a user’s request (e.g. through the use of a

man-in-the-middle attack, such as DNS poisoning or ARP poisoning), then the attacker can force a

request to the same domain over unencrypted HTTP. Once the attacker has redirected the user’s

traffic, the attacker can set up a variety of attacks without needing to view the contents of the

controlled traffic. Such attacks include:

• Creating a cloned version of the application that communicates over HTTP for the retrieval of

sensitive information

• Overwriting of cookie values by hosting an application on a subdomain and setting cookie

values with a wide domain scope




Systems Impacted



Praetorian identified the lack of Strict-Transport-Security headers through an application walk-

through. To verify the issue, Praetorian captured a response packet header and confirmed the lack

of an HSTS policy header, as seen below. The issue was specifically identified on API requests

created by refactoring web socket requests as http requests.

Figure 5: An example response missing the ’Strict-Transport-Security’ header.

Recommendation

Add the HTTP Strict-Transport-Security header to all HTTPS responses. The syntax is as

follows:

Strict -Transport -Security: max -age=<seconds >[; includeSubDomains ][; preload]

The max-age parameter specifies the duration for which the browser will require HTTPS when ac-

cessing the site, and should be set to 31536000 (one year). The flag includeSubDomains indicates

that the policy also applies for subdomains of the response sender. The flag preload specifies the

domain owner’s consent to a Google-preloaded HSTS domain list. If adding domains to the HSTS

preload list is an option, the requirements should be carefully noted, as a misconfiguration could

render domains inaccessible.

References

OWASP: HTTP Strict Transport Security

Submit Domain to HSTS Preload List

The Importance of HSTS


https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.md

https://hstspreload.appspot.com/

https://pentestmag.com/the-importance-of-implementing-strict-transport-security/




Communications — — — OWASP-A6





Informational Risk Findings

Sensitive Data Passed in URLAccess Vector (Av) (1) Local





Status

Fixed

Praetorian observed that a token was still passed during a file upload. However, given that the

token was single use, had one minute expiry, and a high level of entropy, Praetorian deemed this

issue as remediated.


Sensitive information within URLs may be captured or logged in various locations, including: the

user’s browser, unencrypted communication channels, the web server, and any forward or reverse

proxy servers between the two end points.

Impact

Placing sensitive information into URLs increases the risk that it will be captured by an attacker. In

this instance the token is single use only, and as a result the risk is relatively low.

Endpoint Impacted

/dma/reports/network-usage/exports - access_token - DMA web interface - Internal Management

Services Interface


Praetorian identified this issue during an application walkthrough. The application sent sensitive

information within the URL. Evidence is shown below.




Figure 6: An authorization token sent via an application URL.

Recommendation

All sensitive data in a POST request should be sent in the request body. Alternatively, sensitive URL

parameters sent in GET requests can be passed to the server through an HTTP header.

References

OWASP - Keep Sensitive Data Out of the URL

3 Reasons Not to Send Sensitive Data in the URL (Even with TLS)


Data Protection WASC-13 — — OWASP-A6


https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Keep_Sensitive_Data_Out_of_the_URL

https://danielmiessler.com/blog/sensitive-information-sent-in-the-url-over-https/

http://projects.webappsec.org/w/page/13246975/Threat%20Classification%20Taxonomy%20Cross%20Reference%20View




Sensitive Information inClient Side StorageAccess Vector (Av) (1) Local


Authentication (Au) (2) User



Status

Accepted Risk at this Time

Praetorian verified the continued use of sensitive information in the client side storage. While this

issue was not remediated, Poly informed Praetorian that the affected application uses AngularJS

Strict Contextual Escaping service to mitigate cross-site scripting attacks. Given these vulnerabilities

cannot be used in tandem, Praetorian understood the lowered risk of this attack vector but continues

to recommend against storing sensitive information in the client side storage.


The web application writes sensitive information to client-side storage.

Impact

The presence of sensitive data can be substantial depending on the type of information exposed.

Therefore, it is best practice to prevent sensitive information from being stored in client-side storage.

Systems Impacted



Praetorian verified that the application stored session information in the browser’s local storage.

Specifically, the application stored Meteor ID’s which could be used to highjack a users session or

resume a suspended session, as seen in the figure below.




Figure 7: User session information stored in local storage.

Recommendation

While local storage is frequently used to store user information, local storage lacks several of the

security controls provided by cookies. For example, there is no way to prevent malicious JavaScript

such as from an XSS attack from reading the data in local storage, increasing the potential impact

of such attacks.

References

OWASP: User Privacy Protection Cheat Sheet


Architecture — — — OWASP-A6


https://www.owasp.org/index.php/User_Privacy_Protection_Cheat_Sheet




OWASP Top 10 ComparisonThe following table represents the most prevalent and critical vulnerabilities identified in OWASP’s

2013 Top 10 List. This list was last updated by OWASP on June 13, 2013 but remains the most

recent update from OWASP as of July 16, 2019.

# Description Name Reference Verification

1 Injection Vulnerabilities OWASP-A1 Not Identified

2 Broken Authentication and Session Management OWASP-A2 Identified

3 Cross-Site Scripting Vulnerabilities OWASP-A3 Not Identified

4 Insecure Direct Object References OWASP-A4 Not Identified

5 Security Misconfiguration OWASP-A5 Not Identified

6 Sensitive Data Exposure OWASP-A6 Identified

7 Missing Function Level Access Control OWASP-A7 Not Identified

8 Cross-Site Request Forgery OWASP-A8 Not Identified

9 Using Components with Known Vulnerabilities OWASP-A9 Not Identified

10 Unvalidated Redirects and Forwards OWASP-A10 Not Identified

Not IdentifiedIndicates that this vulnerability was not identified during Praetorian’s secu-

rity assessment of the application.

IdentifiedIndicates that this vulnerability was identified during Praetorian’s security

assessment of the application.














SANS Top 25 ComparisonThe following table represents the most prevalent and critical vulnerabilities identified in SANS’s

2011 Top 25 List. This list was last updated by SANS on June 29, 2011 but remains the most recent

update from SANS as of July 16, 2019.


1Improper Neutralization of Special Elements used in an

SQL Command (’SQL Injection’)89 Not Identified

2Improper Neutralization of Special Elements used in an OS

Command (’OS Command Injection’)78 Not Identified

3Buffer Copy without Checking Size of Input (’Classic Buffer

Overflow’)120 Not Identified

4Improper Neutralization of Input During Web Page Gener-

ation (’Cross-site Scripting’)79 Not Identified

5 Missing Authentication for Critical Function 306 Not Identified

6 Missing Authorization 862 Not Identified

7 Use of Hard-coded Credentials 298 Not Identified

8 Missing Encryption of Sensitive Data 311 Not Identified

9 Unrestricted Upload of File with Dangerous Type 134 Not Identified

10 Reliance on Untrusted Inputs in a Security Decision 807 Not Identified

11 Execution with Unnecessary Privileges 250 Not Identified

12 Cross-Site Request Forgery (CSRF) 352 Not Identified

13Improper Limitation of a Pathname to a Restricted Direc-

tory (’Path Traversal’)22 Not Identified

14 Download of Code Without Integrity Check 494 Not Identified

15 Incorrect Authorization 863 Not Identified




















16 Inclusion of Functionality from Untrusted Control Sphere 829 Not Identified

17 Incorrect Permission Assignment for Critical Resource 732 Not Identified

18 Use of Potentially Dangerous Function 676 Not Identified

19 Use of a Broken or Risky Cryptographic Algorithm 327 Not Identified

20 Incorrect Calculation of Buffer Size 131 Not Identified

21 Improper Restriction of Excessive Authentication Attempts 307 Not Identified

22 URL Redirection to Untrusted Site (’Open Redirect’) 601 Not Identified

23 Uncontrolled Format String 134 Not Identified

24 Integer Overflow or Wraparound 190 Not Identified

25 Use of a One-Way Hash without a Salt 759 Not Identified

Not IdentifiedIndicates that this vulnerability was not identified during Praetorian’s secu-

rity assessment of the application.

IdentifiedIndicates that this vulnerability was identified during Praetorian’s security

assessment of the application.













Appendices | 29

AppendicesAPPENDIX A: PENETRATION TESTING TOOLSPraetorian uses many open source and proprietary tools during typical engagements. The following

table lists the names and purpose of these tools.

Assessment Tool Purpose

American Fuzzy Lop Open source coverage-guided fuzzer

Angr Open source symbolic code execution engine

Bloodhound Open source attack path generator for Windows environments

Burp Commercial web suite with powerful manual testing features

Burp Plugins Proprietary extensions using Burp’s API

Cobalt Strike Commercial covert channel and beaconing framework

CrackMapExec Open source post-exploitation tool for Windows environments

Driller Open source bridge between afl and angr

Empire Open source powershell post exploitation framework

Gladius Proprietary automated hash detection and cracking tool

Hydra Open source brute force tool supporting many protocols

H0b0’s Rules Proprietary password cracking ruleset

Kali Open source penetration testing Linux distribution

Metasploit Commercial exploitation framework

Nessus Commercial vulnerability scanner

Nikto Open source web server vulnerability scanner

Nmap Open source network mapping with OS fingerprint capabilities

Trudy Proprietary generic TCP/IP proxy tool

Responder Open source LLMNR, NBT-NS and MDNS poisoner



Appendices | 30

APPENDIX B: RISK RATING SCALEPraetorian’s risk rating scale is based on Common Vulnerability Scoring System (CVSS) 2.0 2 and

Microsoft DREAD 3, two widely used scales for rating security vulnerabilities. However, some aspects

of those scales are not ideal for Praetorian’s consulting needs. As the CVSS specification notes, rating

systems must “accurately [reflect] the risk posed by the vulnerability to the user’s environment,”

and DREAD points out that it “can [be extended] to meet your needs.” Therefore, Praetorian has

combined and tailored these scales into a new system that meets the needs of Praetorian and our

clients as a whole. The Risk Rating Scale 2.0 assesses vulnerabilities and associated risk against

five independent risk factors:

Total ofRisk

FactorsRisk Rating

RecommendedTime Frame forAction PlanDevelopment

15 Critical 24 hours

14 High 1 week

13 Medium 1 month

12..10

Low 3 months

9...5

InformationalAddressed at

client’s discretion

Access Vector (Av):

The network location from which

the attack originates

Attack Feasibility (Af):

The extent to which the attack has

been demonstrated or publicized

Authentication Requirements (Au):

What credentials, if any, are neces-

sary for the attack to succeed

Compromise Impact (Ci):

The extent to which the attacker

can control the system in a success-

ful attack

Business Value of Data (Bv):

The type of data put at risk from the

vulnerability

2https://www.first.org/cvss/v2/guide3https://msdn.microsoft.com/en-us/library/ff648644.aspx



Appendices | 31

Each risk factor is assessed at one of three levels. If measurement is not possible, the values are

estimated according to expert opinions applied to real-world scenarios. The assigned values for

each of the five risk factors are then added with equal weight to form the Risk Rating 2.0.

Risk Factor Value Definition

3 External: The attack can be executed fromanywhere across the Internet.

2 Internal/Adjacent: The attack can take place onlyfrom within or adjacent to the target network.

Access Vector (Av)

1 Local: The attack requires read/write/executecapabilities on the target system.

3 Demonstrated: The attack has been demonstratedand/or published in proof-of-concept form.

2Not Demonstrated: The attack has not beencarried out, but a demonstration would be possiblegiven particular resources.

Attack Feasibility(Af)

1 Theoretical: The attack may be difficult orimpossible to demonstrate.

3 None: No prior authentication knowledge isrequired to execute the attack.

2 User: Credentials from a low-privilege user accountare sufficient to execute the attack.

AuthenticationRequirements (Au)

1 Privileged: Credentials from a high-privilegeaccount are required to execute the attack.

3 Complete: There is total information disclosure, fullloss of system.

2 Partial: There is a partial compromise of thesystem’s confidentiality, integrity, and/or availability.

Compromise Impact(Ci)

1 Trivial: There is at most a trivial impact on thesystem’s confidentiality, integrity, or availability.

3 Crucial: Breach of sensitive customer, business, orfinancial data.

2 System: Material breach of system or applicationdata.Business Value (Bv)

1 Trivial: No important data is breached from thevulnerability.



Appendices | 32

APPENDIX C: PROJECT TEAMAs part of the engagement process, Praetorian and Poly planned the time frames, key tasks, and

expected deliverables. The engagement involved contributions from several team members, includ-

ing:

Praetorian Team Role

Donovan Powers Technical Execution

Andrew Cook Project Manager

APPENDIX D: CONTACT INFORMATIONFor any further inquiries, Praetorian has provided the following contact information for Poly’s con-

venience.

Company: Praetorian Group, Inc.

Address:401 Congress Ave., Suite 1540

Austin, TX 78701

Contact Nathan Sportsman

Title: CEO

Phone: (512) 410-0350

Fax: (512) 410-0356

Email: [email protected]


[email protected]


Copyright © 2019 Praetorian. All Rights Reserved.

Documents

PolyDMAEdge Assessment · 2019-08-30 · 3 Cross-SiteScriptingVulnerabilities OWASP-A3 NotIdentified 4 InsecureDirectObjectReferences OWASP-A4 NotIdentified 5 SecurityMisconfiguration