Re: [Burp-users] Damaged manifest and encrypted backup

[Graham K. <gr...@gr...>]

On Fri, May 28, 2021 at 11:14:27AM +0200, Benedikt Hochstrasser wrote:
> Hi list,
> 
> we are using burp to backup various servers in here and it works
> flawlessly. One server, however, contains über-sensitive data and we
> make an encrypted backup with it (which in turn is then backed up to
> some off-site location within the organization).
> 
> When playing through various case scenarios, we examined what happens
> if for some reason the backup's manifest file is damaged.
> 
> Scenario 1: (unencrypted backups): Just copy the file off the backup's
> folder structure and run it through gzip and vss_strip et voilà, you
> have your file. It would be easy to run that procedure through the
> whole folder structure to reconstruct all the data (at the loss of
> meta-data like modification dates and attributes, but we can live with
> that)
> 
> Scenario 2: (encrypted backups): No way we could ever decrypt these
> files, even with the encryption password, as the salt is buried in the
> manifest file which - per our scenario - is
> damaged/unavailable/unusable.
> 
> So, in consequence, this means we must encrypt the backup set file by
> file between burp-ing locally and sending it to off-site storage. Else
> we'd be sitting on a load of garbled data if Murphy strikes.
> 
> It would be really neat if in future versions the encryption salt
> would be stored in the file as done by standard and well-documented
> openssl procedures:
> 
> "openssl enc -aes-256-cbc -in some.pdf -out some.pdf.enc" and "openssl
> enc -d -aes-256-cbc -in some.pdf.enc -out some-new.pdf" to en- and
> decrypt files.
> 
> The salt would be stored along with the file:
> [code]
> hexdump -C some.pdf.enc | head
> 00000000  53 61 6c 74 65 64 5f 5f  a7 b1 32 57 3a 12 a5 e6  |Salted__..2W:...|
> 00000010  8c 41 72 83 be b8 c4 42  a6 2f 22 3c 8c d9 bf c0  |.Ar....B./"<....|
> 00000020  a5 be d9 c1 84 37 b2 6a  79 35 d7 21 f2 df 00 78  |.....7.jy5.!...x|
> 00000030  1f 05 fc 0a b3 5c 94 ff  b4 89 72 64 db 86 8e a1  |.....\....rd....|
> 00000040  76 83 58 62 9b 99 bb 74  5a f1 9a c3 c2 0c 11 66  |v.Xb...tZ......f|
> ...
> [/code]
> 
> I might, of course, be missing something obvious. But as I can see it,
> for encrypted backups, the manifest file is the Achilles Heel of an
> otherwise intact backup set. For unencrypted backups, burp's method is
> flexible and resilient unlike many other backups.

Hello,

I think you make an excellent point, thank you.

I have added this to the github issues:
https://github.com/grke/burp/issues/886

Seeing as a few people have been asking about related issues recently, I intend
to try to implement this soon.