Vulnerability Analysis Part 2 RK Shyamasundar IIT Bombay Outline - - PowerPoint PPT Presentation

Vulnerability Analysis – Part 2

RK Shyamasundar IIT Bombay

Outline

• Software Security

– Buffer Overflow – Buffer Overflow mitigation techniques

• Web Application Security

– Web content security: SSL – Phishing attacks – Side-channel attacks – Finding vulnerabilities – OWASP Top 10 (top 3) – Mitigation techniques – Best practices

Recap: Security Properties

Primary

• Confidentiality
• Authentication
• Freshness
• Availability
• Non-repudiation
• Integrity

Secondary

• Scalability
• Cost
• Usability
• Privacy
• Trust anchor/hierarchy
• State availability: on/off-line

A practitioner of Security Engineering should be juggling between above security properties and find an acceptable balance with well-documented risks/assumptions.

HTTPS/SSL (Padlock & notion of Trust)

HTTPS/SSL (Padlock & notion of Trust)

Successful SSL = padlock

Padlock = layman’s icon for session security*

Getting into the details of a server certificate

Leaf-CA

Intermediate-CA

Root-CA

Certificate Details: Key’s Usage

Certificate Details: Cert’s Usage

Certificate Details: Cert Extension SAN

Certificate Details: Cert Extension CRL, OCSP

SSL Protocol

SSL Protocol

SSL Protocol

Broken padlock = ?

Interesting Read… (2 days ago)

http://wrd.cm/2oEULr3

DNS, SMTP, HTTP

Security cannot be thought in isolation

Attacks on SSL

• CRIME attack [Qualys]
• What is the problem?

– The root cause of the problem is information leakage that occurs when data is compressed prior to encryption. If someone can repeatedly inject and mix arbitrary content with some sensitive and relatively predictable data, and observe the resulting encrypted stream, then she will be able to extract the unknown data from it.

Information Leakage

Other reading…

• Side channel leaks in Web applications

[S&P 2010]

• Sidebuster [CCS 2010]

Improper Configuration & Error Handling

Data Leakage/Privacy/Credential Theft

• http://www.mi.com/in/hdindex/choosePro/in

dex.html?pro=IN_REDMI3S&_1475044200

• URL submission variables
• https://account.xiaomi.com/pass/auth/sns/ho

me?userId=1617339665

Information leakage

Type of webserver: incorrect configuration of webserver Attacker concentrates on a specific set of vulnerabilities!

View Source: continue exploring

This webserver type is different from the previous webserver What does this tell me? (there is either: directory mapping or NFS, or webserver proxy feature in place)

Continue directory traversal

Two webservers offering same content!

Automate the process

• Use open-source/professional tools
• Limitation: known-vulnerabilities
• 0-days: not covered

How should a bank protect its data if everything is SSLized?

SSL Proxy References

• 1. https://blog.heckel.xyz/2013/08/04/use-

sslsplit-to-transparently-sniff-tls-ssl- connections/

• 2. https://blog.heckel.xyz/2013/07/01/how-to-

use-mitmproxy-to-read-and-modify-https- traffic-of-your-phone/

• 3. https://blog.heckel.xyz/2013/08/04/use-

sslsplit-to-transparently-sniff-tls-ssl- connections/

Nessus Vulnerability Scanner: Dashboard

Nessus Vulnerability Scanner: Event Notification

Payloads!

Code injection attack

• Code Injection is the general term for attack types

which consist of injecting code that is then interpreted/executed by the application.

• This type of attack exploits poor handling of

untrusted data. These types of attacks are usually made possible due to a lack of proper input/output data validation, for example:

– allowed characters (standard regular expressions classes or custom) – data format – amount of expected data

Code injection attack

• These types of vulnerabilities can range from

very hard to find, to easy to find

• If found, are usually moderately hard to

exploit, depending of scenario

• If successfully exploited, impact could cover

loss of confidentiality, loss of integrity, loss of availability, and/or loss of accountability

Input validation is necessary!

Preventive Techniques

• Despite best efforts of application developers

to detect and rectify bugs/vulnerabilities it may not be guaranteed that application will be remain secure in future.

• One may take help of application firewalls to

reduce exposure of the application to unauthorized users

– modSecurity (Apache) – AppSensor (OWASP)

Growth of Threat: Growth in the tools available (2004!)

5,000 10,000 15,000 20,000 25,000 1 9 8 1 9 8 1 1 9 8 2 1 9 8 3 1 9 8 4 1 9 8 5 1 9 8 6 1 9 8 7 1 9 8 8 1 9 8 9 1 9 9 1 9 9 1 1 9 9 2 1 9 9 3 1 9 9 4 1 9 9 5 1 9 9 6 1 9 9 7 1 9 9 8 1 9 9 9 2 2 1 2 2 2 3 2 4

Year

Hacker Tools

Source: PestPatrol.com

Categories:

• Binder
• Carding
• Cracking Tool
• Flooder
• Key Generator
• Mail Bomber
• Mailer
• Misc Tool
• Nuker
• Packer
• Password Cracker
• Password Cracking Word List
• Phreaking Tool
• Port Scanner
• Probe Tool
• Sniffer
• Spoofer
• Trojan
• Trojan Creation Tool
• Virus Creation Tool
• Virus Source
• Virus Tutorial
• War Dialer

Requirements and use cases Design Test plans Code Test results Field feedback

Security requirements Risk analysis Risk-based security tests Static analysis (tools) Penetration testing Design Review Iterative approach Code Review

Application Security tollgates in SDLC

References

• https://www.metasploit.com/
• http://valgrind.org/
• https://www.coverity.com/
• http://www.arachni-scanner.com/
• http://www.openvas.org/
• http://www.tenable.com/
• https://www.rapid7.com/products/nexpose/
• https://en.wikipedia.org/wiki/Application_security
• https://portswigger.net/burp/
• https://sourceforge.net/projects/paros/
• http://www.binaryanalysis.org/en/home
• http://bitblaze.cs.berkeley.edu
• https://www.veracode.com/products/static-analysis-sast/binary-code-analysis
• http://angr.io/
• https://cyberpedia.in/manual-sql-injection-by-the-help-of-firebug/
• https://www.owasp.org/index.php/OWASP_AppSensor_Project
• https://www.modsecurity.org/

For the curious ones!

• Availability of services vs Denial of Services

– Akamai & “Krebsonsecurity.com” https://krebsonsecurity.com/2016/09/the- democratization-of-censorship/

• https://projectshield.withgoogle.com/public/

Additional reading…

Outline

• Software Security

– Buffer Overflow – Buffer Overflow mitigation techniques

• Web Application Security

– Web content security: SSL – Phishing attacks – Side-channel attacks – Finding vulnerabilities – OWASP Top 10 (top 3) – Mitigation techniques – Best practices

OWASP top 10

Open Web Application Security Project

Don’t stop at 10

SQL Injection – Illustrated

Firewall Hardened OS Web Server App Server Firewall Databases Legacy Systems Web Services Directories Human Resrcs Billing Custom Code APPLICATION ATTACK Network Layer Application Layer Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce

• Bus. Functions

HTTP request



SQL query



DB Table 



HTTP response 

 "SELECT * FROM accounts WHERE acct=‘’ OR 1=1-- ’"

• 1. Application presents a form to

the attacker

• 2. Attacker sends an attack in the

form data

• 3. Application forwards attack to

the database in a SQL query

Account Summary Acct:5424-6066-2134-4334 Acct:4128-7574-3921-0192 Acct:5424-9383-2039-4029 Acct:4128-0004-1234-0293

• 4. Database runs query containing

attack and sends encrypted results back to application

• 5. Application decrypts data as

normal and sends results to the user

Account: SKU: Account: SKU:

Avoiding SQL Injection Flaws

• Avoid the interpreter entirely, or
• Use an interface that supports bind variables (e.g., prepared statements,
• r stored procedures),
• Bind variables allow the interpreter to distinguish between code and

data

• Encode all user input before passing it to the interpreter
• Always perform ‘white list’ input validation on all user supplied input
• Always minimize database privileges to reduce the impact of a flaw

Recommendations

• For more details, read the

https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

References

HTTP is a stateless protocol

Broken Authentication and Session Management

• Means credentials have to go with every request
• Should use SSL for everything requiring authentication

HTTP is a “stateless” protocol

• SESSION ID used to track state since HTTP doesn’t
• and it is just as good as credentials to an attacker
• SESSION ID is typically exposed on the network, in browser, in logs, …

Session management flaws

• Change my password, remember my password, forgot my password, secret

question, logout, email address, etc…

Beware the side-doors

• User accounts compromised or user sessions hijacked

Typical Impact

How not to create a SESSION ID

h5kek4z9ha1rtrf gj75l3k7hb15rtr l8l65k45hc1rw7i p05jrj53hd1i039 5urltda1he1bn46 j5le97h9hf2yq3h po953ld7hg2awi9 t6zhj2n5hh27bn0 iu345r53hi2aw34

• 0z43411hj2njkl

9por42o9hk3dfrz …

How not to create a SESSION ID

h5kek4z9ha1rtrf gj75l3k7hb15rtr l8l65k45hc1rw7i p05jrj53hd1i039 5urltda1he1bn46 j5le97h9hf2yq3h po953ld7hg2awi9 t6zhj2n5hh27bn0 iu345r53hi2aw34

• 0z43411hj2njkl

9por42o9hk3dfrz …

• 9,7,5,3,1,9,7,5,3,1,9…
• h,h,h,h,h,h,h,h,h,h,h,

…

• a,b,c,d,e,f,g,h,i,j,k,…
• 1,1,1,1,1,2,2,2,2,2,3,…

Broken Authentication Illustrated

Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce

• Bus. Functions

1 User sends credentials 2 Site uses URL rewriting (i.e., put session in URL) 3 User clicks on a link to http://www.hacker.com in a forum www.boi.com?JSESSIONID=9FA1DB9EA... 4 Hacker checks referrer logs on www.hacker.com and finds user’s JSESSIONID 5 Hacker uses JSESSIONID and takes over victim’s account

Avoiding Broken Authentication and Session Management

• Authentication should be simple, centralized, and standardized
• Use the standard session id provided by your container
• Be sure SSL protects both credentials and session id at all times

Verify your architecture

• Forget automated analysis approaches
• Check your SSL certificate
• Examine all the authentication-related functions
• Verify that logoff actually destroys the session
• Use OWASP’s WebScarab to test the implementation

Verify the implementation

• https://www.owasp.org/index.php/Authentication_Cheat_Sheet

Follow the guidance from

Cross-Site Scripting (XSS)

• Raw data from attacker is sent to an innocent user’s browser

Occurs any time…

• Stored in database
• Reflected from web input (form field, hidden field, URL, etc…)
• Sent directly into rich JavaScript client

Raw data…

• Try this in your browser – javascript:alert(document.cookie)

Virtually every web application has this problem

• Steal user’s session, steal sensitive data, rewrite web page, redirect user to

phishing or malware site

• Most Severe: Install XSS proxy which allows attacker to observe and direct all

user’s behavior on vulnerable site and force user to other sites

Typical Impact

Cross-Site Scripting Illustrated

Application with stored XSS vulnerability 3 2 Attacker sets the trap – update my profile

Attacker enters a malicious script into a web page that stores the data

• n the server

1 Victim views page – sees attacker profile Script silently sends attacker Victim’s session cookie

Script runs inside victim’s browser with full access to the DOM and cookies

Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce

• Bus. Functions

(AntiSamy)

Avoiding XSS Flaws

• Recommendations

– Eliminate Flaw

• Don’t include user supplied input in the output page

– Defend Against the Flaw

• Use Content Security Policy (CSP)
• Primary Recommendation: Output encode all user supplied input (Use

OWASP’s ESAPI or Java Encoders to output encode) https://www.owasp.org/index.php/ESAPI https://www.owasp.org/index.php/OWASP_Java_Encoder_Project

• Perform ‘white list’ input validation on all user input to be included in page
• For large chunks of user supplied HTML, use OWASP’s AntiSamy to sanitize

this HTML to make it safe See: https://www.owasp.org/index.php/AntiSamy

• References

– For how to output encode properly, read the

https://www.owasp.org/index.php/XSS_(Cross Site Scripting) Prevention Cheat Sheet

Interesting Reads…

• An XSS on Facebook via PNGs & Wonky

Content Types [January 2016, link]

• A $5,000 Google Maps XSS (by fiddling with

Protobuf) [9th March, link]

Cross Site Request Forgery (CSRF)

• An attack where the victim’s browser is tricked into issuing a command to a

vulnerable web application

• Vulnerability is caused by browsers automatically including user authentication

data (session ID, IP address, Windows domain credentials, …) with each request Cross Site Request Forgery

• What if a hacker could steer your mouse and get you to click on links in your
• nline banking application?
• What could they make you do?

Imagine…

• Initiate transactions (transfer funds, logout user, close account)
• Access sensitive data
• Change account details

Typical Impact

CSRF Vulnerability Pattern

• The Problem

– Web browsers automatically include most credentials with each request – Even for requests caused by a form, script, or image on another site

• All sites relying solely on automatic

credentials are vulnerable!

– (almost all sites are this way)

• Automatically Provided Credentials

– Session cookie – Basic authentication header – IP address – Client side SSL certificates – Windows domain authentication

CSRF Illustrated

3 2 Attacker sets the trap on some website on the internet (or simply via an e-mail) 1 While logged into vulnerable site, victim views attacker site Vulnerable site sees legitimate request from victim and performs the action requested <img> tag loaded by browser – sends GET request (including credentials) to vulnerable site

Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce

• Bus. Functions

Hidden <img> tag contains attack against vulnerable site Application with CSRF vulnerability

Avoiding CSRF Flaws

• Add a secret, not automatically submitted, token to ALL sensitive requests

– This makes it impossible for the attacker to spoof the request

• (unless there’s an XSS hole in your application)

– Tokens should be cryptographically strong or random

• Options

– Store a single token in the session and add it to all forms and links

• Hidden Field: <input name="token" value="687965fdfaew87agrde"

type="hidden"/>

• Single use URL: /accounts/687965fdfaew87agrde
• Form Token: /accounts?auth=687965fdfaew87agrde …

– Beware exposing the token in a referer header

• Hidden fields are recommended

– Can have a unique token for each function

• Use a hash of function name, session id, and a secret

– Can require secondary authentication for sensitive functions (e.g., eTrade)

• Don’t allow attackers to store attacks on your site

– Properly encode all input on the way out – This renders all links/requests inert in most interpreters See the: www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet for more details

How do you address these problems?

• Develop Secure Code

– Follow the best practices in OWASP’s Guide to Building Secure Web Applications

• https://www.owasp.org/index.php/Guide
• And the cheat sheets: https://www.owasp.org/index.php/Cheat_Sheets

– Use OWASP’s Application Security Verification Standard as a guide to what an application needs to be secure

• https://www.owasp.org/index.php/ASVS

– Use standard security components that are a fit for your organization

• Use OWASP’s ESAPI as a basis for your standard components
• https://www.owasp.org/index.php/ESAPI
• Review Your Applications

– Have an expert team review your applications – Review your applications yourselves following OWASP Guidelines

• OWASP Code Review Guide:

https://www.owasp.org/index.php/Code_Review_Guide

• OWASP Testing Guide:

https://www.owasp.org/index.php/Testing_Guide

References: Tools

• Kali Linux
• OpenVAS (+metasploit)
• ZAP
• Charles Proxy
• Apache modSecurity