P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\titulka.jpg PA193 - Secure coding principles and practices Defense in depth •Petr Švenda svenda@fi.muni.cz • Based on slides by Zdeněk Říha P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg D:\Documents\Obrázky\is2\Plain-Blue-icon.png What prevents malicious code on server? | PA193 - Defense in depth D:\Documents\Obrazky\is2\Home-Server-icon.png Where would you attack? Where is defense in depth applied? How many layers are present? Are these layers independent? D:\Documents\Obrazky\question.png devil Internet Server Malicious code 2 rm -rf Malicious code execution on remote server Firewall, antivirus, ADSL, DEP, filtering on Many layers => is it perfect? (no) How to bypass? Phishing P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Layers of defense •Code/setup review –Manual review, fuzzing, static/dynamic analysis, pentests… (prevention) •Network level –IDS, ISP filtering, firewall… (prevent reaching server) •Host level –User authentication, HTTPS… (limit attack surface) –Antivirus, Sandboxing… (if attacker reach the application) –ASLR, DEP… (if code is executed) –Access rights (low-priority user) –DMZ/Virtualization (if whole server is compromised) –… • 3 | PA193 - Defense in depth P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Defense in depth •It is an general approach/concept/strategy •You have to apply it in your concrete project •You have to think as an attacker –Then select appropriate defenses/measures •Your need to be able to find your weakest point –And make sure that the weakest point is strong enough • •This lecture will give you some hints – | PA193 - Defense in depth 4 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg ACKNOWLEDGEMENT •Original slides made by Zdeněk Říha, •existing and new mistakes responsibility of me 5 | PA193 - Defense in depth P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Defense in depth: Definition (Wikipedia) •Non-IT: “defense in depth (also known as deep or elastic defense) is a military strategy; it seeks to delay rather than prevent the advance of an attacker, buying time and causing additional casualties by yielding space.” •IT: “defense in depth is an information assurance concept in which multiple layers of security controls (defense) are placed throughout an IT system. Its intent is to provide redundancy in the event a security control fails or a vulnerability is exploited that can cover aspects of personnel, procedural, technical and physical for the duration of the system's life cycle.” | PA193 - Defense in depth 6 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Defense in depth – key features •IT: “defense in depth is an information assurance concept in which multiple layers of security controls (defense) are placed throughout an IT system. Its intent is to provide redundancy in the event a security control fails or a vulnerability is exploited that can cover aspects of personnel, procedural, technical and physical for the duration of the system's life cycle.” • 7 | PA193 - Defense in depth P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Defense in depth – application code •Code fails. We have to take it as a fact. All code has a nonzero likelihood of containing one or more vulnerabilities •You need to change your outlook from "my code is very good quality" to "though my code is the best it can be with today's knowledge, it likely still has security defects.“ –Michael Howard, Attack Surface (MSDN) | PA193 - Defense in depth 8 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Basic concepts •Simplicity –Keep it simple (stupid) principle - KISS •Compartmentalization –Principle of least privilege –Minimize needed trust •Expect failures –Use more than one security mechanism (layered) –Secure the weakest link, Fail securely •Work in team –Everyone can design defense he/she cannot breach –Do not reinvent wheel, Code review, tools | PA193 - Defense in depth 9 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg KISS principle •Keep it as simple as possible –KISS – Keep it Simple Stupid –“Invented” in 1960s in aviation industry •Simplicity –Less things can go wrong –Fewer possible inconsistencies –Code is easier to understand –When errors occur, they are easier to understand and fix •Pay attention to interfaces and interactions | PA193 - Defense in depth 10 KISS principle: “Keep It Simple, Silly” (often stronger pejoratives are substituted for “silly) Simplicity refers to all dimensions: design, implementation, operation, interaction with other components, even in specification. The toolkit philosophy of the UNIX system is excellent here; each tool is designed and implemented to perform a single task. The tools are then put together. This allows the checking of each component, and then their interfaces. It is conceptually much less complex than examining the unit as a whole. The key, though, is to define all interfaces completely (for example, environment variables and global variables as well as parameter lists). P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Keep It Simple •Don’t add unnecessary features –Additional functionality means more ways to attack •Use simple algorithms that are easy to verify –Premature optimizations –‘Hacks’ in code makes it •More difficult to understand •More difficult to maintain | PA193 - Defense in depth 11 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg FreeBSD-SA-11:08.telnetd II. Problem Description When an encryption key is supplied via the TELNET protocol, its length is not validated before the key is copied into a fixed-size buffer. III. Impact An attacker who can connect to the telnetd daemon can execute arbitrary code with the privileges of the daemon (which is usually the "root" superuser). IV. Workaround No workaround is available, but systems not running the telnet daemon are not vulnerable. | PA193 - Defense in depth 12 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Compartmentalization •Divide system into modules –Each module serves a specific purpose –Different modules will have different access rights –The access rights are related to activities •Example application: 1.Need access to files 2.Reads user or network input 3.Execute privileged instructions (under root UID) •Real example: –Apache vs. suEXEC – | PA193 - Defense in depth 13 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg suEXEC - example •User “Alice” has a website including some CGI scripts in her own public_html folder, which can be accessed by http://server/~alice. •Bob now views Alice's webpage, which requires Apache to run one of these CGI scripts. •Instead of running all scripts as “wwwrun”, the scripts in /home/alice/public_html will be wrapped using suEXEC and run with Alice's user ID resulting in higher security and eliminating the need to make the scripts readable and executable for all users or everyone in the "wwwrun" group. • • | PA193 - Defense in depth 14 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Least Privilege •A subject should be given only those privileges necessary to complete its task –Function, not identity, controls –Rights added as needed and discarded after use (!) •The original formulation from Jerome Saltzer –“Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job.” •Dynamic assignments of privileges was later discussed by Roger Needham and others | PA193 - Defense in depth 15 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Least Privilege - example •On UNIX-based systems binding a program to a port number <1024 requires root privilege. –(Let’s ignore modern ‘capabilities’ at this moment) •Many internet servers listening on well known ports (like webserver on port 80, mailserver on port 25 etc.) need to be run with root privilege. •As soon as the port is bound the process should drop the root privilege as it is typically not needed anymore. •Many programs keep running with the root privileges. –After a successful attack against the process the attacker receives the power of root –“Sendmail” was well known for problems of this kind •Visual Studio required Admin privileges for long time => developers were admins => programs were requiring admin privileges to execute | PA193 - Defense in depth 16 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Minimize needed trust •Minimize trust relationships •Clients, servers should not trust each other –all can get hacked –can be manipulated by users •Trusted code should not call untrusted code •Do not trust the input (!) –Separate lecture on input validation will follow •Do not trust the communication channel –Use encryption, data authentication etc. –Separate lecture on secure channel will follow | PA193 - Defense in depth 17 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Example: Web security •Web server + web client •Simple HTML form (FORM,INPUT,TEXT,MAXLENGTH, …) •Validity of fields checked by Javascript on clientside MC900424790[1] MC900195258[1] | PA193 - Defense in depth 18 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Example: Web security (2) | PA193 - Defense in depth 19 •It is easy to avoid these checks –Disable Javascript –Send the “filled” form directly –Tools (e.g. python request module) P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Example: Web security (3) •The server cannot trust that the input received from the web browser will be correct with respect to the limitations specified –E.g. MAXLENGTH attribute of the INPUT fields –E.g. values will be check by the Javascript functions •It is easy to avoid these checks –Disable Javascript –Send the “filled” form directly –Tools (e.g. python request module) MC900424790[1] MC900441338[1] | PA193 - Defense in depth 20 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Fail defaults •Blacklist vs. Whitelist •Example: firewall –Default action is to drop packets –The administrator configures the firewall to allow only the packet types deemed acceptable though •Example: input filtering –E.g. HTML tags in blog posts • | PA193 - Defense in depth 21 P:\CRCS\2012_0178_Redesign_loga_a_JVS\PPT_prezentace\sablona\pracovni\normalni.jpg Example - Blacklisting of HTML tags •E.g. blocking the tags –‘applet’, ‘body’, ‘bgsound’, ‘base’, ‘basefont’, ‘embed’, ‘frame’, ‘frameset’, ‘head’, ‘html’, ‘id’, ‘iframe’, ‘ilayer’, ‘layer’, ‘link’, ‘meta’, ‘name’, ‘object’, ‘script’, ‘style’, ‘title’, ‘xml’ •A new version of HTML arrives (e.g. HTML5) –New tags (like