Question? Leave a message!




Top Ten Web Attacks

Top Ten Web Attacks 10
Top Ten Web Attacks Saumil Shah NetSquare BlackHat Asia 2002, SingaporeTodayÕs battleground Ð the Web TodayÕs battleground Ð the Web ¥ Web sites and web applications rapidly growing. ¥ Complex business applications are now delivered over the web (HTTP). ¥ Increased Òweb hackingÓ activity. ¥ Worms on the web. ¥ How much damage can be done ¥ FirewallsTypical Web Application setup Typical Web Application setup SQL HTTP Firewall Database request (cleartext or SSL) Web app DB Web app Web Web Web app Client Server DB Web app HTTP reply (HTML, ¥Apache Plugins: Database Javascript, ¥IIS ¥Perl connection: VBscript, ¥Netscape ¥C/C++ ¥ADO, etc) etcÉ ¥JSP, etc ¥ODBC, etc.Traditional HackingÉLimitations Traditional HackingÉLimitations ¥ Modern network architectures are getting more robust and secure. ¥ Firewalls being used in almost all network rollouts. ¥ OS vendors learning from past mistakes () and coming out with patches rapidly. ¥ Increased maturity in coding practices.Utility of Firewalls Utility of Firewalls ¥ Hacks on OS network services prevented by firewalls. Web app DB Web app Web Web app Server DB Web app wuftpd X X X X Sun RPC X X X X NT ipc X X X XUtility of Firewalls Utility of Firewalls ¥ Internal backend application servers are on a non routable IP network. Web app (private addresses) DB Web app Web Web app Server DB Web app X X X XUtility of Firewalls Utility of Firewalls ¥ Outbound access restricted. Why would a web server telnet out Web app DB Web app Web Web app Server DB Web app X X X XFutility of Firewalls Futility of Firewalls ¥ Ecommerce / Web hacking is unfettered. ¥ Web traffic is the most commonly allowed of protocols through Internet firewalls. ¥ Why fight the wall when youÕve got an open door ¥ HTTP is perceived as ÒfriendlyÓ traffic. ¥ Content/Application based attacks are still perceived as rare.The Web HackerÕs Toolbox The Web HackerÕs Toolbox Essentially, all a web hacker needs is É ¥ a web browser, ¥ an Internet connection, ¥ É and a clear mind.Classifying Web Hacks Classifying Web Hacks Web Hacks fall under the following categories: ¥ URL Interpretation attacks ¥ Input Validation attacks ¥ SQL Injection attacks ¥ Impersonation attacks ¥ Buffer Overflow attacksFirewalls cannot preventÉ Firewalls cannot preventÉ Web Web Client Server ¥ URL Interpretation Attacks. web server mis configurationFirewalls cannot preventÉ Firewalls cannot preventÉ Web app Web app Web Web Web app Client Server Web app ¥ Input Validation attacks. URL poor Interpretation checking attacks of user inputsFirewalls cannot preventÉ Firewalls cannot preventÉ Web app DB Web app Web Web Web app Client Server DB Web app ¥ SQL Query Poisoning URL Input Extend SQL Interpretation Validation statements attacks attacksFirewalls cannot preventÉ Firewalls cannot preventÉ Reverse engineering HTTP cookies. Web app DB Web app Web Web Web app Client Server DB Web app ¥ HTTP session hijacking. URL Input SQL query ¥ Impersonation. Interpretation Validation poisoning attacks attacksWhy is Web Hacking so deadly Why is Web Hacking so deadly ¥ Ports 80 and 443 are usually allowed through firewalls. ¥ A single URL works its way into may components. ¥ And in most cases, the only defense is Òsecure codingÓ.The URL as a cruise missile The URL as a cruise missile http: // 10.0.0.1 / catalogue / display.asp pg = 1 product = 7 Web app DB Web app Web Web app Server DB Web appWeb Hacks net effects Web Hacks net effects Web Hacks cause three types of effects: ¥ Extra information disclosure. (paths, etc.) ¥ Source code and arbitrary file content disclosure. ¥ Extra data disclosure (e.g. return all rows) ¥ Arbitrary command execution.The Web HackerÕs Toolbox The Web HackerÕs Toolbox Some desired accessories would be É ¥ a port scanner, ¥ netcat, ¥ vulnerability checker (e.g. whisker), ¥ OpenSSL, É etc.Hacking over SSL Hacking over SSL ¥ SSL Myth: ÒStrong 128 bit crypto stops hackers dead in their tracksÓ ¥ Using netcat and OpenSSL, it is possible to create a simple twoline SSL Proxy ¥ Listen on port 80 on a host and redirect requests to port 443 on a remote host through SSL. nc SSL web web client openssl serverThe Top 10 Web Hacking Techniques The Top 10 Web Hacking Techniques 1. URL Misinterpretation 2. Directory Browsing 3. Retrieving ÒnonwebÓ Files 4. Reverse Proxying 5. Java DecompilationThe Top 10 Web Hacking Techniques The Top 10 Web Hacking Techniques 6. Source Code Disclosure 7. Input Validation 8. SQL Query Poisoning 9. Session Hijacking 10.Buffer Overflows1. URL Misinterpretation 1. URL Misinterpretation ¥ The web server fails to parse the URL properly. ¥ e.g. the Unicode / Superfluous decode attack. ¥ Mismatched resource mappings in the configuration. ¥ e.g. +.htr, .JSP, Java remote command execution, etc.1. URL Misinterpretation 1. URL Misinterpretation Countermeasures: ¥ Usually require a vendor supplied fix. ¥ Thorough inspection of the web server configuration and bindings.2. Directory Browsing 2. Directory Browsing ¥ Ability to retrieve complete directory listing within directories on the web server. ¥ Usually happens when the default document is missing. ¥ Notsostrict Web server configuration.2. Directory Browsing 2. Directory Browsing Countermeasures: ¥ Web server configuration lockdown. ¥ Disable serving of directory listings. ¥ Sometimes the error may require a vendor supplied fix.3. Retrieving ÒnonwebÓ Files 3. Retrieving ÒnonwebÓ Files ¥ ÒNonwebÓ files can be: ¥ Archive files (.zip, .tar.gz, etc) ¥ Backup files (.bak, , etc) ¥ Header / Include files (.inc, .asa, etc) ¥ Text files (readme.txt, etc) ¥ Can be retrieved with some guess work. ¥ e.g. if there is a directory called /reports/, look for Òreports.zipÓ.3. Retrieving ÒnonwebÓ Files 3. Retrieving ÒnonwebÓ Files Countermeasures: ¥ Eliminate careless presence of such files. ¥ Disable serving certain file types by creating a resource mapping. ¥ Strict change control measures.4. Reverse Proxying 4. Reverse Proxying ¥ Web proxy servers may work both ways ¥ Typically meant to allow users from within a network to access external web sites. ¥ May end up proxying HTTP requests from the outside world to the internal network. ¥ e.g. Compaq Insight Manager ¥ Usually happens when the front end web server proxies requests to back end app servers.4. Reverse Proxying 4. Reverse Proxying Countermeasures: ¥ Check the web server proxy configuration thoroughly. ¥ Be careful when creating URL mappings to internal servers.5. Java Decompilation 5. Java Decompilation ¥ Java Bytecode can be decompiled quite effectively. ¥ May disclose sensitive information such as passwords, application paths, etc. ¥ May also disclose application logic Ð such as generation of session IDs, encryption, etc. ¥ Java Archive files (.jar files) may contain files other than bytecode, such as configuration files.5. Java Decompilation 5. Java Decompilation Countermeasures: ¥ Java bytecode obfuscation. ¥ Elimination of sensitive configuration information within bytecode. ¥ Elimination of unnecessary files within .jar files.6. Source Code Disclosure 6. Source Code Disclosure ¥ Ability to retrieve application files in an unparsed manner. ¥ Attackers can recover the source code of the web application itself. ¥ The code can then be used to find further loopholes / trophies. ¥ May be caused my many ways: ¥ Misconfiguration or vendor errors ¥ Poor application design, etc.6. Source Code Disclosure 6. Source Code Disclosure Countermeasures: ¥ Vendor supplied fixes. ¥ Locking down the web server configuration. ¥ Secure coding practices.7. Input Validation 7. Input Validation ¥ Root cause of most web hacks. ¥ All inputs received should be validated: ¥ data types ¥ data ranges (e.g. ve or fractional numbers) ¥ buffer sizes and bounds ¥ metacharacters ¥ Tampering with hidden fields. ¥ Bypassing client side checking (e.g. javascript).7. Input Validation 7. Input Validation Countermeasures: ¥ These are the worst to deal with ¥ There is no other countermeasure but proper coding practices.8. SQL Query Poisoning 8. SQL Query Poisoning ¥ Parameters from the URL or input fields get used in SQL queries. ¥ An instance of Input Validation attacks. ¥ Data can be altered to extend the SQL query. ¥ e.g. http://server/query.aspitem=3+OR+1=1 ¥ Execution of stored procedures. ¥ May even lead to backend database server compromise.8. SQL Query Poisoning 8. SQL Query Poisoning Countermeasures: ¥ Again, no easy fix. ¥ Thorough source code review. ¥ Following the principle of least privilege for the database application. ¥ Elimination of unnecessary database users and stored procedures.9. Session Hijacking 9. Session Hijacking ¥ HTTP is inherently a ÒstatelessÓ protocol. ¥ Many web applications are stateful. ¥ Poor mechanisms of state tracking. ¥ Hidden fields carrying a session ID ¥ Client side cookies ¥ É with no server side session tracking. ¥ Reverse engineering of the session ID leads to access of other usersÕ data.9. Session Hijacking 9. Session Hijacking Countermeasures: ¥ Use server side session ID tracking. ¥ Match connections with time stamps, IP addresses, etc. ¥ Cryptographically generated session IDs. ¥ hard to sequence. ¥ Use web application server session management APIs when possible.10. Buffer Overflows 10. Buffer Overflows ¥ Poor bounds checking. ¥ Web server HTTP requests. ¥ e.g. ASP buffer overflow, .printer, etc. ¥ Application Input fields. ¥ e.g. ColdFusion DoS, etc. ¥ Can cause: ¥ Denial of service (crashing the app / service) ¥ Remote command execution (shellcode)10. Buffer Overflows 10. Buffer Overflows Countermeasures: ¥ Vendor supplied fixes. ¥ Bounds checking within applications. ¥ Source code reviews. ¥ Buffer overflow testing.Hacking Web enabled Devices Hacking Web enabled Devices ¥ Network equipment, printers, etc. becoming Òweb enabledÓ. ¥ e.g. Cisco IOS HTTP hack, HP WebJetAdmin hack, etc. ¥ May leak sensitive information about a network. ¥ May allow proxying of web attacks.Beating the IDS Beating the IDS ¥ ÒSecure HackingÓ Ð hacking over SSL. ¥ Many ways of writing the same URL. ¥ Defeats signature based pattern matching. ¥ Spurious parameters. ¥ Intentionally generating false positives.Closing Thoughts Closing Thoughts ¥ Far harder to secure web sites and web applications. ¥ Need to create a heightened levels of security awareness. ¥ Use of formal software engineering methods for developing web applications. ¥ Use of secure coding practices. ¥ Thorough application testing.Closing Thoughts Closing Thoughts ¥ ÒThere is no patch for carelessnessÓ. ¥ Web Hacking: Attacks and Defense Saumil Shah, Shreeraj Shah, Stuart McClure Addison Wesley Ð 2002.Thank you saumilnetsquare.com http://www.netsquare.com/ +91 98254 31192
Website URL
Comment