How to Test Configuration and Deployment Management.? | Based on Owasp
In this session I will give an example of how to test based on owasp, there are 13 testing checklists
1. Test Network Infrastructure Configuration
Summary
For example, a web server vulnerability that would allow a remote attacker to disclose the source code of the application itself (a vulnerability that has arisen a number of times in both web servers or application servers) could compromise the application, as anonymous users could use the information disclosed in the source code to leverage attacks against the application or its users.
How to Test ?
Test the connection, is it connected?
example, ping localhost
or
If your friends have a vulnerability lab running on your local computer.
You can use the Nmap tool to see if there are any Target server vulnerabilities
sudo nmap -sV -v 127.0.0.1 -p-
And then, You can check this version on Internet, its vuln ?
2. Test Application Platform Configuration
Summary
Proper configuration of the single elements that make up an application architecture is important in order to prevent mistakes that might compromise the security of the whole architecture.
How to Test ?
3. Test File Extensions Handling for Sensitive Information
Summary
File extensions are commonly used in web servers to easily determine which technologies, languages and plugins must be used to fulfill the web request. While this behavior is consistent with RFCs and Web Standards, using standard file extensions provides the penetration tester useful information about the underlying technologies used in a web appliance and greatly simplifies the task of determining the attack scenario to be used on particular technologies. In addition, mis-configuration of web servers could easily reveal confidential information about access credentials.
How to Test ?
- Dirbust sensitive file extensions, or extensions that might contain raw data (e.g. scripts, raw data, credentials, etc.).
- Validate that no system framework bypasses exist on the rules set.
dirb http://127.0.0.1
4. Review Old Backup and Unreferenced Files for Sensitive Information
Summary
While most of the files within a web server are directly handled by the server itself, it isn’t uncommon to find unreferenced or forgotten files that can be used to obtain important information about the infrastructure or the credentials.
How to Test ?
- Find and analyse unreferenced files that might contain sensitive information.
These results are the analysis of our scanning to find if there is sensitive information from the Dirb Tool.
5. Enumerate Infrastructure and Application Admin Interface
Summary
Administrator interfaces may be present in the application or on the application server to allow certain users to undertake privileged activities on the site. Tests should be undertaken to reveal if and how this privileged functionality can be accessed by an unauthorized or standard user.
An application may require an administrator interface to enable a privileged user to access functionality that may make changes to how the site functions. Such changes may include:
- user account provisioning
- site design and layout
- data manipulation
- configuration changes
How to Test ?
- Identify hidden administrator interfaces and functionality.
Using Dirseach Tool or other tool can free to used:
dirsearch -u 127.0.0.1
=================================================================================
Extensions: php, aspx, jsp, html, js | HTTP method: GET | Threads: 30 | Wordlist size: 10927
Output File: /home/mashan/.dirsearch/reports/127.0.0.1_23-02-17_16-24-35.txt
Error Log: /home/mashan/.dirsearch/logs/errors-23-02-17_16-24-35.log
Target: http://127.0.0.1/
[16:24:35] Starting:
[16:24:40] 301 - 305B - /.git -> http://127.0.0.1/.git/
[16:24:40] 200 - 3KB - /.git/
[16:24:40] 200 - 269B - /.git/config
[16:24:40] 200 - 73B - /.git/description
[16:24:40] 200 - 757B - /.git/branches/
[16:24:40] 200 - 23B - /.git/HEAD
[16:24:40] 200 - 4KB - /.git/hooks/
[16:24:40] 200 - 944B - /.git/info/
[16:24:40] 200 - 240B - /.git/info/exclude
[16:24:40] 200 - 191B - /.git/logs/HEAD
[16:24:40] 200 - 1KB - /.git/logs/
[16:24:40] 301 - 315B - /.git/logs/refs -> http://127.0.0.1/.git/logs/refs/
[16:24:40] 200 - 191B - /.git/logs/refs/heads/master
[16:24:40] 301 - 321B - /.git/logs/refs/heads -> http://127.0.0.1/.git/logs/refs/heads/
[16:24:40] 301 - 330B - /.git/logs/refs/remotes/origin -> http://127.0.0.1/.git/logs/refs/remotes/origin/
[16:24:40] 301 - 323B - /.git/logs/refs/remotes -> http://127.0.0.1/.git/logs/refs/remotes/
[16:24:40] 200 - 191B - /.git/logs/refs/remotes/origin/HEAD
[16:24:40] 200 - 1KB - /.git/objects/
[16:24:40] 301 - 316B - /.git/refs/heads -> http://127.0.0.1/.git/refs/heads/
[16:24:40] 200 - 41B - /.git/refs/heads/master
[16:24:40] 200 - 11KB - /.git/packed-refs
[16:24:40] 200 - 1KB - /.git/refs/
[16:24:40] 200 - 32B - /.git/refs/remotes/origin/HEAD
[16:24:40] 301 - 318B - /.git/refs/remotes -> http://127.0.0.1/.git/refs/remotes/
[16:24:40] 301 - 315B - /.git/refs/tags -> http://127.0.0.1/.git/refs/tags/
[16:24:40] 301 - 325B - /.git/refs/remotes/origin -> http://127.0.0.1/.git/refs/remotes/origin/
[16:24:41] 200 - 55KB - /.git/index
[16:24:42] 403 - 274B - /.ht_wsr.txt
[16:24:42] 403 - 274B - /.htaccess.sample
[16:24:42] 403 - 274B - /.htaccess_extra
[16:24:42] 403 - 274B - /.htaccess_orig
[16:24:42] 403 - 274B - /.htaccess.bak1
[16:24:42] 403 - 274B - /.htaccess_sc
[16:24:42] 403 - 274B - /.htaccess.save
[16:24:42] 403 - 274B - /.htaccess.orig
[16:24:42] 403 - 274B - /.htaccessOLD2
[16:24:42] 403 - 274B - /.htaccessBAK
[16:24:42] 403 - 274B - /.htm
[16:24:42] 403 - 274B - /.html
[16:24:42] 403 - 274B - /.htaccessOLD
[16:24:42] 403 - 274B - /.httr-oauth
[16:24:42] 403 - 274B - /.htpasswds
[16:24:42] 403 - 274B - /.htpasswd_test
[16:25:01] 200 - 3KB - /README
[16:25:01] 200 - 3KB - /README.md
[16:25:35] 301 - 305B - /ajax -> http://127.0.0.1/ajax/
[16:25:49] 301 - 308B - /classes -> http://127.0.0.1/classes/
[16:25:49] 200 - 4KB - /classes/
[16:25:53] 200 - 2KB - /configuration/
[16:26:01] 301 - 314B - /documentation -> http://127.0.0.1/documentation/
[16:26:01] 200 - 2KB - /documentation/
[16:26:14] 200 - 408B - /home.php
[16:26:17] 301 - 307B - /images -> http://127.0.0.1/images/
[16:26:17] 200 - 10KB - /images/
[16:26:18] 200 - 4KB - /includes/
[16:26:18] 301 - 309B - /includes -> http://127.0.0.1/includes/
[16:26:19] 200 - 54KB - /index.php
[16:26:20] 200 - 54KB - /index.php/login/
[16:26:22] 301 - 311B - /javascript -> http://127.0.0.1/javascript/
[16:26:28] 200 - 2KB - /login.php
[16:26:45] 301 - 310B - /passwords -> http://127.0.0.1/passwords/
[16:26:45] 200 - 946B - /passwords/
[16:26:54] 200 - 73KB - /phpinfo.php
[16:26:59] 200 - 225B - /register.php
[16:27:02] 200 - 141B - /robots.txt
[16:27:05] 403 - 274B - /server-status
[16:27:05] 403 - 274B - /server-status/
[16:27:17] 301 - 307B - /styles -> http://127.0.0.1/styles/
Task Completed6. Test HTTP Methods
Summary
HTTP offers a number of methods (or verbs) that can be used to perform actions on the web server. While GET and POST are by far the most common methods that are used to access information provided by a web server, there are a variety of other methods that may also be supported, and can sometimes be exploited by attackers.
How to Test ?
- Enumerate supported HTTP methods.
- Test for access control bypass.
- Test HTTP method overriding techniques.
example :
nc 127.0.0.1 80
and Other.
7. Test HTTP Strict Transport Security
Summary
The HTTP Strict Transport Security (HSTS) feature lets a web application inform the browser through the use of a special response header that it should never establish a connection to the specified domain servers using un-encrypted HTTP. Instead, it should automatically establish all connection requests to access the site through HTTPS. It also prevents users from overriding certificate errors.
How to Test ?
- Review the HSTS header and its validity
The presence of the HSTS header can be confirmed by examining the server’s response through an intercepting proxy or by using curl as follows:
curl -s -D- http://127.0.0.1 | grep -i strict
Strict-Transport-Security: max-age=31536000
8. Test RIA Cross Domain Policy
Rich Internet Applications (RIA) have adopted Adobe’s crossdomain.xml policy files to allow for controlled cross domain access to data and service consumption using technologies such as Oracle Java, Silverlight, and Adobe Flash. Therefore, a domain can grant remote access to its services from a different domain. However, often the policy files that describe the access restrictions are poorly configured. Poor configuration of the policy files enables Cross-site Request Forgery attacks, and may allow third parties to access sensitive data meant for the user.
How To Test ?
9. Test File Permission
Summary
When a resource is given a permissions setting that provides access to a wider range of actors than required, it could lead to the exposure of sensitive information, or the modification of that resource by unintended parties. This is especially dangerous when the resource is related to program configuration, execution, or sensitive user data.
How to Test ?
- Review and identify any rogue file permissions.
example :
10. Test for Subdomain Takeover
Summary
A successful exploitation of this kind of vulnerability allows an adversary to claim and take control of the victim’s subdomain. This attack relies on the following:
- The victim’s external DNS server subdomain record is configured to point to a non-existing or non-active resource/external service/endpoint. The proliferation of XaaS (Anything as a Service) products and public cloud services offer a lot of potential targets to consider.
- The service provider hosting the resource/external service/endpoint does not handle subdomain ownership verification properly.
How to Test ?
- Enumerate all possible domains (previous and current).
- Identify forgotten or misconfigured domains.
Using the dig command the tester looks for the following DNS server response messages that warrant further investigation:
NXDOMAINSERVFAILREFUSEDno servers could be reached.
./dnsrecon.py -d victim.com
[*] std: Performing General Enumeration against: victim.com...
[-] DNSSEC is not configured for victim.com
[*] SOA ns1.codehof.net 23.141.40.11
[*] SOA ns1.codehof.net 2620:b0:2000:102::1:53
[*] NS ns1.codehof.net 23.141.40.11
[*] Bind Version for 23.141.40.11 ""
[*] NS ns1.codehof.net 2620:b0:2000:102::1:53
[*] NS libel.victim.com 5.200.21.143
[*] Bind Version for 5.200.21.143 ""
[*] NS ns2.codehof.net 23.141.40.12
[*] Bind Version for 23.141.40.12 ""
[*] NS ns2.codehof.net 2620:b0:2000:102::2:53
[*] MX exim-h.den.codehof.net 23.141.40.25
[*] MX exim-h.den.codehof.net 2620:b0:2000:102::1:25
[*] TXT victim.com google-site-verification=wzN3eCkYYRwPx9o2sHbCHYsps9Un1rN9yYjoKhPl2jI
[*] TXT victim.com v=spf1 ip4:5.200.21.143 ip4:23.141.40.0/24 ip6:2620:b0:2000::/48 -all
[*] TXT _dmarc.victim.com v=DMARC1;p=reject;aspf=r;adkim=r
[*] TXT _domainkey.victim.com o=-
[*] Enumerating SRV Records
[+] 0 Records Found11. Test Cloud Storage
Summary
Cloud storage services facilitate web application and services to store and access objects in the storage service. Improper access control configuration, however, may result in sensitive information exposure, data being tampered, or unauthorized access.
How to Test ?
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://<cloud-storage-service>/<object>To test the ability to upload a file:
curl -X PUT -d 'test' 'https://<cloud-storage-service>/test.txt'This article may still be lacking and incomplete, maybe I will improve it in the future.
Thank you, and </To Be Shadow>
