Common Findings Database

From Church of 0 Day Wiki
Jump to: navigation, search

Crypto[edit]

Block Cipher Uses ECB Mode
Summary A block cipher in ECB mode encrypts every block of plaintext into ciphertext without using any additionaly nonce/input. What this results in is that for every pair of matching plaintext inputs, their corresponding ciphertexts will also match.
Capabilities and Risk Though each block is still effectively encrypted to the specifications of the algorithm selected. ECB mode does not do anything to change the output of a block to differentiate it from any other block if the two blocks are identical. What this means in effect, is that if you encrypted the message "zaeyx is a cool dude, dude." The "dude"s would come out as the same ciphertext. The output might look something like "yuqbd jd q eadn defg, defg." This reveals information about the plaintext. And might in some cases be enough to allow the decryption of the entire message.
Detection Detection of a block cipher operating in this mode can be accomplished by observing the output ciphertext for signs of repeating patterns equal to one block length. With access to the cipher's implementation in code, one can check that ECB is or is not the mode of operation.
Remediation One must not operate block ciphers in ECB mode. Switch to a preferred mode such at CTR (counter) mode, or CBC (cipher block chaining) among others.
References https://crypto.stackexchange.com/questions/20941/why-shouldnt-i-use-ecb-encryption
https://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Eng.pdf
https://news.ycombinator.com/item?id=7959519
Exploitation An attacker may exploit a ciphertext encrypted in this manner by comparing blocks to find repeating patterns. The attacker may then use this information to reveal the plaintext of the ciphertext by careful analysis.
Password Storage Uses Fast Hashing Algorithm
Summary Hashing algorithms are the defacto standard for disk resident password representation formats. Such hashing algorithms are defined to only operate in one direction. That is, they only turn plaintext passwords into their hashed form. They cannot take a hash and "decrypt" it back into a plaintext password. As such, an attacker attempting to reveal the plaintext associated with a hash has only one option, make brute force attempts at producing a matching hash. Since hashing algorithms must also by definition be deterministic, if the attacker is able to find a hash which matches the hash he is attempting to "crack." He can assume beyond all reasonable doubt that the plaintext he used to create that hash is the user's plaintet password.

The difference between "fast" and "slow" hashing algorithms is exactly that. One algorithm takes very little time to compute. The other takes much longer to compute, (is slow).

When dealing with fast hashing algorithms, and attacker is able to make many more guesses in the same amount of time, increasing his chance of finding the resulting plaintext password.

Capabilities and Risk Fast hashing algorithms are used primarily for their simplicity/ease of use, and speed/insignificant load on computational resources. However when using fast hashing algorithms, you must understand that the passwords stored with this algorithm are potentially orders of magnitude easier to reveal to an attacker, should he gain access to the stored hashes.

With the plaintext passwords in hand, the attacker is highly likely to use the information to further his malicious intentions. Or to leak the plaintext passwords on the internet in an attempt to embarrass and humiliate your service in the eyes of the public.

Detection Detection of such a vulnerability is exceedingly simple. Determine if the algorithms your service uses to hash passwords is a fast or slow hashing algorithm (if it is a hashing algorithm at all).

Examples of fast hashing algorithms are as follows:

If access to the application is limited for the purposes of ascertaining the the name of the algorithm used, it is often possible to determine the algorithm that generated a hash by looking at the hash itself.

One such tool capable of performing this analysis to a limited extent is John the Ripper, which can be found here.

Remediation Remediation is simple. One should upgrade any systems capable of receiving such an upgrade, to slow hashing algorithms.

Examples of which are as follows:

Another interesting hashing algorithm is SCrypt which uses extensive amounts of memory rather than time in order to limit an attacker's ability to parallel compute when attacking a hash.

If for some reason it is impossible for a system or service to be upgraded from a fast hashing algorithm, it is then paramount that a proper password policy be set and enforced in order to increase the complexity of stored passwords and increase the work the attacker must perform.

An example of a password policy that might mitigate the use of fast hashing algorithm to some extent is as follows: 

>>Min-Length:21
>>Must Contain: Upper/Lower Alpha, Numeric, Special Char
>>Recommend: Passphrase, not password
References http://codahale.com/how-to-safely-store-a-password/

https://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage

https://security.stackexchange.com/questions/15790/why-do-people-still-use-recommend-md5-if-it-is-cracked-since-1996

https://crackstation.net/hashing-security.htm

Exploitation Exploitation for an attacker is quite simple. Just load an unknown hash that into a hash crackingg piece of software such as John the Ripper and wait. With a fast hashing algorithm and a bit of luck, it won't take long.

Printers[edit]

Default Credential (Printers)
Summary Most enterprise printers and many SOHO devices ship with an interface allowing for remote configuration of the devices that are located on the network. In many cases, the security of these systems will be overlooked due to a lack of security understanding about the capabilities of these devices. This can allow printers to act as a means to gain network details and to potentially gain access to sensitive information being printed.
Capabilities and Risk Many of the capabilities and risks depend on the features of the printer. More advanced devices will often provide details of the documents printers, including potential username information. Some printers may have "advanced functions" that can provide additional network information.

Gain access to printer files and configuration Execute programs from the printer by loading custom firmware images Read files on the printer and potentially intercept printed files

Detection Printers with Web UIs will most often standard http/https ports (80/443). Additional functionality may also be exposed through the printer ports (e.g. HP JetDirect port 9100).
Remediation Printers should have all web interface passwords changed to strong passwords. Additionally, it is important to ensure that only SSL is available for login when the option is available.
References IronGeek page on Printer Hacking

Deral Heiland: From Printer to Pwned
Extensive Default Password List

Exploitation Standard web interface used for accessing UI and entering passwords.

Tomcat[edit]

Tomcat Manager - Default Login Credentials
Summary Default Tomcat Management credentials
Capabilities and Risk This is to replace any "level" or "score" because of how much context is needed for a vulnerability to have one which is beyond the scope of this database.
  • List of possible uses for this vulnerability to give real-world uses
  • Read files as www-data (or use web server is running as)
  • DDoS service
  • Code execution (for this one to fly there needs to be a reference proving it)
Detection Default credentials can be tried by authenticating witht the http Tomcat login. The list below contains default Tomcat credentials.

username/password

  • tomcat/tomcat
  • both/tomcat
  • role1/tomcat
  • manager/manager
  • admin/admin
Remediation Default accounts should be disabled or have their password reset.
References [Link to blog post]

[Link to CVE] [Link to Metasploit module] [Link to Nessus/NeXpose/Qualys write up]

Exploitation The tomcat management console can be accessed by navigating to the url: http://x.x.x.x:8080/manager

WEB[edit]

Command Injection
Summary Command Injection occurs when an insecure application passes unsafe user supplied content to a system shell.
Capabilities and Risk When Command Injection occurs, and attacker may be able to execute arbitrary commands as the web application's host machine. This gives effective control over whatever portion of the host machine the web server's user is given access to.
Detection Detection can be accomplished by searching for command line access by the web server's user that is not expected to have been given by the normal operations of the application. For example, if an application uses command line operations to perform a ping. If the web server's user is executing any command other than "ping" you might have a problem.

One can search for abnormal commands in a number of ways, including but not limited to monitoring web user command line history, monitoring of logs (such as apache's access.log, monitoring of network traffic to detect requests on the wire (IDS for example), and hardcoding monitoring routines into the application itself.

Remediation Sanitize input that is passed to the system shell from an untrusted source.

Here are a number of resources to assist you in properly sanitizing data in a number of languages.

PHP

ASP.NET

Ruby Rails

Java+method)

Python/Ruby

Input sanitization is accomplished by removing/escaping special characters from user supplied input. Or by properly quoting the user supplied input.

References https://www.owasp.org/index.php/Command_Injection
Exploitation To exploit this vulnerability, an attacker simply injects into a vulnerable field a command seperator for the system type (linux, windows) of the host machine in question. Followed by the command to be executed.

The command seperator is used to end the command that the application expects to execute, and everything that follows is added as commands appended to the application's usual request.

For example, if an application takes user input in the form of an IP address to "ping" from the command line; and the application does not correctly sanitize input: A normal request might look like "ping user_supplied_ip". The injection might look like "ping && cat /etc/passwd".

Example is illustrated below. <syntaxhighlight lang="php"> <?php

if(isset($_GET['ip'])) { 

       $ip = $_GET['ip'];
       $output = shell_exec("ping -c 3 $ip");
echo "
$output
";

} ?> </syntaxhighlight> The PHP code above is vulnerable to command injection since it does not sanitize any input.

Here is what the ping form might look like with a user supplied IP to ping.

  • File:Injection 0.png
    Here is what the ping form might look like with a user supplied IP to ping.
  • File:Injection 1.png
    Once the user submits the form the site takes the IP parameter and drops it to the command line where it executes the command above.
  • File:Injection 2.png
    However if the user was to supply a command seperator as seen here (Linux command seperator) they would be able to execute arbitrary commands, not just ping.
  • File:Injection 3.png
    And the results...

As you can see, exploitation is quite simple in a basic scenario like this.

Default/Guessable Login Credentials
Summary A brief summary of the vulnerability
Capabilities and Risk This is to replace any "level" or "score" because of how much context is needed for a vulnerability to have one which is beyond the scope of this database.
  • List of possible uses for this vulnerability to give real-world uses
  • Read files as www-data (or use web server is running as)
  • DDoS service
  • Code execution (for this one to fly there needs to be a reference proving it)
Detection How does one detect the exploitation of this vulnerability, or detect its presence.
Remediation What are some of the ways to fix this vulnerability?
References *Link to blog post
  • Link to CVE
  • Link to Metasploit module
  • Link to Nessus/NeXpose/Qualys write up
Exploitation A write up on how this vulnerability can be exploited with demo code or screen shots
Directory Traversal / File Include
Summary Insufficient web server ACLs and/or input sanitization allow direct file access requests for files outside of the intended directory or document root directory.
Capabilities and Risk *Information disclosure (reading files as web server user)
  • Overwrite files (overwrite files as web server user)
  • Denial of Service
Detection To detect directory traversal vulnerabilities, the application must first be mapped to identify parameters which reference files on the server, such as /profile.php?user=bob.html or /display.asp?page=../main.html. Once the target pages and parameters have been identified, attempt to access files which would likely reside on the target system. Identifying the operating system, web server software and version, and application version will assist in identifying likely candidates.

If the server is vulnerable to directory traversal, it will be possible to "escape" from the intended directory and/or document root by referencing a series of directories above the intended directory using dot-dot-slash ("../") notation. Depending on the starting directory, several dot-dot-slashes to reach the target directory.

Example #1: Linux password file http://www.example.com/profile.php?user=../../../../../etc/passwd

Example #2: Window.ini http://www.example.com/display.asp?page=../../../../../Windows/system.ini Windows Web Servers If the target web server is running on Windows, it may be necssary to use back slashes ("\") instead of forward slashes.

Absolute Path Traversal In some instances, it may be possible to specify the absolute path of the file.

Example #3: Linux password file via absolute path traversal

http://www.example.com/profile.php?user=/etc/passwd

Encoding During testing, it may appear that the web server ACLs and input sanitization are functioning properly. Testing should also include requests using character encoding to bypass input sanitization routines in the application.

Encoding Example #1: http://www.example.com/profile.php?user=..%2f..%2f..%2f..%2f..%2fetc%2fpasswd

Encoding Example #2: http://www.example.com/profile.php?user=%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd

Overwriting files If the web application uses client-supplied input to specify the target location or file name for file uploads, it may be possible to overwrite existing files, provided the web server user has write permissions to the target file and directory. In some instances, this may result in a denial of service condition. Testing for directory traversal file overwrite vulnerabilities uses the same methods outlined above.

Remediation The developer should define the intended document root directory or directories that are valid for the file access request. All file access requests should be compared against this list of valid directories. Additionally, whenever client-supplied input (including cookies and headers) is used as part of a file access request, input sanitization should be employed using a whitelist filter.
References *https://www.owasp.org/index.php/Path_Traversal
Exploitation See examples above.
Insecure Direct Object Reference
Summary Insecure Direct Object Reference results from using user-supplied input to directly reference objects. Insecure Direct Object References allow attackers directly reference objects by manipulating the parameter value controlling the object reference, allowing access to objects owned by other application users.
Capabilities and Risk Capabilities:
  • Direct access to database records, messages, files, etc.
Detection To detect Insecure Direct Object Reference, the application must first be mapped to identify parameters which may control object references, such as ?invoice=12345 or ?msgId=654321. After identifying potential testing points, attempt to enumerate other objects by manipulating the value associated with the identified parameter. Insecure Direct Object Reference exists when the application returns objects belonging to other application users.

Typically, Insecure Direct Object Reference exists within the authentication boundary of the application. However, in poorly designed authentication and authorization schemes, it may be possible to access objects for which authentication is normally required. For example, if a company's support page offers only certain knowledgebase articles to unauthenticated users and requires authentication for all others, it may be possible to access articles which normally require authentication. In this example, if kbarticle.php?article=12345 is viewable by unauthenticated users, but article=55555 is intended for only authenticated users, if article=55555 is accessible by an unauthenticated user then Insecure Direct Object Reference exists.

Remediation To prevent Insecure Directo Object References, the web application must assign ownership of each referenceable object to a given user, set of users, or group. Whenever objects are referenced, the authorization record for the referened object must be compared against the requesting user. Users lacking appropriate authorization should be denied access to the object.
References *https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References
Exploitation *Identify parameters which reference objects
  • Enumerate objects using BurpSuite Intruder or similar methods
  • Determine if objects are owned by another user or should be referenceable by requester
Redirection Based Privilege Escalation
Summary Redirection Based Privilege Escalation describes a situation in which a web application is split into at least two parts. One highly secure section (such as a payment system) and one less secured section (an index page perhaps). When an attacker gains access to the less secure portion of the site, he may leverage this capability to gain access to the application flow and in effect escalate his privileges to exploit the more secure section.
Capabilities and Risk An attacker may utilize this technique to turn access to a less secured section of a site into full application flow control.

More work is spent securing the highly sensitive section of the site. But a vulnerability is a less sensitive section of the site is potentially just as dangerous under this model.

Detection Detection relies on the application defense team being able to detect the underlying XSS in the less sensitive portion of the application.

Additional detection methods include writing hidden javascript routines into the code of the site which send an alert home if they are hosted somewhere other than the original site.

Remediation Do not keep the security of one portion of the site your highest priority. Control over application flow can be achieved with an injection to any section for the subset of users which visit that section.
References N/A
Exploitation An attacker may in effect escalate their privileges to gain access to application flow by first finding an inject-able field in any one portion of the site. The attacker then injects into that field a script that performs a redirection to a site that they have control over. The attacker clones the insecure application and redeploys a copy on their malicious site.

When a user visits the page containing the injection they are redirected to the attacker's malicious copy of the vulnerable application. This happens transparently, and unless the user is exceptionally privy they are unlikely to notice the redirection. They will then continue to use the application as before. Potentially accessing the highly secure sections (such as the payment system) on the attacker's malicious site.

SQL Injection
Summary SQL Injection occurs when a un-sanitized field takes content from an un-trusted source and passes it directly into an SQL query.
Capabilities and Risk SQL Injection allows an attacker to execute arbitrary SQL in the context of the web application. Potentially gaining the ability to read, write, and modify database contents.
Detection Detection can be accomplished by white-listing known database lookups performed by the web application, and alerting if any commands other than the white-listed ones are executed against the database in the context of the web application.

This can be accomplished by coding a method into whatever application is used to access the db, that performs these checks/alerts. MySQL query history can also be monitored directly.

Detection of SQLi can also be performed by network or host based IDS.

SQLi can also be detected by monitoring for unexpected changes to the database and its contents manually. Or by monitoring the web application's logs (such as apache's access.log). Or by monitoring network activity for signs of sensitive data being accessed by a remote party.

Remediation Correctly sanitize input into the database from any and all un-trusted sources.

This resource provides instructions for proper sanitization in a number of languages: http://bobby-tables.com/ Another resource can be found here.

The main method by which one avoids SQLi is through the use of parametereized queries. A parameterized query is a query for which specific inputs are mapped to specific parameters. The exact way to implement is different in every language and for every library (SQL backend/server type). However, here is a wonderful resource, a multi-language cheat sheet from OWASP.

The end goal is to remove/escape special characters from the user supplied input. Or to properly encapsulate the user supplied input in quotes that it cannot escape. These methods can accomplish that for you.

References https://www.owasp.org/index.php/SQL_Injection
Exploitation An attacker can exploit this vulnerability by simply injecting arbitrary SQL into an unsanitized input field. The attacker is usually required to properly guess the format of the query into which his input in injected. He can then reverse engineer the format, causing his data to in effect "break out" of the query and create it's own.

For example. If a query performs a lookup of username by first name in a users table it might look something like this: SELECT username FROM users WHERE firstname='user_supplied_firstname'. In this scenario, the attacker would be able to "break out" of the quoted parameter by setting his input like so user_supplied_firstname = ' or 1=1;--

The final query would look like this: SELECT username FROM users WHERE firstname= or 1=1;--

This would tell the SQL database to return all the usernames where the firstname is equal to , or where 1=1. 1 is always equal to 1, therefore it always returns true. This will cause the query therefore to return all of the usernames in the database.

It's a very basic example. But it demonstrates exactly what SQLi is. When special characters are allowed into a query unescaped, they can modify the query itself.

An example is demonstrated below. <syntaxhighlight lang="php"> <?php if(isset($_GET['firstname'])) { 

       $search = $_GET['firstname'];
       $db = new SQLite3('users.db');
       $results = $db->query("SELECT username FROM users WHERE firstname='$search'");
       while($row = $results->fetchArray()){
               echo $row[0];
               echo "
";
       }

} ?> </syntaxhighlight> The above PHP code is vulnerable to SQLi. It doesn't attempt to escape or remove special characters from the user supplied input before passing it into the query.

It also does not use parameterized queries to wrap the user supplied input inside of quotes, forcing them to stay inside a specific parameter.

As you can see, it doesn't take much for an attacker to exploit SQLi when presented with a vulnerable application.

Server-Side Request Forgery (SSRF)
Summary The application takes a URL from the user and retrieves the contents of the URL on behalf of the user. However, the application does not sufficiently validate the requested destination. (Paraphrased from CWE-918)
Capabilities and Risk *By exploiting SSRF, an attacker can make requests from the application server.
  • An attacker can interact with otherwise restricted IP addresses and services, either on the server itself (localhost), or on other IPs. This can give an external attacker visibility to an internal environment. This includes using the vulnerable server to port scan other hosts (Cross Site Port Attacks (XSPA)).
  • If the vulnerable server can communicate with backend API's or services that do not require authentication, the external attacker can fully interact with those services.
  • If the vulnerable application is hosted in a cloud environment, such as Amazon EC2 and OpenStack, this may allow the attacker to gain access to metadata services, which can be used to gain access to sensitive information, sometimes including credentials or private keys.
Detection 1) Browse the target application using an intercepting proxy (Burp, Fiddler, ZAP, etc). Determine if the following conditions apply:

The target application is accepting a URL from you. Ex: www.thirdpartysite.com The target application is displaying part or all of the result back to you. 2) If both conditions apply, look at your proxy logs. If you do not see the request to the resource (www.thirdpartysite.com) in your proxy logs, but you see the content on the page, this indicates that the content returned to you has been requested by the server itself on your behalf. This behavior indicates the application is vulnerable to SSRF.

An intentionally vulnerable demo application requesting a page on behalf of the user:

  • File:Ssrf1.png
    An intentionally vulnerable demo application requesting a page on behalf of the user:
  • File:Ssrf2.png
    Requesting a webpage that shows the User-Agent and IP address of the requester:
Remediation Rather than proxying requests on behalf of users, the application should have the user’s browser retrieve the desired information. If it is necessary to proxy the request, a white-list should be used on the server side and the User-Agent information should be stripped or modified.
References OWASP Top 10 2013-A1-Injection

CWE-918: Server-Side Request Forgery (SSRF) CWE-441: Unintended Proxy or Intermediary ('Confused Deputy') EC2 Instance Metadata Service Documentation OpenStack Metadata Service Documentation Compromising an unreachable Solr server with CVE-2013-6397 Bringing a Machete to the Amazon Prezi Got pwned - A tale of responsible disclosure

Exploitation Once you have determined that the application is vulnerable to SSRF, the vulnerability can be exploited in many different ways.

Manually testing SSRF using a browser (GET Requests), or something like Burp Repeater (POST Requests) The level of risk you can demonstrate depends on how much you know about the environment. Is the vulnerable application hosted on a service that uses a metadata service (ex: http://169.254.169.254)? If so, pull up the reference documents above and make some requests to valid metadata service endpoints for your respective service. EC2: http://www.example.com/?url=169.254.169.254/latest/dynamic/instance-identity/document To discover services, exploit SSRF to perform a XSPA. One simple way to do this is to use Burp Intruder. Send the initial Request to Burp Intruder For the URL, use http://host:port format, and make the port the position For the payload, enter the port numbers you want to test (only TCP works) Start the attack. Pay attention to the response times for each requested port. You should be able to infer which ports are open and which ports are closed based on the response times. Quicker times are open ports, longer times are closed ports (they timed out before the client gave up). Can you target other services via SSRF that are not directly accessible to you? You could even run a tool like dirbuster or the http-enum NSE via SSRF.

  • File:Ssrf3.png
    Exploiting SSRF to query the Amazon EC2 Metadata service:
  • File:Ssrf4.png
    Exploiting SSRF to query Amazon EC2 instance user data:
  • File:Ssrf5.png
    Exploiting SSRF with Burp Intruder and a word list to query a second internal host that is not directly accessible to the attacker. Note how request 3 is a different size than all of the other requests. That is because for all of the other requests, a "page not found" message was sent:
Weak SSL Configurations
Summary Many web servers still support out dated methods of securing connections with SSL/TLS. These methods can make the communications between the server and clients more suspectible to both traditional man-in-the-middle attacks and to more sophisticated attacks where the SSL Handshake is intercepted and modified to create weaker connections between the client and the server.
Capabilities and Risk This can be used to lead to the exposure of encrypted communications, which are often used to transmit sensitive data, which includes (but is not limited to):
  • Usernames/Passwords
  • Personally Identifiable Information
  • Personal Health Information
  • Financial Data
Detection Readily available tools like 'sslscan' can be used to determine the versions of SSL/TLS and cipher suites supported by a server. Servers can also be tested using 'openssl s_client', which has several configuration options for enabling different versions of SSL/TLS and cipher suites. This can allow for testing a server's connection and determining the supported cipher suites.
Remediation The best remedy for this solution is to ensure that web servers relying upon SSL/TLS are using up-to-date cipher suites that offer appropriate levels of protection. Modern cipher suites making use of algorithms like AES and SHA-256 are examples of the algorithms to consider for use. Servers should be configured to a minimum SSL/TLS version of TLS v.1.0
References *TLS Wikipedia
Exploitation *An attacker can use methods like ARP Spoofing or rogue wireless access points to intercept network communications
  • Use iptables to re-direct to your proxy listening port: iptables -t nat -A PREROUTING -p tcp --destination-port 443 -j REDIRECT --to-ports <$listenPort>
  • Use proxy tool (e.g. mitmproxy) to intercept the connection and alter SSL Handshake so client only requests weaker versions of SSL and/or weaker ciphers (configuration will vary depending on the tool(s) used.
XSS - Reflective
Summary Cross-site scripting (XSS) is a vulnerability that enables attackers to inject client-side code into web applications.
Capabilities and Risk Worst case RCE (see reference for Hipchat below)
Detection How does one detect the exploitation of this vulnerability, or detect its presence.
Remediation What are some of the ways to fix this vulnerability?
References *XSS to RCE in Hipchat: http://maustin.net/2015/11/12/hipchat_rce.html
  • Link to CVE
  • Link to Metasploit module
  • Link to Nessus/NeXpose/Qualys write up
Exploitation A write up on how this vulnerability can be exploited with demo code or screen shots
XSS - Stored
Summary Cross Site Scripting is
Capabilities and Risk This is to replace any "level" or "score" becuase of how much context is needed for a vulnerability to have one which is beyond the scope of this database.
  • List of possible uses for this vulnerability to give real-world uses
  • Read files as www-data (or use web server is running as)
  • DDoS service
  • Code execution (for this one to fly there needs to be a refence proving it)
Detection How does one detect the exploitation of this vulnerability, or detect its presence.
Remediation What are some of the ways to fix this vulnerability?
References *Link to blog post
  • Link to CVE
  • Link to Metasploit module
  • Link to Nessus/NeXpose/Qualys write up
Exploitation A write up on how this vulnerability can be exploited with demo code or screen shots
Cross Site Trust Exploitation
Summary Cross site trust exploitation occurs when an attacker is able to inject data into a web page for the purpose of making the site appear to say something it otherwise would not. This results in the user's trust in the site being exploited. No actual code execution is required.
Capabilities and Risk XSTE may allow an attacker to trick users into performing actions that they otherwise would not. If the user trusts that the content of the site cannot be set by anyone other than the site itself the user is highly likely to trust any content appearing on the site.

The attacker might use for example, an error field in a form which allows injecion of arbitraty (non-code) content to make the error field appear to read that the user must contact the "site admin" @ "[email protected]".

Detection Detection may be accomplished by monitoring site content and potential injection points. Your best hope is not detection, but rather remediation.
Remediation You must not allow injection into any portion of your application where injected content would appear to be coming from the site itself. The user must not be able to in any way edit error fields for example. (This commonly occurs when a web developer creates one error page which takes the error message as a parameter.)
References http://www.lanmaster53.com/2014/05/cross-site-trust-exploitation/
Exploitation The exploitation of this vulnerability is specific to the application in question. It commonly requires nothing more than the attacker writing content into a sanitized field which does not properly format its output to clarify the origin of the content.

Please see the attached blog post for more information.


Windows[edit]

Old KRBTGT Password
Summary Commonly referred to as the "Golden Ticket", this vulnerability stems from the fact that the KRBTGT user account that Microsoft uses to "sign" tickets isn't forced to change and is often discounted due to the fact that it expires soon after the domain is created. If an attacker is able to gain access to the password hash of this account (usually by dumping the domain hashes), they will be able to create kerberos ticket to log in to any Windows domain service or share as any user they wish, even fake ones, with any group membership they wish.
Capabilities and Risk Anyone with access to the KRBTGT user account's password hash can effectively authenticate as any user in the domain until the account's password has been changed twice.
Detection TODO add detection mechanisms, there are a few
Remediation Set up a script to change the password of the KRBTGT account password once a day. This limits the possible abuse window to 48 hours (because of the requirement to change the password twice to be effective). With a 48 hour window, it is less likely that an abuse of the Golen Ticket will be beneficial to an attacker or insider who has gotten to the point where they can dump the KRBTGT's account password hash.
References Kerberos & KRBTGT: Active Directory’s Domain Kerberos Service Account: https://adsecurity.org/?p=483
Exploitation A write up on how this vulnerability can be exploited with demo code or screen shots
PowerShell
Summary PowerShell scripting provides a lot of power to IT Administrators, but it can also be a powerful tool for an attacker who gains access to a system running PowerShell. The scripting can allow an attacker to perform many functions that may normally require them install other applications/tools to perform those functions.
Capabilities and Risk PowerShell can prove to be useful to attackers for a variety of reasons. There are examples where systems which had access to the cmd.exe blocked did not have the same access to powershell.exe blocked, allowing essentially the same level of access as with the cmd.exe.

Additionally, the vast scripting capabilities mean that many tools and exploits can potentially be run from a system on which a standard user account may not have privilege to install tools. These tools could be used to perform functions to elevate privileges on the local system, perform network reconaissance, perform attacks against other remote systems, etc.

Detection Execution of powershell.exe on a Windows system is a sign of its availabilty. To check the execution policy, you can run: 
Get-ExecutionPolicy
Remediation The best policy is to disable script execution within PowerShell. The Set-ExecutionPolicy allows a Restricted option that will prevent the execution of scripts. While some security guides may recommend setting a policy that only allows signed scripts, this is a trivial barrier for an attacker to bypass. An attacker can bypass this by loading their own user-level certificate (and if necessary CA) and sign scripts that way. These scripts would then still validate as signed.
References *Wikipedia link on PowerShell
Exploitation A write up on how this finding can be exploited with demo code or screen shots
Shared Local Windows Admin Password
Summary Pass the Hash is
Capabilities and Risk Lateral code execution and access to all systems with same local admin password
Detection Other than dumping hashes and trying it out yourself, I'm lost on this one
Remediation *Disable the local Administrator (RID 500) account. Or simply do not enable the account as it has been disabled by default since Windows Vista
  • Enable LocalAccountTokenFilterPolicy registry key as detailed in the references
  • Use Microsoft's LAPS or alternative local account randomization tool to randomize the local account passwords.
References *Pass the Hash
Exploitation Dumping hashes from exploited machine then using the hash to access other machines on the network
WDigest Enabled
Summary WDigest is an authentication funtion that is built into Windows. It is used to allow automatic authentication against web applications that require Digest authentcation (MD5). In order to provide the MD5 hash automatically, Windows stores the clear text version of that the user's password. Tools like Mimikatz and WCE provide a way to dump these passwords out of memory with the use of administrative access to a system. Mimikatz even has the ability to do this offline with a memory dump of a system's LSASS process.
Capabilities and Risk Lateral code execution and access to all systems that require only password authentication. Due to the fact that Pass-the-Hash is non-trivial with RDP and usually requires specific settings to be set, a clear text credential is much more damaging to an organization.
Detection *Host level by detecting Mimikatz or WCE usage
  • Network level by mass usage of credentials. Attackers need to find where the credentials dumped can be used and the usual way to do this is to test them out and see where access is granted
Remediation Disable WDigest storage by applying the patch KB2871997 to all applicable systems
References Patch for Wdigest storage: http://blogs.technet.com/b/kfalde/archive/2014/11/01/kb2871997-and-wdigest-part-1.aspx
Exploitation Using Mimikatz to dump clear text credentials
WPAD Enabled
Summary WPAD (Web Proxy Auto Discovery Protocol) affects any system that has "Auto Discovery Proxy Settings" turned on but it is on by default in Windows.
Capabilities and Risk *Steal credentials while on the same network as the user affected
  • SMB or HTTP relay of credentials to NTLM based services
  • Code execution when used in conjuntion with PSEXEC
Detection Wireshark looking for WPAD requests on the wire.
Remediation Windows has per-user and per-system proxy settings making this a very difficult setting to fix enterprise wide.

Using the reference on craig-tolley.co.uk you can set a VB script to run as a Logon Script that will disable this setting.

References *https://www.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol
Exploitation Scenario 1: Credential Stealing 
Code and screen shots of this happening

Scenario 2: SMB Relay to PSEXEC for code execution 

Code and screen shots of this happening
Weak SPN Password
Summary Service Principal Names (SPNs) are a Microsoft way of desinating and identifying where services are running in a domain. These SPNs are attached to accounts within active directory. Any Domain User has the ability to lookup these attributes and request access to the service they provide. The Active Directory Domain Controller will issue the user requesting access to the service a Kerberos ticket. This ticket includes in it the encrypted and hashed password for the user the service is running under. Microsoft does this to allow access in the process of that service.

Example SPN Kerberos Tickets: Id  : uuid-7856e72a-2c40-4d94-a939-8c671b80e2bd-2 SecurityKeys  : {System.IdentityModel.Tokens.InMemorySymmetricSecurityKe 

                      y}

ValidFrom  : 5/19/2016 3:06:41 PM ValidTo  : 5/20/2016 12:53:24 AM ServicePrincipalName : http/win10.sittingduck.info SecurityKey  : System.IdentityModel.Tokens.InMemorySymmetricSecurityKey

Id  : uuid-7856e72a-2c40-4d94-a939-8c671b80e2bd-3 SecurityKeys  : {System.IdentityModel.Tokens.InMemorySymmetricSecurityKe 

                      y}

ValidFrom  : 5/19/2016 3:06:41 PM ValidTo  : 5/20/2016 12:53:24 AM ServicePrincipalName : MSSQLSvc/WIN2K8R2.sittingduck.info SecurityKey  : System.IdentityModel.Tokens.InMemorySymmetricSecurityKey

Capabilities and Risk An attacker can use the SPN services to request tickets for all of the SPNs listed in the domain and attempt to crack the passwords for all of the users the services are running under. If the SPN services are running under a user context, and the attacker is able to brute force crack the password for that user, the attacker can then utilize that password in any way that user has permissions for.
  • Acquire list of services running on a particular host
  • Acquire Kerberos tickets with the context of the user running the service
  • Compromise a domain based on the level of the user running the SPN service (Domain Admin accounts have been used to run Services in the past)
Detection Because this is standard usage of Active Directory it blends into normal daily traffic. Windows Advanced Threat Analytics (ATA) has a module that includes detection of large numbers of SPN Kerberos ticket requests. The other useful detection mechanism is to detect any time a service account is used outside of the machine to which it is assigned.
Remediation *Use Managed Service Accounts if possible. They are automatically restricted to a single machine (will not work for cluster services), and change their password on a regular basis much like computer accounts.
  • Ensure that any service accounts have long, strong passwords (20 character+)
References *Service Principal Names
Exploitation Acquire list of SPNs and request them using Impacket's GetUserSPNs.py example script:

[email protected]:~/impacket/examples# ./GetUserSPNs.py -dc-ip 192.168.168.10 sittingduck.info/notanadmin Impacket v0.9.15-dev - Copyright 2002-2016 Core Security Technologies

Password: ServicePrincipalName Name MemberOf PasswordLastSet

---------- ------------------------------------------------ -------------------

http/win10.sittingduck.info uberuser CN=Domain Admins,CN=Users,DC=sittingduck,DC=info 2015-11-10 23:47:21 MSSQLSvc/WIN2K8R2.sittingduck.info sqladmin01 Crack the service ticket password using oclHashcat:

[email protected]:~/oclHashcat# ./oclHashcat -m 13100 hash -w 3 -a 3 ?l?l?l?l?l?l?l oclHashcat v2.01 (g0891e39) starting...

Device #1: Hawaii, 2858/4025 MB allocatable, 1010Mhz, 44MCU Device #2: AMD FX(tm)-8120 Eight-Core Processor, skipped

Hashes: 1 hashes; 1 unique digests, 1 unique salts Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates Applicable Optimizers:

  • Zero-Byte
  • Not-Iterated
  • Single-Hash
  • Single-Salt
  • Brute-Force

Watchdog: Temperature abort trigger set to 90c Watchdog: Temperature retain trigger set to 80c

Device #1: Kernel /root/git/oclHashcat/kernels/m13100_a3.919aa8b9.kernel (234320 bytes) Device #1: Kernel /root/git/oclHashcat/kernels/markov_le.919aa8b9.kernel (36184 bytes)

Device #1: autotuned kernel-accel to 64 Device #1: autotuned kernel-loops to 50

[s]tatus [p]ause [r]esume [b]ypass [c]heckpoint [q]uit =>

$krb5tgs$23$*user$realm$test/hashcat*$08e2261b7a89e56f530b2f7e0620fe8b$ecdca97c13814c95810d7706faf986dad98d06ba033fc5a45fbe9b417b855db5:hashcat

Session.Name...: oclHashcat Status.........: Cracked Input.Mode.....: Mask (?l?l?l?l?l?l?l) [7] Hash.Target....: $krb5tgs$23$*user$realm$test/hashcat*$08e... Hash.Type......: Kerberos 5 TGS-REP etype 23 Time.Started...: Wed Feb 17 08:33:57 2016 (5 secs) Speed.Dev.#1...: 111.0 MH/s (80.83ms) Recovered......: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts Progress.......: 252313600/8031810176 (3.14%) Rejected.......: 0/252313600 (0.00%) Restore.Point..: 0/456976 (0.00%) HWMon.GPU.#1...: 0% Util, 42c Temp, 20% Fan

Started: Wed Feb 17 08:33:57 2016 Stopped: Wed Feb 17 08:34:04 2016

Wireless[edit]

WPA EAP-TLS Mode Certificate Only
Summary EAP-TLS based authentication is the best form of Wireless security currently available because of the need for a client certificate to authenticate to the wireless. However, without additional authentication it is difficult to detect misuse or theft of the client certificate.
Capabilities and Risk Theft / Creation of valid certificate used for continued access wireless network
Detection *Use of of client certificates on multiple IP addresses
  • Re-issuance of certificates with export flag enabled
Remediation Revoke certificate effected and start investigation into the user(s) effected. Unless re-issued in order to be exportable, administrative access to the machine it was installed on is needed in order to extract the certificate.
References *Setting up EAP-TLS with Cisco WLC
Exploitation Scenario 1 - Exporting Certificate via Mimikatz 
Test
WEP Encryption Used
Summary A brief summary of the vulnerability
Capabilities and Risk fill me
Detection fill me
Remediation fill me
References fill me
Exploitation fill me
WPA Pre-Shared Key
Summary fill me
Capabilities and Risk fill me
Detection fill me
Remediation fill me
References fill me
Exploitation fill me
Wifi Protected Setup (WPS)
Summary WPS is a feature most often found on home wireless routers; however, due to a large overlap in the home, small office, and small business markets, the feature has crept into some smaller corporate environments where wireless networks are setup using more commodity hardware.

WPS can pose a variety of risks for wireless network security. The PIN-based method can be vunerable to brute force attacks over the air. Other types (e.g. push-button methods) would require physical access to the router.

Capabilities and Risk This would allow an attacker to gain unauthorized access to a wireless network, thereby allowing for additional access into the network and systems attached to that connection.
Detection WPS settings can be confirmed by examining the configuration of your wireless router. Button-based WPS methods will have a button located on the router.
Remediation Disable WPS on wireless access points. If a device cannot disable WPS, default PIN values should be changed. Physical access to the router should be limited and secured to prevent local, physical attacks using WPS.
References *WPS Wikipedia
Exploitation reaver -i [monitor interface number] -b [ESSID] -v
Retrieved from "http://churchof0day.org/w/index.php?title=Common_Findings_Database&oldid=26"