1
00:00:00,000 --> 00:00:03,751
SEAN MALONE: Afternoon, this is HiveMind, we're looking

2
00:00:03,751 --> 00:00:07,999
at distributed file storage using JavaScript botnets.

3
00:00:08,042 --> 00:00:10,000
I am Sean Malone.

4
00:00:10,000 --> 00:00:12,626
Principal security consultant at FusionX.

5
00:00:12,959 --> 00:00:15,000
We are definitely hiring.

6
00:00:15,000 --> 00:00:17,959
FusionX needs a little bit of an introduction though.

7
00:00:17,959 --> 00:00:18,999
So let me tell you a little bit about what we do

8
00:00:18,999 --> 00:00:22,834
of the we do a combination of penetration testing, red teaming,

9
00:00:22,834 --> 00:00:25,959
sophisticated adversary assessments.

10
00:00:25,959 --> 00:00:28,626
Basically, we assess your entire organization, not just

11
00:00:28,626 --> 00:00:32,375
a particular network, system or application.

12
00:00:32,417 --> 00:00:34,000
If that sounds like something you'd be interested in,

13
00:00:34,000 --> 00:00:36,000
hit me up after the talk.

14
00:00:36,709 --> 00:00:39,417
The problem we're looking to solve here

15
00:00:39,417 --> 00:00:44,292
is that sometimes even when using encryption to store sensitive data,

16
00:00:44,292 --> 00:00:46,876
we run into problems.

17
00:00:46,999 --> 00:00:52,501
That problem is that with encryption, the data is still present.

18
00:00:52,501 --> 00:00:54,417
It's simply encrypted.

19
00:00:54,417 --> 00:00:57,999
And if it's encrypted in a way that we can recover it,

20
00:00:57,999 --> 00:01:03,083
then someone else can force us to recover it for them.

21
00:01:03,083 --> 00:01:06,959
Such as a court order or a $5 wrench.

22
00:01:06,999 --> 00:01:10,542
So encryption is not always going to be enough.

23
00:01:10,999 --> 00:01:15,209
So, if we can't simply store the files encrypted on our own systems,

24
00:01:15,209 --> 00:01:17,125
what can we do?

25
00:01:17,626 --> 00:01:19,584
The first thing that comes to mind store the files

26
00:01:19,584 --> 00:01:21,834
on someone else's system.

27
00:01:21,834 --> 00:01:24,999
That way if your system is seized, then the files aren't there.

28
00:01:24,999 --> 00:01:27,250
The problem is that that's usually illegal.

29
00:01:27,501 --> 00:01:33,250
So what I want to do is look at a way to do that with standard functionality

30
00:01:33,250 --> 00:01:37,417
in a way that's at least less illegal.

31
00:01:37,417 --> 00:01:39,083
Mostly legal.

32
00:01:40,083 --> 00:01:44,209
The way we do this is start functionality, no exploits.

33
00:01:44,209 --> 00:01:49,999
Just using tips and tricks and looking at the standard features

34
00:01:49,999 --> 00:01:52,584
in web browsers.

35
00:01:52,626 --> 00:01:57,792
So what I mean by this is that all of the techniques that I'm presenting

36
00:01:57,792 --> 00:02:00,834
here, all of the features that my technique

37
00:02:00,834 --> 00:02:04,584
uses are used in real web applications.

38
00:02:04,626 --> 00:02:06,751
So there's nothing to patch.

39
00:02:06,751 --> 00:02:10,209
Removing these features would break modern web applications.

40
00:02:10,334 --> 00:02:11,999
So that's a great advantage here because this

41
00:02:11,999 --> 00:02:15,792
is something that's going to work for the foreseeable future.

42
00:02:15,792 --> 00:02:18,999
It's not something that is only going to work until some vendor patches

43
00:02:18,999 --> 00:02:21,876
the particular vulnerability.

44
00:02:22,209 --> 00:02:24,083
First, a disclaimer.

45
00:02:24,292 --> 00:02:26,501
This is a research project.

46
00:02:26,501 --> 00:02:29,167
I'm not responsible for what you do with this software,

47
00:02:29,167 --> 00:02:32,626
it's not intended to be used to store critical data

48
00:02:32,626 --> 00:02:35,751
at this point though the concept should be able

49
00:02:35,751 --> 00:02:38,209
to get there eventually.

50
00:02:38,459 --> 00:02:40,501
Also, I'm not a lawyer.

51
00:02:40,501 --> 00:02:42,999
Nothing in here is legal advice and I'm not responsible

52
00:02:42,999 --> 00:02:48,459
for anything legal or illegal that you choose to do with this software.

53
00:02:50,501 --> 00:02:53,999
Web browsers have undergone some significant changes

54
00:02:53,999 --> 00:02:56,999
in the last 15 years or so.

55
00:02:56,999 --> 00:03:00,167
We started off with the most basic form of client side storage or

56
00:03:00,167 --> 00:03:02,292
the browser cookie.

57
00:03:02,292 --> 00:03:05,417
We had JavaScript for data processing and a jacker

58
00:03:05,417 --> 00:03:09,626
or asynchronous JavaScript in XML for that back end client

59
00:03:09,626 --> 00:03:12,292
to server communication.

60
00:03:12,334 --> 00:03:18,125
That's changed recently with the advent of HTML 5 features.

61
00:03:18,125 --> 00:03:22,999
We have all of those older technologies still present in the browser.

62
00:03:22,999 --> 00:03:24,626
But they've all been upgraded.

63
00:03:24,626 --> 00:03:27,626
Now we have web storage to store larger amounts of data

64
00:03:27,626 --> 00:03:29,584
in the browser.

65
00:03:29,584 --> 00:03:33,459
We have web workers who can spin off JavaScript threads that are separate

66
00:03:33,459 --> 00:03:36,999
from the main GUI threads so you can do more processing

67
00:03:36,999 --> 00:03:41,459
without gumming up your application, and we have web sockets that create

68
00:03:41,459 --> 00:03:44,501
a persistent socket from the client browser back

69
00:03:44,501 --> 00:03:46,375
to the server.

70
00:03:47,125 --> 00:03:50,876
So the end result here is that a web browser is basically

71
00:03:50,876 --> 00:03:54,542
a computer program that will communicate back to my server,

72
00:03:54,542 --> 00:03:59,918
execute any arbitrary code that I hand it and store any arbitrary data that I ask it

73
00:03:59,918 --> 00:04:01,375
to store.

74
00:04:01,626 --> 00:04:03,542
Sounds like a botnet node, right?

75
00:04:05,125 --> 00:04:07,584
You might ask what about sandboxing.

76
00:04:07,918 --> 00:04:10,959
Doesn't that make it impossible to access the system data,

77
00:04:10,959 --> 00:04:13,542
execute code on the system.

78
00:04:13,542 --> 00:04:15,209
Yes, it does that for the purpose of some

79
00:04:15,209 --> 00:04:18,375
of the browser security improvements but the short answer

80
00:04:18,375 --> 00:04:20,959
is I don't care about that.

81
00:04:20,959 --> 00:04:21,999
I don't need to do anything unite

82
00:04:21,999 --> 00:04:25,626
outside of the normal browser security manual.

83
00:04:25,626 --> 00:04:27,792
I'm simply running code in the context

84
00:04:27,792 --> 00:04:32,792
of the domain that runs the code and accessing data that I've stored

85
00:04:32,792 --> 00:04:37,459
on that same domain so it's all on the same origin.

86
00:04:37,459 --> 00:04:40,542
It's all within the browser security policy.

87
00:04:40,542 --> 00:04:43,167
Again, these are features, not bugs.

88
00:04:44,751 --> 00:04:48,751
So let's look at what it takes to actually build a botnet on top

89
00:04:48,751 --> 00:04:50,751
of web browsers.

90
00:04:50,792 --> 00:04:56,125
The first step in building any botnet is going to be the node infestation.

91
00:04:56,125 --> 00:04:59,584
How do we actually get our code running on the node.

92
00:04:59,584 --> 00:05:02,751
How do we take control of that particular node.

93
00:05:02,999 --> 00:05:07,542
The first most obvious technique is to simply use a site that you own.

94
00:05:07,542 --> 00:05:09,209
If you own a site that's getting

95
00:05:09,209 --> 00:05:13,959
a thousand hits every 5 minutes you have the capable of executing

96
00:05:13,959 --> 00:05:17,999
a code you want on web browsers every minute.

97
00:05:17,999 --> 00:05:19,167
That's a lot of power.

98
00:05:19,167 --> 00:05:21,999
Most sites don't do anything with that.

99
00:05:21,999 --> 00:05:24,250
But there's definitely the potential there.

100
00:05:24,792 --> 00:05:27,999
That's when there's a compromised site so any time there's

101
00:05:27,999 --> 00:05:32,083
a consistent cross site vulnerability where we can store a piece

102
00:05:32,083 --> 00:05:36,459
of JavaScript on a site that is executed every time somebody visits

103
00:05:36,459 --> 00:05:39,792
that particular site, we can include every visitor

104
00:05:39,792 --> 00:05:43,542
to that compromised site in our botnet by adding that piece

105
00:05:43,542 --> 00:05:47,918
of persistent JavaScript onto the compromised site.

106
00:05:48,250 --> 00:05:50,375
URL shorteners are fun one.

107
00:05:50,375 --> 00:05:53,459
Normally you have a URL shortener that simply redirects

108
00:05:53,459 --> 00:05:55,375
to the target.

109
00:05:55,375 --> 00:05:59,167
But what if we simply load a full screen iFrame showing

110
00:05:59,167 --> 00:06:02,999
the intended URL and in the background we have

111
00:06:02,999 --> 00:06:07,959
a second iFrame that is running our botnet code?

112
00:06:08,334 --> 00:06:10,792
You can use ad distribution networks.

113
00:06:10,792 --> 00:06:12,999
There was a great talk at Blackhat this year

114
00:06:12,999 --> 00:06:18,792
about various ad distribution networks where instead of distributing an image,

115
00:06:18,792 --> 00:06:22,999
you can actually give them an iFrame source and they'll put

116
00:06:22,999 --> 00:06:29,334
an iFrame on the target pages that then sends traffic back to your site.

117
00:06:29,334 --> 00:06:32,584
The intent is to use this for sort of SEO page rank type things but,

118
00:06:32,584 --> 00:06:36,542
if you have people going to your site, you can make them a member

119
00:06:36,542 --> 00:06:38,459
of your botnet.

120
00:06:38,999 --> 00:06:42,250
My personal favorite is the anonymous proxy server.

121
00:06:42,459 --> 00:06:46,083
I stood up an open anonymous proxy listening

122
00:06:46,083 --> 00:06:50,542
on port 80, excuse me, on port 8080.

123
00:06:50,999 --> 00:06:53,167
Stood this up a few weeks ago.

124
00:06:53,167 --> 00:06:54,292
Let it just sit there.

125
00:06:54,292 --> 00:06:55,542
Didn't advertise this.

126
00:06:55,542 --> 00:06:58,584
Didn't solicit traffic at all and right now it's getting hit

127
00:06:58,584 --> 00:07:03,083
by about 20,000 unique IP addresses every 10 minutes.

128
00:07:03,501 --> 00:07:06,125
(Laughter) This is completely unsolicited traffic,

129
00:07:06,125 --> 00:07:10,334
I never promised to do anything with this traffic.

130
00:07:10,334 --> 00:07:13,876
I never promised to return any particular content.

131
00:07:13,876 --> 00:07:15,542
I never promised that the page I return

132
00:07:15,542 --> 00:07:18,876
is the actual page they request.

133
00:07:18,876 --> 00:07:22,792
Usually it looks a lot like the page they request but it also has

134
00:07:22,792 --> 00:07:24,999
an iFrame in it.

135
00:07:24,999 --> 00:07:28,501
So it's another great way to build a botnet very easily

136
00:07:28,501 --> 00:07:30,751
and very quickly.

137
00:07:31,918 --> 00:07:36,417
Command an control is done through the HTML 5 iSockets this

138
00:07:36,417 --> 00:07:42,501
is through the official working group publication on web sockets.

139
00:07:43,292 --> 00:07:46,792
To allow bidirectional communication with server side processes,

140
00:07:46,792 --> 00:07:50,999
that could have been written with botnet communication in mind.

141
00:07:50,999 --> 00:07:54,834
That's exactly what you want to do for your command and control channel.

142
00:07:55,459 --> 00:07:57,584
When that doesn't work, you should always have a way

143
00:07:57,584 --> 00:07:59,375
to fall back to Ajax.

144
00:07:59,626 --> 00:08:02,667
Older browsers don't support Ajax and sometimes when you're going

145
00:08:02,667 --> 00:08:05,999
through proxies and such, web sockets and proxies don't play

146
00:08:05,999 --> 00:08:09,709
nicely so it's always good to have that additional fall back there so

147
00:08:09,709 --> 00:08:12,083
you don't lose your nodes.

148
00:08:12,999 --> 00:08:17,083
Data storage is done through HTML 5 web storage.

149
00:08:17,083 --> 00:08:21,334
Again a quote through web application, the quote I like is web applications may

150
00:08:21,334 --> 00:08:24,876
wish to store megabytes of user data.

151
00:08:24,876 --> 00:08:28,792
What they really mean is megabytes of application data.

152
00:08:28,792 --> 00:08:31,459
Megabytes of whatever the application server decides

153
00:08:31,459 --> 00:08:34,167
to push down to the client.

154
00:08:34,167 --> 00:08:36,999
So I'm making that megabytes of my data being stored

155
00:08:36,999 --> 00:08:40,501
on all of these different browser nodes.

156
00:08:41,751 --> 00:08:44,501
The back end is a Ruby on Rails application

157
00:08:44,501 --> 00:08:47,999
with a my SQL database with the active record database

158
00:08:47,999 --> 00:08:50,083
extraction layer.

159
00:08:50,626 --> 00:08:55,959
In addition, I'm running a Redis certificator key value storage

160
00:08:55,959 --> 00:09:00,999
that has nice features for what we're doing here.

161
00:09:01,083 --> 00:09:03,999
Redis by default has persistence.

162
00:09:03,999 --> 00:09:08,125
It runs to disk, but you can disable that, meaning when the power is pulled,

163
00:09:08,125 --> 00:09:10,999
the Redis values are gone.

164
00:09:10,999 --> 00:09:14,626
And you can also expire particular keys.

165
00:09:14,626 --> 00:09:17,999
So, say you're uploading a file and splitting it into blocks.

166
00:09:17,999 --> 00:09:20,751
If those blocks temporarily live in Redis, you can set

167
00:09:20,751 --> 00:09:25,667
a key and those blocks disappear after a particular time.

168
00:09:25,667 --> 00:09:30,083
It's a great way to check for a time to live for all the nodes in the blocks

169
00:09:30,083 --> 00:09:32,999
for all the different files.

170
00:09:33,167 --> 00:09:38,999
So that's what it takes to build a JavaScript botnet.

171
00:09:38,999 --> 00:09:40,792
We're going to be using this JavaScript botnet

172
00:09:40,792 --> 00:09:42,709
for data storage.

173
00:09:42,709 --> 00:09:46,083
But there's definitely more we can do with this.

174
00:09:46,334 --> 00:09:50,417
Other fun botnet uses would be network scanning, simply checking

175
00:09:50,417 --> 00:09:53,334
to see what ports are open.

176
00:09:53,334 --> 00:09:55,999
And again all of this is come from your nodes.

177
00:09:56,083 --> 00:09:57,999
This does show as coming from a source IP address

178
00:09:57,999 --> 00:10:00,501
at your command and control server.

179
00:10:00,999 --> 00:10:05,999
D DOS attacks are another fun one and data processing with web workers,

180
00:10:05,999 --> 00:10:10,083
anything you can break up into a relatively discrete task you

181
00:10:10,083 --> 00:10:13,667
can push down to these nodes and have the nodes do

182
00:10:13,667 --> 00:10:19,751
all the heavy lifting for you, so long as you can write it in JavaScript.

183
00:10:19,959 --> 00:10:23,501
JavaScript is not going to be nearly as efficient in writing it

184
00:10:23,501 --> 00:10:24,876
in something like C.

185
00:10:24,876 --> 00:10:29,417
But when you consider you can spin off multiple threads so you can have

186
00:10:29,417 --> 00:10:33,876
four different threads running in four different cores if your node

187
00:10:33,876 --> 00:10:37,167
is a quad core system and if you can do this on, say,

188
00:10:37,167 --> 00:10:41,999
a persistent cross site scripting vulnerability on a popular viral video

189
00:10:41,999 --> 00:10:46,375
or something, that's a lot of processing power there.

190
00:10:46,459 --> 00:10:47,999
And it's free.

191
00:10:50,792 --> 00:10:53,959
Now we have the botnet, let's look at what it takes to actually build

192
00:10:53,959 --> 00:10:56,501
a file system on top of that botnet.

193
00:10:56,584 --> 00:10:58,999
First, a few definitions here.

194
00:10:59,334 --> 00:11:03,959
A file block is what I'm using to refer to a piece of file that has

195
00:11:03,959 --> 00:11:06,250
a set maximum size.

196
00:11:06,667 --> 00:11:11,083
A file is going to be made up of multiple file blocks.

197
00:11:11,250 --> 00:11:13,501
A node is simply any web browser that's

198
00:11:13,501 --> 00:11:15,876
a member of the botnet.

199
00:11:15,959 --> 00:11:18,626
And the server is the central command

200
00:11:18,626 --> 00:11:23,083
and control server that also serves as sort of the phone book

201
00:11:23,083 --> 00:11:25,209
for these files.

202
00:11:25,209 --> 00:11:27,292
It's directory of what files have been uploaded

203
00:11:27,292 --> 00:11:30,876
and where all these different files live.

204
00:11:33,334 --> 00:11:36,375
So when we're storing the file, we upload the file

205
00:11:36,375 --> 00:11:40,417
through web application just like any other web application and it

206
00:11:40,417 --> 00:11:44,125
is going to need to live on the server for a very short period

207
00:11:44,125 --> 00:11:47,999
of time while we execute the following steps.

208
00:11:48,125 --> 00:11:52,959
We break this file into the name, the MIME type and the data.

209
00:11:53,834 --> 00:11:56,999
We take all of this and put it into basically,

210
00:11:56,999 --> 00:12:00,542
a JSON encoding so it's a simple string at that point

211
00:12:00,542 --> 00:12:02,751
and encrypt that.

212
00:12:02,751 --> 00:12:05,209
And that and this is just a simple additional step

213
00:12:05,209 --> 00:12:08,501
of AES encryption so that with we push these blocks

214
00:12:08,501 --> 00:12:11,999
down to the nodes, the nodes can't see the actual data

215
00:12:11,999 --> 00:12:13,751
in the file.

216
00:12:14,459 --> 00:12:16,876
The end result is the encrypted data which

217
00:12:16,876 --> 00:12:18,999
is the basic C4 string.

218
00:12:18,999 --> 00:12:23,626
We split that into a bunch of different file blocks that simply take

219
00:12:23,626 --> 00:12:30,667
the first 1,024 characters, pull those off into a block and then the next 1,024.

220
00:12:30,834 --> 00:12:35,999
All these elements are tuneable here so there's no particular reason that I'm

221
00:12:35,999 --> 00:12:39,250
using 1,024 depending on the particular file and

222
00:12:39,250 --> 00:12:42,792
the reliability of the nodes, you may want smaller

223
00:12:42,792 --> 00:12:45,083
or larger file sizes.

224
00:12:45,083 --> 00:12:49,292
Sounds like it's time for a quick break (Applause.) What's

225
00:12:49,292 --> 00:12:51,375
this called?

226
00:12:51,876 --> 00:12:55,083
Shot the n00b.

227
00:12:55,501 --> 00:13:00,167
It's really hard to get accepted for a talk here at DEF CON.

228
00:13:00,167 --> 00:13:03,167
So congratulations to our new speaker, very competitive.

229
00:13:06,083 --> 00:13:07,250
All right.

230
00:13:07,250 --> 00:13:08,999
I need someone from the audience.

231
00:13:31,751 --> 00:13:32,999
All right.

232
00:13:32,999 --> 00:13:35,584
So our first time DEF CON attendees and speakers.

233
00:13:42,417 --> 00:13:43,792
(cheers and applause).

234
00:13:43,792 --> 00:13:44,999
Paul had a rough night.

235
00:13:44,999 --> 00:13:46,792
Not doing well.

236
00:13:54,709 --> 00:13:56,083
All right.

237
00:13:56,083 --> 00:13:58,459
(Applause)    Come on, only three shots to go.

238
00:13:58,459 --> 00:13:59,459
Oh, God.

239
00:13:59,667 --> 00:14:01,999
Three shots this hour.

240
00:14:04,250 --> 00:14:07,501
You can just stay there for the rest of the talk if you need to.

241
00:14:11,250 --> 00:14:12,999
Oh, shit.

242
00:14:12,999 --> 00:14:14,083
There's people here.

243
00:14:14,083 --> 00:14:19,999
SEAN MALONE: All right.

244
00:14:20,250 --> 00:14:25,667
So we now have file blocks from our uploaded file.

245
00:14:26,417 --> 00:14:29,999
The next step is storing those blocks in our botnet.

246
00:14:29,999 --> 00:14:34,083
B1 represents a particular block 1 from our uploaded file that is living

247
00:14:34,083 --> 00:14:35,999
on the server.

248
00:14:36,459 --> 00:14:38,999
We're going to pull in a certain number of nodes

249
00:14:38,999 --> 00:14:40,999
from our botnets.

250
00:14:40,999 --> 00:14:42,167
We just randomly pick a certain number

251
00:14:42,167 --> 00:14:46,834
of nodes that have checked in with us in the last minute or so.

252
00:14:46,834 --> 00:14:48,709
So we know that they're online.

253
00:14:48,999 --> 00:14:53,125
We push this block down to the nodes there.

254
00:14:53,417 --> 00:14:55,999
And so now the block lives on the nodes and does not live

255
00:14:55,999 --> 00:14:57,959
on the server.

256
00:14:57,959 --> 00:15:00,459
The server keeps track of which nodes have that particular

257
00:15:00,459 --> 00:15:03,918
block and it keeps track of the check sum for the block

258
00:15:03,918 --> 00:15:07,459
but it does not keep the block data itself.

259
00:15:07,918 --> 00:15:11,918
So now this is going to be a very transient botnet.

260
00:15:11,918 --> 00:15:15,667
As nodes come and leave, these particular nodes may only be

261
00:15:15,667 --> 00:15:18,999
online for another few minutes.

262
00:15:18,999 --> 00:15:20,876
Maybe even another 30 seconds.

263
00:15:20,876 --> 00:15:22,083
So what we're doing is we do

264
00:15:22,083 --> 00:15:26,250
a constant heartbeat where every 5 or 10 seconds, depending

265
00:15:26,250 --> 00:15:30,709
on how you have this tuned, the nodes are going to be sending

266
00:15:30,709 --> 00:15:34,792
up a heartbeat where they basically check in and say hey,

267
00:15:34,792 --> 00:15:39,792
I'm a node, I'm still online, my node ID, here is the ID and check sum

268
00:15:39,792 --> 00:15:45,083
for each block that I have stored in my browser local storage.

269
00:15:45,292 --> 00:15:48,083
So eventually some of these are going to go offline or

270
00:15:48,083 --> 00:15:51,501
the data is going to be corrupted either intentionally

271
00:15:51,501 --> 00:15:53,792
are unintentionally.

272
00:15:53,792 --> 00:15:56,334
We have to keep in mind we can't trust the nodes here.

273
00:15:56,751 --> 00:16:00,999
Somebody running that node could be intentionally modifying

274
00:16:00,999 --> 00:16:06,083
the data So once the number of live confirmed good nodes drops

275
00:16:06,083 --> 00:16:10,999
below a certain value, we then replicate, we pull in the set

276
00:16:10,999 --> 00:16:16,209
of new nodes that do not currently have this block.

277
00:16:16,334 --> 00:16:18,542
We take the the server sends a query

278
00:16:18,542 --> 00:16:22,542
down to the existing good nodes, pulls that block back

279
00:16:22,542 --> 00:16:27,375
up to the server and distributes it to the new nodes so we're back

280
00:16:27,375 --> 00:16:32,417
up so that safe level of replication to make sure that we don't lose

281
00:16:32,417 --> 00:16:34,209
that block.

282
00:16:34,501 --> 00:16:37,209
We have to go through the server.

283
00:16:37,209 --> 00:16:39,999
We can't do this in a strict peer to peer fashion

284
00:16:39,999 --> 00:16:44,667
because JavaScript can't actually open a port from within a browser

285
00:16:44,667 --> 00:16:48,250
and listen for an incoming connection.

286
00:16:48,459 --> 00:16:50,083
From my perspective, it would be good if we could,

287
00:16:50,083 --> 00:16:52,959
but it's not such a great security move.

288
00:16:54,459 --> 00:16:57,459
Retrieving a block looks very similar.

289
00:16:57,459 --> 00:17:01,999
The server simply sends out a query to all of the nodes containing

290
00:17:01,999 --> 00:17:06,501
a particular block saying hey, please send me this node and

291
00:17:06,501 --> 00:17:10,626
the node sends it back up to the server.

292
00:17:10,959 --> 00:17:13,501
All of the nodes will send it back up.

293
00:17:13,501 --> 00:17:15,209
The server does a check sum verification

294
00:17:15,209 --> 00:17:19,083
on the server side to make sure that what it's getting back

295
00:17:19,083 --> 00:17:21,999
is what was actually stored.

296
00:17:21,999 --> 00:17:27,876
And then it stores that temporarily in the Reddis data store.

297
00:17:27,999 --> 00:17:32,876
And it puts it in there with a expiration of, say, 20 seconds.

298
00:17:32,876 --> 00:17:36,083
So all the blocks are going to be requested and they're stored

299
00:17:36,083 --> 00:17:40,667
locally in memory on the server for that time to live.

300
00:17:41,959 --> 00:17:44,999
This lets us rebuild the file now.

301
00:17:44,999 --> 00:17:48,209
So we've requested all of these blocks back from the nodes.

302
00:17:48,584 --> 00:17:50,751
We simply concatenate them.

303
00:17:51,334 --> 00:17:54,834
And then rebuild that into encrypted data.

304
00:17:54,999 --> 00:17:59,083
And the password is provided that the point by the user.

305
00:17:59,125 --> 00:18:02,626
And the decryption is then done providing us

306
00:18:02,626 --> 00:18:07,876
with the name, the MIME type and the actual file data.

307
00:18:07,918 --> 00:18:11,834
Rebuild that into a particular file and provide it as a download

308
00:18:11,834 --> 00:18:13,626
to the user.

309
00:18:13,999 --> 00:18:16,999
And the user is able to download it from the web application and

310
00:18:16,999 --> 00:18:20,626
from the user's perspective, ones all of this is set up and running,

311
00:18:20,626 --> 00:18:22,542
it's very simple.

312
00:18:22,542 --> 00:18:26,209
It's provide a file and a password, upload the file, come back later,

313
00:18:26,209 --> 00:18:30,584
provide that password, download the file and have the file back

314
00:18:30,584 --> 00:18:32,626
on your system.

315
00:18:32,999 --> 00:18:34,999
But this file meantime has been distributed

316
00:18:34,999 --> 00:18:38,083
across all these different nodes.

317
00:18:38,083 --> 00:18:41,834
So getting back to where we started this talk, we want

318
00:18:41,834 --> 00:18:47,083
to do this so that that file is not living on the server itself.

319
00:18:47,083 --> 00:18:52,083
So, when everything goes wrong, here's what happens.

320
00:18:52,501 --> 00:18:55,083
Pick your favorite three letter agency.

321
00:18:55,626 --> 00:18:58,083
They come in and seize this server.

322
00:18:58,083 --> 00:19:00,999
They've heard that you're storing some sort of data that they want

323
00:19:00,999 --> 00:19:02,876
to know about.

324
00:19:03,167 --> 00:19:06,667
What happens when they seize the server, the server goes off line

325
00:19:06,667 --> 00:19:09,083
and the nodes go offline.

326
00:19:09,083 --> 00:19:11,876
They're no longer going to the command and control.

327
00:19:13,334 --> 00:19:16,999
The block is going to fail because the nodes are going

328
00:19:16,999 --> 00:19:20,876
off line because they're all going off line.

329
00:19:20,876 --> 00:19:24,918
The server isn't getting that heartbeat, the blocks aren't be replicated

330
00:19:24,918 --> 00:19:26,792
to new nodes.

331
00:19:26,959 --> 00:19:29,959
The result is that the blocks are lost.

332
00:19:29,999 --> 00:19:33,626
And when those blocks are lost, the server no longer has

333
00:19:33,626 --> 00:19:37,083
a correct phone book, the phone book for those blocks

334
00:19:37,083 --> 00:19:39,083
is out of date.

335
00:19:39,584 --> 00:19:42,751
It doesn't know where to find those blocks if you want

336
00:19:42,751 --> 00:19:45,999
to go back and download that file.

337
00:19:45,999 --> 00:19:48,999
So the end result is that the files are unrecoverable.

338
00:19:49,083 --> 00:19:52,375
Now, let me be clear on what I mean by unrecoverable here.

339
00:19:52,375 --> 00:19:56,626
It's practically speaking, it's not feasible to recover the file.

340
00:19:56,709 --> 00:20:00,000
It is definitely possible to go out and seize all of the nodes or

341
00:20:00,000 --> 00:20:04,792
at least the critical mass of the nodes in the botnet but that's going to be

342
00:20:04,792 --> 00:20:08,125
at least in order of magnitude more difficult than simply

343
00:20:08,125 --> 00:20:11,999
seizing a file and getting a court order for or seizing a server

344
00:20:11,999 --> 00:20:15,709
and getting a court order for the owner to decrypt the data

345
00:20:15,709 --> 00:20:17,584
on that server.

346
00:20:17,584 --> 00:20:22,834
It's also possible to poison the botnet by injecting if you're part

347
00:20:22,834 --> 00:20:26,250
of this three letter agency, you inject enough

348
00:20:26,250 --> 00:20:30,292
of your own nodes deliberately into this botnet, log

349
00:20:30,292 --> 00:20:36,999
all the block data and then rebuild the file after you seize the server.

350
00:20:36,999 --> 00:20:38,999
You have the additional layer of encryption here

351
00:20:38,999 --> 00:20:42,167
but as we talked about sometimes that's not enough.

352
00:20:42,167 --> 00:20:45,501
So the only real protection that you have against this

353
00:20:45,501 --> 00:20:49,209
is to have a sufficiently large botnet that it would

354
00:20:49,209 --> 00:20:52,709
be difficult to seize every node.

355
00:20:52,709 --> 00:20:54,876
There's also a certain element of security

356
00:20:54,876 --> 00:20:58,876
through obscurity here where you have to know that this is how

357
00:20:58,876 --> 00:21:03,292
the files are being stored before the server is seized.

358
00:21:03,292 --> 00:21:06,083
You can't go back afterwards and inject nodes once

359
00:21:06,083 --> 00:21:09,999
the server has gone offline because those blocks can't be

360
00:21:09,999 --> 00:21:14,125
recovered in order to be replicated to your nodes Obviously,

361
00:21:14,125 --> 00:21:18,083
if the server itself is compromised and I mean compromised

362
00:21:18,083 --> 00:21:20,375
instead of seized.

363
00:21:20,375 --> 00:21:23,959
So, if that 3 letter agency is able to access the server

364
00:21:23,959 --> 00:21:27,459
without the server going off line, they can issue

365
00:21:27,459 --> 00:21:33,083
the rebuild command and intercept the file on the server itself.

366
00:21:33,083 --> 00:21:36,250
So there are definitely limitations to be aware of.

367
00:21:36,417 --> 00:21:38,792
But there's always going to be that security usability

368
00:21:38,792 --> 00:21:40,417
tradeoff here.

369
00:21:40,417 --> 00:21:44,999
And I think that what we have here provides a drastic increase

370
00:21:44,999 --> 00:21:49,459
in security in that it is significantly more difficult

371
00:21:49,459 --> 00:21:55,999
to recover the file if you're looking at a server seizure situation.

372
00:21:56,918 --> 00:22:00,999
But it's still very usable from the end user perspective.

373
00:22:03,959 --> 00:22:07,667
There's interesting illegal unanswered questions here.

374
00:22:08,999 --> 00:22:14,417
I have my own personal opinions on these but I think there's still a lot

375
00:22:14,417 --> 00:22:16,751
of unknowns here.

376
00:22:16,999 --> 00:22:19,959
The first is this legal?

377
00:22:19,959 --> 00:22:22,083
I'm calling it mostly legal.

378
00:22:22,083 --> 00:22:24,918
There are definitely legal ways to build the botnet such

379
00:22:24,918 --> 00:22:28,501
as if somebody's going to a site that you own.

380
00:22:28,501 --> 00:22:31,999
But is the very act of storing a significant amount

381
00:22:31,999 --> 00:22:36,292
of data that's unnecessary for the functionality of the site so

382
00:22:36,292 --> 00:22:39,667
the user's intent was not to download that data,

383
00:22:39,667 --> 00:22:45,751
is this legitimate or does that constitute unauthorized use of a computer.

384
00:22:45,959 --> 00:22:49,999
And the same question for bandwidth and processing power.

385
00:22:50,999 --> 00:22:54,375
Any time we're doing all that heartbeat to block traffic,

386
00:22:54,375 --> 00:22:58,501
we're using bandwidth and processing power as well.

387
00:22:58,501 --> 00:23:02,667
This is even more true if we're doing an actual data processing botnet

388
00:23:02,667 --> 00:23:07,292
with web workers, bandwidth is going to be even more true if we're,

389
00:23:07,292 --> 00:23:11,459
say, conducting some sort of high traffic application using

390
00:23:11,459 --> 00:23:13,250
those nodes.

391
00:23:13,999 --> 00:23:17,751
I look at this and say you know, this sounds

392
00:23:17,751 --> 00:23:21,959
like an animated flash advertisement.

393
00:23:21,959 --> 00:23:25,584
If you go out to a particular site and they push

394
00:23:25,584 --> 00:23:31,459
down a flash advertisement, it's additional bandwidth when that ad

395
00:23:31,459 --> 00:23:33,876
is pushed down.

396
00:23:33,876 --> 00:23:38,501
It's additional storage in the browser storage and additional

397
00:23:38,501 --> 00:23:40,999
browsing power.

398
00:23:40,999 --> 00:23:42,834
So we're talking about more a difference in quantity

399
00:23:42,834 --> 00:23:44,918
as opposed to quality.

400
00:23:45,083 --> 00:23:50,125
My opinion is that legally it's acceptable because somebody did deliberately go

401
00:23:50,125 --> 00:23:53,999
to that site and, when you go to the site, there's sort

402
00:23:53,999 --> 00:23:58,876
of an implicit assumption that you're going to download and execute

403
00:23:58,876 --> 00:24:03,459
in your browser whatever that Web site gives to you.

404
00:24:03,459 --> 00:24:06,083
There's not ap opt infor each and every component.

405
00:24:06,083 --> 00:24:08,999
But it is unanswered.

406
00:24:08,999 --> 00:24:11,334
I'm not aware of legal precedent in this area.

407
00:24:12,167 --> 00:24:15,999
From the other side, what if you're storing data

408
00:24:15,999 --> 00:24:19,918
without encryption or without any form of encoding

409
00:24:19,918 --> 00:24:23,751
and so it turns up in a forensic search of the one

410
00:24:23,751 --> 00:24:25,792
of the nodes.

411
00:24:25,792 --> 00:24:27,250
So somebody is running their web browser,

412
00:24:27,250 --> 00:24:31,083
happens to become a member of the botnet, you push down data,

413
00:24:31,083 --> 00:24:35,459
if their systems later analyze forensically and this illegal content

414
00:24:35,459 --> 00:24:40,709
shows up on their system, that's going to look pretty bad for them.

415
00:24:40,876 --> 00:24:45,125
So are you responsible for data that a site that you deliberately

416
00:24:45,125 --> 00:24:49,125
went to loaded a hidden iFrame, pushed down that data

417
00:24:49,125 --> 00:24:54,292
on to your computer, are you responsible for that data?

418
00:24:54,751 --> 00:24:56,083
I don't know.

419
00:24:57,999 --> 00:24:59,417
Demo time.

420
00:25:06,999 --> 00:25:12,834
So we'll start off showing the node side of things.

421
00:25:12,876 --> 00:25:14,626
This is my personal Web site.

422
00:25:14,626 --> 00:25:17,834
I'm loading it through this proxy here.

423
00:25:17,834 --> 00:25:20,834
I've got it running with foxy proxy.

424
00:25:20,999 --> 00:25:25,918
And if we look at the source for the site, most of this is normal source

425
00:25:25,918 --> 00:25:30,792
but down at the bottom we've got this hidden iFrame.

426
00:25:30,999 --> 00:25:34,167
This is a simple engine X proxy and there's a rule

427
00:25:34,167 --> 00:25:39,292
in there that simply says do a find and replace on the body content

428
00:25:39,292 --> 00:25:44,876
of the response and replace that slash body tag with the iFrame and then

429
00:25:44,876 --> 00:25:47,209
the slash body tag.

430
00:25:47,209 --> 00:25:50,584
It's really simple and efficient and it pushes out iFrames

431
00:25:50,584 --> 00:25:53,709
to thousands of different nodes.

432
00:25:54,999 --> 00:25:59,918
On the console side of things, we see all these different requests

433
00:25:59,918 --> 00:26:02,375
going back and forth.

434
00:26:02,375 --> 00:26:04,083
The Check queue and I've had this fall back to AJAX

435
00:26:04,083 --> 00:26:07,083
because we're going through the proxy.

436
00:26:07,751 --> 00:26:12,083
It's easier to see because the fire bugs haven't caught

437
00:26:12,083 --> 00:26:16,125
up with the persistent web connections.

438
00:26:16,501 --> 00:26:20,584
So these post requests for check queue are basically saying

439
00:26:20,584 --> 00:26:23,083
anything I need to do?

440
00:26:23,083 --> 00:26:25,083
Any blocks you need me to store?

441
00:26:25,167 --> 00:26:30,083
Any blocks that you need me to send back to the server.

442
00:26:31,999 --> 00:26:37,584
So the heartbeat, let me see if I can grab one

443
00:26:37,584 --> 00:26:42,083
of these let me jump back up.

444
00:26:49,834 --> 00:26:54,834
The post data here is simply the block ID, that's that file block

445
00:26:54,834 --> 00:26:59,209
and UID and the MD5 check sum for each of the file blocks,

446
00:26:59,209 --> 00:27:05,209
so these are blocks that are currently being stored in this node.

447
00:27:05,459 --> 00:27:08,999
So it does that heartbeat every so often to just let it know, hey, I'm still here,

448
00:27:08,999 --> 00:27:12,334
these are the blocks, these are the check sums.

449
00:27:12,918 --> 00:27:17,584
However, if I close down firebug, you see my pretty face

450
00:27:17,584 --> 00:27:20,292
and no traffic there.

451
00:27:20,501 --> 00:27:24,834
So it's all completely transparent in the background.

452
00:27:27,709 --> 00:27:31,501
Here's what the C2 server interface looks like.

453
00:27:31,501 --> 00:27:33,792
Again, this is a Ruby on Rails application.

454
00:27:33,834 --> 00:27:35,083
We've got a simple interface showing

455
00:27:35,083 --> 00:27:37,999
the files that have been uploaded.

456
00:27:38,250 --> 00:27:41,876
And there's a separate page here for the nodes.

457
00:27:41,876 --> 00:27:43,792
So this is a list of nodes that have been active

458
00:27:43,792 --> 00:27:45,999
within the last minute.

459
00:27:46,209 --> 00:27:48,375
In order to retain a little bit more control

460
00:27:48,375 --> 00:27:51,999
over this particular demonstration, I'm not having this run

461
00:27:51,999 --> 00:27:54,999
with thousands of different nodes.

462
00:27:54,999 --> 00:27:58,999
This is just from a few IP addresses and systems that I control here.

463
00:27:59,209 --> 00:28:01,292
The last updated time is the last time we heard

464
00:28:01,292 --> 00:28:03,417
from the node there.

465
00:28:03,751 --> 00:28:08,626
The UID is something we store in a cookie on the node to keep track

466
00:28:08,626 --> 00:28:12,584
of which node is which and we correspondingly use that

467
00:28:12,584 --> 00:28:16,626
in the Reddis data store for tracking which blocks live

468
00:28:16,626 --> 00:28:18,709
on which nodes.

469
00:28:19,999 --> 00:28:23,792
So let's take a look at what it takes to upload a file.

470
00:28:24,501 --> 00:28:27,334
We simply put in the name of a file.

471
00:28:29,876 --> 00:28:32,083
Put in a password.

472
00:28:32,667 --> 00:28:35,375
Choose a file that we're going to upload.

473
00:28:36,250 --> 00:28:41,459
And go ahead and upload it basically the same as any other web application

474
00:28:41,459 --> 00:28:43,250
file upload.

475
00:28:43,999 --> 00:28:50,292
The file itself is assigned a UID for the directory tracking purposes.

476
00:28:50,959 --> 00:28:53,417
We go over to detail.

477
00:28:53,667 --> 00:28:57,834
It's got this file name we assigned it but the original file name

478
00:28:57,834 --> 00:29:02,999
is encrypted with the file data and stored out on the nodes.

479
00:29:03,542 --> 00:29:09,542
Here's the listing of all the file data with each of the file blocks and then

480
00:29:09,542 --> 00:29:13,667
the nodes that each file block lives on.

481
00:29:13,751 --> 00:29:16,667
So this point we've got the replication set to 4 nodes

482
00:29:16,667 --> 00:29:21,959
in a production botnet you definitely want to have that set higher.

483
00:29:21,959 --> 00:29:24,250
Say maybe distributed across 20 different nodes and

484
00:29:24,250 --> 00:29:28,999
if it drops below 10, replicate until you're back up to 20.

485
00:29:28,999 --> 00:29:31,209
So there's a large number of blocks here

486
00:29:31,209 --> 00:29:35,083
because I have my block size set relatively small.

487
00:29:35,083 --> 00:29:37,083
Again, all of this is tuneable.

488
00:29:40,626 --> 00:29:46,999
When we go into the fetch dialogue, we put the password back in.

489
00:29:51,334 --> 00:29:54,125
Go ahead and fetch the file.

490
00:29:54,125 --> 00:29:57,667
It loads all the different file blocks and it looks like I typo'd it.

491
00:29:57,834 --> 00:30:00,417
I may have typo'd it when I created it.

492
00:30:05,501 --> 00:30:06,999
There we go.

493
00:30:08,999 --> 00:30:10,250
All right.

494
00:30:10,250 --> 00:30:13,751
And this is a realtime loading bar here in that it's actually showing what blocks

495
00:30:13,751 --> 00:30:17,709
do we have and what which ones are we still waiting on.

496
00:30:17,709 --> 00:30:19,000
So as it goes across, that's showing we sent

497
00:30:19,000 --> 00:30:22,626
out the request and more and more blocks are come in.

498
00:30:22,709 --> 00:30:25,876
When it gets to the end, we finally have all the blocks, the file

499
00:30:25,876 --> 00:30:29,626
is ready, we concatenate, decrypt with the password we just provided

500
00:30:29,626 --> 00:30:32,042
and the file is downloaded.

501
00:30:32,834 --> 00:30:35,250
Yes, we want to keep this file.

502
00:30:35,250 --> 00:30:37,751
And now we're able to view our data that's getting more

503
00:30:37,751 --> 00:30:40,709
and more dangerous to be caught with.

504
00:30:52,167 --> 00:30:56,292
(Laughter) (Applause) I am going to be releasing the code

505
00:30:56,292 --> 00:30:58,999
for the botnet itself.

506
00:30:59,834 --> 00:31:04,250
Both the engine X side of things, which is basically

507
00:31:04,250 --> 00:31:07,999
an engine X configuration file.

508
00:31:07,999 --> 00:31:09,209
That's all there is to it.

509
00:31:09,209 --> 00:31:13,584
And then releasing the Ruby on Rails application side of it.

510
00:31:14,542 --> 00:31:19,999
Again, it's a research project, not the most stable software out there.

511
00:31:19,999 --> 00:31:22,083
But you'll at least be able to see how I do things,

512
00:31:22,083 --> 00:31:24,459
how I track the blocks.

513
00:31:25,334 --> 00:31:29,083
All of that is going to be available code will be

514
00:31:29,083 --> 00:31:34,417
on github but it will be linked to from my personal side.

515
00:31:34,417 --> 00:31:39,209
And the the slides will be up there as well.

516
00:31:39,209 --> 00:31:41,834
As well as a video of the presentation.

517
00:31:42,334 --> 00:31:45,834
With that, I'll open it up for questions.

518
00:31:45,834 --> 00:31:50,999
I think we two microphones, two different locations in the room here.

519
00:31:50,999 --> 00:31:52,083
So, if we could use those to make sure I can hear you,

520
00:31:52,083 --> 00:31:53,999
that would be great.

521
00:31:54,083 --> 00:31:57,292
Yes    AUDIENCE: Hi.

522
00:31:58,334 --> 00:32:04,083
I wanted to ask you what happens if the three letter agency seizes your

523
00:32:04,083 --> 00:32:07,918
system while it's still operating?

524
00:32:08,334 --> 00:32:11,876
Still connected to the net?

525
00:32:11,876 --> 00:32:14,999
SEAN MALONE: So, if they seize it while it's still connected,

526
00:32:14,999 --> 00:32:19,125
if they take it offline, the replication fails.

527
00:32:19,125 --> 00:32:21,083
AUDIENCE: No, if they keep it online.

528
00:32:21,083 --> 00:32:22,999
SEAN MALONE: If they keep it online, if they're able

529
00:32:22,999 --> 00:32:26,292
to take control of the operating system while it stays

530
00:32:26,292 --> 00:32:30,083
online, then they would be able to rebuild it.

531
00:32:30,083 --> 00:32:32,999
So you want to take the normal physical security measures

532
00:32:32,999 --> 00:32:36,999
to make it as difficult as possible for them to take control

533
00:32:36,999 --> 00:32:39,542
without actually unplugging the system or

534
00:32:39,542 --> 00:32:43,751
at least disconnecting it from the network there.

535
00:32:43,959 --> 00:32:46,375
AUDIENCE: Thank you I'm wondering

536
00:32:46,375 --> 00:32:50,334
if the Internet server goes down does that mean

537
00:32:50,334 --> 00:32:53,167
the files go down too.

538
00:32:53,292 --> 00:32:56,125
SEAN MALONE: Correct.

539
00:32:56,125 --> 00:32:59,584
If the Internet connection goes down, if the nodes can no longer connect

540
00:32:59,584 --> 00:33:02,542
to the server, then the data replication fails and

541
00:33:02,542 --> 00:33:04,792
the blocks are lost.

542
00:33:05,626 --> 00:33:09,918
If it comes back online quickly enough, probably within five minutes or so,

543
00:33:09,918 --> 00:33:13,751
you'll probably have enough nodes left that you can recover the data

544
00:33:13,751 --> 00:33:15,999
but it's not guaranteed.

545
00:33:15,999 --> 00:33:19,584
So the purpose of this is definitely to store data where it is better

546
00:33:19,584 --> 00:33:23,083
to lose it entirely than to have somebody recover that data,

547
00:33:23,083 --> 00:33:26,459
decrypt it and be able to pin it on you.

548
00:33:26,501 --> 00:33:28,083
Over here?

549
00:33:28,083 --> 00:33:30,250
AUDIENCE: What about the file size limits of what

550
00:33:30,250 --> 00:33:32,999
the browser will let you store?

551
00:33:32,999 --> 00:33:35,751
SEAN MALONE: Ah yes, so each node is generally able

552
00:33:35,751 --> 00:33:39,626
to store roughly 5 megabytes of data without prompting the user

553
00:33:39,626 --> 00:33:44,999
and we definitely don't want the user to be prompted to allow more data.

554
00:33:44,999 --> 00:33:48,083
But that's 5 megabytes per node.

555
00:33:48,083 --> 00:33:54,959
So, if you have 10,000 nodes, that's 500,000 megabytes.

556
00:33:54,959 --> 00:33:58,584
Even if your replication cuts that by a factor of 10 or so, that's still

557
00:33:58,584 --> 00:34:02,501
a lot of data that can be stored in this botnet.

558
00:34:02,542 --> 00:34:03,999
Yes?

559
00:34:03,999 --> 00:34:06,542
AUDIENCE: Would it be possible to set a timeout on the web storage

560
00:34:06,542 --> 00:34:08,751
to make the node side block self destruct

561
00:34:08,751 --> 00:34:11,292
after a certain amount of time?

562
00:34:11,292 --> 00:34:15,083
SEAN MALONE: Yes, you can definitely add such a time out.

563
00:34:15,083 --> 00:34:18,709
There's a failsafe kill switch thing where if the node cannot talk

564
00:34:18,709 --> 00:34:23,501
to the server within a certain number of seconds, then it simply wipes

565
00:34:23,501 --> 00:34:26,999
the local storage and the browser there so that even

566
00:34:26,999 --> 00:34:31,999
if the nodes are recovered or seized, more work has to be done at least

567
00:34:31,999 --> 00:34:34,999
in order to access that data.

568
00:34:35,417 --> 00:34:38,334
AUDIENCE: What kind of transfer overhead is there

569
00:34:38,334 --> 00:34:43,459
in comparison to the size both on the server and the node end?

570
00:34:43,459 --> 00:34:46,292
SEAN MALONE: So in terms of the actual algorithm

571
00:34:46,292 --> 00:34:49,999
for the encoding for the encryption and the encoding,

572
00:34:49,999 --> 00:34:54,459
I don't know exactly as a percentage of file size.

573
00:34:54,459 --> 00:35:00,792
But it's basically JSON encoding, AES encryption and then just chopping

574
00:35:00,792 --> 00:35:03,501
it up into blocks.

575
00:35:03,501 --> 00:35:06,667
AUDIENCE: I mean how much data is being sent back and forth?

576
00:35:06,792 --> 00:35:09,125
SEAN MALONE: It's going to depend entirely

577
00:35:09,125 --> 00:35:12,083
on how much data you're storing and how much is stored

578
00:35:12,083 --> 00:35:13,999
on the browser.

579
00:35:14,834 --> 00:35:18,083
Those check queue commands are very small.

580
00:35:18,083 --> 00:35:20,083
That's a post request with no data.

581
00:35:20,083 --> 00:35:23,292
That's just is there anything for me to do?

582
00:35:23,292 --> 00:35:25,999
And normally it's just getting back an empty array.

583
00:35:25,999 --> 00:35:27,292
There's nothing left to do.

584
00:35:28,292 --> 00:35:30,999
The heartbeat command is what you saw up there

585
00:35:30,999 --> 00:35:33,792
on the screen with the block ID.

586
00:35:33,999 --> 00:35:35,918
And the MD5 for each block so there's

587
00:35:35,918 --> 00:35:39,083
a little bit more, but usually it's just getting back

588
00:35:39,083 --> 00:35:40,999
200OK response.

589
00:35:40,999 --> 00:35:43,584
So it's pretty lightweight as far as the total amounts

590
00:35:43,584 --> 00:35:47,542
of bandwidth because it's going to depend on the tuning parameters

591
00:35:47,542 --> 00:35:51,250
for how quickly you're checking the queues and how often you're

592
00:35:51,250 --> 00:35:53,751
sending the heartbeats.

593
00:35:54,250 --> 00:35:58,083
So those can all be tuned depending on how stable the particular nodes

594
00:35:58,083 --> 00:36:00,125
in this botnet are.

595
00:36:00,999 --> 00:36:02,250
Yes?

596
00:36:02,250 --> 00:36:05,250
AUDIENCE: Do you have any way of protecting against, say,

597
00:36:05,250 --> 00:36:08,999
malicious user who connects and sets their local storage

598
00:36:08,999 --> 00:36:12,334
to be persistent in their browser versus just I assume

599
00:36:12,334 --> 00:36:15,999
you have it set for like a transitory temporary thing so

600
00:36:15,999 --> 00:36:20,834
it's not a permanent one with the domain once it's offline?

601
00:36:21,250 --> 00:36:25,999
SEAN MALONE: So we do store it in local storage.

602
00:36:25,999 --> 00:36:28,876
Meaning that it is going to be more persistent.

603
00:36:28,876 --> 00:36:31,459
And the reason for doing that is say you have a browser

604
00:36:31,459 --> 00:36:33,999
with multiple tabs open.

605
00:36:33,999 --> 00:36:36,999
If the user and if they're all going through that proxy,

606
00:36:36,999 --> 00:36:40,542
you want a user to be able to close tabs, move to other tabs

607
00:36:40,542 --> 00:36:46,209
and have that data stay there so you're not needing to replicate unnecessarily.

608
00:36:46,626 --> 00:36:49,083
It would be possible to use session storage which

609
00:36:49,083 --> 00:36:51,250
is going to expire more.

610
00:36:53,250 --> 00:36:56,792
Again, if no matter what you're doing, if you have

611
00:36:56,792 --> 00:37:00,999
a deliberately poisoned botnet and that 3 letter agency is able

612
00:37:00,999 --> 00:37:06,167
to get a sufficiently large number of nodes, a sufficiently high percentage

613
00:37:06,167 --> 00:37:10,999
of nodes, then regardless of how you set it, if logging that traffic,

614
00:37:10,999 --> 00:37:15,751
they may be able log those blocks, it may provide additional security

615
00:37:15,751 --> 00:37:18,417
but not significantly so.

616
00:37:18,501 --> 00:37:22,083
AUDIENCE: Are there any inherent restrictions or reasons why you

617
00:37:22,083 --> 00:37:26,083
wouldn't have the clients connect to a series of failover servers

618
00:37:26,083 --> 00:37:30,834
in the event your Internet goes out or your power goes out.

619
00:37:30,834 --> 00:37:33,667
SEAN MALONE: You could.

620
00:37:33,667 --> 00:37:35,501
However, that would need to be pushed

621
00:37:35,501 --> 00:37:41,999
down from a C2 server and that gives that 3 letter agency multiple chances.

622
00:37:41,999 --> 00:37:45,083
So, if they seize that first server and everything goes offline,

623
00:37:45,083 --> 00:37:49,417
if replication is still being done through a second, third, 4th, 5th server,

624
00:37:49,417 --> 00:37:52,292
once they do forensic analysis on the first server,

625
00:37:52,292 --> 00:37:55,209
they'll see we screwed up our chances with this one

626
00:37:55,209 --> 00:37:57,876
but we know we have to take different tactics

627
00:37:57,876 --> 00:38:00,999
and possibly poison the botnet since it still exists and

628
00:38:00,999 --> 00:38:04,999
is being replicated on those other servers as well.

629
00:38:04,999 --> 00:38:07,459
So again, it would definitely provide

630
00:38:07,459 --> 00:38:11,626
a higher availability guarantee, but it would provide

631
00:38:11,626 --> 00:38:17,626
a significantly reduced confidentiality guarantee at that point.

632
00:38:17,626 --> 00:38:18,876
AUDIENCE: Thank you.

633
00:38:18,876 --> 00:38:20,083
SEAN MALONE: Yes?

634
00:38:20,292 --> 00:38:23,542
AUDIENCE: When you mentioned the legal questions outstanding,

635
00:38:23,542 --> 00:38:27,083
have you consulted legal counsel about that?

636
00:38:27,083 --> 00:38:28,375
SEAN MALONE: I have not.

637
00:38:28,375 --> 00:38:31,999
AUDIENCE: I would I've got a card for you after.

638
00:38:31,999 --> 00:38:33,375
SEAN MALONE: Sounds good.

639
00:38:33,375 --> 00:38:34,375
Yeah.

640
00:38:34,375 --> 00:38:35,250
I definitely would be interested in exploring that side of things

641
00:38:35,250 --> 00:38:36,999
a little more.

642
00:38:36,999 --> 00:38:38,999
AUDIENCE: That would probably be good.

643
00:38:38,999 --> 00:38:39,999
Thanks.

644
00:38:39,999 --> 00:38:40,918
AUDIENCE: Do you have a sense empirically

645
00:38:40,918 --> 00:38:45,959
of how what percentage of the file is lives on the server

646
00:38:45,959 --> 00:38:48,709
at any given moment?

647
00:38:48,709 --> 00:38:49,999
Because of replication?

648
00:38:52,334 --> 00:38:55,167
SEAN MALONE: Empirically, no.

649
00:38:55,250 --> 00:38:59,626
Theoretically, it depends on how quickly you need to replicate.

650
00:38:59,834 --> 00:39:03,334
So the more stable your nodes are, the longer those nodes are online,

651
00:39:03,334 --> 00:39:07,209
the less often you're going to need to replicate.

652
00:39:07,209 --> 00:39:10,250
And it's that replication that causes the data to need to flow

653
00:39:10,250 --> 00:39:12,792
through the server again.

654
00:39:13,083 --> 00:39:16,459
Any time a file is uploaded, any time a file is rebuilt,

655
00:39:16,459 --> 00:39:21,125
and any time a block is replicated, that data is stored on the server

656
00:39:21,125 --> 00:39:24,083
with a timeout of 20 seconds.

657
00:39:24,083 --> 00:39:27,999
For a relatively fast botnet, where you have at least one node

658
00:39:27,999 --> 00:39:32,834
for each block that's going to reply much more quickly than that,

659
00:39:32,834 --> 00:39:38,292
you could probably tune that down to more like 5 or 10 seconds.

660
00:39:38,918 --> 00:39:41,959
But it's hard to say for sure because it depends entirely

661
00:39:41,959 --> 00:39:44,709
on the makeup of that botnet.

662
00:39:46,999 --> 00:39:48,709
All right.

663
00:39:48,709 --> 00:39:49,709
I think we're done.

664
00:39:49,709 --> 00:39:50,709
Thank you very much.

665
00:39:50,709 --> 00:39:50,709
(Applause.)    For any additional questions, I will be available

666
00:39:50,709 --> 00:39:52,626
in the chillout lounge after the talk.

667
00:39:52,626 --> 00:39:52,626
And just a reminder, if you got anything drinking or eating

668
00:39:52,626 --> 00:39:52,626
in here, please take your garbage with you and put it

669
00:39:52,626 --> 00:39:54,167
in the appropriate containers.

670
00:39:54,167 --> 00:39:56,083
Just helps us out at the end of the con.

671
00:39:56,083 --> 00:39:57,083
Thanks.