| 2024-01-08 03:56:52 |
Andrew Ruthven |
bug |
|
|
added bug |
| 2024-01-08 20:18:57 |
Jeremy Stanley |
description |
Hey folks,
During our latest annual penetration test of our OpenStack based cloud, it was discovered that Horizon, when creating a volume transfer to another project, provides a link to download the transfer credentials to a file which can then be saved. This link includes the transfer secret aka authorisation key, and is sent as a GET to the server. The server code parses the URL, pulls out the UUID and authorisation key and the renders a template to be returned. The use of GET here exposes the authorisation key.
As you're no doubt aware, sensitive information contained within URLs can be recorded in multiple locations, including the user’s web browser, the web server, and any forward or reverse proxy servers situated between the two endpoints. In addition, URLs are commonly displayed on-screen, bookmarked, or shared via email by users. When users follow off-site links, these URLs may also be revealed to third parties through the Referrer header. Therefore, inserting credentials into a URL heightens the vulnerability of them being intercepted and subsequently exploited by potential attackers (in this case the Referrer header is unlikely).
To reproduce:
1. Configure a browser to use an intercepting proxy such as Burp.
2. Log in to Horizon as a user with privileges to manager volumes.
3. Navigate to: ”Volumes” > ”Volumes”.
4. Choose a volume then select the ”Create Transfer” action.
5. Provide a transfer name then click the ”Create Volume Transfer” button.
6. Observe that the ”Transfer ID” and ”Authorisation Key” are populated.
7. Click the ”Download transfer credentials” button to download the credentials.
8. Observe a URL like the following in Burp:
GET / project / volumes /98fd<<redacted >>66b0/ download_creds /363e<< redacted >>27c1 HTTP /1.1
Host: dashboard.example.com
This is made worse by the fact that Cinder doesn't expire transfer requests:
https://opendev.org/openstack/cinder/src/commit/4ee1bdaf648064adb6ad9f0e4fda6adc6ad1cbb6/cinder/transfer/api.py#L164
Path match in Horizon:
https://opendev.org/openstack/horizon/src/commit/fb1a3e88daf479b8fc5edcf26995fb860c76d05c/openstack_dashboard/dashboards/project/volumes/urls.py#L66 (and is present in master)
Code in Horizon which generates the result:
https://opendev.org/openstack/horizon/src/commit/fb1a3e88daf479b8fc5edcf26995fb860c76d05c/openstack_dashboard/dashboards/project/volumes/views.py#L672 (and is present in master)
Ideally the generation of creds file would be fully in the browser, there is no need for a round trip to the server. If a round trip is necessary, then it should be via a POST and not include the transfer key in the URL.
Kind regards,
Andrew |
This issue is being treated as a potential security risk under
embargo. Please do not make any public mention of embargoed
(private) security vulnerabilities before their coordinated
publication by the OpenStack Vulnerability Management Team in the
form of an official OpenStack Security Advisory. This includes
discussion of the bug or associated fixes in public forums such as
mailing lists, code review systems and bug trackers. Please also
avoid private disclosure to other individuals not already approved
for access to this information, and provide this same reminder to
those who are made aware of the issue prior to publication. All
discussion should remain confined to this private bug report, and
any proposed fixes should be added to the bug as attachments. This
embargo shall not extend past 2024-04-07 and will be made
public by or on that date even if no fix is identified.
Hey folks,
During our latest annual penetration test of our OpenStack based cloud, it was discovered that Horizon, when creating a volume transfer to another project, provides a link to download the transfer credentials to a file which can then be saved. This link includes the transfer secret aka authorisation key, and is sent as a GET to the server. The server code parses the URL, pulls out the UUID and authorisation key and the renders a template to be returned. The use of GET here exposes the authorisation key.
As you're no doubt aware, sensitive information contained within URLs can be recorded in multiple locations, including the user’s web browser, the web server, and any forward or reverse proxy servers situated between the two endpoints. In addition, URLs are commonly displayed on-screen, bookmarked, or shared via email by users. When users follow off-site links, these URLs may also be revealed to third parties through the Referrer header. Therefore, inserting credentials into a URL heightens the vulnerability of them being intercepted and subsequently exploited by potential attackers (in this case the Referrer header is unlikely).
To reproduce:
1. Configure a browser to use an intercepting proxy such as Burp.
2. Log in to Horizon as a user with privileges to manager volumes.
3. Navigate to: ”Volumes” > ”Volumes”.
4. Choose a volume then select the ”Create Transfer” action.
5. Provide a transfer name then click the ”Create Volume Transfer” button.
6. Observe that the ”Transfer ID” and ”Authorisation Key” are populated.
7. Click the ”Download transfer credentials” button to download the credentials.
8. Observe a URL like the following in Burp:
GET / project / volumes /98fd<<redacted >>66b0/ download_creds /363e<< redacted >>27c1 HTTP /1.1
Host: dashboard.example.com
This is made worse by the fact that Cinder doesn't expire transfer requests:
https://opendev.org/openstack/cinder/src/commit/4ee1bdaf648064adb6ad9f0e4fda6adc6ad1cbb6/cinder/transfer/api.py#L164
Path match in Horizon:
https://opendev.org/openstack/horizon/src/commit/fb1a3e88daf479b8fc5edcf26995fb860c76d05c/openstack_dashboard/dashboards/project/volumes/urls.py#L66 (and is present in master)
Code in Horizon which generates the result:
https://opendev.org/openstack/horizon/src/commit/fb1a3e88daf479b8fc5edcf26995fb860c76d05c/openstack_dashboard/dashboards/project/volumes/views.py#L672 (and is present in master)
Ideally the generation of creds file would be fully in the browser, there is no need for a round trip to the server. If a round trip is necessary, then it should be via a POST and not include the transfer key in the URL.
Kind regards,
Andrew |
|
| 2024-01-08 20:19:14 |
Jeremy Stanley |
bug task added |
|
ossa |
|
| 2024-01-08 20:19:28 |
Jeremy Stanley |
ossa: status |
New |
Incomplete |
|
| 2024-01-08 20:19:48 |
Jeremy Stanley |
bug |
|
|
added subscriber Horizon Core security contacts |
| 2024-01-30 14:51:18 |
Vishal Manchanda |
horizon: status |
New |
Confirmed |
|
| 2024-01-30 14:58:29 |
Vishal Manchanda |
horizon: importance |
Undecided |
Critical |
|
| 2024-03-20 16:53:21 |
Radomir Dopieralski |
horizon: assignee |
|
Radomir Dopieralski (deshipu) |
|
| 2024-03-25 11:14:34 |
Radomir Dopieralski |
attachment added |
|
0001-Pass-the-auth_key-for-volume-transfer-in-the-session.patch https://bugs.launchpad.net/horizon/+bug/2048493/+attachment/5759260/+files/0001-Pass-the-auth_key-for-volume-transfer-in-the-session.patch |
|
| 2024-03-25 12:28:18 |
Radomir Dopieralski |
attachment added |
|
0001-Don-t-pass-the-auth_key-for-volume-transfer-in-the-U.patch https://bugs.launchpad.net/horizon/+bug/2048493/+attachment/5759284/+files/0001-Don-t-pass-the-auth_key-for-volume-transfer-in-the-U.patch |
|
| 2024-03-25 12:28:37 |
Radomir Dopieralski |
horizon: status |
Confirmed |
In Progress |
|
| 2024-03-25 14:21:43 |
Jeremy Stanley |
description |
This issue is being treated as a potential security risk under
embargo. Please do not make any public mention of embargoed
(private) security vulnerabilities before their coordinated
publication by the OpenStack Vulnerability Management Team in the
form of an official OpenStack Security Advisory. This includes
discussion of the bug or associated fixes in public forums such as
mailing lists, code review systems and bug trackers. Please also
avoid private disclosure to other individuals not already approved
for access to this information, and provide this same reminder to
those who are made aware of the issue prior to publication. All
discussion should remain confined to this private bug report, and
any proposed fixes should be added to the bug as attachments. This
embargo shall not extend past 2024-04-07 and will be made
public by or on that date even if no fix is identified.
Hey folks,
During our latest annual penetration test of our OpenStack based cloud, it was discovered that Horizon, when creating a volume transfer to another project, provides a link to download the transfer credentials to a file which can then be saved. This link includes the transfer secret aka authorisation key, and is sent as a GET to the server. The server code parses the URL, pulls out the UUID and authorisation key and the renders a template to be returned. The use of GET here exposes the authorisation key.
As you're no doubt aware, sensitive information contained within URLs can be recorded in multiple locations, including the user’s web browser, the web server, and any forward or reverse proxy servers situated between the two endpoints. In addition, URLs are commonly displayed on-screen, bookmarked, or shared via email by users. When users follow off-site links, these URLs may also be revealed to third parties through the Referrer header. Therefore, inserting credentials into a URL heightens the vulnerability of them being intercepted and subsequently exploited by potential attackers (in this case the Referrer header is unlikely).
To reproduce:
1. Configure a browser to use an intercepting proxy such as Burp.
2. Log in to Horizon as a user with privileges to manager volumes.
3. Navigate to: ”Volumes” > ”Volumes”.
4. Choose a volume then select the ”Create Transfer” action.
5. Provide a transfer name then click the ”Create Volume Transfer” button.
6. Observe that the ”Transfer ID” and ”Authorisation Key” are populated.
7. Click the ”Download transfer credentials” button to download the credentials.
8. Observe a URL like the following in Burp:
GET / project / volumes /98fd<<redacted >>66b0/ download_creds /363e<< redacted >>27c1 HTTP /1.1
Host: dashboard.example.com
This is made worse by the fact that Cinder doesn't expire transfer requests:
https://opendev.org/openstack/cinder/src/commit/4ee1bdaf648064adb6ad9f0e4fda6adc6ad1cbb6/cinder/transfer/api.py#L164
Path match in Horizon:
https://opendev.org/openstack/horizon/src/commit/fb1a3e88daf479b8fc5edcf26995fb860c76d05c/openstack_dashboard/dashboards/project/volumes/urls.py#L66 (and is present in master)
Code in Horizon which generates the result:
https://opendev.org/openstack/horizon/src/commit/fb1a3e88daf479b8fc5edcf26995fb860c76d05c/openstack_dashboard/dashboards/project/volumes/views.py#L672 (and is present in master)
Ideally the generation of creds file would be fully in the browser, there is no need for a round trip to the server. If a round trip is necessary, then it should be via a POST and not include the transfer key in the URL.
Kind regards,
Andrew |
Hey folks,
During our latest annual penetration test of our OpenStack based cloud, it was discovered that Horizon, when creating a volume transfer to another project, provides a link to download the transfer credentials to a file which can then be saved. This link includes the transfer secret aka authorisation key, and is sent as a GET to the server. The server code parses the URL, pulls out the UUID and authorisation key and the renders a template to be returned. The use of GET here exposes the authorisation key.
As you're no doubt aware, sensitive information contained within URLs can be recorded in multiple locations, including the user’s web browser, the web server, and any forward or reverse proxy servers situated between the two endpoints. In addition, URLs are commonly displayed on-screen, bookmarked, or shared via email by users. When users follow off-site links, these URLs may also be revealed to third parties through the Referrer header. Therefore, inserting credentials into a URL heightens the vulnerability of them being intercepted and subsequently exploited by potential attackers (in this case the Referrer header is unlikely).
To reproduce:
1. Configure a browser to use an intercepting proxy such as Burp.
2. Log in to Horizon as a user with privileges to manager volumes.
3. Navigate to: ”Volumes” > ”Volumes”.
4. Choose a volume then select the ”Create Transfer” action.
5. Provide a transfer name then click the ”Create Volume Transfer” button.
6. Observe that the ”Transfer ID” and ”Authorisation Key” are populated.
7. Click the ”Download transfer credentials” button to download the credentials.
8. Observe a URL like the following in Burp:
GET / project / volumes /98fd<<redacted >>66b0/ download_creds /363e<< redacted >>27c1 HTTP /1.1
Host: dashboard.example.com
This is made worse by the fact that Cinder doesn't expire transfer requests:
https://opendev.org/openstack/cinder/src/commit/4ee1bdaf648064adb6ad9f0e4fda6adc6ad1cbb6/cinder/transfer/api.py#L164
Path match in Horizon:
https://opendev.org/openstack/horizon/src/commit/fb1a3e88daf479b8fc5edcf26995fb860c76d05c/openstack_dashboard/dashboards/project/volumes/urls.py#L66 (and is present in master)
Code in Horizon which generates the result:
https://opendev.org/openstack/horizon/src/commit/fb1a3e88daf479b8fc5edcf26995fb860c76d05c/openstack_dashboard/dashboards/project/volumes/views.py#L672 (and is present in master)
Ideally the generation of creds file would be fully in the browser, there is no need for a round trip to the server. If a round trip is necessary, then it should be via a POST and not include the transfer key in the URL.
Kind regards,
Andrew |
|
| 2024-03-25 14:21:49 |
Jeremy Stanley |
information type |
Private Security |
Public Security |
|
| 2024-04-04 23:08:53 |
OpenStack Infra |
horizon: status |
In Progress |
Fix Released |
|
