SECURE SYSTEMS ENGINEERING ERIK TEWS <E.TEWS@UTWENTEL.NL> - - PowerPoint PPT Presentation

secure systems engineering
SMART_READER_LITE
LIVE PREVIEW

SECURE SYSTEMS ENGINEERING ERIK TEWS <E.TEWS@UTWENTEL.NL> - - PowerPoint PPT Presentation

SECURE SYSTEMS ENGINEERING ERIK TEWS <E.TEWS@UTWENTEL.NL> HOUSEKEEPING The covert channel traces are online You get always 5 traces from the unmodified app 5 traces from Other student submissions My own implementation


slide-1
SLIDE 1

SECURE SYSTEMS ENGINEERING

ERIK TEWS <E.TEWS@UTWENTEL.NL>

slide-2
SLIDE 2

▪ The covert channel traces are online ▪ You get always ▪ 5 traces from the unmodified app ▪ 5 traces from ▪ Other student submissions ▪ My own implementation

2

HOUSEKEEPING

11.06.2018 Systems Security – Secure Systems Engineering

slide-3
SLIDE 3

▪ Feel free to submit questions ▪ When you missed a lab session, you can catch up with it next week right after the lecture in Twente

3

NEXT WEEK

11.06.2018 Systems Security – Secure Systems Engineering

slide-4
SLIDE 4

▪ Choose a good architecture ▪ Use methods from secure programming ▪ Run everything with the least privilege possible ▪ Have permanent monitoring and updates

4

SECURE SYSTEMS ENGINEERING

HOW TO BUILD SECURE SYSTEMS

11.06.2018 Systems Security – Secure Systems Engineering

slide-5
SLIDE 5

5

A GOOD ARCHITECTURE?

11.06.2018 Systems Security – Secure Systems Engineering

Your application

slide-6
SLIDE 6

6

TYPICAL DESIGN FOR A WEB APPLICATION

11.06.2018 Systems Security – Secure Systems Engineering

Database Web server Application

slide-7
SLIDE 7

7

TYPICAL DESIGN FOR A WEB APPLICATION

11.06.2018 Systems Security – Secure Systems Engineering

Database Web server Application User accounts

slide-8
SLIDE 8

8

USING MICROSITES/MICROSERVICES

11.06.2018 Systems Security – Secure Systems Engineering

Database Web server Application Database Web server Application Database Web server Application Common services Database

slide-9
SLIDE 9

9

DIFFERENT SECURITY ZONES

11.06.2018 Systems Security – Secure Systems Engineering

Robot control Web frontend Sensors and validation

slide-10
SLIDE 10

▪ Split your application into individual modules/layers ▪ Put either very insecure or highly privileged stuff into modules ▪ Have a clear separation between them ▪ Have a clear way of communication between them

11.06.2018 10

SUMMARY FOR SECURITY FRIENDLY ARCHITECTURES

Systems Security – Secure Systems Engineering

slide-11
SLIDE 11

▪ For each of the modules try to drop privileges ▪ Do we need to write files? ▪ Do we need write access to the database? ▪ Should we be able to see all fields in a table?

11.06.2018 11

LEAST PRIVILEGE

Systems Security – Secure Systems Engineering

slide-12
SLIDE 12

▪ By default, a web application can ▪ Load all kinds of resources from everywhere ▪ Use inline JavaScript ▪ Send form data everywhere ▪ Load content from insecure sources ▪ Read all cookies for this specific host

DROPPING PRIVILEGES ON WEB APPLICATIONS

slide-13
SLIDE 13

11.06.2018 13

USING A CONTENT SECURITY POLICY

Systems Security – Secure Systems Engineering

slide-14
SLIDE 14

▪ Content-Security-Policy: default-src 'self‘ ▪ Content-Security-Policy: default-src 'self' *.trusted.com ▪ Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com ▪ Delivered in an HTTP header

11.06.2018 14

EXAMPLES

Systems Security – Secure Systems Engineering

slide-15
SLIDE 15

▪ There is a (poorly written) python app that allows you to search for US presidents ▪ Add a CSP for the app

11.06.2018 15

ASSIGNMENT CSP

Systems Security – Secure Systems Engineering

slide-16
SLIDE 16

▪ Limiting the attack surface can be helpful ▪ An application running on Linux has acces to the entire system ▪ Entire filesystem ▪ Bind to all network interfaces ▪ See all processes ▪ We would like to limit that

16

ISOLATION

11.06.2018 Systems Security – Secure Systems Engineering

slide-17
SLIDE 17

▪ Namespaces ▪ Network ▪ IPC ▪ Mount (filesystem) ▪ Process ID ▪ UTS (Hostname) ▪ Control group

11.06.2018 17

ISOLATION FEATURES ON LINUX

Systems Security – Secure Systems Engineering

slide-18
SLIDE 18

▪ Try to run unshare

11.06.2018 18

AN EXAMPLE

Systems Security – Secure Systems Engineering

slide-19
SLIDE 19

▪ Uses namespaces (as well as some other technologies) ▪ Creates isolated containers on Linux ▪ For processes running inside a container, it looks like a standalone Linux system ▪ In fact, they share a common kernel ▪ Pro ▪ Very efficient ▪ Con ▪ A kernel bug will compromise all containers

11.06.2018 19

DOCKER

Systems Security – Secure Systems Engineering

slide-20
SLIDE 20

11.06.2018 20

A DEFAULT LINUX SYSTEM

Systems Security – Secure Systems Engineering

Kernel Application 1 Application 2 Application 3

slide-21
SLIDE 21

11.06.2018 21

LINUX WITH DOCKER

Systems Security – Secure Systems Engineering

Kernel Application 1 Application 2 Application 3 Web container Database container

slide-22
SLIDE 22

11.06.2018 22

LINUX WITH XEN

Systems Security – Secure Systems Engineering

Kernel Dom0 Management tools Application 1 App 2 Xen Hypervisor Kernel DomU App 3 Kernel DomU

slide-23
SLIDE 23

11.06.2018 23

LINUX WITH KVM

Systems Security – Secure Systems Engineering

Kernel Application 1 Kernel Guest Kernel Guest Application 2 App 3 App 4

slide-24
SLIDE 24

▪ Pro ▪ A kernel bug will (hopefully) only compromise the specific VM ▪ Running different kernels is possible ▪ Some things are hard to put into containers ▪ Cons ▪ In general, this needs way more ressources

11.06.2018 24

LINUX WITH XEN AND KVM

Systems Security – Secure Systems Engineering

slide-25
SLIDE 25

▪ We would still like to run apps with the least priviledge possible ▪ Reduces impact on everything in the same container/system when a single app is compromised ▪ May also reduce the attack surface against the currently running Linux kernel

11.06.2018 25

DROPPING PRIVILEDGES ON LINUX

Systems Security – Secure Systems Engineering

slide-26
SLIDE 26

Prepare to react ct

14.05.2018

TXT

1 2

In Intern rnet

1 2 Posting messages is anonymous

The text on this slide will instruct your audience on how to post. This text will only appear once you start a free or a credit session. Please note that the text and appearance of this slide (font, size, color, etc.) cannot be changed.

slide-27
SLIDE 27

How can we drop priviledges on Linux?

  • 1. Your

audience's responses will appear here. Please feel free to change the font, color etc. This text disappears after starting your session and slideshow.

  • 2. Your

audience's responses will appear here. Please feel free to change the font, color etc. This text disappears after starting your session and slideshow.

  • 3. Your

audience's responses will appear here. Please feel free to change the font, color etc. This text disappears after starting your session and slideshow. # Messages: 0

Internet This text box will be used to describe the different message sending methods. TXT TXT The applicable explanations will be inserted after you have started a session.

slide-28
SLIDE 28

▪ When you like to, get a Linux vm up and running ▪ Download the seccomp-examples.zip from canvas

BREAK

slide-29
SLIDE 29

▪ Interface for applications to request services by the operating systems ▪ Opening files (open) ▪ Writing to files (write) ▪ Reading from files (read) ▪ Establish network connections (socket/connect) ▪ Attach a debugger (ptrace) ▪ Allocate memory (brk) ▪ Operating system specific

SYSCALLS

slide-30
SLIDE 30

#include <stdio.h> #include <stdlib.h> int main(int argc, char ** argv) { FILE * f = fopen("logs/myapp.log", "w+"); if (f == NULL) { fprintf(stderr, "Cannot open the logfile\n"); return 1; } fprintf(f, "App started!\n"); return 0; }

11.06.2018 30

CODE EXAMPLE

Systems Security – Secure Systems Engineering

slide-31
SLIDE 31

▪ Usually not used directly (libc wrapper) ▪ Arguments depend on the individual call ▪ Often an integer to specify ▪ Length ▪ Flag/Enum ▪ Resource/File handle ▪ Or a pointer to the program memory ▪ Data structure/buffer to be used by the syscall ▪ Memory to transfer results to ▪ Can be shown using strace <program>

11.06.2018 31

WORKING WITH SYSCALLS ON LINUX

Systems Security – Secure Systems Engineering

slide-32
SLIDE 32
  • pen("logs/myapp.log", O_RDWR|O_CREAT|O_TRUNC, 0666) = 3

fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 write(3, "App started!\n", 13) = 13

11.06.2018 32

RESULTS FOR THE EXAMPLE

Systems Security – Secure Systems Engineering

slide-33
SLIDE 33
  • pen("logs/myapp.log", O_RDWR|O_CREAT|O_TRUNC, 0666) = 3

fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 write(3, "App started!\n", 13) = 13

11.06.2018 33

ARGUMENTS

Systems Security – Secure Systems Engineering

File handle Buffer content to write Buffer length

slide-34
SLIDE 34

SYSCALLS EXAMPLE (FOR PRINTF/WRITE)

Userspace Kernelspace Syscall handler Application Standard C library Call fprintf(…) write syscall trap into kernel space write handler Device driver Copy from userspace

slide-35
SLIDE 35

▪ Linux provides 300+ syscalls ▪ Probably no application that needs all of them ▪ They can be used by adversaries who exploit a weakness in your code ▪ socket/connect to establish network connections ▪ openat/getdents/open/read to read local files ▪ execve to launch another program ▪ Seccomp helps you to prevent that

11.06.2018 35

SYSCALLS ON LINUX

Systems Security – Secure Systems Engineering

slide-36
SLIDE 36

▪ Application compiles a filter for syscalls ▪ List of allowed syscalls ▪ Optionally with restrictions in the arguments ▪ Action to be executed for forbidden syscalls ▪ Usually terminate the application immediately ▪ Alternatively a debugger can be attached ▪ The filter is transferred to the kernel space ▪ Every syscall is checked before it is executed ▪ Filters cannot be removed

11.06.2018 36

SECCOMP HIGH LEVEL OVERVIEW

Systems Security – Secure Systems Engineering

slide-37
SLIDE 37

SYSCALLS EXAMPLE (FOR PRINTF/WRITE)

Userspace Kernelspace Syscall handler Application Standard C library seccomp filter Call to prctl Call to prctl prctl handler Seccomp handler

slide-38
SLIDE 38

SYSCALLS EXAMPLE (FOR PRINTF/WRITE)

Userspace Kernelspace Syscall handler Application Standard C library Call fprintf(…) write syscall trap into kernel space write handler Device driver Copy from userspace seccomp filter

slide-39
SLIDE 39

#include <stdio.h> void calcloop() { int a,b; int matched; while(1) { matched = scanf("%d %d", &a, &b); if(matched != 2) { printf("Bye!\n"); return; } printf("%d + %d = %d\n", a, b, a+b); } } int main(int argc, char ** argv) { printf("My tiny calculator\n"); calcloop(); return 0; } 39

CALC EXAMPLE

11.06.2018 Systems Security – Secure Systems Engineering

slide-40
SLIDE 40

My tiny calculator 1 + 1 = 2 2 + 5 = 7 Bye!

40

RUNNING IT

echo -e "1 1\n2 5\n" | ./calc

11.06.2018 Systems Security – Secure Systems Engineering

slide-41
SLIDE 41

… write(1, "My tiny calculator\n", 19My tiny calculator ) = 19 fstat(0, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 read(0, "1 1\n2 5\n\n", 4096) = 9 write(1, "1 + 1 = 2\n", 101 + 1 = 2 ) = 10 write(1, "2 + 5 = 7\n", 102 + 5 = 7 ) = 10 read(0, "", 4096) = 0 write(1, "Bye!\n", 5Bye! ) = 5 exit_group(0) = ? +++ exited with 0 +++

41

RUNNING IT

echo -e "1 1\n2 5\n" | strace ./calc

11.06.2018 Systems Security – Secure Systems Engineering

slide-42
SLIDE 42

▪ read ▪ Read from stdin ▪ write ▪ Write to stdout ▪ fstat ▪ Retrieve information about stdin and stdout ▪ exit_group ▪ Terminate

11.06.2018 42

REQUIRED SYSCALLS

Systems Security – Secure Systems Engineering

slide-43
SLIDE 43

int setup_seccomp() { scmp_filter_ctx ctx; ctx = seccomp_init(SCMP_ACT_KILL); int calls[] = { SCMP_SYS(read), SCMP_SYS(write), SCMP_SYS(exit_group), SCMP_SYS(fstat) }; int calls_length = sizeof(calls)/sizeof(calls[0]); int i; if (ctx == NULL) { return -1; } for (i = 0; i < calls_length; i++) { if (seccomp_rule_add(ctx, SCMP_ACT_ALLOW, calls[i], 0) < 0) { seccomp_release(ctx); fprintf(stderr, "adding rule %d failed\n", i); return -1; } } if (seccomp_load(ctx) < 0) { seccomp_release(ctx); fprintf(stderr, "loading seccomp failed\n"); return -1; } return 0; }

11.06.2018 43

SETTING UP FILTERS

Systems Security – Secure Systems Engineering

slide-44
SLIDE 44

Compile with: ▪ gcc –o calc-seccomp calc-seccomp.c –lseccomp

11.06.2018 44

LIVE DEMO

Systems Security – Secure Systems Engineering

slide-45
SLIDE 45

▪ We may also restrict the arguments of the Syscall ▪ Read only from stdin ▪ Write only to stdout ▪ Fstat only on stdin ▪ Exit_group only with return code 0

11.06.2018 45

ADVANCED SECCOMP FILTERING

Systems Security – Secure Systems Engineering

slide-46
SLIDE 46

if (seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(read), 1, SCMP_CMP(0, SCMP_CMP_EQ, STDIN_FILENO)) < 0) { seccomp_release(ctx); fprintf(stderr, "could not setup rule for read\n"); return -1; }

11.06.2018 46

ARGUMENTS FOR READ

Systems Security – Secure Systems Engineering

For read, the first argument must be equal to STDIN_FILENO

slide-47
SLIDE 47

if (seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 1, SCMP_CMP(0, SCMP_CMP_EQ, STDOUT_FILENO)) < 0) { seccomp_release(ctx); fprintf(stderr, "could not setup rule for write\n"); return -1; }

11.06.2018 47

WRITE

Systems Security – Secure Systems Engineering

slide-48
SLIDE 48

if (seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(fstat), 1, SCMP_CMP(0, SCMP_CMP_EQ, STDIN_FILENO)) < 0) { seccomp_release(ctx); fprintf(stderr, "could not setup rule for fstat\n"); return -1; }

11.06.2018 48

FSTAT

Systems Security – Secure Systems Engineering

slide-49
SLIDE 49

if (seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit_group), 1, SCMP_CMP(0, SCMP_CMP_EQ, 0)) < 0) { seccomp_release(ctx); fprintf(stderr, "could not setup rule for exit_group\n"); return -1; }

11.06.2018 49

EXIT_GROUP

Systems Security – Secure Systems Engineering

slide-50
SLIDE 50

11.06.2018 50

DEMO TIME

Systems Security – Secure Systems Engineering

slide-51
SLIDE 51

▪ Only works on Linux ▪ You need to know which syscalls your application requires ▪ Might break with a libc upgrade ▪ Only filtering on the syscalls and their direct arguments ▪ Dereferencing of pointers not possible

11.06.2018 51

LIMITATIONS

Systems Security – Secure Systems Engineering

slide-52
SLIDE 52

Userspace Kernelspace Syscall handler Application Standard C library Call fprintf(…) write syscall trap into kernel space write handler Device driver Copy from userspace seccomp filter inspect Application 2

Modify memory

SYSCALLS EXAMPLE (FOR PRINTF/WRITE)

slide-53
SLIDE 53

▪ Very handy tool to implement sandboxes ▪ Rules can be generated dynamically ▪ However syscalls used by a program depend on the exact libc version

  • r runtime environment

▪ Might easily break when libraries are updated

11.06.2018 53

SECCOMP SUMMARY

Systems Security – Secure Systems Engineering

slide-54
SLIDE 54

▪ There is a random cat picture serving web server in the files sectin, written in (poor, ugly, unsafe) C ▪ Write a Seccomp patch for it ▪ Make sure only the currently used syscalls are allowed ▪ Rewrite the application to work with a minimal set of syscalls (Bonus) ▪ read, write, shutdown, close, exit* ▪ And add a corresponding seccomp patch

11.06.2018 54

SECCOMP ASSIGNMENT

Systems Security – Secure Systems Engineering

slide-55
SLIDE 55

▪ https://www.chromium.org/developers/design-documents/sandbox

11.06.2018 55

FURTHER READING

Systems Security – Secure Systems Engineering

slide-56
SLIDE 56

▪ Windows update in a nutshell ▪ Software downloads new software packages from a P2P network ▪ Packages are verified ▪ Packages are then installed ▪ They might overwrite every file on the system including the

  • perating system kernel

▪ How may we use the isolation and access control features from the lecture here?

56

ONE PROBLEM…

11.06.2018 Systems Security – Secure Systems Engineering

slide-57
SLIDE 57

▪ I don't need to explain what a webbrowser does ▪ Where does a webbrowser need to write to?

11.06.2018 57

ANOTHER THING

Systems Security – Secure Systems Engineering

slide-58
SLIDE 58

▪ Split different functionality with different access permissions into different modules ▪ Isolate those modules in different processes ▪ Apply different security policies to those processes ▪ Have clear and simple communication paths between those processes

11.06.2018 58

KEY IDEA

Systems Security – Secure Systems Engineering

slide-59
SLIDE 59

11.06.2018 59

A PATTERN: THE BROKER (REFERENCE MONITOR)

Systems Security – Secure Systems Engineering

Main Application "Safe as" dialog Request file handle Return file handle

slide-60
SLIDE 60

▪ Application to view pictures and videos on the local harddisk ▪ Easy browsing through all files in a directory ▪ How may we apply the pattern here?

11.06.2018 60

A PICTURE AND VIDEO VIEWER

Systems Security – Secure Systems Engineering

slide-61
SLIDE 61

▪ Supports chatting with friends ▪ Allows you to send and receive files

11.06.2018 61

A CHAT APPLICATION

Systems Security – Secure Systems Engineering

slide-62
SLIDE 62

▪ Needs access to your webcam when you would like to have a video conference ▪ Should not have access to your webcam when you are getting dressed in your room and you feel unwatched

11.06.2018 62

SKYPE (WHATSAPP, FACEBOOK MESSENGER…)

Systems Security – Secure Systems Engineering

slide-63
SLIDE 63

▪ Split your application into individual modules/layers ▪ Put either very insecure or highly privileged stuff into modules ▪ Have a clear separation between them ▪ Have a clear way of communication between them

11.06.2018 63

SUMMARY

Systems Security – Secure Systems Engineering