Latest Vulnerabilities of 2024- CERT

 CIVN-2024-0139: Multiple Vulnerabilities in Citrix products

 CIVN-2024-0138: Multiple Vulnerabilities in Microsoft Edge
 CIVN-2024-0137: Multiple Vulnerabilities in Cisco
 CIVN-2024-0136: Multiple Vulnerabilities in Google Chrome for
Desktop
 CIVN-2024-0135: Multiple Vulnerabilities in GitLab
 CIVN-2024-0134: Multiple Vulnerabilities in Mozilla products
 CIVN-2024-0133: Multiple Vulnerabilities in IBM WebSphere
Products
 CIVN-2024-0132: Multiple Vulnerabilities in Red Hat JBoss
Enterprise Application Platform
 CIVN-2024-0131: Multiple Vulnerabilities in Atlassian Products
 CIVN-2024-0130: Multiple Vulnerabilities in Zoom Products

Top 10 Vulnerabilities
 A01:2021-Broken Access Control : 94% of applications were
tested for some form of broken access control. The 34 Common
Weakness Enumerations (CWEs) mapped to Broken Access Control
had more occurrences in applications than any other category.
 A02:2021-Cryptographic Failures: previously known as Sensitive
Data Exposure, which was broad symptom rather than a root cause.
The renewed focus here is on failures related to cryptography which
often leads to sensitive data exposure or system compromise.
 A03:2021-Injection: 94% of the applications were tested for some
form of injection, and the 33 CWEs mapped into this category have
the second most occurrences in applications. Cross-site Scripting is
now part of this category in this edition.
 A04:2021-Insecure Design: focus on risks related to design flaws.
If we genuinely want to “move left” as an industry, it calls for more
use of threat modelling, secure design patterns and principles, and
reference architectures.
 A05:2021-Security Misconfiguration: 90% of applications were
tested for some form of misconfiguration. With more shifts into
highly configurable software, it’s not surprising to see this category
move up. The former category for XML External Entities (XXE) is
now part of this category.
 A06:2021-Vulnerable and Outdated Components: This category
moves up from #9 in 2017 and is a known issue that we struggle to
test and assess risk. It is the only category not to have any Common
Vulnerability and Exposures (CVEs) mapped to the included CWEs,
so a default exploit and impact weights of 5.0 are factored into their
scores.
 A07:2021-Identification and Authentication Failures: was
previously Broken Authentication and is sliding down from the
second position, and now includes CWEs that are more related to
identification failures. This category increased availability of
standardized frameworks seems to be helping.
 A08:2021-Software and Data Integrity Failures: focusing on
making assumptions related to software updates, critical data, and
CI/CD pipelines without verifying integrity. One of the highest
weighted impacts from Common Vulnerability and
Exposures/Common Vulnerability Scoring System (CVE/CVSS)
data mapped to the 10 CWEs in this category. Insecure
Deserialization from 2017 is now a part of this larger category.
 A09:2021-Security Logging and Monitoring Failures: was
previously Insufficient Logging & Monitoring and is added from the
industry survey (#3). This category is expanded to include more
types of failures, is challenging to test for, and isn’t well represented
in the CVE/CVSS data. However, failures in this category can
directly impact visibility, incident alerting, and forensics.
 A10:2021-Server-Side Request Forgery: The data shows a
relatively low incidence rate with above average testing coverage,
along with above-average ratings for Exploit and Impact potential.
This category represents the scenario where the security community
members are telling us this is important, even though it’s not
illustrated in the data at this time.

Report vulnerabilities to CERT-In

Security Incident

A computer security incident is any adverse event whereby some aspect of a computer system is
threatened viz. loss of confidentiality, disruption of data or system integrity, denial of service
availability.
Why should you report it to CERT-In

Any organisation or corporate using computer systems and networks may be confronted with security
breaches or computer security incidents. By reporting such computer security incidents to CERT-In
the System Administrators and users will receive technical assistance in resolving these incidents.
Contents of Incident Report
The following information (as much as possible) may be given while reporting the incident.

 Time of occurrence of the incident

 Information regarding affected system/network
 Symptoms observed
 Relevant technical information such as security systems deployed, actions taken to mitigate the
damage etc.

To whom should you report

The following channels may be used to report the incident to CERT-In.

 E-mail : [email protected]
 Helpdesk : +91-1800-11-4949
 Fax : +91-1800-11-6969

Verification by CERT-In

CERT-In will verify the authenticity of the report.

Triage
CERT-In will then analyse the information provided by the reporting authority and identify the
existence of an incident. In case it is found that an incident has occurred, a tracking number will be
assigned to the incident. Accordingly, the report will be acknowledged and the reporting authority will
be informed of the assigned tracking number. CERT-In will designate a team as needed.
Incident Response
The designated team will assist the concerned System Administrator in following broad aspects of
incident handling:

 Identification: to determine whether an incident has occurred, if so analyzing the nature of such
incident, identification and protection of evidence and reporting of the same.
 Containment: to limit the scope of the incident quickly and minimise the damage
 Eradication: to remove the cause of the incident
 Recovery: taking steps to restore normal operation

CERT-In will provide support to the System Administrators in identification, containment, eradication,
and recovery during the incident handling in the form of advice. CERT-In will not physically deploy or
send any member for attending the incident response activity at the site of occurrence. The priority of
assisting in responding to the incidents will be decided by CERT-In keeping in view the severity of
incident and availability of resources.

Vulnerability Reporting
Security vulnerabilities in any product can be sent through mail
at [email protected]. CERT-In accepts PGP encrypted
emails and attachments. Acknowledgement is done within 72
hours.
It expects details like:

- Product(s) affected

- Exact version or model affected

- Vendor details

- Details of vulnerability

- Impact of vulnerability

- How vulnerability wad discovered

- Tools used in discovering

- Other information

CERT gives credit and vendors provide rewards for these

vulnerability reportings.