Security Forem

Cover image for CompTIA SY0-701 2.3 Security+ Study Guide: Understanding Common Vulnerabilities
Andrew Despres
Andrew Despres

Posted on

CompTIA SY0-701 2.3 Security+ Study Guide: Understanding Common Vulnerabilities

This guide synthesizes key attack vectors and security weaknesses, providing the foundational knowledge needed to identify and mitigate threats in modern IT environments.

Core Concepts in Software Vulnerabilities

Software Vulnerabilities

Software is the engine of modern computing, but its complexity creates opportunities for attackers. Understanding how these vulnerabilities are exploited is the first step toward building a robust defense.

Buffer Overflows

A buffer overflow is an attack where an attacker writes more data into a specific area of memory (a "buffer") than it is designed to hold. This excess data "overflows" into adjacent memory areas, potentially overwriting critical instructions or data.

  • How it Works: Application developers are supposed to implement "bounds checking" to ensure that any data written to a buffer does not exceed its allocated size (e.g., ensuring only 8 bytes of data are written to an 8-byte buffer). Attackers actively search for applications that lack proper bounds checking.
  • Real-World Analogy: Imagine you have a glass (the buffer) that can hold exactly 8 ounces of water. A buffer overflow is like trying to pour 9 ounces of water into it. The first 8 ounces fill the glass, but the extra ounce spills out onto the table (adjacent memory), potentially damaging whatever is there.
  • Attacker's Goal: While a clumsy overflow might just crash the application, a skilled attacker aims for a repeatable exploit. They craft the overflowing data precisely to overwrite specific parts of memory, forcing the application to execute a function that benefits them, such as granting elevated privileges.
  • Example in Action:
    1. An application has two variables in memory: variable A (8 bytes, empty) and variable B (2 bytes, value 1979).
    2. Variable B controls user permissions: a value below 2000 grants user rights, while a value over 24,000 grants administrator rights. Variable B cannot normally be modified by a user.
    3. An attacker discovers a vulnerability that allows them to write 9 bytes into the 8-byte variable A.
    4. The attacker inputs the 9-character word "excessive". The first 8 letters (excessiv) fill variable A.
    5. The 9th letter, e (hex value 65), overflows and overwrites the first byte of variable B.
    6. This changes the value of variable B to 25,856, granting the attacker full administrator rights without needing any credentials.

Code Injection

Code injection is a broad category of attack where an attacker inserts their own malicious code into an application's input fields. If the application doesn't properly validate or sanitize the input, it may execute the attacker's code. This can take many forms, including HTML, XML, and SQL injection.

SQL Injection (SQLi)

Structured Query Language (SQL) is the standard language used to communicate with databases. A SQL Injection (SQLi) attack occurs when an attacker injects malicious SQL commands into an application's input, tricking the application into running unintended queries against the database.

  • How it Works: An application might take a username from a search box and build a query like: SELECT * FROM users WHERE name = '[username_input]'. An attacker can manipulate the input to alter this query.
  • Classic Exploit (' OR '1'='1'): By entering Professor' OR '1'='1 into the search box, the attacker changes the query to SELECT * FROM users WHERE name = 'Professor' OR '1'='1'. Since 1 always equals 1, the condition is always true, and the database returns all user records, not just the one for "Professor".
  • Impact: A successful SQLi attack can grant an attacker complete control over a database, allowing them to view, modify, or delete all data, or even crash the database server entirely.

Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) is one of the most common web application vulnerabilities. It allows an attacker to inject malicious scripts (usually JavaScript) into a web page viewed by other users. The attack exploits the trust a user's browser has for a legitimate website. It is abbreviated XSS to avoid confusion with Cascading Style Sheets (CSS).

There are two primary types of XSS attacks:

  1. Non-Persistent (Reflected) XSS:
    • The attacker crafts a malicious link containing a script and sends it to the victim (e.g., via email or text).
    • The victim clicks the link, which directs them to a legitimate but vulnerable website.
    • The website takes the malicious script from the URL and "reflects" it back to the victim's browser, where it executes.
    • The script then steals sensitive information like session cookies and sends it to the attacker, who can use it to hijack the victim's session.
  2. Persistent (Stored) XSS:
    • The attacker posts the malicious script directly onto a website where it gets stored permanently, such as in a social media post, a comment section, or a forum message.
    • Every user who views that page will have the malicious script automatically executed in their browser.
    • This is far more dangerous as it can infect a large number of users without any direct interaction from the attacker beyond the initial post.

Case Study: Subaru Website Vulnerability (June 2017)

Security researcher Aaron Guzman discovered a severe XSS vulnerability in Subaru's website, which compounded another major security flaw:

  • The Flaw: When a user logged in, they received a session token that never expired. This token could be used to perform any service request for the associated vehicle.
  • The Exploit: An attacker could use a reflected XSS attack to send a victim a malicious link. When clicked, the script would steal the victim's non-expiring token and send it to the attacker.
  • The Impact: With this single token, the attacker gained permanent, full control over the victim's vehicle functions via the website. They could even add their email to other accounts, gaining control over multiple vehicles with the same token. Fortunately, Subaru patched these vulnerabilities after being notified.

Protecting Against XSS

  • For Users: Do not click on untrusted links. Manually type trusted domain names into your browser. Keep your browser and applications fully updated.
  • For Developers: Implement strict input validation on all user-input fields to ensure no scripts can be injected.

Memory Injection

For malware to function, it must run in the computer's memory (RAM). Memory injection is a technique where malware injects its code into the memory space of another legitimate, running process.

  • Benefit to Attacker: This allows the malware to hide from antivirus software that might be looking for new or suspicious processes. Furthermore, the malware inherits the same rights and permissions as the legitimate process it has injected itself into, providing a simple method for privilege escalation.

DLL Injection

A common form of memory injection is DLL Injection. A Dynamic-Link Library (DLL) is a type of file in Windows containing code and data that can be used by multiple programs at the same time.

  1. The attacker places a malicious DLL file onto the target system's storage.
  2. The attacker then finds a way to force a running process (the "target process") to load this malicious DLL.
  3. The target process executes the code within the malicious DLL, effectively running the malware with its own permissions.

Race Conditions

A race condition occurs when the outcome of an operation depends on the sequence or timing of two or more uncontrollable events. In security, this often happens when a system checks for a condition and then performs an action, but the state of the condition changes between the check and the action.

Time-of-Check to Time-of-Use (TOCTOU)

This is the classic race condition attack.

  • The "Race": An application checks for a resource's status (Time-of-Check) and then, based on that check, performs an action (Time-of-Use). An attacker aims to change the resource's status after the check but before the use.
  • Real-World Analogy: Imagine a bouncer checks your ID at the door (Time-of-Check). After you're approved, but before you walk in (Time-of-Use), you hand your ID out the window to an underage friend who then uses it to try and enter. The bouncer's check is now invalid.
  • Example: Bank Transfer Flaw:
    1. A banking application immediately updates deposits but has a delay in updating withdrawals.
    2. User 1 and User 2 both want to transfer $50 from Account A to Account B. Both accounts start with $100.
    3. Both users check the balances and see $100 in each.
    4. User 1 adds $50 to Account B. Account B is now $150.
    5. User 2 adds $50 to Account B. Account B is now $200.
    6. User 1 withdraws $50 from Account A. From their view, Account A has $50.
    7. User 2 also withdraws $50 from Account A. Because withdrawals are not immediately updated across the system, the application still thinks Account A has its original $100 before performing the withdrawal. It calculates $100 - $50 = $50.
    8. The Result: Two separate $50 withdrawals were made from Account A, but due to the race condition, the final balance is incorrectly shown as $50 instead of $0.

Zero-Day Vulnerabilities

A zero-day vulnerability is a security flaw in software that is known to attackers but is not yet known to the software vendor or the public.

  • The Timeline:
    1. An attacker or researcher discovers a previously unknown vulnerability.
    2. The attacker develops an exploit to take advantage of it.
    3. Because the vendor is unaware of the flaw, no patch or fix exists.
    4. The attacker launches an attack using this exploit. This is called a zero-day attack because the vendor has had "zero days" to fix the problem.
  • Significance: Zero-day attacks are extremely dangerous because there are no immediate defenses. Until the vendor can identify the vulnerability and release a patch, systems remain exposed.
  • Tracking: The Common Vulnerabilities and Exposures (CVE) database (cve.mitre.org) is a central repository for tracking publicly known security vulnerabilities, including those that were once zero-days.

System-Level Vulnerabilities

System-Level Vulnerabilities

Beyond individual software flaws, vulnerabilities can exist at the level of the operating system, virtualization layer, or even in the hardware itself.

Operating System (OS) Vulnerabilities

The OS is a foundational layer of computing, making it a prime target for attackers.

  • Complexity: Modern operating systems like Windows 11 contain tens of millions of lines of code, creating a vast attack surface where vulnerabilities can hide.
  • Patch Cycle: OS vendors constantly release security patches to fix discovered flaws. Microsoft, for example, releases a large bundle of security updates on the second Tuesday of each month, known as Patch Tuesday. On May 9, 2023, nearly 50 separate vulnerabilities were patched; the previous month saw almost 100 fixes.
  • Best Practices for Patching:
    • Update Promptly: Apply security patches as soon as possible after release to close the window of opportunity for attackers.
    • Test First: In large organizations, test patches in a non-production environment to ensure they don't break critical applications.
    • Have Backups: Always maintain a current, known-good backup. If a patch causes problems, you can revert to the previous state.

Virtualization Vulnerabilities

Virtualization allows multiple operating systems to run on a single physical machine, but this introduces unique security challenges.

  • VM Escape: This is a highly critical vulnerability where an attacker with control of one virtual machine (VM) is able to "escape" the confines of that VM and gain access to the underlying host hypervisor or other VMs on the same host.
    • Example: Pwn2Own 2017: Researchers chained together multiple exploits to achieve a VM escape. They used a JavaScript bug in the Microsoft Edge browser to access the Windows 10 kernel on the guest VM, then exploited a hardware simulation bug in VMware to move from the guest VM to the host.
  • Resource Reuse: A hypervisor manages the allocation of physical resources (like RAM) to multiple VMs. It often over-allocates resources, meaning the total RAM assigned to all VMs exceeds the physical RAM available. If the hypervisor has a bug in its memory management, it's possible for one VM to access a piece of memory that was previously used—but not properly cleared—by another VM, potentially exposing sensitive data.

Misconfiguration Vulnerabilities

Misconfiguration Vulnerabilities

Sometimes the greatest weakness isn't a complex software bug, but a simple mistake in configuration.

Misconfiguration types, descriptions and real-world examples

Mobile Device Vulnerabilities

Mobile Device Vulnerabilities

Mobile devices present a unique challenge due to their portability and constant connectivity.

  • Jailbreaking (iOS) and Rooting (Android): These terms refer to replacing the device's stock operating system with a modified one. This is done to bypass manufacturer restrictions and security controls, but it also disables the security features enforced by Mobile Device Management (MDM) solutions.
  • Sideloading: This is the practice of installing applications from sources other than the official app stores (e.g., Apple App Store, Google Play). Jailbroken or rooted devices can easily sideload apps, which may contain malware and haven't been vetted for security. Corporate Acceptable Use Policies (AUPs) almost always forbid these actions.

Supply Chain & Hardware Vulnerabilities

Supply Chain Vulnerabilities
An organization's security posture doesn't exist in a vacuum. It relies on a complex web of suppliers, vendors, and manufacturers, each of whom represents a potential point of failure.

The Supply Chain

The supply chain encompasses every step from raw materials to the final product delivered to the consumer. A vulnerability can be introduced at any point.

  • Third-Party Service Providers: Outsourcing services like payroll, cloud management, or even office cleaning can introduce risks. If a service provider is breached, attackers can use their legitimate access to pivot into your network.
    • Case Study: The 2013 Target Breach: Attackers stole over 40 million credit card numbers from Target. The initial breach did not target Target directly; it started with a phishing email sent to an HVAC vendor that managed Target's climate control systems. The attackers stole the HVAC vendor's credentials, used them to access Target's network, and found that the HVAC systems were on the same network as the point-of-sale cash registers, allowing them to install malware and harvest card data.
  • Malicious Updates & Software Supply Chain: This is when an attacker compromises the development or distribution process of a legitimate software vendor. They inject malicious code into the software before it is signed and shipped to customers.
    • Case Study: The 2020 SolarWinds Orion Attack: Attackers breached SolarWinds' internal development systems and inserted malicious code into the Orion software platform. This compromised update was then digitally signed by SolarWinds and automatically distributed to 18,000 customers, including Fortune 500 companies and US federal agencies like the Pentagon and Homeland Security. The attackers gained widespread, trusted access to some of the world's most sensitive networks.
  • Counterfeit Hardware: Attackers may sell counterfeit networking equipment (routers, switches) that looks identical to legitimate hardware but contains backdoors or malicious firmware. In 2022, the Department of Homeland Security arrested a reseller who had sold over a billion dollars' worth of counterfeit Cisco products manufactured in China.

Hardware Lifecycle Vulnerabilities

Physical hardware devices have a finite lifespan, and failure to manage it creates security risks.

  • Firmware: The low-level operating system running on hardware devices (like IoT thermostats, routers, etc.) is called firmware. Unlike a PC's OS, users often cannot update it directly and must rely on the manufacturer, who may be slow to release patches. The Trane Comfortlink II thermostat had a known vulnerability for a full year before the manufacturer released a patch.
  • End-of-Life (EOL): This is a notice from a manufacturer that they will stop selling a particular product. Security patches may still be available for a limited time.
  • End-of-Service-Life (EOSL): This is the critical date. After EOSL, the manufacturer will no longer provide any support or security patches for the device. Any device that has reached its EOSL should be replaced immediately, as any new vulnerabilities discovered will remain unpatched forever.
  • Legacy Systems: These are outdated systems that are still in use because they perform a critical business function and cannot be easily replaced. Since they are often past their EOSL, they must be protected with mitigating controls like strict firewall rules and specialized Intrusion Prevention System (IPS) signatures to isolate them from the rest of the network.

The landscape of vulnerabilities is vast and constantly evolving. As we've seen through case studies like Target and SolarWinds, a single weakness—whether in code, configuration, or a trusted relationship—can have catastrophic consequences. The attacker's advantage lies in needing to find just one flaw, while defenders must secure everything. This reality makes a deep understanding of these vulnerabilities not just an academic exercise, but a critical necessity for any security professional.

Top comments (0)