The Layman's Guide to Zero-Day Engineering

Video thumbnail (Frame 0) Video thumbnail (Frame 1757) Video thumbnail (Frame 3243) Video thumbnail (Frame 4576) Video thumbnail (Frame 5689) Video thumbnail (Frame 7041) Video thumbnail (Frame 8362) Video thumbnail (Frame 10158) Video thumbnail (Frame 11401) Video thumbnail (Frame 12642) Video thumbnail (Frame 13795) Video thumbnail (Frame 15362) Video thumbnail (Frame 16808) Video thumbnail (Frame 18408) Video thumbnail (Frame 20202) Video thumbnail (Frame 21519) Video thumbnail (Frame 22607) Video thumbnail (Frame 23805) Video thumbnail (Frame 24979) Video thumbnail (Frame 26441) Video thumbnail (Frame 27940) Video thumbnail (Frame 30237) Video thumbnail (Frame 32454) Video thumbnail (Frame 33795) Video thumbnail (Frame 35223) Video thumbnail (Frame 36580) Video thumbnail (Frame 37809) Video thumbnail (Frame 39172) Video thumbnail (Frame 40986) Video thumbnail (Frame 42555) Video thumbnail (Frame 43867) Video thumbnail (Frame 45259) Video thumbnail (Frame 46755) Video thumbnail (Frame 48096) Video thumbnail (Frame 49509) Video thumbnail (Frame 50796) Video thumbnail (Frame 52285) Video thumbnail (Frame 53845) Video thumbnail (Frame 55569) Video thumbnail (Frame 56929) Video thumbnail (Frame 58514) Video thumbnail (Frame 59848) Video thumbnail (Frame 61289) Video thumbnail (Frame 62396) Video thumbnail (Frame 63970) Video thumbnail (Frame 65528) Video thumbnail (Frame 67124) Video thumbnail (Frame 68299) Video thumbnail (Frame 69463) Video thumbnail (Frame 70594) Video thumbnail (Frame 71815) Video thumbnail (Frame 72940) Video thumbnail (Frame 74249) Video thumbnail (Frame 75404) Video thumbnail (Frame 76671) Video thumbnail (Frame 77901) Video thumbnail (Frame 79177) Video thumbnail (Frame 80430) Video thumbnail (Frame 81660) Video thumbnail (Frame 83207) Video thumbnail (Frame 84599)
Video in TIB AV-Portal: The Layman's Guide to Zero-Day Engineering

Formal Metadata

Title
The Layman's Guide to Zero-Day Engineering
Subtitle
A demystification of the exploit development lifecycle
Title of Series
Author
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
2018
Language
English

Content Metadata

Subject Area
Abstract
There's a certain allure to zero-day exploits. At the apex of the security industry, these elusive technologies are engineered by a persistent few to open doors of software systems that were never meant to exist. We go behind-the-scenes to provide an inside look at the zero-day development lifecycle, breaking common misconceptions regarding this increasingly difficult tradecraft.
Keywords Security

Related Material

The following resource is accompanying material for the video
Video is cited by the following resource
Process (computing) Motion capture Content (media) Flag Musical ensemble Compilation album Social class
Collaborationism Service (economics) Context awareness Software developer Electronic program guide Code Exploit (computer security) Information technology consulting Demoscene Wave packet Goodness of fit Self-organization Right angle Musical ensemble Information security Information security Physical system Physical system
Point (geometry) State observer Computer font Observational study Process (computing) Software Multiplication sign Process (computing) Control flow
Code Virtualization Web browser Exploit (computer security) Twitter Revision control Category of being Software Single-precision floating-point format Energy level Cuboid Information security Physical system
Mobile app Link (knot theory) Code Virtual machine Code Bit Formal language Connected space Root Single-precision floating-point format Calculation Gastropod shell Energy level Remote procedure call Routing Metropolitan area network Computer worm
Observational study Expert system Code Mereology Event horizon Mathematics Software Blog Personal digital assistant Series (mathematics) Blog Chain Right angle Office suite Series (mathematics) Resultant Computer worm
Electric generator Software engineering Code Mobile Web Expert system Code Web browser Product (business) Twitter Expected value Type theory Software Self-organization Game theory Information security Vulnerability (computing) Spacetime Physical system
Scaling (geometry) Software developer Code Line (geometry) Multiplication sign Projective plane Complex (psychology) Code Infinity Expert system Wave packet Optical disc drive Type theory Software Quicksort Game theory Information security Information security Task (computing)
Digital electronics Scaling (geometry) Multiplication sign Motion capture Motion capture Software bug Process (computing) Cuboid Flag Convex hull Arc (geometry) Fingerprint Graphical user interface Flag Scalable Coherent Interface
Mapping Process (computing) Software Code Average Order (biology) Projective plane Line (geometry) Quicksort Order of magnitude Software bug
Slide rule Scaling (geometry) Process (computing) Software Software developer Blog Electronic program guide Exploit (computer security) Computer worm Mereology Task (computing) Vulnerability (computing)
Web page Wechselseitige Information Greatest element Exploit (computer security) Mathematical analysis Bookmark (World Wide Web) Computer Blog Phase transition Inverse trigonometric functions Information Message passing HTTP cookie Graphical user interface Vulnerability (computing) Computer virus Information Twitter Web browser Wiki Error message Emulator Compiler Sheaf (mathematics) System programming Information security Extension (kinesiology)
Point (geometry) Trail Trail Forcing (mathematics) Software developer Exploit (computer security) Exploit (computer security) Component-based software engineering Component-based software engineering Software Software Flag Integrated development environment Right angle Selectivity (electronic) Information security Information security Library (computing) Computer architecture Row (database)
Complex (psychology) Open source Computer file Mapping Code Source code Code Directory service Maxima and minima Directory service Web browser Line (geometry) Approximation Product (business) Visualization (computer graphics) Network topology Square number Cuboid Video game Software framework Vulnerability (computing)
Focus (optics) Length Length Code Directory service Web browser Focus (optics) Software bug Power (physics) Performance appraisal Web 2.0 Performance appraisal Reduction of order Vulnerability (computing) Software development kit
Run time (program lifecycle phase) Mapping Code Interface (computing) Zoom lens Code Directory service Line (geometry) Directory service Core dump Interpreter (computing) Energy level Object (grammar) Reverse engineering
Run time (program lifecycle phase) Process (computing) Code Multiplication sign Authorization Code Directory service Bit Line (geometry) Directory service Software bug
State observer Trail Server (computing) Service (economics) Server (computing) Twitter Number Subset Software bug Arithmetic mean Component-based software engineering Root Phase transition Energy level Escape character Information security Window Physical system Window
Software engineering Ewe language Electronic data interchange Electronic data interchange Server (computing) MIDI Code Perspective (visual) Software bug Component-based software engineering Website Right angle Escape character Conditional-access module Vulnerability (computing) Window
Module (mathematics) Point (geometry) Trail Slide rule Just-in-Time-Compiler Software developer Code Linear regression Patch (Unix) Disintegration MIDI Complex (psychology) Code Skewness Software bug Number Component-based software engineering Rewriting Information security Game theory Vulnerability (computing) Row (database)
Open source Multiplication sign Expert system Mereology Perspective (visual) Software bug Strategy game Percolation theory Core dump Collision Process (computing) Fuzzy logic Information security Vulnerability (computing) Point cloud Vulnerability (computing) NP-hard Mapping Length Complex (psychology) Open source Code Bit Scalability Exploit (computer security) Arithmetic mean Process (computing) Crash (computing) Chain Self-organization Social class Right angle Fiber bundle Resultant
Complex (psychology) Intel Digital filter Run time (program lifecycle phase) Computer file Code Line (geometry) Student's t-distribution Price index Directory service Function (mathematics) Scalability Whiteboard Core dump Software testing Information Traffic reporting Vulnerability (computing) Form (programming) Electric generator View (database) Run time (program lifecycle phase) Code Statistics Element (mathematics) Web application Shooting method Personal digital assistant Function (mathematics) Chain Formal grammar Fuzzy logic Software testing Right angle Arithmetic progression Reduction of order Electric current
User interface Block (periodic table) Code Multiplication sign Maxima and minima Code Set (mathematics) Bit Software bug Goodness of fit Personal digital assistant Formal grammar Cuboid Software testing Condition number
Dynamical system Touchscreen Open source Code Debugger Debugger MIDI Mathematical analysis Maxima and minima Code Menu (computing) Coma Berenices Mathematical analysis Area Digital photography Personal digital assistant Core dump Source code Hill differential equation Aerodynamics Reading (process)
Complex (psychology) Statistics Context awareness Open source Code Modal logic Time travel Debugger Code Mass System call Software bug Inclusion map Uniform resource locator Causality Root Blog Speicherbereinigung Reverse engineering Vulnerability (computing) Condition number
Area Slide rule Context awareness Functional (mathematics) Software developer Code Military base Debugger Code Stack (abstract data type) System call Flow separation Operator (mathematics) System programming Source code Vulnerability (computing)
Mathematics Cone penetration test Code Blog Code Quicksort Freeware Exploit (computer security) Vulnerability (computing) Software bug Data type
Point (geometry) Context awareness Complex (psychology) Intel Programming paradigm Software developer Code Military base Multiplication sign Software developer Expert system Code Mereology Unit testing Web browser Web 2.0 Personal digital assistant Software testing Software testing Graphical user interface Condition number
Point (geometry) Functional (mathematics) Server (computing) Code Open source Code Bound state Software bug Function (mathematics) Computer programming Blog output System identification output Freezing Window Social class
Asynchronous Transfer Mode Server (computing) Cone penetration test Service (economics) Open source Server (computing) Code Streaming media Content (media) Cartesian coordinate system Message passing Kernel (computing) Diagram Quicksort Window Physical system Window
Vulnerability (computing) Server (computing) Mobile app File format Uniqueness quantification Bit Twitter Message passing Buffer solution Fuzzy logic Information security Data buffer Information security Window Vulnerability (computing)
Server (computing) Touchscreen Key (cryptography) Multiplication sign Bit Graph coloring 2 (number) Message passing Forest Password Cuboid Fuzzy logic Window
Frame problem Server (computing) Executive information system Graph (mathematics) MIDI Code Thread (computing) Number Software bug Crash (computing) Blog Escape character Address space
State observer Vulnerability (computing) Information Network topology Forest Expert system Code Fuzzy logic Predicate (grammar) Software bug
Server (computing) Blog Process (computing) Pairwise comparison Graphical user interface Software bug Twitter Window
Expected value Software developer Sheaf (mathematics) Code Bit Software bug
Complex (psychology) Server (computing) Touchscreen Forcing (mathematics) Exploit (computer security) Web browser Mereology Exploit (computer security) Software bug Kernel (computing) Calculation Energy level Right angle Window Physical system
Mathematics View (database) Exploit (computer security) Quicksort Task (computing) Physical system
State observer Scripting language Just-in-Time-Compiler Machine code Java applet Exploit (computer security) Similarity (geometry) Primitive (album) Web browser Mereology Exploit (computer security) Software bug Spring (hydrology) Chain Data structure Quicksort
Different (Kate Ryan album) Code Term (mathematics) Speicherbereinigung Data structure Event horizon Software bug Software development kit
Just-in-Time-Compiler Multiplication sign Exploit (computer security) Software bug
Digital photography Proof theory Type theory Scripting language Repository (publishing) Java applet Musical ensemble Software bug
Reading (process) Scripting language Multiplication sign Java applet Electronic mailing list Right angle Exploit (computer security) Graphical user interface Software bug Vulnerability (computing)
Latent heat Process (computing) Multiplication sign Lipschitz-Stetigkeit Quicksort Exploit (computer security) Twitter
Multiplication sign Software developer Real number Chain Cuboid Virtualization Quicksort Demoscene
Subject indexing Complex (psychology) Semiconductor memory 1 (number) Bound state Cuboid Bit Integer Software bug
Malware Code Multiplication sign Software developer Ultraviolet photoelectron spectroscopy Line (geometry) Escape character Exploit (computer security) Software bug
Bit Software bug
Device driver Arithmetic progression Installable File System Software bug
Point (geometry) Crash (computing) Process (computing) Touchscreen Inheritance (object-oriented programming) Code Software developer Calculation Exploit (computer security) Vulnerability (computing) Computer worm
Crash (computing) Personal digital assistant Computer programming Flag Escape character Computer-assisted translation Login Physical system Flag
Empennage Code Interior (topology) Multiplication sign Code Cloud computing Line (geometry) Exploit (computer security) Function (mathematics) Computer programming Gastropod shell Physical system Computer worm
Root Code Calculation Multiplication sign File system Source code Computer worm Bit Escape character Library (computing) Computer worm
Array data structure Multiplication Information Image resolution Semiconductor memory Function (mathematics) Multiplication sign Memory management Computer worm Software testing Leak
Beta function Code Core dump Mereology Pivot element Number Revision control Befehlsprozessor Finite difference Different (Kate Ryan album) Personal digital assistant Normal (geometry) Right angle Operating system Address space Physical system Condition number
Dependent and independent variables Multiplication sign Sheaf (mathematics) Electronic program guide Software testing Web browser Figurate number Software bug
Skeleton (computer programming) Server (computing) Cone penetration test Ring (mathematics) Virtual machine Information privacy Neuroinformatik Physical system
Multiplication sign Web crawler Mapping State of matter Denial-of-service attack Digital signal Density of states Twitter Bookmark (World Wide Web) Twitter Internetworking Internetworking Blog System programming Website Energy level Website
Sign (mathematics) Server (computing) Process (computing) Internetworking Code Denial-of-service attack Power (physics)
Multiplication sign Electronic program guide Exploit (computer security) Right angle Musical ensemble Game theory
Roundness (object) Moment (mathematics) Cartesian closed category Speech synthesis Right angle Musical ensemble Semiconductor memory
[Music] the layman's guide to zero day engineering is our next talk by and my colleagues out in Austin who run the pound your own comp contest assure me that our next speakers are really very much top of their class and I'm really looking forward to the talk before that a capture the flag contents like that requires having done a lot of your homework upfront so that you have the tools at your disposal at at the time so that you can win and Marcus and Amy are here to tell us something way more valuable about the actual tools that they found but how they actually arrived to the of those tools and the you know the process of going going to that and I think that is going to be a very valuable recipe or lesson for us so please help me welcome Marcus and Amy to a very much anticipated talk
[Music]
all right hi everyone thank you for making out to our talk this evening so I'd like to start by thanking the CCC organizers for inviting us out here to give this talk this was a unique opportunity for us to share some of our experience with the community and we're really happy to be here so yeah I hope
you guys enjoy okay so who are we well my name is Marcus Gadsden I sometimes go by the handle Gazza Dolan which is my last name and I'm joined here by my coworker Amy I was also a good friend and longtime collaborator we work for a company
called Rhett two systems Rhett two is best known publicly for its security research and development behind the scenes we do consulting and have been pushing the improvs available available 'ti of security education and specialized security training as well as raising awareness and sharing information like you're going to see today so this talk has been structured roughly
to show our approach in breaking some of the world's most hardened consumer software in particular we're going to talk about one of the zero days that we produce at ret - in 2018 and over the course of the talk we hope to break some common misconceptions about the process of zero day engineering we're going to highlight some of the observations that we've gathered and built up about this industry and this trade over the course of many years now and we're going to try to offer some advice on how to get started doing this kind of work as an individual so we're calling this talk a
non technical commentary about the process of zero day engineering at times it may seem like we are stating the obvious but the point is to show that there's less magic behind the curtain then most of you spectators probably realize so let's talk about pounding 2018 for those that don't know Rondon is
an industry level security competition organized annually by Trend Micro a zero day initiative upon own invites the top
security research researchers from around the world the showcase zero day exploits against high value software targets such as premiere web browsers operating systems and virtualization solutions such as hyper-v VMware virtual box Zen whatever so a trek - we thought it'd be fun to playing punt on this year specifically we wanted to target the
calm petitions browser category we chose to attack Apple's Safari web browser on Mac OS because it was new it was mysterious but also to avoid any prior conflicts of interest and so for this competition we ended up developing any type of zero-day known typically as a single click RCE or
safari remote kind of as some some industry language so what this means is that we could gain remote route level access to your macbook should you click a single malicious link of ours that's kind of terrifying you know a lot of you might feel like you're very prone to not
clicking malicious links or not getting Spearfish but it's so easy maybe you're in a coffee shop maybe I just man in the middle of your connection it's pretty yeah it's a pretty scary world so this is actually a picture that we took on stage at pono in 2018 directly following our exploit attempt this is absolutely Joshua Smith from zdi holding the
competition machine after our exploit had landed unfortunately a little bit too late but the payload at the end of our exploit would pop apples calculator app and a root shell on the victim machine this is usually used to demonstrate code execution so for fun we
also made the payload change that stops background to the right to logo so that's what you're seeing there so what makes this zero date a fun case study is that we had virtually no prior experience with Safari or Mac OS going into this event we literally didn't even
have a single MacBook in the office we actually had to go out and buy one and so as a result you get to see how we as expert researchers approach new and unknown software targets so I promise
that this was a non-technical talk which is mostly true that's because we actually publish all the nitty-gritty details for the entire exploit chain as a verbose six part blog series on our blog this past summer it's hard to make highly technical talks fun and accessible to all audiences so we've reserved much of the truly technical stuff for you to read at your own leisure it's not a prerequisite for this talk so don't feel bad if you haven't read those so with that in mind
we're ready to introduce you to the very first step of what we're calling the layman's guide to zero day engineering so
at the start of this talk I said we'd be attacking some of the most high-value and well protected consumer software this is no joke right this is a high-stakes game so before any of you even think about looking at code or searching for vulnerabilities in these
products you need to set some expectations about what you're going to be up against so this is a picture of
you you might be a security expert a software engineer or even just an enthusiast but through some odd twist of self-loathing you find yourself interested in zero-days and the desire to break some high-impact software like a web browser but it's important to recognize that you're looking to defy some of the largest most successful organizations of our generation these types of companies have every interest in securing their products and building trust with consumers these vendors have steadily even growing their investments in software and device security and that trend will only continue you see cyber security and headlines every day hacking you know these systems compromised it's only getting more popular you know there's more money than ever in this space so this is a beautiful mountain
peak that represents your mission of I want to craft Azure today but you're sent up this mountain is not going to be an easy task as an individual the odds
are not really in your favor this game is sort of a free-for-all and everyone is at each other's throats so in one corner is the vendor who might as well have infinite money and infinite experience in another corner is the rest of the security research community fellow enthusiasts all their threat actors so all of you are going to be fighting over the same train which is the code this is unforgiving terrain in and of itself but the vendor has home-field advantage so these obstacles are not fun but it's only going to get worse for you
newcomers often don't prepare themselves for understanding what kind of time scale you should expect when working on these types of projects so for those of
you who are familiar with the capture the flag circuit these competitions usually our time box from 36 to 48 hours normally they're over a weekend you know we came out of that circuit we loved the sport we still play but how long does it
take to develop a zero-day well it can vary a lot sometimes you get really lucky I've seen someone produce a chrome / v8
bug in two days other times it's taken two weeks sometimes it takes a month but sometimes it can actually take a lot longer to study and exploit new targets you need to be thinking you know you need to be looking at time in these kind of scales and so it could take three and a half months it could take maybe even six months for some targets the fact of the matter is that it's almost impossible to tell how long the process is going to take you and so unlike a CTF
challenge there's no upper bound to this process of zero day Engineering there's no guarantee that the exploitable bugs you need to make a zero date even exist in the software you're targeting you also don't always know what you're looking for and you're working on projects that are many order magnitudes larger than any sort of educational resource we're talking millions of lines of code or your average CTF challenge might be a couple hundred lines to see at most so I can already see the terror
and self-doubt in some of your eyes but
I really want to stress that you shouldn't be too hard on yourself about this stuff as a novice you need to keep these caveats in mind and accept that failure is not unlikely in the journey alright so please check this box before
watching the rest of the talk so having built some psychological foundation for the task at hand the next step and the layman's guide is what we call reconnaissance so this is kind of a
goofy slide but yes even Metasploit reminds you to start out doing recon so with regard to 0-2 engineering discovering vulnerabilities against large scale software can be an absolutely overwhelming experience like that mountain it's like where do I start what foothill do I go up like where do I even go from there so to overcome this it's vital to build foundational knowledge about the target it's also one of the least glamorous
parts of the zero day development process it's often skipped by many you don't see any of the other speakers really talking about this so much you don't see blog post for people like I googled for eight hours about Apple Safari before writing a zero day for it so you want to aggregate and review all existing research related to your target this is super super important so how do
we do our recon well the simple answer
is Google everything this is literally us googling something and what we do is we go through and we click and we download any bookmark every single thing for about five pages and you see all
these buttons that you never click at the bottom of Google all the things are here's related searches you might want to look at you should definitely click all of those you should also go through at least four or five pages and keep downloading and saving everything that looks remotely relevant so you just keep
doing this over and over and over again and you just Google and Google and Google everything that you think could possibly be related and the idea is you know you just want to grab all this information you want to understand everything you can about this target even if it's not Apple Safari specific I mean look into v8 look into Chrome look into opera look into chakra look into whatever you want so the goal is to
build up a security literature a library of security literature related to your target and its ecosystem and then I want
you to read all of it but I don't want you don't don't force yourself to understand everything in your sack of new literature the point of this exercise is to build additional concepts about the software its architecture and its security track record by the end of
the countess's phase you should aim to be able to answer these kind of questions about your target what is the purpose of the software how is it architected that's can anyone describe what WebKit's architecture is to me what are its major components is there a sandbox around it how do you di get how do the developers debug it are there any tips and tricks are there special Flags what does it security track record look like does it have historically vulnerable components is their existing write-ups exploits or research in it etc all right we're through reconnaissance step two is going to be target selection so there's actually a few different
names that you could you could maybe call this technically we're targeting Apple Safari but you want to try and narrow your scope and so what we're
looking at here is a treemap visualization of the the WebKit source so Apple Safari web browser is actually built on top of the WebKit framework which is a essentially a browser engine this is open source and so yeah this is a tree map visualization of the source directory where files are sorted in by size so each of those boxes is essentially a file while all the gray box is too big grey boxes are directories all the sub squares are
files and each file is a size based on it's a lines of code I'm Hugh the the blue hues represent approximate maximum cyclomatic complexity detected in each source file and you might be getting anyway you might be getting flashbacks back to that picture that mountain peak how do you even start to hunt for security vulnerabilities in a product or code base of this size three million lines of code you know I maybe you're in like I don't know like a hundred thousand lines of C or C++ in my life let alone read or reviewed three million so the short answer to breaking this
problem down is that you need to reduce your scope evaluation and focus on depth over breadth and this is most critical when attacking extremely well picked over targets you know maybe you're
probing an IOT device you can probably just sneeze ed that thing and you're gonna find vulnerabilities but you know you're fighting on a very different landscape here and so you need to be very detailed with your review so reduce your scope our reconnaissance and past
experience with exploiting browsers have leaded us to focus on web kits JavaScript engine highlighted up here in orange so bugs and j/s engines when it comes to browsers are generally regarded as extremely powerful bugs but they're also few and far between and they're kind of becoming more rare as more of you are looking for bugs more people are
colliding they're they're dying quicker and so anyway let's try to reduce our scope so we reduce our scope from 3 million down to 350 thousand lines of code here we'll zoom in to that orange so now we're
looking at the JavaScript directory specifically the JavaScript core directory so this is a JavaScript engine within WebKit as used by Safari on Mac OS and specifically to further reduce our scope we chose to focus on the highest level interface of the JavaScript core which is the runtime folder so this contains code that's almost 1 for 1 mappings to JavaScript objects and methods in the interpreter so for example array dot reverse or concat or whatever it's very close to
what you JavaScript authors are familiar with and so this is what the road and time folder looks like at approximately 70,000 lines of code when we were spinning up for Pony owned we said ok we are going to find a bug in this directory in one of these files and
we're not going to leave it until we have you know walked away with something so if we take a step back now this is what we started with and this is what we've done we've reduced our scope so it helped illustrate illustrates this you know whittling process it was almost a little bit arbitrary there's a lot there previously there's been a lot of bugs in the runtime directory but uh it's really been cleaned up the the past few years so anyway this is what we chose for our RTE
so having spent a number of years going back and forth between attacking and defending I've come to recognize that bad components do not get good fast usually researchers are able to hammer away at these components for years before they reach some level of acceptable security so to escape Safari sandbox we simply looked at the security trends covered during their common sense phase so this observation historically bad components will often take years to improve means that we chose to look at
windows server and so for those that don't know Windows server is a root level system service that runs on Mac OS our research turned up a trail of ugly bugs from the from a mockolate from from essentially the window server which is accessible to the safari sandbox and in
particular when we're doing our research we are looking at CD eyes website and you can just search all their advisory advisories that they've disclosed and in particular in 2016 there's over 10 plus phone abilities reported to zdi that were used as sandbox escapes or privilege escalations style issues and so these
are only vulnerabilities that reported as EDI if you look in 2017 there is for all again used for the same purpose I think all of these were actually
probably used at pwned on both years and then in 2018 there's just one and so this is three years over the span of three years where people were hitting
the same exact component and Apple or researchers around the world could have been watching or listening and finding bugs and fighting over this land right here and so it's pretty interesting I mean that gives some perspective the fact of the matter is that it's hard to
write it it's really hard for bad components to improve quickly nobody wants to try and sit down and rewrite bad code and vendors are terrified absolutely terrified of shipping regressions most vendors will only patch or modify old bad code only when they absolutely must for example when a vulnerability is reported to them and so
as listed on this slide there's a number of reasons why certain module or component has terrible has a terrible security track record just try to keep in mind that's usually a good place to look for more bugs so if you see a waterfall of bugs this year in some component like wasm or JIT maybe you
should be looking there right because that might be good for a few more years all right step 3 so after all this talk we're finally getting to a point where we can start probing and exploring the codebase in greater depth this step is all about bug hunting so as an individual researcher
or a small organization the hardest part of the zero day engineering process is usually discovering an exploitable vulnerability that's just kind of from our perspective this can maybe vary from
person to person but you know we don't have 100 million dollars to spend on fuzzers for example and so we literally have one map book right and so uh it's kind of like looking for a needle in a haystack we're also well versed in the exploitation process itself and so those end up being a little bit more formulaic for ourselves so there are two
core strategies for finding exploitable vulnerabilities there's a lot of pros and cons to both of these approaches but I don't want to spend too much time talking about their strengths or weaknesses so they're all listed here the the short summary is that fuzzing is the main go-to strategy for many security enthusiasts some of the key perks is that it's a scalable its scalable and almost always yields results and so a spoiler alert but later in this talk we're gonna see we fudge both of our bugs both the bugs that we use for our full chain and we you know it's 2018 these things are still falling out with some very trivial means okay so source review is the other main strategy source review is often much harder for novices but I can produce some high quality bugs when performed diligently you know if you're looking to just get into the stuff I would say start real simple start with fuzzing and see how far you get so yeah for the purpose of
this talk we're mostly going to focus on fuzzing this is a picture from the dashboard of a simple scalable fuzzing harness we built for JavaScript core this is when we were ramping up for Pony owned and trying to build our chain it
was a grammar based JavaScript fuzzer based on Mozilla's dharma there is nothing fancy about it this is a snippet of some of what some of its output looked like we had only started building it out when we actually found the exploitable vulnerability that we ended up using so we haven't we haven't really
played with this much since then but it's I mean it shows kind of how easy it was to get where we needed to go so
something like we we'd like to stress heavily to the folks who fuzz is that it really must be treated as a science for these competitive targets guys I know code coverage isn't the best metric but you absolutely must use some form of introspection to quantify the progress and reach of your fuzzing please don't just fuzz blindly so our fuzzy would generate web-based code coverage reports of our grammars every 15 minutes or so this allowed us to quickly iterate upon our file helping to generate more interesting complex test cases a good target is 60% code coverage so you can see that in the upper right hand corner that's kind of what we're shooting for again it really varies from target to target this is also just us focusing on the runtime folder if you see in the upper left hand corner and so something that we've observed again over many
targets and exotic exotic targets is that bugs almost always fall out of what we call the hard-fought final coverage percentages and so what this means is
you might work for a while trying to build up your coverage trying to you know build a good set of test cases or grammars for fuzzing and then you'll hit that 60 percent and you'll be ok what am I missing now like everyone gets to 60% let's say but then once you start
inching a little bit further is when you start finding a lot of bugs and so for example we will pull up code and we'll be like why did we not hit those blocks up there why are those grey box why did
we never hit those in our millions of test cases and we'll go find that that's some weird edge case or some unoptimized condition or something like that and we will modify our test cases to hit that code other times will actually sit
down pull it up on our projector and
talk through some of that code and we'll be like what the hell is going on there and so this is actually it's funny this
is actually a live photo that I took
during our ponent own hunt the you know
as cliche as this picture is of half their standing in front of like a dark
screen in the dark room this was absolutely real you know we were we were just reading some code and so it's it's good to rubber ducky among co-workers into to hash out ideas helped confirm theories or discard them and so yeah this kind of leads us to the next piece
of advice is when you're doing source review so this applies to both debugging or assessing kind of those coroner cases and whatnot if you're ever unsure about the code that you're reading you absolutely should be using debuggers on dynamic analysis so as painful as it can maybe be to set up a JavaScript core or
debug this massive C++ location that's dumping these massive call stats that are 100 deep you need to learn those tools are you never going to be able to understand the amount of context necessary for some of these bugs and complex code so for example one of
our blog posts makes extensive use of our r2 to reverse Archer root cause the vulnerability that we ended up exploiting it was a race condition in the garbage collector totally wild bug there's probably I said there was probably three people on earth that could have spotted this bug through source review it required immense knowledge of code base in my opinion to be able to recognize this as a vulnerability we found it through fuzzing we had to root cause it using time travel debugging Mozilla's RR which is an amazing project and and so yeah absolutely use debuggers this is an
example of a call stack again just using a debugger to dump the call stack from a function that you're auditing can give you an insane amount of context as to how that function is used what kind of data its operating it on operating it on maybe you know what kind of areas of the code base it's called from you're not actually supposed to be able to read the size or read the slide but it's a back
trace from gdb that is 40 or 50 call steps deep alright so there's this huge misconception by novices that new code
is inherently more secure and that vulnerabilities are only being removed from code bases not added this is almost patently false and this is something that I've observed over the course of several years countless targets you know
code from all sorts of vendors and there's this really great blog post put out by ivan from GPZ this past fall and
in this blog post he basically so one year ago he fudged WebKit using his fuzzer call it D'Amato he found a bunch of vulnerabilities he reported them and then he open sourced the fuzzer but then this year this fall he downloads fuzzer ran it again with little to no changes just just to get things up and running and then he found another 8 plus exploitable use after free realities so what's really amazing about this is when you look at these last two columns that have highlighted in red virtually all the bugs he found have been introduced or regressed in the past 12 months so yes new vulnerabilities get introduced every single day so the
biggest reason new code is considered harmful is simply that it's not had years to sit and market this mean it hasn't had time to mature it hasn't been tested exhaustively like the rest of the code base as soon as that developer pushes it whenever it hits release whenever it hits stable that's when you have a billion users pounding at it let's say on Chrome I don't know how big that user base is but its massive and that's a thousand users around the world just using the browser who are effectively buzzing it just by browsing the web instead of course you're gonna manifest interesting conditions that will cover things that are not in your test cases in unit testing so yeah it's not uncommon it's a the second point
down here is that it sound common for new code to break assumptions made elsewhere in the code base and this is also actually extremely common the complexity of these code bases can be absolutely insane and it can be extremely hard to tell if let's say some new code that Joe Schmoe the new developer adds break some paradigm held by let's say the previous owner of the code base he maybe doesn't understand that as well you know maybe it could be an expert developer who just made a mistake it's super common now the piece
of advice this should be a no-brainer for bite hunting but novices often grow impatient and start hopping around between code and functions and getting lost or trying to chase use after freeze or bug classes without really truly understanding you know what they're looking for so you know a great starting point is always identify the sources of
user input or the way that you can interface with a program and then just follow the data follow it down you know what functions parse it what manipulates your data what reads it what what writes to it you know just keep it simple and so when we're looking for our
sandbox escapes we knew we're looking at windows server and our research had showed that there's all these functions we didn't know anything about Mac but we read this blog post from keen that was like oh there's all these functions that you can send data to in Windows Server and apparently there's about 600 and they're there there are all these functions prefixed with underscore underscore X and so
these 600 endpoints well parson operate upon data that we send to them and so to draw a rough diagram there's essentially this big red
data tube from the Safari sandbox to the Windows Server system service this tube can deliver arbitrary data that we control it to all those 600 endpoints we immediately immediately thought let's just try to man in the middle this data pipe so that we can like see what's going on and so that's exactly what we did we just hooked up two frite to it another open-source dbi it's on github it's pretty cool and we were able to
stream all the messages flowing over this pipe so we could see all this data just being sent into the Windows server from all sorts of applications actually everything on Mac OS talks to this the Windows server is responsible for drawing all your windows on the desktop your mouse clips your whatever it's kind
of like Explorer yep see on windows so you know we see all this data coming through we see all these crazy messages all these unique message formats all these data buffers that it's sending in and this was just begging to be fudged and so we said okay let's fuzz it and I
remember we were getting all hype and I just simply remember thinking maybe we can jerry-rig AFL into the window server or let's mutate these buffers Radames a-- or why don't we just try flipping some bits and so that's what we did and
so pop our app she had a very timely tweet just a few weeks back that echoed this exact experience he said that looking at my security / vulnerability research career my biggest mistakes were almost always trying to be too clever success hides behind what is the dumbest thing that could possibly work the takeaway here is that you
should always start simple and right so this is our forest farm it's a
single 13-inch MacBook Pro I don't know if this is actually gonna work it's not a big deal if it doesn't I'm only gonna
play a few seconds of it so this is me literally placing my wallet on the enter key and you can see this this uh box popping up and we're fuzzing our fuzzers running now and flipping bits in the messages and the screen is changing colors you're gonna start seeing the boxes freaking out it's going all over the place this is because the bits are being flipped it's corrupting stuff it's changing the messages normally this this little box is supposed to share your password hint but the thing is by holding the enter key on the lock screen all this traffic was being generated to the windows server and every time the windows server crashed you know where it brings you it brings you right back to your lock screen so we had this awesome fuzzing setup by just holding the enter key yeah
and we you know we lovingly titled that
that picture advanced persistent threat in our blog so this is a crash that we
got out of the fuzzer on this occurred very quickly actually this was probably within the first 24 hours so we found a ton of crashes we we didn't even explore all of them there's probably a few still sitting on our server but uh there's lots of Nelda graphs lots of garbage but then this one stood out in particular so anytime you see this thing up here that says exe bad access with a big number of their address equals blah blah blah that that's a really bad place to be and so this is a bug that we ended up using at pwned own to perform our sandbox escape if you want to read about it again it's on the blog we're not going to go too deep into it here so maybe some of you
have seen the info sub comment comic you know it's all about how you know people trying to do these really cool clever things they get people who can get too caught up trying to inject so much science and technology into these problems that they often miss the forest for the trees and so you know here we are in the second panel you know we just wrote this really crappy little fuzzer and we found our bug pretty quickly and this guy's really upset so which brings
us to the misconception that only expert researchers with blank tools can find bugs and so you can fill in the blank with whatever you want it can be
cutting-edge tools state-of-the-art state-sponsored magic bullet this is not true there are very few secrets so the next observation you should be very wary of any bugs that
you find quickly a good mantra is that an easy-to-find bug is just as easily found by others and so what this means
is that soon after our blog post went out so actually at pono in 2018 we actually knew we had collided with fluorescence one of the other competitors we both struggled with exploiting this issue is a difficult bug to exploit you know and we were we had some very creative exploit it was a very strange but uh there was some discussion after the fact on Twitter by Ned started by Ned he's probably out here actually speaking tomorrow you guys should go see this talk about the chrome IPC that should be really good but uh there's some discussion on Twitter that Ned had started in Nicholas who's also here said well at least three teams found it separately so at least us fluorescents and Nicholas had found this bug and we
were all at Ponemah own so you can think how many people out there might have also found this there's probably at least a few how many people actually tried to weaponize this thing uh maybe not many it was kind of a difficult bug and so there probably at least a yeah a few other researchers who are aware of this bug so yeah that kind of closes the you know if you found a bug very quickly especially with fuzzing you can almost guarantee that someone else has found it so I'm going to pass over the next
section to Amy to continue and yeah yep alright so we just talked a bunch about you know techniques and expectations when you're actually looking for the bug I'm gonna take over here and talk a little bit about what to expect when trying to you know exploit whatever bug you end up finding yeah so we have the exploit development is the next step so
okay you found a bug right you've done the hard part you were looking at whatever your target is maybe it's a browser maybe it's the Windows server or the kernel or whatever you're trying to target but the question is how do you
actually do the rest how do you go from the bug to actually popping a calculator onto the screen the systems that you're working with have such a high level of complexity that even just like understanding you know enough to know how your bug works it might not be enough to actually know how to exploit it should we try to like brute force our way to an exploit is that a good idea
well alright before we try to tackle your bug let's take a step back and ask a slightly different question you know how do we actually write an exploit like
this in general now you know I feel like a lot of people consider these kind of exploits maybe be and their own league at least when you compare them to something like maybe what you do at a CTF competition or something simpler like that and if you were for example to be given a browser
exploit challenge at a CTF competition it may seem like an impossibly daunting task has just been laid in front of you if you've never done this stuff before so how can we work to sort of change that view and you know it might be kind
of cliche but I actually think the best way to do it is through practice and I know everyone says oh how do you get good practice but I think that this is actually very valuable for this and the way that practicing actually comes out is that well before we talked a lot about consuming everything you could about your targets like searching for
everything you could that's public downloading it trying to read it even if you don't understand it because you'll hopefully glean something from it it doesn't hurt but maybe your goal now could be actually trying to understand it as at least as much as you can you know it's going to be it's not gonna be easy these are very intricate systems that we're attacking here and so it will be a lot of work to understand this stuff but for every old exploit you can work your way through the path will become clearer for actually exploiting these targets so as because I focus
mostly on browser work and I did the browser part of our chain at least the exploitation part I have done a lot of exploits and read a ton of browser exploits and one thing that I have found is that a lot of them have very very similar structure and they'll have similar techniques in them they'll have similar sort of primitives that are being used to build up the exploit and so that's one observation and to actually illustrate that I have an
example so alongside us at this poni on the spring we had a Samuel cross of Phoenix he's probably here right now but so he was targeting Safari just like we were but his bug was in the just-in-time compiler at the JIT which converts JavaScript to the machine code our bug was nowhere
near that it was over in the garbage collector so a completely different kind of bug but the bug here the he had it was super reliable it was very very clean I recommend you go look at it online it's a very good resource and then a few months later at pwned own
mobile so another pony event we have a fluorescing kit which was an amazing team who managed to pretty much pone everything they could get their hands on at that competition including an iPhone which of course iPhone uses Safari so they needed a Safari bug the Safari bug that they had was very similar in structure to the previous bug earlier that year at least in terms of how the bug worked and what you could do with it so now you could exploit both of these bugs with very similar exploit code almost in the same way there were a few tweaks you had to do because Apple added a few things since then but the path between bug and code execution was very similar then even a few months after
that there is a CTF called real-world CTF which took place in China and as the title suggests they had a lot of realistic challenges including Safari so
of course my team RPI SEC was there and they woke me up in the middle of the night and tasked me with solving it and so I was like ok ok look at this and I looked at it and it was a JIP bug and I've never actually before that looked at the Safari JIT and so you know I didn't have much previous experience doing that but because I had taken the time to read all the public exploits so I read all the pound the other prone to own competitors exploits and I read all the other things that people were releasing for different see bees I had seen a bug like this before very similar and I knew how to exploit it so I could I was able to quickly build the path
from bug to code exec and we actually managed to get first blood on the challenge which was really really cool
[Music] so so what does this actually mean well
I think not not every bug is gonna be
you know that easily to swap into an exploit but I do think the understanding old ex place is extremely valuable if you're trying to exploit new bugs a good place to start if you're interested in looking at old bugs is on places like this with the Jazz vole and DB which is a basically a repository of a whole bunch of JavaScript bugs and proof of concepts and sometimes even exploits for them and so if you were to go through all those I guarantee by the end you'd have a great understanding of the types of bugs that are showing up these days and probably how to explain most of them and but there aren't that many bugs that
get published that are full exploits and there's only a couple year maybe so what
do you do from there once you've read all of those and you need you want to learn more well maybe you start trying to exploit other bugs yourself so you can go for example I like chrome because they have a very nice list of all their vulnerabilities that they post every time they have an update and they even link you to the issue so you can go and see exactly what was wrong and so take some of these for example at the very top you have out-of-bounds right and v8 so we could click on that and go and see what the bug was and then we could try to write an exploit for it and then by the end we will have had a
much better idea of how to exploit an out-of-bounds write in v8 and we've now done it ourselves too so this is a chance to sort of apply what you've learned but you say think okay that's a lot of work you know that I have to do all kinds of other stuff I'm still in school or I have a full-time job can I just place etf's well it's a it's a good question
the question is how much do CTS actually help you with these kind of exploits I do think that you can build a very good mindset for this because you need a very adversarial mindset to do this sort of work but a lot of the times the
challenges don't really represent the real-world exploitation there's a good tweet just the other day like a few days ago where we were saying that yeah Lipsey is leaves like random whoopsy challenges I don't think it's yes his lips see here yeah are often very artificial and don't carry much value to real world because they're very specific some people love these sort of very specific CTF challenges but I don't think that there's as much value as
there could be however a lot of there's been a couple CTS recently and historically as well that have had pretty realistic challenges in them in
fact right now is a CTF 35 c3 CTF is running and they have three browser exploit challenges they have a full chain Safari challenge they have a virtual box challenge it's like it's pretty crazy and it's crazy to see people solve those challenges in such a short time span too but I think that it's definitely something that you can look at afterwards even if you don't manage to get through one of those challenges today but something to like try to work on and so these sort of these sort of new or CTFs are actually pretty good for people who want to jump off to this kind of real estate or real exploit development work however it can be kind of scary for newer newcomers to the CTF scene because suddenly you know it's your first CTF and they're asking you to exploit chrome and you're like what what is going on here so there it
is a bit of a double-edged sword sometimes alright so now we found the bug and we have experience so what do we actually do well you have to kind of get lucky though because even if you've had a ton of experience that doesn't necessarily mean that you can instantly write an exploit for a bug our JavaScript exploit was kind of like that it was kind of nice we knew what to do very right away but the Brat are our sandbox exploit did not fit into a nice box of a previous exploit that we had seen so it took a lot of effort and
quickly I'll show so this was the actual bug that we exploited for the sandbox it's a pretty simple bug it's a integer issue where index is signed which means it can be negative so normally it expects like a value like 4 but we could give it a value like make three and that would make it go out of bounds and we could corrupt memory so very simple bug not like a crazy complex one like some of the other ones we've seen but does that mean that this exploit is gonna be really simple well
let's see uh huh that's a lot of code so our exploit for this bug ended up being about 1,300 lines and so that's pretty crazy and you won't probably wondering how it gets there but I don't say just be aware that if when you do find a simple-looking bug it might not be that easy to to solve or to exploit and it might take a lot of effort but don't get
discouraged if it happens to you it just means it's time to ride the exploit development roller coaster and basically
what that means is there's a lot of ups and downs to an exploit and we have to basically ride the roller coaster until hopefully we haven't the exploit finished and we had to do that for our sandbox escape and so to start I say we
found the bug and we had a bunch of great ideas we'd previously seen a bug exploited like this by keen and we had read their papers and we had a great idea but then we're like okay okay it's
gonna work we just have to make sure this one bit is not set and it was like in a random looking value so we assumed it would be fine you know but turns out that bit is always set and we have no
idea why and note no one else knows why so thank you Apple for that and so really okay maybe we can work around it maybe we can figure out a way to unset it and we're like oh yes we can delete it it's gonna work again everything will be great until you realize that that actually breaks the rest the exploit so it's it's this back and forth it's an up and down and you know sometimes when you
solve one issue you know you think
you've got what you need and then another issue shows up yeah so it's all
about making incremental progress towards removing all the issues that are in your way getting to at least
something that works and so just as a quick aside this all happened within like 60 minutes one night yeah there was
just Amy saw me just like I just like out of breath I was like are you kidding me like there's two bugs that tricked us off that meant that made this bug much more difficult to exploit and there is no good reason for why those issues were there and so it was a horrible experience but it's the one I'd recommend yeah sure and so the this roller coaster I would say actually applies to the entire
process not just for you know the exploit development because you'll have it when you find crashes that don't actually lead to vulnerabilities or unexplainable crashes or super unreliable exploits you just have to keep pushing your way through until
eventually you hopefully you get to the end of the ride and you've got yourself a nice exploit and so now okay so we we
assume okay we've written an exploit at this point it's a maybe it's not the most reliable thing but it works like I can get to my code exec every now and then so we got start talking about the payload so what is a payload exactly a payload is whatever your exploits is trying to actually do it could be trying to open up a calculator on the screen it could be trying to launch your sandbox
escape exploit it could be trying to clean up your system after you're explained by that I mean fix the program that you're actually exploiting so in CTFs we don't get a lot of practice with
this because we're so used to doing system you know cat flag and then it doesn't matter if the entire program is crashing down in flames around us because we got the flag and so in this case yeah you got the flag and then it crashes right away because you didn't have anything after your option but in
the real world it kind of matters a little more so here's an example of like what would happen if your exploit didn't
clean up after itself and just crashes
and goes back to the login screen this
doesn't look very good this if you're at a conference like pone to own this won't
work I don't think that they would let you win if this happened and so it's
very important to try to go back and fix up any damage that you've done to the
system before they crack be right after
you finished all right and so actually running your payload so a lot of times we see are in the
exploits we'll see that you'll get to the code exec here which is just cc's which men means int three which just tells the program to stop or trap to a breakpoint and all the exploits you see most of the time they just stop here they don't tell you anymore and to be fair you know they've gotten you code exact they're just talking about the exploit but you know you still have to figure out how to do your payload because unless you want to write those 1300 lines of code in handwritten assembly and then make it into shellcode you're not going to have a good time and so we had to figure out a way to
actually take our payload write it to the file system in the only place that the sandbox with lettuce and then we could run it again as a library and then it would go and actually do our exploit and so yeah and so now that you've like
assembled everything you're almost done here you have your
exploit working you get a calculator pops up this was actually our sandbox escape running and popping calculator and proving that we had root code exec
but we're not completely done yet because we need to do a little bit more which is exploit reliability we need to make sure that our exploit is actually as reliable as we want it to because if it only works one in a hundred times that's not going to be very good for
pone to own we ended up building a harness for our Mac which would let us run the exploit multiple times and then collect information about it so we could look here and we could see very easily how often it would fail on how often it would succeed and then we could go and get more information maybe a log and
other stuff like how long it ran and this led it made it very easy to iterate over our exploit and try to correct issues and make it better and more reliable we found that most of our
failures were coming from our heap groom which is where you try to align all your memory in certain ways but there's not much that you can do there in our situation so we tried to make it as best
as we could and then accepted the reliability that we got used something else might wanna test on is a bunch of multiple devices
for example our JavaScript exploit was a race condition so that means the number of CPUs in the device on the speed of the CPUs actually might matter when you're running your exploit you might want to try different operating systems or different operating system versions because even if they're all vulnerable
they might have different quirks or tweaks that you have to do to actually make your exploit work reliably on all of them we had we wanted to test on the mac OS beta as well as the normal mac OS
released so that we could make sure it worked in case apple pushed an update right before the competition so we had to make sure that some parts of our code and our exploit could be interchanged so for example we have addresses here that we were specific to the operating system version and we could swap those out very easily by changing what part of the code is done here yeah and then also if
you're targeting some browsers you might be interested in testing them on mobile too even if you're not targeting a mobile device because a lot of times the bugs might also work on a phone or at least the initial bug will and so that's another interesting target you might be interested in if you weren't thinking
about it originally so generally what I'm trying to say is try throwing your exploit at everything you can and hopefully you will be able to recover some reliability percentages or figure out things that you overlooked in your initial testing all right I'm going to
throw it back over for the final section so I didn't get a get to spend as much time as I would have liked on this section but I think it's an important discussion to have on here and so the very last step of our layman's guide is about responsibilities and so this is
critical and so you've listened to our talk you've seen us develop the skeleton keys to computers and systems and devices you know we can create doors
into computers and servers and people's machines you can invade privacy you can
deal damage to people's lives and companies and systems and countries and so there's a lot of you have to be very careful with these and so everyone in this room you know if you take any of our advice going into this stuff you know please knowledge what you're getting into and what can be done to people and so there's at least one example that's kind of related that you know I pulled out
quickly that you know quickly came to mind was in 2016 I I have supposed to remember this day actually sitting at work and there's this uh there was this
massive DDoS that plagued the internet at least in the US and it took down all your favorite sites Twitter Amazon Netflix Etsy github Spotify reddit I remember the whole internet came to a
crawl in the US this is a l-3 outage map this was absolutely insane and I
remember people were bouncing off the walls like crazy you know after the fact and they're all referencing Bruce niners blog and they were you know on Twitter there's all this discussion popping up that this was likely a state actor this was a newly sophisticated DDoS attack Bruce suggested it was China or Russia or you know some nation-state and the blog post was specifically titled someone is learning how to take down the internet but then a few months later we
figured out that this was called the mirai botnet and there's actually just a bunch of kids trying to ddos each other's Minecraft servers and so it's a it's scary because you know I have a lot
of respect for the young people and how talented they are and it's a but people need to be very conscious about the damage that can be caused by these things Moriah they weren't using O'Day's per se well later now nowadays they are using O'Day's but but back then they weren't they were just it was an IOT based botnet one of the biggest in the world or highest throughput but it was incredibly damaging and you know so when
you're it's hard to recognize the power of an OU day until you are wielding it and so that's why it's not the first step of the layman's guide once you finish this process you'll come to realize the danger that you can cause but also the danger that you might be putting yourself in and so I kind of want to close on that please be very
careful right and so that's all we have
this is a conclusion the layman's guide that's the summary and if you have any questions we'll take them
now otherwise if we've run out of time you can catch us after the top and we'll have some cool stickers too so
[Music] Wow great talk Thanks we have very very
little time for questions if somebody's very quick they can come up to one of the microphones in the front will the handle one but otherwise will you guys be available after the talk yeah we'll be available after the talk if you want to come up in chat I we
might get swarmed but we'll also have some cool right to stickers so come grab them if you want them I didn't work where can we find you we'll be over here we'll try to head out to the back yeah yeah because we have another talk coming in a moment or so okay I don't see any
questions so I'm going to wrap it up at the at this point but as I said the speakers will be available let's give this great speech another round of applause [Applause]
[Music] [Music]
Feedback