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:
- CVE-2024-31871 - Insecure communications 1/2
- CVE-2024-31872 - Insecure communications 2/2
- CVE-2024-31873 - Hardcoded passwords
- 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.
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:
...
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
...
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:
...
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)
...
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):
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)
...
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:
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)
...
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):
...
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)
Content of ibmsecurity/appliance/isdsappliance.py (line 254):
...
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)
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):
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)
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:
...
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):
...
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:
...
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):
...
Content of ibmsecurity/isam/web/reverse_proxy/aac_configuration.py:
...
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):
...
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:
...
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 }
...
Content of ibmsecurity/isam/aac/risk_profiles.py:
...
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
...
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):
- 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.
- Apr 6, 2024: Issue #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/
published on 2024-11-01 00:00:00 by Pierre Kim <pierre.kim.sec@gmail.com>