DOCSLIB.ORG

Using Protocol Fuzzing to Harden Storage Systems and to Protect Them from 0-Day Attacks

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Using Protocol Fuzzing to Harden Storage Systems and to Protect Them from 0-Day Attacks Using protocol fuzzing to harden storage systems and to protect them from 0-day attacks Mikko Varpiola Codenomicon Ltd. http://www.codenomicon.com/ 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. INTRODUCTIONS 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 2 About the Speaker Codenomicon Co-Founder (test suite developer No. 1) Been fuzzing software since 1998 Specialized in protocol fuzzing Key member in PROTOS research and of OUSPG research group First practical implementations of model based fuzzers Industry wide ASN.1 flaws Speaker in various conferences such as Blackhat, CanSecWest, and Techno Security 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 3 DEMO 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 4 What is Fuzzing -- HD Moore 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 5 UNKNOWN VULNERABILITY MANAGEMENT 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 6 Software is Infrastructure 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 7 Reality as it is [still] today Programmers are NOT known for writing secure, or bug free code!!!! 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 8 So say we all! From 1995 to Q3 of 2008 Computer Emergency Response Team (CERT) had 44,074 known vulnerabilities cataloged based on reports from public sources and submitted data. This means the potential of unknowns is most likely greater and the severity has escalated to current day http://www.cert.org/stats/ That’s 9.28 new known vulnerabilities per day over past 13 years. 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 9 Unknown vs. Known vulnerabilities 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 10 Short history of [notable] exploitation of unknown vulnerabilities Morris Worm* CodeRED* SQL Slammer* Stuxnet* Attacks on Sony Phone masters Xbox GoldenEye Wikileaks Anonynous (1994-1995) exploit for homebrew (operation LulZsec Citibank (1994) PROTOS games* Payback) EMC/RSA SecureID SNMP Multi-vendor Google.cn Lockheed Martin Test suite (operation Aurora) (and who others?) JPEG (and other static (2000-2001) Melissa Virus content exploits. Around Morgan Stanley? South Korea DoD (1999) 2004) French G-20 Indian Defense Canadian DoD (Apr, 2010) Rise and Fall of ID & IMF… records Theft. British Foreign Ministry Gawker Media Morto worm… (+1.5M records stolen…) First CyberWar. Omega Eng. Corp. Between Russia and Kaspersky AV (~2000) …. Estonia (2008) Amazon, Ebay,… DDoS (~2000) Era of SQL injection, DDoS, spam and malware 1988 2001 2003 2010 2011 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 11 We are not keeping up... An estimate of 4/5th of our security spending is on reactive technologies and less less than 1/5 on proactive measures! Does that sound right? ( and by the way – reactive measures offer little or no defense against attacks based on unknown vulnerabilities ) 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 12 Big picture – evolution of cyber threat Organized cyber- State sponsored hacking Kinetic damage and kinetic response Early hacktivism and computer crime and computer crime Careful target Careful target selection 197x-1995 2000- 2009- 2010- 1995- 2011- Random - arget selection t Pseudo Vandalism / 2nd generation “hacktivism” iHacktivism 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 13 Anatomy of a hack Swordfish / http://www.imdb.com/title/tt0244244/ Sorry….Only in Hollywood! 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 14 Anatomy of a hack Choose your target Study, analyse, identify Plan Implement Execute! 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 15 Anatomy of a hack Choose your target Study, analyse, identify Plan Implement Execute! People Defenses Ecosystem Organization Software used Software Hardware used Hardware 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 16 Anatomy of a hack Choose your target Study, analyse, identify Plan Implement Execute! 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 17 Anatomy of a hack Choose your target Study, analyse, identify Plan Implement & Test Execute! 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 18 Anatomy of a hack Choose your target Study, analyse, identify Plan Implement & Test Execute! 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 19 Or just use a perfect backdoor NOTE: Skillsets of exploiting and finding the bug is @crossroads or has already diverged. 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 20 Are you compliant, and... 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 21 UVM spells Unknown Vulnerability Management 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 22 We need to start building better SW Everyone needs to start doing fuzzing and to manage their unknown vulnerabilities! We need Energy Star for Software fuzzing! http://amphionforum.com/ http://www.ruggedsoftware.org/ http://www.safecode.org/ 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 23 [Unknown] Vulnerability Management 2012 1995 - 2000 SATAN/SAINT Around 1998- 2000 Reactive Nessus, Qualys, HP, IBM, ISS Symantec,…. Known Vulnerability Management Known vulnerability scanners and policy compliance tools Total Vulnerability Management Unknown Vulnerability Management (UVM) SAST APPROACH DAST APPROACH Proactive ( 1980- ) ( 2000- ) PC Lint, OSS, Fuzzing Coverity, Fortify, IBM Ounce (OSS, Codenomicon, Labs, Microsoft,… Peach, Sulley,…) Whitebox testing Blackbox testing 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 24 So I found UV – Now what? Remediate! Fix the problem Update version of software Fix defect if you own the IP Report problem to affected vendor Isolate the device or subnet Write a rule/signature/policy for the IDS/IPS/Gateway/etc Turn the service off until issue resolved Total Vulnerability Management Unknown Vulnerability Management (UVM) Proactive DAST APPROACH ( 2000- ) -> No source code needed -> Implementation language independent Fuzzing -> No false positives (e.g. crash is a crash) (OSS, Codenomicon, -> Meaningful remediation paths Peach, Sulley,…) -> Modern tools easy to use / operate 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 25 UVM Lifecycle Test/Scan Analyze/Identify Report Protect/Remediate 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 26 We are getting there… Federal/Mil. requirements: DoD DIACAP, NIST SP.800, DoD DIACAP (Common Criteria) http://iase.disa.mil/diacap/ … Private infrastructure: All major US carriers are fuzzing NIST SP.800 Verizon now requires it as lab entry http://csrc.nist.gov/publications/PubsSPs.html criteria Enterprise world following suit Amphion Forum Inustry forums SNIA MSFT Blutooth SIG 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 27 ...and we need to build it right! http://www.microsoft.com/security/sdl/default.aspx Fuzzing in the Verification phase of the MS SDL Modern SDLs such as Microsoft SDLC, new Cisco SDLC and BSIMM all recognize that fuzzing has a key role in creating a secure and rugged software. 2011 Storage Developer Conference. © Codenomicon Ltd. Information contained herein is subject to change without notice. All Rights Reserved. 28 Unknown (0-day) vulnerability When 0-day exploit is seen in public,
Load more

Recommended publications
  • Automatically Bypassing Android Malware Detection System
    FUZZIFICATION: Anti-Fuzzing Techniques Jinho Jung, Hong Hu, David Solodukhin, Daniel Pagan, Kyu Hyung Lee*, Taesoo Kim * 1 Fuzzing Discovers Many Vulnerabilities 2 Fuzzing Discovers Many Vulnerabilities 3 Testers Find Bugs with Fuzzing Detected bugs Normal users Compilation Source Released binary Testers Compilation Distribution Fuzzing 4 But Attackers Also Find Bugs Detected bugs Normal users Compilation Attackers Source Released binary Testers Compilation Distribution Fuzzing 5 Our work: Make the Fuzzing Only Effective to the Testers Detected bugs Normal users Fuzzification ? Fortified binary Attackers Source Compilation Binary Testers Compilation Distribution Fuzzing 6 Threat Model Detected bugs Normal users Fuzzification Fortified binary Attackers Source Compilation Binary Testers Compilation Distribution Fuzzing 7 Threat Model Detected bugs Normal users Fuzzification Fortified binary Attackers Source Compilation Binary Testers Compilation Distribution Fuzzing Adversaries try to find vulnerabilities from fuzzing 8 Threat Model Detected bugs Normal users Fuzzification Fortified binary Attackers Source Compilation Binary Testers Compilation Distribution Fuzzing Adversaries only have a copy of fortified binary 9 Threat Model Detected bugs Normal users Fuzzification Fortified binary Attackers Source Compilation Binary Testers Compilation Distribution Fuzzing Adversaries know Fuzzification and try to nullify 10 Research Goals Detected bugs Normal users Fuzzification Fortified binary Attackers Source Compilation Binary Testers Compilation
    [Show full text]
  • Jeffrey Heim, Marcel Hernandez, Maria Nunez,& Matthias Katerna Morris Worm on November 2, 1988, Robert Tappan Morris Releas
    Jeffrey Heim, Marcel Hernandez, Maria Nunez,& Matthias Katerna Morris Worm On November 2, 1988, Robert Tappan Morris released a worm into the internet. The experimental worm was the first of its kind. It replicated itself and programmed itself, so it ended up spreading much faster than Morris expected. It self-programmed and self-replicated at an exponential rate in a manner that had never been seen before. Morris knew this worm was not necessarily ethical, for he released it out of MIT instead of his own Cornell University. In due course, many computers across the United States had crashed because of Morris. Once he discovered how much damage the worm had been causing, he reached out to a friend at Harvard looking for a solution to stop it. They attempted in sending an anonymous message to the network with directions that could kill the worm, but the message came through too late since they system was clogged. Many significant computers at colleges, businesses and the military became infected. The cost to fix each computer ranged from $200 to over $53,000. The worm exploited vulnerabilities in computer systems and in the UNIX email software. Within 24 hours of releasing the worm, thousands of people were aware something was unusual. Eventually, it would infect ten percent of all computers using the internet. The Morris Worm was the largest malware case ever to reach this percentage. However, the percentage was so high due to the fact that the number of computers was much less than today. The computers it impacted included significant systems, such as Stanford’s, Berkley’s and NASA’s.
    [Show full text]
  • Internet Security Threat Report VOLUME 21, APRIL 2016 TABLE of CONTENTS 2016 Internet Security Threat Report 2
    Internet Security Threat Report VOLUME 21, APRIL 2016 TABLE OF CONTENTS 2016 Internet Security Threat Report 2 CONTENTS 4 Introduction 21 Tech Support Scams Go Nuclear, 39 Infographic: A New Zero-Day Vulnerability Spreading Ransomware Discovered Every Week in 2015 5 Executive Summary 22 Malvertising 39 Infographic: A New Zero-Day Vulnerability Discovered Every Week in 2015 8 BIG NUMBERS 23 Cybersecurity Challenges For Website Owners 40 Spear Phishing 10 MOBILE DEVICES & THE 23 Put Your Money Where Your Mouse Is 43 Active Attack Groups in 2015 INTERNET OF THINGS 23 Websites Are Still Vulnerable to Attacks 44 Infographic: Attackers Target Both Large and Small Businesses 10 Smartphones Leading to Malware and Data Breaches and Mobile Devices 23 Moving to Stronger Authentication 45 Profiting from High-Level Corporate Attacks and the Butterfly Effect 10 One Phone Per Person 24 Accelerating to Always-On Encryption 45 Cybersecurity, Cybersabotage, and Coping 11 Cross-Over Threats 24 Reinforced Reassurance with Black Swan Events 11 Android Attacks Become More Stealthy 25 Websites Need to Become Harder to 46 Cybersabotage and 12 How Malicious Video Messages Could Attack the Threat of “Hybrid Warfare” Lead to Stagefright and Stagefright 2.0 25 SSL/TLS and The 46 Small Business and the Dirty Linen Attack Industry’s Response 13 Android Users under Fire with Phishing 47 Industrial Control Systems and Ransomware 25 The Evolution of Encryption Vulnerable to Attacks 13 Apple iOS Users Now More at Risk than 25 Strength in Numbers 47 Obscurity is No Defense
    [Show full text]
  • Moonshine: Optimizing OS Fuzzer Seed Selection with Trace Distillation
    MoonShine: Optimizing OS Fuzzer Seed Selection with Trace Distillation Shankara Pailoor, Andrew Aday, and Suman Jana Columbia University Abstract bug in system call implementations might allow an un- privileged user-level process to completely compromise OS fuzzers primarily test the system-call interface be- the system. tween the OS kernel and user-level applications for secu- OS fuzzers usually start with a set of synthetic seed rity vulnerabilities. The effectiveness of all existing evo- programs , i.e., a sequence of system calls, and itera- lutionary OS fuzzers depends heavily on the quality and tively mutate their arguments/orderings using evolution- diversity of their seed system call sequences. However, ary guidance to maximize the achieved code coverage. generating good seeds for OS fuzzing is a hard problem It is well-known that the performance of evolutionary as the behavior of each system call depends heavily on fuzzers depend critically on the quality and diversity of the OS kernel state created by the previously executed their seeds [31, 39]. Ideally, the synthetic seed programs system calls. Therefore, popular evolutionary OS fuzzers for OS fuzzers should each contain a small number of often rely on hand-coded rules for generating valid seed system calls that exercise diverse functionality in the OS sequences of system calls that can bootstrap the fuzzing kernel. process. Unfortunately, this approach severely restricts However, the behavior of each system call heavily de- the diversity of the seed system call sequences and there- pends on the shared kernel state created by the previous fore limits the effectiveness of the fuzzers.
    [Show full text]
  • Vulnerability Management: Overview
    Resource ID: w-013-3774 Cybersecurity Tech Basics: Vulnerability Management: Overview SEAN ATKINSON, CIS™ (CENTER FOR INTERNET SECURITY), WITH PRACTICAL LAW INTELLECTUAL PROPERTY & TECHNOLOGY Search the Resource ID numbers in blue on Westlaw for more. A Practice Note providing an overview of what Design, implementation, or other vendor oversights that create defects in commercial IT products (see Hardware and Software cyber vulnerability management programs Defects). are, how they work, and the key role they play Poor setup, mismanagement, or other issues in the way an in any organization’s information security organization installs and maintains its IT hardware and software components (see Unsecured Configurations). program. This Note discusses common types of Vulnerability management programs address these issues. Other cyber vulnerabilities and core process steps for common vulnerabilities that organizations must also tackle in their implementing and maintaining a vulnerability information security programs include: management program to decrease cybersecurity Gaps in business processes. Human weaknesses, such as lack of user training and awareness. risks. It also addresses common pitfalls that Poorly designed access controls or other safeguards. can lead to unnecessary cyber incidents and Physical and environmental issues. data breaches. Unlike threats, organizations can often directly control their vulnerabilities and therefore minimize the opportunities for threat actors. Most organizations depend on a combination of commercial and custom-developed hardware and software products to support their Organizations that develop their own in-house software should information technology (IT) needs. These technology components use security by design techniques to avoid creating vulnerabilities. inevitably include vulnerabilities in their design, setup, or the code that For more information on assessing overall data security risks and runs them.
    [Show full text]
  • Active Fuzzing for Testing and Securing Cyber-Physical Systems
    Active Fuzzing for Testing and Securing Cyber-Physical Systems Yuqi Chen Bohan Xuan Christopher M. Poskitt Singapore Management University Zhejiang University Singapore Management University Singapore China Singapore [email protected] [email protected] [email protected] Jun Sun Fan Zhang∗ Singapore Management University Zhejiang University Singapore China [email protected] [email protected] ABSTRACT KEYWORDS Cyber-physical systems (CPSs) in critical infrastructure face a per- Cyber-physical systems; fuzzing; active learning; benchmark gen- vasive threat from attackers, motivating research into a variety of eration; testing defence mechanisms countermeasures for securing them. Assessing the effectiveness of ACM Reference Format: these countermeasures is challenging, however, as realistic bench- Yuqi Chen, Bohan Xuan, Christopher M. Poskitt, Jun Sun, and Fan Zhang. marks of attacks are difficult to manually construct, blindly testing 2020. Active Fuzzing for Testing and Securing Cyber-Physical Systems. In is ineffective due to the enormous search spaces and resource re- Proceedings of the 29th ACM SIGSOFT International Symposium on Software quirements, and intelligent fuzzing approaches require impractical Testing and Analysis (ISSTA ’20), July 18–22, 2020, Virtual Event, USA. ACM, amounts of data and network access. In this work, we propose active New York, NY, USA, 13 pages. https://doi.org/10.1145/3395363.3397376 fuzzing, an automatic approach for finding test suites of packet- level CPS network attacks, targeting scenarios in which attackers 1 INTRODUCTION can observe sensors and manipulate packets, but have no existing knowledge about the payload encodings. Our approach learns re- Cyber-physical systems (CPSs), characterised by their tight and gression models for predicting sensor values that will result from complex integration of computational and physical processes, are sampled network packets, and uses these predictions to guide a often used in the automation of critical public infrastructure [78].
    [Show full text]
  • The Art, Science, and Engineering of Fuzzing: a Survey
    1 The Art, Science, and Engineering of Fuzzing: A Survey Valentin J.M. Manes,` HyungSeok Han, Choongwoo Han, Sang Kil Cha, Manuel Egele, Edward J. Schwartz, and Maverick Woo Abstract—Among the many software vulnerability discovery techniques available today, fuzzing has remained highly popular due to its conceptual simplicity, its low barrier to deployment, and its vast amount of empirical evidence in discovering real-world software vulnerabilities. At a high level, fuzzing refers to a process of repeatedly running a program with generated inputs that may be syntactically or semantically malformed. While researchers and practitioners alike have invested a large and diverse effort towards improving fuzzing in recent years, this surge of work has also made it difficult to gain a comprehensive and coherent view of fuzzing. To help preserve and bring coherence to the vast literature of fuzzing, this paper presents a unified, general-purpose model of fuzzing together with a taxonomy of the current fuzzing literature. We methodically explore the design decisions at every stage of our model fuzzer by surveying the related literature and innovations in the art, science, and engineering that make modern-day fuzzers effective. Index Terms—software security, automated software testing, fuzzing. ✦ 1 INTRODUCTION Figure 1 on p. 5) and an increasing number of fuzzing Ever since its introduction in the early 1990s [152], fuzzing studies appear at major security conferences (e.g. [225], has remained one of the most widely-deployed techniques [52], [37], [176], [83], [239]). In addition, the blogosphere is to discover software security vulnerabilities. At a high level, filled with many success stories of fuzzing, some of which fuzzing refers to a process of repeatedly running a program also contain what we consider to be gems that warrant a with generated inputs that may be syntactically or seman- permanent place in the literature.
    [Show full text]
  • Psofuzzer: a Target-Oriented Software Vulnerability Detection Technology Based on Particle Swarm Optimization
    applied sciences Article PSOFuzzer: A Target-Oriented Software Vulnerability Detection Technology Based on Particle Swarm Optimization Chen Chen 1,2,*, Han Xu 1 and Baojiang Cui 1 1 School of Cyberspace Security, Beijing University of Posts and Telecommunications, Beijing 100876, China; [email protected] (H.X.); [email protected] (B.C.) 2 School of Information and Navigation, Air Force Engineering University, Xi’an 710077, China * Correspondence: [email protected] Abstract: Coverage-oriented and target-oriented fuzzing are widely used in vulnerability detection. Compared with coverage-oriented fuzzing, target-oriented fuzzing concentrates more computing resources on suspected vulnerable points to improve the testing efficiency. However, the sample generation algorithm used in target-oriented vulnerability detection technology has some problems, such as weak guidance, weak sample penetration, and difficult sample generation. This paper proposes a new target-oriented fuzzer, PSOFuzzer, that uses particle swarm optimization to generate samples. PSOFuzzer can quickly learn high-quality features in historical samples and implant them into new samples that can be led to execute the suspected vulnerable point. The experimental results show that PSOFuzzer can generate more samples in the test process to reach the target point and can trigger vulnerabilities with 79% and 423% higher probability than AFLGo and Sidewinder, respectively, on tested software programs. Keywords: fuzzing; model-based fuzzing; vulnerability detection; code coverage; open-source program; directed fuzzing; static instrumentation; source code instrumentation Citation: Chen, C.; Han, X.; Cui, B. PSOFuzzer: A Target-Oriented 1. Introduction Software Vulnerability Detection The appearance of an increasing number of software vulnerabilities has made auto- Technology Based on Particle Swarm matic vulnerability detection technology a widespread concern in industry and academia.
    [Show full text]
  • Configuration Fuzzing Testing Framework for Software Vulnerability Detection
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Columbia University Academic Commons CONFU: Configuration Fuzzing Testing Framework for Software Vulnerability Detection Huning Dai, Christian Murphy, Gail Kaiser Department of Computer Science Columbia University New York, NY 10027 USA ABSTRACT Many software security vulnerabilities only reveal themselves under certain conditions, i.e., particular configurations and inputs together with a certain runtime environment. One approach to detecting these vulnerabilities is fuzz testing. However, typical fuzz testing makes no guarantees regarding the syntactic and semantic validity of the input, or of how much of the input space will be explored. To address these problems, we present a new testing methodology called Configuration Fuzzing. Configuration Fuzzing is a technique whereby the configuration of the running application is mutated at certain execution points, in order to check for vulnerabilities that only arise in certain conditions. As the application runs in the deployment environment, this testing technique continuously fuzzes the configuration and checks "security invariants'' that, if violated, indicate a vulnerability. We discuss the approach and introduce a prototype framework called ConFu (CONfiguration FUzzing testing framework) for implementation. We also present the results of case studies that demonstrate the approach's feasibility and evaluate its performance. Keywords: Vulnerability; Configuration Fuzzing; Fuzz testing; In Vivo testing; Security invariants INTRODUCTION As the Internet has grown in popularity, security testing is undoubtedly becoming a crucial part of the development process for commercial software, especially for server applications. However, it is impossible in terms of time and cost to test all configurations or to simulate all system environments before releasing the software into the field, not to mention the fact that software distributors may later add more configuration options.
    [Show full text]
  • Fuzzing with Code Fragments
    Fuzzing with Code Fragments Christian Holler Kim Herzig Andreas Zeller Mozilla Corporation∗ Saarland University Saarland University [email protected] [email protected] [email protected] Abstract JavaScript interpreter must follow the syntactic rules of JavaScript. Otherwise, the JavaScript interpreter will re- Fuzz testing is an automated technique providing random ject the input as invalid, and effectively restrict the test- data as input to a software system in the hope to expose ing to its lexical and syntactic analysis, never reaching a vulnerability. In order to be effective, the fuzzed input areas like code transformation, in-time compilation, or must be common enough to pass elementary consistency actual execution. To address this issue, fuzzing frame- checks; a JavaScript interpreter, for instance, would only works include strategies to model the structure of the de- accept a semantically valid program. On the other hand, sired input data; for fuzz testing a JavaScript interpreter, the fuzzed input must be uncommon enough to trigger this would require a built-in JavaScript grammar. exceptional behavior, such as a crash of the interpreter. Surprisingly, the number of fuzzing frameworks that The LangFuzz approach resolves this conflict by using generate test inputs on grammar basis is very limited [7, a grammar to randomly generate valid programs; the 17, 22]. For JavaScript, jsfunfuzz [17] is amongst the code fragments, however, partially stem from programs most popular fuzzing tools, having discovered more that known to have caused invalid behavior before. LangFuzz 1,000 defects in the Mozilla JavaScript engine. jsfunfuzz is an effective tool for security testing: Applied on the is effective because it is hardcoded to target a specific Mozilla JavaScript interpreter, it discovered a total of interpreter making use of specific knowledge about past 105 new severe vulnerabilities within three months of and common vulnerabilities.
    [Show full text]
  • Creating a Patch and Vulnerability Management Program
    Special Publication 800-40 Version 2.0 Creating a Patch and Vulnerability Management Program Recommendations of the National Institute of Standards and Technology (NIST) Peter Mell Tiffany Bergeron David Henning NIST Special Publication 800-40 Creating a Patch and Vulnerability Version 2.0 Management Program Recommendations of the National Institute of Standards and Technology Peter Mell Tiffany Bergeron David Henning C O M P U T E R S E C U R I T Y Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 November 2005 U.S. Department of Commerce Carlos M. Gutierrez, Secretary Technology Administration Michelle O'Neill, Acting Under Secretary of Commerce for Technology National Institute of Standards and Technology William A. Jeffrey, Director CREATING A PATCH AND VULNERABILITY MANAGEMENT PROGRAM Reports on Computer Systems Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations. National Institute of Standards and Technology Special Publication 800-40 Version 2.0 Natl.
    [Show full text]
  • Lesson 6: Hacking Malware
    LESSON 6 HACKING MALWARE Lesson 6: Malware WARNING The Hacker Highschool Project is a learning tool and as with any learning tool there are dangers. Some lessons if abused may result in physical injury. Some additional dangers may also exist where there is not enough research on possible effects of emanations from particular technologies. Students using these lessons should be supervised yet encouraged to learn, try, and do. However ISECOM cannot accept responsibility for how any information herein is abused. The following lessons and workbooks are open and publicly available under the following terms and conditions of ISECOM: All works in the Hacker Highschool Project are provided for non-commercial use with elementary school students, junior high school students, and high school students whether in a public institution, private institution, or a part of home-schooling. These materials may not be reproduced for sale in any form. The provision of any class, course, training, or camp with these materials for which a fee is charged is expressly forbidden without a license including college classes, university classes, trade-school classes, summer or computer camps, and similar. To purchase a license, visit the LICENSE section of the HHS web page at http://www.hackerhighschool.org/licensing.html. The HHS Project is an open community effort and if you find value in this project we ask that you support us through the purchase of a license, a donation, or sponsorship. 2 Lesson 6: Malware Table of Contents WARNING....................................................................................................................................................2
    [Show full text]