secure systems engineering
play

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


  1. SECURE SYSTEMS ENGINEERING ERIK TEWS <E.TEWS@UTWENTEL.NL>

  2. 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

  3. 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

  4. 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

  5. A GOOD ARCHITECTURE? Your application Systems Security – Secure Systems Engineering 5 11.06.2018

  6. TYPICAL DESIGN FOR A WEB APPLICATION Web server Application Database Systems Security – Secure Systems Engineering 6 11.06.2018

  7. TYPICAL DESIGN FOR A WEB APPLICATION User accounts Web server Application Database Systems Security – Secure Systems Engineering 7 11.06.2018

  8. 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

  9. DIFFERENT SECURITY ZONES Sensors and Robot Web frontend validation control Systems Security – Secure Systems Engineering 9 11.06.2018

  10. 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

  11. 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

  12. 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

  13. USING A CONTENT SECURITY POLICY Systems Security – Secure Systems Engineering 13 11.06.2018

  14. 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

  15. 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

  16. 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

  17. ISOLATION FEATURES ON LINUX ▪ Namespaces ▪ Network ▪ IPC ▪ Mount (filesystem) ▪ Process ID ▪ UTS (Hostname) ▪ Control group Systems Security – Secure Systems Engineering 17 11.06.2018

  18. AN EXAMPLE ▪ Try to run unshare Systems Security – Secure Systems Engineering 18 11.06.2018

  19. 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

  20. A DEFAULT LINUX SYSTEM Kernel Application 1 Application 2 Application 3 Systems Security – Secure Systems Engineering 20 11.06.2018

  21. LINUX WITH DOCKER Kernel Web container Database container Application 1 Application 2 Application 3 Systems Security – Secure Systems Engineering 21 11.06.2018

  22. 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

  23. 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

  24. 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

  25. 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

  26. 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

  27. 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.

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

  29. 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

  30. 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

  31. 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

  32. 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

  33. 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

  34. 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

  35. 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

  36. 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

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend