0:00:15.799,0:00:20.360
Herald: So could you give a warm welcome[br]of applause to Stephan Gronke who will be
0:00:20.360,0:00:23.329
talking to you in one minute.
0:00:23.799,0:00:31.277
Applause
0:00:31.277,0:00:35.290
Stephan: So hi everybody my name is
0:00:35.290,0:00:39.420
Stephan Gronke. I'm a software developer[br]since about 15 years, working in solo
0:00:39.420,0:00:44.499
projects and larger teams and smaller[br]teams. So mostly my development stack was
0:00:44.499,0:00:50.260
JavaScript and you will find some of the[br]tools that I mentioned coming from this
0:00:50.260,0:00:55.829
world, but I'm very sure you can also find[br]something for your project that applies
0:00:55.829,0:01:02.249
here. Here's my email address, my PGP key[br]and my favorite social network account.
0:01:02.249,0:01:09.350
Yeah, so a little spoiler what will happen[br]today: I will talk about development
0:01:09.350,0:01:14.060
process exploitation. So that means if you[br]are developing your software and somebody
0:01:14.060,0:01:18.460
joins your team and since you code for[br]review it could happen that it executes
0:01:18.460,0:01:23.560
code on your machine without your[br]knowledge. There are a few things that are
0:01:23.560,0:01:27.969
really hard to catch or I found hard to[br]catch and I want to share. Maybe you have
0:01:27.969,0:01:32.170
the same problems and you find that the[br]same mitigations apply for your project as
0:01:32.170,0:01:40.929
well. I will then continue and... let's[br]start with a software development process
0:01:40.929,0:01:44.799
that's a small cycle. So first of all it[br]starts with an operating system: you need
0:01:44.799,0:01:48.600
to have a computer to write a software and[br]that's something you need to trust first
0:01:48.600,0:01:59.720
off. If you... yes, so your operating[br]system contains keys and credentials, it
0:01:59.720,0:02:03.159
contains the source code you want to[br]develop and the tools that you have in
0:02:03.159,0:02:09.180
place. And the major risk is that tools[br]are vulnerable to some exploitation or
0:02:09.180,0:02:13.330
that your host is already compromised and[br]you write a software, commit it to your
0:02:13.330,0:02:20.530
coworkers and it isn't what you intended[br]to write. That's a larger problem here.
0:02:20.530,0:02:25.611
After you start writing code, the editor[br]is kind of the interface that I have to
0:02:25.611,0:02:33.250
write the files and edit the code. I find[br]it kind of complex to use an editor. On
0:02:33.250,0:02:36.420
the left you can see that many of the[br]editors come with a package manager
0:02:36.420,0:02:41.940
included, which is a good sign for the[br]complexity that these tools have. And I
0:02:41.940,0:02:45.150
don't know what tools you need but they[br]support you in development so it's very
0:02:45.150,0:02:49.490
good to, for example, have code linters[br]and auto-completion in place to write
0:02:49.490,0:02:56.750
better code. At the same time it can be a[br]problem because they can execute code
0:02:56.750,0:03:02.472
unattendedly. We will see in a moment. The[br]mitigation I came up with for the editor
0:03:02.472,0:03:06.680
part is that you have a virtualized[br]environment where you run your editor. So
0:03:06.680,0:03:11.080
when something happens and and it is[br]compromised, not your root system is also
0:03:11.080,0:03:15.880
compromised as well. You want to monitor[br]all your config files that you have in the
0:03:15.880,0:03:20.590
project and you want to get awareness what[br]exactly happens on my system when I run
0:03:20.590,0:03:22.450
and view this code.
0:03:24.510,0:03:28.430
The next part you will[br]probably use as a shell integration. So as
0:03:28.430,0:03:33.340
soon as you open your repository some of[br]the shells I saw just tell you what
0:03:33.340,0:03:36.840
branch you're working in and what files[br]were changed and so on. So that's
0:03:36.840,0:03:41.790
something that comes very neat if you're[br]developing but it can be a risk as well.
0:03:43.430,0:03:47.240
So my opinion on the shell integrations is[br]mostly that it's made for software
0:03:47.240,0:03:50.980
development on your own system. So when[br]you write the code and you can trust it
0:03:50.980,0:03:55.760
it's not a problem to use those tools at[br]all, but as soon as you get sources from
0:03:55.760,0:04:05.760
foreign developers it can be a problem. So[br]choose your tools wisely and don't execute
0:04:05.760,0:04:12.290
code from others if possible. The[br]versioning system that you commit your
0:04:12.290,0:04:20.040
code to is also a very good choice. For[br]example Git and yeah Git can execute hooks
0:04:20.040,0:04:24.070
on different occasions. For example when[br]you check out new code, if you commit and
0:04:24.070,0:04:30.040
so on. That means if you managed to clone[br]a repository and a ".git" folder is
0:04:30.040,0:04:34.410
included or a ".hg" folder is included, it[br]could mean that your operating system
0:04:34.410,0:04:39.800
decides to execute whatever is in the[br]hooks. It's not possible to store a ".git"
0:04:39.800,0:04:43.130
folder within a Git repository but it's[br]possible to store it in a Mercurial
0:04:43.130,0:04:48.480
repository or in a SVN or something, and[br]then your shell integration won't know
0:04:48.480,0:04:53.210
what the original source was and will[br]execute it anyway. One thing that was
0:04:53.210,0:04:57.990
introduced for example from Visual Studio[br]Code, this October, is that they now
0:04:57.990,0:05:00.890
support git hooks - which is a great[br]feature, right? chuckles
0:05:01.974,0:05:03.090
The mitigations
0:05:03.090,0:05:07.030
against this are pretty easy: you can[br]either set a different hooks path, which
0:05:07.030,0:05:12.790
is not within this project repository so[br]that you don't execute git hooks at all,
0:05:12.790,0:05:16.850
or you can use that little wrapper here[br]that you see, to for example check at
0:05:16.850,0:05:21.210
least that there is no file that is a git[br]hook within that folder before you execute
0:05:21.210,0:05:25.210
git. It's a very good choice if you want[br]to protect yourself from that
0:05:25.210,0:05:27.995
vulnerability.
0:05:29.745,0:05:33.913
So after you committed the[br]code and shared it to the versioning
0:05:33.913,0:05:38.410
server, you probably are going to build it[br]automatically. So some services like
0:05:38.410,0:05:44.230
Travis CI will run it, will run it for[br]you. So they will run tests, they will
0:05:44.230,0:05:49.090
compile the software and also they do the[br]package versioning and deployment to some
0:05:49.090,0:05:53.880
other places. It becomes a problem if you[br]can't reproduce the results from your
0:05:53.880,0:05:59.740
built runner, because it's an system you[br]don't control sometimes. And as soon as
0:05:59.740,0:06:04.400
you get the binary result from it - if you[br]compile the software that compiles to
0:06:04.400,0:06:09.030
binary - you need to check that result[br]somehow, because somebody could have
0:06:09.030,0:06:15.230
altered it without your knowledge and then[br]you will ship it to your users. Also a
0:06:15.230,0:06:19.280
problem on many of this build workers is:[br]you want to have this process very fast.
0:06:19.280,0:06:23.130
So that means you don't want to wait until[br]all the dependencies are installed and the
0:06:23.130,0:06:28.290
great service is that you have caching in[br]between these projects. This means that,
0:06:28.290,0:06:33.030
for example, if somebody managed to inject[br]the version to the cache of some CI
0:06:33.030,0:06:37.919
system, then it will eventually show up in[br]other projects as well and you can pivot
0:06:37.919,0:06:43.940
across the projects. Usually if you have a[br]build environment it has access to some
0:06:43.940,0:06:48.840
kind of development key. Mostly if you get[br]pull requests from externals, the keys are
0:06:48.840,0:06:52.450
stored encrypted and you don't have access[br]to them, but as soon as somebody has write
0:06:52.450,0:06:58.110
access to your repository also the keys[br]could be leaked. Let's make an example:
0:06:58.110,0:07:01.520
you have somebody offering you a software[br]and you don't give permission to edit the
0:07:01.520,0:07:05.930
master branch of the repository but as[br]soon as you open an open a branch anywhere
0:07:05.930,0:07:10.530
and make a pull request Travis CI or other[br]build runners will use that and decrypt
0:07:10.530,0:07:14.110
the passwords for you and give you access[br]to the credentials which you can then
0:07:14.110,0:07:16.942
print or do whatever you intend to.
0:07:18.235,0:07:21.500
Yeah,[br]and for me the best option here would be
0:07:21.500,0:07:26.420
to have reproducible builds because then[br]you can use different of the build workers
0:07:26.420,0:07:30.300
and compare results somehow so that you[br]see if one gets compromised the other two
0:07:30.300,0:07:33.519
will tell you: hey, there's a different[br]result, have a look please.
0:07:34.220,0:07:35.800
That would be great.
0:07:36.250,0:07:40.040
And also the build steps; I[br]mentioned building, testing and packaging
0:07:40.040,0:07:43.940
the software are totally different steps[br]so what you can do is you can have one
0:07:43.940,0:07:48.930
compartment per step so that you can have[br]a data at a finer level and see what
0:07:48.930,0:07:55.669
happens here. After you compiled the[br]software, you built the software, you need
0:07:55.669,0:07:59.840
to ship it to the user somehow so either[br]you store it in your own server or most
0:07:59.840,0:08:04.740
often you use a CDN. You just put it there[br]and it's the asset that's lying around.
0:08:04.740,0:08:09.460
Your users will come around, download it[br]from here and execute it, so what is the
0:08:09.460,0:08:13.669
problem here? The problem is, that if you[br]have an URL it's very hard to prove that
0:08:13.669,0:08:19.110
it's actually from the real maintainer. If[br]you call your software like if - if you
0:08:19.110,0:08:23.260
call your account like a different[br]project, then people won't be able to
0:08:23.260,0:08:28.320
notice the difference somehow. What you[br]can do to mitigate this, is to publish the
0:08:28.320,0:08:34.319
URLs that you legitly using and also sign[br]your assets so that users can check is
0:08:34.319,0:08:38.370
that something that the developer intended[br]to give me or is it something that is
0:08:38.370,0:08:42.740
really ... that is really not intended.
0:08:43.204,0:08:44.986
So, ...
0:08:46.176,0:08:49.359
Yes. And the next part is you need to [br]reach out to your users
0:08:49.359,0:08:52.139
so you make people aware,[br]that there is a project they can
0:08:52.139,0:08:57.160
check out, they can clone and usually you[br]have the package registries. A few slides
0:08:57.160,0:09:03.899
back you saw that the package managers are[br]also included in the editors, so that's
0:09:03.899,0:09:08.290
also something where you can ship the[br]software but the package manager I was
0:09:08.290,0:09:12.790
mostly looking at was for example NPM.[br]There was an interesting occasion where
0:09:12.790,0:09:19.139
somebody had a project called Kik.The[br]company Kik then tried to take it down and
0:09:19.139,0:09:23.259
the person just ignored it for the moment[br]but then Kik reached out to NPM directly
0:09:23.259,0:09:27.860
and they deleted the repository. In[br]consequence the developer removed all his
0:09:27.860,0:09:31.920
projects from the versioning server and a[br]few hours later malware showed up with the
0:09:31.920,0:09:35.779
same project names, so that means if you[br]have a software that uses that
0:09:35.779,0:09:40.649
dependencies and somebody freed up names[br]it would affect your repository as well
0:09:40.649,0:09:46.670
and compromise it. That's something that[br]needs mitigation. I think the best idea
0:09:46.670,0:09:51.480
here is to not only identify the[br]project by a unique identifier but also
0:09:51.480,0:09:58.319
have a GUID or an or a unique identifier[br]per project that does not change, so that
0:09:58.319,0:10:01.700
you can make a difference. That's[br]something that's up to the package
0:10:01.700,0:10:05.310
registries to implement. That's not[br]something we can do as a user but it's a
0:10:05.310,0:10:11.370
very common case - it's a very common case[br]that these packages fluctuate.
0:10:11.370,0:10:14.750
So for example, if somebody deletes it,[br]you don't have a backup of that.
0:10:14.750,0:10:18.495
A very good idea is also to store offline[br]backups of every package that you
0:10:18.495,0:10:22.422
check out and that you install to[br]your software because it's very bad
0:10:22.422,0:10:26.597
if you want to maintain your software and[br]you figure out there's something, there's
0:10:26.597,0:10:29.372
something missing and I can't recover[br]because it's deleted.
0:10:33.165,0:10:38.110
Yes, software developers have some[br]needs during their work.
0:10:38.110,0:10:42.730
I want my tooling to perform if my[br]code editor for example is in the VM and
0:10:42.730,0:10:49.139
the VM is slow, that's something that's[br]annoying all over the process. So then on
0:10:49.139,0:10:53.110
the other hand the velocity is something[br]that your manager will require from you if
0:10:53.110,0:10:59.089
you write commercial software or you try[br]to get something done and you can't spend
0:10:59.089,0:11:03.019
all day to work on chores and improve[br]the repository, the versioning and so on.
0:11:03.019,0:11:09.579
So that's something you need to deal with.[br]Another big factor for me is the
0:11:09.579,0:11:13.480
reliability. So as soon as your software[br]goes down and you are in holiday or
0:11:13.480,0:11:18.240
something, anybody else from the company[br]or from your team should be able to
0:11:18.240,0:11:26.329
recover what was there before, also known[br]as the bus-factor and, yeah, if you have
0:11:26.329,0:11:30.779
convenience like for example Ruby on Rails[br]gives you. It gives you a very good,
0:11:30.779,0:11:34.510
very easy start in the projects and that's[br]something you don't want to break by
0:11:34.510,0:11:38.839
making it too complicated with a[br]development environment. And also
0:11:38.839,0:11:45.490
something I've found to be more annoying[br]than helpful is, if you want to pair-
0:11:45.490,0:11:49.579
program and you have a very[br]compartmentalized environment, it's very
0:11:49.579,0:11:53.269
hard to share the resources that you need[br]to talk about with other developers,
0:11:53.269,0:11:56.699
expecting you're not in the same room but[br]working remotely, what is for me most
0:11:56.699,0:11:58.479
often the case.
0:12:02.110,0:12:06.601
A large problem that I saw is, if you[br]underhand somebody code,
0:12:06.601,0:12:13.030
if you go ahead and and check out[br]code from any online resources, it's
0:12:13.030,0:12:17.372
sometimes very hard to tell if the code[br]that you see in your, e.g. Git diff,
0:12:17.372,0:12:22.689
is what you really would expect to[br]see. I have some examples here, which can
0:12:22.689,0:12:25.959
show how this could work and how this[br]could look like if somebody tries
0:12:25.959,0:12:30.459
to inject code to your repository, that[br]you don't see. First of all, let's start
0:12:30.459,0:12:37.529
with something easy, that's phishing. What[br]you see here on the slide, on the left
0:12:37.529,0:12:42.999
side maybe you see the cursor. That's not[br]a full path, that is just a domain name.
0:12:42.999,0:12:49.680
The slashes in here are UTF-8 characters[br]so that thing here resolves to a hostname,
0:12:49.680,0:12:54.089
and if you control this host, you can get[br]a certificate for it and then the example
0:12:54.089,0:12:59.959
below you see, how it would look like, if[br]you install it. First I have a host that's
0:12:59.959,0:13:04.480
just running a web server on port 80, so[br]that you can see the result. Okay, I was
0:13:04.480,0:13:09.120
cheating a little bit. I was putting the[br]domain in the /etc/hosts so that I don't
0:13:09.120,0:13:15.519
have to buy it, for just showing it. It's[br]strange that dot zip is a domain actually,
0:13:15.519,0:13:21.599
but then if you install it, you would see[br]that you can send somebody a very
0:13:21.599,0:13:25.140
nice-looking link which looks like a[br]totally different project, but it's
0:13:25.140,0:13:30.649
pointing to your server instead; and I[br]found many of the package managers having
0:13:30.649,0:13:34.899
the nice feature of executing PostScript[br]hooks, so that means, if you have
0:13:34.899,0:13:38.574
installed it, it will run some commands[br]afterwards for you.
0:13:42.105,0:13:46.499
Then there is invisible code. If you go[br]online somewhere, find in a forum or in a
0:13:46.499,0:13:50.760
blog, you find an article and see, "hey,[br]that code is actually solving my problem",
0:13:50.760,0:13:54.509
you go ahead and copy/paste it. So, on the[br]left you see the source code how this
0:13:54.509,0:14:00.290
would look like in HTML for the blog. On[br]the right there's the result. So you can
0:14:00.290,0:14:03.980
go ahead, you can copy/paste from it and[br]if you paste it to a text area, you will
0:14:03.980,0:14:07.759
see, that the result is something that you[br]didn't expect. For example, if you copy a
0:14:07.759,0:14:11.509
large chunk of code, you won't go ahead[br]and review it on your local system again
0:14:11.509,0:14:15.649
and that could be the compromise for your[br]project.
0:14:26.869,0:14:31.141
Another example here is, you can[br]use ASCII characters,
0:14:31.141,0:14:34.957
the control characters to influence[br]the output in your terminal.
0:14:34.957,0:14:38.379
So if your terminal also[br]supports the legacy of ASCII control
0:14:38.379,0:14:42.540
characters, you can use that to just[br]revert the line and override it with
0:14:42.540,0:14:47.850
something you wouldn't expect. What you[br]see on top here, that harmless script is
0:14:47.850,0:14:52.059
the file. It's a little larger than you[br]would expect for just a echo foo, but not
0:14:52.059,0:14:57.009
something you would notice when you just[br]see it. Looking at it from a hex editor
0:14:57.009,0:15:01.060
you can see, that there is something more[br]going on than just the foo and if you
0:15:01.060,0:15:05.509
actually execute it, it will not print[br]something, it will create the pwned text,
0:15:05.509,0:15:11.498
which is a good example for you that your[br]host was compromised in this moment.
0:15:15.049,0:15:20.089
Another example I found online, so credit[br]to Ariel for this, so there is a byte
0:15:20.089,0:15:23.100
sequence you can use so that this even[br]works in a Git diff. So when you're
0:15:23.100,0:15:27.110
working exclusively in your terminal and[br]you're not doing reviews on GitHub or some
0:15:27.110,0:15:32.710
graphical tool, it could be the case that[br]you don't notice what was going on. What
0:15:32.710,0:15:37.529
you can see here on the left is, I created[br]an empty repository, I added a small
0:15:37.529,0:15:43.129
script and in the next step down here, I[br]added some improvement to the script,
0:15:43.129,0:15:50.569
which is actually the malicious commit[br]that's here in red. Afterwards, I just ran
0:15:50.569,0:15:55.690
a Git diff on the code and I see that[br]there is only no backdoor, oh sorry that
0:15:55.690,0:16:00.809
should be okay in the updated slides. So,[br]you don't see the evil.sh that it's
0:16:00.809,0:16:05.559
executed as well, if you run it. That's[br]something I consider very dangerous.
0:16:10.893,0:16:16.179
So, some mitigations: the best thing you[br]can do, is to make it expensive for your
0:16:16.179,0:16:21.089
attackers to compromise or try to. So[br]as soon as you have the chance to notice
0:16:21.089,0:16:27.009
what is going on, also retrospectively,[br]you can at least burn the capabilities and
0:16:27.009,0:16:31.889
tell others how your project was attempted[br]to compromise and that's something
0:16:31.889,0:16:35.499
that is, in my opinion, the best[br]mitigation against this complexity.
0:16:36.919,0:16:41.750
What you can also do, is you can test your[br]software from external services directly,
0:16:41.750,0:16:47.509
which will tell you, if some compromise[br]happened. For example, Git has it newly
0:16:47.509,0:16:52.399
introduced. They will check your packages,[br]the dependencies and will warn you about
0:16:52.399,0:16:59.499
some vulnerabilities that are commonly[br]known. The best thing you can do on your
0:16:59.499,0:17:02.470
local system is to build small[br]compartments, so that if some compromise
0:17:02.470,0:17:08.709
happens, it doesn't affect your full host.[br]Also not all your projects you have
0:17:08.709,0:17:12.360
access to. And it's very important, that[br]you have backups on a different system
0:17:12.360,0:17:16.270
than the hosts you're working on. So if[br]the compromise happens you still have
0:17:16.270,0:17:20.849
access to the original data and can[br]compare it and do some forensics on this.
0:17:23.589,0:17:27.640
So, the intrusion detection forensics;[br]there are some great tools available.
0:17:27.640,0:17:32.600
For example my favorites are DTrace and[br]Opensnoop. You can monitor changes and
0:17:32.600,0:17:37.101
access on the file system or on your[br]system at all. And you can e.g. set some
0:17:37.101,0:17:40.120
rules for your projects that are[br]specifically matching. So I am
0:17:40.120,0:17:44.359
not going to share some rules that match[br]for all projects, but you will figure out
0:17:44.359,0:17:48.779
what is e.g. important. Very[br]good start is e.g. to Opensnoop for
0:17:48.779,0:17:54.029
/etc/passwd if there was some access, then[br]you can e.g. say that's not something
0:17:54.029,0:18:00.770
what my software would do. And again it's[br]very important to have the backups of this
0:18:00.770,0:18:04.530
because in the moment where you execute[br]it, you can't trust your host at all.
0:18:06.894,0:18:11.919
The idea how to achieve this is,[br]if you have a VM per project for example,
0:18:11.919,0:18:15.610
you let it run for half a year,[br]you don't approve the situation. Instead
0:18:15.610,0:18:19.309
of having one system that you need to[br]update the software to, you need to update
0:18:19.309,0:18:23.950
afterwards all the projects that you're[br]working on frequently and that's something
0:18:23.950,0:18:28.360
that's easy to forget. So it's dangerous.[br]If you assume that every time you run some
0:18:28.360,0:18:31.940
command or every time you work in a[br]project, you spin up a new server entirely
0:18:31.940,0:18:36.090
from scratch, install the dependencies and[br]so on that's something that's not a risk
0:18:36.090,0:18:43.240
for you. Also, if you have for example a[br]virtualized server environment you can
0:18:43.240,0:18:48.380
have memory dumps at any time, you can[br]monitor the network and you can also diff
0:18:48.380,0:18:51.770
the filesystem. For example, if you stop[br]the server and just compare it to a
0:18:51.770,0:18:55.540
previous version and see, "hey, here is[br]something that was changed that I didn't
0:18:55.540,0:18:58.970
plan". It's great to know.
0:19:01.960,0:19:05.800
Very important is also to separate your[br]accounts. E.g., if you see large GitHub
0:19:05.800,0:19:09.317
accounts, people are making contributions[br]every day since years.
0:19:11.759,0:19:17.410
So it shows that the people[br]have access to very, to many projects from
0:19:17.410,0:19:22.250
the same machine. And the permission model[br]from GitHub for example, allows you to
0:19:22.250,0:19:26.669
store an SSH key for write access. But it[br]automatically has access to all the
0:19:26.669,0:19:30.940
repositories you control. So the best that[br]you can have here, is to make a
0:19:30.940,0:19:35.459
new GitHub account for, ... or to make a[br]new account on that versioning system
0:19:35.459,0:19:39.020
that only has exclusively write access[br]to that single repository.
0:19:39.740,0:19:43.580
So when you work in your[br]compartmented system and you want to
0:19:43.580,0:19:50.260
upload or pull changes, you can't[br]influence other repositories. That means
0:19:50.260,0:19:54.580
compromise doesn't spread across all your[br]projects and so on, which would be an
0:19:54.580,0:20:00.330
invitation for malware somehow or[br]ransomware. And you get a better
0:20:00.330,0:20:06.049
permission model if you create a GitHub[br]organization. In this case you can also
0:20:06.049,0:20:11.649
limit your own access in a better way. So[br]my recommendation is not to work on your
0:20:11.649,0:20:15.119
personal GitHub account but create an[br]organization for your project.
0:20:18.809,0:20:26.100
Something many projects are missing are to[br]find responsible persons for security
0:20:26.100,0:20:33.310
and to clearly communicate what is the[br]plan for incident response. Small example:
0:20:33.310,0:20:36.770
If you have a new project and you[br]find a vulnerability, you would like to
0:20:36.770,0:20:40.571
commit it, but you don't open an issue[br]publicly, because then everybody, every
0:20:40.571,0:20:44.490
user would be affected. You try to reach[br]out to some developers and if you don't
0:20:44.490,0:20:52.570
have any clue how to securely achieve[br]this, that can get you into trouble. And
0:20:52.570,0:20:58.080
there are quite a few projects which don't[br]communicate this and some of them don't
0:20:58.080,0:21:01.955
even respond to their security@ email[br]address, which is bad.
0:21:05.660,0:21:12.210
In this case I told you what I saw from[br]my experiences of working on the projects.
0:21:12.210,0:21:20.699
So that's basically my summary of[br]what can be harmful
0:21:20.699,0:21:23.210
and what can be good for your project.
0:21:23.220,0:21:33.089
Applause
0:21:33.089,0:21:38.179
Herald: Thank you and we now have time for[br]Q&A. In the room you can line up behind
0:21:38.179,0:21:43.070
the microphones and I can see we have a[br]question from the internet already.
0:21:44.410,0:21:50.029
Signal Angel: What about Git signed[br]commits? Any thoughts on that?
0:21:50.029,0:21:53.620
Answer: So as soon as you have signed[br]commits and I find that you also email
0:21:53.620,0:21:57.073
with the same PGP key, it's very[br]interesting that you have the PGP key on
0:21:57.073,0:22:01.329
the same host probably, then you have your[br]Git executable. So if somebody executes
0:22:01.329,0:22:06.520
Git hooks, they can steal your PGP keys[br]from this. I didn't find any tutorial
0:22:06.520,0:22:11.590
online which explains you, how to make it[br]manually, so that you don't use the Git
0:22:11.590,0:22:17.049
for signing the commits. But I think it[br]can be very good to sign the commits,
0:22:17.049,0:22:23.210
but it can be also dangerous, because your[br]email communication can be compromised.
0:22:23.210,0:22:28.980
Herald: Microphone number four.[br]Q: In the Git diff you showed us, there
0:22:28.980,0:22:36.874
were some control characters. I think[br]Git diff pipes to less by default, so
0:22:36.874,0:22:41.360
shouldn't they appear there somewhere?[br]A: No, they don't. I just checked with the
0:22:41.360,0:22:47.290
latest version today. So, that's something[br]that, well, we can also click on the blog
0:22:47.290,0:22:49.814
and see, if there is the video available.
0:23:04.734,0:23:08.449
Yeah, it's very hard to show from my[br]HTML slide how this works.
0:23:08.449,0:23:11.337
So this video animation, ...[br]maybe we can enlarge it a bit.
0:23:12.777,0:23:14.226
That's how it would work.
0:23:30.260,0:23:34.523
So most often, yes, if you pipe to less or[br]you use a hex editor to review,
0:23:34.523,0:23:36.410
then you would notice, yes.
0:23:38.270,0:23:44.299
Q: I somehow remember that, maybe it[br]only shows for longer diffs, but I think
0:23:44.299,0:23:46.740
when I type "git diff", I can scroll[br]around.
0:23:46.740,0:23:53.000
A: Ah, that's interesting. I need to try.[br]Herald: We have a question from microphone
0:23:53.000,0:23:58.539
number one.[br]Q: You mentioned Travis having access to
0:23:58.539,0:24:07.470
hidden variables and you being able to[br]leak those variables during pull requests.
0:24:07.470,0:24:10.409
What are your suggestions to mitigate[br]that?
0:24:10.409,0:24:15.220
A: Don't give people write access to your[br]repository, not even to branches that you
0:24:15.220,0:24:18.710
don't trust. So, as soon as they have[br]write access, they would also know the
0:24:18.710,0:24:23.409
secrets behind the variables in this case.[br]I like the security model, because if you
0:24:23.409,0:24:26.779
for example get contributions from[br]outside, nobody can trigger that and steal
0:24:26.779,0:24:29.250
your keys.[br]But as soon as you build it on your own
0:24:29.250,0:24:32.440
branch somewhere in the repository that[br]changes.
0:24:32.440,0:24:38.940
Q: Yes, but if you submit a pull request,[br]you don't necessarily have to have write
0:24:38.940,0:24:43.460
access to that repository.[br]A: Yes, that's what I mean. If you come
0:24:43.460,0:24:48.240
from outside and it's not within the same[br]repository, the secrets are not decrypted.
0:24:48.240,0:24:52.350
So you can't run the steps. For example,[br]you would not like to deploy directly from
0:24:52.350,0:24:57.759
a foreign branch, somewhere.[br]Herald: We have a question from microphone
0:24:57.759,0:25:02.700
number four.[br]Q: You mentioned the problem with
0:25:02.700,0:25:07.409
different compartments and how to exchange[br]those environments without people. I think
0:25:07.409,0:25:10.980
that problem has already been solved with[br]Vagrant and some kind of provisioning
0:25:10.980,0:25:14.899
software like Ansible.[br]Do you have any experience with checking
0:25:14.899,0:25:20.480
those results of those Vagrant boxes that[br]are automatically provisioned, like
0:25:20.480,0:25:25.830
having some server spec software to check[br]those environments afterwards, or having
0:25:25.830,0:25:31.269
some kind of hashing, how to find out, if[br]they have been reproduced the same way and
0:25:31.269,0:25:37.039
or if they have been any exploit used[br]in that process of setting up the Vagrant
0:25:37.039,0:25:40.250
environments.[br]A: Yes, so different levels you can look
0:25:40.250,0:25:46.150
at this. There was some, ..., I try to[br]find it, yes. You can for example memory
0:25:46.150,0:25:50.120
dump at any time, if you have the hosts[br]trying somewhere or was your question
0:25:50.120,0:25:55.150
exactly that you want to check, if your[br]environment that was spun up was not
0:25:55.150,0:25:58.870
compromised yet?[br]Q: Yeah, there has to be some kind of
0:25:58.870,0:26:05.830
process, how to verify that the produced[br]environments are the ones you expect them
0:26:05.830,0:26:10.990
to be, or if they have been compromised[br]and the problem is, I have used those
0:26:10.990,0:26:16.610
environments and tried, first I tried the[br]full disk encryption for the Vagrant boxes
0:26:16.610,0:26:26.960
but the problem is, it's always the same[br]key for the encryption, so that doesn't
0:26:26.960,0:26:30.530
work and even as you mentioned, you can[br]have a memory dump, so you can read out
0:26:30.530,0:26:37.110
that key so there's no real possibility to[br]set up a Vagrant box that can't be
0:26:37.110,0:26:46.350
tampered with afterwards. So there has to[br]be some kind of hash sum to compare those
0:26:46.350,0:26:49.151
produced results.[br]A: Yeah, so as soon as you have a
0:26:49.151,0:26:53.350
reproducible build and the result that[br]you, for example script languages are much
0:26:53.350,0:26:57.650
easier to achieve, because then you can[br]just diff the filesystem directory and
0:26:57.650,0:27:02.030
see, if there was some change. What I[br]would do in this case, is to run multiple
0:27:02.030,0:27:05.559
services and compare the results, if[br]that's possible. For example, you have
0:27:05.559,0:27:10.630
these reproducible builds, then run it on[br]a few servers which are independent and
0:27:10.630,0:27:14.500
compare what you have.[br]Herald: We have two more questions from
0:27:14.500,0:27:17.960
microphone number one and only a few[br]minutes left. Microphone number one.
0:27:17.960,0:27:22.770
Q: So, what's your recommendation for[br]handling credentials in application
0:27:22.770,0:27:28.789
configuration files? We need often some[br]database user and password or something
0:27:28.789,0:27:33.840
like this in, say Spring Boot Application[br]YML, or things like that?
0:27:33.840,0:27:40.640
And is there any best practice or any[br]framework which can handle such things or
0:27:40.640,0:27:46.919
we need to explicitly encrypt these[br]credentials in this application and then
0:27:46.919,0:27:51.710
decrypt for itself in the application, but[br]then you need symmetric keys, or?
0:27:51.710,0:27:56.250
A: Yes, so Ansible for example comes with[br]a mechanism that's called Ansible Vault,
0:27:56.250,0:28:00.000
which encrypts that with a passphrase that[br]you can enter in your command line as soon
0:28:00.000,0:28:03.990
as you touch the file. For example, if you[br]want to run Ansible then, it will ask you
0:28:03.990,0:28:07.679
for the password when starting up. So, if[br]you want to share that password with your
0:28:07.679,0:28:11.220
developers everybody has access to the[br]same keys, I would prefer to give
0:28:11.220,0:28:16.000
everybody, so every person in this team or[br]even every device a different key, if
0:28:16.000,0:28:21.100
that's possible somehow.[br]That's what I was trying to mention with
0:28:21.100,0:28:24.830
the GitHub accounts; that you don't use[br]one GitHub account but you use many of
0:28:24.830,0:28:27.049
them. If you, ... yeah.
0:28:28.099,0:28:31.860
Herald: We have one more question from[br]microphone number one and then a question
0:28:31.860,0:28:35.090
from the internet.[br]Q: Yeah, my question was more about, I
0:28:35.090,0:28:38.919
mean some of your recommendations are low-[br]hanging fruits, but some of them it's
0:28:38.919,0:28:42.850
like, it's just impossible. I mean it's[br]not sustainable, like it's very hard to
0:28:42.850,0:28:46.960
maintain and so I'm wondering, if you use[br]all of them every day or just part of them
0:28:46.960,0:28:50.190
or do you just leave like an ??? at the[br]end?
0:28:50.190,0:28:54.399
A: It depends on the project. So what I[br]try to do on my development system is to
0:28:54.399,0:28:59.280
have these compartment, so that one[br]compromised project would not affect
0:28:59.280,0:29:04.289
others. Because I'm not the only person[br]checking and merging the code, so and
0:29:04.289,0:29:08.820
that's something that gets quickly too[br]much for one person to review. So, I
0:29:08.820,0:29:13.150
can't review all the code that I'm running[br]currently on my computer, that's true. But
0:29:13.150,0:29:16.540
I can try to mitigate what the impact of[br]this will be.
0:29:16.890,0:29:20.617
Herald: And the question from the internet.[br]Signal: What tool would you recommend
0:29:20.617,0:29:31.850
for diffing a file system?[br]A: Diff. giggles Well, it worked for me
0:29:31.850,0:29:38.620
so far. Or what exactly is the question[br]about? Um, maybe you want to see, if did
0:29:38.620,0:29:42.179
the hash change in the files? So when you[br]have e.g. the script file one and
0:29:42.179,0:29:45.669
the script file B and they have a[br]different hash sum, that's something I
0:29:45.669,0:29:49.760
would consider something I would look up[br]manually. So as soon as I have an
0:29:49.760,0:29:53.440
indication that there was something wrong,[br]I would look it up manually and use any
0:29:53.440,0:29:57.059
tool that I have. Hex editor or whatever[br]is available.
0:29:57.059,0:30:01.200
Herald: Good. We have less than one minute[br]left. Are there any final remarks?
0:30:01.200,0:30:03.620
Stephan: Thank you.[br]Herald: Thank you very much.
0:30:03.620,0:30:05.927
Applause
0:30:10.147,0:30:15.860
postroll music
0:30:15.860,0:30:28.000
subtitles created by c3subtitles.de[br]in the year 2019. Join, and help us!