Open Stack

On 10-02-21 11:29:06, Jan Wasilewski wrote:
> Thank you for a nice description of how everything is organized. It is much
> easier to understand the full workflow.
> 
> >> I'll try to find some time to write these up again later in the week.
> That would be great, I will try to do this by myself, but I'm wondering if
> it's possible to do "all magic" directly from a payload that is visible
> from barbican CLI.
> 
> Anyway, I checked also related conversation at openstack-lists and I'm
> wondering about this part:
> http://lists.openstack.org/pipermail/openstack-dev/2017-May/117470.html
> 
> Is there a way to replace the compromised LUKS passphrase with the current
> implementation of barbican? I was trying to do this by myself but without
> luck. I'm also wondering if there is a procedure that can help here(if you
> know?)

AFAIK the only way to do this at present is by retyping [1] the volume
to a different encrypted volume type. That should result in a new volume
using new secrets etc that for LUKSv1 volumes would mean a new
passphrase.

[1] https://docs.openstack.org/api-ref/block-storage/v3/index.html?expanded=retype-a-volume-detail#volume-actions-volumes-action

> wt., 9 lut 2021 o 23:12 Lee Yarwood <lyarwood at redhat.com> napisał(a):
> 
> > On 09-02-21 12:48:38, Jan Wasilewski wrote:
> > > Hi All,
> > >
> > > I have a question about the possible decryption of LUKS volume. I'm
> > testing
> > > currently barbican+cinder, but I'm just wondering if there is a way, to
> > > somehow decrypt my LUKS volume with payload generated by a barbican. Is
> > > there any procedure for that? I was doing it by myself, but somehow it
> > > doesn't work and I got an error:
> > >
> > > [TEST]root at barbican-01:/usr/lib/python3/dist-packages# barbican secret
> > get
> > > --payload --payload_content_type application/octet-stream
> > >
> > http://controller.test:9311/v1/secrets/76631940-9ab6-4b8c-9481-e54c3ffdbbfe
> > >
> > +---------+--------------------------------------------------------------------------------------------------------+
> > > | Field   | Value
> > >                                         |
> > >
> > +---------+--------------------------------------------------------------------------------------------------------+
> > > | Payload | b'\xbf!i\x97\xf4\x0c\x12\xa4\xfe4\xf3\x16C\xe8@
> > \xdc\x0f\x9d+:\x0c7\xa9\xab[\x8d\xf2\xf1\xae\r\x89\xdc'
> > > |
> > >
> > +---------+--------------------------------------------------------------------------------------------------------+
> > >
> > > cryptsetup luksOpen
> > /dev/disk/by-id/wwn-0x6e00084100ee7e7e7ab0b13c0000386f
> > > my-volume
> > > Enter passphrase for
> > > /dev/disk/by-id/wwn-0x6e00084100ee7e7e7ab0b13c0000386f: *<passphrase from
> > > payload>*
> > > No key available with this passphrase.
> > >
> > > I thought that above issue can be related to encoding, so I took payload
> > > value directly from vault and use it as a key-file, but problem is
> > exactly
> > > the same(my encrypted volume is the last volume list by domblklist
> > option):
> > >
> > > vault kv get secret/data/e5baa518207e4f9db4810988d22087ce | grep value |
> > > awk -F'value:' '{print $2}'
> > >
> > 4d4d35676c336567714850663477336d2b415475746b74774c56376b77324b4e73773879724c46704678513d]
> > >
> > > [TEST]root at comp-02:~# cat bbb
> > >
> > 4d4d35676c336567714850663477336d2b415475746b74774c56376b77324b4e73773879724c46704678513d
> > > [TEST]root at comp-02:~# cat bbb | base64 -d > pass2
> > > [TEST]root at comp-02:~# cat pass2
> > > ▒▒߻▒▒▒▒▒^<▒N▒▒▒▒~پ5▒▒▒▒▒▒▒z߾▒▒▒▒~▒▒▒▒▒n▒▒▒▒▒]▒[TEST]root at comp-02:~#
> > > [TEST]root at comp-02:~# virsh domblklist instance-00000da8
> > > Target     Source
> > > ------------------------------------------------
> > > vda        /dev/dm-17
> > > vdb        /dev/disk/by-id/wwn-0x6e00084100ee7e7e74623bd3000036bc
> > > vdc        /dev/dm-16
> > > vde        /dev/disk/by-id/wwn-0x6e00084100ee7e7e7ab0b13c0000386f
> > > vdf        /dev/disk/by-id/wwn-0x6e00084100ee7e7e7bd45c1b000038b5
> > > [TEST]root at comp-02:~# udisksctl unlock -b
> > > /dev/disk/by-id/wwn-0x6e00084100ee7e7e7bd45c1b000038b5 --key-file pass2
> > > Error unlocking /dev/dm-21:
> > > GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error unlocking
> > > /dev/dm-21: Failed to activate device: Operation not permitted
> > > [TEST]root at comp-02:~# cryptsetup luksOpen
> > > /dev/disk/by-id/wwn-0x6e00084100ee7e7e7bd45c1b000038b5 my-volume
> > > --master-key-file=pass2
> > > Volume key does not match the volume.
> > >
> > >
> > > I see that nova/cinder and barbican are doing this stuff somehow so I
> > > strongly believe there is a way to decrypt this manually. Maybe I’m doing
> > > something wrong in my testing-steps.
> > > Thanks in advance for any help here! Unfortunately, I haven’t found any
> > > materials on how to do this.
> >
> > Yeah this is thanks to a long standing peice of technical debt that I've
> > wanted to remove for years but I've never had to the change to.
> >
> > The tl;dr is that os-brick and n-cpu both turn the associated symmetric key
> > secret into a passphrase using the following logic, ultimately calling
> > binascii.hexlify:
> >
> >
> > https://github.com/openstack/nova/blob/944443a7b053957f0b17a5edaa1d0ef14ae48f30/nova/virt/libvirt/driver.py#L1463-L1466
> >
> >
> > https://github.com/openstack/os-brick/blob/ec70b4092f649d933322820e3003269560df7af9/os_brick/encryptors/cryptsetup.py#L101-L103
> >
> > I'm sure I've written up the steps to manually decrypt a cinder volume
> > using these steps before but I can't seem to find them at the moment.
> > I'll try to find some time to write these up again later in the week.
> >
> > Obviously it goes without saying that c-vol/c-api should be creating a
> > passphrase secret for LUKS encrypted volumes to avoid this madness.
> >
> > Cinder creating and associating symmetric keys with encrypted volumes when
> > used with Barbican
> > https://bugs.launchpad.net/cinder/+bug/1693840
> >
> > --
> > Lee Yarwood                 A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672
> > 2D76
> >

-- 
Lee Yarwood                 A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210210/71c67f6e/attachment.sig>