Software security


Published on

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software security

  1. 1. 1 Corporate Information Security Software Security Jarno Niemelä
  2. 2. 2 Software Vulnerabilities ● Memory corruption attacks – – Signed and Unsigned values – ● Buffer Overflows Format string vulnerabilities Command injection attacks – – Cross site scripting – ● SQL injections Path escalations Access privilege attacks – SQL/HTTPD user able to create files – Applications having access outside of their own data domain Jarno Niemelä
  3. 3. 3 Buffer Overflows ● ● ● Buffer overflow is caused when program writes more data to buffer than is allocated for it This extra data can write over the function stack and return address Which means that instead of returning normally from function, attacker can direct the program to his own code ● This is called arbitrary code execution ● Simple example ● char buf[200]; gets(buf); Jarno Niemelä
  4. 4. 4 Unsigned To Signed Conversion Error ● ● Good code should always check all incoming data for correct size, but also that can be done badly char buffer[200]; int dataSize; if(dataSize<200) memcpy(buffer,data,dataSize); ● memcpy is expecting unsigned int and we are giving signed ● Which means that value will be converted unsiged int ● ● -1 in unsigned is 0xFFFFFFFF - 1= 4294967294 So in other words the check gives no protection Jarno Niemelä
  5. 5. Are Memory Corruption Attacks Really That Simple ● ● ● ● ● Yes, if we are talking about ancient code Modern OS memory management and compilers make exploiting memory corruption more difficult However with time and skill attackers still can take advantage of memory corruption This means that you have one smart guy discovering a vulnerability and creating exploit And then horde of less talented attackers using it Jarno Niemelä 5
  6. 6. 6 SQL injections ● ● SQL injection means attacker adding his own SQL commands over user input For example typical password check uses command – – What if you enter foo' or 1=1? – Select user from users where password='foo' or 1=1 – ● Select user from users where password='%s' Or “..where password='foo'; delete * from users; The problem is that unless programmer sanitizes all input attacker can close statement and continue with another SQL statament within same string Jarno Niemelä
  7. 7. 7 What Can Be Done With SQL Injections? ● ● Bypass password checks Alter operation, for example order password reset for any user to any email ● Modify database contents, for example prices in web shop ● Write files to system, execute files ● Basically anything that the SQL user is capable of Jarno Niemelä
  8. 8. 8 Format String Vulnerabilities ● String formatting is very powerful coding tool – ● Something simple as “ERROR file %s” not found can be bad – – ● But it can be like juggling with chainsaws If attacker can manipulate the file name he can include more format string options Which can result in buffer overflow or memory writes Also consider “select * from users where user=%s;” – Can become “select * from users where user=1; delete from users;” Jarno Niemelä
  9. 9. 9 Error Reports ● ● ● ● ● Probably everyone has seen badly written web pages that show very verbose error message. Sometimes even Java/etc stack trace is included This is a very bad practice as if site has SQL injection vulnerability the error report page can be used to leak information If attacker gets to insert his own SQL, he can print database contents instead of error reports Never show error details to user, have just nice clean error page and log all important information do not show it over the web. Jarno Niemelä
  10. 10. 10 How To Avoid Vulnerabilities ● ● ● ● There are many ways to detect and prevent programming errors that lead to vulnerability However with the amount of code being written it is practical impossibility to avoid vulnerabilities in large applications So instead of just trying to avoid errors applications have to be designed so that single error does not give full access to everywhere The principle is the same as with any other security – Build security in from the start – Modularize your system – Prevent, detect, respond, learn, improve Jarno Niemelä
  11. 11. Security Should Start In Architectural Level ● ● ● ● ● 11 Like in building security the earlier you plan security in the cheaper it will be in the long run So while you are planning architecture for your software, you also need to plan the security architecture for it Start security by defining software architecture document The document is needed to gather your thoughts just what you need to cover in order to create secure software By thinking about security right from the start you can minimize the need to modify things to make them secure later Jarno Niemelä
  12. 12. 12 Security In Software Architecture ● ● Start architectural planning from your business process, forget all about servers and technology for a moment Model all your business actions in conceptual level – – ● Imagine system components as people – ● Imagine the model as physical office Who can cheat and how Think ways how you can prevent your components from cheating Think what you need to create yourself and what you can get ready from others Jarno Niemelä
  13. 13. Things Software Architecture Should Cover ● How much security you need ● Standard engineering techniques you can employ ● Secure code and libraries you can use, are they secure? ● Your basic assumptions what you are protecting against ● Chain of trust between components ● Communications security between servers, don't be Google ● Error handling,failure tolerance and graceful degradation ● Safe default actions and values ● Multiple layers of defense ● Make sure someone is accountable for each major part ● Enemy Jarno Niemelä 13
  14. 14. 14 Software Design ● This is the part where money is either saved or wasted ● Make sure that your design follows security architecture ● ● When you design software, you have to make sure that things are inherently secure Fixing security problems when software is in production is 60 times more expensive than preventing it at design stage – Soo Hoo K, Sudbury AW, & Jaquith AR, Secure Business Quarterly, 5 pp, Q2 2001 Jarno Niemelä
  15. 15. 15 Secure Design Steps ● Access the risks and threats – – How much it costs – ● What can go wrong What legal requirements you have Adopt a risk mitigation strategy – Accept the risk (do nothing) – Minimize risk by reducing probability or damage – Transfer the risk to insurance or customers (banking, credit cards) Jarno Niemelä
  16. 16. 16 Secure Design Steps ● Construct mental models – ● Systems are hard to think about, so construct analogies Decide on high level technical issues – What language to use – How to authenticate users – How to audit that your program functions correctly – How to defend against attacks Jarno Niemelä
  17. 17. 17 Secure Design Steps ● Select security techniques and technologies – – What code verification tools to use – How to test against attacks – What third party security libraries and tools are needed – ● What development and testing tools to use How to ensure that tools do their job Plan operation and maintanance – How to monitor system performance – How to administer user accounts – How to backup and how to recover from total failure Jarno Niemelä
  18. 18. 18 Requirements For A Secure Design ● Each part of business process is isolated from others ● Each component has access only to data it needs ● Component that only reads data has no write access ● Component that only writes data has no read access ● ● ● Access to data is monitored and unnecessary reads are forbidden Components that handle only internal data must not communicate outside of business process What component does not need must be blocked Jarno Niemelä
  19. 19. 19 Secure Design Example ● ● You have web shop that needs database for inventory, pricing and transactions and transactions Should you place DB on same or different server? Same server Different server ● Cheaper ● ● Simpler to install ● ● Simpler to administrate ● Can be made secure ● But if security fails,all data is available to attacker Jarno Niemelä ● ● More expensive Web shop can be isolated from database Attack on web fronted does not give full access to database Easier to detect unauthorized access
  20. 20. 20 Results of Proper and Improper Design Both Kaspersky and F-Secure had SQL injections Kaspersky ● ● ● ● SQL injection in support form Leaked confidential data User names, activation codes, lists of bugs, admins, web show tables 178 news articles Jarno Niemelä F-Secure ● ● ● ● SQL injection in statistics server Isolated database DB contained only public data that was accessible from our statistics page anyway 41 news articles
  21. 21. 21 Security In Software Implementation ● Inform yourself – ● Handle data with caution – ● Allow other components to fail so that you can recover Create extensive unit tests – ● Don't trust anything that comes outside of your system Don't trust other components – ● Know how code is attacked so you can defend it Always test with bad data and attack code Create culture of code review and get tools for it – Make sure that all code is inspected by another developer Jarno Niemelä
  22. 22. 22 Inform Yourself ● You need to know all about attacks that apply to your code ● Fortunately there are a lot of information resources available – – – – ● Identify what languages and resources you are using and google around before starting to code Jarno Niemelä
  23. 23. 23 Handle Data With Caution ● Basically all exploits are based on feeding bad data – ● So handle data like a basket of snakes Always sanitize or parametrize all data – – For example in user names turn O'hara to O'hara – ● You need to know what is acceptable data, and filter it Or use libraries that do proper escaping for you Don't trust anything you read – – If you are reading something that has length information, don't trust it. Have safe maximum length Don't wait forever for data that does not arrive, always have timeout Jarno Niemelä
  24. 24. 24 Use System Access Controls ● Divide different parts of your application under different users, both system users and SQL users – ● Code that does not write, must have read only access. – ● For example JSP code that displays shop inventory Code that only writes does not need read access – ● Divide by function, web UI, support forms, transaction processor all need own users. Support form that stores user feedback does not need to be able to read what it has written If possible place each component to it's own container – And have monitoring script for extra files Jarno Niemelä
  25. 25. 25 Use Secure Coding Methods ● Know what functions are dangerous in your language – Find out what is safe alternative ● For example in C you have strcpy and strncpy ● Avoid building dynamic SQL – – ● Use parametrized queries so that input cannot modify statement In other words, use prepared statements or SQL functions Read secure coding resources for whatever language you are working on Jarno Niemelä
  26. 26. 26 Store Passwords Safely ● Never store them in cleartext, calculate hash and store that ● Don't use plain hash, they can be cracked in seconds ● Use salt to prevent rainbow tables (precalculation attacks) – – – ● Salt recipe: static random data+username+password This way attacker has to know your salt value before he can try dictionary or brute force attack on passwords However if attacker has system level access, he has your code and thus knows how your salt is formed What you want to use is something that is VERY slow to calculate, so bruteforcing will be >10000 slower than with simple SHA-1 or SHA-256 hash Jarno Niemelä
  27. 27. 27 Basic Version Of Slow Hash import hashlib ● hasher=hashlib.sha256() hashed_pw="password" salt="457897696840" ● user="joefoo" hasher.update(hashed_pw+user+salt) ● for i in xrange(124220): hasher.update(hasher.hexdigest()+user+salt) print hasher.hexdigest() ● ● ● Jarno Niemelä What we are doing here is feeding the password and two salts through SHA-256 hashing loop As each iteration of SHA-256 gets input from previous none of the iterations can be skipped Thus attacker has to spend 124220 times longer than with simple SHA-256 Procedure is known as key strengthening or streching The example code runs in about 0.5 seconds in my old desktop However it is not advisable to write your own implementation. Go with reviewed example code
  28. 28. 28 Well Known Slow Hash Implementations ● RSA PKCS #5: Password-Based Cryptography Standard – – ● PBKDF2 is well known hashing scheme that uses SHA-1 or other hash algorithm with multiple iterations Http:// Bcrypt, other well known slow password implementation – – ● Java: Python: Scrypt, is designed to make GPU based attacks unfeasible – Jarno Niemelä
  29. 29. 29 Have Separate Server For Passwords ● Password DB must not be in UI server ● Set up separate server with RESTful or other interface ● Only allowed messages are password query and response ● Thus frontend server compromise does not compromise DB ● Alternatively you can use OAuth and outsource authentication to Google, Facebook or other player – Provided that it suits your business model ● ● Jarno Niemelä
  30. 30. 30 Certificate Theft ● Software world is moving to application stores ● Which means attacker need certificates to make malware ● And even without stores certificate helps to hide ● This means that attackers are very interested in stealing code signing certificates or any other dev account ID ● We see code signed malware on daily basis ● And stolen certificates on almost every week ● keywords=&sort_by=id Jarno Niemelä
  31. 31. 31 Protect Your Signing Certificate ● Getting your certificate stolen is really bad PR ● Thus you need make sure your cert is not stolen ● At minimum code signing should be done on isolated server ● Better would be to use hardware security module for signing ● ● ● ● But even with HSM attacker can still make your code signing server to sign malware Thus you have to make sure that human always inspects what is being signed, or you have content monitoring Jarno Niemelä
  32. 32. 32 Protect Your SSL Certs ● Just like code signing certs SSL certs are a hot commodity ● However you must have them on your webserver ● Which is a bit of a dilemma ● ● ● You can store it by storing your SSL cert in HSM or use load balancer that does SSL acceleration ● Of course enterprise level HSM are rather expensive ● Commonly used alternative is to use passphrase a for key ● And secondary server that gives passphrase on request ● But this is not nearly as good as real security Jarno Niemelä
  33. 33. 33 Use Static Code Analyzers ● There are a lot of automatic tools that find bugs for yor ● For example Klocworks – – Tool that will analyze your code and tell how bad it is – ● SQL injection,Process or file injection,ode injection, Cross-site scripting (XSS), Request forging, etc But Klockworks is just automated tool, it does not find everything. Use it to save your time on bugs it does not find Jarno Niemelä
  34. 34. 34 Use Vulnerability Scanners ● ● Like network scanners there are many vulnerability scanners you can use to find problems in your code Burb suite is interactive scannert tool that allows to inspect possible application vulnerabilities – – – Other good tools Jarno Niemelä
  35. 35. 35 Fuzzers ● Exploits are basically broken input to your code ● Thus you can find vulnerabilities by generating a lot of input ● This is called fuzzing, it is very effective technique ● ● ● ● Simply mount your code so that it will receive constant stream of input from fuzzer, and let it run for couple days Radamsa is devils own fuzzer Given protocol or file sample it is bound to generate input that will find flaws in code that is not fuzzed before Fuzz before you get fuzzed Jarno Niemelä
  36. 36. 36 Don't Trust Any Network ● ● ● ● ● ● Only net you can trust is the one where you see cable Which means that you cannot trust connections between two of your data centers Or connections inside cloud hosted provider Even big players like Google had not encrypted connections between their own data centers Which means NSA had really easy time to access all the data they wanted Thus all connections between servers should be protected by properly implemented encryption Jarno Niemelä
  37. 37. 37 Security In Day To Day Operation ● Just building something to be secure is not enough ● You need to maintain the system properly ● ● ● ● Know all third party modules you are using, keep track of the security news on them When some component has vulnerability, make sure it is patched Keep track on new attack techniques, and test your systems against them Before SQL injections were known, almost all servers were vulnerable Jarno Niemelä
  38. 38. 38 Rules For Running Good Operation ● Rotate hardware often enough – ● 3 years should be maximum server lifespan Make sure you keep track of system buildup – – ● Log files can consume amazing amount of space over time What happens if /var or /tmp fills up? Create custom watchdogs in the system – ● If system does not get constant changes in file system, use integrity checker and alarm on any new files Make sure that also other than developers know how to fix the system. – Yes I know midnight phonecalls give nice bonus, but... Jarno Niemelä
  39. 39. 39 Application Firewalls ● Application firewalls are content inspecting firewalls that are placed between network connection and your application – Application firewalls know how the protocol works (HTTP) and can identify malicious content – Filter out SQL infections, Cross site scripting, etc – Basically they prevent the attack from ever getting into code ● ● ● Jarno Niemelä
  40. 40. 40 Application Firewalls Are Not Silver Bullet ● Even as application firewalls can prevent attacks they are not the final word in security ● App firewall protects only against attacks it knows about ● Also the firewall itself may be vulnerable to attack ● ● So if you think code cannot be trusted, and you cannot replace it, do use firewall But also start searching replacement for the bad code Jarno Niemelä
  41. 41. 41 References ● OWASP Application Security Community – ● Secure Coding Principles & Practices – ● O'Reilly, Mark G Graff & Kenneth R. van Wyk Format String Vulnerabilities – ● Stability Anti-Patterns – Jarno Niemelä