7 Vulnerabilities and Attack Surfaces · Security+

Exam objective 2.4: Explain types of vulnerabilities and attack surfaces.

This objective is about the weaknesses attackers exploit and the places where those weaknesses live. It spans the whole technology estate: products that are unsupported, unpatched, obsolete, or unmanaged; open ports and services; application flaws such as race conditions and malicious updates; insecure code with hardcoded secrets and unsafe exception handling; operating system and virtualization flaws; zero-days; cryptographic weaknesses; stale credentials; rogue devices and shadow IT; wireless and low-powered communications; large language models; identity providers; mobile devices; misconfiguration; and public repositories and object storage.

This is an "explain" objective. You will not be asked to write an exploit, but you must recognize each vulnerability type from a short description, explain why it is dangerous, and connect it to the right mitigation. Expect scenario stems such as "a scan reveals..." or "an auditor discovers..." followed by a request to name the vulnerability or the attack surface it creates.

Vulnerabilities, Exploits, and Attack Surfaces

A vulnerability is a weakness in a system, process, or design that a threat can exploit. An exploit is the technique or code that takes advantage of that weakness. The attack surface is the sum of all points where an unauthorized user could try to enter data, extract data, or influence a system: every listening port, every login page, every API, every employee inbox, every wireless radio, and every third-party integration.

Two ideas drive almost every answer in this chapter:

Reduce the attack surface. Every service, account, device, and integration you do not need is a liability. Removing it eliminates whole classes of vulnerability at once.
Know what you have. Most vulnerabilities in this objective (unmanaged systems, rogue devices, shadow IT, stale credentials, public storage) are failures of visibility. You cannot patch, monitor, or harden what you do not know exists.

Chapter 4 introduced threats and vulnerabilities in general terms, and Chapter 6 covered the vectors attackers use to reach a target. This chapter catalogs where the weaknesses are. Chapter 16 (objective 4.3) covers how to find, prioritize, and remediate them through vulnerability management, and Chapter 14 (objective 4.1) covers mitigating controls.

Vulnerability = the hole. Threat = who or what might use the hole. Exploit = the tool that goes through the hole. Attack surface = the total number of holes and doors. Risk = how likely and how bad it is if someone goes through.

Lifecycle Vulnerabilities: Unsupported, Unpatched, Obsolete, and Unmanaged

Four bullets in this objective describe products that have drifted outside normal maintenance. They overlap, but the exam treats them as distinct, so learn the precise meaning of each.

Unsupported Products

An unsupported product is hardware, software, or firmware for which the vendor no longer provides updates, security patches, or technical support. Vendors publish lifecycle milestones: end of sale (EOS), after which the product cannot be purchased; end of support or end of life (EOL), after which no more fixes are released. Some vendors offer paid extended security updates for a limited period after EOL. Once support ends, every newly discovered vulnerability becomes permanent. Attackers know this and actively target EOL platforms because exploits written for them will keep working indefinitely. Examples include old Windows Server releases, network appliances past their support date, and industrial control software whose vendor has gone out of business.

Unpatched Systems

An unpatched system is one for which a fix exists but has not been applied. This is the most common vulnerability in real breaches: attackers frequently exploit flaws for which patches have been available for months or years. Reasons systems remain unpatched include fear of breaking production applications, lack of maintenance windows, missing asset inventory, devices that require manual firmware updates, and patches that require a reboot nobody schedules.

The difference from an unsupported product is simple: an unpatched system could be fixed today; an unsupported product cannot be fixed by the vendor at all.

Obsolete Systems

An obsolete system is technology that has been superseded and no longer meets current requirements, even if it still runs. Obsolescence is broader than support status. A system may be obsolete because it cannot run modern security agents, cannot support current encryption (for example, it only speaks TLS 1.0 or SMBv1), lacks hardware features such as a TPM or Secure Boot, or depends on components no longer manufactured. Obsolete systems often become legacy systems that persist because a critical business application depends on them.

Unmanaged Systems

An unmanaged system is a device or workload that is not under the organization's management tooling: it is not enrolled in the patch management system, the endpoint detection and response (EDR) console, the mobile device management (MDM) platform, or the configuration management database (CMDB). It may have been built for a test and forgotten, deployed by a business unit, or acquired in a merger. Unmanaged systems miss patches, configuration baselines, and monitoring automatically, which makes them ideal footholds.

Term Core problem Can it be patched? Typical response
Unsupport
ed

Vendor no longer provides fixes No (except paid extended support)

Upgrade, replace, or isolate with compensating controls

Unpatched Fix exists but not applied Yes Patch management, prioritize by risk Obsolete Superseded, cannot meet current requirements

Maybe, but still inadequate

Modernize; plan migration
Unmanage
d

Outside management and monitoring tools

Unknown—nobody is responsible

Discover, inventory, enroll or remove

Exam tip

When the question says the vendor "no longer releases updates," choose unsupported (or end of life). When it says a patch "has been available for six months," choose unpatched. When it says a server "does not appear in the asset inventory or EDR console," choose unmanaged. When none of the patches can solve the problem because the platform cannot support modern protocols, think obsolete or legacy.

Real-world scenario

A manufacturing plant runs a quality-control workstation on an operating system that reached end of life four years ago. The workstation controls a measurement instrument whose vendor driver only works on that OS. Replacing the instrument costs $400,000. The security team cannot patch the workstation, so it removes internet access, places the workstation on an isolated VLAN reachable only from one jump host, disables USB storage, and applies application allow listing. These are compensating controls (Chapter 1) for an unsupported, obsolete system.

Ports and Services

Every listening port represents a service waiting for input from the network, and every service is code that may contain vulnerabilities. Open ports are the classic network attack surface. Common problems include:

Unnecessary services, such as a print spooler on a domain controller, a web management interface on a production database server, or Telnet enabled on a switch.
Insecure (cleartext) protocols that expose credentials and data: Telnet (TCP 23), FTP (TCP 20/21), HTTP (TCP 80), SNMPv1/v2c (UDP 161), POP3 (TCP 110), and IMAP (TCP 143) without TLS. Secure alternatives are SSH (22), SFTP or FTPS, HTTPS (443), SNMPv3, POP3S (995), and IMAPS (993).
Administrative services exposed to the internet, such as RDP (TCP 3389), SSH, SMB (TCP 445), or database ports like MS SQL (1433), MySQL (3306), and PostgreSQL (5432). Internet-exposed RDP and SMB have been leading ransomware entry points for years.
Default or debug services left running after installation, such as sample applications and development consoles.

The fix is service minimization: disable what you do not need, restrict what you do need to specific source networks, and replace cleartext protocols with encrypted equivalents. Port scanning with tools such as Nmap identifies the current surface.

$ nmap -sV 10.20.5.14

Port state service version

21/tcp open ftp vsftpd 2.3.4
22/tcp open ssh OpenSSH 7.2p2
23/tcp open telnet Linux telnetd
80/tcp open http Apache httpd 2.4.18
3306/tcp open mysql MySQL 5.5.62

In this sample, Telnet and FTP send credentials in cleartext, MySQL is reachable from the network rather than only from the local application, and the version strings reveal old software. Each line is an attack surface item.

Common trap

Changing a service to a nonstandard port (for example, SSH on 2222) is security through obscurity. It reduces noise from automated scanners but does not remove the vulnerability. On the exam, it is never the best answer when disabling or restricting the service is an option.

Application Vulnerabilities

Race Conditions: TOC and TOU

A race condition occurs when the outcome of a process depends on the timing or sequence of events, and an attacker can manipulate that timing. The classic security race condition is time-of-check to time-of-use (TOCTOU):

Time of check (TOC) is the moment a program verifies a condition—for example, that a user has permission to write a file, or that an account balance covers a withdrawal.
Time of use (TOU) is the moment the program acts on that verification.

If the condition can change between the check and the use, an attacker can slip in during the gap. Examples:

A privileged program checks that /tmp/report.txt is a regular file the user owns, then opens it for writing. Between the check and the open, the attacker replaces the file with a symbolic link to /etc/passwd, and the privileged program overwrites the system password file.
A banking API checks that an account has $100, then debits it. An attacker sends twenty withdrawal requests at the same instant; all twenty pass the check before any debit is recorded, withdrawing $2,000.
A gift card or coupon is redeemed many times by parallel requests before the "used" flag is set.

Figure 7.1: A TOCTOU race condition, in which an attacker swaps the file between the time of check and the time of use

Mitigations include making check-and-use atomic operations, using locks and database transactions, operating on file handles rather than file names, and designing APIs to be idempotent.

Memory aid

TOCTOU: "Checked it, then used it—but somebody swapped it in between." The vulnerability lives in the gap between TOC and TOU.

Malicious Update

A malicious update is a software update that has been tampered with or replaced so that it delivers malware through the trusted update channel. Because organizations deliberately install vendor updates, often automatically and with high privileges, a compromised update reaches thousands of victims at once. This is a form of supply chain attack (Chapter 6).

Well-known examples include the 2020 SolarWinds Orion compromise, in which attackers inserted a backdoor into the vendor's build process so that signed updates carried it, and the 2017 NotPetya outbreak, which spread through a compromised update to the M.E.Doc accounting software used in Ukraine. Malicious updates may also come from a hijacked update server, a compromised developer account on a package registry, or a man-in-the-middle on an unauthenticated update channel. Defenses include code signing and verification of signatures before installation, hash verification, retrieving updates over authenticated TLS channels, staged rollouts that test updates before broad deployment, monitoring updated software for unusual behavior, and software bills of materials (SBOMs) to know which components you run. Note that code signing alone did not stop SolarWinds, because the malicious code was inserted before signing; build-pipeline integrity matters too.

Code Vulnerabilities

Hardcoded Secrets

A hardcoded secret is a password, API key, private key, database connection string, or token written directly into source code, scripts, configuration files committed to version control, or compiled binaries. Hardcoded secrets are dangerous because:

Anyone with access to the code—or a decompiled binary—can read them.
They are copied wherever the code goes: forks, backups, developer laptops, container images, and public repositories.
They are hard to rotate, because changing them requires a code change and redeployment, so they often stay valid for years.
The same secret is often shared across environments, so a leak from a test system exposes production.

# config.py (committed to Git)
DB_HOST = "prod-db.internal.example.com"
DB_USER = "app_admin"
DB_PASSWORD = "Summer2024!"
AWS_SECRET_ACCESS_KEY = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

The fix is to store secrets in a secrets manager or vault (such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault), inject them at runtime through environment variables or managed identities, and run secrets scanning on repositories (an objective 4.1 control covered in Chapter 14). If a secret was ever committed, assume it is compromised and rotate it—deleting it in a later commit does not remove it from the repository history.

Unsafe Exception Handling

An exception is an error condition that interrupts normal program flow, such as a failed database query, a missing file, or invalid input. Unsafe exception handling occurs when code handles these conditions in a way that weakens security. Two forms matter most:

Information disclosure through verbose errors. An unhandled exception returns a stack trace, SQL query, file path, framework version, or internal hostname to the user. Attackers use these details to map the application and craft precise attacks.
Failing open. When an error occurs inside a security check, the code skips the check and continues. For example, an authorization function throws an exception when the directory server times out, and a catch-all block simply returns true, granting access.

HTTP/1.1 500 Internal Server Error

System.Data.SqlClient.SqlException: Incorrect syntax near 'admin''.

at LoginController.Authenticate(String user, String pass)
Query: SELECT * FROM Users WHERE name='admin'' AND pwd='...'
Server: SQLPROD01 Framework: .NET 4.6.1

This error reveals that user input reaches a SQL query unsanitized, names the database server, and discloses the framework version—everything an attacker needs to start a SQL injection attack. Safe practice is to fail securely (fail closed): deny access when a security check cannot complete, log detailed errors on the server side, and show users a generic message with a correlation ID. Catch specific exceptions rather than swallowing all of them, and never put security decisions inside a catch block that defaults to success.

Exam tip

If a question describes a web page that displays a stack trace, database error, or software version after malformed input, the vulnerability is improper or unsafe error/exception handling, and the fix is generic error messages with server-side logging.

Operating System-Based Vulnerabilities

OS-based vulnerabilities are weaknesses in the operating system itself: the kernel, drivers, system services, default configurations, and built-in utilities. Because the OS mediates everything on the host, an OS flaw can let an attacker escalate from a normal user to SYSTEM or root, bypass security features, or execute code remotely without any user interaction. Examples include:

Kernel and driver vulnerabilities that allow local privilege escalation. Attackers also use "bring your own vulnerable driver" (BYOVD) techniques, loading a legitimately signed but vulnerable driver to gain kernel access and disable EDR.
Remotely exploitable network services, such as the SMBv1 flaw exploited by EternalBlue (MS17- 010), which WannaCry and NotPetya used to spread as worms.
Insecure defaults, such as unnecessary services enabled, permissive file permissions, or weak legacy authentication protocols like NTLMv1 or LM hashes.
Missing hardening, such as disabled host firewalls, local administrator rights for all users, or no Secure Boot.

Mitigations include timely OS patching, hardening against benchmarks such as CIS Benchmarks or DISA STIGs, least privilege for local accounts, host-based firewalls, and EDR. Chapter 14 covers Group Policy and SELinux as OS security controls.

Virtualization Vulnerabilities

Virtualization lets many virtual machines (VMs) share one physical host under a hypervisor. Type 1 (bare-metal) hypervisors such as VMware ESXi, Microsoft Hyper-V, and KVM run directly on hardware; Type 2 (hosted) hypervisors such as VirtualBox run on top of a host OS. Containers share the host kernel rather than running full guest operating systems. Key vulnerabilities include:

VM escape: an attacker in a guest VM exploits a hypervisor flaw to break out and execute code on the host or in other VMs. This is the most serious virtualization vulnerability because it breaks the isolation that multi-tenant computing depends on. Container escape is the equivalent for containers.
Resource reuse: memory, disk blocks, or GPU memory allocated to one VM are reassigned to another without being cleared, potentially exposing the previous tenant's data.
VM sprawl: VMs are so easy to create that organizations accumulate unmanaged, unpatched, forgotten VMs—an unmanaged-system problem in virtual form.
Hypervisor and management-plane compromise: an attacker who controls vCenter, the hypervisor management interface, or the cloud control plane controls every VM beneath it. Ransomware groups have specifically targeted ESXi hosts to encrypt all VMs at once.
Side-channel attacks across VMs that share CPU caches, such as Spectre- and Meltdown-class flaws.
Insecure snapshots and images: VM snapshots capture memory and disk, including secrets, and old templates may contain outdated, vulnerable software.

Mitigations include patching hypervisors promptly, isolating management interfaces on a dedicated network, limiting who can administer the virtualization platform, removing unused VMs, and using hardened, regularly updated golden images.

Figure 7.2: VM escape, in which an attacker in one guest exploits the hypervisor to reach the host and other guests

Common trap

VM escape and VM sprawl sound similar but are very different. VM escape is an attacker breaking out of a guest into the hypervisor. VM sprawl is an administrative failure: too many unmanaged VMs. If the question mentions "accessing other guests" or "the host," it is escape.

Zero-Day Vulnerabilities

A zero-day vulnerability is a flaw that is unknown to the vendor or for which no patch is available, so defenders have had "zero days" to fix it. A zero-day exploit is an attack that uses such a flaw. Once the vendor learns of the vulnerability and releases a fix, it becomes a known (n-day) vulnerability, and unpatched systems then fall into the "unpatched" category discussed earlier.

Figure 7.3: The zero-day window lasts until a patch exists, after which unpatched systems carry a known n-day vulnerability

Zero-days are valuable and expensive, so they are most often used by nation-state actors, advanced persistent threats, and well-funded criminal groups, and they may be sold on exploit markets. Because signature-based tools cannot recognize an exploit no one has seen before, defenses rely on:

Behavior-based and anomaly detection (EDR, XDR, UEBA) that spots what the exploit does rather than what it looks like.
Defense in depth, so that one exploited flaw does not lead to full compromise.
Least privilege, segmentation, and application allow listing, which limit what a successful exploit can reach.
Exploit mitigations built into modern operating systems, such as ASLR, DEP, and control-flow integrity.
Rapid patching once a fix appears, and vendor mitigations or workarounds before it does.

Exam tip

"No patch is available," "previously unknown," or "the vendor is not yet aware" all point to zero-day. The best answer for detecting zero-days is typically behavioral or heuristic analysis, not signature-based antivirus.

Cryptographic Vulnerabilities

Cryptography only protects data when algorithms, implementations, and key management are all sound (Chapter 3 covers objective 1.3 in depth). Cryptographic vulnerabilities include:

Weak or deprecated algorithms: DES and 3DES, RC4, MD5 and SHA-1 for signatures or integrity, and RSA keys shorter than 2048 bits.
Deprecated protocols: SSL 2.0/3.0 and TLS 1.0/1.1, which are vulnerable to attacks such as POODLE and BEAST. Current guidance is TLS 1.2 with strong cipher suites, or TLS 1.3.
Downgrade susceptibility: servers that still accept weak versions or "export-grade" ciphers can be forced into using them (see protocol downgrade in Chapter 8).
Poor key management: keys stored in plaintext next to the data they protect, keys never rotated, private keys shared among servers, or keys embedded in firmware.
Implementation flaws: Heartbleed (CVE-2014-0160) in OpenSSL leaked server memory, including private keys, even though the underlying cryptography was sound.
Weak randomness: predictable random number generators produce guessable keys, nonces, and session IDs.
Improper use: reusing initialization vectors, using ECB mode (which leaks patterns), storing passwords with fast unsalted hashes instead of a salted key-stretching function such as bcrypt, scrypt, PBKDF2, or Argon2.
Certificate problems: expired, self-signed, or mis-issued certificates, and clients that do not validate certificates.
Quantum exposure: data encrypted with RSA or elliptic-curve algorithms today may be harvested now and decrypted later once cryptographically relevant quantum computers exist, which is why migration to post-quantum algorithms is under way.

Unmanaged and Stale Credentials

A stale credential is an account, password, key, or token that remains valid after it is no longer needed: a former employee's account, a contractor's VPN login, an API key for a decommissioned integration, or an SSH key belonging to a departed administrator. An unmanaged credential is one not tracked by identity governance or a privileged access management (PAM) tool: local administrator accounts with the same password on every workstation, service accounts whose passwords never change, and personal access tokens created by developers.

These credentials are attractive to attackers because nobody is watching them. Logins from a dormant account rarely trigger investigation, and there is often no owner to notice misuse. Stale credentials also undermine MFA, because older service accounts and legacy protocols are frequently exempt from it. Mitigations include automated deprovisioning tied to HR events, periodic access reviews and account audits, disabling accounts after a period of inactivity, PAM vaulting and automatic rotation of privileged and service account passwords, unique local administrator passwords (for example, with Microsoft LAPS), short-lived tokens, and group Managed Service Accounts (gMSAs). Chapter 18 (objective 4.5) covers the identity lifecycle.

During an investigation, analysts find that an attacker accessed the file server using the account jsmith-adm. HR records show J. Smith left the company 14 months ago. The account was disabled in the HR system but never removed from Active Directory because the deprovisioning workflow only covered standard accounts, not separate admin accounts. The vulnerability is a stale credential; the root cause is incomplete deprovisioning.

Rogue Devices

A rogue device is any unauthorized hardware connected to the organization's network or environment. Examples include:

A rogue access point plugged into a wall jack by an employee who wanted better Wi-Fi, creating an unsecured bridge from the parking lot into the internal LAN.
An evil twin access point set up by an attacker with the same SSID as the corporate network to lure clients (a wireless attack discussed in Chapter 8).
A small implant such as a Raspberry Pi, a "LAN Turtle," or a malicious USB device hidden behind a printer to give an attacker persistent remote access.
An unauthorized personal laptop, switch, or IoT gadget connected to a corporate port. Rogue devices bypass perimeter controls entirely because they are already inside. Defenses include network access control (NAC) with 802.1X port authentication, disabling unused switch ports, port security (MAC limiting), wireless intrusion prevention systems (WIPS) that detect unauthorized APs, periodic physical and wireless surveys, and comparing discovered devices against the asset inventory.

Shadow IT

Shadow IT is technology—hardware, software, or cloud services—that employees or departments use without the knowledge or approval of the IT and security teams. Common examples are personal file-sharing accounts used to move work files, a marketing team's unapproved SaaS analytics platform, a developer's personal cloud account running a test copy of production data, and unsanctioned generative AI tools into which staff paste confidential documents.

Shadow IT usually arises from good intentions—people trying to get work done faster—but creates serious exposure: data stored outside approved controls and contracts, no security review, no backup, no logging, no offboarding, and possible regulatory violations. It is closely related to unmanaged systems and stale credentials.

Mitigations combine detection and governance: cloud access security brokers (CASBs) and secure web gateways that discover SaaS usage, DLP, firewall and DNS log review, clear acceptable use policies, and —most effectively—a fast, friendly approval process so employees do not feel they need to go around IT.

Note

Shadow IT is not limited to outsiders or attackers. The defining feature is that it is unsanctioned, not that it is malicious. Chapter 5 discusses shadow IT from the threat actor perspective, where the employee is an unintentional insider.

Wireless and Low-Powered Communications

Wireless networks extend the attack surface beyond the building's walls. Key vulnerabilities include:

Weak Wi-Fi security: open networks, WEP (completely broken), WPA with TKIP, and WPA2- Personal with weak passphrases that can be cracked offline from a captured four-way handshake. WPA3 replaces the pre-shared key handshake with Simultaneous Authentication of Equals (SAE), which resists offline dictionary attacks.
Wi-Fi Protected Setup (WPS): the PIN method can be brute-forced quickly and should be disabled.
Evil twins and rogue APs, deauthentication attacks that force clients to reconnect, and jamming that denies service.
Bluetooth: bluejacking (sending unsolicited messages), bluesnarfing (stealing data), and implementation flaws such as BlueBorne that allow remote code execution without pairing.
NFC and RFID: eavesdropping, skimming, and cloning of access badges and contactless cards over short distances.

Low-powered communications are the radio technologies used by IoT devices, sensors, wearables, and industrial equipment: Bluetooth Low Energy (BLE), Zigbee, Z-Wave, LoRaWAN, and cellular IoT standards such as NB-IoT and LTE-M. They matter because:

The devices have limited CPU, memory, and battery, so they often omit strong encryption, authentication, and secure update mechanisms.
Default or hardcoded keys are common, and pairing processes may use weak or no authentication.
Firmware is rarely updated, so vulnerabilities persist for the life of the device.
Many devices are deployed outside managed IT entirely—in building automation, medical devices, and smart offices.

Defenses include segmenting IoT devices onto separate networks, changing default credentials, requiring encrypted protocols and secure pairing, choosing vendors with a firmware update commitment, and monitoring the radio environment.

Large Language Models (LLMs)

Large language models such as those behind chat assistants and coding copilots are now part of the attack surface. When an organization deploys an LLM, or connects one to internal data, tools, and APIs, it inherits new weaknesses: prompt injection (attacker text, typed directly or hidden in a document or web page the model reads, overrides the model's instructions), sensitive information disclosure (the model reveals system prompts, training data, or retrieved internal data), excessive agency (a model connected to email, files, or code execution with broad permissions is manipulated into harmful actions), insecure output handling (model output passed unvalidated to a browser, shell, or database), and supply chain risk from third-party models, plug-ins, and datasets. Employees pasting confidential data into public AI services is also a shadow IT problem.

Treat the LLM as untrusted: apply least privilege to its integrations, validate its outputs as you would any user input, and log its activity. Chapter 9 (objective 2.6) covers AI threats in depth, including the OWASP Top 10 for LLM Applications.

Identity Providers

An identity provider (IdP) authenticates users and issues assertions or tokens that other applications trust. Examples include Microsoft Entra ID, Okta, Ping Identity, Google Workspace, and on-premises Active Directory Federation Services. IdPs power single sign-on (SSO) with SAML, OAuth 2.0, and OpenID Connect (Chapter 18).

IdPs are a high-value attack surface because they concentrate trust: compromise the IdP and you can impersonate any user to every federated application. Vulnerabilities and attack patterns include:

Token and assertion forgery: stealing an IdP signing key or certificate lets attackers mint valid SAML assertions or tokens for any user ("Golden SAML").
Session token theft: stolen session cookies or refresh tokens let attackers bypass MFA entirely, because the authentication already happened.
Misconfigured federation trusts: an attacker who can add a federated domain or a new trusted IdP to a tenant can authenticate as anyone.
Weak administrative protection: IdP admin accounts without phishing-resistant MFA, or help-desk processes that let a caller reset MFA through social engineering.
Over-permissioned OAuth applications: users consent to malicious apps that request broad access to mail and files.
Outages: if the IdP is unavailable, users cannot reach any application that depends on it, so it is also an availability single point of failure.

Mitigations include protecting signing keys in HSMs, phishing-resistant MFA (FIDO2/passkeys) for all administrators, conditional access policies, monitoring for new federation trusts and admin role changes, short token lifetimes, and admin consent workflows for OAuth apps.

Mobile Devices

Smartphones and tablets carry email, MFA authenticators, corporate apps, and sensitive data, and they travel everywhere. Mobile vulnerabilities include:

Jailbreaking (iOS) and rooting (Android): removing the vendor's security restrictions so that unsigned apps can run with elevated privileges and OS protections no longer apply.
Sideloading: installing apps from outside the official app store, bypassing store review. Third-party app stores increase the risk of malicious apps.
Outdated OS versions: many Android devices stop receiving updates after a few years, leaving them permanently vulnerable.
Malicious or over-permissioned apps that request access to contacts, SMS, microphone, or location.
Lost or stolen devices without encryption, screen locks, or remote wipe.
Insecure connections: public Wi-Fi, Bluetooth, and NFC exposure.
Mixing personal and corporate data under BYOD (bring your own device), COPE (corporate-owned, personally enabled), or CYOD (choose your own device) models. Mobile device management (MDM) and mobile application management (MAM) enforce encryption, passcodes, OS versions, jailbreak/root detection, app allow lists, containerization that separates work and personal data, and remote wipe.

Exam tip

Jailbreak is the iOS term; rooting is the Android term. Both mean bypassing the manufacturer's restrictions. Sideloading means installing an app from outside the official store—it does not by itself require jailbreaking on Android.

Misconfiguration

Misconfiguration is a system or service set up insecurely, and it is one of the most common causes of breaches—especially in the cloud. Unlike a software bug, the code works as designed; the settings are wrong. Common misconfigurations include:

Default credentials left unchanged on routers, cameras, databases, and management consoles.
Default configurations with sample applications, debug modes, and directory listing enabled.
Overly permissive access: firewall rules allowing any/any, security groups allowing 0.0.0.0/0 to SSH or RDP, IAM roles with wildcard permissions, file shares granting "Everyone: Full Control."
Disabled security features: logging turned off, encryption at rest not enabled, MFA not enforced, host firewalls disabled.
Unsecured administrative interfaces exposed to the internet.
Configuration drift: systems that were built correctly but changed over time through undocumented manual edits.

# Cloud security group - misconfigured

Inbound rule: TCP 22 Source: 0.0.0.0/0 (SSH open to the entire internet)

Inbound rule: TCP 3389 Source: 0.0.0.0/0 (RDP open to the entire internet)

Inbound rule: ALL Source: 0.0.0.0/0 (all traffic allowed)

Defenses include secure baselines and hardening benchmarks, infrastructure as code (IaC) with reviewed templates, configuration management and desired-state tooling that corrects drift (Chapter 19), cloud security posture management (CSPM), and change management (Chapter 2).

Public Repositories

Public repositories are publicly accessible code and package hosting services: GitHub, GitLab, and Bitbucket for source code, and package registries such as npm, PyPI, RubyGems, NuGet, Maven Central, and Docker Hub. They create two distinct exposures:

1. Data exposure from your own repositories. Developers accidentally make a repository public or push code containing secrets, internal hostnames, or proprietary algorithms. Automated bots scan public commits continuously and can harvest a leaked cloud key within minutes.
2. Supply chain risk from consuming public code. Projects depend on hundreds of open-source packages, any of which may be vulnerable or malicious. Attack techniques include typosquatting (publishing reqeusts to catch typos of requests), dependency confusion (publishing a public package with the same name as an internal one, so the build system fetches the attacker's version), maintainer account takeover, and malicious contributions to legitimate projects (as in the 2024 XZ Utils backdoor).

Mitigations include secrets scanning and push protection, repository visibility policies, software composition analysis (SCA) to identify vulnerable dependencies, pinning dependency versions and verifying hashes, private package mirrors, SBOMs, and reviewing new dependencies before adoption.

Public Object Storage

Object storage services—Amazon S3 buckets, Azure Blob Storage containers, and Google Cloud Storage buckets—store files as objects accessed via HTTP APIs. Public object storage vulnerabilities arise when buckets or individual objects are configured for anonymous public read (or, worse, write) access. Misconfigured buckets have exposed hundreds of millions of records, including voter rolls, medical data, and backups.

Causes include enabling public access for a single file and accidentally applying it to the whole bucket, copying bucket policies from examples, presigned URLs with long lifetimes, and "temporary" public sharing that is never undone. Attackers find exposed buckets with automated tools that guess bucket names. Public write access is especially dangerous: attackers can plant malware in files that websites serve to visitors, or encrypt and ransom the contents.

Defenses include account-level settings that block public access by default (for example, S3 Block Public Access), least-privilege bucket policies, encryption, access logging, CSPM tools that alert on public buckets, and regular reviews. This is a classic shared responsibility issue: the cloud provider secures the storage platform, but the customer is responsible for how it is configured.

Real-world scenario

A security researcher emails a retailer to report that a storage bucket named retailco-backups allows anonymous listing. It contains nightly database exports with customer names and addresses. The bucket was made public two years earlier so a contractor could download one file. The vulnerability is public object storage caused by misconfiguration; the immediate fix is to remove public access and enable account-wide public access blocking, then investigate access logs to determine whether data was downloaded and whether breach notification is required (Chapter 20).

Chapter Summary

The attack surface is every point where an attacker can interact with your environment. Reducing it and keeping an accurate inventory are the two most powerful general defenses.
Unsupported products receive no fixes; unpatched systems have fixes not yet applied; obsolete systems cannot meet current requirements; unmanaged systems sit outside management tooling. Compensating controls protect what cannot be fixed.
Unnecessary, cleartext, and internet-exposed ports and services are a primary network attack surface.
Race conditions exploit the gap between TOC and TOU; malicious updates abuse trusted update channels.
Hardcoded secrets leak with code and resist rotation; unsafe exception handling leaks internals or fails open.
OS-based, virtualization (VM escape, sprawl, resource reuse), zero-day, and cryptographic vulnerabilities each need distinct defenses; zero-days call for behavioral detection and defense in depth.
Stale credentials, rogue devices, and shadow IT are visibility failures; wireless and low-powered technologies extend the surface beyond walls.
LLMs, identity providers, and mobile devices are high-value modern surfaces; misconfiguration, public repositories, and public object storage cause many real-world exposures.

Key Terms

Vulnerability; exploit; attack surface; end of life (EOL); end of sale; unsupported product; unpatched system; obsolete system; legacy system; unmanaged system; service minimization; cleartext protocol; security through obscurity; race condition; time-of-check to time-of-use (TOCTOU); time of check (TOC); time of use (TOU); malicious update; supply chain attack; code signing; hardcoded secret; secrets manager; secrets scanning; unsafe exception handling; fail closed; fail open; OS-based vulnerability; hypervisor; VM escape; resource reuse; VM sprawl; zero-day; n-day; cryptographic vulnerability; stale credential; unmanaged credential; rogue device; rogue access point; shadow IT; cloud access security broker (CASB); low-powered communications; Bluetooth Low Energy; Zigbee; LoRaWAN; large language model (LLM); identity provider (IdP); jailbreaking; rooting; sideloading; misconfiguration; configuration drift; public repository; typosquatting; dependency confusion; public object storage; shared responsibility.

Review Questions

1. A vulnerability scan shows that a file server is missing a critical security update that the vendor released nine months ago. Which vulnerability type BEST describes this finding?

A. Zero-day
B. Unsupported product
C. Unpatched system
D. Obsolete system

2. A developer pushes a configuration file containing a production database password to a public Git repository. She notices within an hour and pushes a new commit that deletes the password. What should the security team do NEXT?

A. Nothing, because the password was removed from the current version
B. Make the repository private
C. Rotate the database password and review database access logs
D. Run a vulnerability scan on the database server

3. An online store discovers that attackers redeemed a single-use discount code more than 300 times by sending simultaneous requests to the checkout API. Which vulnerability did the attackers exploit?

A. Buffer overflow
B. Race condition
C. Unsafe exception handling
D. Hardcoded secret

4. A penetration tester submits a single quote character in a login form and receives a page displaying the SQL query, the database server name, and the .NET framework version. Which vulnerability does this BEST demonstrate?

A. Misconfigured object storage
B. Unsafe exception handling
C. Cryptographic vulnerability
D. Zero-day

5. A cloud provider patches a hypervisor flaw that allowed code running in one customer's virtual machine to break out, execute commands on the underlying host, and access other customers' virtual machines. Which vulnerability was patched?

A. VM sprawl
B. VM escape
C. Resource reuse
D. Rogue device

6. A security analyst finds a small wireless device plugged into an unused network jack behind a printer in the lobby. The device is not in the asset inventory. Which TWO controls would BEST prevent this in the future? (Select TWO.)

A. 802.1X network access control
B. Disabling unused switch ports
C. Code signing
D. Secrets scanning
E. Data masking

7. The marketing department signed up for an online survey platform using a corporate credit card and uploaded the full customer list. IT was not consulted. Which term BEST describes this?

A. Shadow IT
B. Rogue access point
C. Malicious update
D. Unmanaged credential

8. Thousands of organizations were compromised after installing a digitally signed update from a trusted network monitoring software vendor. Investigators found the attackers had modified the vendor's build process. Which vulnerability type is MOST directly involved?

A. Unpatched system
B. Malicious update
C. Zero-day
D. Misconfiguration

9. An organization's audit finds 42 active Active Directory accounts belonging to employees who left more than six months ago. Which control would MOST effectively address the root cause?

A. Enforcing password complexity
B. Automated deprovisioning tied to HR termination events
C. Deploying a WIPS
D. Enabling full-disk encryption

10. Which of the following are examples of cryptographic vulnerabilities? (Select TWO.)

A. A web server that still accepts TLS 1.0 and RC4 cipher suites
B. A switch with Telnet disabled
C. Passwords stored as unsalted MD5 hashes
D. A storage bucket with Block Public Access enabled
E. A VPN using AES-256-GCM

11. An attacker steals the token-signing certificate from a company's federation server and creates valid authentication assertions for any user, accessing multiple cloud applications without passwords or MFA. Which attack surface was compromised?

A. Mobile device
B. Public repository
C. Identity provider
D. Low-powered communications

12. A security team learns that an attacker is exploiting a flaw in a popular VPN appliance. The vendor has acknowledged the issue but has not yet released a patch. Which of the following is the BEST immediate response?

A. Wait for the vendor patch and apply it during the next maintenance window
B. Apply vendor-recommended mitigations, restrict access to the appliance, and increase monitoring for indicators of exploitation
C. Replace signature-based antivirus with a newer version
D. Change the VPN to a nonstandard port

Answers and Explanations

1. C. A fix exists and has been available for months but has not been applied, so the system is unpatched. A zero-day has no patch available. An unsupported product receives no patches from the vendor. An obsolete system is outdated technology, which is not what the finding describes.
2. C. Deleting the secret in a later commit does not remove it from Git history, and public repositories are scraped by bots within minutes. The password must be treated as compromised: rotate it and check access logs for misuse. Making the repository private does not invalidate a secret that may already have been copied, and a vulnerability scan does not address credential exposure.
3. B. Simultaneous requests that all pass the "code not yet used" check before any of them marks the code as used is a classic time-of-check to time-of-use race condition. A buffer overflow writes beyond memory bounds, unsafe exception handling concerns error behavior, and no embedded credential is involved.
4. B. Returning the query, server name, and framework version in an error page is unsafe (improper) exception handling that discloses internal details. It also suggests a SQL injection flaw, but the vulnerability demonstrated by the output itself is the verbose error. None of the other options relate to error output.
5. B. Breaking the isolation between a guest VM and the hypervisor or other guests is VM escape. Resource reuse involves reassigned memory or storage that was not cleared before being given to another tenant, not code breaking out to the host. VM sprawl is an administrative problem of too many unmanaged VMs, and a rogue device is unauthorized hardware.
6. A, B. 802.1X NAC requires devices to authenticate before a switch port grants network access, and disabling unused ports removes the opportunity to plug in at all. Code signing protects software integrity, secrets scanning protects repositories, and data masking hides sensitive values—none prevent unauthorized hardware.
7. A. Technology adopted by a business unit without IT or security approval is shadow IT. A rogue access point is unauthorized wireless hardware, a malicious update is a tampered software update, and an unmanaged credential is an untracked account or key.
8. B. A tampered update delivered through a vendor's trusted, signed channel is a malicious update and a supply chain compromise. The victims were not unpatched—they were installing updates. While the backdoor was unknown when deployed, the defining feature is the abuse of the update mechanism. Misconfiguration does not describe a compromised build process.
9. B. The accounts are stale credentials resulting from incomplete offboarding. Automating deprovisioning when HR records a termination fixes the root cause. Password complexity does not remove accounts, WIPS detects rogue wireless devices, and disk encryption protects data at rest.
10. A, C. Accepting TLS 1.0 and RC4 exposes traffic to known cryptographic attacks, and unsalted MD5 password hashes can be cracked rapidly with precomputed tables and GPUs. Disabling Telnet and blocking public bucket access are good practices, and AES-256-GCM is a strong modern cipher.
11. C. Stealing the token-signing certificate of a federation server (an identity provider) allows forging assertions trusted by every federated application, often called a Golden SAML attack. The other options are unrelated attack surfaces.
12. B. With no patch available, this is effectively a zero-day situation. The best response is to apply vendor mitigations or workarounds, limit exposure (for example, restricting management interfaces and source IPs), and monitor closely for exploitation. Waiting leaves the appliance exposed, antivirus signatures are unlikely to detect a new exploit against a network appliance, and changing the port is security through obscurity.