1. Authentication
- Brute Force
- Insufficient Authentication
- Weak Password Recovery Validation
2. Authorization
- Credential/Session Prediction
- Insufficient Authorization
- Insufficient Session Expiration
- Session Fixation
3. Client-side Attacks
- Content Spoofing
- Cross-site Scripting
4. Command Execution
- Buffer Overflow
- Format String Attack
- LDAP Injection
- OS Commanding
- SQL Injection
- SSI Injection
- XPath Injection
5. Information Disclosure
- Directory Indexing
- Information Leakage
- Path Traversal
- Predictable Resource Location
6. Logical Attacks
- Abuse of Functionality
- Denial of Service
- Insufficient Anti-automation
- Insufficient Process Validation
|
 |
Directory listing
Automatic directory listing/indexing is a web server function that lists
all of the files within a requested directory if the normal base file
(index.html/home.html/default.htm) is not present. When a
user requests the main page of a web site, they normally type in a
URL such as: http://www.example - using the domain name and
excluding a specific file. The web server processes this request and
searches the document root directory for the default file name and
sends this page to the client. If this page is not present, the web
server will issue a directory listing and send the output to the client.
Essentially, this is equivalent to issuing an "ls" (Unix) or "dir"
(Windows) command within this directory and showing the results in
HTML form. From an attack and countermeasure perspective, it is
important to realize that unintended directory listings may be possible
due to software vulnerabilities (discussed in the example section
below) combined with a specific web request.
When a web server reveals a directory's contents, the listing could
contain information not intended for public viewing. Often web
administrators rely on "Security Through Obscurity" assuming that if
there are no hyperlinks to these documents, they will not be found, or
no one will look for them. The assumption is incorrect. Today's
vulnerability scanners, such as Nikto, can dynamically add additional
directories/files to include in their scan based upon data obtained in
initial probes. By reviewing the /robots.txt file and/or viewing
directory indexing contents, the vulnerability scanner can now
interrogate the web server further with these new data. Although
potentially harmless, Directory Indexing could allow an information
leak that supplies an attacker with the information necessary to
launch further attacks against the system.
Example
The following information could be obtained based on directory
indexing data:
- Backup files - with extensions such as .bak, .old or .orig
- Temporary files - these are files that are normally purged from
the server but for some reason are still available
- Hidden files - with filenames that start with a "." period.
- Naming conventions - an attacker may be able to identify the
composition scheme used by the web site to name directories or
files. Example: Admin vs. admin, backup vs. back-up, etc...
- Enumerate User Accounts - personal user accounts on a web
server often have home directories named after their user
account.
- Configuration file contents - these files may contain access
control data and have extentions such as .conf, .cfg or
.config
- Script Contents - Most web servers allow for executing scripts
by either specifying a script location (e.g. /cgi-bin) or by
configuring the server to try and execute files based on file
permissions (e.g. the execute bit on *nix systems and the use of
the Apache XBitHack directive). Due to these options, if
directory indexing of cgi-bin contents are allowed, it is
possible to download/review the script code if the permissions
are incorrect.
There are three different scenarios where an attacker may be able to
retrieve an unintended directory listing/index:
1) The web server is mistakenly configured to allow/provide a
directory index. Confusion may arise of the net effect when a
web administrator is configuring the indexing directives in the
configuration file. It is possible to have an undesired result
when implementing complex settings, such as wanting to allow
directory indexing for a specific sub-directory, while disallowing
it on the rest of the server. From the attacker's perspective, the
HTTP request is identical to the previous one above. They
request a directory and see if they receive the desired content.
They are not concerned with or care "why" the web server was
configured in this manner.
2) Some components of the web server allow a directory index
even if it is disabled within the configuration file or if an index
page is present. This is the only valid "exploit" example
scenario for directory indexing. There have been numerous
vulnerabilities identified on many web servers, which will result
in directory indexing if specific HTTP requests are sent.
3) Google' cache database may contain historical data that would
include directory indexes from past scans of a specific web site.
References
Directory Indexing Vulnerability Alerts
http://www.securityfocus.com/bid/1063
http://www.securityfocus.com/bid/6721
http://www.securityfocus.com/bid/8898
Nessus "Remote File Access" Plugin Web page
http://cgi.nessus.org/plugins/dump.php3?family=Remote%20file%20access
Web Site Indexer Tools
http://www.download-freeware-shareware.com/Internet.php?Theme=112
Intrustion Prevention for Web
http://www.modsecurity.org
Search Engines as a Security Threat
http://it.korea.ac.kr/class/2002/software/
Reading%20List/Search%20Engines%20as%20a%20Security%20Threat.pdf
The Google Hacker's Guide
http://johnny.ihackstuff.com/security/premium/The_Google_Hackers_Guide_v1.0.pdf
To receive your Free Application
Vulnerability Assessment for testing of one attack vulnerability of your choice, please submit your payment of $1999.00 for a second Directory listing attack vulnerability test.
|
