Legal Requirements
Before reporting a vulnerability, please read and accept these legal requirements.
By signing up to participate in the SAS Vulnerability Disclosure Program (the “Program”) and/or by submitting a report hereunder, each external researcher (“You” or “Researcher”) agree to following legal requirements (the “Agreement”). You represent and warrant that you are at least eighteen (18) years of age and that you have full authority to enter into this Agreement. If you do not wish to accept the terms of this Agreement, do not sign up or participate in the Program.
- In connection with Your security research activities or other participation in the Program, You agree to comply with (1) all applicable Federal, State, and local laws and (2) all requirements and guidelines described in the Program documentation.
- You hereby represent that You have obtained the necessary approvals and consents from all third parties, including but not limited to Your employer, for the purpose of participating in the Program.
- You agree that You will not do the following without the prior written consent of SAS:
- Use in advertising, publicity, or otherwise the name of SAS or its affiliates or any trade name, trademark, trade device, service mark, symbol, or any abbreviation, contraction, or simulation thereof owned by SAS or its affiliates
- Represent, directly or indirectly, any service or work provided by You as approved or endorsed by SAS or its affiliates.
- You hereby represent and warrant that You will disclose all of the testing results found or identified by You in connection with Your security research activities or other participation in the Program (“Testing Results”) to SAS. Furthermore, You hereby assign to SAS, and agree to assign to SAS, any and all of Your Testing Results and all rights thereto. To the extent any rights in Your Testing Results are not assignable, You shall grant, and agree to grant, to SAS under any and all such rights an irrevocable, paid-up, royalty free, perpetual, exclusive, sublicensable (directly or indirectly through multiple tiers), transferable, and worldwide license to use and permit others to use such Testing Results in any manner desired by us (and/or our customers and sponsors) without restriction or accounting to you, including, without limitation, the right to make, have made, sell, offer for sale, use, rent, lease, import, copy, prepare derivative works, publicly display, publicly perform, and distribute all or any part of such Testing Results and modifications and combinations thereof and to sublicense (directly or indirectly through multiple tiers) or transfer any and all such rights. Further, You shall waive, and agree to waive, in favor of SAS any moral right or other right or claim that is contrary to the intent of a complete transfer of rights to SAS in Your Testing Results.
- You agree that any and all information acquired or accessed by You as part of Your participation in the Program, including but not limited to Your Testing Results, (the “Confidential Information”) is confidential to SAS. Before engaging in any testing or submitting findings You agree that You will (i) hold in confidence and not disclose to any third party any Confidential Information, except as approved in writing by SAS; (ii) protect such Confidential Information with at least the same degree of care that You use to protect Your own confidential information, but in no case, less than reasonable care; and (iii) immediately notify SAS upon discovery of any loss or unauthorized disclosure of the Confidential Information. You shall not copy, reproduce, sell, assign, license, market, transfer, or otherwise dispose of, give, or disclose such Confidential Information to third parties, or use such Confidential Information for any purposes other than for Your participation in the Program.
- You acknowledge and agree that any and all information You encounter while participating in the Program is owned by SAS or its third-party providers, clients, or customers. You have no rights, title, or ownership to any information You may encounter. Except for the limited use of the Information authorized in this Agreement, SAS grants You no copyright, patent, trademark, trade secret or other intellectual property rights.
- SAS may modify the terms of this Agreement or terminate the Program at any time.
- By submitting Your Testing Results, You consent to such Results being transferred to, and stored in, the United States. You further acknowledge that You have read and accepted the Terms of Use, Privacy Policy, and Disclosure Guidelines (together with this Agreement, the “Researcher Terms and Conditions.”.
- You must not test for spam, social engineering, or denial of service issues. Your testing must not violate any law, or disrupt or compromise any data that is not their own.
- No Testing Results or submissions may be publicly disclosed at any time by You. SAS does not publicly disclose reports at this time. If and when SAS does disclose a report, You hereby authorize us to publicize Your Testing Results, including account name. With respect to the personal information of Researchers, please refer to the SAS Privacy Policy available at https://www.sas.com/en_us/legal/privacy.html.
CORPORATE VULNERABILITIES
What's in scope
Applications and networks that reside on sas.com and jmp.com.
What's out of scope
- Vulnerabilities in product security.
- Findings that can be easily obtained with automated tools.
- Vulnerabilities in Flash files.
- Reports from automated tools or scans, or those affecting outdated browsers.
- Denial of service attacks.
- Issues without clearly identifying the security impact (such as clickjacking on a static website) or speculative theoretical exploitability (e.g., using UXSS to steal the auth cookies and/or identifying Apache Tomcat 8.0.43 but not being able to perform any attack).
- Missing security best practices and controls, such as rate-limiting/throttling, lack of cross-site request forgery (CSRF) protection, lack of security headers, missing flags on cookies, descriptive errors, server/technology disclosure without clear and working exploit.
- Lack of crossdomain.xml, p3p.xml, robots.txt, or any other policy files and/or wildcard presence or misconfigurations.
- Use of known-vulnerable libraries or frameworks (e.g., an outdated JQuery or AngularJS without clear and working exploit).
- Self-exploitation (e.g., cookie reuse, self-cookie-bomb or self-denial-of-service).
- Self-cross-site scripting vulnerabilities without evidence on how the vulnerability can be used to attack another user.
- Lack of HTTS or reports about insecure SSL/TLS configuration.
- Password complexity requirements, account/email enumeration, or any report that discusses how you can learn whether a given username or email address has a related SAS account.
- Presence or lack of autocomplete attribute on web forms/password managers.
- Server banner disclosure or technology used disclosure.
- Full path or IP address disclosure.
- CSRF on logout or insignificant functionalities.
- Publicly accessible login panels.
- CSS injection attacks, unless it provides the ability to read anti-CSRF tokens or other sensitive information.
- Tabnapping.
- Host header injection, unless it provides access to interim proxies.
- Cache poisoning.
- Reflective file download.
- Cross-origin resource sharing access-control-allow-origin or accepting a custom origin header that does not specifically show a valid attack scenario.
- Path-relative stylesheet import vulnerabilities without an impactful exploitation scenario (e.g., stealing CSRF tokens).
- OPTIONS / TRACE / DELETE / PUT / WEBDAV or any other HTTP methods accepted by the server that do not specifically show a valid attack scenario.
- Cookie scoped to parent domain or anything related to the path misconfiguration and improperly scoped.
- Private IP/hostname disclosures or real IP disclosures for services using content delivery network.
- Open ports that do not lead directly to a vulnerability.
- SAS policies on presence or absence of sender policy framework/DomainKeys identified mail/domain-based message authentication, reporting and conformance records.
- Lack of domain name servers (DNS), certificate authority authorization, and DNS-related configurations.
- Weak certificate hash algorithm.
- Social engineering of SAS employees or contractors.
- Any physical or wireless attempt against SAS property or data centers.
Guidelines for detecting and reporting vulnerabilities
- Although SAS does not have a compensating bug bounty program, we welcome security vulnerability reports from external researchers.
- When reporting vulnerabilities, please consider the attack scenario and exploitability, as well as the security impact of the bug.
- Avoid pivoting further into the network by using a vulnerability.
- Please note the requirements for Remote Code Execution, SQL Injection and FileUpload vulnerabilities described below.
- Do not exploit SAS service providers. Prohibited actions include brute-forcing login credentials of domain registrars, DNS hosting companies and email providers. External researchers are not authorized to perform any actions to property, systems, services or data that are not owned by SAS.
- Report any vulnerability that exposes Personally Identifiable Information (PII) immediately to SAS at sirt@sas.com. Do not proceed with access and immediately purge any local information, if applicable. You may pull our GPG key from: gpg --keyserver hkp://pool.sks-keyservers.net --search-keys "SAS SIRT".
Remote Code Execution (RCE) requirements
Vulnerabilities that allow the execution of code on the application server or shell command on the server itself should be run in accordance with the requirements below.
Prohibited actions when conducting RCE attempts:
- Altering or uploading files on the webserver. (When file-upload functionality upload of web shells is prohibited, try uploading echo, info, or any variable, info-based invocation code.)
- Altering file permissions.
- Reading sensitive files on the system (e.g., /etc/shadow) or looking through the file or folder structure. The same applies to XXE, LFI, and Path Traversal, or any other vulnerability that allows you to read underlying file/folder structure.
- Altering, modifying or deleting any files on the system. This includes:
- Copying any files from the system and disclosing them to a non-SAS site or entity.
- Interacting with underlying OS-level data and/or databases.
- Interacting with other services that run on the OS-level and or any remote hosts that reside on the network.
- Interrupting the normal operation of the server.
- Establishing persistent connection mechanisms (e.g., netcat or ssh reverse tunnel).
Allowed actions when conducting RCE attempts for UNIX:
- Executing 'ifconfig', 'hostname', 'whoami', 'uptime', 'top', or any metrics commands.
- Reading content of the '/etc/hosts ' file.
- Using 'echo' to pipe characters into a file located in the "/tmp/", reading the file and then removing it right after confirmation.
Allowed actions when conducting RCE attempts for Windows:
- Executing 'ipconfig', 'hostname', 'whoami' or any metrics commands.
- Reading content of the 'drive:/boot.ini', 'drive:/install.ini' or 'drive:/Windows/System32/drivers/etc/networks'.
- Using 'echo' to pipe characters into a file located in the drive:/temp, reading the file (type) and then removing it right after confirmation.
SQL Injection (SQLi) requirements
Vulnerabilities that allow the injection of attacker-controlled parts of the SQL query should be run in accordance with the requirements below.
Prohibited actions when conducting SQLi attempts:
- Reading sensitive files on the system (for example, /etc/shadow) or looking through the file/folder structure (SELECT LOAD_FILE).
- Reading specific, sensitive database records.
- Creating, altering, modifying or deleting any files or records on the system or database. This includes use of INTO OUTFILE.
- Performing command execution, including xp_cmdshell, uploading .so or any action that leads to command execution.
- Creating or deleting users.
- Reading or altering username and password information. This includes password hashes.
- Interrupting the normal operation of the server and the database.
Allowed actions when conducting SQLi attempts:
- Executing SELECT queries such as "@@version", "user();" "system_user();", "database();", "@@hostname".
- Listing database names from schema, listing Columns, Table names.
- Executing mathematical, conversion or logical queries, such as:
- ASCII Value -> Char (SELECT char(65); # returns A).
- Char -> ASCII Value (SELECT ascii(‘A’); # returns 65).
- String Concatenation (SELECT CONCAT(‘A’,'B’,'C’); # returns ABC).
- Case Statement (SELECT CASE WHEN (1=1) THEN ‘A’ ELSE ‘B’ END; # returns A).
- SELECT 0×414243; # returns ABC.
- Time Delay (SELECT BENCHMARK(1000000,MD5(‘A’)); SELECT SLEEP(5); ).
- Using logic and time in server responses.
- Using output responses.
File-upload requirements
Vulnerabilities that allow the upload of files through any means (e.g., PUT HTTP method or file-upload functionality/module) are subject to the requirements below.
Prohibited actions when conducting file-upload attempts:
- Altering, modifying, deleting or replacing any files on the system (such as defacement).
- Uploading files to the account of a user that is not owned by the external researcher and the external researcher is not authorized. This does not apply to system users or web users like www-data f.g.
- Uploading files that deliberately introduce additional exploitation vectors (e.g., HTML code with cross-site scripting code on it).
- Uploading files that can cause denial of service (e.g., oversized files or an unlimited number of files, resulting in running out of disk quota).
Allowed actions when conducting file-upload attempts:
- Chained exploitation vectors that allow users to jump out from the upload folder using f.g. path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy.
- Upload of a file (any extension) with no content, simple string, integer or a special character.
Guidelines for submitting security vulnerability reports
- Submit your report via email. To receive the email address, you must review and agree to all legal requirements by clicking the Submit button below.
- Include clear, concise steps to reproduce the issue. Please list the URL and any affected parameters; describe the browser, operating system or app version; and describe the perceived impact, including how the bug could be exploited.
What to expect after submitting a report
- You will receive an acknowledgment of receipt once you've submitted the report.
- Members of the SAS GIS team will review and validate the submission. Vulnerabilities are classified by the degree of risk, as well as the impact they present to the host system, including the amount and type of data exposed, the privilege level obtained and the proportion of systems or users affected.
- SAS does not publicly disclose reports. If SAS does disclose a report, it will be mutually agreed upon with the external researcher.
