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 Systems Security – Secure Systems Engineering 2 11.06.2018
NEXT WEEK ▪ 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 Systems Security – Secure Systems Engineering 3 11.06.2018
SECURE SYSTEMS ENGINEERING HOW TO BUILD SECURE SYSTEMS ▪ Choose a good architecture ▪ Use methods from secure programming ▪ Run everything with the least privilege possible ▪ Have permanent monitoring and updates Systems Security – Secure Systems Engineering 4 11.06.2018
A GOOD ARCHITECTURE? Your application Systems Security – Secure Systems Engineering 5 11.06.2018
TYPICAL DESIGN FOR A WEB APPLICATION Web server Application Database Systems Security – Secure Systems Engineering 6 11.06.2018
TYPICAL DESIGN FOR A WEB APPLICATION User accounts Web server Application Database Systems Security – Secure Systems Engineering 7 11.06.2018
USING MICROSITES/MICROSERVICES Common Database services Application Web server Database Web server Application Database Application Web server Database Systems Security – Secure Systems Engineering 8 11.06.2018
DIFFERENT SECURITY ZONES Sensors and Robot Web frontend validation control Systems Security – Secure Systems Engineering 9 11.06.2018
SUMMARY FOR SECURITY FRIENDLY ARCHITECTURES ▪ 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 Systems Security – Secure Systems Engineering 10 11.06.2018
LEAST PRIVILEGE ▪ 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? Systems Security – Secure Systems Engineering 11 11.06.2018
DROPPING PRIVILEGES ON WEB APPLICATIONS ▪ 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
USING A CONTENT SECURITY POLICY Systems Security – Secure Systems Engineering 13 11.06.2018
EXAMPLES ▪ 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 Systems Security – Secure Systems Engineering 14 11.06.2018
ASSIGNMENT CSP ▪ There is a (poorly written) python app that allows you to search for US presidents ▪ Add a CSP for the app Systems Security – Secure Systems Engineering 15 11.06.2018
ISOLATION ▪ 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 Systems Security – Secure Systems Engineering 16 11.06.2018
ISOLATION FEATURES ON LINUX ▪ Namespaces ▪ Network ▪ IPC ▪ Mount (filesystem) ▪ Process ID ▪ UTS (Hostname) ▪ Control group Systems Security – Secure Systems Engineering 17 11.06.2018
AN EXAMPLE ▪ Try to run unshare Systems Security – Secure Systems Engineering 18 11.06.2018
DOCKER ▪ 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 Systems Security – Secure Systems Engineering 19 11.06.2018
A DEFAULT LINUX SYSTEM Kernel Application 1 Application 2 Application 3 Systems Security – Secure Systems Engineering 20 11.06.2018
LINUX WITH DOCKER Kernel Web container Database container Application 1 Application 2 Application 3 Systems Security – Secure Systems Engineering 21 11.06.2018
LINUX WITH XEN Xen Hypervisor Kernel Dom0 Kernel DomU Kernel DomU Management tools Application 1 App 2 App 3 Systems Security – Secure Systems Engineering 22 11.06.2018
LINUX WITH KVM Kernel Kernel Guest Kernel Guest Application 1 Application 2 App 3 App 4 Systems Security – Secure Systems Engineering 23 11.06.2018
LINUX WITH XEN AND KVM ▪ 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 Systems Security – Secure Systems Engineering 24 11.06.2018
DROPPING PRIVILEDGES ON LINUX ▪ 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 Systems Security – Secure Systems Engineering 25 11.06.2018
Prepare to react ct In Intern rnet 1 The text on this slide will instruct your audience on how to post. This 2 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, TXT 1 color, etc.) cannot be changed. 2 Posting messages is anonymous 14.05.2018
How can we drop priviledges on Linux? 1. Your 2. Your 3. Your audience's audience's audience's responses will responses will responses will appear here. appear here. appear here. Please feel free Please feel free Please feel free to change the to change the to change the font, color etc. font, color etc. font, color etc. This text This text This text disappears after disappears after disappears after starting your starting your starting your session and session and session and slideshow. slideshow. slideshow. Internet This text box will be used to describe the different message sending methods. # Messages: 0 TXT TXT The applicable explanations will be inserted after you have started a session.
BREAK ▪ When you like to, get a Linux vm up and running ▪ Download the seccomp-examples.zip from canvas
SYSCALLS ▪ 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
CODE EXAMPLE #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 ; } Systems Security – Secure Systems Engineering 30 11.06.2018
WORKING WITH SYSCALLS ON LINUX ▪ 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> Systems Security – Secure Systems Engineering 31 11.06.2018
RESULTS FOR THE EXAMPLE open("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 Systems Security – Secure Systems Engineering 32 11.06.2018
ARGUMENTS File handle open("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 Buffer length Buffer content to write Systems Security – Secure Systems Engineering 33 11.06.2018
SYSCALLS EXAMPLE (FOR PRINTF/WRITE) Application Call fprintf (…) Standard C library write syscall Copy from trap into userspace Userspace kernel space Kernelspace Syscall handler write handler Device driver
SYSCALLS ON LINUX ▪ 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 Systems Security – Secure Systems Engineering 35 11.06.2018
SECCOMP HIGH LEVEL OVERVIEW ▪ 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 Systems Security – Secure Systems Engineering 36 11.06.2018
Recommend
More recommend