Scribd Logo
Upload

Welcome to Scribd!

  • 587 views

    Source Code Review

    Uploaded by

    cikgufatah
    This document outlines the methodology for penetration testing and vulnerability analysis. It discusses designing testing for both design flaws and operational security concerns. Example flaws are given for each category. The testing process involves collecting information, modeling the application, identifying resources, examining inputs and outputs, reviewing external components and user roles. Trust boundaries and audit trails are also analyzed. Tools are listed for static analysis, obfuscation and reverse engineering, vulnerability scanning, and exploitation.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PPTX, PDF, TXT or read online from Scribd

    Source Code Review

    Uploaded by

    cikgufatah
    587 views37 pages
    This document outlines the methodology for penetration testing and vulnerability analysis. It discusses designing testing for both design flaws and operational security concerns. Example flaws are given for each category. The testing process involves collecting information, modeling the application, identifying resources, examining inputs and outputs, reviewing external components and user roles. Trust boundaries and audit trails are also analyzed. Tools are listed for static analysis, obfuscation and reverse engineering, vulnerability scanning, and exploitation.

    Copyright

    © Attribution Non-Commercial (BY-NC)

    Available Formats

    PPTX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    This document outlines the methodology for penetration testing and vulnerability analysis. It discusses designing testing for both design flaws and operational security concerns. Example flaws are given for each category. The testing process involves collecting information, modeling the application, identifying resources, examining inputs and outputs, reviewing external components and user roles. Trust boundaries and audit trails are also analyzed. Tools are listed for static analysis, obfuscation and reverse engineering, vulnerability scanning, and exploitation.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PPTX, PDF, TXT or read online from Scribd
    Download as pptx, pdf, or txt
    587 views37 pages

    Source Code Review

    Uploaded by

    cikgufatah
    This document outlines the methodology for penetration testing and vulnerability analysis. It discusses designing testing for both design flaws and operational security concerns. Example flaws are given for each category. The testing process involves collecting information, modeling the application, identifying resources, examining inputs and outputs, reviewing external components and user roles. Trust boundaries and audit trails are also analyzed. Tools are listed for static analysis, obfuscation and reverse engineering, vulnerability scanning, and exploitation.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PPTX, PDF, TXT or read online from Scribd
    Download as pptx, pdf, or txt
    of 37

    Penetration Testing & Vulnerability Analysis

    Methodology Top 10 Popular Threats What are Design Flaws? Example Design Flaws Design Analysis & Steps What are Operation Security Concerns? Example Operational Security Concerns Tools

    Design Review & Analysis Operational Review & Analysis Vulnerability Verification Reporting & Submission

    A1: Injection A2: Cross-Site Scripting (XSS) A3: Broken Authentication and Session Management A4: Insecure Direct Object References A5: Cross-Site Request Forgery (CSRF) A6: Security Misconfiguration A7: Insecure Cryptographic Storage A8: Failure to Restrict URL Access A9: Insufficient Transport Layer Protection A10: Invalidated Redirects and Forwards

    A design vulnerability is a problem that arises from a fundamental mistake or oversight in the softwares design The Art of Software Security Assessment Lack of security forethought Intrinsic to the apps architecture Can be subtle Are often devastating

    Reliable

    Work seamlessly across OSes/versions Do not corrupt memory! Usually have little/no preventative protection mechanisms Rarely alarm detection tools Do not crash on failure

    Easily fingerprinted Work well in symphony Difficult to fix, so they hang around for a while

    Authentication

    Bypasses Lack of Authentication Lack of Authorization Giving higher privileges to lower privileged users Storing key with plaintext Improper use

    Authorization

    Cryptography

    Business Logic

    Authentication Bypass

    Lack of Authorization

    RealVNC NULL Authentication Method, Authentication Bypass in 2006

    switch(authentication_type) { case USE_PASSWORD: getCredentials(&creds.password); if (validateCreds(creds)) { auth_flag = 1; } break; case USE_NULL_AUTH: auth_flag = 1; break; }

    Debugging / QA hardcoded usernames / passwords

    if (!strcmp(password, mySecret)) { auth_flag = 1; break; }

    Cryptographic

    Hardcoded keys Hardcoded password Password stored in clear-text inside database

    Collect Information Modelling The Application Understand Business Logic, Intention & Architecture Security analysis towards the application from gathered information

    Application Specs, RFCs, etc Architectural Documentation, URS, SDS, etc Data Flow Diagrams Especially anything on security relevant matters

    Identify Resources Resources are anything used by the application which may be useful to an attacker

    Data (Credentials? Personal info?) used by the application Control the application has or grants access to

    All of resources combined represent every piece of access to data or functionality offered by a system

    Example Input

    What type of input does the application get? Where/Who does the data come from? What is the purpose of the input? Track the input data flow How trusted is the data? How much validation is performed on the data?

    Example Threats

    SQL Injection Remote File Inclusion Local File Inclusion Remote Code Execution (Interpreter, OS) Bypass JavaScript Restriction

    Something to think about

    Any external influence you can provide which affects the program is input!

    Examine Output
    What type of output data is there? (Is it sensitive?) Where does the output go? How does the input result in output? How can the data be leveraged by an attacker?

    Example Threats
    Cross Site Scripting (XSS) Application Error Output

    SQL, PHP, Database, File Physical Path, etc

    Sensitive Information
    Email, Phone

    What type of External Components are there?

    Network Services/Web Services used by the application


    SOAP, REST, WCF, JSON, TCP/UDP

    Libraries
    DXUniversal, Telerik, etc.

    Databases
    MSSQL, Oracle, NoSQL/MongoDB/etc.

    Anything the application relies on that is not part of the application itself

    User Roles

    What are the various roles of users?


    Users Super Users Administrators Backup User

    How do they identify themselves? How is a user authenticated?


    Form, OpenID, CardSpace

    How are privilege levels defined? Where are user roles unclear?

    Trust Boundaries

    Given the user roles, and the resources, where should trust boundaries lie?
    Form URI

    Where is trust granted by the application to external components


    Physical Drive

    Databases

    Are these trust boundaries enforced uniformly? Are there unclear areas of trust?

    Audit Trails

    Are all submissions form logged? Are all transactions logged? Are all logged including timestamp, user access, etc. ? Are all deleted records being deleted from the data store (Database, Local log) ?

    Operational vulnerabilities are the result of issues in an application's configuration or deployment environment. The Art of Software Security Assessment

    Infrastructure supporting the application Environmental concerns

    Operational issues happen outside the scope of the application Not problems which will be indicated in the source itself Possible concerns can be inferred by thinking about what the application does, and how it is likely deployed

    Poor configuration? External components


    Databases setup with open ports, default passwords Default scripts left around web servers Anonymous logins allowed on ftp servers Unpatched components

    Failure to use secure technologies around the applications deployment


    Lack of SSL on web servers exchanging credentials Poorly generated certificates/bad random data Compiled application binaries would easily being reverse engineered to let attacker read the application flow

    Security Hardening Mechanisms


    C/C++ - DEP, Stack Cookies, Hardened Heap, SEH validation, Address Space Layout Randomization IIS.Net Enable Custom Error, URL Rewriting, Application Firewall (ThreatSentry, WebKnight) Obfuscation To protect compilation binary from being reverse engineered

    Policy, security in depth


    Network segmentation System user roles Chroot/Jails Firewalls

    Error Reporting Enable

    Data Transaction In Clear-Text

    Source Code From Reverse Engineered App

    Static Analysis Tools Yasca (.Net, Java, C, C++) FlawFinder (C, C++) HP Fortify (.Net, Java, C, C++, Delphi) RATS (C, C++) Development Environment Tools Microsoft Visual Studio 2010 Coderush FXCop Eclipse

    Obfuscation & Reverse Engineering .Net Reflector IDA Pro, OllyDbg Unity3D Obfuscator Dotfuscator Runtime Analyzer CheatEngine Fiddler2 Acunetix, Paros, Burp Suite

    Web Vulnerability Scanner Acunetix Web Vulnerability Scanner SkipFish Vega Network Vulnerability Scanner Tenable Nessus Rapid7 Nexpose Exploitation SQLMap Havij Metasploit Framework

    You might also like