>> I would like to introduce John, Menerick speaking of open source fairy dust andpoking holes in all sorts of weird crap.  So     ‑    ‑      
>>  Good morning, everyone.  Would anyone like some bubbly?  Come on up.  Come on.  Anyone right here.
>>  Yeah, I need alcohol.
(Laughter).
>>  I just asked that individual, do you have a driver's license.  Steal his identity.  He was like fuck you.  I was like damn it.  Cheers for the lovely champagne and, yeah, this talk is going to be interesting.  We'll talk about projects, particular the ones that Al lout internet to run or vice versa, quite interesting and overall in my day to day life or in real life I am a security dragon.  I do fun things, good or bad depending on your pointer of view.  Let's get the legal part out of the way.  The views and pins expressed here are my own, only and in no way represent the views it, positions or pins expressed or implied of my employer presenter or past of any one else of my thoughts or opinions are like to change from time to time.  This is an off shoot of having an open mind.  So let's start off with what we're not going to be talking about.  We're not going to be talking about wars between proprietary.  We're not going to be talking about the scary vulnerabilities in projects because I like to open a big toolbox.  I'll be dropping the latest and greatest here.  I haven't told anyone.  Hey guys I have this awesome exploit for Linux.  I don't think a lot of people would be happy with me but I know I would Ma ache lot of underground people happy.  So what we're going to talk about is this magical theory about unicorns pixies and fairy dust.  LL cat looking down on you and everything is magical and fun and then I was looking at node.GS from a security perspective, are they checking validations and things like that and I was oh my God this is scary.  Where is the bleach.  I need it for my eyes.  What is going on.  I looked at spying, I looked at MGP, I looked at web servers and I looked on and on and I was like this is really bad.  Then I started looking at is this a systemic issue.  What's going on.  So, it's like what's going on?  So, we're going to start off way very simple welcome to open source.  Welcome to the internet.  Here's some of the data that I found.  And then show you guys how to reproduce this and test it all on your own.  So we'll have our lovely assistant Jen here show us the internet.  Yes, the internet.  This is a hilarious prank blowing up on youtube but circa 2007, AT&T created this cute little info graphic of the internet.  It's a huge map where it's basically a collection of things that agreed to share information with each other.  Hey, I'll send your way if you send it your way.  How are we going to do.  Let's use open standards.  Way back in the early days of the internet got my former mentor, I use a     ‑    ‑     a strong contributor to the home group video club featured the early days where you had all these people sharing source code with each other.  From there it grew into this ideal where open source software, open standards, open free bear, free hardware.  When you have this ideal kind of growing over time through decades you start to get a lot of fallacies and myths untruths about it.  One of the biggest ones that I saw was no one ever said that it was secure.  Sure, free, take it but it was truly never secure.  And then that's what I thought about a month ago when I was watching a presentation about the history of the internet and I lied.  Someone said open source is more secure.  Everyone's looking at it and everyone's     ‑    ‑     it's locked down, yeah, and I'm like I quick rewind back, flipped through the title.  Internet society president, one of the organizations for the internet said yeah this stuff is all right its secured.  Just ignore attacks, just ignore all the fundamental design flaws.  And, yeah, it's not secure.
>>  (Inaudible).
(Laughter).
>>  You really need to work on your slides, man.
(Laughter).
>>  It's just so genius it just bleeds into people.  You don't even have to see.  It just bleeds through the screens.  So, I would like, if I may, to tell you a short story about the next policy.
>>  (Inaudible). 
>>  So, this is a sort story about four people named everybody, somebody, anybody and nobody.  Okay, good times.  There was a job to be done and everybody was asked to do it.  Everybody was sure somebody would do it.  Anybody could have done it but nobody did it.  Keep going on.  Somebody got angry that     ‑    ‑     somebody got angry that no one really did anything because it was, can we guess why?  Everybody's job.  Everybody thought that anybody could do it.  Nobody realized that everybody would not do it.  So, we end up with everybody blamed somebody and nobody did what anybody could have done.  Now, when I read this story online I was like wait, where have I seen this recently?  Oh, that's right the security chamber in the blogosphere blaming SSI, like oh, heart bleed it was so easy to find, anybody could have found it, it was in there for years.  Take those one to three developers and lynch mob them.  I'm like, wait, what, one to three people?  Huge code base.  If you've ever seen the hollow rampage     ‑    ‑     you should read.  And, no, and, you know, further echo chamber where hey guys I'm the policy of everybody's looking at the code or hey, guys, let's make sure there's nothing on there.  No.  They're really not.  Or if they are.
>>  I have a different code for you.
>>  Yeah, drink, motherfucker, drink.
(Applause).
>>  Congratulations.
>>  And actually that's really interesting.
>>  (Inaudible).
>>  Yeah, right.  But I can't.
>>  Good morning.
>>  Good morning.
>>  And good luck.
>>  Thank you.
>>  All right.  So, who are the type of contributors who help out with open source projects.  In the lower right you have the activist.  Touring other's work, they want to contribute or create owned property to solve a particular ethical, moral or lifestyle choice.
>>  Code that when you run it it prints up the source code in the shape of a camel.  Cool I guess or just do it for the hell of it.  And then till you see more on the internet infrastructure open source projects was more financially motivated contributors where they're like this company will come in and say, hey, there's a large sum of money, can you write this feature for us.  You can contribute it, open source was like hey, can you write it for us or you'll have institutions will be like, hey, I have some money here, I don't really care how you spend it, you guys are doing an amazing job.  Go on.  Or you'll have others that are like hey, I really like what you're doing with this language or project.  Come work for us and you'll spend half your time and work on your project.  Interesting incentives but effectively overall these are very crucial projects that are maintained, created by a strained cadre of volunteers.  Very rare to use incentivize.  They're strange and it's pretty saw.  When you end up with strained resources you have to presidential candidate your priorities.  So let's pick a very over simplistic list, functional, stability, compliance, performance, usable/maintainability and then security.  Well, when I create something on the internet that I want to run and just work fairly well, functionality, nah, not so G you're seeing projects that whenever I run these systems I'm not looking for the latest and greatest thing.  I'm looking for the most stable thing and since I love bashing out compliance, let's get that one out of here.  Compliance is the by product of the bit security program but unless you're dealing with crypto or situations where your project need use such as Phipps, no compliance after thought.  And I'm not sure how many of you have ever played with host rules but usability/maintainability not really an operation up there.  Like that's nice but they don't care.  We're not going to maintain it.  We're left with three.  Stability, performance and security.  So, the fun part is I originally thought security was kind of up there.  Like stealing candy from a baby, you'll find something in there butter once you get to a certain level then they're financially motivated to care about security, either reputation or context but for the most part they really only care about two things, performance and stability, the network     ‑    ‑     this admin, this reliability in here.  They just want D and S that works.  They own have to play one or two machines and off it goes.  But ultimately you have these very limited number of contributors who have really only so much time in the day.  You can't grow time.  So, you end up with a lot of thrift code being created with very little attention.  It actually kind of makes it kind of hard.  So, now we're going to play a game.  Name this programming language.  So, here we have a an awesome set of guys, living the life, cool, water's there, looks like a grille, electric, hooked up to an extension cord.  HP up here and someone said that yesterday but we'll get to that but no.  No, you're not far off but there's a better analogy.  The extension cord with the water going through, can anyone guess what it is?  CC plus plus.  I guess the easiest way to define it is from one of the top I'd say     ‑    ‑     when you carry pointers around and can't track if they're live or how long they are it's going to hard.  The hard part is     ‑    ‑     thousands of lines of code, thousands of files it's not that you have to worry about your application logic but with this language you have to start worrying about memories, you have certain memory management and boundary management and exceptions and oh, God, my brain is tired of thinking about it.  There's going to be a hobbyist thrown in here or the project themselves but unless they have a very strong security development background which none of them really do, C, C plus experts and java, man, what can I say about java these days?  I think Charlie Miller said it best.  It's not like java got insecure all of a sudden.  It's been insecure for years.  The hard part is the life cycle it's like we need to get this out the door, we need the pack and shit we're making decisions at 4:00     a.m. we have to live with for the rest of our lives.  We'll come back to that tomorrow.  And really smart people working on this create a program like java, write once, run anywhere really hard.  And well, for the lovely fellow who loves to talk about PHP, kind of like programming  with a noose around your head.  It will give developers plenty of room to program their write and before you know it the noose is around your neck and you're like oh, shit, fuck and, bam.  And I'm not really going to talk about go, dart, fortunately but I don't like looking at Pearl.  But there's tons of languages out there.  From what I've seen just browsing, what would I use to run DNS, what would I use to run X, old school going way back to the bricks of building of the internet and you'll see CC plus plus has survived over the years.  So when I started looking at all these different projects of, hm, there's so many out there, what did I look at.  It's like well there's some really big warning signs.  I could go on about the technical side of really old security vulnerabilities that are still opened that they haven't patched or, you know, if they can't even do the functional feature requests from ten years ago they're probably not even caring about security.  But the obvious one is no strategy from the project coding and everything where someone will come in and they'll code for a year or two and then kind of give it up and then someone will work off the source code and then they'll go to the other side and go it was cool or development‑    wise you have people going here and there, implement their own memory allocation management, libraries and they'll introduce     ‑    ‑     instead of strategizing the not the greatest research comes out crowd here and yeah it's quite interesting.  And this one     ‑    ‑     next one should be fairly obvious.  So, when I was     ‑    ‑     I think I have probably a few thousand vulnerabilities in exploit.  Some of these I have to really tell someone.  Looked in their web site, looked in their source code and I'm like how do I tell them.  Send E‑    mails to their RFC's security app, no response.  And I was like fine i really have no choice.  Throw it up in their issue tracker.  Then one of the core developers says John, why did you put this here?  Everyone can see this.  And I'm like because I didn't know where else to put it.  I looked on Google, didn't find anything, looked on your web site.  Here's a patch for your read me.  I'm sorry .  
(Laughter).
>>>  But unless these projects had a large swath of issues coming their way they don't really know thousand digest them.  They don't know how to handle them.  And second to last, complex code.  This is quite technical but looking through this code and it looks really complex and you're like I don't really know what's going on here.  Reality is neither does the developer.
(Laughter). 
>>>  And as you can see this chart green is bad, red is kind of good.  But, um, yeah, just complex code.  Now the Black Hat, there's a lot of old installations running, so old versions for engine X.  Why?  Because change is actually hard.  I didn't see how security go in there you need to upgrade your patching server because Kaminski just said something awesome and DNS admins will be like oh but you don't have to suffer any of the consequences and we were like, yes, that's nice, go ahead upgrade it.  So a lot of people rarely upgrade unless they're force to do for compliance obligations.  But ultimately change is hard.  So, where are we now?  That is the great question.  Now that we've gone through the history.  Start looking at what we're going to be doing.  So, I've studied a lot of the major open source projects for web servers, hyper visors, since our audience is bunch of security, security tools, MP3 servers.  I don't like Windows programming so much other than very new areas working on services a lost people typically don't run Windows technology for infrastructure services.  Typically it's DSP.  Can anyone tell me what I think is the scariest most vulnerable open source project out there today that everyone is using $50 for someone who can tell me the name of the project that is the most vulnerable.
>>  (Inaudible).
(Laughter).
>>>  Here's a hint its a mail server.  Not send mail.  If you think ex‑    ‑     you would think exchange but can't make any statements to that.
>>  Hugo.
>>  Who said XM?
>>  Here you are, sir, come on up.
(Applause).
>>  (Inaudible).
(Laughter).
>>  Exactly.  So, let's look at the data, shall we?  Okay.  So what we have here is good old blue charts.  Kind of fun.  So what we have done here is critical deaths is the.  We have critical density as every how many lines of code there would be one, you know, vulnerability.  What I did is inversed that saying for every line of code how likely is there to be a vulnerability.  And then same with high density.  High vulnerabilities, you know, not critical, not at low, quantitatively I could go on for hours but the reality is up and to the right is scary.  Down to the left is safe.  Then we have here color wise just a pure number of critical vulnerabilities, just overall.  And then the size just an idea of the size of the project.  So, not just executable lines of code.  So XM has 13,000 critical vulnerabilities.  What the hell?  And X bit of lines of code, sure up and down you could argue but 35,000.  Yeah.  Let's go all the way down here, 290 critical vuln.  Yeah, so on this chart you really can't tell.  They're all relative to each other.  But when you look at the overall and XM's an outlier.  So, DNS, God, feels like I'm just beating on a dead horse.  Yeah.  Bind, let's look at a really old version of Vine.  Bind eight, just continued this.  It was a horrendous project, we're going to tear it all down with bind nine and start anew.  Deadline for development life cycle, now we have to make priorities, you're making shareholders happy so overall, you know, not bad but when you say not bad 6,000 critical vulnerabilities, 4,000, I mean, was the into your versions per se, 2000, it's better but, yeah, that's scary.  So, normally I would have Bundy or bind ten out here     ‑    ‑     up here.  I won't go into reasons why that was a failed project.  Most likely it was split off and there was a write 68 presentation on the magical fairy dust of that progress and how it's bastardized and kicked off but effectively it would make all of this look like an outlier.  Also many of the other open source DNS projects that would look far down to the left, like they're actually pretty solid and on their web sites, say, hey we actually care about security and we do it well.  Web servers.  Top and to the right, 90, 98.  Not too bad and number out here, okay, cool, and then engine X.  You think there would be a lot but you can see as I slowly move down here it's a little bit better and then down there solid Apache.  They do testing, they have a lot of infrastructure built up, so overall, I'm going to pick Apache over Lidy.  Let's look at good old open source operating systems.  Since I didn't have enough time nor sanity to go through the DSB set and many others I created this picture versions of Linux and just for shits and giggles let's do zen.  Not that bad.  139 bricks.  Doesn't get down to Linux.  The 3261 series, not that many criticals.  They're pretty responsive, proactive.  What's wrong with you, blah, blah, blah, not appropriate.  Yeah.  And I was like hey let's just lick the file system and devices and that's really where a lot of the vulnerabilities existed, the device drivers and file system.  For the core part I'm sure there's a few there in crypto but not really.  It's actually pretty solid.  Time, something we never have enough of.  Yeah.  MCPDAV, still not that bad.  MC P‑    4 26, 139, no the that bad.  KRONI better.  And open MPC didn't have a lot of crits.  So then we start looking over here at FSL, right.  Everyone loves open SSL so this is an old release.  And, yeah, it was bad.  4500 criticals.  Way up here crypto cat.  Look at it this way.  So, here we have high density, critical, crypto cat, SSL, main base they're working out of but imagine the amount of technical security.  As these different teams, you know, transfer the code and they let off everybody's doing better.  SSL21crits.  GSR, java, cryptos, doing better.  Java, open SL, 98, bitcoin, everyone looks for bitcoin, I don't have the status up here but bitcoin, two, three years ago, set up I analyzed it and it was scary.  Now when I came back and it was cleaned up so thank you to whoever looked at all that source code and cleaned it all.  And crypto.  Yes.  All of the fun application libraries.  Before we get there let's talk about security.  Open PPGJS.  That's kind of scary.  You know what's also scary, really, really old version of snort.  NCH root kit has a few crits.  Has some privilege escalations that no one else has.  Another version of pseudo, snort, little bit more compliant.  Tech secure, java, snort, snort, tour has some issues but nothing really bad.  Open GPN.  I was expecting open GPN because I really wanted some code execution exploits.  There are few but it's pretty solid surprisingly.  Yes, so, I like core libraries but what I use on a daily basis that I would love to see exploits and vulnerabilities for so I just picked a few.  So, way up to the top left we have W get.  I should have done lip curl and curl but I didn't have enough time but, dude, W get is vulnerable.  It needs some attention from either part, white hat or Black Hat.  Barb, not that bad.  There's a few things.  And then SSM peg, I believe they're     ‑    ‑     they were talking about hey, guys, watch out, there's flaws in SSM peg.  Look remote code execution.  Awesome.  Installed everywhere.  And I'm like really, it's not that bad, a the least the stuff that I'm seeing, so, yeah it's     ‑    ‑     there's a lot of people that SSM peg is really vulnerable.  In my perspective there's a lot more scarier stuff out there.  So, here we go.  Looking at kind of all those low data sets together, far out and to the right is XM.  Now one thing about this from the previous ones now we're looking at this from a log rhythmic perspective.  If we were to do this linear, it would be like oh, yeah, hey, no, no, no, that's an outlier.  No, it's legit.  But I'm like yeah, it's bad.  So, yeah, it's out there once again.  But, um, open SSL, old versions, W get's out there, crypto cat way down here, Linux.  Okay, interesting.  Not as scary as you would have thought.  And then, yeah, are you surprised?  So, I'm going through about 2000 plus open source projects, open up their repositories and going through it.  Most of them are all right.  But the critical internet ones are pretty scary.  They're not trying to make the world secure.  So, with that being said, (Inaudible) where would I be without all of the good juicy exploits and vulnerabilities.  So let's like name this project.  So, what we have here is a couple of java applications, hello, bit further down below towards the bottom line 119, okay go do something, trans this form, send that request log.  As you get further along, highlighted, I'm looking through this there's like HTmel.  Content injection.  That's not the worst thing in the world but, you know, okay, you're kind of failing at it but you're in many places but not here.  Can anyone guess what is this project?  Anyone?  Buehler?
>>  (Inaudible).
>>  Big data.  Anyone.  Pretty close.  GFS.  They try to do well.  Yeah, it's interesting.  So, one of those warning signs to you.  This code is shit.  It's badly formatted.  It's hard to understand.  It readmits tons of things which are already in the server core.  If you're like me with my nomadic application library, yeah I'm going to get this thing and at the very bottom, okay, cool, do some stuff, I'm going through then at the very bottom and the farther left you can barely see you're like rather mal.  The server source code says this will always succeed.  And yes, it will.  Name that project.  Free radius.  Short simple one.  Yeah, this one is the typical of this project, you know, I'm going call this array, when I look at it dynamicly, okay, cool.  And down below you stuff the array with this value, 96 bites, so 96, H, throws it in, loads it up out of bounds.  Oh, XM I love you.  So what we have now are Black Hats.  Some projects.  It's out there.  It's vulnerable.  It's easy to produce but the white hats here, make sure you apply their appropriate risk management.  Third party source code that you include in your projects or use in your infrastructure and use operational security best practices.  Make sure everything is secured.  So, yeah, many people looking for these.  I was amazed that I was finding these, just pure number like hell why am I not seeing these mailing list, why are all these entities such as the MXA, and others just     ‑    ‑     who     ‑    ‑     am I the only one using my toolbox?  Like what's going on here.  I'm not doing anything really special and neither do you have to as well.  So, whether or not you want to do this for street cred, to get a job or say, hey, look at my name, I'm a nar cystic vulnerability pimp or maybe you want to sign off as net dad and say hey I pulled off this exploit or you want to do it for the lulls like watch this explode, quick send, like here's a cool exploit for Linux through the terminal, everybody will be like, oh, or pretty much like myself, you're like worst case     ‑    ‑     what you could also do is go more the white hat route, bug bounty program, they'll offer you some small sum of money depending on the person who's paying or you can kind of go the gray market where ethical, legal, moral boundaries aren't so clear and you could go straight underground and get 100 to a thousand X.  But really depends what is your incentive.  'Cause once you figure out your incentive, really determines how much time and resources you're going to put into this.  My typical stack was using gift such that I didn't have to watch all the time, I just had my automation take off.  Oh, look, somebody did something at 2:00 a.m.  I didn't have to wake up.  As using Amazon web searchs, a few hundred instances, you don't really have to, really depends on what scale you want to go.  You could have it run on moderately powered laptop, decent solid drive and memory.  Just like Neal said we need guns, well, we need memory just to handle all of this.  And I used Jenkins and tracked everything, which ones are scary, which ones are not.  Hey, John you need pay attention.  Ultimately I was doing static and dynamic analysis.  On the static side you could use cling, good old break man, find bugs or use a proprietary software such as fortify and there's tons of these tools out here.  You just have to understand the limitations of each but static has its faults.  It won't find everything.  It says I think there's something here I'm not really sure.  That's when you refer to get the dynamic side as well.  D trades, RDDB and then really hit it such that you get your code coverage as well so when you get all three together you're like, wait, I know how to reproduce this, hello exploit but I also see.  And if you don't want to do this, there's a lot of new infrastructure projects towards open source project but they still haven't made you identify yourself as, hey, I'm from IFC, so you just say yeah, probe bind in there and they'll break it and give you all the vulnerabilities so thank you.  Swap is a great tool like that.  But ultimately you'll end up with all these vulnerabilities, you need some assurance such that when I come up with you I'm not blowing a bunch of hot air in your face.  So look at the natural vulnerability database and work backwards.  Run all your shit on it and be like hey what's going on here.  I didn't find it and then find out why and keep fine tuning it until you get there.  You're going to have a lot of chat and you need to separate the two so since I love programming, working with data sets and everything, it's pretty easy to get a very black and white, sure there will be a area of gray and that's where your manual side comes in, and also source code in addition to static and dynamic but I know math and commuter science is hard so here's some research from some Stanford researchers, they're like hey you have all niece vulnerability data sets from distinct sources here's how you pull them altogether.  Okay.  So, without going into the gibberish math there in the lower left of the screen, effectively you have those data sets, how confident are you, okay, cool, did some cool     ‑    ‑     does some cool stuff and then pulls that many altogether.  Nice.  Now I need to rank them.  They also produced ranking.  So, if you can imagine the network here isn't that safe and I don't really trust right now anything that's electronic.  So, when I get back home I'll code all of the source code, all of the findings so that they summarize and I'll be like hey guys look at some of my previous note you'll see where I ripped apart open SSL, node.  There's tons of stuff there. ultimately the web site for this is going to be hack the planet dot ninja.  So just go to the internet here, use all your fun stuff.  Now you have to have all the fun little fonts and all that but effectively that's it.  So, I would like to thank everyone for comeing.
[Applause].
>>  Oh, wait.  One more thing.  You guys are keeping     ‑    ‑     I have always wantd to see a remote execution or exploit for notepad.  Like come on where is it?  I've been waiting.  Privilege escalation anything?  No.  I'm like wait, pike company.  Let's hate on some E max.  Here we have E max.  I won't say too much but 2788 here's your array 4,000 bites in size, very large number of stuff in there.  Yeah.  Nice try.  But thanks.  No thanks.  I like Zim.  I'll stay.  Thank you for coming.  That's all.
(Applause). 
>>  Why did you set up your own Jenkins box?
>>  I have a lot of Amazon credits.
(Laughter). 
>>  Pick the tool that's best for you.  Whatever makes you happy.
>>  Thanks.