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!