When visiting a supported email account, currently Outlook and Gmail, Paladin Browser Protection prompts you to activate their phishing protection.
Upon clicking Activate, Google tells you that Paladin Cyber will be able to read both your contacts and the contents of your emails.
Once activated, any time the user reads their emails, the Paladin Browser Protection plugin will send the msgID or threadID to the Paladin Cyber Firebase endpoint.
callFirebaseFunction(‘scoreGmailMessage’, {
msgID: request.msgID,
email: request.email
}
……
callFirebaseFunction(‘scoreGmailThread’, {
threadID: request.threadID,
email: request.email
}
Paladin Cyber has a background process that checks the Firebase endpoint to kick off a job to download the email or thread and perform the phishing analysis. This is evident by the email generated by Google after this feature is enabled.
Paladin Cyber provided the server-side code for this feature and we can confirm the email is pulled by the backend system, and run through the phishing score algorithm implemented by Paladin Cyber. When a phishing email is detected by the scoring algorithm, the user id of the user and the domain that triggered the detection is logged by the analytics engine. The content of the email or other related information is NOT stored. For the emails that do not meet the scoring threshold to be marked as phishing, the algorithm does NOT retain any additional data.
Public Wi-Fi Protection / Secure Web Traffic
Paladin Browser Protection turns on Secure Web Traffic by default, this feature is also referred to as Public Wi-Fi Protection in other marketing material.
When enabled, Paladin Browser Protection uses an SSL connection to an HTTP Proxy run by Paladin Cyber in order to protect unencrypted data from being accessed in insecure environments such as open, unencrypted, Wi-Fi networks. Using an SSL HTTP proxy is an effective way to upgrade insecure connections to secure ones without impacting website functionality. This does mean that connections that would normally be insecure (e.g. http://) will still be insecure when leaving the HTTP Proxy, as shown below.
Since all traffic passes through Paladin Cyber proxy servers, those servers need to handle all of the bandwidth for all of the sites that are visited. As such, Paladin Cyber whitelists sites which shouldn’t pass through the proxy because they are already either sufficiently secured or proxying those sites would break their functionality.
This means connections to any of these sites will NOT pass through Paladin Cyber’s proxy. By whitelisting the https:// versions of these sites, Paladin Browser Protection avoids tunneling connections already secured by the standard TLS from a user’s browser. Tunneling these connections through the proxy would not be necessary since the standard TLS connection negotiated by the browser presumably is already offering sufficient protection.
const proxyWhitelist = [
// IPv4 private ranges
“10.0.0.0/8”,
“172.16.0.0/12”,
“192.168.0.0/16”,
// IPv6 private ranges
“fe80::/10”,
“fc00::/7”,
// Local host ranges
“”,
// Ignore all secure-web sockets
“wss://*”,
// Ignore all TLS HTTP connections
“https://*”,
// Whitelist web socket due to outages in some common SaaS software from IP based license locking
“ws://*”,
// Whitelist for comcast customers to not affect service
“*.comcast.net”,
];
| Finding – WebSocket traffic not support by Proxy |
|---|
| Severity - LOW: The SSL HTTP proxy used by Paladin Browser Protection doesn’t tunnel unencrypted web sockets (ws://). We recommend adding support for these to achieve the goal of upgrading all insecure connections. |
| Recommendation: Add additional support for both unsecured web sockets to proxy to meet the goal of protecting all unsecured user traffic. |
| Paladin Response: Some SaaS websites enforce websocket max connections based on an IP address licensing model. If enough users are using a page that uses this feature, then other users will be unable to use the page because Paladin Browser Protection has proxied all of the users through a single or small handful of IP addresses. |
Content Filter
Paladin Browser Protection provides a content filter which will block connections to websites deemed insecure. To support this feature, every website visited is checked against a dynamically updated site list maintained and run by Paladin Cyber. Each site a user visits is checked against the list and if it matches, the site is blocked and an analytics entry is made indicating that site was blocked.
We also reviewed the server-side source code for this feature so we could audit how Paladin blocks sites and what data is collected along the way.
| Finding – TLD Parsing bug could lead to entire TLDs being whitelisted |
|---|
Severity - REMEDIATED: While reading the code that parses top-level domain (TLD) names from URLs we discovered this hardcoded slice operation in the code that generates the whitelist:
Without describing exactly how the whitelist process works, we determined through code examination that if a domain with multiple suffixes was whitelisted (such as www.mail.google.co.uk) the result will be that all domains in the TLD will be whitelisted. This is due to the above, hardcoded -2 in Paladin’s whitelist building code. When parsing www.mail.google.co.uk, Paladin’s code will incorrectly parse the domain as .co.uk instead of google.co.uk. This causes the entire .co.uk TLD to be added to the whitelist; Preventing Paladin from blocking bad sites that end in .co.uk. This bug will apply similarly to any multiple suffix domains (e.g. com.cn, com.az, etc.). |
| Recommendation: Utilize Mozilla’s curated TLD list1 in order to correctly parse TLDs. |
While testing other aspects of the Paladin Browser Protection extension we did find that view-source is now broken by the content filter feature:
| Point of Interest – View-source on a page flagged as phishing |
|---|
Severity - POI: Viewing source of a webpage is considered phishing by phishing protection.
|
| Recommendation: Whitelist view source unless there is good reason to leave it marked as phishing. |
XSS Protection
The Paladin Browser Protection uses the JSXSS JavaScript library2. XSS filtering based on regular expressions isn’t perfect. Depending on the app, the regular expressions can’t find every case that could inject XSS. This library properly detects all the techniques outlined in the comprehensive OWASP XSS filter evasion cheat sheet3. The JSXSS library provides a nice test site4 so evasion techniques can be tried rapidly.
Basic XSS evasion techniques were attempted to try to find one that passed the JSXSS library filters, including some of the more uncommon bypass techniques we have encountered. None of the tests were able to successfully execute XSS. A look through the JSXSS libraries’ GitHub issues also confirms that if anything, it may be too aggressive, removing more than the XSS which can cause other parts of the page to break.
Paladin Browser Protection’s use of this library is entirely to determine if the page has XSS or not, and when it does, then render an error. Paladin Browser Protection doesn’t try to render the original page, avoiding the problems that may be introduced into the page by such an aggressive XSS filter.
One potential issue was identified where the XSS protection was not invoked when the password manager fills saved usernames into the page. Setting a username to contain an XSS will successfully inject it into the page but not gain true XSS execution. This XSS injection is effectively blocked because Paladin Browser Protection is correctly utilizing innerText instead of innerHTML when filling, usernames and passwords into the page. We note that innerText is the industry-recommended remediation for XSS issues when inserting content into a page.
2 Javascript XSS library http://jsxss.com/en/index.html
3 OWASP XSS Filter Evastion Cheat Sheet
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
4 Javascript XSS test site http://jsxss.com/en/try.html
Password Manager
The Password Manager uses your Paladin Cyber password, created during signup, to store and remember usernames and passwords for websites. The Paladin icons attached to password fields include a strength meter that updates while you type in a potential password.
The password manager utilizes the industry standard for JavaScript crypto: CrytpoJS. CryptoJS is used to generate cryptographically secure random numbers as well as perform SHA512 hashes in order to determine if credentials are already stored by the Password Manager. Additionally, BCryptJS is utilized to both increase cost factors of calculating hashes, as well as derive AES 256 keys to encrypt the passwords themselves. Each domain for which passwords are stored gets its own BCrypt generated salt value; used in the crypto for encrypting keys and generating hashes.
The default BCryptJS cost factor is 10. While Paladin Browser Protection increases this value to 12, it is hard-coded and would require an update to increase:
| Point of Interest – Consider increasing BCrypt cost factor dynamically |
|---|
| Severity - POI: The BCrypt cost factor for the password manager is currently set to 12, this is probably sufficient, but could be increased depending on run time browser tests. |
| Recommendation: Ideally, the BCrypt cost factor would be tunable on the server side rather than hard-coded into the Paladin Browser Protection extension. This way Paladin Cyber can increase the cost factor as compute speed increases without having to update the extension itself. |
We used the provided source code to create a diagram of how the encryption functions for various parts of the password manager operate. The images below describe the process for generating the username and credential hashes used in preventing the decryption of credentials to determine if the credentials had already been stored by the Password Manager.
Below, we diagramed the site password-encryption schemed, and, for completeness, we also diagramed the metadata encryption scheme as well.
Finally, we diagramed the entire master key generation scheme. This master key is used to encrypt passwords and metadata as described above.
We did identify what appears to be a flaw with the way the plugin parses the top-level domain (TLD) in the password manager. Here is the code that gets the TLD, which incorrectly slices the last two parts off to calculate the TLD.
Here is a screenshot in a nodeJS web panel that shows that this code incorrectly parses anything that ends in .co.uk
In order to demonstrate the security impact of this parsing issue, we created an account on ticketmaster.co.uk with the credentials below:
Username: o2432648@nwtg.net Password: asdfasdfasdf1234
Due to the above-mentioned parsing bug, any .co.uk site will prompt to fill in the credentials of ticketmaster.co.uk. Here is a first-time visit to another website we’ve never browsed previously and have no account created. We see Paladin Browser Protection prompts to insert the credentials for ticketmaster.co.uk.
After choosing to fill in the credentials, Paladin Browser Protection provides a Show/Hide link so we can view the password and confirm it is the ticketmaster.co.uk credentials:
| Finding – Password Manager Improperly parses the TLD of a website |
|---|
| Severity - REMEDIATED: This functionality could potentially allow sensitive information to be disclosed to websites or used a method of information extraction during a social engineering exercise. |
| Recommendation: Ensure that domains are properly parsed utilizing above referenced Mozilla’s TLD list. |
While reviewing the Password Manager we also found an interesting function, exportAllData. Examination of the code shows that this function is currently only utilized for testing code.
| Point of Interest – Consider removing export passwords function |
|---|
| Severity - POI This export all data function is necessary for testing but does not need to be present in release builds and should probably be removed. Should some unknown chrome extension compromise exist, having a function that decrypts and dumps all passwords could be dangerous. |
| Recommendation: Remove functions needed only for testing from release builds |
| Paladin Response: This code is for an upcoming password management UI feature and will be utilized to allow users to export their password database if needed. |
Network Testing
The network and infrastructure components of the Paladin plugin were tested using standard penetration testing methodologies along with reviewing the AWS configurations. There weren’t any significant issues or vulnerabilities with these components. We did not have access to the endpoints to test local security configurations. Port scanning and enumeration against the following IPs were conducted using Nmap.
| Host | Port |
|---|---|
| 18.216.112.37 | 443 |
| 52.15.41.229 | 80,443 |
| 52.14.225.212 | 443 |
| 13.58.216.34 | 80,443 |
| 13.58.16.218 | 443 |
| 18.224.73.169 | 22,80,443 |
| 18.223.172.73 | 443 |
We investigated all the web ports, which appeared to be either API endpoints or proxy servers. After which our focus turned to the only host with SSH. According to our scans the versions of SSH installed is OpenSSH 7.2p2, which has a known timing attack (CVE-2016-6210) that can allow attackers to enumerate valid SSH usernames. The attack takes advantage of a hardcoded password in OpenSSH that is encrypted with Blowfish, and used when a known bad username attempts to SSH. When a valid user opens an SSH connection, OpenSSH will encrypt the password using SHA512 taking substantially longer. We put together the following script and attempted to enumerate host names.