Advanced Topics: Wireless, Cloud, IoT, Cryptography practice questions

Weaponization

Why it fails: Weaponization involves creating an exploit. Hardcoded credentials are a vulnerability, not an exploit.

Installation

Why it fails: Installation is about deploying malware; hardcoded credentials are a pre-existing vulnerability.

Exploitation

Why it fails: Exploitation involves actively leveraging a vulnerability to achieve a goal. Merely finding the credentials is reconnaissance; using them to access the backend would be exploitation.

SSRF

Why it fails: Server-Side Request Forgery (SSRF) is a vulnerability where an attacker can induce a server-side application to make HTTP requests to an arbitrary domain of the attacker's choosing. This attack primarily targets web applications and their underlying infrastructure, allowing an attacker to access internal systems or external services that the server can reach, but it has no direct applicability as a wireless network attack vector itself.

Dictionary attack

Why it fails: A dictionary attack is a brute-force method of password cracking that attempts to guess passwords by systematically trying words from a pre-compiled list, or "dictionary." While it is a technique used against passwords obtained from wireless networks (e.g., WPA/WPA2 PSK handshakes), it is a generic password cracking methodology, not a specific attack against the wireless network protocol or infrastructure itself.

Replay attack

Why it fails: A replay attack involves an attacker intercepting and re-transmitting valid data transmissions, often authentication credentials or session tokens, to trick a system into performing an action or granting access. While replay attacks can occur in wireless contexts, such as replaying captured authentication frames, they are a broad category of network attack applicable across many protocols and network types (wired, wireless, cellular), not a specific attack unique to wireless network vulnerabilities.

Evil twin attack using a stronger signal

Why it fails: An evil twin attack involves a rogue access point (AP) impersonating a legitimate one, often with the same SSID. While a stronger signal might passively attract new connections in some scenarios, it typically cannot force an already connected client to disconnect from its legitimate AP and reassociate with the rogue AP. Active de-authentication frames are usually required to disrupt existing connections and prompt clients to search for a new, seemingly legitimate network.

WPA2 dictionary attack on the handshake

Why it fails: A WPA2 dictionary attack aims to crack the Pre-Shared Key (PSK) by capturing the four-way handshake and then attempting to guess the passphrase against a list of common words or phrases. This attack method is used for gaining unauthorized access to the network itself by discovering the PSK, allowing a malicious actor to join the legitimate network. It does not involve redirecting client traffic to a fake login page or creating a rogue access point for phishing purposes.

WPS PIN brute-force attack

Why it fails: A WPS PIN brute-force attack exploits a design flaw in Wi-Fi Protected Setup (WPS) to guess the router's 8-digit PIN, which then reveals the WPA2 Pre-Shared Key (PSK). The primary goal of this attack is to gain the actual network passphrase, enabling the attacker to connect to the legitimate Wi-Fi network as an authorized user. This method does not involve setting up a rogue access point or redirecting client traffic to a malicious login portal for credential harvesting.

SQL injection

Why it fails: SQL injection is a code injection technique that exploits vulnerabilities in an application's database layer. Attackers insert malicious SQL statements into input fields, causing the application to execute unintended database commands. This attack primarily targets data integrity, confidentiality, and availability within a database, but it does not involve breaking or analyzing cryptographic primitives or encrypted data to reveal plaintext. Therefore, it is not considered a cryptanalytic attack.

Cross-site scripting (XSS)

Why it fails: Cross-site scripting (XSS) is a client-side code injection attack where malicious scripts are injected into legitimate websites. When a user visits the compromised site, their browser executes the malicious script, which can steal cookies, session tokens, or other sensitive information, or even redirect the user. XSS primarily exploits vulnerabilities in web application input validation and output encoding, targeting user browsers and web application logic, rather than attempting to break or analyze cryptographic algorithms or encrypted data.

Implement strict input validation on all user-supplied URLs

Why it fails: Strict input validation on user-supplied URLs is a crucial defense-in-depth measure, but it is often insufficient as a standalone SSRF mitigation. Attackers can frequently bypass validation rules using techniques like IP address encoding, URL shorteners, or redirect chains, which still trick the server into accessing internal resources. Therefore, while helpful, it does not provide a robust primary defense against sophisticated SSRF attacks.

Disable the use of external URLs in application features

Why it fails: Disabling the use of external URLs in application features is often an impractical and incomplete solution for SSRF prevention. Many modern cloud applications inherently require the ability to fetch or interact with external resources for core functionalities, making a complete disablement infeasible without breaking the application. Furthermore, this approach does not address potential SSRF vectors where the application might internally construct or resolve URLs to sensitive internal resources, even without direct user input for external links.

Use a web application firewall (WAF) with SSRF signatures

Why it fails: While a Web Application Firewall (WAF) with SSRF signatures can provide some protection, it is generally not a comprehensive solution for Server-Side Request Forgery. WAFs primarily inspect incoming requests and rely on known patterns, which may miss novel SSRF payloads or those targeting unique internal IPs like cloud metadata services. Crucially, a WAF typically does not inspect the *outbound* connections made by the server itself, which is where the actual SSRF exploitation occurs, rendering it ineffective against the core attack vector.

Vulnerable software libraries

Why it fails: Vulnerable software libraries pertain to weaknesses within the code components used by an application, often third-party dependencies, which can be exploited to compromise the application itself. This issue is distinct from cloud IAM policies, which govern *who* can access *what* resources within the cloud provider's infrastructure. IAM policies do not control the security posture or vulnerabilities present within the application's codebase or its underlying libraries.

Weak encryption algorithms

Why it fails: Weak encryption algorithms relate to the cryptographic strength used to protect data at rest or in transit, such as using outdated ciphers (e.g., DES, RC4) or insufficient key lengths. Cloud IAM policies define permissions for identities to *perform* actions related to encryption services (e.g., using a Key Management Service key), but they do not dictate the specific algorithms or cryptographic strengths employed. These settings are typically configured at the service level (e.g., S3 bucket encryption, database encryption settings) or within the application itself.

Insecure MQTT configuration

Why it fails: Insecure MQTT configuration refers to vulnerabilities within the Message Queuing Telemetry Transport protocol, primarily used in IoT environments for lightweight messaging between devices and brokers. Issues like unauthenticated access to MQTT brokers, lack of TLS encryption, or improper authorization rules for topics are specific to the MQTT implementation. These security concerns are entirely separate from cloud provider IAM policies, which manage access to cloud services and resources, not the security of an IoT messaging protocol.

RC4

Why it fails: RC4 is classified as a symmetric stream cipher, meaning it encrypts data bit by bit or byte by byte using a single, shared secret key for both encryption and decryption. This fundamental characteristic places it squarely within symmetric cryptography, which requires all communicating parties to possess the identical key, making it unsuitable for scenarios demanding distinct public and private keys.

3DES

Why it fails: Triple Data Encryption Standard (3DES) is a symmetric block cipher that applies the DES algorithm three times to each data block, typically using two or three distinct keys. Despite its iterative application and multiple keys, 3DES remains a symmetric algorithm because the same set of keys used for encryption must also be used for decryption, failing to meet the criteria for asymmetric key pairs.

AES

Why it fails: The Advanced Encryption Standard (AES) is a prevalent symmetric block cipher, processing data in fixed-size blocks (128 bits) using a single, secret key for both encryption and decryption. Its security relies entirely on the secrecy of this shared key, which is a hallmark of symmetric cryptography, thereby classifying it distinctly apart from asymmetric algorithms that employ separate public and private keys.

Perform a dictionary attack against the root user password

Why it fails: Performing a dictionary attack against the root user password is an attempt to compromise the master AWS account credentials directly. This is distinct from exploiting a vulnerability within an EC2 instance to obtain its assigned IAM role credentials. The root user password is not typically stored on or accessible via an EC2 instance's metadata service, making this attack vector irrelevant to the scenario of leveraging an instance vulnerability for IAM role credential theft.

Use Pacu to enumerate S3 buckets

Why it fails: Using Pacu to enumerate S3 buckets is a post-exploitation activity, meaning it occurs after an attacker has already obtained valid AWS credentials. Pacu is a powerful open-source AWS exploitation framework, but its primary function is to leverage existing credentials for reconnaissance, privilege escalation, and data exfiltration. The question specifically asks for the method to obtain the IAM credentials in the first place, not how to utilize them once acquired.

Exploit a container escape vulnerability in Docker

Why it fails: Exploiting a container escape vulnerability in Docker would involve breaking out of a containerized environment to gain access to the underlying host operating system. While a significant security concern in containerized deployments, this attack vector is not directly relevant to obtaining IAM credentials via an EC2 instance's metadata service. The question implies an instance-level vulnerability leading to credential theft, without any specific indication or necessity of Docker containers being present or involved in the immediate path to the IAM role.

3DES

Why it fails: Triple DES (3DES) is a symmetric block cipher, meaning it employs the identical secret key for both encrypting and decrypting data. It operates by applying the Data Encryption Standard (DES) algorithm three times to each data block, enhancing its security compared to single DES. However, its symmetric nature necessitates secure key distribution and management among communicating parties, and it is slower than modern alternatives like AES.

SHA-256

Why it fails: SHA-256 is a cryptographic hash function, not an encryption algorithm, designed to produce a fixed-size output (256 bits) from arbitrary-length input data. Its primary purpose is to ensure data integrity and authenticity by creating a unique digital fingerprint, not to conceal information. Unlike encryption, hashing is a one-way process, making it irreversible and therefore unsuitable for providing confidentiality.

AES

Why it fails: The Advanced Encryption Standard (AES) is a modern, highly efficient symmetric block cipher widely adopted for securing sensitive data. As a symmetric algorithm, it employs the same secret key for both encryption and decryption operations, making secure key management a critical security consideration. AES processes data in fixed-size blocks and offers robust confidentiality, but it does not inherently provide non-repudiation or authentication.

The bucket is in a different region than the EC2 instance

Why it fails: Incorrect. The bucket's region relative to EC2 does not affect public access permissions.

The bucket policy grants 's3:GetObject' and 's3:PutObject' to 'Principal': *

Why it fails: Incorrect. While a bucket policy with Principal: * can grant public access, the actions listed (GetObject, PutObject) do not allow listing the bucket. Listing requires s3:ListBucket.

Server-side encryption is disabled

Why it fails: Incorrect. Disabling server-side encryption does not affect access permissions; it only impacts data protection.

Replay attack

Why it fails: A replay attack targets cryptographic weakness by capturing legitimate, encrypted communication and then retransmitting it later to achieve an unauthorized effect. While the attacker does not need to decrypt the message, the attack exploits the absence of proper freshness mechanisms, such as nonces or timestamps, within the cryptographic protocol. Without these protections, the system cannot distinguish between a legitimate, current message and an identical, replayed message, leading to potential unauthorized actions or state changes.

Cross-site scripting

Why it fails: Cross-site scripting (XSS) is a client-side code injection attack that exploits vulnerabilities in web applications to inject malicious scripts into web pages viewed by other users. This attack primarily targets the end-user's browser and its interaction with the web application, often to steal session cookies, deface websites, or redirect users. XSS does not directly exploit cryptographic algorithms or protocols; instead, it leverages improper input sanitization and output encoding to manipulate client-side content.

SQL injection

Why it fails: SQL injection is a code injection technique that exploits security vulnerabilities in a web application's database layer. Attackers insert malicious SQL code into input fields, which is then executed by the database, allowing unauthorized access, modification, or deletion of data. This attack directly targets the application's database interaction logic and improper input validation, rather than exploiting any cryptographic algorithms, protocols, or their implementations.

Dragonblood downgrade attack forcing the AP to use WPA2-Personal

Why it fails: Dragonblood targets WPA3-Personal's SAE handshake, not WPA3-Enterprise with 192-bit mode. The AKM suite 00-0F-AC:12 indicates GCMP-256 and SHA-384, which are not vulnerable to SAE downgrade. Forcing a transition to WPA2-Personal is not possible because the AP is configured for Enterprise authentication and does not advertise PSK AKMs.

Evil twin attack capturing EAP-TLS certificate exchange for offline cracking

Why it fails: EAP-TLS uses mutual certificate authentication; the client validates the server certificate, so an evil twin without a trusted certificate fails. Capturing the exchange does not allow offline cracking because the TLS tunnel protects credentials and the private key is not exposed. Thus, this attack would not succeed against properly configured EAP-TLS.

KRACK key reinstallation attack against the 4-way handshake

Why it fails: KRACK exploits vulnerabilities in the WPA2 4-way handshake, but WPA3-Enterprise with 192-bit mode uses stronger cryptographic suites and mitigations. The AKM 00-0F-AC:12 indicates the use of GCMP-256, which is not affected by the original KRACK vulnerability. Therefore, this attack is unlikely to succeed.

CoAP resource discovery enumeration using the /.well-known/core resource

Why it fails: Resource discovery is a legitimate feature of CoAP, not an attack. While it can expose available resources, it is not an attack itself. The question asks for attacks, so this is incorrect. Enumeration may be a precursor to an attack, but it is not the attack itself.

CoAP observe option hijacking to intercept notifications

Why it fails: The Observe option allows clients to subscribe to resource updates. Hijacking would require intercepting the DTLS-protected traffic, which is not feasible without breaking DTLS. If DTLS is properly implemented, the observe notifications are encrypted and integrity-protected, making hijacking difficult. Thus, this is not a relevant attack in this scenario.

CoAP amplification attack using the Block-Wise option to cause resource exhaustion

Why it fails: CoAP amplification typically exploits the request/response size difference, but the Block-Wise option is used for large payloads and does not inherently amplify traffic. An attacker could send a small request with a large block size request, but the server's response is limited by the block size. This is not a primary attack vector for CoAP with DTLS.

Client-side encryption with a KMS CMK

Why it fails: Client-side encryption means the data is encrypted before uploading to S3, and the customer manages the keys. While a KMS CMK can be used, automatic rotation is not guaranteed unless configured. This adds complexity and does not provide the simplicity of server-side encryption with automatic rotation.

SSE-S3 with default encryption

Why it fails: SSE-S3 uses S3-managed keys, but it does not provide automatic annual key rotation. The keys are managed by AWS, but rotation is not configurable or automatic. While it encrypts data at rest, it does not meet the requirement for automatic annual rotation of the key.

SSE-C with a customer-provided key

Why it fails: SSE-C requires the customer to provide and manage the encryption key. AWS does not store the key and does not perform automatic rotation. The customer is responsible for rotating the key manually. This does not meet the requirement for automatic annual rotation by AWS.

WPS PIN brute-force attack

Why it fails: A WPS PIN brute-force attack targets the Wi-Fi Protected Setup (WPS) protocol's 8-digit PIN authentication mechanism. This attack exploits a design flaw allowing the PIN to be validated in two halves, significantly reducing the number of attempts needed to guess the correct PIN. It involves systematically trying various PIN combinations, often by sending authentication requests, rather than passively collecting a large number of unique Initialization Vectors (IVs) from network traffic for cryptographic analysis.

Evil twin AP deployment

Why it fails: An evil twin access point (AP) deployment involves setting up a rogue AP that mimics a legitimate one by using the same Service Set Identifier (SSID). The primary objective is to trick unsuspecting users into connecting to the malicious AP, allowing the attacker to intercept their network traffic, capture credentials through phishing, or inject malware. This attack relies on impersonation and user deception, and it does not involve the collection of numerous unique Initialization Vectors (IVs) as a core mechanism for its operation.

WPA handshake capture

Why it fails: WPA/WPA2 cracking primarily focuses on capturing the 4-way handshake that occurs when a client authenticates with an access point. This handshake contains cryptographic material derived from the Pre-Shared Key (PSK) or EAP credentials, which can then be subjected to offline dictionary or brute-force attacks. Unlike WEP, WPA's robust key derivation functions and larger IVs mean that simply collecting a large number of unique Initialization Vectors (IVs) is not a viable method for recovering the WPA key.

Perform a de-authentication attack on the target AP

Why it fails: Reaver is specifically designed to exploit vulnerabilities in Wi-Fi Protected Setup (WPS) by systematically brute-forcing the WPS PIN. It does not perform de-authentication attacks, which are typically executed using tools like aireplay-ng to disconnect clients from an access point. De-authentication attacks are primarily used to force a client to re-authenticate, often to capture a WPA/WPA2 handshake, a function distinct from Reaver's WPS-focused operation.

Capture the 4-way handshake for WPA cracking

Why it fails: Capturing the 4-way handshake, which is essential for offline WPA/WPA2-PSK cracking, is not a function of Reaver. This process typically involves monitoring wireless traffic with tools such as airodump-ng to intercept the exchange between a client and an access point during authentication. Reaver operates by directly interacting with the WPS protocol to guess the PIN, thereby bypassing the need to capture and crack the WPA handshake.

Scan for nearby access points and their BSSIDs

Why it fails: Scanning for nearby access points and their Basic Service Set Identifiers (BSSIDs) is a network discovery function performed by tools like airodump-ng or iwlist scan. Reaver, on the other hand, is an attack tool that requires the target AP's BSSID, along with its associated wireless interface, as input parameters to initiate its WPS brute-force attack. It does not possess built-in capabilities for network reconnaissance or AP enumeration.

AWS is responsible for physical security of data centers

Why it fails: AWS operates under a shared responsibility model where it is indeed responsible for the "security of the cloud," which includes the physical security of its data centers, hardware, and global infrastructure. However, an S3 bucket misconfiguration, such as an overly permissive policy, falls under the customer's "security in the cloud" responsibilities. Therefore, while the statement about AWS's physical security is true, it does not address the root cause of an exposed S3 bucket.

The customer is responsible for patching the S3 service

Why it fails: Under the AWS shared responsibility model, AWS is fully responsible for the operational aspects and underlying infrastructure of managed services like S3, which includes patching the S3 service itself. Customers are not granted access to the underlying S3 service infrastructure to perform patching or maintenance. The customer's responsibility lies in configuring the service correctly, specifically managing access policies and permissions for their S3 buckets and objects.

AWS is responsible for network infrastructure; the customer for data classification

Why it fails: While AWS is indeed responsible for the underlying network infrastructure that supports S3, ensuring its availability and security, this is part of the "security of the cloud." The customer is responsible for data classification, determining the sensitivity of data stored in S3. However, the specific issue of an exposed S3 bucket stems from misconfigured access controls, which is a customer responsibility for "security in the cloud," not directly related to the underlying network or merely classifying the data.

Disable the MQTT broker entirely and switch to HTTP

Why it fails: Disabling the MQTT broker and switching to HTTP is generally impractical for an existing IoT ecosystem, as devices are often purpose-built for MQTT's lightweight publish/subscribe model. This drastic change would require significant re-engineering and redeployment of all IoT devices. Furthermore, merely switching to HTTP without implementing HTTPS and client authentication would simply replace one insecure communication method with another, failing to address the fundamental lack of secure transport and access control that the original problem presents.

Change the default topic names to obfuscated strings

Why it fails: Changing default topic names to obfuscated strings offers no real security benefit, as this approach relies on 'security by obscurity,' which is not a recognized security control. An attacker can easily discover topic names by subscribing to the '#' wildcard, observing network traffic, or reverse-engineering device firmware. This method does not prevent unauthorized access, provide data confidentiality, or offer any form of authentication for the communication, leaving the system vulnerable.

Use a VPN for all IoT device communication

Why it fails: A VPN encrypts traffic between the IoT device and the broker, but the MQTT protocol itself still lacks authentication; the attacker, already on the same local network, can intercept the decrypted traffic after the VPN tunnel terminates at the broker endpoint. This option is tempting because a VPN is correctly used to secure communications across untrusted networks, and it would be the right choice if the threat were an external attacker on a different subnet rather than a local-network eavesdropper.

RC4

Why it fails: RC4 is classified as a symmetric stream cipher, not a block cipher. Unlike block ciphers that process data in fixed-size chunks, RC4 generates a pseudorandom keystream that is XORed with the plaintext, encrypting data bit by bit or byte by byte. This fundamental difference means it does not operate with a fixed block size, making it distinct from algorithms that encrypt discrete blocks of data.

3DES

Why it fails: Triple DES (3DES) is indeed a symmetric block cipher, but it operates on a fixed block size of 64 bits, not 128 bits. While 3DES applies the DES algorithm three times with either two or three distinct 56-bit (effective) keys to enhance security, its underlying data processing unit remains 64 bits. Therefore, it does not meet the criteria for a 128-bit block size often associated with modern symmetric encryption standards.

RSA

Why it fails: RSA (Rivest–Shamir–Adleman) is an asymmetric cryptographic algorithm, also known as public-key cryptography. Unlike symmetric algorithms that use a single shared secret key for both encryption and decryption, RSA employs a pair of mathematically linked keys: a public key for encryption and a private key for decryption. This fundamental distinction immediately disqualifies it as a symmetric algorithm, regardless of its block processing characteristics.

SQL Injection

Why it fails: SQL Injection exploits vulnerabilities in an application's database queries, allowing attackers to inject malicious SQL code through user input. This attack primarily targets the database layer to retrieve, modify, or delete data, or even execute administrative commands. The observed log entry, however, describes an HTTP request to an internal IP address, not a manipulation of a database query.

Container escape

Why it fails: Container escape refers to a security vulnerability where an attacker breaks out of an isolated container environment to gain unauthorized access to the underlying host operating system. While a critical threat, the log entry indicates a network request originating *from* the server or container to an internal service. This action does not directly represent an attempt to compromise the host system itself, but rather leverages the container's network access.

Cross-Site Scripting (XSS)

Why it fails: Cross-Site Scripting (XSS) is a client-side code injection attack where malicious scripts are injected into legitimate websites and executed in the victim's web browser. This vulnerability typically aims to steal session cookies, deface web pages, or redirect users to malicious sites, impacting the end-user directly. The observed log entry, however, details a server-initiated request to an internal IP, which is a server-side action, not a client-side script execution.