# 2.0 Configuration and Deployment Management Testing * 2.1 Test Network Infrastructure Configuration Known Server Vulnerabilities (CVEs, ...) - automation - Administrative Tools (default username and password, ) * 2.2 Test Application Platform Configuration * Black-Box Testing * Sample and Known Files and Directories * Comment Review - automated - * System Configuration * [CIS-CAT Lite](https://www.cisecurity.org/blog/introducing-cis-cat-lite/) * [Microsoft’s Attack Surface Analyzer](https://github.com/microsoft/AttackSurfaceAnalyzer) * [NIST’s National Checklist Program](https://nvd.nist.gov/ncp/repository) * Gray-Box Testing * Configuration Review * Only enable server modules (ISAPI extensions in the case of IIS) that are needed for the application. This reduces the attack surface since the server is reduced in size and complexity as software modules are disabled. It also prevents vulnerabilities that might appear in the vendor software from affecting the site if they are only present in modules that have been already disabled. * Handle server errors (40x or 50x) with custom-made pages instead of with the default web server pages. Specifically make sure that any application errors will not be returned to the end user and that no code is leaked through these errors since it will help an attacker. It is actually very common to forget this point since developers do need this information in pre-production environments. * Make sure that the server software runs with minimized privileges in the operating system. This prevents an error in the server software from directly compromising the whole system, although an attacker could elevate privileges once running code as the web server. * Make sure the server software properly logs both legitimate access and errors. * Make sure that the server is configured to properly handle overloads and prevent Denial of Service attacks. Ensure that the server has been performance-tuned properly. * Never grant non-administrative identities (with the exception of `NT SERVICE\\WMSvc`) access to applicationHost.config, redirection.config, and administration.config (either Read or Write access). This includes `Network Service`, `IIS_IUSRS`, `IUSR`, or any custom identity used by IIS application pools. IIS worker processes are not meant to access any of these files directly. * Never share out applicationHost.config, redirection.config, and administration.config on the network. When using Shared Configuration, prefer to export applicationHost.config to another location (see the section titled “Setting Permissions for Shared Configuration). * Keep in mind that all users can read .NET Framework `machine.config` and root `web.config` files by default. Do not store sensitive information in these files if it should be for administrator eyes only. * Encrypt sensitive information that should be read by the IIS worker processes only and not by other users on the machine. * Do not grant Write access to the identity that the Web server uses to access the shared `applicationHost.config`. This identity should have only Read access. * Use a separate identity to publish applicationHost.config to the share. Do not use this identity for configuring access to the shared configuration on the Web servers. * Use a strong password when exporting the encryption keys for use with shared -configuration. * Maintain restricted access to the share containing the shared configuration and encryption keys. If this share is compromised, an attacker will be able to read and write any IIS configuration for your Web servers, redirect traffic from your Web site to malicious sources, and in some cases gain control of all web servers by loading arbitrary code into IIS worker processes. * Consider protecting this share with firewall rules and IPsec policies to allow only the member web servers to connect. * Logging In both cases (server and application logs) several issues should be tested and analyzed based on the log contents: 1. Do the logs contain sensitive information? 2. Are the logs stored in a dedicated server? 3. Can log usage generate a Denial of Service condition? 4. How are they rotated? Are logs kept for the sufficient time? 5. How are logs reviewed? Can administrators use these reviews to detect targeted attacks? 6. How are log backups preserved? 7. Is the data being logged data validated (min/max length, chars etc) prior to being logged? * Sensitive Information in Logs This sensitive information can be misused by an attacker if they obtained the logs, for example, through administrative interfaces or known web server vulnerabilities or misconfiguration (like the well-known `server-status` misconfiguration in Apache-based HTTP servers) list of sensitive information is: * Debug information * Stack traces * Usernames * System component names * Internal IP addresses * Less sensitive personal data (e.g. email addresses, postal addresses and telephone numbers associated with named individuals) * Business data * Application source code * Session identification values * Access tokens * Sensitive personal data and some forms of personally identifiable information (PII) * Authentication passwords * Database connection strings * Encryption keys * Bank account or payment card holder data * Data of a higher security classification than the logging system is allowed to store * Commercially-sensitive information * Information it is illegal to collect in the relevant jurisdiction * Information a user has opted out of collection, or not consented to e.g. use of do not track, or where consent to collect has expired * Log Storage Logs can introduce a Denial of Service condition if they are not properly stored * Log Rotation This feature should be tested in order to ensure that: * Logs are kept for the time defined in the security policy, not more and not less. * Logs are compressed once rotated (this is a convenience, since it will mean that more logs will be stored for the same available disk space). * File system permission of rotated log files are the same (or stricter) that those of the log files itself. For example, web servers will need to write to the logs they use but they don’t actually need to write to rotated logs, which means that the permissions of the files can be changed upon rotation to prevent the web server process from modifying these. Some servers might rotate logs when they reach a given size. If this happens, it must be ensured that an attacker cannot force logs to rotate in order to hide his tracks. * Log Access Control Event log information should never be visible to end users. Even web administrators should not be able to see such logs since it breaks separation of duty controls. Ensure that any access control schema that is used to protect access to raw logs and any applications providing capabilities to view or search the logs is not linked with access control schemas for other application user roles. Neither should any log data be viewable by unauthenticated users. * Log Review In order to analyze web server attacks the error log files of the server need to be analyzed. Review should concentrate on: * 40x (not found) error messages. A large amount of these from the same source might be indicative of a CGI scanner tool being used against the web server * 50x (server error) messages. These can be an indication of an attacker abusing parts of the application which fail unexpectedly. For example, the first phases of a SQL injection attack will produce these error message when the SQL query is not properly constructed and its execution fails on the back end database. * 2.3 Test File Extensions Handling for Sensitive Information * Forced Browsing * The following file extensions should never be returned by a web server, since they are related to files which may contain sensitive information or to files for which there is no reason to be served. (.asa, .inc, .config) * The following file extensions are related to files which, when accessed, are either displayed or downloaded by the browser. Therefore, files with these extensions must be checked to verify that they are indeed supposed to be served (and are not leftovers), and that they do not contain sensitive information. * `.zip`, `.tar`, `.gz`, `.tgz`, `.rar`, etc.: (Compressed) archive files * `.java`: No reason to provide access to Java source files * `.txt`: Text files * `.pdf`: PDF documents * `.docx`, `.rtf`, `.xlsx`, `.pptx`, etc.: Office documents * `.bak`, `.old` and other extensions indicative of backup files (for example: `~` for Emacs backup files) * File Upload Windows 8.3 legacy file handling can sometimes be used to defeat file upload filters. Usage Examples: 1. `file.phtml` gets processed as PHP code. 2. `FILE~1.PHT` is served, but not processed by the PHP ISAPI handler. 3. `shell.phPWND` can be uploaded. 4. `SHELL~1.PHP` will be expanded and returned by the OS shell, then processed by the PHP ISAPI handler. * 2.4 Review Old Backup and Unreferenced Files for Sensitive Information login.asp → login.asp.old /.snapshot/ * Black-Box Testing * Inference from the Naming Scheme Used for Published Content For example, if a page viewuser.asp is found, then look also for edituser.asp, adduser.asp and deleteuser.asp. If a directory /app/user is found, then look also for /app/admin and /app/manager. * Other Clues in Published Content HTML and JavaScript files (comments in html and dirs in js) * /robots.txt * Blind Guessing (dirbusting) * Information Obtained Through Server Vulnerabilities and Misconfiguration Numerous vulnerabilities have been found in individual web servers which allow an attacker to enumerate unreferenced content, for example: * Apache ?M=D directory listing vulnerability. * Various IIS script source disclosure vulnerabilities. * IIS WebDAV directory listing vulnerabilities. * Use of Publicly Available Information search for unlinked pages in archives (spidering new vs spidering cached) * Filename Filter Bypass Because deny list filters are based on regular expressions, one can sometimes take advantage of obscure OS filename expansion features in which work in ways the developer didn’t expect. The tester can sometimes exploit differences in ways that filenames are parsed by the application, web server, and underlying OS and it’s filename conventions. Example: Windows 8.3 filename expansion `c:\\\\program files` becomes `C:\\\\PROGRA\\~1` * Remove incompatible characters * Convert spaces to underscores * Take the first six characters of the basename * Add `~` which is used to distinguish files with names using the same six initial characters * This convention changes after the first 3 cname ollisions * Truncate file extension to three characters * Make all the characters uppercase * Gray-Box Testing Performing gray box testing against old and backup files requires examining the files contained in the directories belonging to the set of web directories served by the web server(s) of the web application infrastructure. Theoretically the examination should be performed by hand to be thorough. However, since in most cases copies of files or backup files tend to be created by using the same naming conventions, the search can be easily scripted. For example, editors leave behind backup copies by naming them with a recognizable extension or ending and humans tend to leave behind files with a `.old` or similar predictable extensions. A good strategy is that of periodically scheduling a background job checking for files with extensions likely to identify them as copy or backup files, and performing manual checks as well on a longer time basis. * 2.5 Enumerate Infrastructure and Application Admin Interfaces * Black-Box Testing * Directory and file enumeration (*/admin or /administrator etc..*) - google dorks - * brute forcing of server contents * Comments and links in source code * Reviewing server and application documentation * Publicly available information. Many applications such as WordPress have default administrative interfaces . * Alternative server port. Administration interfaces may be seen on a different port on the host than the main application. * Parameter tampering or in a cookie `` `Cookie: session_cookie; useradmin=0` a combination of the above techniques may be used to attempt to bypass authentication In such an instance the tester should be aware of the potential for administrative account lockout if such functionality is present. * Gray-Box Testing WebSphere: `/admin /admin-authz.xml /admin.conf /admin.passwd /admin/* /admin/logon.jsp /admin/secure/logon.jsp` PHP: `/phpinfo /phpmyadmin/ /phpMyAdmin/ /mysqladmin/ /MySQLadmin /MySQLAdmin /login.php /logon.php /xmlrpc.php /dbadmin` FrontPage: `/admin.dll /admin.exe /administrators.pwd /author.dll /author.exe /author.log /authors.pwd /cgi-bin` WebLogic: `/AdminCaptureRootCA /AdminClients /AdminConnections /AdminEvents /AdminJDBC /AdminLicense /AdminMain /AdminProps /AdminRealm /AdminThreads` WordPress: `wp-admin/ wp-admin/about.php wp-admin/admin-ajax.php wp-admin/admin-db.php wp-admin/admin-footer.php wp-admin/admin-functions.php wp-admin/admin-header.php` * 2.6 Test HTTP Methods * Discover the Supported Methods When testing an application that has to accept other methods, e.g. a RESTful Web Service, test it thoroughly to make sure that all endpoints accept only the methods that they require. tool: `nmap -p 443 --script http-methods --script-args http-methods.url-path='/index.php' localhost` * Testing the PUT Method 1. Capture the base request of the target with a web proxy. 2. Change the request method to `PUT` and add `test.html` file and send the request to the application server. ```json PUT /test.html HTTP/1.1 Host: testing-website HTTP PUT Method is Enabled ``` 3. If the server response with 2XX success codes or 3XX redirections and then confirm by `GET` request for `test.html` file. The application is vulnerable. If the HTTP `PUT` method is not allowed on base URL or request, try other paths in the system. > NOTE: If you are successful in uploading a web shell you should overwrite it or ensure that the security team of the target are aware and remove the component promptly after your proof-of-concept. * Testing for Access Control Bypass Find a page to visit that has a security constraint such that a GET request would normally force a 302 redirect to a log in page or force a log in directly. Issue requests using various methods such as HEAD, POST, PUT etc. as well as arbitrarily made up methods such as BILBAO, FOOBAR, CATS, etc. If the web application responds with a `HTTP/1.1 200 OK` that is not a log in page, it may be possible to bypass authentication or authorization. The following example uses [Nmap’s `ncat`](https://nmap.org/ncat/). ```html $ ncat www.example.com 80 HEAD /admin HTTP/1.1 Host: www.example.com HTTP/1.1 200 OK Date: Mon, 18 Aug 2008 22:44:11 GMT Server: Apache Set-Cookie: PHPSESSID=pKi...; path=/; HttpOnly Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Set-Cookie: adminOnlyCookie1=...; expires=Tue, 18-Aug-2009 22:44:31 GMT; domain=www.example.com Set-Cookie: adminOnlyCookie2=...; expires=Mon, 18-Aug-2008 22:54:31 GMT; domain=www.example.com Set-Cookie: adminOnlyCookie3=...; expires=Sun, 19-Aug-2007 22:44:30 GMT; domain=www.example.com Content-Language: EN Connection: close Content-Type: text/html; charset=ISO-8859-1 ``` If the system appears vulnerable, issue CSRF-like attacks such as the following to exploit the issue more fully: * `HEAD /admin/createUser.php?member=myAdmin` * `PUT /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123` * `CATS /admin/groupEdit.php?group=Admins&member=myAdmin&action=add` Using the above three commands, modified to suit the application under test and testing requirements, a new user would be created, a password assigned, and the user made an administrator, all using blind request submission. * Testing for HTTP Method Overriding Some web frameworks provide a way to override the actual HTTP method in the request by emulating the missing HTTP verbs passing some custom header in the requests. The main purpose of this is to circumvent some middleware (e.g. proxy, firewall) limitation where methods allowed usually do not encompass verbs such as `PUT` or `DELETE`. The following alternative headers could be used to do such verb tunneling: * `X-HTTP-Method` * `X-HTTP-Method-Override` * `X-Method-Override` In order to test this, in the scenarios where restricted verbs such as PUT or DELETE return a “405 Method not allowed”, replay the same request with the addition of the alternative headers for HTTP method overriding, and observe how the system responds. The application should respond with a different status code (*e.g.* 200) in cases where method overriding is supported. The web server in the following example does not allow the `DELETE` method and blocks it: ```html $ ncat www.example.com 80 DELETE /resource.html HTTP/1.1 Host: www.example.com HTTP/1.1 405 Method Not Allowed Date: Sat, 04 Apr 2020 18:26:53 GMT Server: Apache Allow: GET,HEAD,POST,OPTIONS Content-Length: 320 Content-Type: text/html; charset=iso-8859-1 Vary: Accept-Encoding ``` After adding the `X-HTTP-Header`, the server responds to the request with a 200: ```html $ ncat www.example.com 80 DELETE /resource.html HTTP/1.1 Host: www.example.com X-HTTP-Method: DELETE HTTP/1.1 200 OK Date: Sat, 04 Apr 2020 19:26:01 GMT Server: Apache ``` * 2.7 Test HTTP Strict Transport Security The use of this header by web applications must be checked to find if the following security issues could be produced: * Attackers sniffing the network traffic and accessing the information transferred through an un-encrypted channel. * Attackers exploiting a manipulator in the middle attack because of the problem of accepting certificates that are not trusted. * Users who mistakenly entered an address in the browser putting HTTP instead of HTTPS, or users who click on a link in a web application which mistakenly indicated use of the HTTP protocol. ```html # How to Test $ curl -s -D- | grep -i strict # output be like ... Strict-Transport-Security: max-age=31536000 ``` * 2.8 Test RIA Cross Domain Policy To test for RIA policy file weakness the tester should try to retrieve the policy files crossdomain.xml and clientaccesspolicy.xml from the application’s root, and from every folder found. For example, if the application’s URL is `http://www.owasp.org`, the tester should try to download the files `http://www.owasp.org/crossdomain.xml` and `http://www.owasp.org/clientaccesspolicy.xml`. After retrieving all the policy files, the permissions allowed should be be checked under the least privilege principle. Requests should only come from the domains, ports, or protocols that are necessary. Overly permissive policies should be avoided. Policies with `*` in them should be closely examined. Example : ` ` Result Expected : * A list of policy files found. * A list of weak settings in the policies. * 2.9 Test File Permission A clear example is an execution file that is executable by unauthorized users. For another example, account information or a token value to access an API - increasingly seen in modern web services or microservices - may be stored in a configuration file whose permissions are set to world-readable from the installation by default. Such sensitive data can be exposed by internal malicious actors of the host or by a remote attacker who compromised the service with other vulnerabilities but obtained only a normal user privilege. In Linux, use `ls` command to check the file permissions. Alternatively, `namei` can also be used to recursively list file permissions. `$ namei -l /PathToCheck/` The files and directories that require file permission testing include but are not limited to: * Web files/directory * Configuration files/directory * Sensitive files (encrypted data, password, key)/directory * Log files (security logs, operation logs, admin logs)/directory * Executables (scripts, EXE, JAR, class, PHP, ASP)/directory * Database files/directory * Temp files /directory * Upload files/directory * 2.10 Test for Subdomain Takeover * Black-Box Testing The first step is to enumerate the victim DNS servers and resource records. There are multiple ways to accomplish this task, for example DNS enumeration using a list of common subdomains dictionary, DNS brute force or using web search engines and other OSINT data sources. Using the dig command the tester looks for the following DNS server response messages that warrant further investigation: * `NXDOMAIN` * `SERVFAIL` * `REFUSED` * `no servers could be reached.` * Testing DNS A, CNAME Record Subdomain Takeover Perform a basic DNS enumeration on the victim’s domain (`victim.com`) using `dnsrecon`: `$ ./dnsrecon.py -d victim.com [*] Performing General Enumeration of Domain: victim.com ... [-] DNSSEC is not configured for victim.com [*] A subdomain.victim.com 192.30.252.153 [*] CNAME subdomain1.victim.com fictioussubdomain.victim.com ...` Identify which DNS resource records are dead and point to inactive/not-used services. Using the dig command for the `CNAME` record: `$ dig CNAME fictioussubdomain.victim.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> ns victim.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42950 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1` The following DNS responses warrant further investigation: `NXDOMAIN`. To test the `A` record the tester performs a whois database lookup and identifies GitHub as the service provider: `$ whois 192.30.252.153 | grep "OrgName" OrgName: GitHub, Inc.` The tester visits `subdomain.victim.com` or issues a HTTP GET request which returns a “404 - File not found” response which is a clear indication of the vulnerability. * Testing NS Record Subdomain Takeover Identify all nameservers for the domain in scope: `$ dig ns victim.com +short ns1.victim.com nameserver.expireddomain.com` In this fictious example the tester checks if the domain `expireddomain.com` is active with a domain registrar search. If the domain is available for purchase the subdomain is vulnerable. The following DNS responses warrant further investigation: `SERVFAIL` or `REFUSED`. * Gray-Box Testing The tester has the DNS zone file available which means DNS enumeration is not necessary. The testing methodology is the same. * 2.11 Test Cloud Storage First identify the URL to access the data in the storage service, and then consider the following tests: * read the unauthorized data * upload a new arbitrary file You may use curl for the tests with the following commands and see if unauthorized actions can be performed successfully. To test the ability to read an object: `curl -X GET https:///` To test the ability to upload a file: `curl -X PUT -d 'test' 'https:///test.txt'` * Testing for Amazon S3 Bucket Misconfiguration The Amazon S3 bucket URLs follow one of two formats, either virtual host style or path-style. * Virtual Hosted Style Access `https://bucket-name.s3.Region.amazonaws.com/key-name` In the following example, `my-bucket` is the bucket name, `us-west-2` is the region, and `puppy.png` is the key-name: `https://my-bucket.s3.us-west-2.amazonaws.com/puppy.png` * Path-Style Access `https://s3.Region.amazonaws.com/bucket-name/key-name` As above, in the following example, `my-bucket` is the bucket name, `us-west-2` is the region, and `puppy.png` is the key-name: `https://s3.us-west-2.amazonaws.com/my-bucket/puppy.jpg` For some regions, the legacy global endpoint that does not specify a region-specific endpoint can be used. Its format is also either virtual hosted style or path-style. * Virtual Hosted Style Access `https://bucket-name.s3.amazonaws.com` * Path-Style Access `https://s3.amazonaws.com/bucket-name` * Identify Bucket URL For black-box testing, S3 URLs can be found in the HTTP messages. The following example shows a bucket URL is sent in the `img` tag in a HTTP response. `... ...` For gray-box testing, you can obtain bucket URLs from Amazon’s web interface, documents, source code, or any other available sources. * Testing with AWS-CLI In addition to testing with curl, you can also test with the AWS Command-line tool. In this case `s3://` protocol is used. * List The following command lists all the objects of the bucket when it is configured public. `aws s3 ls s3://` * Upload The following is the command to upload a file `aws s3 cp arbitrary-file s3://bucket-name/path-to-save` This example shows the result when the upload has been successful. `$ aws s3 cp test.txt s3://bucket-name/test.txt upload: ./test.txt to s3://bucket-name/test.txt` This example shows the result when the upload has failed. `$ aws s3 cp test.txt s3://bucket-name/test.txt upload failed: ./test2.txt to s3://bucket-name/test2.txt An error occurred (AccessDenied) when calling the PutObject operation: Access Denied` * Remove The following is the command to remove an object `aws s3 rm s3://bucket-name/object-to-remove` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://0xa1mn.gitbook.io/cyber-explained/pentesting/owasp-testing-guide/2.0-configuration-and-deployment-management-testing.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.