12. Introduction to Security Assessments
When dealing with information systems and security assessments, it’s important to understand core security principles and concepts. Let’s start by defining key attributes that are the foundation of securing systems.
1. The CIA Triad:
The CIA triad consists of three primary attributes of security:
Confidentiality: Ensures that only authorized actors can access specific system or information.
Integrity: Ensures that the data or system remains unaltered unless intended by authorized parties.
Availability: Ensures that the system or data is accessible when needed, by authorized users.
These concepts form the cornerstone of most security efforts, including system deployment, maintenance, and security assessments.
2. Emphasis on Different Aspects of the CIA Triad:
Depending on the context, one attribute of the CIA triad may be more important than the others.
Example 1 (Personal Journal):
Confidentiality may be the most important factor. You don’t mind if the journal is occasionally unavailable or if its integrity is modified, but preventing others from reading it is critical.
Example 2 (Medical Prescription System):
Integrity is paramount. While confidentiality and availability are important, ensuring that the information in the system remains unaltered is crucial because incorrect data could lead to dangerous consequences.
3. Identifying Issues Based on the CIA Triad:
When discovering an issue or vulnerability in a system, consider which attribute(s) it affects. Vulnerabilities can impact one or more components of the CIA triad.
Example: SQL Injection Vulnerabilities
Confidentiality: If an attacker can use SQL injection to extract data from the database without changing it.
Integrity: If an attacker can modify data in the database using SQL injection.
Availability: If an attacker initiates a resource-heavy query via SQL injection, leading to a denial of service (DoS) attack.
Multiple (Confidentiality, Integrity, Availability): If SQL injection allows the attacker to gain full access to the host operating system, they can compromise all three aspects by accessing, modifying, and potentially disabling the system.
4. Risk, Threats, and Vulnerabilities:
Understanding risk involves recognizing threats and vulnerabilities.
Risk is what you’re trying to prevent from happening (e.g., being compromised or losing data).
Threat refers to who or what could cause harm (e.g., hackers, malware, or natural disasters).
Vulnerability refers to the weaknesses that allow threats to exploit them (e.g., poor system configuration or outdated software).
Example (Malaria):
Risk: The chance of contracting malaria.
Threat: Mosquitoes.
Vulnerability: Lack of immunity to malaria.
Controls: Medication, bug repellent, and mosquito nets can address both the vulnerability and the threat to mitigate the risk.
5. Security Assessment and Risk Mitigation:
When conducting security assessments, it’s crucial to identify risks and categorize them by their associated threats and vulnerabilities. By implementing controls to mitigate threats and vulnerabilities, you can effectively reduce the overall risk. This understanding helps direct your efforts and resources to the most critical areas for system security.
12.1. Kali Linux in an Assessment
1. The Importance of a Clean, Working Installation
Before starting any assessment with Kali Linux, it’s crucial to begin with a clean installation. Reusing an existing setup from previous assessments can introduce several problems:
System Changes: As you work through an assessment, you might install tools or make modifications. While these may solve immediate issues, they complicate system maintenance and future configurations.
Cross-Contamination of Data: Using a single installation across multiple assessments may mix up data from different clients, leading to confusion or security risks.
2. Automate Installation for Future Use
Having a pre-customized version of Kali Linux, ready for automated installation, will save significant time in the future.
Refer to the process of Building Custom Kali Live ISO Images and Unattended Installations for guidance on how to set up your Kali system to be ready quickly for field assessments.
3. Encryption for Data Security
Encrypted Installation: It’s highly recommended to use an encrypted installation for your Kali system, as it protects the data on the physical machine (especially if your laptop is stolen).
Additional Safety Measures: Consider nuking the decryption key after securing an encrypted copy with a co-worker. This ensures the data remains protected until you return and can restore the system with the decryption key.
4. Ensure Proper Package Installation
Think ahead and install the tools necessary for your specific assessment type. For example:
kali-tools-wireless for wireless assessments.
kali-tools-web for web application security testing.
Ensure that all necessary tools are installed before heading out, as internet access during an assessment may be limited.
5. Review Network Settings
Check DHCP settings and review listening services on the system. This is essential because:
Excessive Listening Services: These might reveal your system’s presence to others or get your system flagged during an assessment.
If you’re working in a network intrusion investigation, be particularly cautious not to alter the compromised systems while setting up your network configuration.
6. Forensic Work Considerations
If your role involves forensic investigations, using kali-tools-forensic metapackage in forensics mode is crucial. This mode ensures:
No automatic mounting of disks.
No use of the swap partition.
This ensures the integrity of the system under analysis while still giving you access to forensic tools to investigate without affecting the evidence.
7. The Bottom Line
Proper preparation is key. A clean, customized, and secure Kali Linux installation tailored to the specific assessment will ensure the entire process runs smoothly.
Following these guidelines will help ensure that your Kali environment is efficient, effective, and secure throughout the assessment process.
12.2. Types of Assessments
Types of Assessments:
Vulnerability Assessment: Identifies security flaws in systems.
Compliance Test: Ensures adherence to security standards and regulations.
Traditional Penetration Test: Simulates real-world attacks to find and exploit vulnerabilities.
Application Assessment: Focuses on security within applications, identifying vulnerabilities and misconfigurations.
Key Terms:
Vulnerability: A flaw that could compromise system security (e.g., SQL Injection, Buffer Overflow).
Exploit: Software that takes advantage of a vulnerability to execute unintended actions on a system.
12.2.1. Vulnerability Assessment
A vulnerability assessment is a systematic approach to identifying, categorizing, and reporting weaknesses in a target environment. These assessments are designed to create an inventory of vulnerabilities, helping organizations mitigate potential threats and improve overall security.
Key Concepts in Vulnerability Assessments
Definition of a Vulnerability A vulnerability is any weakness that could compromise the confidentiality, integrity, or availability of an information system if exploited.
Scope of the Assessment The target environment is the boundary within which the assessment is conducted. Adherence to this scope is critical to maintaining client trust and avoiding legal or operational repercussions.
Objectives
Identify and document vulnerabilities in the target environment.
Prioritize risks for remediation.
Establish a baseline for security improvements.
The Assessment Process
Automated Vulnerability Scanning Automated tools (e.g., Nessus, OpenVAS, Nikto) are used to:
Discover live systems in the target network.
Enumerate services, platforms, and software versions.
Match collected data points to known vulnerability signatures.
Key Data Points for Signature Matching The accuracy of vulnerability detection relies on gathering multiple data points:
Operating System Version: Vulnerabilities often depend on the underlying OS version.
Patch Level: Patches may mitigate vulnerabilities without altering version identifiers.
Processor Architecture: Some vulnerabilities are architecture-specific (e.g., Intel x64).
Software Version: Ensures accurate matching with known vulnerabilities.
Authenticated vs. Unauthenticated Scans
Unauthenticated Scans: Limited to information exposed by open services.
Authenticated Scans: Use credentials to access deeper data, such as installed software, running processes, and applied patches.
Interpreting Scan Results
Signature Match Outcomes
True Positive: A detected issue is a real vulnerability.
False Positive: A detected issue is mistakenly flagged as a vulnerability.
True Negative: No vulnerability exists, and none is reported.
False Negative: A vulnerability exists but is not detected.
Note: False negatives are particularly problematic because they leave systems vulnerable without detection.
Risk Ratings Vulnerabilities are evaluated based on their likelihood of occurrence and impact, often using the NIST SP 800-30 framework:
Likelihood of Occurrence: Assesses the probability of exploitation (High, Medium, Low).
Impact: Measures the harm caused by exploitation (High, Medium, Low).
Overall Risk: Combines likelihood and impact to determine the need for mitigation (High, Medium, Low).
Challenges and Considerations
System Load Vulnerability scans consume system resources and bandwidth. Adjusting scanning threads can manage the trade-off between scan speed and system load.
Risk Ratings and False Results
Automated tools often use predefined risk ratings that may not reflect the specific context of an organization.
Manual analysis by a professional is essential for accurate interpretation and prioritization.
Signature Rule Base Scanners rely on signature databases, which vary in accuracy and completeness. Regular updates and use of comprehensive rule sets are critical for reliable results.
Value of Vulnerability Assessments
Initial Foundation for Security: Vulnerability assessments often serve as the starting point for more detailed evaluations, such as compliance audits and penetration tests.
Ongoing Security Monitoring: Mature organizations integrate vulnerability assessments into their regular security routines.
Baseline Metrics: These assessments provide benchmarks for measuring the effectiveness of security improvements over time.
Using Kali Linux for Vulnerability Assessments
Kali Linux is an ideal platform for vulnerability assessments, offering numerous tools in its Information Gathering, Vulnerability Analysis, and Web Application Analysis categories. Resources such as the Kali Linux Tools Listing, official documentation, and training courses (e.g., Metasploit Unleashed) provide further guidance on using these tools effectively.
By conducting well-organized vulnerability assessments and analyzing results accurately, organizations can proactively manage risks and maintain a strong security posture.
12.2.2. Compliance Penetration Test
Compliance-based penetration tests focus on evaluating an organization's adherence to specific security frameworks, often mandated by industry or government regulations. These tests are a step beyond basic vulnerability assessments, incorporating specific compliance criteria to measure the organization's security posture against required standards.
What is a Compliance-Based Penetration Test?
Definition: A structured security assessment designed to verify an organization’s compliance with a predefined framework or standard.
Purpose: Ensure regulatory or contractual obligations are met while identifying and mitigating risks.
Common Frameworks:
PCI DSS: Payment Card Industry Data Security Standard for protecting cardholder data.
DISA STIG: Defense Information Systems Agency Security Technical Implementation Guides for secure system configurations.
FedRAMP: Federal Risk and Authorization Management Program for cloud services.
FISMA: Federal Information Security Management Act for federal IT systems.
These frameworks define specific security requirements, many of which are technical and lend themselves to automated or manual testing.
Compliance Test Workflow
Initiating with a Vulnerability Assessment Compliance-based tests typically begin with a vulnerability assessment to identify basic security gaps. For example, in PCI DSS:
Use password attack tools to address "Requirement 2: Avoid vendor-supplied defaults".
Use database assessment tools to meet "Requirement 11: Regularly test security systems".
Fulfilling Compliance Requirements
Some requirements are purely technical and can be validated using tools (e.g., testing encryption protocols or access controls).
Others, such as physical security or policy compliance, require creative approaches, documentation reviews, and potentially manual testing.
Using Kali Linux
Kali Linux provides a robust, customizable platform with hundreds of pre-installed tools tailored to compliance testing.
Tools are categorized for specific tasks, such as password attacks, database assessments, and vulnerability analysis.
The Debian-based nature of Kali allows for easy installation of additional tools, tailored to the specific compliance framework.
Package Management and Framework-Specific Tools
Searching the Kali package manager with compliance-specific keywords often reveals valuable tools for tasks like configuration audits and security benchmarks.
Example: DISA STIG tools for configuration management.
Why Use Kali Linux for Compliance Tests?
Wide Range of Tools The built-in tools in Kali Linux cover almost every aspect of penetration testing, from vulnerability scanning to network analysis and exploit creation.
Flexibility As an open-source platform, Kali can integrate custom scripts or specialized tools required for niche compliance standards.
Industry Adoption Many organizations adopt Kali Linux as their default assessment platform for compliance checks due to its comprehensive features and customizability.
Challenges and Solutions in Compliance Testing
Framework-Specific Requirements Not all compliance requirements are technical; some may relate to physical security, policy enforcement, or staff training. Solution: Combine technical tools with manual assessments and policy reviews.
Tool-Specific Limitations Some automated tools may not directly align with framework requirements. Solution: Use creative approaches, such as leveraging scripting or custom workflows, to meet specific needs.
Depth vs. Scope Compliance assessments often require striking a balance between depth (thorough testing) and scope (broad coverage of requirements). Solution: Prioritize high-risk areas while maintaining a broad enough focus to meet compliance mandates.
Benefits of Compliance-Based Penetration Tests
Regulatory Assurance Demonstrates adherence to industry or government standards, protecting organizations from legal or financial penalties.
Enhanced Security Posture Beyond compliance, these tests help identify gaps in security that may not be explicitly covered by the framework.
Trust and Accountability Provides clients, partners, and regulators with confidence in the organization’s commitment to security.
12.2.3. Traditional Penetration Test
Overview
Definition Complexity:
The term "Penetration Test" has various interpretations across industries.
Often confused with compliance-based penetration tests or vulnerability assessments that focus on minimum requirements.
Focus of Traditional Penetration Tests:
Designed to improve an organization’s overall security, going beyond minimum compliance.
Objective-driven rather than scope-driven (e.g., simulate internal user compromise or external attack).
Identifies vulnerabilities, validates findings, exploits issues, and uncovers worst-case scenarios.
Key Characteristics
Moves beyond vulnerability scanning tools; relies on manual analysis, creative approaches, and iterative processes.
Explores identified vulnerabilities to assess potential access and leverage for additional attacks.
Phases of a Penetration Test
Information Gathering
Goal: Learn as much as possible about the target environment.
Activities:
Non-invasive actions that mimic standard user behavior.
Forms the foundation for the assessment.
Tools: Found in Kali’s Information Gathering category.
Vulnerability Discovery
Goal: Actively identify potential vulnerabilities through non-standard user actions.
Activities:
Vulnerability scanning.
Active information gathering techniques.
Tools: Found in Vulnerability Analysis, Web Application Analysis, Database Assessment, and Reverse Engineering categories.
Exploitation
Goal: Exploit vulnerabilities to gain a foothold.
Tools: Found in Web Application Analysis, Database Assessment, Password Attacks, and Exploitation Tools categories.
Pivoting and Exfiltration
Goal: Expand access and retrieve sensitive information.
Activities:
Privilege escalation.
System pivoting.
Data exfiltration.
Tools: Found in Password Attacks, Exploitation Tools, Sniffing & Spoofing, and Post Exploitation categories.
Reporting
Goal: Document and communicate assessment activities and findings.
Activities:
Compilation of detailed reports for client review.
Tools: Found in Reporting Tools category.
12.2.4. Application Assessment
Overview
Application assessment focuses narrowly on a single application, unlike broader assessments.
Increasingly common due to the complexity of mission-critical applications, often developed in-house.
Usually conducted in conjunction with a broader assessment, as needed.
Applications Assessed
Web Applications
Common externally-facing attack surface.
Accessible and often targeted; workflow-specific issues may go unnoticed in standard assessments.
Tools: kali-tools-web metapackage.
Compiled Desktop Applications
Includes applications like PDF readers or web-based video programs.
Many mature applications exist, but vulnerabilities still remain in less-reviewed desktop software.
Mobile Applications
Fast-growing attack surface with methodologies evolving rapidly.
Tools for analysis: Reverse Engineering menu in Kali.
Assessment Methods
Automated Tools
Application-specific tools with logic tailored to identify unknown issues, not just known signatures.
Example: Burp Suite for web applications.
Identifies input fields and tests them (e.g., SQL injection attacks).
Interactive Assessments
Black Box Assessment
Assessor/tool uses no special access beyond a standard user’s level.
Mimics external attack scenarios with self-registered accounts or unlogged-in access.
White Box Assessment
Full access to source code, admin privileges, and all functionality.
Comprehensive review but not a simulation of real-world attacks.
Hybrid Approach
Combines aspects of black box and white box methods.
Example: Admin-provisioned user accounts allow deeper exploration without full source code access.
12.3. Formalization of the Assessment
Importance of Formalization
Defines expectations and provides legal authority for the assessment.
Critical step to ensure activities are permitted and do not lead to unintended consequences.
Always consult with the organization’s legal representative for detailed guidance.
Rules of Engagement
Key elements to define before starting:
Systems in Scope
Clearly outline which systems are allowed for interaction.
Avoid interfering with critical business operations.
Timeframes
Specify the time of day and the attack window for conducting the assessment.
Some organizations impose strict timing limitations.
Exploitation of Vulnerabilities
Define whether discovered vulnerabilities can be exploited.
Specify the approval process for exploitation attempts:
Controlled vs. realistic approaches to exploitation.
Handling Significant Issues
Outline the protocol for managing critical discoveries:
Immediate reporting or address at the assessment’s conclusion.
Emergency Contacts
Identify key personnel to contact in case of emergencies or problems.
Awareness and Communication
Define who will know about the activity.
Clarify if the assessment includes testing incident response/detection performance.
Post-Assessment Expectations
Detail the expected deliverables (e.g., reports, presentations).
Ensure all parties agree on results communication.
Authorization and Validation
Authorization
Acquire formal approval from authorized personnel.
Without this, assessment activities may be illegal.
Validation of Scope
Never assume the scope provided is accurate—validate it rigorously:
Confirm systems are owned and operated by the client.
Address potential issues with cloud service providers—obtain special permissions if needed.
Double-check IP address blocks:
Example: Avoid targeting neighbors in shared Class C ranges.
Tools for Validation
Use OSINT tools under the Information Gathering menu in Kali to verify the scope.
Key Takeaways
Formalization ensures a clear understanding of goals, protects against legal issues, and prevents unintended harm.
Always validate the scope to ensure all systems are within bounds and properly authorized.
Good preparation and communication lead to a smoother, more effective assessment process.
12.4. Types of Attacks
During the exploitation phase, various classes of vulnerabilities are targeted, each requiring specific techniques. Kali Linux simplifies this process with a categorized menu system and the Kali tools website, which offers detailed information and usage examples for tools, making it easier to find and utilize the right exploit for the task.
12.4.1. Denial of Service
Overview
Denial of Service (DoS): Exploiting a vulnerability to cause loss of service by crashing a process.
Stress Testing Tools: Available in the Kali Linux menu to identify vulnerabilities susceptible to DoS attacks.
Distinction Between DoS and DDoS
DoS (Denial of Service):
Typically caused by a singular vulnerability exploit or improper use of an exploit.
Often unintentional during professional assessments.
DDoS (Distributed Denial of Service):
Involves resource consumption attacks from multiple sources.
Rarely a part of professional security assessments.
DoS in Professional Assessments
Often occurs due to:
Partially functional or PoC (Proof of Concept) code used in the field.
Properly coded exploits causing DoS in specific scenarios.
Mitigation Challenges:
Avoiding PoC or untested exploits reduces risk but may limit assessment quality.
Always seek legal protection for potential mishaps.
Memory Corruption:
Occurs when a memory location in a process is accidentally modified due to programming errors.
Can lead to unpredictable behavior or allow attackers to control program execution flow.
Often referred to as buffer overflows, but the term does not encompass the full range of memory corruption types.
Common Types of Memory Corruption
Stack Buffer Overflow
Cause: Writing more data to a stack buffer than its allocated space.
Effect: Adjacent memory gets corrupted, often causing program crashes.
Heap Corruption
Cause: Manipulating heap memory pointers to overwrite data in the heap linked list.
Context: Heap memory is allocated during runtime and stores program data.
Integer Overflow
Cause: Creating a numeric value that exceeds the allocated storage size.
Effect: Unintended program behavior or vulnerabilities.
Format String
Cause: Using unchecked user input in a program's formatting functions.
Effect: Memory locations may be:
Revealed (information disclosure).
Overwritten (data corruption or execution control).
Key Considerations
Memory corruption exploits require distinct tactics and techniques depending on the type.
Successful exploitation often enables arbitrary code execution or significant manipulation of program behavior.
Preventative programming practices (e.g., bounds checking, secure coding standards) can reduce memory corruption risks.
12.4.3. Web Vulnerabilities
Complexity of Modern Websites:
Modern websites are dynamic, with pages generated for individual users.
This complexity can lead to vulnerabilities in both back-end logic and the site's presentation layer.
Prevalence of Web Attacks:
Web applications are common attack targets due to widespread use of externally facing services.
Common Web Vulnerabilities
SQL Injection (SQLi)
Cause: Improperly-programmed applications that fail to sanitize user input.
Impact:
Attackers can extract sensitive data from databases.
Potential to take over the entire server.
Cross-Site Scripting (XSS)
Cause: Similar to SQL injection, results from improper sanitization of user input.
Impact:
Attackers can manipulate the site or users, executing malicious code in the context of the user’s browser session.
12.4.4. Password Attacks
Overview
Target: Password attacks focus on the authentication system of a service.
Categories:
Online Password Attacks: Attempt multiple passwords directly against a running system.
Offline Password Attacks: Obtain hashed or encrypted password values and attempt to crack them offline.
Key Aspects of Password Attacks
Online Password Attacks
Directly attempts passwords on a live system.
Offline Password Attacks
Process:
Obtain password hashes or encrypted values.
Work to crack them into clear text.
Challenge: Cracking is computationally expensive, limiting the attacker's attempt rate.
GPU Workarounds
Advantage: Using graphics processing units (GPUs) speeds up the cracking process.
Tools: kali-tools-gpu metapackage includes tools designed to take advantage of GPU power.
Common Password Attack Techniques
Vendor-Supplied Default Passwords
Attackers often target known default passwords supplied by vendors (e.g., "admin" or "password").
Strategy: Scan for these default accounts hoping to exploit a known value.
Custom Dictionary Attacks
Process:
Create a wordlist tailored to the target environment.
Use the list in an online attack against common or known accounts.
Attempt each word in sequence.
Considerations in Password Attack Assessments
Noise
Password attacks can generate a lot of traffic due to repeated authentication attempts, making them noticeable.
Account Lockout
Many systems lock accounts after a certain number of failed login attempts, which could disrupt the attack.
Slow Performance
Password cracking can be slow, particularly when using comprehensive wordlists, making efficient attack execution difficult.
12.4.5. Client-Side Attacks
Overview
Shift in Target: As server-side services have become harder to attack, attackers increasingly target client-side applications on employee workstations within an organization.
Tools: The Social Engineering Tools menu category in Kali Linux offers various applications to assist in executing client-side attacks.
Common Client-Side Attack Methods
Historical Attacks
Early Exploits: Flash, Acrobat Reader, and Java were common targets for client-side attacks in the early 2000s.
Exploitation Method:
Attackers would craft malicious web pages containing code designed to exploit vulnerabilities in these applications.
Visiting these pages would trigger vulnerabilities or social engineering techniques to execute malicious code on the user's system.
Current Exploitation
HTML Application (HTA): The most popular method of client-side attacks today.
Process:
Attackers entice the target to visit a malicious website, which triggers vulnerabilities or tricks the user into executing malicious code.
Challenges and Mitigation
Difficult to Prevent
Client-side attacks are challenging to prevent due to the need for:
User Education: Employees must be educated about the risks of visiting untrusted websites or opening unknown attachments.
Constant Application Updates: Frequent updates are necessary to patch known vulnerabilities in client-side applications.
Network Controls: Proper network controls and security measures can help mitigate the risks but are not foolproof.
User Education
Training users to recognize suspicious activity and avoid unsafe behavior is crucial in defending against client-side attacks.
12.6.1. Information security assessments
Questions
Explain the relationship and difference between a vulnerability and an exploit.
Explain the difference between a false positive and a false negative. Which is more dangerous? Why?
What is an SQL injection?
What is a buffer overflow?
What is a race condition?
What is a file inclusion vulnerability?
Answers:
In terms of information security, a vulnerability is a weakness that can be leveraged to compromise the confidentiality, integrity, or availability of an information system. An exploit is software that has been specially crafted to take advantage of a vulnerability.
A false positive occurs when a vulnerability scan indicates a vulnerability and none exists. A false negative occurs when the scan does not detect a vulnerability and one actually exists. A false negative is more dangerous because a vulnerability has been overlooked.
An SQL injection is a type of vulnerability that occurs when a web application does not properly sanitize user input which allows the potential manipulation of the underlying database.
A buffer overflow is a type of vulnerability that occurs when a programming error allows user input to write to memory beyond the space allocated for it.
A race condition is a type of vulnerability that occurs when, through careful timing, a user could alter a sequence of events to create a vulnerability.
A file inclusion is a type of vulnerability that occurs when a web application allows the user to submit input into files or upload files to a server.
Hacker's Mantra: Hacking is not about breaking things; it’s about building knowledge. -- Richard Stallman
Last updated
Was this helpful?