Full Disclosure mailing list archives

Hello,

Please find a text-only version below sent to security mailing lists.

The complete version on "4 vulnerabilities in ibmsecurity" is posted here:
  https://pierrekim.github.io/blog/2024-11-01-ibmsecurity-4-vulnerabilities.html

The text version is also posted here:
  https://pierrekim.github.io/advisories/2024-ibmsecurity.txt


=== text-version of the advisory  ===

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

## Advisory Information

Title: 4 vulnerabilities in ibmsecurity
Advisory URL: https://pierrekim.github.io/advisories/2024-ibmsecurity.txt
Blog URL: https://pierrekim.github.io/blog/2024-11-01-ibmsecurity-4-vulnerabilities.html
Date published: 2024-11-01
Vendors contacted: IBM
Release mode: Released
CVE: CVE-2024-31871, CVE-2024-31872, CVE-2024-31873, CVE-2024-31874



## Product description

This repository contains Python code to manage IBM Security Appliances using their respective REST APIs. ISAM 
appliance has the most mature code.

From https://github.com/IBM-Security/ibmsecurity

## Vulnerability Summary

Vulnerable versions: ibmsecurity < v2024.4.5.

The summary of the vulnerabilities is as follows:

1. CVE-2024-31871 - Insecure communications 1/2
2. CVE-2024-31872 - Insecure communications 2/2
3. CVE-2024-31873 - Hardcoded passwords
4. CVE-2024-31874 - Uninitialized variables

TL;DR: An attacker located on the network can MITM TLS connections to
IBM Security Verify Access (ISVA) appliances, recover credentials and
compromise the entire IBM Security Verify Access infrastructure. IBM
Security Verify Access is a SSO solution mainly used by banks, Fortune
500 companies and governmental entities.

_Miscellaneous notes_:

The vulnerabilities were found in February 2023 and were communicated
to IBM in March 2023. They ultimately were patched in April 2024
(after 13 months).

Communication with IBM was difficult. At first, IBM support had
confirmed that they would patch the vulnerabilities found in the
ibmsecurity library. Then, in April 2024, IBM advised that the only
way to get security patches is to go Full-disclosure and open a github
issue containing all technical details. Although this was unusual, I
created a github issue, which was subsequently redacted by IBM -
https://github.com/IBM-Security/ibmsecurity/issues/416.

_Impacts_

An attacker can compromise the entire authentication infrastructure
based on IBM Security Verify Access by intercepting admin credentials
on the network.

_Recommendations_

- - Apply security patches.
- - Enable certificate validation (not enabled by default).



## Details - Insecure communications 1/2

The ibmsecurity package has been partially audited as it provides the
underlying Python APIs used to communicate with IBM Security Verify
Access (ISVA).

Unfortunately, the security of the ibmsecurity package is very poor
and, by default, all the SSL/TLS connections to the remote ISVA server
are configured in an insecure way.

The latest version of the ibmsecurity library
(`ibmsecurity-2022.8.22.0`) has been downloaded using pip in order for
the source code to be reviewed:

    kali% pip download ibmsecurity
    Collecting ibmsecurity
    Using cached ibmsecurity-2022.8.22.0-py3-none-any.whl (391 kB)
    Collecting requests
    Using cached requests-2.28.1-py3-none-any.whl (62 kB)
    Collecting charset-normalizer<3,>=2
    Using cached charset_normalizer-2.1.1-py3-none-any.whl (39 kB)
    Collecting urllib3<1.27,>=1.21.1
    Using cached urllib3-1.26.12-py2.py3-none-any.whl (140 kB)
    Collecting certifi>=2017.4.17
    Using cached certifi-2022.9.24-py3-none-any.whl (161 kB)
    Collecting idna<4,>=2.5
    Using cached idna-3.4-py3-none-any.whl (61 kB)
    Saved ./ibmsecurity-2022.8.22.0-py3-none-any.whl
    Saved ./requests-2.28.1-py3-none-any.whl
    Saved ./certifi-2022.9.24-py3-none-any.whl
    Saved ./charset_normalizer-2.1.1-py3-none-any.whl
    Saved ./idna-3.4-py3-none-any.whl
    Saved ./urllib3-1.26.12-py2.py3-none-any.whl
    Successfully downloaded ibmsecurity requests certifi
charset-normalizer idna urllib3
    kali%

The `invoke_*` functions in the ibmsecurity library will use by
default the `_suppress_ssl_warning()` method that will remove any
security related to SSL/TLS.

For example, the method `invoke_put()` is defined in the file
`ibmsecurity/appliance/isamappliance.py`, as shown below on line 402:

Content of `ibmsecurity/appliance/isamappliance.py`:

[code:python]
...
  3 from requests.packages.urllib3.exceptions import InsecureRequestWarning
...
 17 class ISAMAppliance(IBMAppliance):
...
 45     def _suppress_ssl_warning(self):
 46         # Disable https warning because of non-standard certs on appliance
 47         try:
 48             self.logger.debug("Suppressing SSL Warnings.")
 49
requests.packages.urllib3.disable_warnings(InsecureRequestWarning) #
[1] <- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
 50         except AttributeError:
 51             self.logger.warning("load
requests.packages.urllib3.disable_warnings() failed")
...
402     def invoke_put(self, description, uri, data,
ignore_error=False, requires_modules=None, requires_version=None,
403                    warnings=[], requires_model=None):
404         """
405         Send a PUT request to the LMI.
406         """
407
408         self._log_request("PUT", uri, description)
409         response = self._invoke_request(self.session.put, description, uri,
410                                         ignore_error, data,
411
requires_modules=requires_modules, requires_version=requires_version,
412
requires_model=requires_model, warnings=warnings)
413         return response
...
[/code]

The method `_invoke_request()` called on line 409 inside the
`invoke_put()` method will disable any SSL/TLS security on line 334 by
calling the method `_suppress_ssl_warning()` previously defined on
line 45:

Content of `ibmsecurity/appliance/isamappliance.py`:

[code:python]
...
305     def _invoke_request(self, func, description, uri,
ignore_error, data={}, requires_modules=None,
306                         requires_version=None, warnings=[],
requires_model=None):
307         """
308         Send a request to the LMI.  This function is private and
should not be
309         used directly.  The invoke_get/invoke_put/etc functions
should be used instead.
310         """
...
334         self._suppress_ssl_warning() # <- insecure SSL/TLS
connection to the remote ISVA instance
...
336         try:
337             if func == self.session.get or func == self.session.delete:
338
339                 if data != {}:
340                     r = func(url=self._url(uri), data=json_data,
verify=False, headers=headers)
341                 else:
342                     r = func(url=self._url(uri), verify=False,
headers=headers)
343             else:
344                 r = func(url=self._url(uri), data=json_data,
345                          verify=False, headers=headers)
346
347             if func != self.session.get:
348                 return_obj['changed'] = True  # Anything but GET
should result in change
349
350             self._process_response(return_obj=return_obj,
http_response=r, ignore_error=ignore_error)
...
[/code]

Execution flow: The `invoke_put()` method is defined on the line 402
of the `ibmsecurity/appliance/isamappliance.py` file. This method will
then use the `_invoke_request()` method, defined on line 305. This
`_invoke_request()` method will call the `suppress_ssl_warning()`
method on line 334. The `suppress_ssl_warning()` method is defined on
line 45: any security related to SSL/TLS will be then removed.

These methods defined in `ibmsecurity/appliance/isamappliance.py` are insecure:

- - invoke_post_files (line 148)
- - invoke_put_files (line 203)
- - invoke_get_file (line 246)
- - _invoke_request (line 305)
- - _invoke_request_with_headers (line 355)
- - invoke_post_snapshot_id (line 427)
- - invoke_request (line 516)

These methods defined in `ibmsecurity/appliance/isdsappliance.py` are
also insecure:

- - invoke_post_files (line 135)
- - invoke_put_files (line 184)
- - invoke_get_file (line 228)
- - _invoke_request (line 288)

In the `ibmsecurity/appliance/isdsappliance.py` Python file, we can
find again the same `suppress_ssl_warning()` method which is also used
by other methods (e.g. `invoke_post_files()` as shown below):

[code:python]
  3 from requests.packages.urllib3.exceptions import InsecureRequestWarning
...
 17 class ISDSAppliance(IBMAppliance):
...
 39     def _suppress_ssl_warning(self):
 40         # Disable https warning because of non-standard certs on appliance
 41         try:
 42             self.logger.debug("Suppressing SSL Warnings.")
 43
requests.packages.urllib3.disable_warnings(InsecureRequestWarning)
 44         except AttributeError:
 45             self.logger.warning("load
requests.packages.urllib3.disable_warnings() failed")
...
135     def invoke_post_files(self, description, uri, fileinfo, data,
ignore_error=False, requires_modules=None,
136                           requires_version=None, warnings=[],
json_response=True):
...
166         self._suppress_ssl_warning()
167
168         try:
169             r = requests.post(url=self._url(uri=uri), data=data,
auth=(self.user.username, self.user.password),
170                               files=files, verify=False, headers=headers)
171             return_obj['changed'] = True  # POST of file would be a change
172             self._process_response(return_obj=return_obj,
http_response=r, ignore_error=ignore_error)
...
[/code]

These methods are used everywhere in the ibmsecurity library to
communicate with the remote ISVA infrastructure. 1162 calls to
insecure methods have been identified:

    kali% rgrep invoke_ ibmsecurity
    ibmsecurity/isds/server.py: return
isdsAppliance.invoke_get("Retrieving Server Status",
"/widgets/server")
    ibmsecurity/isds/server.py: return
isdsAppliance.invoke_post("Restarting the service " + serverID,
    ibmsecurity/isds/server.py: return
isdsAppliance.invoke_post("Restarting the service " + serverID,
    ibmsecurity/isds/server.py: return
isdsAppliance.invoke_post("Restarting the service " + serverID,
    ibmsecurity/isds/server.py: return
isdsAppliance.invoke_post("Restarting the service " + serverID,
    ibmsecurity/isds/available_updates.py: return
isdsAppliance.invoke_get("Retrieving available updates",
    ibmsecurity/isds/available_updates.py: return
isdsAppliance.invoke_get("Discover available updates",
    ibmsecurity/isds/available_updates.py: return
isdsAppliance.invoke_post_files(
    ibmsecurity/isds/available_updates.py: ret_obj =
isdsAppliance.invoke_post("Install Available Update",
    ibmsecurity/isds/fixpack.py: return
isdsAppliance.invoke_get("Retrieving fixpacks",
    ibmsecurity/isds/fixpack.py: return isdsAppliance.invoke_post_files(
    [...]
    kali% rgrep invoke_ ibmsecurity | wc -l
    1162
    kali%

The ibmsecurity Python library massively uses insecure methods to
communicate with the remote ISVA infrastructure, with 1162 calls to
insecure functions.



## Details - Insecure communications 2/2

The ibmsecurity package has been partially audited as it provides the
underlying Python APIs used to communicate with IBM Security Verify
Access (ISVA).

Unfortunately, the security of the ibmsecurity package is very poor,
and, by default, all the SSL/TLS connections to the remote ISVA server
are insecure due to the insecure option (`Verify=false`) used with the
methods provided by the `requests` module (to send HTTPS requests to
the remote ISVA infrastructure).

For example, the method `invoke_post_snapshot_id()` will use
`Verify=false` in the HTTPS request on line 455 to disable any
verification of the remote SSL certificate (in addition to the
previous insecure `_suppress_ssl_warning()` method found in Insecure
communications 1/2).

Content of `ibmsecurity/appliance/isamappliance.py`:
[code:python]
429     def invoke_post_snapshot_id(self, description, uri, data,
ignore_error=False, requires_modules=None,
430                                 requires_version=None,
warnings=[], requires_model=None):
431         """
432         Send a POST request to the LMI.  Snapshot id is part of the uri.
433         Requires different headers to normal post.
434         """
...
452         self._suppress_ssl_warning()
453
454         try:
# VVVVVVVVVVVV
455             r = self.session.post(url=self._url(uri=uri),
data=data, verify=False, headers=headers)
456             return_obj['changed'] = False  # POST of snapshot id
would not be a change
457             self._process_response(return_obj=return_obj,
http_response=r, ignore_error=ignore_error)
...
[/code]

Similar vulnerabilities can be found everywhere in the Python sources.

For example, in the method `invoke_request()` inside
`ibmsecurity/appliance/isamappliance.py` and `invoke_get_file()`
inside `ibmsecurity/appliance/isdsappliance.py`:

Content of `ibmsecurity/appliance/isamappliance.py` (line 555):

[code:python]
...
518     def invoke_request(self, description, method, uri,
filename=None, ignore_error=False, requires_modules=None,
519                        requires_version=None,
520                        warnings=[], requires_model=None, **kwargs):
...
551         self._suppress_ssl_warning()
...
555             r = self.session.request(method, url=self._url(uri),
verify=False, **args)
[/code]

Content of `ibmsecurity/appliance/isdsappliance.py` (line 254):

[code:python]
...
228     def invoke_get_file(self, description, uri, filename,
no_headers=False, ignore_error=False, requires_modules=None,
229                         requires_version=None, warnings=[]):
230         """
231         Invoke a GET request and download the response data to a file
232         """
...
251         self._suppress_ssl_warning()
252
253         try:
254             r = requests.get(url=self._url(uri=uri),
auth=(self.user.username, self.user.password), verify=False,
255                              stream=True, headers=headers)
[/code]

Vulnerable functions identified in `ibmsecurity/appliance/isdsappliance.py`:

- - invoke_post_files vulnerability present on line 170;
- - invoke_put_files vulnerability present on line 214;
- - invoke_get_file vulnerability present on line 254;
- - _invoke_request vulnerabilities present on lines 322, 325 and 329;

Vulnerable functions identified in `ibmsecurity/appliance/isamappliance.py`:

- - invoke_post_files vulnerabilities present on lines 187 and 189;
- - invoke_put_files vulnerability present on line 232;
- - invoke_get_file vulnerability present on line 272;
- - _invoke_request vulnerabilities present on lines 338, 340 and 343;
- - _invoke_request_with_headers vulnerabilities present on lines 383,
385 and 388;
- - invoke_post_snapshot_id vulnerability present on line 453;
- - invoke_request vulnerability present on line 553.

The vulnerable library can also be found in Github
(https://github.com/IBM-Security/ibmsecurity/blob/master/ibmsecurity/appliance/isamappliance.py#L187):

[code:python]
        try:
            if data_as_files is False:
                r = self.session.post(url=self._url(uri=uri),
data=data, files=files, verify=False, headers=headers)
            else:
                r = self.session.post(url=self._url(uri=uri),
files=files, verify=False, headers=headers)
[/code]

The ibmsecurity Python library massively uses insecure methods to
communicate with the remote ISVA infrastructure, with 1162 calls to
insecure functions.



## Details - Hardcoded passwords

It was observed that the ibmsecurity library contains hardcoded users
and passwords:

Content of `ibmsecurity/isam/web/reverse_proxy/federation_configuration.py`:

[code:python]
...
7 def config(isamAppliance, instance_id, federation_id=None,
federation_name=None, hostname='127.0.0.1',
  port='443', username='easuser',
8 password='passw0rd', reuse_certs=False, reuse_acls=False,
check_mode=False, force=False):
...
[/code]

Similar vulnerabilities can be found in the source codes.

For example, in the method `invoke_request()` inside
`ibmsecurity/appliance/isamappliance.py` and `invoke_get_file()`
inside `ibmsecurity/appliance/isdsappliance.py`, we can find hardcoded
credentials:

Content of `ibmsecurity/isam/web/reverse_proxy/oauth_configuration.py`:

[code:python]
...
10 def config(isamAppliance, instance_id, hostname='127.0.0.1',
port=443, username='easuser', password='passw0rd',
11 junction="/mga", reuse_certs=False, reuse_acls=False, api=False,
browser=False, auth_register=None, fapi_compliant=None,
12 check_mode=False, force=False):
...
[/code]

Content of `ibmsecurity/isam/web/reverse_proxy/aac_configuration.py`:
[code:python]
...
9 def config(isamAppliance, instance_id, hostname='127.0.0.1',
port=443, username='easuser', password='passw0rd',
10 junction="/mga", reuse_certs=False, reuse_acls=False,
check_mode=False, force=False):
...
[/code]

Attacker can use hardcoded passwords to compromise installations.



## Details - Uninitialized variables

It was observed that the ibmsecurity library uses variables before
they are initialized in:

- - ibmsecurity/isam/aac/attribute_matchers.py
- - ibmsecurity/isam/aac/risk_profiles.py

The `json_data` variable is used on line 106 but is only defined on line 108:


Content of `ibmsecurity/isam/aac/attribute_matchers.py`:

[code:python]
...
 98 def _check(isamAppliance, description, properties):
 99     """
100     Check and return True if update needed
101     """
102     update_required = False
103     ret_obj = get(isamAppliance, description)
104     if ret_obj['data'] == {}:
105         logger.warning("Attribute Matcher not found, returning no
update required.")
106         return None, update_required, json_data
107     else:
108         json_data = {
109             "properties": properties,
110             "predefined": ret_obj['data']['predefined'],
111             "supportedDatatype": ret_obj['data']['supportedDatatype'],
112             "uri": ret_obj['data']['uri']
113         }
...
[/code]


Content of `ibmsecurity/isam/aac/risk_profiles.py`:

[code:python]
...
152 def _check(isamAppliance, name, active, description, attributes,
predefined):
153     """
154     Check and return True if update needed
155     """
156     update_required = False
157     ret_obj = get(isamAppliance, name)
158     if ret_obj['data'] == {}:
159         logger.warning("Risk Profile not found, returning no
update required.")
160         return None, update_required, json_data
161     else:
162         if ret_obj['data']['predefined'] is True:
163             logger.warning("Predefined Risk Profiles can NOT be
updated, returning no update required.")
164             return ret_obj['data']['id'], update_required, {}
165         else:
166             json_data = {
167                 "name": name,
168                 "active": active,
169                 "predefined": predefined
170             }
171             if attributes is not None:
172                 json_data['attributes'] = attributes
...
[/code]

The Python code can crash.



## Vendor Response

IBM provided a security bulletin:

Security Bulletin: Multiple Security Vulnerabilities were found in
Open Source libraries used to deploy IBM Security Verify Access
Appliances (CVE-2024-31871, CVE-2024-31872, CVE-2024-31873,
CVE-2024-31874) - https://www.ibm.com/support/pages/node/7147932:

- - CVE-2024-31871: IBM Security Verify Access Appliance could allow a
malicious actor to conduct a man in the middle attack when deploying
Python scripts due to improper certificate validation.
- - CVE-2024-31872: IBM Security Verify Access Appliance could allow a
malicious actor to conduct a man in the middle attack when deploying
Open Source scripts due to missing certificate validation.
- - CVE-2024-31873: IBM Security Verify Access Appliance contains
hard-coded credentials which it uses for its own inbound
authentication that could be obtained by a malicious actor.
- - CVE-2024-31874: IBM Security Verify Access Appliance uses
uninitialized variables when deploying that could allow a local user
to cause a denial of service.



## Report Timeline

This security assessment was reported to IBM along with the security
assessment of IBM Security Verify Access. Please find the complete
timeline below:

* October 2022: Security assessment performed on IBM Security Verify Access.
* Feb 12, 2023: A complete report was sent to IBM.
* Feb 13, 2023: IBM acknowledged the reception of the security
assessment and said that scan tools usually report a lot of issues so
I have to check the status of detected CVEs by browsing RedHat
webpages and create an issue for each CVE.
* Feb 13, 2023: Replied to IBM saying that the security assessment was
not done using a scanner.
* Feb 14, 2023: Asked for an update.
* Feb 14, 2023: IBM confirmed that the report was shared with L3 and
"IBM hacking team".
* Feb 22, 2023: IBM said they were still assessing the report.
* Mar 13, 2023: An additional report on ibmsecurity was sent to IBM.
* Mar 13, 2023: IBM confirmed that the second report was shared with L3 team.
* Mar 15, 2023: IBM wanted to organize a meeting about the findings.
* Mar 15, 2023: I replied that I would like to have a written feedback
for each reported vulnerability in order to have constructive
discussion.
* Apr 4, 2023: I asked again IBM to confirm the vulnerabilities
* Apr 5, 2023: IBM shared the analysis (VulnerabilityResponse.xlsx),
confirming several vulnerabilities.
* Apr 11, 2023: I provided my comments
(VulnerabilityResponse-comments-Pierre.xlsx) and asked to organize a
meeting.
* Apr 11, 2023: IBM confirmed a meeting is possible.
* Apr 18, 2023: I asked to organize a meeting on Apr 19, 2023.
* Apr 18, 2023: IBM confirmed a meeting is possible.
* Apr 19, 2023: I asked to have a meeting where every party (dev team,
support and myself) can be present.
* Apr 19, 2023: IBM confirmed a meeting would take place on Apr 20, 2023.
* Apr 20, 2023: Meeting with IBM regarding ISVA. IBM confirmed they
would recheck some of the issues and would provide CVEs for the
vulnerabilities.
* Apr 23, 2023: I asked to have a second meeting about ibmsecurity.
* Apr 23, 2023: IBM confirmed they will organize a meeting on ibmsecurity.
* Apr 24, 2023: I asked the timeline to get security patches.
* Apr 24, 2023: IBM confirmed there are no ETA to get security patches.
* Apr 27, 2023: Meeting with IBM regarding ibmsecurity. IBM confirmed
they will fix all the issues.
* May 10, 2023: I asked for CVE identifiers to track the vulnerabilities.
* May 11, 2023: IBM said that PSIRT records have been opened and the
scoring is in progress.
* May 15, 2023: I reached IBM because I found a CVE (CVE-2023-25927)
and a security bulletin likely corresponding to a vulnerability I
reported, thanks to @CVEnew on Twitter:
https://www.ibm.com/support/pages/node/6989653. I asked if this was
one of the reported vulnerabilities.
* Jul 7, 2023: IBM said the dev team was still working on the final
list of issues and that everything would be fixed in the 10.0.7
release.
* Jul 10, 2023: I asked when the 10.0.7 release would be available. I
asked again more details about the previous advisory.
* Jul 11, 2023: IBM said that the 10.0.7 release would be published on
Dec 23, 2023. Regarding the CVEs, IBM replied they would need to
discuss with the dev team.
* Jul 12, 2023: I asked IBM to confirm if CVE-2023-25927 was one of
the reported vulnerabilities.
* Jul 12, 2023: IBM said that they do not credit security researchers.
* Jul 13, 2023: I provided several IBM security bulletins where
security researchers were credited, e.g.
https://www.ibm.com/support/pages/security-bulletin-vulnerabilities-exist-ibm-data-risk-manager-cve-2020-4427-cve-2020-4428-cve-2020-4429-and-cve-2020-4430.
* Jul 14, 2023: IBM confirmed that they would forward the information
to L3 team and asked what I would want to do with this case.
* Jul 14, 2023: I said that (1) I was still waiting for information
about CVE-2023-25927, (2) I did not have any information regarding
security patches for ibmsecurity and (3) I asked IBM to provide me
with the final list of vulnerabilities that would be patched in the
10.0.7. Since the list of confirmed vulnerabilities was quite long, I
wanted to confirm that nothing was missed.
* Jul 28, 2023: IBM said that they did not know if CVE-2023-25927 is
one of the reported vulnerabilities and in any case, it is impossible
to edit the security bulletin and give credits.
* Aug 16, 2023: IBM asked if additional assistance was required [NB:
IBM likely wanted to close this ticket while no security patches were
published].
* Aug 17, 2023: I asked again information about ibmsecurity and CVE-2023-25927.
* Oct 20, 2023: IBM said they were still analysing the requests (final
list of patched vulnerabilties, security patches of ibmsecurity and
status of CVE-2023-25927).
* Oct 25, 2023: IBM asked to organize a meeting.
* Oct 25, 2023: I replied that I was still waiting for the final list
of vulnerabilities that would be fixed in version 10.0.7. There was
also no information regarding security patches for ibmsecurity.
* Oct 25, 2023: IBM replied they wanted to discuss about the
vulnerabilities in a meeting.
* Oct 29, 2023: IBM asked to organize a meeting again.
* Oct 30, 2023: I accepted the meeting and I asked IBM to provide the
list of vulnerabilities that would be patched with their current
status. I also asked the status of ibmsecurity.
* Oct 30, 2023: IBM asked to have a meeting on Nov 7, 2023.
* Nov 2, 2023: I confirmed my presence to the meeting.
* Nov 5, 2023: IBM confirmed the meeting.
* Nov 7, 2023: Meeting with IBM. IBM provided me with a new report
containing new feedbacks for several vulnerabilities. Also IBM
confirmed that several vulnerabilities would be patched in 2024 and
ibmsecurity would be patched in December 2023. IBM asked me to review
a specific vulnerability that appears to be invalid (_V-[REDACTED] -
Insecure SSLv3 connections to the DSC servers_).
* Nov 21, 2023: IBM asked me to review the new report shared by IBM.
* Nov 28, 2023: IBM asked for updates.
* Dec 4, 2023: I answered that I did not have anymore access to the
test infrastructure and IBM had to wait for my analysis until I get
again access to the test infrastructure.
* Dec 4, 2023: IBM asked me to check the vulnerabilities as soon as possible.
* Dec 21, 2023: I got access to a test infrastructure and reviewed
some vulnerabilities.
* Dec 21, 2023: I sent a new analysis to IBM, containing details of 4
vulnerabilities.
* Dec 27, 2023: IBM confirmed the reception of the new analysis.
* Jan 15, 2024: IBM asked me to update ISVA and recheck all the vulnerabilities.
* Jan 16, 2024: I asked IBM if ibmsecurity was also patched.
* Jan 16, 2024: IBM confirmed that a new case must be opened for
ibmsecurity to get security patches(!).
* Jan 22, 2024: IBM wanted to organize a new meeting.
* Jan 22, 2024: I replied that I failed to understand the issue with
the ibmsecurity library and that I had a written confirmation by IBM
that security patches would be provided. The vulnerabilities found in
ibmsecurity were reported in March 2023 (10 months ago).
* Jan 22, 2024: I informed IBM that I discovered(!) a new security
bulletin thanks to @CVEnew:
https://www.ibm.com/support/pages/node/7106586, but only 15
vulnerabilities were listed instead of the 35 vulnerabilities
confirmed by IBM. I asked IBM to clarify the situation as it looked
like less than half of vulnerabilities were indeed patched.
* Jan 24, 2024: IBM created a new case for ibmsecurity.
* Jan 29, 2024: IBM confirmed that 5 vulnerabilities had not been
patched in the latest version (10.0.7).
* Jan 29, 2024: I reached IBM to get the status of 15 unpatched
vulnerabilities. I provided the updated analysis to IBM.
* Feb 7, 2024: IBM confirmed that some of the vulnerabilities were
"being processed" and that some of vulnerabilities had been also
silently patched and no security bulletins had been published.
* Feb 20, 2024: IBM asked for updates.
* Feb 20, 2024: I asked when would be the release date for ISVA 10.0.8
and the complete list of vulnerabilities that would be patched in this
release.
* Feb 20, 2024: IBM confirmed that the 10.0.8 release would be
published in mid-2024.
* Feb 23, 2024: I sent a new vulnerability to IBM "Authentication
Bypass on IBM Security Verify Runtime".
* Feb 23, 2024: IBM confirmed the reception of the vulnerability and
asked to close the ticket.
* Feb 23, 2024: I said that since some vulnerabilities had not been
patched, the ticket must stay open.
* Feb 23, 2024: IBM said that they cannot keep the ticket open and
they needed to close it.
* Feb 23, 2024: I explained that the vulnerabilities were reported
over a year ago and IBM confirmed they had not fully fixed in the
latest version and that some vulnerabilities were also still under
evaluation. I said that I would agree to close this ticket if IBM
could confirm that all vulnerabilities reported in the ticket had been
correctly fixed in the latest version. I also asked IBM to provide the
corresponding security bulletins.
* Feb 27, 2024: Regarding the authentication bypass, IBM replied that
the runtime was supposed to be in the intranet zone.
* Feb 28, 2024: I asked IBM to clarify where in the documentation
specified that the runtime should not be exposed. For example, in
https://www.ibm.com/docs/en/sva/10.0.7?topic=support-docker-image-verify-access-runtime,
it was not explained that exposing this runtime on the network was a
high security risk.
* Mar 4, 2024: Regarding the vulnerabilities found in ibmsecurity, IBM
said that any security vulnerability found in ibmsecurity must be
reported by opening an issue in the Github repository.
* Mar 8, 2024: IBM confirmed they were able to reproduce the
authentication bypass vulnerability.
* Mar 12, 2024: IBM confirmed they would add an optional MTLS
authentication in the next release (10.0.8) and they would update the
ISVA documentation to block any attempt of the authentication bypass
vulnerability.
* Mar 29, 2024: IBM published a new security bulletin:
https://www.ibm.com/support/pages/node/7145400.
* Mar 29, 2024: IBM confirmed that any security vulnerability found in
ibmsecurity must be reported by opening an issue in the Github
repository.
* Apr 1, 2024: Creation of
https://github.com/IBM-Security/ibmsecurity/issues/416.
* Apr 2, 2024: IBM confirmed the reception of the report
https://github.com/IBM-Security/ibmsecurity/issues/416#issuecomment-2032110397.
* Apr 3, 2024: https://github.com/IBM-Security/ibmsecurity/issues/416
was entirely redacted by IBM.
* Apr 5, 2024: I asked if the vulnerabilities would be patched in the
#416 issue (https://github.com/IBM-Security/ibmsecurity/issues/416).
* Apr 6, 2024: Issue #416
(https://github.com/IBM-Security/ibmsecurity/issues/416) closed.
* Apr 6, 2024: I added again the content of
https://github.com/IBM-Security/ibmsecurity/issues/416 and asked if
CVEs would be published.
* Apr 10, 2024: Security bulletin for ibm security published:
https://www.ibm.com/support/pages/node/7147932.
* Apr 10, 2024: I reached IBM regarding a new security bulletin, with
a potential vulnerability I reported
https://www.ibm.com/support/pages/node/7145828.
* Apr 10, 2024: IBM said this security bulletin was unrelated to the
vulnerabilities I reported.
* Apr 15, 2024: IBM confirmed that the final vulnerabilities would be
fixed in ISVA 10.0.8.
* Apr 15, 2024: I provided a list of unfixed vulnerabilities and asked
for more information.
* Apr 16, 2024: IBM confirmed that all the unfixed vulnerabilities
would be fixed in ISVA 10.0.8 and asked to close the ticket.
* Apr 16, 2024: I confirmed that this ticket can be closed only when
the security patches are available.
* Apr 16, 2024: IBM confirmed they wanted to close the ticket because
nothing would be updated before mid-2024.
* Apr 17, 2024: I replied that "It makes no sense to close this ticket
until the vulnerabilities have been fixed. The fact that the
vulnerabilities are fixed mid-year is a decision made by IBM. IBM was
made aware of these vulnerabilities over a year ago, and yet we are
still waiting for security patches. If this ticket is closed, I would
consider that the vulnerabilities have been fixed and it is perfectly
fine to publish the technical analysis."
* May 6, 2024: IBM closed the existing ticket and opened new tickets
for the remaining vulnerabilities.
* May 6, 2024: I contacted IBM PSIRT asking if it was fine to publish
the vulnerabilities since the ticket was closed by IBM.
* May 7, 2024: I reopened the ticket stating that some of the patched
vulnerabilities did not receive a CVE and there were also some
unpatched vulnerabilities. I asked IBM to provide me with the CVE
assigned to each vulnerability. I also asked IBM to confirm that,
since this ticket had been closed by IBM, all the vulnerabilities had
been fixed and that I would be able to publish the technical details.
* May 8, 2024: IBM said they would review the list of vulnerabilities.
* May 10, 2024: IBM PSIRT asked me not to publish technical details of
unpatched vulnerabilities.
* May 17, 2024: IBM provided me with an incomplete list of CVEs, with
different vulnerabilities under the same CVE identifier and asked to
close the ticket.
* May 20, 2024: IBM asked for my comments on the list of CVEs.
* May 20, 2024: I confirmed that several CVEs were missing and the
list was incomplete.
* May 21, 2024: IBM provided me with an explanation regarding the missing CVEs.
* May 21, 2024: I asked IBM to quote their explanation in the security advisory.
* May 21, 2024: IBM asked to have a meeting.
* May 22, 2024: I replied that I would prefer written communication
since it was very difficult to track the status of the vulnerabilities
with (1) CVEs obtained only several months after the release of
security bulletins, (2) tickets closed by IBM for unpatched
vulnerabilities, (3) vulnerabilities in ibmsecurity which could be
corrected by IBM and which could then no longer be managed by IBM, and
(4) missing CVEs.
* May 22, 2024: IBM asked to have a meeting to remove any confusion.
* May 23, 2024: I replied that there's not much confusion except
missing CVEs for silently patched vulnerabilities and lack of
communication from IBM when releasing security patches. I asked IBM to
share the CVEs with the corresponding vulnerabilities and indicate the
security bulletins with the list of corresponding vulnerabilities.
* May 24, 2024: IBM stated they would provide me with additional CVEs.
* May 30, 2024: I confirmed that the creation of additional CVEs is fair.
* Jun 2, 2024: IBM confirmed 3 new CVEs in a new security bulletin:
https://www.ibm.com/support/pages/node/7155356.
* Jun 3, 2024: I asked IBM the release date of the 10.0.8 version.
* Jun 3, 2024: IBM confirmed that the exact date was not yet decided.
* Jun 6, 2024: IBM asked if I had comments about the remaining vulnerabilities.
* Jun 8, 2024: I asked IBM the status of a previously patched vulnerability.
* Jun 10, 2024: IBM confirmed that this vulnerability had not been
previously patched and would be patched in the 10.0.8 release.
* Jun 11, 2024: IBM asked to create separate cases for the remaining
vulnerabilities.
* Jun 19, 2024: IBM asked if I needed assistance.
* Jun 23, 2024: IBM confirmed that the 10.0.8 version was released and
that they would close the ticket tracking the vulnerabilities.
* Jun 26, 2024: I asked IBM to provide the corresponding CVEs and the
link of the security bulletin.
* Jun 27, 2024: IBM provided me with the link to the security
bulletin: https://www.ibm.com/support/pages/node/7158790 and said that
the 10.0.8 version was released with all the patched vulnerabilities.
IBM closed the ticket.
* Jul 3, 2024: I reopened the ticket and asked IBM to provide me with
the list of vulnerabilities with the corresponding CVEs since I was
not able to correctly map the CVEs to the vulnerabilities I reported.
* Jul 8, 2024: IBM provided me with the list of CVEs. IBM closed the ticket.
* Sep 7, 2024: I sent an email to IBM PSIRT stating that I was going
to publish the security advisory and that some CVEs were still
missing. I also stated that CVE-2023-38371 seemed to be an error since
it was confirmed not to be a vulnerability according to our previous
email exchanges.
* Sep 9, 2024: I asked IBM to provide me with an official link
regarding the runtime authentication bypass, to publish it in the
security advisory.
* Sep 13, 2024: IBM PSIRT provided me with (1) links regarding the
runtime authentication bypass and (2) additional CVEs. They also
confirmed that at least one vulnerability was not fixed and asked me
not to disclose this finding until it was patched. No information was
provided when this vulnerability would be patched.
* Nov 1, 2024: A security advisory is published.



## Credits

These vulnerabilities were found by Pierre Barre aka Pierre Kim (@PierreKimSec).



## References

https://pierrekim.github.io/blog/2024-11-01-ibmsecurity-4-vulnerabilities.html

https://pierrekim.github.io/advisories/2024-ibmsecurity.txt

https://pierrekim.github.io/blog/2024-11-01-ibm-security-verify-access-32-vulnerabilities.html

https://pierrekim.github.io/advisories/2024-ibm-security-verify-access.txt

https://www.ibm.com/support/pages/node/7147932

https://github.com/IBM-Security/ibmsecurity/issues/416



## Disclaimer

This advisory is licensed under a Creative Commons Attribution Non-Commercial
Share-Alike 3.0 License: http://creativecommons.org/licenses/by-nc-sa/3.0/

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEoSgI9MSrzxDXWrmCxD4O2n2TLbwFAmckrboACgkQxD4O2n2T
LbxT0BAAiFtMwoXwQZ86MJwK4TkmenuPSmnRfYcE5v3P3PYlhEqp1SCajyiOySiu
Wy0qcJEhHb1xFZsxABlA/tzK23sqf2mt4rhaYSGzOjj2diOQvawS2ODSdnkKOXUb
oaoUK8H2mav4uOaCHKXxYPA0Si1AS7wvUlkC/tR+ZM2kkiYwUvStKIZWivbsB+7K
T6/1Xpc1vYSjuHJm+if4tbMaDXBDFZsMQZdGk5V5a4aNb+nBviSsG4OHsCFpEQbC
kybhmNVaDXGsHbWPFGzoq7DAIHYj0qUQKe7eITkrHIiV1gi0k5ZQwN2qsUQNvmRY
0XjvH2ioZ20xG9L2AHvLHVDcnpl4nzWqNgtXn9ouTGdZU3ks/aSsvmknPX0Z0OAu
QBH9OchXSv2TGOA+gHik3//9NGi36W74SuW+P1B+69iA19xVPsvIzAMrOW3dDuGM
j3MGsI54OLckDtO9UaWlDJ5yN6UrOya1OnPY8u8sZTsN5Zw272yC6Za3vH46XX8S
bdIrh9atmfnQmzIQh/uaGLA/Z+H6Oj/7ERJbhoNDlK/edSntMPN+nnJAeAho+bOr
Qsvyzu1kvxZUzQ4TdQS49PWy2yDLCd796DL6P9xfpzsIScEQlMfXEOViBlmkSujp
SMEWsMRbGSV1qVpOT5UwEI7I305ZpcZ2Svd20DhM1c4F+/E1Pz8=
=rADO
-----END PGP SIGNATURE-----



-- 
Pierre Kim
pierre.kim.sec () gmail com
@PierreKimSec
https://pierrekim.github.io/
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/

Current thread:

• 4 vulnerabilities in ibmsecurity Pierre Kim (Nov 03)