Open Stack

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?)
Thanks in advance.

Best regards,
Jan

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210210/db440cd7/attachment.html>