A0®: Softwaíc

a⭲d Data
I⭲tcgíitQ Ïailuícs
Softwaíc a⭲d data i⭲tcgíitQ failuícs íclaťc ťo codc
a⭲d i⭲ríasťí"cť"íc ťkať docs ⭲oť píoťccť agai⭲sť
i⭲ťcgíiťQ :iolaťio⭲s. A⭲ cxamplc or ťkis is wkcíc a⭲
applicaťio⭲ íclics "po⭲ pl"gi⭲s, libíaíics, oí mod"lcs
ríom "⭲ťí"sťcd so"íccs, ícposiťoíics, a⭲d co⭲tc⭲t
dcli:cíQ ⭲ctwoíks (CDNs). A⭲ i⭲scc"íc CI/CD
(continuous integration and continuous delivery or
deployment) pipcli⭲c ca⭲ i⭲ťíod"cc ťkc poťc⭲ťial roí
"⭲a"ťkoíizcd acccss, malicio"s codc, oí sQsťcm
compíomisc.
 How ťo Píc:c⭲ť
4. Use of software chain security Aids
• Utilizing tools like OWASP CycloneDX or OWASP Dependency-Check helps
security professionals to find out whether or not the application/software
components feature any sort of vulnerabilities.
5. Follow Pipeline Deployment Standard
• The CI/CD pipeline used for software/application development should feature
appropriate segregation, access control, and configuration. This helps in code
flow integrity during the entire development and execution phase.
6. Encrypt and Validate All Data
• It's very crucial to make sure that any unencrypted or unverified data is not
shared with any unauthorized resource. All data, before sharing, must go
through an extensive integrity check or be backed by a digital signature. This
practice helps one to spot any tampering or replay related incidents related to
your data/serial processes.
 EXAMPLES:
When end-user updates happen devoid of signing
• Many applications/software come with auto-update features and don’t
comply with the user-verification process using the digital signing
mechanism. Such unsigned update incidences provide an opportunity for
threat actors to corrupt the targeted system/software. This could be a
serious issue and has no direct fix. The only remedy is to fix the issue in
the future version only.
The incidence of insecure deserialization
• Incidence deserialization occurs when a React application uses Spring Boot
microservices and programmers struggle hard to make sure the code used
remains unalterable. To make this happen, programmers generally
perform user state serialization. If that’s not done correctly, an attacker
can easily
figure out the “r00” Java object signature. Using the Java Serial Killer tool,
the threat actor can perform remote code execution.
Based on the Figure
1.A hacker identifies the agency's insecure CI/CD
pipeline and installs malicious code that gets into
production.
2.Customers unknowingly download malicious code
from the agency's replacement servers.
3.The malicious replacement connects to the
customer's environment and the hacker uses it to gain
access to the customer's network.
A09:2021 – SccuíitQ
Loggi⭲g a⭲d Mo⭲itoíi⭲g
Ïailuícs
Security logging and monitoring
failures are security vulnerabilities
that can occur when a system or
application fails to log or monitor
security events properly. This can
allow attackers to gain unauthorized
access to systems and data without
detection.
Some of the most common security logging and
monitoring failures include:
•Not Logging Important Security Events: This can include
failed login attempts, unauthorized access to sensitive
data, or changes to system configurations.
•Not Monitoring Logs for Suspicious Activity: This can
include repeated failed login attempts, unusual traffic
patterns, or changes to system configurations.
•Not Storing Logs for Long Enough: This can make it
challenging to investigate security incidents that occurred
in the past.
•Not Having a Process for Reviewing and Responding
to Security Logs: This can allow security incidents to go
undetected and unaddressed.
•Insecure Logging and Monitoring Systems: This can
allow attackers to access or modify logs, making
tracking their activities difficult.
Real-Life Example of Security Logging and Monitoring Failures:
2013 Target Data Breach
Attackers gained access to Target's network through a vendor
portal that third-party vendors used to access Target's systems.
Once they had access to the network, the attackers were able to
install malware on Target's point-of-sale (POS) systems to steal
the credit and debit card numbers of customers.
One key contributing factor to the breach was that Target did not
properly log failed login attempts, which allowed the attackers to
try different usernames and passwords until they were
successful. The stores also did not monitor their logs for
suspicious activity, such as repeated failed login attempts from
the same IP address.
How Can You Protect Against Security
Logging and Monitoring Failures?
The key to protecting against security logging and
monitoring failures is to log all critical security events
and monitor them for suspicious activity. Let’s dive into
what that means:

Ensure comprehensive logs are generated, capturing

essential security events, including user authentication,
access control, and data manipulation. This allows for
effective tracking and detection of any malicious
activities.
How Can You Protect Against Security
Logging and Monitoring Failures?
• Securely store and protect log files to ensure their integrity
and confidentiality, including measures to prevent tampering
and unauthorized access, preserving the reliability of the
logged data.
• Implement a process to regularly review and analyze
logs with both automated tools and manual inspection to
detect possible security incidents and emerging threats.
• Set up real-time monitoring and alerting systems to detect
and respond to security events swiftly to lessen the impact
of attacks and prevent potential breaches.
How Can You Protect Against
Security Logging and Monitoring
Failures?
• Create a comprehensive incident response plan that
clearly outlines roles, responsibilities, and procedures
to be followed to ensure a prompt and coordinated
response to security events detected.
• Commit to a path of continuous improvement by
drawing insights from past incidents and evolving
threats, to enhance logging and monitoring practices,
adapting to emerging challenges, and fostering a
proactive security stance.
A10:2021 – Scí:cí
Sidc Rcqucst
ÏoígcíQ
A Server-Side Request Forgery (SSRF) attack
involves an attacker abusing server functionality
to access or modify resources. The attacker
targets an application that supports data imports
from URLs or allows them to read data from
URLs. URLs can be manipulated, either by
replacing them with new ones or by tampering
with URL path traversal.
• Typically, attackers supply a URL (or modify an
existing one) and the code running on the server
reads or submits data to it. Attackers can leverage
URLs to gain access to internal data and services that
were not meant to be exposed – including HTTP-
enabled databases and server configuration data.
• Once an attacker has tampered with the request, the
server receives it and attempts to read data to the
altered URL. Even for services that aren’t exposed
directly on the public internet, attackers can select a
target URL, which enables them to read the data.
Types Of SSRF Attacks
In a server SSRF attack, attackers exploit a process in
which a browser or other client system directly
accesses a URL on the server. The attacker will replace
the original URL with another, typically using the IP
127.0.0.1 or the hostname “localhost”, which point to
the local file system on the server. Under this
hostname the attacker finds a file path that leads to
sensitive data.
How Server SSRF works
•For example, on a weather website, the
web application queries its server for
current weather forecasts to display. It
can do this using a REST API, passing a
URL with an API request from the user’s
browser to the server. The request
might look like this:
This will cause the server to display the
contents of the /admin folder to the
attacker. Because the request is executed
within the server’s file system, it bypasses
ordinary access controls and exposes the
information even though the attacker is
unauthorized.
Back-End SSRF attacks
• Another variant on SSRF is when a server has a
trusted relationship with a back-end component. If,
when the server connects to that component, it has
full access rights, an attacker can forge a request and
gain access to sensitive data, or perform unauthorized
operations. Back-end components often have weak
security because they are considered to be protected
inside the network perimeter.
Continuing the previous example, the attacker could
replace the API call with:
If the server connects to a back-end component on IP
address 192.168.12.5 and is allowed to access the
/admin directory on that component’s file system, the
attacker can similarly gain access and view the content
of the directory.
Mitigating Server-Side Request Forgery
It is common to apply regular expressions and
simple blacklists to user input, in order to
mitigate SSRF and similar attacks. However,
generally speaking, blacklists are an ineffective
method of security control. Attackers can easily
discover ways to get around them. For example, a
cybercriminal may employ a wildcard DNS
service, an HTTP redirect, or an alternate IP
encoding.
WILDCARD DNS SERVICE
A wildcard DNS service is a DNS record that matches requests for non-
existent domain names. It uses the asterisk (*) symbol as part of the
domain name.
e.g. *. example.com. This type of record allows all subdomains to
share the same set of web content with a single DNS entry.
How it works
• When a DNS query is received, the authoritative DNS name
server searches its zone file for matching records
• If no records match, the server returns a response that the
hostname does not exist
• A wildcard record matches requests for non-existent hostnames
Response Handling
To stop response information from reaching the
cybercriminal, you should make sure that the response
that is received conforms to what is anticipated. On no
account should the raw response body received from
the request initiated by the server be transferred to
the client.
Disable Unused URL Schemas
If your application is solely reliant on HTTPS or
HTTP to initiate requests, permit only these URL
schemas. By disabling unused URL schemas, you
deny attackers the ability to utilize the application
to carry out requests via potentially harmful
schemas, including dict://, file:///, and gopher://.
Examplc Aťťack Scc⭲aíios
Aťťackcís ca⭲ "sc SSRI ťo aťťack sQsťcms píoťccťcd bcki⭲d wcb
applicaťio⭲ riícwalls, riícwalls, oí ⭲cťwoík ACḺs, "si⭲g scc⭲aíios s"ck as:
Scc⭲aíio 1: Poíť sca⭲ i⭲ťcí⭲al scí:cís – Ir ťkc ⭲cťwoík aíckiťccť"íc
is "⭲scgmc⭲ťcd, aťťackcís ca⭲ map o"ť i⭲ťcí⭲al ⭲cťwoíks a⭲d
dcťcími⭲c ir poíťs aíc opc⭲ oí closcd o⭲ i⭲ťcí⭲al scí:cís ríom
co⭲⭲ccťio⭲ ícs"lťs oí clapscd ťimc ťo co⭲⭲ccť oí ícjccť SSRI paQload
co⭲⭲ccťio⭲s.
Scc⭲aíio 2: Sc⭲siťi:c daťa cxpos"íc – Aťťackcís ca⭲ acccss local
rilcs oí i⭲ťcí⭲al scí:iccs ťo gai⭲ sc⭲siťi:c i⭲roímaťio⭲ s"ck
as file:///etc/passwd a⭲d http://localhost:28017/.