mubix / cfdb Goto Github PK

Neo4j Query with Blood Hound data:

MATCH (c1:Computer)-[:MemberOf*1..]->(g:Group) WHERE g.objectsid ENDS WITH '-516' WITH COLLECT(c1.name) AS domainControllers MATCH (c2:Computer {unconstraineddelegation:true}) WHERE NOT c2.name IN domainControllers RETURN c2.name,c2.operatingsystem ORDER BY c2.name ASC

Source: https://hausec.com/2019/09/09/bloodhound-cypher-cheatsheet/

Write up:

The following servers have “Unconstrained Delegation”. This means that if an attacker gained access to one of these servers with administrative rights, they can steal Kerberos tickets (specifically ‘Ticket-Granting-Tickets’ TGTs) that can be reused against the Domain Controllers or other systems. It is recommended that this permission be removed if possible, or the systems be protected as high value targets.

/*
Title: Remote File Inclusion
Description: Remote File Inclusion Vulnerability
*/

• LAST UPDATED DATE: 12 - 13 -15
• LAST UPDATED BY: Mike Hodges

Summary

A file inlcusion vulnerability that allows an attacker to include a file located at an external URL

Capabilities and Risk

• Allows attackers to execute arbritrary code on the server that could potentially
  lead to complete compromise of the system

Detection

• Identify scripts that take filenames as parameters
• Pass an external url to a file as parameter to the application and verify
  that the application rendered/executed the file
• If not immediately successful, attempt to identify the filter being used
  and craft input that attempts to bypass it

Remediation

Properly validate all input being passed to file inclusion methods.

References

• https://www.owasp.org/index.php/Testing_for_Remote_File_Inclusion
• http://securityxploded.com/remote-file-inclusion.php
• http://projects.webappsec.org/w/page/13246955/Remote%20File%20Inclusion

Exploitation

--In progress--

/*
Title: Local File Inclusion
Description: Search engine meta data about the finding
*/

• LAST UPDATED DATE: 12 - 13 - 15
• LAST UPDATED BY: Mike Hodges

Summary

Local File Inclusion (LFI) allows the attacker the include files that are already locally present on the server
through the exploitation of a flawed file inclusion procedure.

Capabilities and Risk

• Could allow attackers to access arbritrary files on the system leading to
  potential information information disclosure
• In more serious cases, LFI, can lead to remote code execution on the server and
  complete compromise of the system. (https://www.exploit-db.com/papers/12886/)

Detection

• Identify scripts that take filenames as parameters
• Use directory traversal sequences in the filename parameter in order to access
  a file that is known to be present on the system
• If not immediately successful, attempt to identify the filter being used
  and craft input that attempts to bypass it

Remediation

Implement file inclusion procedures that properly sanitize all input.

References

• https://www.owasp.org/index.php/Testing_for_Local_File_Inclusion
• http://hakipedia.com/index.php/Local_File_Inclusion
• https://www.exploit-db.com/papers/12886/

Exploitation

Consider the code below (Credit: owasp.org)

The code is normally used like this:

http://vulnerable_host/preview.php?file=myFile

However an attacker can exploit the lack of sanitization by using null-byte terminators, %00, to effectively end the string before .php is added:

http://vulnerable_host/preview.php?file=../../../../etc/passwd%00

This would results like the following:

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
alex:x:500:500:alex:/home/alex:/bin/bash
margo:x:501:501::/home/margo:/bin/bash

/*
Title: SQL Injection
Description: SQL Injection SQLi database vulnerability
*/

• LAST UPDATED DATE: 12 - 13 -15
• LAST UPDATED BY: Mike Hodges

Summary

A code injection technique that allows an attacker to make arbritrary calls
to the backend database.

Capabilities and Risk

SQL Injection allows an attacker to access entries in the application database
and in some cases write to the database which can lead to code execution on
the server.

It can lead to partial or complete loss of the database entries and in
the worst case scenario allow an attacker to gain a foothold on the machine.

Detection

• Identify where user input being used as data for a database call (i.e. username)
• Attempt to inject SQL meta-characters and commands to modify/create a query in order to view the database contents

Remediation

Properly sanatize all database calls using both a whitelist of known good input and blacklist of potentially dangerous meta characters and functions.

References

• https://www.owasp.org/index.php/SQL_Injection
• http://pentestmonkey.net/cheat-sheet/sql-injection/mysql-sql-injection-cheat-sheet -- payload crafting cheatsheet
• https://www.exploit-db.com/papers/13045/ -- SQL Injection tutorial on MySQL, great walkthrough

Can we have sections added for OSINT, Physical Security, and possibly Business Practices or something that would relate to social engineering and users being exploited by phishing?

/*
Title: Apache Commons Collections Deserialization
Description: Search engine meta data about the finding
*/

• LAST UPDATED DATE: 12 - 13 - 15
• LAST UPDATED BY: Mike Hodges

Summary

The Apache Commons Collections Java library insecurely deserializes data
and with InvokerTransformer an attacker can build serializable objects that
will execute arbitrary Java code.

Capabilities and Risk

Any application that has the Apache Commons Collection library in its Java
class path and accepts serialized data can be coerced into executing arbrtrary code
on the attacker's behalf

This poses a high risk to any server running the ACC library and could
lead to complete compromise of the system.

Detection

Verify the server is running Java with the Apache Commons Collections in the class path.

Identify serialized Java objects being sent ot the application

Replace the serialized Java object with your base-64 encoded payload and verify.

Remediation

Santizie all deserialized data being processed to the application

Update the Apache Commons Collection to the newest version.
Only fixes some of the insecure functions, some still exist
From Adobe's Statement:
"However, to be clear: this is not the only known and especially not unknown useable gadget. So replacing your installations with a hardened version of Apache Commons Collections will not make your application resist this vulnerability.

References

• http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ -- great read
• http://www.kb.cert.org/vuls/id/576313
• https://github.com/foxglovesec/JavaUnserializeExploits -- exploits
• Link to Nessus/NeXpose/Qualys write up

There are X users who have their passwords stored in active directory. These accounts were verified to have these passwords still active and the accounts are enabled. This is usually the result of an application creating a user in Active Directory programmatically using direct LDAP queries. It is recommended these accounts be investigated to see if they are still in use and if the passwords can be changed. The effect is that any user in the domain can query LDAP for these passwords in clear text.

• LAST UPDATED DATE: 12 - 13 - 15
• LAST UPDATED BY: Mike Hodges

Summary

Directory traversal is an HTTP exploit which allows attackers to access restricted directories and/or execute commands outside of the web server's root directory.

Capabilities and Risk

• Access restricted files such as application source code with the permissions of the web server

Detection

• Identify user input that the application uses in order to retrieve files and attempt to access higher directories
  by inputting a ../ ex. ../../../../etc/passwd.
• You will often encounter input filters that discourage simple ../ so try different
  encodings and patterns such as url encoded or unicode encoded characters.

Remediation

• Properly sanitize user input that is used to access files on the server

References

• https://www.owasp.org/index.php/Path_Traversal
• http://projects.webappsec.org/w/page/13246952/Path%20Traversal

Exploitation

Input example source code here

Instead of having "LAST UPDATED BY:" in the template, how about handling contributions the way NMAP NSE's do, where you just list all of the people who have made contributions to that template on an "author(s)" line. In practice, if you make a contribution, you just append your name to the list of authors. I foresee multiple people having a hand in many of these findings, and it would be nice to see which ones have had the most eyes on them.

For example, from the http-enum nmap NSE script:

author = "Ron Bowes, Andrew Orr, Rob Nicholls"