Re: [Burp-users] Damaged manifest and encrypted backup
Brought to you by:
grke
|
From: Graham K. <gr...@gr...> - 2021-05-30 10:31:43
|
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. |