Differences between revisions 8 and 15 (spanning 7 versions)
Revision 8 as of 2010-04-20 03:44:12
Size: 8588
Editor: c-71-226-185-105
Comment:
Revision 15 as of 2010-04-20 03:48:38
Size: 8130
Editor: c-71-226-185-105
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:

Link to PDF of powerpoint presentation
http://dl.dropbox.com/u/68566/WebHacking.pdf
Link to PDF of powerpoint presentation http://dl.dropbox.com/u/68566/WebHacking.pdf
Line 8: Line 5:
 *In the early days of web hacking the web server was often the main target.
 *Now days vulnerabilities in server software are widely publicized and easy to detect and attack and protect.
 *Fewer and fewer vulnerabilities are showing up because…
 * In the early days of web hacking the web server was often the main target.
 * Now days vulnerabilities in server software are widely publicized and easy to detect and attack and protect.
 * Fewer and fewer vulnerabilities are showing up because…
Line 14: Line 11:

---- /!\ '''Edit conflict - other version:''' ----
  * Proactive countermeasures are fast becoming standard (Watchfire’s App''''''''Sheild, Microsoft’s URLScan, etc.)

---- /!\ '''Edit conflict - your version:''' ----
Line 21: Line 13:
---- /!\ '''End of edit conflict''' ----
  * Automated vulnerability-scanning products that can quickly check common problems
Line 25: Line 14:
 *Web server vulnerabilities tend to fall into one of the following categories:  * Web server vulnerabilities tend to fall into one of the following categories:
Line 27: Line 16:
  *Source code disclosure
  *Canonicalization
  *Server extensions
  *Input validation (ex. Buffer overflows)
  * Source code disclosure
  * Canonicalization
  * Server extensions
  * Input validation (ex. Buffer overflows)
Line 33: Line 22:
 *With more and more features in web software, developers are adding in more sample code and scripts to show what can be done.
 *If left in place the sample files can become an easy target for hackers.
 *Ex. IIS4 had two sample files that let hackers remote access and reveal the contents of just about every other file on the server.
 * With more and more features in web software, developers are adding in more sample code and scripts to show what can be done.
 * If left in place the sample files can become an easy target for hackers.
 * Ex. IIS4 had two sample files that let hackers remote access and reveal the contents of just about every other file on the server.
Line 38: Line 27:
 *Allow a malicious user to view the source code of application files on a vulnerable web server that is intended to remain confidential.
 *Can combine this with other attacks to gain access to protected areas such as /etc/passwd, etc.
 *Good practice to assume your web files will be seen, and should never store sensitive data in any source code.
 * Allow a malicious user to view the source code of application files on a vulnerable web server that is intended to remain confidential.
 * Can combine this with other attacks to gain access to protected areas such as /etc/passwd, etc.
 * Good practice to assume your web files will be seen, and should never store sensitive data in any source code.
Line 43: Line 32:
 *Computer and network resources can often be addressed using more than one way.
 *Ex. C:\text.txt ; ..\\text.txt ; \\computer\C$\text.txt
 *Apps that make security decisions based on the resource name can be vulnerable to these attacks, and easily fooled.
 *Make sure to keep web platforms up to date with all patches.
 *Compartmentalize your directory structure.
 *Constrain input using platform-layer solutions (MS’s URLScan) to strip unicode or double-hex-encoded characters before reaching the server.
 * Computer and network resources can often be addressed using more than one way.
 * Ex. C:\text.txt ; ..\\text.txt ; \\computer\C$\text.txt
 * Apps that make security decisions based on the resource name can be vulnerable to these attacks, and easily fooled.
 * Make sure to keep web platforms up to date with all patches.
 * Compartmentalize your directory structure.
 * Constrain input using platform-layer solutions (MS’s URLScan) to strip unicode or double-hex-encoded characters before reaching the server.
Line 51: Line 40:
 *Web servers by themselves are minimal in functionality, extensions add a lot to the web experience
 *With web extensions also come trouble
 *MS’s indexing extension, IPP, IIS5, WebDAV, SSL, etc all are extensions and all have had their fair share of security holes
 *Make sure you patch or disable the vulnerable extension. In general make sure you only run extensions that are needed and nothing more
 * Web servers by themselves are minimal in functionality, extensions add a lot to the web experience
 * With web extensions also come trouble
 * MS’s indexing extension, IPP, IIS5, WebDAV, SSL, etc all are extensions and all have had their fair share of security holes
 * Make sure you patch or disable the vulnerable extension. In general make sure you only run extensions that are needed and nothing more
Line 57: Line 46:
 *Buffer overflow attack symbolizes the coup de grace of hacking
 *Often result in the ability to execute arbitrary commands on the victim machine, with very high privilege levels
 *Easiest way to counter buffer overflow vulnerabilities is to apply a software patch
 * Buffer overflow attack symbolizes the coup de grace of hacking
 * Often result in the ability to execute arbitrary commands on the victim machine, with very high privilege levels
 * Easiest way to counter buffer overflow vulnerabilities is to apply a software patch
Line 62: Line 51:
 *Tools that automate the process of parsing web servers for a bunch of vulnerabilities that come from the hacking community
 *Allows you to focus on patching the holes that are found when the automated process is done, make sure to patch them fast because a hacker can find them easily too
 *Ex. Nikto, and Nessus
 
 * Tools that automate the process of parsing web servers for a bunch of vulnerabilities that come from the hacking community
 * Allows you to focus on patching the holes that are found when the automated process is done, make sure to patch them fast because a hacker can find them easily too
 * Ex. Nikto, and Nessus
Line 67: Line 56:
 *Web app hacking refers to hacking the app itself and not the web server
 *Requires more patience and sophistication then hacking off the shelf web server software
 * Web app hacking refers to hacking the app itself and not the web server
 * Requires more patience and sophistication then hacking off the shelf web server software
Line 71: Line 60:
 *Search engines are dangerous because users are careless
 *Makes finding candidate machines almost effortless
 *Find list of publicly accessible pages    *Site:southern.edu; inurl:southern.edu
 *Find unprotected directories
  *Index of /admin” /password, /mail, password.txt
 *Find password hint applications that are poorly setup
  *Password hint, password hint –email, show password hint –email, filetype:htaccess user
 * Search engines are dangerous because users are careless
 * Makes finding candidate machines almost effortless
 * Find list of publicly accessible pages
  *
Site:southern.edu; inurl:southern.edu
 * Find unprotected directories
  * Index of /admin” /password, /mail, password.txt
 * Find password hint applications that are poorly setup
  * Password hint, password hint –email, show password hint –email, filetype:htaccess user
Line 81: Line 70:
 *A serious attacker takes the time to become familiar with the application
 *Download entire contents of site, look for low hanging fruit
  *Local path info, back-end server names, IP address, SQL query strings with passwords, info comments, etc
 *Tools
  *wget to get entire websites which can then be used to study later in great detail
 * A serious attacker takes the time to become familiar with the application
 * Download entire contents of site, look for low hanging fruit
  * Local path info, back-end server names, IP address, SQL query strings with passwords, info comments, etc
 * Tools
  * wget to get entire websites which can then be used to study later in great detail
Line 88: Line 77:
 *Once target app content has been crawled and analyzed attacker will then turn to more in-depth probing
 *Ultimate goal of this is to thoroughly understand the architecture and design of the application and identify any weaknesses
 *Focus on authentication, session management, database interaction, generic input validation, and application logic
 * Once target app content has been crawled and analyzed attacker will then turn to more in-depth probing
 * Ultimate goal of this is to thoroughly understand the architecture and design of the application and identify any weaknesses
 * Focus on authentication, session management, database interaction, generic input validation, and application logic
Line 93: Line 82:
 *Browser plug-ins allow you to view the requests as they are made and stop, and modify them on their way
 *Very valuable in finding hidden form fields, modifying query arguments and request headers, and inspecting the response from the remote server
 *TamperData is a plug-in for Firefox coupled with no-script can selectively run and edit JavaScript
 * Browser plug-ins allow you to view the requests as they are made and stop, and modify them on their way
 * Very valuable in finding hidden form fields, modifying query arguments and request headers, and inspecting the response from the remote server
 * !TamperData is a plug-in for Firefox coupled with no-script can selectively run and edit !JavaScript
Line 98: Line 87:
 *Web proxies that are in between the web client and server
 *Basically a man-in-the-middle during an http session
 *Fiddler can be used with any WinINET library software, IE, Outlook, Office, etc
 *Fiddler can adjust files on the way
  *Ex. bpu .css
 * Web proxies that are in between the web client and server
 * Basically a man-in-the-middle during an http session
 * Fiddler can be used with any WinINET library software, IE, Outlook, Office, etc
 * Fiddler can adjust files on the way
  * Ex. bpu .css
Line 105: Line 94:
 *The main categories are
  *Cross-Site Scripting (XSS)
  *Injection Flaws
  *Cross-Site Request Forgery (CSRF)
 * The main categories are
  * Cross-Site Scripting (XSS)
  * Injection Flaws
  * Cross-Site Request Forgery (CSRF)
Line 111: Line 100:
 *Arise from input/output validation deficiencies in web applications
 *Attacks other users of the page
  *Ex. Attacker puts code in guestbook online, people who view guestbook has the attackers code executed, potentially giving attacker control of second users’ system
 *Counter with filter input parameters for special characters. Ex. < > ( ) # & “
 * Arise from input/output validation deficiencies in web applications
 * Attacks other users of the page
  * Ex. Attacker puts code in guestbook online, people who view guestbook has the attackers code executed, potentially giving attacker control of second users’ system
 * Counter with filter input parameters for special characters. Ex. < > ( ) # & “
Line 117: Line 106:
 *Adjusting the SQL to point it at a file you wish to view
 *Is a problem because by default a web browser is a “trusted” user.
 *Counter measures
  *Perform strict input validation on any input from the client
  *Replace direct SQL statements with stored procedures, prepared statements    *Implement defaut error handling
  *Lock down ODBC
  *Lock down database server configuration
 * Adjusting the SQL to point it at a file you wish to view
 * Is a problem because by default a web browser is a “trusted” user.
 * Counter measures
  * Perform strict input validation on any input from the client
  * Replace direct SQL statements with stored procedures, prepared statements
  *
Implement defaut error handling
  * Lock down ODBC
  * Lock down database server configuration
Line 127: Line 116:
 *Known about for nearly a decade, but just now becoming a serious problem
 *Allows for users to stay logged in without having to authenticate after each page load
 *Can cause problems for the users, passwords changed, funds transferred, merchandise purchased, and more.
 *Attacker puts image tag in a real page that a user is already logged in to and when the browser requests the link instead of an image it is a url string that can change the password for example.
  *&<img src=http://example.com/update_account.asp?new_password=evil>
 *Conutermeasures
  *Tying the incoming request to the auth. session. Use random values, tied to the specified user’s session. If it doesn’t match have them re authenticate their connection.
 * Known about for nearly a decade, but just now becoming a serious problem
 * Allows for users to stay logged in without having to authenticate after each page load
 * Can cause problems for the users, passwords changed, funds transferred, merchandise purchased, and more.
 * Attacker puts image tag in a real page that a user is already logged in to and when the browser requests the link instead of an image it is a url string that can change the password for example.
  *<img src=http://example.com/update_account.asp?new_password=evil>
 * Conutermeasures
  * Tying the incoming request to the auth. session. Use random values, tied to the specified user’s session. If it doesn’t match have them re authenticate their connection.
Line 136: Line 125:
 *Allows attackers to adjust hidden fields before being sent to the server for processing
 *Business should not have price of item set as a hidden form   *Would be very easy to adjust the price
 *Countermeasures
  *Limit the use of hidden tags, or at least confirm the value before processing
 * Allows attackers to adjust hidden fields before being sent to the server for processing
 * Business should not have price of item set as a hidden form
 *
Would be very easy to adjust the price
 * Countermeasures
  * Limit the use of hidden tags, or at least confirm the value before processing
Line 144: Line 133:
||<#32CD32> Sample files, Source code disclosure, Canonicalization, Server extensions, Input validation(ex. Buffer overflow) || ||<#32cd32>Sample files, Source code disclosure, Canonicalization, Server extensions, Input validation(ex. Buffer overflow) ||



Line 146: Line 139:
||<#32cd32>!TamperData or Fiddler ||
Line 147: Line 141:
---- /!\ '''Edit conflict - other version:''' ----
||<#32CD32> Tamper''''''Data or Fiddler ||
Line 150: Line 142:
---- /!\ '''Edit conflict - your version:''' ----
||<#32CD32> !TamperData or Fiddler ||
Line 153: Line 143:
---- /!\ '''End of edit conflict''' ----
Line 155: Line 145:
||<#32CD32> wget || ||<#32cd32>wget ||



Line 157: Line 151:
||<#32CD32> Using search engines || ||<#32cd32>Using search engines ||

Ch 11 - Web Hacking

Link to PDF of powerpoint presentation http://dl.dropbox.com/u/68566/WebHacking.pdf

Early Days

  • In the early days of web hacking the web server was often the main target.
  • Now days vulnerabilities in server software are widely publicized and easy to detect and attack and protect.
  • Fewer and fewer vulnerabilities are showing up because…
    • Vendors and open-source are learning from past mistakes
    • Sys. Admins are learning how to better configure
    • Vendors and open-source are responding faster to patches
    • Proactive countermeasures are fast becoming standard (Watchfire’s AppSheild, Microsoft’s URLScan, etc.)

Current Vulnerabilities

  • Web server vulnerabilities tend to fall into one of the following categories:
    • Sample files
    • Source code disclosure
    • Canonicalization
    • Server extensions
    • Input validation (ex. Buffer overflows)

Sample Files

  • With more and more features in web software, developers are adding in more sample code and scripts to show what can be done.
  • If left in place the sample files can become an easy target for hackers.
  • Ex. IIS4 had two sample files that let hackers remote access and reveal the contents of just about every other file on the server.

Source Code Disclosure

  • Allow a malicious user to view the source code of application files on a vulnerable web server that is intended to remain confidential.
  • Can combine this with other attacks to gain access to protected areas such as /etc/passwd, etc.
  • Good practice to assume your web files will be seen, and should never store sensitive data in any source code.

Canonicalization Attacks

  • Computer and network resources can often be addressed using more than one way.
  • Ex. C:\text.txt ; ..\\text.txt ; \\computer\C$\text.txt
  • Apps that make security decisions based on the resource name can be vulnerable to these attacks, and easily fooled.
  • Make sure to keep web platforms up to date with all patches.
  • Compartmentalize your directory structure.
  • Constrain input using platform-layer solutions (MS’s URLScan) to strip unicode or double-hex-encoded characters before reaching the server.

Server Extensions

  • Web servers by themselves are minimal in functionality, extensions add a lot to the web experience
  • With web extensions also come trouble
  • MS’s indexing extension, IPP, IIS5, WebDAV, SSL, etc all are extensions and all have had their fair share of security holes
  • Make sure you patch or disable the vulnerable extension. In general make sure you only run extensions that are needed and nothing more

Buffer Overflows

  • Buffer overflow attack symbolizes the coup de grace of hacking
  • Often result in the ability to execute arbitrary commands on the victim machine, with very high privilege levels
  • Easiest way to counter buffer overflow vulnerabilities is to apply a software patch

Web Server Vulnerability Scanners

  • Tools that automate the process of parsing web servers for a bunch of vulnerabilities that come from the hacking community
  • Allows you to focus on patching the holes that are found when the automated process is done, make sure to patch them fast because a hacker can find them easily too
  • Ex. Nikto, and Nessus

Web Application Hacking

  • Web app hacking refers to hacking the app itself and not the web server
  • Requires more patience and sophistication then hacking off the shelf web server software

Finding vulnerable apps with Google

  • Search engines are dangerous because users are careless
  • Makes finding candidate machines almost effortless
  • Find list of publicly accessible pages
    • Site:southern.edu; inurl:southern.edu

  • Find unprotected directories
    • Index of /admin” /password, /mail, password.txt
  • Find password hint applications that are poorly setup
    • Password hint, password hint –email, show password hint –email, filetype:htaccess user

Web Crawling

  • A serious attacker takes the time to become familiar with the application
  • Download entire contents of site, look for low hanging fruit
    • Local path info, back-end server names, IP address, SQL query strings with passwords, info comments, etc
  • Tools
    • wget to get entire websites which can then be used to study later in great detail

Web Application Assessment

  • Once target app content has been crawled and analyzed attacker will then turn to more in-depth probing
  • Ultimate goal of this is to thoroughly understand the architecture and design of the application and identify any weaknesses
  • Focus on authentication, session management, database interaction, generic input validation, and application logic

Browser Plug-ins

  • Browser plug-ins allow you to view the requests as they are made and stop, and modify them on their way
  • Very valuable in finding hidden form fields, modifying query arguments and request headers, and inspecting the response from the remote server
  • TamperData is a plug-in for Firefox coupled with no-script can selectively run and edit JavaScript

Tool Suites

  • Web proxies that are in between the web client and server
  • Basically a man-in-the-middle during an http session
  • Fiddler can be used with any WinINET library software, IE, Outlook, Office, etc
  • Fiddler can adjust files on the way
    • Ex. bpu .css

Common Web Application Vulnerabilities

  • The main categories are
    • Cross-Site Scripting (XSS)
    • Injection Flaws
    • Cross-Site Request Forgery (CSRF)

Cross-Site Scripting (XSS)

  • Arise from input/output validation deficiencies in web applications
  • Attacks other users of the page
    • Ex. Attacker puts code in guestbook online, people who view guestbook has the attackers code executed, potentially giving attacker control of second users’ system
  • Counter with filter input parameters for special characters. Ex. < > ( ) # & “

SQL Injection

  • Adjusting the SQL to point it at a file you wish to view
  • Is a problem because by default a web browser is a “trusted” user.
  • Counter measures
    • Perform strict input validation on any input from the client
    • Replace direct SQL statements with stored procedures, prepared statements
    • Implement defaut error handling
    • Lock down ODBC
    • Lock down database server configuration

Cross-Site Request Forgery

  • Known about for nearly a decade, but just now becoming a serious problem
  • Allows for users to stay logged in without having to authenticate after each page load
  • Can cause problems for the users, passwords changed, funds transferred, merchandise purchased, and more.
  • Attacker puts image tag in a real page that a user is already logged in to and when the browser requests the link instead of an image it is a url string that can change the password for example.
  • Conutermeasures
    • Tying the incoming request to the auth. session. Use random values, tied to the specified user’s session. If it doesn’t match have them re authenticate their connection.

Misuse of Hidden Tags

  • Allows attackers to adjust hidden fields before being sent to the server for processing
  • Business should not have price of item set as a hidden form
  • Would be very easy to adjust the price
  • Countermeasures
    • Limit the use of hidden tags, or at least confirm the value before processing

Quiz

1. List 2 of the 5 common web server vulnerabilities.

Sample files, Source code disclosure, Canonicalization, Server extensions, Input validation(ex. Buffer overflow)

2. Name one of the two browser plugins/toolsets to preform a man-in-the-middle attack.

TamperData or Fiddler

3. What is a common tool used to gather entire websites?

wget

4. What is the easiest method to find vulnerable web applications?

Using search engines

HackingExposedChapter11 (last edited 2010-04-20 03:48:38 by c-71-226-185-105)