PG - The Lore shows the Way - Eric Rand

now do I get a yes all righty good afternoon uh my name is Eric ran on the twitters you might know me as mutant some other places too I won't mention them here you'll see a URL there round hat security com / Lord ODP if you want the slides afterwards for some stupid reason go ahead and grab them I so we'll start out basically lore is basically what amounts to knowledge there's a lot of fun connotations that tend to come with it people assume it's something that comes in tomes of Forgotten lore or refers to really kind of strange subjects like the lore of herbs or the lore of birds or all sorts of weird

things what comes down to basically is knowledge that is fairly specific for a field that's all there is to it it's a fun word it's very evocative I like using it go ahead how it applies to information security basically you're looking at a whole bunch of different applications that you might have the kind of jargon the various other things that people in the information security field are assumed to know and are assumed to pass down to the various people that they mentor or teach over time so on top of the various positive implications there's also some negative ones there's the constant fight between for instance the VI and emacs folks which I'm sure everyone has encountered

from time to time there's the language based nonsense that happens with OC is better Java's better you both don't know what you're talking about pearl is the best what is pearl it's nothing but bash your face on the keyboard etc there's very positive and very negative things that do get passed down keep these in mind so to talk about the rest of this talk I'm going to introduce a topic that is a little bit outside the scope of info SEC that's tropes for those of you who have not been to TV tropes I'm sorry for the next month because you will lose it basically a trope is it's a device for convention it's something that is

culturally recognized that the author or screenwriter or producer can essentially leverage to get the kind of reaction that he wants so you see there you've got your Cowboys fighting having a tussle the guy with the white hat is obviously the good guy they got the black hat is obviously the bad guy we in the info SEC community know about white hat and black hat and all the other shadings of hats we like hats ah but basically because you're aware of the tropes of the Western you can tell instantly without any other context what's happening in this particular still the good guy has just got the drop on the bad guy and is holy them up with

a six-shooter that's obvious or should be obvious so basically the condemned condensation of tropes leads to the kind of cultural expectations that you can work with and this kind of cultural knowledge ends up producing certain effects because if you are in a culture and you're aware of the cultures expectations then you know what you are it's how you are expected to behave whether you behave in line with the expectations or whether you deliberately violate those expectations leads to whatever actions you take having certain consequences and those consequences especially if they're widely known feed back into the cultural knowledge so basically if you act in line with the cultural knowledge with the kind of expectations the culture has of you

then the kind of consequences are fairly predictable if you violate the expected actions those consequences are likely to be fairly predictable also unless you happen to do something completely new and innovative but not a lot of people go and violate cultural expectations and completely new and innovative ways so all the world is a stage it's fairly true people do tend to play out relatively predictable roles and if you've ever really looked into social engineering you can see that that's kind of what makes it work you take on a certain role when your social engineering and you expect them to react in a certain way according to that role that you've taken so if you expand that

out a little bit basically what it comes down to is if people are in a certain situation they will tend to think and react in relatively predictable ways that's how culture works so we'll examine that a little bit with a neat little thing from 1981 how many of you know what tftp is and who's used it in the past year okay so pretty much the basic idea of tftp is the simplest possible way to get a file from one computer to another across a network really simple the client goes queries the services i want this file the surface says okay here's the first chunk the client acknowledges sends a knack okay I've got the first junk to be the

next one and it continues on and on the Sorcerer's Apprentice bug results from naive implementations of tftp basically what happens is when you get a certain amount of traffic clogging up the network you end up with what amounts to a a timeout condition the packets are delayed and the client sends a request I didn't get that packet give me this so in the naive implementations basically what it came down to was that when the server received a duplicate request for packet number six will say I want packet number six I want pack at number six it would send out packet number six in response to both of those requests and unfortunately the way the client was written when it got pack at

number six it would send out the acknowledgement and request for packet number seven both times which quickly led to traffic kind of exploding and it started to really clog up the network and if it was left to go on long enough like that the situation could grow quickly worse and worse and worse and generally you ended up with not only the tftp client and server having issues let anyone else who is on the same network segment or any other affected Network segments leading to what amounted to a completely melted down network which is not exactly an optimal situation for anybody so okay that one turned out to have a relatively simple fix as these things go RFC 1123 basically said okay

the server isn't supposed to go and get completely hog wild if it starts receiving a lot of duplicate requests it should only send a response to the first one easy enough a little more complexity on the server which can handle it the clients are dumb for tftp its intended for really dumb clients so the server can handle it problem solved not so much roughly 22 years later in the Apache Commons tftp implementation the same thing happened again because they forgot about RFC 1123 they just looked at the original one and as it happened they ended up by using essentially the same implementation the first time the same thought processes they ended up with what amounted to the same problem

notice that it took just over 22 years for that to recur this becomes kind of significant same need same thought process same bug more or less what I just said but it's worth reemphasize thinking along the same lines will end up leading you to the same traps so fixing it good old research and actually this slide is already obsolete those of you with time machines will want to go back to yesterday and look at the ontology a young intelligence primer talk which has a really great solution for this I will have looked forward to have been seeing you basically the what it comes down to for this obsolete methodology is to look at the complete

RFC history don't just look up whatever comes first look up all the rfcs that pertain to the kind of protocol that you're implementing other people have done the same thing in the past no doubt there are very few really novel software projects out there a lot of the stuff at least partially reimplement solder stuff learn from their mistakes it's it do the homework and you don't end up with the same problems and there are many older developers who have definitely been there they have seen this even if they are talking about their racing pigeons in the meantime try and pay attention at least a little bit when they're talking about things that are recognizable is

work so segwaying on two strings walk into a bar the first string says I'd like a beer the second string says I'd also like a beer hash ampersand ! correct horse battery staple 5283 the first string says I'm sorry my friends not null terminated so for those of you who laughed you recognize the inherent problem with some of these ctypes is that they're not really that safe to use they lead to certain problems and a lot of them are concerned in fact with strings strings do tend to run on for a while and if they don't have that null you end up hopping off into wild and unexplored territory and potentially getting some interesting stuff back out so there's all sorts of

very bad consequences of this kind of action there are safe alternatives for each one of these functions but people will still end up using these functions because it's the first thing that came to mind people are still referring to the old k in our book when they're writing their C code and they're still writing C code for things where other tools are available that might do it a bit better so unless you're willing to take those kind of horrible consequences that are potentially life-altering for a great many people it might behoove you to double check some of these functions it can lead to bad things this next one I was kind of debating over whether to

include because go to is really contentious I go to is considered harmful as far back as 1968 there are a lot of people who still consider it harmful and there are a lot of very very vocal people who love it and think it is the best thing ever usually the argument that i get if i ever dare bring it up in public is but it helps me escape from internal nested functions really fast well yes it does but an axe will help you escape from situations pretty fast that doesn't mean it's always the next the best tool for the particular job so it's dangerous some people like danger some people like to live on the edge

some people like to code crypto and see just be if you're going to use go to just be really careful so onto the direct malware type of part of the talk there the morris worm has a really interesting situation it's the first really widespread internet work it was called the internet worm for awhile up until friends came along so what happened basically the the summary version is that in 1988 is filled by the name of robert morris jr i decided that his summer project needed a little letting out so in fairly short order about ten percent of the internet was impacted one way or another a lot of different hosts were specifically compromised and a lot

of house ended up with traffic issues and some hosts decided to disconnect from the internet entirely to avoid getting it and there were three main avenues of attack so they did what amounted to a remote execution exploit on sent mail because send mail always has a problem somewhere I'm sure finger D the old finger program it's not very much in use today for those of us who never really had encounters with it in the first place but it was basically a way no matta to a directory look up for people you would finger someone at a given host aha and it would return certain information that they decide to make public and thirdly good old brute

force everyone knows brute force no need to even talk about it the morris worm actually did a few clever things it renamed its process so that it would be less obvious to administrators it actually did something that you'll recognize from today's botnets it talked to what I'm added to a moderate server and despite the fact that it was spreading fairly quickly admins got real motivated and figured out not only through disassembly the code but through careful monitoring of the network traffic that produce ways to mitigate the spread either to prevent the host from being caught in the first place or ways to patch the binary such that he wouldn't be vulnerable it inspired a lot of imitators over the

years this particular methodology the worm methodology is really really efficient in some ways it spreads by itself and you can convince it to report back to you on a fairly regular basis what's also interesting is that a lot of the various ways in which worms have spread over the years I've got a few samples there have been due to things like buffer overruns and reuse of other methodologies so the takeaway for this is that the same methodologies have been used repeatedly over and over and over again because they work you're looking for a tool that will spread quickly across a wide network here's a tool that spreads quickly across a wide network it's a solution that is easily thought

of if you are in the same problem space what's particularly interesting is that it's not really limited to host either the internet census 2012 incident used gateways domestic consumer gateways that were not patched because honestly who in here has patched a router anytime in the past ever yeah nobody thinks about it's that box that sits in the corner that lets you have the Internet it's it's a blind spot and it happens to be a really effective vector for getting a foothold on a network to look at what's on the network so the knowledge that you get from this is useful for both attack and defense on the attack side if you are looking at someone's brand new implementation of

something you can probably count on them making at least some of the mistakes that people made the last time it was implemented which gives you an enormous leg up if you're trying to crack it because if you know what the mistake is going to be then you just need to look for it and if it's there hey half the jobs done for you no need to take further reconnaissance but you also know from past history where sis admin's tend to ignore things like gateways router firmwares I'm sure every one of us who is administered a network has forgotten some device on their network at some point I and also ways to optimize your own processes a lot of these worms have

gotten caught in the past because they spread quickly enough to cause enough concern so by clogging up everyone's network with your worm you end up getting people alarmed and motivated to fix it then there have been instances of worms that have gone and attempted to mitigate this to varying levels of success on the defensive side the applications are equally evident if you know how people have tried to attack you in the past then you have at least some model for how they're likely to continue trying to attack you in the future brute force will always be a thing as more and more people have access to more and more processors that are badly secured but

nets will continue to be a thing and botnets will continue to be used for brute force so you can always expect that for instance I things that were used in the past to hide or circumvent process renaming I'm sure every one of us has seen a suspicious service host exe at some point I may be used in the future and malware authors are also developers they to make mistakes earlier this year for instance there was rather interesting cryptolocker clone where the guy accidentally used a very stupid key where he figured that the key in bits since the the key and bytes or something like that was adequate it turned out to be easily crackable for

that particular implementation people who are in similar situations people implementing the same kinds of things will tend to think in the same general mindset that's where the real big takeaways here so if you know how it used to be done then you'll have an idea for how it will be done in the future so the witty aphorisms at the end of this presentation if you don't use history history will use you whether or not you're in Soviet Russia I what it comes down to is this is the kind of thing that makes history repeat if you are head carrying the same mindset is the people who did it before because you're working on the same problem but you're

not aware of how they did it before then you'll end up doing it again you don't really want that if you do know how they did it before then you have the advantage of being able to use their mistakes to learn from and any mistake that you don't have to learn from is a good one so that's the end of it and I've got loads of time by the look of it so if you have any questions feel free to ask them

and there's a real good point there is that all the things that used to happen in v4 you can probably look for in some extent to v6 not just the land attack but all the old tricks about how you would mangle a network to hide what you were doing or it's just that the problem space for v6 is a lot larger than the problem space for v4 so it's well worth keeping an eye on not only that but you know how the protocol was implemented by various vendors that kind of thing and you have to pass that down for it to be usable it has to be available before someone can know about it and a

differential and knowledge provides a blind spot to someone and you would probably do well to make sure that someone that is blind is not you yep not to get all confusion about it but respect your elders and yes there are some very very happy elders in this room

because it was on another line and it looked better not everything has to have deep meaning anyone else thank you for him from you know what you're saying and how you parse how much would you save this problem is essentially the shape of things conforming to the territory that it sits on versus the institutionalization of process is right we have this tendency to say we go to school and you know school sort of teaches us how to do certain things happy comes the process and so there or a common element process will also produce the commonalities results rate versus felt like I guess that nature versus nurture marketing right is to some extent there's that nature things

to the nature of the way that these things happen not so we received roll but just the fact that you're going to build an attribute that is part of it um we could probably go all night debating whether or not education causes thinking in the same way or whether people just inherently think in the same way I'm not really going into that at this point I just know that people will act the same way in the same situation and it's something that just happens you can do with it what you want and you can look for the reasons for it by all means but that's a little deeper than I intended good

if I depends on how catastrophic you want it certain things have been fairly catastrophic I did reference that lovely heartbleed thing which I think we'll all agree was fairly high in the catastrophe scale for impact as for actual information leakage I don't know if we'll ever know I I would rather not find out about a catastrophe that was brought on by a mistake that was made by someone who could have known better so that's kind of the reason for putting this out there pay attention to what happened in the past so that you won't be tomorrow's headline hey for more it's been that way absolutely there are choices that can be made in in choosing

to implement in languages that inherently try to mitigate that uh there will always be the old guard that loves their seat and will insist on it yes I'm picking on see a little bit I know but just the awareness that it is a possibility at the same time gives you a chance to go back and double-check just because you know that a buffer overrun can happen in these situations you can always go back hopefully sometime before it goes live and at least take a quick high-level look to make sure those situations have been cropped up

thank you very much [Applause]