1 00:00:00,125 --> 00:00:02,918 As you can probably tell from the title of this talk, it's 2 00:00:02,918 --> 00:00:04,751 about cloud storage. 3 00:00:04,751 --> 00:00:07,999 I'm going to be covering an API line vulnerability. 4 00:00:07,999 --> 00:00:08,999 I'm Zak. 5 00:00:10,375 --> 00:00:14,999 I'm a student at the University of Waterloo. 6 00:00:15,334 --> 00:00:17,542 I have had an interest in computer security 7 00:00:17,542 --> 00:00:20,667 and applied security for a very long time. 8 00:00:20,999 --> 00:00:24,042 This is my second DEF CON and the first I'm speaking at a DEF CON 9 00:00:24,042 --> 00:00:27,292 or any conference bigger than about 20 people. 10 00:00:27,292 --> 00:00:28,292 So (Applause). 11 00:00:29,626 --> 00:00:30,999 Thanks. 12 00:00:32,501 --> 00:00:33,999 Hopefully I will get that same response 13 00:00:33,999 --> 00:00:35,542 afterwards too. 14 00:00:35,542 --> 00:00:36,667 It remains to be seen. 15 00:00:36,667 --> 00:00:38,876 So I'm giving a talk on cloud storage and when I was 16 00:00:38,876 --> 00:00:40,999 before this talk, I was doing some recon 17 00:00:40,999 --> 00:00:43,751 and speaking to some of my friends and find out what 18 00:00:43,751 --> 00:00:46,000 they use cloud storage for. 19 00:00:46,501 --> 00:00:49,334 A lot of them use it as a USB key replacement. 20 00:00:49,334 --> 00:00:53,999 They share large 10 megabyte files or backups of their documents, 21 00:00:53,999 --> 00:00:56,999 or across several devices. 22 00:00:58,334 --> 00:01:01,918 Really for the most part it replaces USB keys and a lot 23 00:01:01,918 --> 00:01:05,501 of them still street cloud storage systems as the same way 24 00:01:05,501 --> 00:01:07,834 they treat USB keys. 25 00:01:08,167 --> 00:01:11,834 A large contain to throw files into and then delete a few to free 26 00:01:11,834 --> 00:01:14,999 up a little bit of space afterwards. 27 00:01:15,167 --> 00:01:17,501 But one of the cool things about cloud storage systems 28 00:01:17,501 --> 00:01:21,459 is they have many more features than just space providing. 29 00:01:21,626 --> 00:01:24,876 So I have a little chart here. 30 00:01:24,876 --> 00:01:26,167 I don't know if you can see it. 31 00:01:26,167 --> 00:01:28,083 It speaks about some of the additional mechanisms that some 32 00:01:28,083 --> 00:01:32,999 of the cloud storage providers have, like history and backup retention. 33 00:01:34,999 --> 00:01:38,626 So the vulnerability, the main discussion I want to have 34 00:01:38,626 --> 00:01:43,709 with this is the idea that treating files as blocks, filling up a larger box, 35 00:01:43,709 --> 00:01:49,417 doesn't quite represent cloud storage when you have this time dimension. 36 00:01:49,542 --> 00:01:54,999 So if we try and reframe that previous picture, with the as a space time graph, 37 00:01:54,999 --> 00:01:59,709 we can as a Gant chart, really, we have different time intervals 38 00:01:59,709 --> 00:02:03,542 and then by removing files, we can see the life span 39 00:02:03,542 --> 00:02:09,083 of these files stops existing after a certain amount of time. 40 00:02:09,083 --> 00:02:11,125 And then with this type of representation, we can think 41 00:02:11,125 --> 00:02:14,999 about the amount of space we are using as a sliding bar. 42 00:02:14,999 --> 00:02:15,792 At any given time, we are occupying 43 00:02:15,792 --> 00:02:17,999 a different amount of space. 44 00:02:19,292 --> 00:02:21,626 This gives us an interesting sort of mechanism 45 00:02:21,626 --> 00:02:25,083 with which we can recover previously deleted files. 46 00:02:26,167 --> 00:02:30,083 Really what we are talking about, a lot of these cloud systems have 47 00:02:30,083 --> 00:02:32,999 a size limitation, but have a time duration system 48 00:02:32,999 --> 00:02:36,083 for their history backup or retention. 49 00:02:36,667 --> 00:02:39,999 When you have these two independent quota management systems, 50 00:02:39,999 --> 00:02:43,667 you have unlimited storage because you can exploit history 51 00:02:43,667 --> 00:02:47,501 retention to get an additional ounce of space. 52 00:02:47,667 --> 00:02:50,375 Really we are limited by our upload, rather than 53 00:02:50,375 --> 00:02:55,167 the existing cloud system the existing cloud parameters. 54 00:02:58,999 --> 00:03:01,999 So what this tool does, when we are doing an upload 55 00:03:01,999 --> 00:03:04,751 of a large file, we take a large file and cut it 56 00:03:04,751 --> 00:03:07,999 up into several smaller fragments and load these fragments 57 00:03:07,999 --> 00:03:10,999 as different versions of some arbitrarily new file 58 00:03:10,999 --> 00:03:15,083 and then we top it all off with a chunk of zero size. 59 00:03:15,083 --> 00:03:16,584 This way, that our quota mechanism sees this 60 00:03:16,584 --> 00:03:18,209 as a zero file. 61 00:03:18,209 --> 00:03:20,417 They see this as a zero sized file despite having 62 00:03:20,417 --> 00:03:22,501 the history backup. 63 00:03:22,999 --> 00:03:25,999 So retrieval is very easy if we do this process. 64 00:03:26,459 --> 00:03:30,083 We just have to pull all out versions and glue them back together with cat. 65 00:03:31,083 --> 00:03:37,083 Going back to the storage time graph, I used this to represent a file earlier. 66 00:03:37,083 --> 00:03:39,834 Earlier, what we can treat it as is more like this, 67 00:03:39,834 --> 00:03:44,083 where we have different versions of this file that together create that 68 00:03:44,083 --> 00:03:47,250 original file, but are occupied considerably smaller 69 00:03:47,250 --> 00:03:50,083 amounts of space in existence. 70 00:03:50,083 --> 00:03:52,667 So, you know, our account use is actually closer to zero, 71 00:03:52,667 --> 00:03:57,250 when we are looking at it from a different a different time. 72 00:03:57,250 --> 00:03:59,584 So it's a fairly easy idea. 73 00:03:59,584 --> 00:04:01,250 I rolled it into a tool for you guys. 74 00:04:01,250 --> 00:04:03,999 I call this De pack Choppa, running with the whole cloud 75 00:04:03,999 --> 00:04:06,250 enlightenment thing. 76 00:04:06,417 --> 00:04:10,626 It chops up files and packs them and de packs them afterwards. 77 00:04:13,876 --> 00:04:16,167 I created a pluggable is service framework. 78 00:04:16,167 --> 00:04:18,959 And it lets you plug out the API specifics 79 00:04:18,959 --> 00:04:22,876 of the individual cloud utilities. 80 00:04:23,125 --> 00:04:26,584 From this, the tool maintains a storage database, back end 81 00:04:26,584 --> 00:04:30,584 for fragmentation to maintain the history of the maintaining 82 00:04:30,584 --> 00:04:34,250 the history of fragments and the initial files that form 83 00:04:34,250 --> 00:04:36,334 these fragments. 84 00:04:42,417 --> 00:04:46,125 So I can talk all day up here, but you guys want to see 85 00:04:46,125 --> 00:04:48,083 a demo, right? 86 00:04:48,083 --> 00:04:49,459 AUDIENCE MEMBER: Yeah. 87 00:04:49,459 --> 00:04:50,626 ZAK BLACHER: Right? 88 00:04:50,626 --> 00:04:51,626 All right. 89 00:04:52,626 --> 00:04:54,292 Let's see. 90 00:04:58,667 --> 00:05:01,167 So, yeah. 91 00:05:01,459 --> 00:05:04,876 I'm getting a little bit of resolution problems there. 92 00:05:04,876 --> 00:05:05,876 Is that better? 93 00:05:06,292 --> 00:05:07,584 Okay. 94 00:05:07,584 --> 00:05:08,918 So what I'm sorting here. 95 00:05:08,918 --> 00:05:10,959 I don't have anything in this directory. 96 00:05:10,959 --> 00:05:14,626 I'm just showing you, there's nothing up my sleeves. 97 00:05:14,626 --> 00:05:16,417 And I'm creating a 64 megabyte file that I will upload 98 00:05:16,417 --> 00:05:18,083 to the service. 99 00:05:18,834 --> 00:05:21,209 Here's the checksum of it, just stating that 100 00:05:21,209 --> 00:05:24,292 from behind and then let's upload it. 101 00:05:24,542 --> 00:05:27,999 One of the things I'm doing here as sort of a way to you know, one 102 00:05:27,999 --> 00:05:30,292 of the things I'm trying to demonstrate here 103 00:05:30,292 --> 00:05:33,083 is there are ways of circumventing existing detection 104 00:05:33,083 --> 00:05:34,999 mechanisms here. 105 00:05:36,375 --> 00:05:39,751 What I'm doing here, the file size for the individual fragments 106 00:05:39,751 --> 00:05:42,792 is around about 512k, plus or minus 5%. 107 00:05:42,999 --> 00:05:45,417 Try to get around any sort of mechanisms in place 108 00:05:45,417 --> 00:05:48,918 to detect continual overwrites of the same thing. 109 00:05:48,918 --> 00:05:50,999 Now, I will get into this a little bit later. 110 00:05:50,999 --> 00:05:52,542 There's a bunch of different techniques that we can 111 00:05:52,542 --> 00:05:57,501 mask as we are doing this, but for now, it will demonstrate fairly well. 112 00:05:58,250 --> 00:06:02,751 This information is generated from the de pack tool itself. 113 00:06:03,083 --> 00:06:05,250 It's showing you the individual chunks that belong 114 00:06:05,250 --> 00:06:08,209 to this file, and the product upload. 115 00:06:08,626 --> 00:06:09,999 I will use this to compare later on, when I have 116 00:06:09,999 --> 00:06:12,999 the information I'm getting back from the server. 117 00:06:12,999 --> 00:06:15,250 This is all locally generated information. 118 00:06:15,250 --> 00:06:16,959 So we are just about finished. 119 00:06:17,876 --> 00:06:20,209 Yeah, you can see the second to last file, it's about 200k, just 120 00:06:20,209 --> 00:06:23,459 to top it all off and then the last one is the zero size. 121 00:06:23,459 --> 00:06:26,792 You can see I have gone back into this folder. 122 00:06:26,792 --> 00:06:30,459 This checksum I use here, the checksum I use here to act 123 00:06:30,459 --> 00:06:34,125 as the handle on the existing framework takes 124 00:06:34,125 --> 00:06:36,209 up zero size. 125 00:06:36,209 --> 00:06:39,667 So back to where we were. 126 00:06:39,667 --> 00:06:41,375 Now I have deleted that binary and I'm busy reconstructing 127 00:06:41,375 --> 00:06:44,999 the file from the fragments I'm getting back from the server. 128 00:06:45,125 --> 00:06:47,999 So these chunk numbers you see here are the server 129 00:06:47,999 --> 00:06:51,709 is the information provided by the rest API that gives us 130 00:06:51,709 --> 00:06:54,999 the mapping to the individual chucks we are looking 131 00:06:54,999 --> 00:06:56,792 at earlier. 132 00:06:57,459 --> 00:07:00,999 It will see a one to one mapping of the file size we get back here 133 00:07:00,999 --> 00:07:03,292 to the file sizes we sent. 134 00:07:05,250 --> 00:07:06,501 Yeah. 135 00:07:06,584 --> 00:07:10,083 This is specific to Dropbox in this example. 136 00:07:10,083 --> 00:07:13,999 There's no reason it can't be extended to other cloud storage providers. 137 00:07:13,999 --> 00:07:15,792 So I finished downloading it. 138 00:07:15,792 --> 00:07:18,626 It exists there and you can see that the checksums match. 139 00:07:18,626 --> 00:07:20,999 So we can actually use this for storage. 140 00:07:21,167 --> 00:07:22,542 (Applause). 141 00:07:22,959 --> 00:07:27,375 ZAK BLACHER: Thank you. 142 00:07:27,751 --> 00:07:29,918 Thank you. 143 00:07:30,083 --> 00:07:31,918 The tool in the form that I used there is available 144 00:07:31,918 --> 00:07:34,751 on the CDs you guys are getting as part of the packages here but I 145 00:07:34,751 --> 00:07:37,792 will also have the updated version of the code at GitHub at this link, 146 00:07:37,792 --> 00:07:40,292 and you can bug me for it afterwards. 147 00:07:41,626 --> 00:07:43,999 And I wrote it in Python. 148 00:07:47,209 --> 00:07:50,751 For example, we can maintain our own deltas 149 00:07:50,751 --> 00:07:55,999 to map to real changes in the file information rather than faking 150 00:07:55,999 --> 00:07:58,876 it through the API here. 151 00:07:58,876 --> 00:08:01,250 We can do adaptive mangling and use different file names right now 152 00:08:01,250 --> 00:08:03,999 the tool uploads with the get hash, and it uses that 153 00:08:03,999 --> 00:08:06,876 as the anchoring system but there's no reason we have 154 00:08:06,876 --> 00:08:08,417 to use that. 155 00:08:09,751 --> 00:08:12,292 Future work is extending the CLI. 156 00:08:12,292 --> 00:08:14,375 Right now it supports get and put, but, you know, 157 00:08:14,375 --> 00:08:19,292 that's fairly fairly simple functionality to continue working on there. 158 00:08:19,292 --> 00:08:21,417 I also want to get some more modules done. 159 00:08:21,417 --> 00:08:22,999 I looked at some of the other cloud source providers that 160 00:08:22,999 --> 00:08:25,083 have some mechanisms in place to defeat this 161 00:08:25,083 --> 00:08:28,542 but are not particularly rigorous at this time. 162 00:08:28,542 --> 00:08:30,999 Really only drop box works at this stage but we can work on that, 163 00:08:30,999 --> 00:08:32,501 right, guys? 164 00:08:32,709 --> 00:08:34,999 I also want to do some more tuneable options so 165 00:08:34,999 --> 00:08:38,584 that we can look at different ways of automating the process 166 00:08:38,584 --> 00:08:41,542 of generating the file fragments. 167 00:08:41,918 --> 00:08:45,999 In this case, I used a generator to generate 512k chunks, and I had 168 00:08:45,999 --> 00:08:49,999 to overwrite one file but there's no reason we can't use it 169 00:08:49,999 --> 00:08:52,125 to multiple files. 170 00:08:52,125 --> 00:08:54,209 There's a whole bunch of ways we can take depending 171 00:08:54,209 --> 00:08:57,626 on the tuneable objects we want to use. 172 00:08:58,792 --> 00:09:00,999 This wouldn't be a security talk without the implications 173 00:09:00,999 --> 00:09:02,999 of this type of vulnerable. 174 00:09:03,083 --> 00:09:06,751 If we look at the blue team concerns for this, is it's fairly straightforward 175 00:09:06,751 --> 00:09:09,667 to detect this by looking at the constant file size writing and 176 00:09:09,667 --> 00:09:11,709 the time you are starting and the difference 177 00:09:11,709 --> 00:09:13,959 between the Delta uploads. 178 00:09:13,999 --> 00:09:15,959 But, you know, we can deal with this, with generators 179 00:09:15,959 --> 00:09:18,584 by introducing subtle variations in the delays of the uploads 180 00:09:18,584 --> 00:09:21,375 of the different versions of these files. 181 00:09:21,375 --> 00:09:23,334 We can vary the name and the file size and, you know, 182 00:09:23,334 --> 00:09:28,125 that's something we can counteract their initial response to this thing. 183 00:09:28,125 --> 00:09:31,999 Secondly, it's fairly straightforward to ban an API key. 184 00:09:31,999 --> 00:09:34,999 But with the ostensibly, we can request a new one. 185 00:09:34,999 --> 00:09:40,459 We don't limit the available functions or the available tools we can create just 186 00:09:40,459 --> 00:09:43,959 because of one or two bad eggs. 187 00:09:43,959 --> 00:09:46,792 Secondly, or thirdly, the one thing that is fairly evident 188 00:09:46,792 --> 00:09:50,125 is the null caps, the zero sized fragments that make 189 00:09:50,125 --> 00:09:54,209 them take up no space in the internal metrics. 190 00:09:54,626 --> 00:09:56,792 That's a fairly obvious signature. 191 00:09:56,792 --> 00:09:59,083 We can really replace that by using something very small 192 00:09:59,083 --> 00:10:01,292 like a one byte file. 193 00:10:01,667 --> 00:10:04,459 By moving it to one byte, we don't have unlimited space. 194 00:10:09,626 --> 00:10:13,918 One of the concerns this is an issue, having unlimited spaces undermines 195 00:10:13,918 --> 00:10:16,375 their whole business model. 196 00:10:21,584 --> 00:10:25,334 Getting unlimited storage really breaks their financial incentive 197 00:10:25,334 --> 00:10:27,999 for these kinds of things. 198 00:10:27,999 --> 00:10:31,834 Secondly, by going the opposite way, if they break large binary rights, it 199 00:10:31,834 --> 00:10:35,584 will really damage a lot of the existing tools that use drop box 200 00:10:35,584 --> 00:10:39,125 already or any cloud storage system already. 201 00:10:39,417 --> 00:10:42,501 For example, I use encfs, and that does a lot 202 00:10:42,501 --> 00:10:46,709 of binary modifications again and again. 203 00:10:46,709 --> 00:10:49,999 And it will probably trigger very similar to the de pack tool. 204 00:10:50,209 --> 00:10:53,999 Finally, I know we have discussed this several times about Prism 205 00:10:53,999 --> 00:10:57,626 and everything, but deep file analysis is really time consuming, 206 00:10:57,626 --> 00:11:02,918 but really it's more time consuming than it is problematic for themselves. 207 00:11:02,918 --> 00:11:06,083 So that's something that we can use to get around that. 208 00:11:06,417 --> 00:11:09,667 So I got through everything I wanted to say in about 11 minutes. 209 00:11:09,667 --> 00:11:11,999 I wanted to give some special thanks to my friends who encouraged me 210 00:11:11,999 --> 00:11:13,584 to do this. 211 00:11:14,918 --> 00:11:16,999 That's all I have to say. 212 00:11:17,209 --> 00:11:18,459 Enjoy your lunches. 213 00:11:18,459 --> 00:11:19,459 (Applause). 214 00:11:19,459 --> 00:11:20,876 Hello! 215 00:11:20,876 --> 00:11:23,667 You are still speaking. 216 00:11:23,667 --> 00:11:25,999 You are late! 217 00:11:25,999 --> 00:11:29,334 ZAK BLACHER: No, I'm not. 218 00:11:29,334 --> 00:11:30,334 Yes, you are. 219 00:11:30,334 --> 00:11:31,876 Do not enjoy your lunches! 220 00:11:31,876 --> 00:11:32,876 Don't you move! 221 00:11:32,876 --> 00:11:33,876 Got it? 222 00:11:33,876 --> 00:11:41,792 ZAK BLACHER: Oh, yeah, this is a fun conference. 223 00:11:41,792 --> 00:11:42,792 Yeah! 224 00:11:42,792 --> 00:11:44,999 ZAK BLACHER: I forgot about this up here. 225 00:11:44,999 --> 00:11:46,083 What do we call this? 226 00:11:46,125 --> 00:11:48,959 Shot the n00b. 227 00:11:48,959 --> 00:11:50,542 Why do we do shot the n00b? 228 00:11:50,999 --> 00:11:52,959 First time speaker. 229 00:11:53,083 --> 00:11:54,417 What else do we need? 230 00:11:54,417 --> 00:11:55,999 AUDIENCE MEMBER: Alcohol. 231 00:11:55,999 --> 00:11:56,999 There right there. 232 00:11:58,792 --> 00:12:00,999 First time at DEF CON, sir? 233 00:12:00,999 --> 00:12:01,999 Yep. 234 00:12:01,999 --> 00:12:03,083 All right, come on up. 235 00:12:03,083 --> 00:12:05,083 He needs a lot of alcohol! 236 00:12:05,667 --> 00:12:09,083 She was sitting next to him. 237 00:12:09,083 --> 00:12:10,375 Is this your girlfriend? 238 00:12:10,375 --> 00:12:11,459 This is my wife. 239 00:12:11,459 --> 00:12:12,459 All right. 240 00:12:12,459 --> 00:12:13,459 Congratulations. 241 00:12:13,459 --> 00:12:14,459 All right. 242 00:12:14,459 --> 00:12:15,501 Here we go. 243 00:12:15,792 --> 00:12:19,125 It's very hard to be chosen to speak at DEF CON. 244 00:12:19,125 --> 00:12:20,125 Very competitive. 245 00:12:20,999 --> 00:12:34,959 So big round of applause for our first time speaker. 246 00:12:34,959 --> 00:12:36,125 Competitive drinking. 247 00:12:36,125 --> 00:12:37,375 ZAK BLACHER: Thanks! 248 00:12:37,375 --> 00:12:38,751 All right, thanks a lot. 249 00:12:38,751 --> 00:12:40,501 Okay, now you can say you're done. 250 00:12:40,501 --> 00:12:41,626 ZAK BLACHER: Okay. 251 00:12:41,626 --> 00:12:42,626 I'm done. 252 00:12:42,626 --> 00:12:43,626 Thank you. 253 00:12:43,626 --> 00:12:46,542 (Applause) I'm going to hyperventilate for a little bit. 254 00:12:46,542 --> 00:12:48,292 Why are you all sitting out there? 255 00:12:48,292 --> 00:12:49,292 Go away! 256 00:12:49,292 --> 00:12:51,167 AUDIENCE MEMBER: Get the fuck out!