*37C3 preroll music*
basically textbooks have been written
about it countless talks have been
have been Illuminating all of the errors
of our ways and still all those sucky
software is out there but
Fefe over here the hero of our show
has put out has put all of these best
practices into you know into his work to
try to create a secure website he's
going to show us how it's done so that
we can all sleep way better at night and
with that template go back and
and secure our own software and so with
that I'm going to hand it right over to
Fefe give him a round of applause
*applause*
thank you I have to start
with an apology because I did submit
this talk but it was rejected so the
slides are not at the stage where they
should be these are our slides for a
previous version of the talk it contains
all the material and I tried to update
it more but that destroyed the flow so
we we're stuck with it basically the
difference was the the audience so while
I expect more developers here the other
audience was more and hackers and
business people so I try to get them
from where they are and the main question
usually is "are we there yet?" right
so about me you probably
seen this before I'm a code auditor by
trade I have a small company and
companies show us their code and I show
them bugs I find in them quite easy
but before we start I have a small
celebration to do this actually happened
just a day before the first time I
talked about this so Kaspersky
message they found some malware introduced
tied to libc
which I have written so this is
like a
*applause*
some of the malware people
know what's good
so basically the main question when I
talk to customers is we spend so much
money on this why isn't it working
and the answer is you're doing it wrong
so I will try to show now what exactly is wrong
and there's a small preface here people
usually say there's no time to do this
right and that's just wrong you have
exactly as much time per day as other
people who did great things so you can
do great things too you just need to do it
so let's play a little warm-up game
it's called how it started and how
it's going so let's have a demo round
IBM Watson is revolutionizing
10 Industries and it's going like this
whatever happened to IBM Watson that's a
typical pattern in the security industry
right so here's another one how it started
revolutionize security with AI
right we all know where this is going
*laugther*
right so that's the pattern
let's play IT security mine sweeper
right so everybody here probably
knows who Gartner is they publish
recommendations and they even have a
voting section where people can say
this is the best product in this section
right so let's look at a few of them and
see what happened to people who trusted Gartner
first is a firewall right so how
it started the number one recommendation
is for Fortinet and they have a lot of
marketing *gibberish*
*laughter*
and if you look how it's going it's not
going so good
so let's extend the pattern a bit
why what happened to me in this regard
so I don't need a firewall
I don't have any ports open that I need blocking right
so you don't need this
strictly speaking you don't need it
next discipline endpoint protection
so it started with Trellix this is the
number one recommendation on Gartner
I hadn't heard of them there like can make
a feed joint venture or something
who cares
they also have great marketing *gibberish*
and then if you look at what happened
it's like they made it worse
okay so this didn't apply to me
either because I don't use snake oil
let's see the third one password manager
also very popular
how it started recommended LastPass
you probably know where this is going
*laugther*
yeah they got owned and then
people got owned
so you may notice a pattern here
this didn't apply to me because
I deserve a password authentication use
public key which has been available for
decades right so small bonus
the last one 2FA
Gartner recommends Duo which has
been bought by Cisco but doesn't matter
so if you look at what Duo does
your server asks the cloud for
permission the cloud goes to the telephone
telephone shows a popup you click yes
and then the cloud tells the server it's
okay you can let them in if you look
really closely you can notice the cloud
doesn't have to do the popup it can just
say sure so this comes pre-owned
there is no need to hack anything here
*laugther*
and something many people don't
realize you don't need two factor
if you have public key that's already the second factor
Okay, so
yeah let's skip over this briefly
Splunk is the the recommend option here
and they make the organization
more resilient unless you install it
*laughter*
*applause*
okay so this one is dear to my heart
because people start arguing about
whether to install patches and
which patch to install first and it used
to be simple you look for problems
then you install the patches and then
it got a bit more complicated and
the result is this right
that's a famous podcast in Germany
it's about municipality who got owned
by ransomware and then had to call the
army for help
*inaudible chatter in crowd*
and what you should do I'm having
this for completeness install all patches
immediately but that's a separate talk
right so you may notice a pattern here
the IT security industry
recommends something and
if you do it you're [ __ ] so don't do it
in case you can't read this says snake
repellent granules and then there's a
snake sleeping next to it
*laugther*
*coughing*
right so if we can't trust the
recommendations of the industry what shall we do
and so I had a lot of
time on my hands because I didn't have
to clean up after crappy IT security
industry recommendations so what
what did I do with my time
and I decided I need a Blog
some time ago now and I started
thinking what do I need and it's
actually not that much I could have just
shown basically static content a little
search function would be good but it's
optional um I didn't need comments for
legal reasons because people start
posting like links to maware or
whatever I don't want that I don't
need that right so the first version was
actually really easy it was a small
standard web server and I had the
blog entries a static HTML files
one file per month it was actually really
easy if you want to search you just can
ask Google and limit it to my site so
posting was also easy had a little
script that I could run on the server
and I just SSH in and SSH I trust for
authentication so there's no new attack
surface I have that anyway and this is a
great design it's secure it's simple
there's low risk it's also high
performance but you couldn't do a talk
about it at the CCC right so
it's too boring so I started to introduce
risk in my setup
*laughter
so the first idea was I had
written a small web server I could just
implement the blog in the web server
because you know it's my code anyway
but that has downsides if the the blog
is running in the web server then it can
access all the memory of the web server
in particular it can see the TLS private
key and that I don't want people to
extract right so it can't be a module
in the web server
and the the obvious solution is
it has to run in a different user ID on
on Linux I'm using Linux or but any
Unix or Windows would be the same
basically it runs in a different user ID
and then if you if you take over the
process of the blog because there's some
bug in it you couldn't access the TLS
key and while I did that the industry
was doing this
*chatter*
that's like the running gag of this
talk I show all kinds of interesting
things the industry did and then show
what I did in that time right so
next question
where's the content I could just have
files on disk like static HTML as before
but I think that's not professional enough
right so for a good CCC talk you
need to be more professional
also for a different
project I had just written an LDAP server
so I decided to reuse it and
while I did that the industry did this
I took this photo at the airport of
Jerusalem so this is an actual ad it's
not photoshopped right it's for
Northrop Grumman which is a
military contractor and it's about full
spectrum cyber across all domains
*chatter*
so why would I write my own LDAP server
mostly because it's small and
because I'm an auditor by trade I know
that if you want a chance to actually
audit the code it needs to be small
because that's a limited resource
the time you can spend on auditing code
right so Postgres is a common SQL
database slapped in the the open LDAP
implementation of the server and tinyldap
is mine and you see it's much slower
and much smaller
yeah so there was more to this
ad campaign I collected a few funny images
right so um if someone manages to
hack the blog CGI or whatever module
I use to to have connect the blog to the
web server they can open any file that
the blog can read right the UID can read
so I should probably do something
about that that was the next step and
the industry was starting to think about
vulnerability management
so there is a mechanism on Unix
on Linux I did a separate talk about that
on the last Congress
it's called seccomp and seccomp it's like
a firewall for sys calls so I can use
seccomp to block open the open sys which
is used to open files but if I have
to use open myself
then I can't block it right so what
to do about that for example my blog
calls local time which converts Unix's
time into the local time zone and for
that it opens a file containing the
description of the system time zone
and that calls open right so if
I just disabled the open system call from
my blog then it couldn't do the time
translation and this is actually
an old problem that also applies to set
ID programs and has has applied to them
for decades so what you can do is you
can reorganize your code so before you
block or before you drop privileges
generally speaking you do the open
calls in this in this example and
then you disable open and then you look
at the the data provided by the attacker
because if the attacker or any untrusted
source is trying to hack you it is via
data it gives you right it's
the environment is compromised so you look
at what kind of uh elements in the
environment are attacker supplied and
before you look at a single byte in them
you do all the dangerous stuff if you can
right so in this case I call local
time once before I drop the open sys call
and then my libc will cache the
time zone data and the next time I call it
after I have looked at the attacker
supplied code there is no need to call
open right so that's a major advantage
of Secom over similar Technologies like
SELinux where all the prohibitions
on sys calls are
applied to the whole process so there is
this is an example and you should make
use of it you should look at your
process and you can see if you have the
source code at least you can see which
parts do I need to do before I can drop
privileges and you move them up right so
that's what I did
this is actually a mockup from
the Estonian cyber security center
so this is real
okay so
next thought so let's
say someone hacks the blog module and
someone else uses the same module but
supplies a password right
this is a common problem in website
in websites there's some kind of login
something you get maybe a session token
or whatever and if someone manages to
take over the middleware
or like the server component
they can see all other connections too
if they are handled by the same
process right that's a major problem
and you can do something about it
so that's the good news here
and in my example it led to me using CGI
instead of fast CGI which is fast CGI
is a newer version of CGI
and the idea with fast CGI is that you
don't spawn a new process for every
request but you have like a Unix domain
socket or another socket to a fast CGI
process and that opens maybe a threat
per request or something but usually
in fast CGI you try to handle the
requests in the same process and then
you can use that process to cach data so
there's a perf advantage to using fast CGI
but for security reasons I don't
I don't use fast CGI so I can't do
caching right so that's a major downside
and you would expect the block to be
really really slow in the end so
first thing I need to use CGI instead of
fast CGI and secondly you could still
use debug APIs so if you use GDB or
another debugger to to look at another
process they use an API called ptrace
but that's a sys call so I can use seccomp
to disallow ptrace if I do those two
and the attacker takes over a blog process
all they can see is the data they supply
themselves right that's a major advantage
Okay so ENISA is actually an EU agency
which I find really disturbing
because they're burning lots of taxpayer
money anyway so let's assume the attacker
can hack my blog they can sill circumvent
any access control I do in the blog
so for example if I have an admin site
or some login site part of the webiste
and it's handled through the same program
and the access control is done in the blog
CGI and someone manages
to hack my blog CGI they could
just skip that so it's really hard
to do access restrictions that can be
circumvented if you do them in your own
code so the solution is not do it in
your own code I don't do any access
restriction in the blog I do it in the
LDAP server so if you connect to my blog
and supply a password then the blog
doesn't know if the password is
right or not there's an for example
there's an interface where you can add
new block entries or you can edit an old
one and for you need to supply
credentials but the block CGI doesn't know
if they are right or not it opens
the connections to the LDAP server with
that credential and then the LDAP server
says yes or no so since we removed
access to the ptraces calls and the
processes are isolated from each other
that means there is nothing to
circumvent here so if someone hacks my
blog the only advantage they get is
they can do the exact same stuff they
could do before basically they can just
talk to the LDAP server
okay so I'm starting to get into
James Bond territory here right
with the attacks they getting more
convoluted right so the industry started
doing threat intelligence feeds which
are useless don't spend money on those
okay so let's say the attacker hacked my
blog and then went to my tinyldap and now
is attacking tinyldap then they can
watch other logins because tinyldap
handles connections from other instances
of the blog too right so the same
problem we had before we just moved the
goal post a little and we need to
prevent this and the obvious solution
is to do the same thing we did
with the blog we have one process of
the LDAP server per request and then we
just allow ptrace right so now you
can't watch even if you get code execution
inside the LDAP server you can't watch
what passwords other people use
you can still see okay the industry
does some [ __ ] again you can still see
the password in the LDAP store right so
the LDAP server has to have a version of
the password to authenticate against and
the industry practice best practice is to
use salted hashes so the password is
not actually in the store
still if someone manages to attack
tinyldap through the blog they can
extract the hashes and try to crack them
but since I'm the only one adding users
I can control the password complexity so
good luck brute forcing that right
okay so this is actually a real problem
not for my blog specifically
but for other web services or services
that are reachable from the internet
what if an attacker doesn't want to steal
my data but it wants to encrypt it
so the ransomware what can you do
about that and my idea was to make
the data store read only so the
LDAP server has a data store that contains
all the blog entries and let's read only
to the add up process you can only read
from it and if you want to write to it
for example to add a new entry it gets
appended to a second file which I call the
journal so SQL databases have a similar
concept and they use it to roll back
transactions I can do the same thing
it's basically a log file
and that means all the differences from
the last time the store was created
the read only store all the differences
are sequentially in the log file
in the journal so that the performance
gets worse the bigger the journal gets
so every now and then I need to combine
the read only part and the journal
a new bigger read only part and
I do that manually
because tinyldap couldn't do it because
I didn't allow tinyldap to write the store
right that was part of the security here
and so with seccomp I can just disable
sys calls I can also install filters so I
can say open is allowed but only if you
use O_APPEND O_APPEND in the open sys
call on Unix means every right you do to
this descriptor is automatically
added to the end so I know if someone
manages to to access the tinyldap
binary and can write to my journal then
the only place the changes can show up
is at the end and that's actually a really
good thing to have because it means
if someone hacks me and adds junk to
my blog I can only remove at the end
and I'm good again compare that to a
usual SQL database if someone wrote
to the database you need to in to play
a backup uh in to restore backup because
they could have changed anything anywhere
right so but tinyldap doesn't even have
file system level permissions to change
anything in the store so I can
re-sleep soundly
yeah the industry spent money on
cyber security mesh architecture
right so the journal integration has
to be done by me manually out of band
so it's not something an automated process
does I do it manually
and when I'm doing it
because it's not that much data it's
like for a week or two I can just read it
again and see if something doesn't look
right this may not be available to all
other scenarios but you have to
realize if you have bigger data it's
usually not all the data that's big
most of it is usually static and read only
and then you have some logs that are
you know billing data that grows and grows
but usually there's part of the data and
this is the part with the you know
identifying information personally or
billing details that stuff is usually
small and mostly static and you could
use this strategy for that too
well yeah okay
so the attacker can still write garbage
to my blog that's still not good
right but since all they can do is append
to the journal I can use my text editor
open the journal and truncate at some
point and then I get all my data back
till the point where they start to [???]
the blog right this is still bad but
it's a very good position to be in
if there's an emergency because you
can basically investigate calmly first
you turn off right write access then you
delete the vandalism and the journal
and you know you haven't lost anything
because if you want to delete an entry
in the blog you could do that too but
that means at the end of the journal you
append a statement saying delete this
record and I can just remove that and I
get the record back right so there's no
way for someone vandalizing my blog to
damage any data that was in it before
all they can do is append junk at the end
and I can live with that right this is
this is should be the guiding thought
between any security you do
if someone hacks you will be in a very
stressful position the boss will be
behind you breathing down your neck are
we done yet? is it fixed? and you want to
have as little to do as possible at that
time you want to to move all the stress
to before you get hacked because then
you have more time
okay the industry did other things again
so what if the attacker doesn't write
garbage to the journal but writes some
exploit to the journal that the next
tinyldap up instance that reads the
journal gets compromised by it
that is a possibility and that would be
bad so agreed that there still a problem
but realize how preposterous the scenario
is so we are talking about an attacker
who found stable zero day in the blog
and then used that and another
stable zero day in tinyldap up to write
to the journal and then have the third
third zero day to compromise the journal
passing code so I mean
yes it is still a problem but we reduced
the risk significantly
and that is what
I'm trying to to tell you here it's not
it's not all or nothing it's good enough
if you can half the risk that's already
very important and you should do it
so as much as you can slice off the risk
the better the better off you will be
if something happens
right because the smaller the code is
that is still attackable the
more you can audit it and be sure it's
good you show it to your friends and
they can audit it too and you
need to save yourself that time because
it happens every now and then that I get
to get to see the whole code base and
the usual code base for commercial
products is like gigabytes of source code
nobody can read that like
I'm good I'm not that good
so this is a good place to be in
I think right so the industry was selling
DDOS mitigation sure whatever
so what happens if someone attacks
the web server that is still a big
problem and it's actually
it's a full damage right
that's the worst that can happen if
someone manages to attack the web server
they can see all traffic coming through
they can look inside TLS secured
connections and they can sniff all the
passwords so that's really bad
unfortunately there is not too much
you can do about that
you could do a separation
so this is something people have been
talking about for a while OpenSSL is
doing this they moved the dangerous crypto
stuff in a second process and use
sandboxing to lock down that process
that could be done but nobody has done
it for OpenSSL yet so OpenSSL doesn't
support that my web server
also supports embed TLS they don't
support that too so I I could spend time
on that and I've been actually
spending some time already but it's not
it's not ready yet but this would be a
good way to reduce the risk and you may
notice that the the tools I'm using to
reduce risks are actually just a handful
there's not it's not you know it's not
witchcraft I'm not inventing new
ways to look at things I'm doing the
same thing again I'm identifying the
part of the code that's dangerous and
then I think about how I can make that
part smaller maybe put it in a different
process lock it down so we need to do
the same thing with the web server
obviously but it's an ongoing process
yeah so again whatever why
haven't I done that yet uh so in my
web server you can it's a build time
decision if you want SSL support or not
and you can see the binary is
significantly bigger if you have SSL
and I'm showing you this because it means
the bulk of the attack surface is the SSL
code it's not my code so if I if I can
put the SSL code in a different process
they still need to see the private key
because that's what TLS needs
the private key otherwise it can't
do the crypto so the bug of the attack
surface would still have access to the
key I can still do it because there
might be bugs in my code and not the
SSL code but that's just 5% of the of
the overall attack surface so
I will probably do it at some point
but it's I don't expect miracles from it
bugs and open SSL will kill me
there's not much I can do about that
*laughter*
okay so I know what you're thinking
*loud laughter*
what about kernel bugs?
so I looked at a few of the recent
kernel bugs and it turns out that they
usually apply to sys calls that are rarely
used in regular programs and because
I'm blocking all the sys calls I don't
really need none of them apply to me
right and this is a this is a pattern
with Kernel bugs
there is a project called Sandstorm
that also uses ptrace and seccomp tracing
to reduce the sys call
surface and then puts regular services
into a sandbox for web services and
they evaded all kinds of of Kernel bugs
just because of that so this is
like a zero effort thing because
obviously if you have a list of sys calls
you'd use a white list and you
have a list of things you are
explicitly low and the rest is disabled
not the other way around right
so none of the usual Kernel bugs apply
to me um because of the the seccomp stuff
I already do so Kernel bugs aren't as big
of a problem as you might think at least
I still have them if I haven't patched
but you can't get to them via the blog
so I have a small confession to make
I'm a bit of a troll and that applies
to this project as well so I used the
worst programming language I used C right
so I'm trolling the security people
and then I'm trolling the Java people
who have been saying you should use
multi-threading for performance and not
have one process per request
so I'm doing actually two fork and exec
per request
I'm trolling the database people
I don't have any caching
I don't have connection pools
and the perf people too because I'm
still faster than most of the regular
solutions so there is no there's really
no downside if you if you architect your
software to use this kind of thing
it will be slower than other ways to do it
but most other software isn't as fast
anyway so there's enough headway that
you can use to do security instead of
performance you will still be faster
so let's recap the methodology I used
first I make a list of all the attacks
I can think of and this means
concrete attacks so what could happen
and what would what would
be the problem then right and then
I think for every item on the list
I consider how to prevent this
can I prevent this? what I need to do
and then I do it right so that's easy
it's like this the Feynman problem solving
algorithm in spirit and this
process is called threat modeling it's
it's like a it's dirty word because it
sounds like there's effort involved and
nobody wants to do it but it's really
it's easy it's just these these steps
you look at your software you
consider all the ways it could be attacked
and then you consider what you
could do to prevent the attack or in
some cases you can't prevent the attack
and then you say well that's a risk I have live with
right so that's called threat modeling
you should try it's awesome
and you saw that I'm trying
to optimize something here I go for a
specific target in this case I want
as little code as possible
the more code there is the more bugs
there will be that's an a very old
insight from I think it was originally
in IBM study and they basically found
that the number of bugs in code is a
function of the lines of code in the code
so there's a little more to it but
basically it's true so and it's not just
any code I want to have less of
if the code is dangerous I particularly
want to have less of it and the the most
important category to to make smaller is
the code that enforces security
guarantees so like one security
guarantee would be you can't log in
if you don't have the right password right
so the code that checks that I want it to
be as small as possible one or two
lines of code if I can manage it and
then it's obvious if it if it's wrong or
not the more complex the code is the
less easy would it be to see if
it's correct or not and that's what you
want in the end you want to be sure the
code is correct so how far did I get
it's actually pretty amazing I think
you can write an LDAP server in 5000 lines
of code the blog is 3500 lines of code
plus the LDAP client library
plus zlib
but I'm only using zlib to compress not to
decompress so most attack scenarios
doesn't don't apply to to my usage of zlib
and the web server is also pretty slow
if you only look at the HTTP code
unfortunately it also contains the
SSL Library which is orders of magnitude
more than my code and that's how you
want it you want the biggest risk not to
be in the new code but in an old code
that someone else already audited if you
can manage it right so this is the
optimization strategy try to have as
little dangerous code as possible sounds
like a no-brainer but if you look at
modern software development you will
find out they do the exact opposite pull
in as many frameworks as as they can
so this strategy is called
TCB minimization you should try it and
I gave a talk about it already it's
actually pretty easy so
I told you what I did to the
to the blog to
diminish the danger that can be done
if someone manages to take it over and
this is actually part of the
TCB minimization process so the blog was a
high risk area and then I took away
privileges and removed excess checks and
in the end even if I give you remote
code execution in the blog process you
can't do anything you couldn't do before
right so it's no longer part of the TCB
the TCB is the part that enforces
security guarantees which the blog CGI
doesn't anymore
so that's what you want to do
you want to end up in the smallest TCB
you can possibly manage and every
step on the way is good so no step is
too small right if you can shave off
even a little routine do it
this is the minimization part of TCB
minimization right I could I was able to
remove the blog from the TCB tinyldap
still has a risk so you saw
the threat model if someone manages to
take over tinyldap they can read the
hashes and try to crack them that's
still bad but I can live with it right
if they vandalize the blog I can undo
the damage without going to the
date library so that's good
if you compare that to the industry
standard you will find that my approach
is much better usually in
the industry you see platform decisions
done by management not by the techies
and it's untroubled by expertise or
risk analysis and you get a
diffusion of responsibility because if
you even if you try to find out who's
responsible for anything you find
well it's that team over there but we
don't really know and then you find out
the team dissolved last week and it's
really horrible and brand new we have
AI tools which is also a diffusion of
responsibility
and then you get people
arguing well it's so bad it can't get
any worse let's go to the cloud where
obviously it gets worse
immediately so I prefer my way
I think in the end it's important to
realize that the the lack of security
you may have in your projects right now
is self-imposed there is no guy with a
shotgun behind you
threatening you can do it you just have
to start right so this is self-imposed
helplessness you can actually help
yourself you just have to start
right how did we get here this is
obviously not a good place to be
like all the software is crappy and
there's a few it's not just that people
are dumb there's a few reasons for that
so back in the day you used to have
bespoke applications that were written
for a specific purpose and they used the
waterfall model and you had the
requirements specification and it was
lots of bureaucracy and really horrible
but it also meant that you knew what
the application had be had to be able to
do so that means you can make sure
anything else is forbidden if you know
what the application needs to be able to
do you can make sure it doesn't do any
other stuff and that is security if you
think about it deny everything that the
application wasn't supposed to be doing
and then that's what an attacker would
do if they take over the machine right
so if you know beforehand what you're
trying to get to you can actually
implement privilege even architecturally
as I've shown you
now we have more of an Ikea model
you buy parts that are designed by
their own teams and the teams designing
the parts don't know what the final
product will look like right in in some
cases even you don't know what the final
product will look like but it's even
worse if you consider that the
team building the part you make your
software from doesn't know what it will
be used for so it has to be as generic
as possible right the more it can be
done with it the better and that's
the opposite of security right security
means understanding what you need to do
and then disallowing the rest and this
means be as generic as you can the parts
are optimized for genericity what's the
name genericism I don't know so they are
optimized to be as flexible as possible
and they are chosen by flexibility
the developer of the part usually
has no idea what it would used for
and that means you can't do least
privilege because you don't know what
the privilege will be that's least so
this is actually a big mess so if
you use parts programmed by other people
you will have to invest extra effort to
find out what kind of stuff you can make
it not do because it will definitely be
able to do more than you need and the
more you can clamp down the more
security you will have it's even
worse if you do agile development
because then by definition you don't
know what the end result will be so
if you don't know that you can't do
security lockdown
so another argument why we got
here is economics of scale so it used to
be that if you build some kind of device
that needs to do something like I don't
know microwave
then you you find parts and
you combine the parts and you solder
them together and then they solve the
problem but these days you don't
solder parts anymore you assemble from
pre-made parts and these are usually
programmable right so a little ARM chip
cost like a tenth of a cent so why use
a special part if you can use an ARM chip
and then program it but that means
you still need to use software that
actually solves the problem the hardware
is generic and that means the hardware
can be hacked and this is turning out to
be a problem right if you had a brake in
in 20 years know it braked right
but now it's programmable
and people haven't realized
how bad that is but it is bad right so
that's that will bite us in the
ass oops
so the response from the industry
has so far been the ostrich method
basically we install stuff that we know
is untrustworthy and so we
install other stuff on top of it that's
also untrustworthy and then we call it
telemetry or big data and to some risk
logging analysis in [???] or whatever
and in the end the attack surface
has mushroomed like a nuclear explosion
right so that's our fault
nobody has forced us to do this you
don't need to do this in your own
projects that's the hopeful message of
this talk in conclusion if you remember
nothing else from this talk remember
that threat modeling is a thing and you
should try it TCB minimization actually
helps least privilege is another facet
of the same thing and if you can use
append only data storage you should
consider it
- blockchain - yeah not a blockchain
append only data storage
it's not blockchain
*laughter*
*applause*
- two more two more
- two more slides
- yeah two more slides
- sorry I'm imposter
- no problem
so the rule of thumb
should be if if the blog of some
unwashed hobbyist from the Internet is
more secure than your IT security then
you should improve your IT security
right that shouldn't happen
all right so that's all from my
talk I think we still have time for
questions do we? yes okay awesome okay
now you can put your hands together
*applause*
so if you want to ask a question
we have four microphones in the room
1 2 3 4 and I'm going to take a
question the first question from
the internet the internet is saying you
actually got hacked or can you elaborate
on what happened?
yes actually there was an
incident where someone was able to post
stuff to my blog and because I had append
only data storage I shrugged it off
basically so use append only data storage
it's it will save your ass at some point
the problem was a bug in my
access control lists I had used some
some access control list in my LDAP server
and I had a line in it that
I should have removed but I forgot to
remove it and that meant you could post
without having credentials but it
happened and it wasn't bad because my
architecture prevented damage as
people are leaving the room could you
leave very quietly thank you
microphone number one
- yeah is there a second alternative
for Windows and MacOS?
- secure alternative well so
basically you can do the principles
I showed in this talk you can do on
those two so usually you will not be
hacked because your MacOS or
Windows had a bug I that happens too but
the bigger problem is that the software
you wrote had a bug or that you the
software that you use had a bug so I'm
I'm trying to tell you Linux isn't
particularly more secure than Windows
it's just it's basically you can write
secure software and insecure software on
any operating system you should still
use Linux because it has advantages but
if you apply these techniques to
your software it will be secure on
MacOS and windows as well right so this
is not for for end users selecting the
software if you select software you have
to trust the vendor
there's no way around that but if
you write your own software then you can
reduce the risk to a point where you can
live with it and sleep soundly
- sure is there a a technical alternative
or similar similarity like seccomp for
Windows and MacOS so can you drop your
privileges after you have opened a file
for example
- so for MacOS I'm not sure but I know
that FreeBSD NetBSD and OpenBSD have an
equivalent thing I think MacOS has it too
but I'm not sure about that for Windows
there's are sandboxing methods you can
look at the Chrome source code for
example they have a Sandbox it's open
source you can use that to do this kind
of thing
- okay thanks
- so microphone number two except down
that's gone so I might go with
mic number three in that csae
sorry four four yes
- will your next talk be about writing
software secure software in Windows and
if no uh how much assets would you
request to compensate for all the pain?
- no
*laughter
it's not a question of money
*laughter*
- okay microphone one
- have you tried removing unnecessary
features from openSSL?
- yes actually I've I've done this
pretty early but it's still it's still
much bigger than my code
so for example openSSL has support for
UDP based TLS but there's a lot of
shared ciphers in there you can remove
ciphers you don't need and and that
helps a bit but it's still it's the
biggest part of the web server by far
- I think there was an internet question
was there no doesn't look like it
no yes no no yes okay
then microphone four
- as someone who is connected or
was connected to an industry which has
programming programmable brakes
what is your opinion about things like
like Misra?
- well well so there are standards
in the automotive industry for example
like Misra to make sure you write better
code and it's mostly compliance
so they give you rules like
you shouldn't use recursion in your code
for example and
the functions should would be this big
at most and this is more I mean it
will probably help a bit but it's much
better to to invest in in good
architecture but you may have noticed I
I've said I wrote the code in C and
I said nothing about what I did to make
sure it's it's good code so that's
that's a different dimension that's
orthogonal right
so follow those standards it will it
will make your code a bit better
probably but it won't solve all the
problems and I think personally you
should do both you should make sure or
try to make sure that there's as little
bugs as possible in your code there's
ways to do that I had a talk about that
too but after you do that you should
still have these kind of
architectural guide guard rails that
keep you on track even if someone
manages to take over the process
- so now I think there was an internet
question
- yes the internet is asking
how would it work to like scale this
truly impressive security architecture up
for more use cases and more like
larger theme or would the theme size and
the feature keep ruin it
- yes so
hello hello
- oh no
*laughter*
- well I'm sorry
*applause*
*postroll music*