>> 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.