IBM Security Verify Access Appliance Insecure Transit / Hardcoded Passwords

—–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—–