>> As you can probably tell from the title of this talk, it's about cloud storage.
I'm going to be covering an API line vulnerability.
I'm Zak.
I'm a student at the University of Waterloo.
I have had an interest in computer security and applied security for a very long time.
This is my second DEF CON and the first I'm speaking at a DEF CON or any conference bigger
than about 20 people.
So ‑‑ (Applause).
Thanks.
Hopefully I will get that same response afterwards too.
It remains to be seen.
So I'm giving a talk on cloud storage and when I was ‑‑ before this talk, I was
doing some recon and speaking to some of my friends and find out what they use cloud storage
for.
A lot of them use it as a USB key replacement.
They share large 10 megabyte files or backups of their documents, or across several devices.
Really for the most part it replaces USB keys and a lot of them still street cloud storage
systems as ‑‑ the same way they treat USB keys.
A large contain to throw files into and then delete a few to free up a little bit of space
afterwards.
But one of the cool things about cloud storage systems is they have many more features than
just space providing.
So I have a little chart here.
I don't know if you can see it.
It speaks about some of the additional mechanisms that some of the cloud storage providers have,
like history and backup retention.
So the vulnerability, the main discussion I want to have with this is the idea that
treating files as blocks, filling up a larger box, doesn't quite represent cloud storage
when you have this time dimension.
So if we try and reframe that previous picture, with the ‑‑ as a space time graph, we
can ‑‑ as a Gant chart, really, we have different time intervals and then by removing
files, we can see the life span of these files stops existing after a certain amount of time.
And then with this type of representation, we can think about the amount of space we
are using as a sliding bar.
At any given time, we are occupying a different amount of space.
This gives us an interesting sort of mechanism with which we can recover previously deleted
files.
Really what we are talking about, a lot of these cloud systems have a size limitation,
but have a time duration system for their history backup or retention.
When you have these two independent quota management systems, you have unlimited storage
because you can exploit history retention to get an additional ounce of space.
Really we are limited by our upload, rather than the existing cloud system ‑‑ the
existing cloud parameters.
So what this tool does, when we are doing an upload of a large file, we take a large
file and cut it up into several smaller fragments and load these fragments as different versions
of some arbitrarily new file and then we top it all off with a chunk of zero size.
This way, that our quota mechanism sees this as a zero file.
They see this as a zero sized file despite having the history backup.
So retrieval is very easy if we do this process.
We just have to pull all out versions and glue them back together with cat.
Going back to the storage time graph, I used this to represent a file earlier.
Earlier, what we can treat it as is more like this, where we have different versions of
this file that together create that original file, but are occupied considerably smaller
amounts of space in existence.
So, you know, our account use is actually closer to zero, when we are looking at it
from a different ‑‑ a different time.
So it's a fairly easy idea.
I rolled it into a tool for you guys.
I call this De‑pack Choppa, running with the whole cloud enlightenment thing.
It chops up files and packs them and de‑packs them afterwards.
I created a pluggable is service framework.
And it lets you plug out the API specifics of the individual cloud utilities.
From this, the tool maintains a storage database, back end for fragmentation to maintain the
history of the ‑‑ maintaining the history of fragments and the initial files that form
these fragments.
So I can talk all day up here, but you guys want to see a demo, right?
>> AUDIENCE MEMBER: Yeah.
>> ZAK BLACHER: Right?
All right.
Let's see.
So, yeah.
I'm getting a little bit of resolution problems there.
Is that better?
Okay.
So what I'm sorting here.
I don't have anything in this directory.
I'm just showing you, there's nothing up my sleeves.
And I'm creating a 64‑megabyte file that I will upload to the service.
Here's the checksum of it, just stating that from behind and then let's upload it.
One of the things I'm doing here as sort of a way to ‑‑ you know, one of the things
I'm trying to demonstrate here is there are ways of circumventing existing detection mechanisms
here.
What I'm doing here, the file size for the individual fragments is around about 512k,
plus or minus 5%.
Try to get around any sort of mechanisms in place to detect continual overwrites of the
same thing.
Now, I will get into this a little bit later.
There's a bunch of different techniques that we can mask as we are doing this, but for
now, it will demonstrate fairly well.
This information is generated from the de‑pack tool itself.
It's showing you the individual chunks that belong to this file, and the product upload.
I will use this to compare later on, when I have the information I'm getting back from
the server.
This is all locally generated information.
So we are just about finished.
Yeah, you can see the second to last file, it's about 200k, just to top it all off and
then the last one is the zero size.
You can see I have gone back into this folder.
This checksum I use here, the checksum I use here to act as the handle on the existing
framework takes up zero size.
So back to where we were.
Now I have deleted that binary and I'm busy reconstructing the file from the fragments
I'm getting back from the server.
So these chunk numbers you see here are the server ‑‑ is the information provided
by the rest API that gives us the mapping to the individual chucks we are looking at
earlier.
It will see a one‑to‑one mapping of the file size we get back here to the file sizes
we sent.
Yeah.
This is specific to Dropbox in this example.
There's no reason it can't be extended to other cloud storage providers.
So I finished downloading it.
It exists there and you can see that the checksums match.
So we can actually use this for storage.
(Applause).
>> ZAK BLACHER: Thank you.
Thank you.
The tool in the form that I used there is available on the CDs you guys are getting
as part of the packages here but I will also have the updated version of the code at GitHub
at this link, and you can bug me for it afterwards.
And I wrote it in Python.
For example, we can maintain our own deltas to map to real changes in the file information
rather than faking it through the API here.
We can do adaptive mangling and use different file names right now the tool uploads with
the get hash, and it uses that as the anchoring system but there's no reason we have to use
that.
Future work is extending the CLI.
Right now it supports get and put, but, you know, that's fairly ‑‑ fairly simple
functionality to continue working on there.
I also want to get some more modules done.
I looked at some of the other cloud source providers that have some mechanisms in place
to defeat this but are not particularly rigorous at this time.
Really only drop box works at this stage but we can work on that, right, guys?
I also want to do some more tuneable options so that we can look at different ways of automating
the process of generating the file fragments.
In this case, I used a generator to generate 512k chunks, and I had to overwrite one file
but there's no reason we can't use it to multiple files.
There's a whole bunch of ways we can take depending on the tuneable objects we want
to use.
This wouldn't be a security talk without the implications of this type of vulnerable.
If we look at the blue team concerns for this, is it's fairly straightforward to detect this
by looking at the constant file size writing and the time you are starting and the difference
between the Delta uploads.
But, you know, we can deal with this, with generators by introducing subtle variations
in the delays of the uploads of the different versions of these files.
We can vary the name and the file size and, you know, that's something we can counteract
their initial response to this thing.
Secondly, it's fairly straightforward to ban an API key.
But with the ostensibly, we can request a new one.
We don't limit the available functions ‑‑ or the available tools we can create just
because of one or two bad eggs.
Secondly, or thirdly, the one thing that is fairly evident is the null caps, the zero‑sized
fragments that make them take up no space in the internal metrics.
That's a fairly obvious signature.
We can really replace that by using something very small like a one byte file.
By moving it to one byte, we don't have unlimited space.
One of the concerns this is an issue, having unlimited spaces undermines their whole business
model.
Getting unlimited storage really breaks their financial incentive for these kinds of things.
Secondly, by going the opposite way, if they break large binary rights, it will really
damage a lot of the existing tools that use drop box already or any cloud storage system
already.
For example, I use encfs, and that does a lot of binary modifications again and again.
And it will probably trigger very similar to the de‑pack tool.
Finally, I know we have discussed this several times about Prism and everything, but deep
file analysis is really time consuming, but really it's more time consuming than it is
problematic for themselves.
So that's something that we can use to get around that.
So I got through everything I wanted to say in about 11 minutes.
I wanted to give some special thanks to my friends who encouraged me to do this.
That's all I have to say.
Enjoy your lunches.
(Applause).
>> Hello!
>> You are still speaking.
>> You are late!
>> ZAK BLACHER: No, I'm not.
>> Yes, you are.
>> Do not enjoy your lunches!
>> Don't you move!
>> Got it?
>> ZAK BLACHER: Oh, yeah, this is a fun conference.
>> Yeah!
>> ZAK BLACHER: I forgot about this up here.
>> What do we call this?
Shot the n00b.
Why do we do shot the n00b?
First time speaker.
What else do we need?
>> AUDIENCE MEMBER: Alcohol.
>> There right there.
First time at DEF CON, sir?
>> Yep.
>> All right, come on up.
>> He needs a lot of alcohol!
>> She was sitting next to him.
Is this your girlfriend?
>> This is my wife.
>> All right.
Congratulations.
>> All right.
Here we go.
It's very hard to be chosen to speak at DEF CON.
Very competitive.
So big round of applause for our first‑time speaker.
>> Competitive drinking.
>> ZAK BLACHER: Thanks!
>> All right, thanks a lot.
>> Okay, now you can say you're done.
>> ZAK BLACHER: Okay.
I'm done.
Thank you.
(Applause) I'm going to hyperventilate for a little bit.
>> Why are you all sitting out there?
Go away!
>> AUDIENCE MEMBER: Get the fuck out!