Skip to content

Latest commit

 

History

History
106 lines (56 loc) · 7.83 KB

Day 23 Task.md

File metadata and controls

106 lines (56 loc) · 7.83 KB
Raw

🎯 Day 23 Task

✅ THM Room

https://tryhackme.com/room/attacktivedirectory

✅ 4.2.2 Test Application Platform Configuration

Test Objectives

  1. Ensure that defaults and known files have been removed.
  2. Validate that no debugging code or extensions are left in the production environments.
  3. Review the logging mechanisms set in place for the application.

How to Test

Black-Box Testing

Sample and Known Files and Directories

Many web servers and application servers provide, in a default installation, sample applications and files for the benefit of the developer and in order to test that the server is working properly right after installation. However, many default web server applications have been later known to be vulnerable. This was the case, for example, for CVE-1999-0449 (Denial of Service in IIS when the Exair sample site had been installed)

Comment Review - It is very common for programmers to add comments when developing large web-based applications. However, comments included inline in HTML code might reveal internal information that should not be available to an attacker. Sometimes, even source code is commented out since a functionality is no longer required, but this comment is leaked out to the HTML pages returned to the users unintentionally.

System Configuration - Various tools, documents, or checklists can be used to give IT and security professionals a detailed assessment of target systems’ conformance to various configuration baselines or benchmarks.

Gray-Box Testing

Configuration Review - The web server or application server configuration takes an important role in protecting the contents of the site and it must be carefully reviewed in order to spot common configuration mistakes.

It is impossible to generically say how a server should be configured, however, some common guidelines should be taken into account:

  1. Make sure the server software properly logs both legitimate access and errors.
  2. 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.
  3. 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.
  4. 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).
  5. 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.
  6. 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.

Logging

Logging is an important asset of the security of an application architecture, since it can be used to detect flaws in applications (users constantly trying to retrieve a file that does not really exist) as well as sustained attacks from rogue users.

  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

Some applications might, for example, use GET requests to forward form data which will be seen in the server logs. This means that server logs might contain sensitive information (such as usernames as passwords, or bank account details). 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).

Event logs will often contain data that is useful to an attacker (information leakage) or can be used directly in exploits:

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

Also, in some jurisdictions, storing some sensitive information in log files, such as personal data, might oblige the enterprise to apply the data protection laws that they would apply to their back-end databases to log files too. And failure to do so, even unknowingly, might carry penalties under the data protection laws that apply.

Log Location

Typically servers will generate local logs of their actions and errors, consuming the disk of the system the server is running on. However, if the server is compromised its logs can be wiped out by the intruder to clean up all the traces of its attack and methods. If this were to happen the system administrator would have no knowledge of how the attack occurred or where the attack source was located. Actually, most attacker tool kits include a ‘‘log zapper ‘’ that is capable of cleaning up any logs that hold given information (like the IP address of the attacker) and are routinely used in attacker’s system-level root kits.

Log Storage

Logs can introduce a Denial of Service condition if they are not properly stored. Any attacker with sufficient resources could be able to produce a sufficient number of requests that would fill up the allocated space to log files, if they are not specifically prevented from doing so. However, if the server is not properly configured, the log files will be stored in the same disk partition as the one used for the operating system software or the application itself. This means that if the disk were to be filled up the operating system or the application might fail because it is unable to write on disk.

Log Rotation

Most servers (but few custom applications) will rotate logs in order to prevent them from filling up the file system they reside on. The assumption when rotating logs is that the information in them is only necessary for a limited amount of time. This feature should be tested in order to ensure that:

  1. Logs are kept for the time defined in the security policy, not more and not less.
  2. 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).
  3. 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.

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.

Note - I am making notes from Official OWASP Website you can check it from here https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/

I am just Sharing what I learn for help Other's !!!

#infosec #learn365 #owasp