Speaker 1: How'd you like to listen to dot net rocks with
Speaker 1: no ads? Easy? Become a patron for just five dollars
Speaker 1: a month. You get access to a private RSS feed
Speaker 1: where all the shows have no ads. Twenty dollars a month.
Speaker 1: We'll get you that and a special dot net Rocks
Speaker 1: patron mug. Sign up now at Patreon dot dot NetRocks
Speaker 1: dot com. Hey, it's dot net rocks. I'm Carl Franklin
Speaker 1: and Amirchard Campbell. We're here again for the nineteen hundredth
Speaker 1: and sixty third time.
Speaker 2: It's almost like an addiction or a pattern or something.
Speaker 2: I don't know.
Speaker 1: You think one of these days we'll figure it out.
Speaker 2: I don't know. If we're going out, we would have
Speaker 2: buy now right.
Speaker 1: Maybe we will talk about what happened in the year
Speaker 1: nineteen sixty three in just a minute. But first let's
Speaker 1: roll the music for better no framework.
Speaker 2: All right, dude, what do you got?
Speaker 3: Well?
Speaker 1: This came from Simon Cropp, who is a font of
Speaker 1: all good things, especially in the.
Speaker 2: Area of tests at Bexter.
Speaker 1: Yeah. He found this tool called xUnit dot Combinatorial Oh,
Speaker 1: which is a project from Andrew Arnott on the Visual
Speaker 1: Studio Platform team but instead of pointing you to the docks,
Speaker 1: which he said are okay, But this particular blog post
Speaker 1: by Andrew Locke really talks about it in detail. So basically,
Speaker 1: it's a the combinatorial is a weird name but fancy word,
Speaker 1: but it's a bunch of features that can make it
Speaker 1: easier to generate the test data you need with x
Speaker 1: unit nice right, So you can also auto generate parameters,
Speaker 1: generate all parameter combinations, or randomly generate values and it's
Speaker 1: all with you know, just a simple code you know
Speaker 1: theory tests right, and you can use more more attributes
Speaker 1: from the combination combinator combinatorial data nice x unit combinatorial. Anyway,
Speaker 1: it's really good and there's a lot of examples on
Speaker 1: this blog post, so you know, like I said, it's
Speaker 1: very easy. Just audit, auto generate permutations and parameters and
Speaker 1: custom defined values. Generating values for a single parameter, you
Speaker 1: can reduce the number of combinations. So there you go,
Speaker 1: know it, learn it, love it. Who's talking to us? Yeah?
Speaker 2: I like about that. Do you know what I think
Speaker 2: about that particular situation. It's like it's one guy to
Speaker 2: write it, but another person to explain it.
Speaker 1: Well, enough that you know, how do we want to
Speaker 1: use it? Yeah, yeah, yeah, it happens. The two talents
Speaker 1: don't necessarily go together.
Speaker 2: They don't necessarily go together. Absolutely true. So who's talking
Speaker 2: to us today? Richard Graud to comment heal for show
Speaker 2: eighteen seventy six, which is back in December twenty three,
Speaker 2: when we talk to our friend Laura Belle Maine, who
Speaker 2: is a regular conversationalist about security and runs a security
Speaker 2: related company. And this was about agile application security, the
Speaker 2: idea that you can incorporate security into your workflow, sprint
Speaker 2: to sprint, it's not crazy. Don't just try and retrofit it.
Speaker 2: At the end, and Rob had this great comedy, says
Speaker 2: great show. I especially appreciated discussion centered around making security
Speaker 2: easier for the average person and for that matter, the
Speaker 2: average developer to implement. So often it has taken that
Speaker 2: the cost of security is inconvenience, but I think that
Speaker 2: turning this idea on its head and is actually what
Speaker 2: needs to happen. In order to get people to do things.
Speaker 2: Security must make secure solutions to be the convenience solution. Convenances,
Speaker 2: the behavior modification tool need to dimploment better security. I mean,
Speaker 2: it's not that convenient about a lock, but you don't
Speaker 2: want to give them up. What you would like is
Speaker 2: a lock that you can unlock reliably when you want to.
Speaker 2: So there's some balance there, I agree, Rob, But it's
Speaker 2: good to have the tooling in place. But also, and
Speaker 2: I think this is one of the things we talked
Speaker 2: about a lot with Laura, was just getting it into
Speaker 2: the workflow so that security is never the after.
Speaker 3: Yeah.
Speaker 2: So Rob, thank you so much for your commented. A
Speaker 2: copy of music Coby is on its way to you,
Speaker 2: And if you'd like a copy of music go by,
Speaker 2: write a comment on the website at dot m Rocks
Speaker 2: dot com or on the facebooks publish every show there
Speaker 2: and if you comment there and I reading the show,
Speaker 2: we'll send you copy of music. O.
Speaker 1: All right, shall we talk about the year nineteen sixty three? Sure,
Speaker 1: it's a few. Yeah, things that happened in sixty three.
Speaker 1: Kennedy assassination, yikes, Vietnam War, it's getting worse. Beatlemania, yeah,
Speaker 1: the antidote to the Vietnam War. I guess I remember
Speaker 1: Paul McCartney says, yeah, you know, when they were telling
Speaker 1: us how to behave in the press, and somebody says,
Speaker 1: bring up the Vietnam War. We'd just say, oh, bad woo,
Speaker 1: bed war.
Speaker 2: That's it. Bet there's any good wars. Yeah, right, bad woo.
Speaker 1: Some civil rights things were going on. In sixty three
Speaker 1: March on Washington, Martin Luther King delivered his famous I
Speaker 1: Have a Dreams speech.
Speaker 2: Good speech and then bad war, good speech, good speech.
Speaker 1: On the bad side of civil rights. The Sixteenth Street
Speaker 1: Baptist Church bombing on September fifteenth, Birmingham, Alabama, killed four
Speaker 1: young girls absolutely intensified national outrage and support for the
Speaker 1: civil rights movement. Push button telephones, the touchdown, and some
Speaker 1: things happened in the nuclear front, right, the Nuclear Test
Speaker 1: Band Treaty on October twenty fourth, and the first commercial
Speaker 1: nuclear reactor began operation in the US. Anything you want
Speaker 1: to say about that.
Speaker 2: Richard, Oh, there were so many reactors at that time.
Speaker 2: They go back to the fifties, so it depends on
Speaker 2: which one we're talking about. But yeah, no, they were
Speaker 2: a lot of military related reactors, but then you had
Speaker 2: the Westinghouses and the General Electrics building the commercial editions
Speaker 2: just to make them reliable. That those were two Gen
Speaker 2: one reactors and they were tricky to operate, and they
Speaker 2: had very skilled people to operate them, and most part
Speaker 2: went well. It's when it grows out over the next
Speaker 2: decade that we started to have more problems with.
Speaker 1: And was it last week we talked about the integrated circuits.
Speaker 1: That was sixty two.
Speaker 2: Yeah, we talked a bit about integrated circuits there because
Speaker 2: they were struggling still struggling to make them. Then too,
Speaker 2: they were part of the equation on the computer front there.
Speaker 2: So there's a couple of interesting things. Last week we
Speaker 2: talked about the Link computer are really the first personal computer,
Speaker 2: but just because you could take one home even though
Speaker 2: it was six foot tall. But the following year at DAK,
Speaker 2: inspired by that machine, they made the PDP five, which
Speaker 2: arguably is the first mass produced mini computer. There were
Speaker 2: only over fifty links made, so these were twelve bit
Speaker 2: words and you could get between one and up to
Speaker 2: thirty two K words of core memory. This is before
Speaker 2: you know integrated circuit memory, so you literally have the
Speaker 2: little wound fires cores in wound in copper to store stuff.
Speaker 2: Came with an editor, assembler or four track compiler and
Speaker 2: a debugger for about twenty seven thousand US dollars and
Speaker 2: it was a less expensive computer than the PDP four,
Speaker 2: which was also a less expensive computer than the PDP one.
Speaker 2: So the original machine made by Deck was very expensive,
Speaker 2: and so they made a cheaper one, and this was
Speaker 2: even cheaper than that, and this machine, the more advanced
Speaker 2: version of the PDB five, will become the very famous
Speaker 2: PDP eight. One piece of software from nineteen sixty three
Speaker 2: is sketch Pad. So this is Ivan Sutherland who was
Speaker 2: writing his PhD thesis, and he was really the ancestor
Speaker 2: of CAD software of computer aided design and arguably the
Speaker 2: very first guy. It ran on the TX two, which
Speaker 2: is a completely unique, one of a kind machine from
Speaker 2: nineteen fifty eight built in it only lasted about twenty
Speaker 2: years or fifteen years, which had sixty four k of
Speaker 2: thirty six bit words and you were able to draw
Speaker 2: directly on the screen with a light pen. Yeah there
Speaker 2: was no mouse yet Nope, that was Xerox part The
Speaker 2: mouse is still coming. Yeah yeah, but you know, these
Speaker 2: are all the beginning efforts with these early machines, but
Speaker 2: also totally bespoke. This was software that ran on exactly
Speaker 2: one computer in the world at the time.
Speaker 1: Right, Wow, Yeah. Well, I can't wait to go through
Speaker 1: the years here leading up to the computer revolution, because
Speaker 1: this is this is where it gets exciting, you know.
Speaker 2: Yeah, And it's we're pulling these bits and pieces together
Speaker 2: and just seeing like that PDP five it's all transistors.
Speaker 2: There's not a single I see in it. It's before that. Right, Wow,
Speaker 2: good stuff.
Speaker 1: All right, stay tuned for more history lessons from Richard
Speaker 1: Campbell and myself. But I suppose it's time to talk
Speaker 1: to our guest, Michael Howard. So. Michael is a senior
Speaker 1: director in the Microsoft Red Team. If you don't know
Speaker 1: what a Red Team is, they're the ones that go
Speaker 1: and hack. You'll tell you all about it, and the
Speaker 1: hackers focused on improving security design and development across Microsoft.
Speaker 1: Based on RT findings. He has been at Microsoft for
Speaker 1: thirty three years, almost always in security except for at
Speaker 1: the start. We're at Microsoft in New Zealand. He supported
Speaker 1: Windows three point x, the Windows SDK, and the Microsoft
Speaker 1: C compiler. Currently lives in Austin, Texas. Is an avid
Speaker 1: scuba diver and life is now much better because his
Speaker 1: wife dives now too fantastic, so she didn't scuba dive
Speaker 1: FORR The early years of your relationship, is that it?
Speaker 3: Well, I've been diving since ELA's seven. Oh well, okay,
Speaker 3: so no, she was absolutely terrified of diving. She felt
Speaker 3: very claustrophobic and also like, I live in Austin, so
Speaker 3: the closest lake to us for die thing is Lake Travis.
Speaker 3: And honestly, the only nice thing about Lake Travis is
Speaker 3: it makes every single diving destination looks so much better.
Speaker 3: It's just a light.
Speaker 2: Not that much diving in Texas really, No.
Speaker 3: Actually, there actually is. Actually there's a yeah Travis. Some
Speaker 3: of the lakes are really commonly dived. And there's also
Speaker 3: abandoned nuclear rocket silo in West Texas called Valhalla, which
Speaker 3: I plan on diving this year as well. Its about
Speaker 3: one hundred and twenty feet down. How many rads hopefully zero?
Speaker 4: There's not a game of fallout, you know, you should
Speaker 4: check that out first, take it out.
Speaker 1: That's right.
Speaker 3: But yeah, it's funny. When my wife got her her certification,
Speaker 3: she refused to do it in Lake Travis. So she
Speaker 3: flew with a girlfriend to the Virgin Islands. Oh nice,
Speaker 3: did a certification there instead?
Speaker 2: You find some warm water to swim around in, right, Yeah.
Speaker 3: Absolutely, she's a blue water princess.
Speaker 2: Yeah.
Speaker 1: There so a couple of things RTI Red Team. So
Speaker 1: tell me about the Microsoft Red Team. I know what
Speaker 1: red teams are because I do a podcast with two
Speaker 1: guys on our Red Team about security security this week.
Speaker 1: But tell us what the Microsoft Red Team does. Yeah.
Speaker 3: We you know, we're basically treated as a real threat
Speaker 3: actor in every possible way you could consider that. Nothing's
Speaker 3: else on the table except JA. That's good. That's actually
Speaker 3: a very good point. There's a story. There's a story
Speaker 3: I can probably tell you there about I don't want
Speaker 3: to get it, only very careful what I say here,
Speaker 3: But I remember showing something on a on a on
Speaker 3: a session and someone said, oh you could you know
Speaker 3: you can get fired because of that. And then this
Speaker 3: friend of mine who's also on the Red Team, colleague
Speaker 3: of mine, chimed up and said, well, actually know he's
Speaker 3: on the Red team. He can get out of get
Speaker 3: a raise. Yeah, the Red Team is really kind of interesting, right.
Speaker 3: So our job is ultimately we start off with an objective,
Speaker 3: whatever that objective is, and we go for it. And
Speaker 3: that's a I mean whatever it takes to get to
Speaker 3: that objective. And a big part that I'm involved with
Speaker 3: is the readouts as I look at what actually happened,
Speaker 3: what was actually done, all the steps along the way,
Speaker 3: and so okay, so what was the for example, the beachhead,
Speaker 3: you know, what got the Red team into the environment
Speaker 3: and where did they go from there? And how did
Speaker 3: they get there? Was it a security vulnerability? Was it,
Speaker 3: you know, like from a code level perspective, or was
Speaker 3: it a week commission on something? Was it insecure this
Speaker 3: that and the other? Was it a combination of things?
Speaker 3: The whole point is for me to learn those things
Speaker 3: and then turn that into appropriate material for inside of Microsoft,
Speaker 3: and eventually we'll make a lot of that available outside
Speaker 3: Microsoft as well. But we're starting internally obviously.
Speaker 1: Are you primarily focused on Azure because I know that
Speaker 1: that's kind of where you where you live, But what
Speaker 1: about internal offices and things like that?
Speaker 3: Yes?
Speaker 1: Both, Yes, I'll just leave it at that.
Speaker 3: Nothing's off the table, nothing's on the table at all.
Speaker 3: What's that's kind of interesting is the Red Team. Now.
Speaker 3: The Microsoft Red Team is really a sort of conglomeration
Speaker 3: of multiple Red teams that existed across Microsoft, now reporting
Speaker 3: under one essentially management chain, essentially on the Scott gu three.
Speaker 3: Ultimately if those cuts you know, primarily Asia, I mean
Speaker 3: he obviously Windows rolls up there as well.
Speaker 1: Right, Penetration tests are kind of expensive. Do you do
Speaker 1: them around the clock?
Speaker 3: We do so. So pen testing is not red teaming, right,
Speaker 3: I mean pent testing is you almost say, hey, I
Speaker 3: want you to go and you know, kick the you
Speaker 3: know what out of this product, right. Red Team starts
Speaker 3: from an objective and objective yeah, oh yeah, we don't
Speaker 3: tell anybody. We don't tell anybody. You know, we want
Speaker 3: to create tokens or we want to air quotes, steal
Speaker 3: money from something whatever. Right, that's the objective. And whoever
Speaker 3: we trample along the way get strampled along the way.
Speaker 3: Whereas pen testing is quite different. It's like, you know, hey,
Speaker 3: find bugs and share point online, find bugs in I
Speaker 3: S or find bugs and.
Speaker 1: Dot it find vulnerabildings.
Speaker 3: Yeah, quite different.
Speaker 1: So the difference is a pentest they ask you to
Speaker 1: do X. In Red Team, they don't even know what
Speaker 1: you're up to. You're just hack hack hack hack.
Speaker 3: Yeah, and you know we'll leaven, not just like attackers. Right,
Speaker 3: So if we are detected, we will you know, change
Speaker 3: course and we will try to will try to obfuscate,
Speaker 3: if me deleting logs or whatever, We'll do it whatever
Speaker 3: needs to be done right, and you know, it's a
Speaker 3: beautiful thing.
Speaker 2: Really.
Speaker 1: I asked Twayne Laflatte, who's the head of the Red
Speaker 1: Team at Pulsar Security, where then I do the podcast with?
Speaker 1: I asked every once in a while, like, do you
Speaker 1: ever get asked, why aren't you a criminal? You know,
Speaker 1: you know all this stuff you can get, you know
Speaker 1: how to get it. He's always giving away criminal career advice,
Speaker 1: you know, and he says, because I'm a good human. Duh.
Speaker 3: Yes, it's interesting. I mean, you know a lot of
Speaker 3: people that I work with, I mean it's the same thing.
Speaker 3: I mean, they're incredibly nice people, like truly nice people,
Speaker 3: but they just have this way of thinking about things
Speaker 3: that a lot of people don't. There's an analogy I
Speaker 3: like to give. You. Even heard the story right where
Speaker 3: people said, you know, we'll only make things more secure
Speaker 3: when we get more people thinking like attackers. Well, my
Speaker 3: argument is you can't do that unless you are one.
Speaker 3: And the example I gave because I mentioned this to
Speaker 3: my wife, this is years ago. We were some word
Speaker 3: I don't know where it was, I mean camera to
Speaker 3: this ATM machine and it said hey on the screen,
Speaker 3: it said, hey, hey, if this temper evident tape is
Speaker 3: tampered with, don't use the device. And I said to
Speaker 3: my wife, said, do you think that's a good thing?
Speaker 3: So well, I don't know what it's even protecting against.
Speaker 3: And I said, well, so you know, quick, give her
Speaker 3: a quick skimming one oh one, and it's a magnificent difference.
Speaker 3: And that's stupid. She said, what do you mean, Well,
Speaker 3: don't you think the criminals can make their own temper
Speaker 3: evident tape number one number two? It's actually worse than that.
Speaker 3: I can knock out every single ATM in town. So
Speaker 3: what do you mean, I still just take my pocket
Speaker 3: knifeound just every single piece of.
Speaker 2: Type, start cutting the tape.
Speaker 3: Yeah, so I'm using the defense against yourself. It's like,
Speaker 3: how did you even think of that?
Speaker 2: Because ease e.
Speaker 1: But you have to have an evil mind.
Speaker 3: You have to think, oh I would I would consider
Speaker 3: myself I don't know, probably chaotic good, Okay, Yeah.
Speaker 2: It's a contrarian mind, just to think of the opposites
Speaker 2: of things too. I did a show on run As
Speaker 2: not that long ago, maybe I'll just go back in
Speaker 2: May with your ideogenous who did a book on how
Speaker 2: to get a career in cybersecurity, excellent book and the
Speaker 2: thing and he talked about the fact that, you know,
Speaker 2: most things insecurity are teachable. The thing that isn't teachable
Speaker 2: is this sort of insatiable curiosity to just keep wanting
Speaker 2: to pay poke away things, try a different way, keep
Speaker 2: on pressing. If you don't have that, this isn't the
Speaker 2: job for you.
Speaker 3: Whenever I'm interviewing people, one of the things I do
Speaker 3: look for is that fire in the belly. Right, It's
Speaker 3: that passion to learn, that passion to dig deeper. I
Speaker 3: don't know you. I'm you guys probably the same as me.
Speaker 3: Right when I was a little kid, I was the
Speaker 3: guy in the corner of reading encyclopedias, you know I was.
Speaker 1: I was taking apart my tape recorders and trying to
Speaker 1: put them back together unsuccessfully.
Speaker 3: Right, But you learned a lot right getting.
Speaker 1: Whacked by my mother. M Yeah, I learned that I
Speaker 1: probably shouldn't take my taper. Yeah, can I have another one?
Speaker 2: I might have made my tape recorder explode. Actually that's
Speaker 2: probably worse.
Speaker 4: Oh, the stuff I the thermite substitute for batteries.
Speaker 3: So I got to actually got an explosion story there.
Speaker 3: When I was a kid, I went to that, this
Speaker 3: is New Zealand. I went to the local chemist and
Speaker 3: of course I went, hey, can I get some you know,
Speaker 3: carbon potassium? I said, saltpeter and sulfur. The guy's like, come.
Speaker 1: On making gunpowder?
Speaker 3: It is like but you know what he said though,
Speaker 3: He said, I've got two options. I can send you
Speaker 3: on your on your way, but you're gonna.
Speaker 1: Do it anyway.
Speaker 3: Or I can show you how to do it safely.
Speaker 3: And he showed me how to do it safely.
Speaker 2: Nice.
Speaker 1: Wow, that's good. Yeah, don't ask about explosion stories your fingers.
Speaker 2: You know. I told the thermiting the old server so
Speaker 2: that we ended up with funky jewelry and a memory
Speaker 2: story the other day. Yes, and it was a bad
Speaker 2: child that it was a practical end for a server
Speaker 2: that everyone hated. Well, I was talking about your teenager
Speaker 2: or the other the many other expos in this day
Speaker 2: and age. I just be labeled as a terrorist, probably
Speaker 2: Canadian polite tarress. What I was was under supervised, clearly, all.
Speaker 1: Right, So what did you come here and talk about?
Speaker 1: Because we could. We could talk about this stuff all day.
Speaker 3: Mm hmm, yeah, I mean, I mean it's in my background.
Speaker 3: That's you know, sort of mentioned in the brief bio
Speaker 3: at the beginning. IS is essentially security however, is an
Speaker 3: interesting topic, right because I originally started when I moved
Speaker 3: to Redmond from from New Zealand. I got a job
Speaker 3: in IIS and the web server intet Information Internet's information
Speaker 3: server as it was then now at Services, but same difference,
Speaker 3: and I eventually took on the role as the security
Speaker 3: PM in IS. Three. I know, you guys are going
Speaker 3: to start giggling to yourself, and I sort of mentioned
Speaker 3: this stuff.
Speaker 2: Now that made a lot of money off the challenge
Speaker 2: in there.
Speaker 1: There's a challenge to keep that secure.
Speaker 3: There's so many stories. When I retire, I think I'll
Speaker 3: write a book on it.
Speaker 2: But three four you've already written a bunch of books there,
Speaker 2: I have.
Speaker 3: I have, that's right, yeah. But I three four, five
Speaker 3: were interesting, right because they were full of security features,
Speaker 3: especially five five was full of security features. We had
Speaker 3: Cerbros integration, we had certificate services. I think it may
Speaker 3: have been actually the first web server that did serve
Speaker 3: aside certificate revocation of client certificates. I think it was
Speaker 3: the first one. We're really hardcore actually about that if
Speaker 3: we couldn't reach the crill distribution point. But that's all
Speaker 3: whole nother discussion. But you know, did they have security features? Yeah,
Speaker 3: had a ton of security features, But were they secure features, right,
Speaker 3: ann answers potentially No.
Speaker 1: I remember path traversal was a problem.
Speaker 3: Yeah, a canonicalization, right, Colonicalization was was a huge problem
Speaker 3: and we even saw it in in dartn Air, right,
Speaker 3: there was an anti cross site scripting library, right, and
Speaker 3: up being so many ways around it that we just thought,
Speaker 3: we just can't maintain this, right, And so yeah, I could.
Speaker 3: I could talk forever about colonicalization problems. I'm a big, big,
Speaker 3: big fan of canonicalization. In fact, canonicalization or two tokens
Speaker 3: kind of worry me. But that's a whole nother discussion
Speaker 3: where you basically doing string comparisons to make access decisions.
Speaker 3: Is there a more than one way of representing something
Speaker 3: that's valid that you're not looking for? But so, yeah,
Speaker 3: I mean so I S three, four, five, especially five.
Speaker 3: Lots of security features, but not particularly secure features, said Carl.
Speaker 3: Canonicalization pas traversal were big ones, and so I ended
Speaker 3: up learning a lot from that, and at that point,
Speaker 3: you know, my my career kind of pivoted from security
Speaker 3: features to securing features, and that's where I really got
Speaker 3: stuck into lower level memory corruption issues in C C
Speaker 3: plus plus again, canonicalization problems across the scripting. Sequel injection,
Speaker 3: I mean, sequel injection basically kind of happened around I
Speaker 3: S three fourish guy Rainforest Puppy r f P M
Speaker 3: getting an email from him saying, hey, look what I discovered,
Speaker 3: and that became sequel injection. In fact, I've spoken a
Speaker 3: couple of times to RFP since since.
Speaker 1: They're still still like number one on the list, isn't
Speaker 1: it sequel injection?
Speaker 2: It's down to three facts in the top ten?
Speaker 1: Is still in the top ten.
Speaker 2: It sat there for so long.
Speaker 3: We know how to solve we know how to solve this.
Speaker 2: Yeah, it's a totally solved problem, and it just doesn't
Speaker 2: get away.
Speaker 3: Yeah. And so the question is why, right, why people
Speaker 3: keep making those mistakes, And honestly, it's because they just
Speaker 3: don't know. I mean, this is an interesting thing, right.
Speaker 3: One of the definitions of a secure system is a
Speaker 3: system that does what it's supposed to do with nothing else. Right. Well,
Speaker 3: if you build some code that does sequally stuff right
Speaker 3: and you do stren cocaatenation for your sequel statements, is
Speaker 3: it going to solve the business problems? Yes, it is, right,
Speaker 3: it's just going to work. But it's the injection part
Speaker 3: that is the or, you know, the something else. You know,
Speaker 3: A secure system is the one that does what it's
Speaker 3: supposed to do with nothing else. But is that something
Speaker 3: else that makes it insecure? It solves all your business problems,
Speaker 3: but it's insecure at the same time, and people don't
Speaker 3: realize it until they start, you know, running tools over
Speaker 3: it or someone you know, compromises the environment.
Speaker 1: Richard and I used to do a talk together at
Speaker 1: various conferences about, you know, walking through sort of the
Speaker 1: history of inner services, and he made a good point
Speaker 1: about saying that iis is like whatuld you call it,
Speaker 1: like a Swiss army knife with all the blades out.
Speaker 1: The Swiss army knife with every blade out was yeah,
Speaker 1: whereas you know.
Speaker 2: Well node was the ultimate opposite. Yeah, no, there are
Speaker 2: no blades. You have to go get each blade right.
Speaker 1: That's right, everything's off by default.
Speaker 3: Right, yeah, but same with I six though, yeah, by six,
Speaker 3: So that's where we made a huge change, right, right,
Speaker 3: So his code name was Kevlar, and there was a
Speaker 3: reason for it being kevl Right. We rewrote huge swaths
Speaker 3: of code, especially string handling and also kind oftilization was
Speaker 3: all centralized. We also changed the design, and one of
Speaker 3: the biggest designs was that IS five, Like you say,
Speaker 3: it was a Swiss army knife with all the blades
Speaker 3: and screwdrivers and what have you sticking out. I six
Speaker 3: was the opposite, right, basically ran essentially nothing and you
Speaker 3: had to opt in for most of the services and
Speaker 3: I seven, which I could even further by opting in
Speaker 3: for specific h GDP verbs, especially the web dev stuff.
Speaker 1: Right, yeah, it's just cool out I remember it.
Speaker 2: Well.
Speaker 1: We learn, you know, from each other and evolve together.
Speaker 3: It was a huge baptism.
Speaker 2: Well and in the early days of I S it
Speaker 2: was about making it easier for developers. You didn't really
Speaker 2: know that much about web development to make things work.
Speaker 3: And and that was Jay Allen's impact, right, I mean
Speaker 3: Jay ran the project and he was a big you know,
Speaker 3: let's get everything onto the web, especially I S. I know, look,
Speaker 3: I understand that. I totally understand that. But at the
Speaker 3: same time, you know, if you start turning stuff off
Speaker 3: by default, it is going to provide some kind of impedance.
Speaker 1: Yeah, you're also not just interested in server stuff, but
Speaker 1: in code security in general, right, like correct avoiding vulnerabilities
Speaker 1: like buffer overruns and things which admittedly aren't so much
Speaker 1: of a problem in a managed language like C sharp,
Speaker 1: but certainly in C C plus plus those are still issues.
Speaker 3: Huge issue. In fact, I'm working on another book now
Speaker 3: with some friends, with some colleagues, and one of the
Speaker 3: chapters is going to be exactly that, like reconsidering the
Speaker 3: role of C and C plus plus.
Speaker 1: Now.
Speaker 2: The only reason, well, this is this what Rassinovich was
Speaker 2: talking about, Like you have to justify writing exactly.
Speaker 3: So racinovert Well it's not just Rescinovi, it's also Dave
Speaker 3: Western writing windows. So the three of us was talking
Speaker 3: at length about about this. And look, I have worked
Speaker 3: in C since I was sixteen. Wow, let's just say
Speaker 3: that was a few years ago. You know, as I mentioned,
Speaker 3: you know in the Buyer at the beginning, right, one
Speaker 3: of my well, my first job at Microsoft was in
Speaker 3: part supporting the Microsoft C compiler it was C version
Speaker 3: four back in the day. But what's interesting is I've
Speaker 3: you know, I've had a huge I have a huge
Speaker 3: love affair with C and C plus plus. I love
Speaker 3: both languages, absolutely, adore both languages. See is probably the
Speaker 3: language that I can write without even thinking. It just
Speaker 3: spews out onto the keyboard. You know. The problem though,
Speaker 3: is that it's too easy to have undefined behavior in
Speaker 3: both languages. And remember that before, you know, definition of
Speaker 3: a secure system is a system that does what it's
Speaker 3: supposed to do with nothing else. A more academic representation
Speaker 3: of that is a system that exhibits no undefined behavior. Well,
Speaker 3: ce on C plus plus has got plenty of undefined
Speaker 3: behavior when it comes to the corruption memory safety. So
Speaker 3: cal you said buffer overruns, but that's only just one.
Speaker 1: That's just one.
Speaker 3: Yeah, that's one, right. The whole gamut is essentially memory safety.
Speaker 3: I know that there's a lot of work going on
Speaker 3: in the C plus plus committees right now around this
Speaker 3: thing is called profiles, to basically say, here is the
Speaker 3: subset of the language that we will we will enforce.
Speaker 3: For example, let's say you have a C array, maybe
Speaker 3: a vector as well. But let's say in an array
Speaker 3: by C array. I don't mean a sorry, a C
Speaker 3: plus plus array. I don't mean a C array. But
Speaker 3: if you've got a C plus plus class that's an
Speaker 3: array and you use just the index operator, you know,
Speaker 3: square brackets eye, that is not bounce checked. But if
Speaker 3: you do dot at I, then that is bounce checked.
Speaker 3: So you may have in the profile. We will only
Speaker 3: allow iterators to use dot at and not just the
Speaker 3: array and the normal array index that we used to
Speaker 3: so that there's that that works. But the problem is
Speaker 3: there is so much in C plus plus code out there.
Speaker 3: Are you really going to re engineer it and refactor it?
Speaker 3: I don't I don't know.
Speaker 2: No, you're not well. If you are, you're not going
Speaker 2: to stay there, You're going to go elsewhere.
Speaker 3: So the word, you know, so the word from on
Speaker 3: high in as you're at least, and this is from Ricinovich,
Speaker 3: is new code must be written using memory save language.
Speaker 3: That could be RUSS, could be see sharp, could be go.
Speaker 3: You know, we saw typescript typescript compiler written and go.
Speaker 2: I mean, there is managed C plus plus, but does
Speaker 2: anybody use it.
Speaker 3: I don't know of anybody using.
Speaker 2: It, or is it actually safe.
Speaker 3: Honestly, I haven't really used it. I found the syntax
Speaker 3: very funky.
Speaker 2: Yeah, and yeah, you know, this is what happened to
Speaker 2: me with VB dot net. I was a good VB programmer.
Speaker 2: I was very happy dot net comes along. VB dot
Speaker 2: net makes me mental because I have VB reflexes, and
Speaker 2: so I switched to C sharp because at least I
Speaker 2: know for sure it's not VB.
Speaker 1: Yeah point.
Speaker 3: Yeah.
Speaker 1: So it took me a while, but I got over
Speaker 1: to Yeah.
Speaker 3: So, you know, Perisenovitch new stuff must be written in
Speaker 3: memory safe language.
Speaker 2: And I know Dave West, I think he said it.
Speaker 2: You have to justify not writing in a memory safe language.
Speaker 3: Yeah, correct, Yeah, that's that's that's the more accurate statement.
Speaker 2: Yeah. Yeah, well he's pretty careful to not talking in absolutes.
Speaker 3: Mister, what was the confidence for computing? But other than that, okay, no,
Speaker 3: it's look I again. For me, it's really difficult. I
Speaker 3: love seeing C plus plus, I love both languages. Look,
Speaker 3: and I realize that C plus plus can get pretty upteous. Sometimes.
Speaker 3: Everyone likes showing the you know, the crazy you know
Speaker 3: C plus plus code, you know, try and work out
Speaker 3: what the heck. There's things doing. I get that, but
Speaker 3: I love cea Sharp for you know, my my general
Speaker 3: rule of thumb is this, and this is my general
Speaker 3: rule of thumb is if you're writing something new sea sharp, However,
Speaker 3: if you need something where you can't incur the cost
Speaker 3: of the garbage collection or the the unpredictability of the
Speaker 3: garbage collector especially on a server, than Rust. I'm a
Speaker 3: huge fan of Russ. I love Russ. I love Rust
Speaker 3: to death.
Speaker 2: And it does seem to strike that balance between I'm
Speaker 2: quite low level and deterministic in what I'm going to do,
Speaker 2: but I'm also memory safe.
Speaker 3: Correct. The downside of Russ is learning it. It is
Speaker 3: a very difficult language to learn. I am some years ago,
Speaker 3: about two years ago now, I gave a presentation inside
Speaker 3: of Microsoft called a lap around Rust, and it's basically
Speaker 3: a one hour session, just a quick hey, you never learned,
Speaker 3: never know anything, know nothing about Russ. Watch this talking
Speaker 3: about visual studio code blah blah blah blah. One half
Speaker 3: of the presentation is just on the borrow checker in Rust,
Speaker 3: because that's what causes most of the pain. And the
Speaker 3: first slide of that is, you know, if you're writing
Speaker 3: Russ for the first two to four weeks, you're going
Speaker 3: to be you know, punching the screen because of the
Speaker 3: borrow checker, because of the way it works, and it
Speaker 3: drives people bonkers. But once you get over that learning hump,
Speaker 3: it's actually it's a beautiful language to learn, and you know,
Speaker 3: nice ecosystem and very good standard library.
Speaker 1: Yeah, well, this seems like a good place to take
Speaker 1: a break. So we'll be right back after these very
Speaker 1: important messages. And as a reminder, if you don't want
Speaker 1: to hear these ads, you can pay five bucks a
Speaker 1: month to become a patron Patreon dot dot and Aarox
Speaker 1: dot com. You get an ad free feed. We'll be
Speaker 1: right back. Did you know there's a dot net on
Speaker 1: aws community. Follow the social media blogs, YouTube influencers and
Speaker 1: open source projects and add your own voice. Get plugged
Speaker 1: into the dot net on aws community at aws dot
Speaker 1: Amazon dot com, slash dot net. And we're back. It's
Speaker 1: dot in Aros. I'm Carl, that's my friend Richard Campbell, hey,
Speaker 1: and our friend Michael Howard, and we're talking code security
Speaker 1: and one thing that has become very evident to me,
Speaker 1: doing you know, a weekly podcast on vulnerabilities and hacks
Speaker 1: that have happened the week before. Is that most of
Speaker 1: these aren't technical vulnerabilities. Most of them. Most of the
Speaker 1: attacks anyway, are from social engineering, and that is just
Speaker 1: a whole another ball away. But it's the first line
Speaker 1: of defense and security is the user. Don't click the
Speaker 1: freaking link in the email or the text message, you know.
Speaker 3: Yeah, I mean I usually get emails from my father
Speaker 3: in law, yeah, saying you know, is this legit? My
Speaker 3: answer was always the same. If you're asking me the question,
Speaker 3: then the answer.
Speaker 2: Is no, you already know the answer.
Speaker 3: That's right. I get ones that everyone's in a while
Speaker 3: from my wife as well, but I mean, yeah, the
Speaker 3: work that's going on, certainly Microsoft, I'm sure other companies
Speaker 3: as well, you know, in the various UIs to mitigate things.
Speaker 3: One of my favorites actually was was added to Office
Speaker 3: years ago, which was to run the you know, the
Speaker 3: process at low integrity level by default, which is really nice. Well,
Speaker 3: I don't know how technical you guys want to get,
Speaker 3: but from my perspective, it was a magnificent defense. It
Speaker 3: assumes that the document, whether it's a PowerPoint, Excel or
Speaker 3: doc file, whatever, it assumes it's malicious and runs it
Speaker 3: in this this essentially a a low integrity sandbox. So
Speaker 3: it does blow up the potential damage. I'm not saying
Speaker 3: it's completely mitigated, but it's certainly less. And you got
Speaker 3: to do things like that, right, You've got to assume
Speaker 3: that the users going to click on things and open
Speaker 3: things and all that sort of stuff, And so how
Speaker 3: do you mitigate the damage.
Speaker 2: Yeah, yeah, we're in the admin's side. Our line is
Speaker 2: always be more careful next time. Is not a strategy, right, yeah, right,
Speaker 2: it's not that the guy clicked on it, it's that
Speaker 2: anything happened when he did.
Speaker 1: Yeah, and just that advice be careful, Well, what does
Speaker 1: that mean? Does that mean don't ever click on anything?
Speaker 1: Does that mean never go to websites? Does that mean
Speaker 1: cut off your hands and live in a box? Thanks
Speaker 1: Roy Blake for that one. You know, it's hard to tell.
Speaker 1: Just be careful.
Speaker 3: That's terrible advice, to be honest, it's terrible. Yeah, I
Speaker 3: mean humans is going to do what humans going to do, right,
Speaker 3: I mean they can click on that. I mean one
Speaker 3: of one of my favorite and I gotta be careful,
Speaker 3: I say here, but I was working doing some work
Speaker 3: with a defense contractor and they got hit with a
Speaker 3: pretty serious attack. And the attack actually came through a
Speaker 3: very senior person within the organization, and it's basically a
Speaker 3: zero day in Acrobat. But the reason why she opened
Speaker 3: it is because the message was about knitting interesting and
Speaker 3: she was an.
Speaker 2: Avid knitter, so very good targeting.
Speaker 3: And so she just opened the dark the PDF and
Speaker 3: that was it. That was the beach air. Yeah, there's
Speaker 3: always going to be something that you're gonna click on.
Speaker 3: We can pontificate and say how awesome we are, but
Speaker 3: I can guarantee all three of us there's something we
Speaker 3: will click on.
Speaker 2: Yep, you're gonna make them and you are just gonna
Speaker 2: have a moment of weakness. You're gonna have a mistake
Speaker 2: at some point.
Speaker 3: And that's why I'm a huge fan of these sort
Speaker 3: of mitigations around assuming that whatever you click on is
Speaker 3: going to blow up, and you know, what can you
Speaker 3: do to mitigate that? And we spend a lot of
Speaker 3: time in Windows especially on that.
Speaker 1: There's some ideas that we've thrown around. One of them
Speaker 1: is to have a separate VM where all your email
Speaker 1: comes through and all your Internet goes in and out
Speaker 1: of the problem then is Okay, if you do have
Speaker 1: to communicate with some data and some files and stuff,
Speaker 1: now you've got to get them around safely without infecting
Speaker 1: each system. But that's not an insurmountable problem.
Speaker 3: You know, it's funny you bring that up.
Speaker 1: You can do a little file Zilla, you know, a
Speaker 1: little FTP, you could do that.
Speaker 3: It's funny you bring that up. That was actually thrown around.
Speaker 3: I want to say fifteen twenty years ago, I was
Speaker 3: a meeting with Gates where Butler lamps and actually threw
Speaker 3: out this idea of I think you got a red green,
Speaker 3: a red VM and a green VM. Yeah, that's exactly
Speaker 3: what it was. Yeah. Wow, But back then, I mean
Speaker 3: vms were super duper heavy as well, and it's releatant.
Speaker 3: Then there were performance impacts. I think we're in a
Speaker 3: much better position today. But you know, when you know Microsoft,
Speaker 3: if you're doing administration and VAS, you're at the back end,
Speaker 3: you can't do it from your machine. You're not allowed, no, right,
Speaker 3: you run it from my secure access workstation. That is
Speaker 3: very limited in what it can do on purpose.
Speaker 1: Yeah, do you remember, Richard, we had we interviewed a
Speaker 1: guy on dot net rocks. It was a little at NBC,
Speaker 1: I think, and he had discovered how to hack dot
Speaker 1: net apps and this was dot net framework, Windows and stuff.
Speaker 1: He could get into memory and change things around, and
Speaker 1: he had developed a tool to do this, and he
Speaker 1: gave the tool away for free, and then he sold
Speaker 1: an anti tool to procure.
Speaker 2: John McCoy is who you're talking about.
Speaker 1: Yeah, to protect yourself from it. I just remember Richard
Speaker 1: and I were horrified. We didn't know anything about this
Speaker 1: before we started talking, and then it was like that's evil,
Speaker 1: you know.
Speaker 3: But yeah, I remember this is some time ago and
Speaker 3: there was a company who, well, that should't work, No,
Speaker 3: I don't, but they came up with the wh They
Speaker 3: came up with a white paper that showed how US
Speaker 3: snaffle private keys out of memory and iis TLS TLS certificates.
Speaker 3: But if you bought their hardware, then the key stayed
Speaker 3: in the hardware. This is before HSM's working hardware security
Speaker 3: models were a thing, and they have one of the
Speaker 3: first ones.
Speaker 1: But meanwhile, we're going to teach you how to Yeah,
Speaker 1: we're going.
Speaker 3: To give you if you buy a device for two
Speaker 3: thousand dollars. And then it is kind of funny that
Speaker 3: the tool they had was really really simple. It basically
Speaker 3: looked for entropy and memory. That's all it really did, right,
Speaker 3: because the private key is random, whereas most memory kind
Speaker 3: of isn't really, and so they would just look for entropy.
Speaker 3: And then what they would do is they were trying
Speaker 3: to match up the public key and the certificate with
Speaker 3: the private key by decrypting and encrypting. And so they
Speaker 3: got the correct answer. But they could do it within
Speaker 3: but they can do it in seconds. So now they
Speaker 3: know the private key. But hey, if you buy our
Speaker 3: hardware device, then the private key stays in the hardware.
Speaker 1: And they probably thought that.
Speaker 3: Don't get me wrong, I'm a huge fan of HSMs,
Speaker 3: I really am.
Speaker 1: Probably thought that was a great idea.
Speaker 2: Yeah, but there's also a way to be as somebody
Speaker 2: who understands security and tries to fix things without you know,
Speaker 2: being part of the problem.
Speaker 1: Right.
Speaker 3: Yeah, Well, let's back up that a little bit. I mean,
Speaker 3: did this company do a service I think explaining to
Speaker 3: people how easy if you've got rogue software on the box,
Speaker 3: you could snaffle the private key. I think it's a
Speaker 3: good thing to know. You know, a lot of people
Speaker 3: may not realize right that you could easily get the
Speaker 3: private key, and that's why you know things like as
Speaker 3: a key vault and managed HSM. You know, the private
Speaker 3: keys stay in the hardware. They never leave unless you
Speaker 3: want to export them in a shrouded manner. Rather, we
Speaker 3: give you know, decrypt and we give signing operations rest
Speaker 3: endpoints instead, so the private key stays in the hardware.
Speaker 1: Yeah, let's talk about GitHub, get lab all them. You
Speaker 1: know that people are raising concerns like existential threats, you know,
Speaker 1: to our very existence because we're dependent on all these
Speaker 1: projects and nobody has software bill of materials unless they're
Speaker 1: really hip, so they don't know where their dependencies are.
Speaker 2: They go.
Speaker 1: You got depend about which tells you, hey, you've got
Speaker 1: some dependencies that aren't safe. But it's kind of a
Speaker 1: full time job. It is, playing whack them all with
Speaker 1: that stuff. It is.
Speaker 3: Yeah. I mean I get notifications, but at least one
Speaker 3: every other day, not necessarily because of anything I have,
Speaker 3: but because of I'm sort of a co owner of
Speaker 3: other people's projects, especially one that's actually on purpose vulnerable.
Speaker 3: Actually they get up guys have I actually use it
Speaker 3: as a demo at build. They're kind enough to give
Speaker 3: me access to it, but of course again depend about
Speaker 3: warnings from that all the time. Yeah, I mean, the
Speaker 3: whole bill of materials things is a really serious problem. Right.
Speaker 3: In fact, back in the day, some old boss Steve Lipner,
Speaker 3: who has since retired, he came with this term giblets,
Speaker 3: which is, you know, components that you depend on that
Speaker 3: you don't own. The problem is if they have a vulnerability, congratulations,
Speaker 3: you've got a vulnerability too.
Speaker 2: You've got it too.
Speaker 3: And the funny thing is that product that sort of
Speaker 3: woke us up to that was actually seql server with slammer.
Speaker 1: Yeah, tell us telescope. I can't remember exactly what happened,
Speaker 1: like two thousand and one.
Speaker 3: Slammer, yeah, two thousand and one. Yeah. It was a worm,
Speaker 3: a really nasty worm. It was a UDP worm. So
Speaker 3: it traveled like wildfire, right because you know, you didn't
Speaker 3: have to do any three way handshakes. You're just dropping
Speaker 3: a UDP packet on the network and off you go.
Speaker 3: So produced, you know, you end up creating huge network
Speaker 3: congestion of compromise machines. What was interesting though, oh yeah, okay,
Speaker 3: I remember now. But what was interesting though, is that
Speaker 3: seql server actually wasn't really impacted. What was impacted was
Speaker 3: msde right, the embedded version of sql server that people
Speaker 3: had their accounting pro right. They needed a good a
Speaker 3: good quality database that wasn't access right, so they wanted
Speaker 3: SQL server, but they don't want to buy seql service
Speaker 3: with msdu right, So the embedded version, so you have
Speaker 3: your accounting soft we're running this database back end, and
Speaker 3: people didn't realize they had it, so they weren't patching it.
Speaker 3: Because they weren't patching it, they got whacked by slammer.
Speaker 3: So that work us up to this idea of that.
Speaker 3: Steve called it giblets, which is components you depend on
Speaker 3: that you don't control.
Speaker 1: So the idea is you're making gravy and you cut
Speaker 1: up these things that you that look like little weird parts,
Speaker 1: and one of them has like a virus or something,
Speaker 1: and is that the idea is that the metaphor, you
Speaker 1: know what?
Speaker 3: I think the metaphor is the chicken is yours, but
Speaker 3: you've got these giblets inside. I don't I don't think
Speaker 3: there's actually a good this. This conversation isn't gonna end
Speaker 3: very well. I don't know body parts that's okay, but
Speaker 3: but yeah, I.
Speaker 2: Thought the main impact of slimer was just burying networks.
Speaker 3: It was a UDIP, it was a UTP payload, so
Speaker 3: and the payload actually sat that actually fit fitted in
Speaker 3: one UDIP packet. So what would happen is, you know,
Speaker 3: you'd have a machine that would just generate random IP
Speaker 3: addresses and then just send that UDOP package to that endpoint.
Speaker 3: But they could do it so quickly that because it was UDP, right,
Speaker 3: there's no three away handshakes.
Speaker 2: And it was already patched, as I recall, it was patched.
Speaker 2: There was a patch, and I'll like it had been
Speaker 2: out for a while too. All of us it RAN
Speaker 2: sequel servers had done the patches. But it's all these
Speaker 2: app devs and these little applications that had msde med
Speaker 2: it in it that hadn't been patched became propagation machine.
Speaker 3: That was the problem. There was one beautiful piece of
Speaker 3: the code was actually buggy. I could be wrong, and
Speaker 3: there's two ways I could go with this. It either
Speaker 3: didn't generate odd numbers or it didn't generate even numbers.
Speaker 3: I can't remember which. Let's just go with even numbers.
Speaker 3: But the random number generatesor for generating the four architects
Speaker 3: from ip address couldn't generate even numbers, so it left
Speaker 3: out huge swaths of the Internet, which is a good thing.
Speaker 3: But yeah, the other interesting part of that is so
Speaker 3: the guy that found the bug was a guy called
Speaker 3: David Litchfield who worked in the UK at the time.
Speaker 3: He worked for Apple. And here I spoke in my
Speaker 3: last book, Designing and Developing Secure as Your Solutions, actually
Speaker 3: spoke with we've been we've been good friends for a
Speaker 3: long time, and I spoke at Land like how he
Speaker 3: found the bug and that sort of stuff. But that
Speaker 3: was the where he put out the announcements about the bug.
Speaker 3: He included a proof of concept, right, and that was
Speaker 3: the last time you ever put out a proof of
Speaker 3: concept because of the damage that was caused by evil
Speaker 3: people using it.
Speaker 2: People use it.
Speaker 3: We imagine, imagine if you didn't even imagine if you
Speaker 3: ran the proof of concept in your own little environment
Speaker 3: and escaped from the lab.
Speaker 2: Yeah, you know, yeah, that's the thing with those propagators,
Speaker 2: like more often than not they did escape from the lab.
Speaker 2: Like that's how they actually got away back in the day,
Speaker 2: in the last black hat days that exists today.
Speaker 3: So for what it's worth though I used that slammer
Speaker 3: code or the bug in SQL serve. Actually the code
Speaker 3: wasn't even in sql The bug wasn't actually in SQL server.
Speaker 3: It wasn't in one TCP one four three three. It
Speaker 3: was UDP one three one four three four, which is
Speaker 3: the management interface, which is not the database engine. It's
Speaker 3: all the management goop around it. So I actually I
Speaker 3: actually use that code for lots of examples about how
Speaker 3: we've made progress at Microsoft and in the industry in general.
Speaker 3: So for example, so Carl, you mentioned GitHub and you
Speaker 3: mentioned dependerbot. Well, another thing that GitHub has which is
Speaker 3: really cool is code ql, which is absolutely I'm a
Speaker 3: huge fan of coql. And so if you've got a
Speaker 3: public repo, or if you have a private repo and
Speaker 3: you have an enterprise agreement, let's let's just go with
Speaker 3: public repair. If you do a poor request, it will
Speaker 3: run codeql. I think they call it security scanning or something.
Speaker 3: It will run coq well over the poor request. And
Speaker 3: if there's a vulnerability, well, actually you can't merge the
Speaker 3: poor request.
Speaker 1: Yeah, nice, that's great.
Speaker 3: Which is really nice. That's even better though, you can
Speaker 3: even opt in for an auto fix and it will
Speaker 3: use AI to generate a fix. Yeah, and it will
Speaker 3: provide that as an update, and you can say whether
Speaker 3: you want to take the take the merge or not. Yeah.
Speaker 1: I guess so.
Speaker 3: But it's really really I'm a huge, huge fan of
Speaker 3: co q WEL because you can write your own rules
Speaker 3: for it, which I really like.
Speaker 1: That's cool.
Speaker 2: I guess we got to talk about AI because it
Speaker 2: sounds like both hacking and and resisting being hacked are
Speaker 2: going to be affected by these tools.
Speaker 3: Yeah. I mean it's more than that, right, I mean,
Speaker 3: I you know, as we mentioned air quotes in the
Speaker 3: green room, the impact AI is having in the software
Speaker 3: industry and security especially cannot be understated. The work that
Speaker 3: we're doing at Microsoft, Like I think every single day
Speaker 3: I have at least two meetings on my calendar that
Speaker 3: have the letters A and I right in there about
Speaker 3: something that's going on in software development, security, security testing.
Speaker 3: Once today I just had just now is on security
Speaker 3: testing with AI and you know producing you know test
Speaker 3: plans that test security. One I had the other day
Speaker 3: was or some scanning, some really smart password scanning or
Speaker 3: you know, looking for rogue endpoint or unpatched doandpoints using AI.
Speaker 3: And they're literally literally, these guys were vibe coding, the developers,
Speaker 3: but they were vibe coding, and they're using Go because
Speaker 3: of the concurrency to be able to scan things quickly again,
Speaker 3: and they were. They batually said that ninety eight percent
Speaker 3: of this was vibe coded. The other two percent was
Speaker 3: a human being. So you know, there's a demo that
Speaker 3: I gave it build where I had some code that
Speaker 3: had a service side request ford. It was in C
Speaker 3: sharp is a rest dandpoint and I actually said in
Speaker 3: Visual Studio, you know, hey, do a security code review
Speaker 3: of this this code, and you know, fingers crossed because
Speaker 3: of the nondeterministic nature of LLLMS. It came back with, hey,
Speaker 3: there's a service side squardry here, and actually came up
Speaker 3: with a couple more I hadn't even thought about. Wow, wow,
Speaker 3: So you know, do we even need static analysis tools
Speaker 3: at this point? Yes, we do. But you know, it's
Speaker 3: just an interesting thing that's built into the product that
Speaker 3: gives you not just a bug, but also an explanation
Speaker 3: of why the bug's bad. And if you want it,
Speaker 3: you know, you can tell it, Hey, we'll fix the
Speaker 3: bug for me. If you're on a Visual Studio code
Speaker 3: in my agent mode or something's crazy.
Speaker 2: It's power. It is powerful and at least gives you
Speaker 2: ideas the question of whether or not it's comprehensive or not. Yeah,
Speaker 2: it's you know, a big one. Well as well as,
Speaker 2: like I said, not deterministic. I asked it again and
Speaker 2: I found different vulnerabilities.
Speaker 3: Right the other way looking at it is it's almost
Speaker 3: like learning on demand as well. Right, well, I didn't
Speaker 3: even know that was a problem. Well now you do, so, Yeah,
Speaker 3: it's I'm a huge fan of course in the defensive
Speaker 3: side of things. You know, we get so many signals
Speaker 3: at Microsoft every single day, and the many trillions of
Speaker 3: signals every single day, there's no where human being can
Speaker 3: go through all them, and so we use AI extensively
Speaker 3: to work out what's real and what's not before a
Speaker 3: human gets to look at things.
Speaker 1: I want to shift gears before we end here. And
Speaker 1: I know that you know secure code is your thing.
Speaker 1: Are there is there anything that we haven't talked about
Speaker 1: that your average developer might fall into the trap of
Speaker 1: or needs to be aware of where you know to
Speaker 1: to leave vulnerabilities in their code. I mean, obviously seql
Speaker 1: injection is a huge one, but I think everybody that
Speaker 1: listens to our show and has listened to it knows
Speaker 1: how to use parameterized queries and all that stuff. But
Speaker 1: are there are any any other things that might not
Speaker 1: be so obvious.
Speaker 3: Yeah, so we mentioned sequel injection. I touched on cross
Speaker 3: site scripting before with remember that talked about the ASP
Speaker 3: dot net class or whatever it was that detected cross
Speaker 3: site scripting and vulnerabilities or attacks I should.
Speaker 1: Say anti forgery tokens.
Speaker 3: That's the one. Yeah, that's another one, and it doesn't matter.
Speaker 3: But you know, talk about a service SID request for
Speaker 3: just squal injection, cross site scripting, memory corruption, and so on.
Speaker 3: They all have one thing in common. They're all input
Speaker 3: valid problems, every single one of them. And that problem
Speaker 3: transcends vulnerabilities, like there'll be new vulnerabilities in the future
Speaker 3: that we don't even know about yet. Even LMS, right,
Speaker 3: LLM suffer from input validation problems.
Speaker 2: Sure, and the.
Speaker 3: Fact that you're merging the data plane with the control plane.
Speaker 3: But that's a whole other problem. So to this day,
Speaker 3: and I wrote about this in Running Secure Code. You
Speaker 3: know the first edition of Running Secure Code, which was
Speaker 3: twenty five years ago now gratulations.
Speaker 2: It's a lot of time.
Speaker 3: I'm not sure if that's good or just absolutely terrifying.
Speaker 3: But yeah, one of the chapters is all input is
Speaker 3: evil until proven otherwise. And that's the same today. And
Speaker 3: so I still think that if developers just learned that
Speaker 3: one thing, like, you know, is this data coming in
Speaker 3: through a rest endpoint through whatever AP port, a socket
Speaker 3: or a web socket or whatever, RPC endpoint, gRPC data
Speaker 3: coming in, you know, is it correctly formed? Is it
Speaker 3: the correct stuff? Don't look for bad things because that
Speaker 3: assumes you know all the bad things. Is it correctly formed?
Speaker 3: Like if I'm expecting a zip code, is it numbers
Speaker 3: with a potential dash? Right, and that's it? And is
Speaker 3: it you know, ten digits long max or something like that.
Speaker 4: That's got to be alpha numerica because we have other
Speaker 4: content that's right, Yeah, exactly right, but even now for
Speaker 4: numeric like sorry, M well, well the UK is the same,
Speaker 4: right UK. So I used to live in L nine
Speaker 4: to ninety L when I was in England. But it's
Speaker 4: interesting that that issue is still the number one source
Speaker 4: of issues, and in fact there's a whole new issue
Speaker 4: set of issues opened up with l MS.
Speaker 3: And it's all input validation, that's all it is. I
Speaker 3: still say that's like the number one thing that developers
Speaker 3: have got to think about is my data correct.
Speaker 2: Yeah.
Speaker 1: I learned about a new attack from doing security this week,
Speaker 1: which was D serialization injection.
Speaker 2: Yep.
Speaker 1: So imagine, if you will, you have a comments paid
Speaker 1: you know, comments thing, and there's no limit to it, right,
Speaker 1: and somebody just pastes in there some JSON that has
Speaker 1: somehow attached some code to it. I don't This is
Speaker 1: what I don't understand. Maybe you de serialize that into
Speaker 1: an object that has code. Yeah, and that object has
Speaker 1: you know, in in its in its initializer, it's code
Speaker 1: that runs.
Speaker 2: Right.
Speaker 3: We'll give an example. You've got a proof of concept
Speaker 3: on this, which is this is why we might sort
Speaker 3: of deprecate to the binary serializer and SEA shop is
Speaker 3: you can deserialize a c shop object and having the
Speaker 3: constructor which will run, right, you can.
Speaker 1: Have exec yeah, exec whatever.
Speaker 3: Right, and I'll just run and I'll just run.
Speaker 1: Yeah.
Speaker 3: So there's nothing special or funky or magic abouts it is.
Speaker 3: You put whatever the heck you want in the constructor
Speaker 3: and then when it's de serialized, that runs. And if
Speaker 3: it's an exact you know, prop I don't know what
Speaker 3: it is in dot net, I'll be honest with you.
Speaker 3: It process dot execute or something process dot run.
Speaker 1: Yeah, yeah, you can create a process you're can just
Speaker 1: run it.
Speaker 3: Now you're running a arbitrary code, and the demo I
Speaker 3: give is just running notepad of course, you know.
Speaker 2: Yeah.
Speaker 1: But the thing is is that that that object has
Speaker 1: to be defined on the system that's doing the de serializing.
Speaker 1: So it's not like you can just put in a
Speaker 1: bunch of JSON and it's going to create a class
Speaker 1: that runs. Do you know what I mean? Yeah, yeah,
Speaker 1: you can't de serialize code like that.
Speaker 3: Yeah, yeah, You've got to have there's got to be
Speaker 3: a class that you know exists. So for someone like
Speaker 3: a person class, right, yeah, then you would put it
Speaker 3: in the person constructor. Yeah.
Speaker 1: Right.
Speaker 3: So so here's there are actually, actually there are other examples.
Speaker 3: There's lots of examples, and in fact, in the red
Speaker 3: team we have a person who is an absolute expert
Speaker 3: in building malicious payloads for deserialization. Okay, so I guess
Speaker 3: I'm all I can say is I'm glad he works
Speaker 3: for Microsoft and nobody else.
Speaker 2: That's good. I'm very I've had a number of people
Speaker 2: I've met over the years where you sort of look
Speaker 2: at them later and go, you know, I'm really glad
Speaker 2: you're a good guy.
Speaker 3: I know.
Speaker 1: One of the things we do, and you might like
Speaker 1: this on our show, is we take the cv score
Speaker 1: for a given threat, which is usually from one to ten,
Speaker 1: you know, being CVSS. Yes, I'm sorry. The CVE is
Speaker 1: the number that identifies the threat, the CVSS scorer, and
Speaker 1: that if it's ten, basically that means, oh my god,
Speaker 1: the world is going to end. You must patch. But
Speaker 1: we also add a contagion score, which is how realistic
Speaker 1: is it that you the average person is going to
Speaker 1: be affected by this vulnerability?
Speaker 2: Right?
Speaker 1: And that to that equation is you know, is it
Speaker 1: connected to the Internet? Do you have to be on
Speaker 1: the local network already? Do you have to have hacked
Speaker 1: to a certain point? So so what do you think
Speaker 1: about that? Do you think that should be an official
Speaker 1: thing like a contagion score or a reality score?
Speaker 3: I mean, I don't think I think that idea is
Speaker 3: actually baked into the modern versions of CVSS, like accessibility,
Speaker 3: does it require an authenticated connection? Does it require human interaction? So,
Speaker 3: if you've got something that requires no authentication, that's remote,
Speaker 3: that requires no human interaction. Then, for example, I remember
Speaker 3: a while ago, I remember a while ago, there was
Speaker 3: a really nasty bug in iOS where someone could send
Speaker 3: a text message, an SMS message.
Speaker 1: Yeah, I remember this too, right, you didn't even have
Speaker 1: to open it and it would own your phone.
Speaker 3: Yeah, exactly, I mean, don't get I mean, you know.
Speaker 3: But again, the nice thing about iOS, you know, most
Speaker 3: mobile platforms, is they're very locked down and isolated, and
Speaker 3: they assume this sort of stuff. But even but even so,
Speaker 3: it was a really nasty bug.
Speaker 1: So they we have seen scores that have been very high,
Speaker 1: like nine or whatever, that we have adjusted down for
Speaker 1: our listeners because because of those things, like you already
Speaker 1: had to be on the network, you had to like
Speaker 1: maybe there had to be a human interaction, like somebody
Speaker 1: got up from their screen and went to the bathroom
Speaker 1: and left themselves logged in, like, you know, a bunch
Speaker 1: of things had to fall into line before you could
Speaker 1: get that thing. So I'm not so sure they do
Speaker 1: a good job of Yeah.
Speaker 3: But here's the problem. But here's the problem. Though KYL
Speaker 3: is a bug by itself is interesting, a CV is interesting.
Speaker 3: You look at what the guys doing, the Red Team,
Speaker 3: they rarely take a single CVE. They chained them together.
Speaker 1: Yeah, yeah, that's true.
Speaker 3: Right, So you may have a remote and unauthenticated thing
Speaker 3: that does nothing exciting. Then you have another one that's
Speaker 3: a local only that gives you some privilege elevation. Then
Speaker 3: you have another one that requires a little bit of
Speaker 3: privileged access, but now it gives you godlike on the box. Right,
Speaker 3: So he chained three together. So that's where it becomes. Yeah,
Speaker 3: that's where it becomes really dangerous. And that's one thing
Speaker 3: I love about the Red Team, right, is they think
Speaker 3: about these things. So John Lambert, corporate VP and security
Speaker 3: fell at Microsoft, you know, he says that attackers thinking graphs,
Speaker 3: that's what they're doing. They're chaining these things together. They
Speaker 3: don't think about individual spot things.
Speaker 1: First we'll use this exploit. Then we'll you know, take
Speaker 1: a late use whatever is the lay of the land.
Speaker 1: I guess what they call it, you know, feeding off
Speaker 1: the land, feeding off the land. Yeah, see what's there? Yeah,
Speaker 1: and then maybe use another exploit, another privsk and then
Speaker 1: you own the box.
Speaker 3: Yeah absolutely, And now next thing you know, you're broken
Speaker 3: out of a VM you know, and you're on the
Speaker 3: host the ultimate path traverse, right. I mean, that's that's
Speaker 3: pretty nasty, you know. And that's where security guarantees come
Speaker 3: into play. Is what are the security guarantees around your
Speaker 3: security mitigation? Is there a security guarantee around it? So,
Speaker 3: for example, there are security guarantees around VMS. If you
Speaker 3: violate that, then that's a serious problem that we will fix, right.
Speaker 3: But other things, so you know, other things don't have
Speaker 3: security guarantees. It's really good examples of his code obfuscation.
Speaker 3: There's no security guarantee. There are none because eventually the
Speaker 3: CPU has to know what instructions to execute. Right.
Speaker 1: And if you know you're you're a hacker, you're on
Speaker 1: the box and you know a assembler or binary, you
Speaker 1: can just go walk the memory and see what's going on.
Speaker 3: It's funnys you bring that up. Someone made a comment
Speaker 3: on x about some C sharp link stuff or whatever
Speaker 3: and said, which is fast? And they give you three
Speaker 3: different examples of link and I said, I don't know,
Speaker 3: So let's look at the assembly language. Nice, you know,
Speaker 3: it's let's look at what it's doing. And it was
Speaker 3: really interesting. And this guy made a comment to me, said,
Speaker 3: you read assembly language. I said, assembly language is the truth.
Speaker 2: This is what it's landing on the processor.
Speaker 3: Yeah, I mean you can read whatever you want in
Speaker 3: the you know, in the source code, but it's what's
Speaker 3: generated by the compiler on the link that matters.
Speaker 1: But quite frankly, I would rather you to look at
Speaker 1: the thing with the assembly language, then learn assembly language
Speaker 1: to the point where I could spot a problem. Thank
Speaker 1: you very much, dude.
Speaker 3: I love assembly language. I'm not gonna lie. I love
Speaker 3: assembly language. It's it's my happy place. Well, I mean
Speaker 3: c is probably my happy place. I love CE, but
Speaker 3: I love a SAMI language. Yeah, I've been learning a
Speaker 3: lot about our assembly language.
Speaker 2: Well, and see what was created to make more portable
Speaker 2: assembly language that you could write one and degenerate down
Speaker 2: and do assembly for different processors.
Speaker 1: So what's next for you? What's in your inbox?
Speaker 3: What's in my inbox? A lot of MCP security these days,
Speaker 3: you believe it or not. On the as of Security podcast,
Speaker 3: we interviewed a guy who works on MCP at Microsoft
Speaker 3: and also on the working group for MCP.
Speaker 1: This is let me get it, Master Control Protocol, a
Speaker 1: little model, monitor model. Anyway, it's what's between your agent
Speaker 1: and the services that you want the agent to access
Speaker 1: on your behalf model context protocol model context. But I'm
Speaker 1: never going to remember this model context protocol.
Speaker 3: Yeah I I I'm you know what, I have problems
Speaker 3: remembering as well. Yeah, I hear every single day.
Speaker 2: Yes, because I keep picking tron Master Control program a lot.
Speaker 1: That's what it is.
Speaker 3: But but yeah, you know, MCP is being used everywhere,
Speaker 3: and all of a sudden, you know as e sql
Speaker 3: database has now got m C MCP server. Visual Studio
Speaker 3: code is an MCP client.
Speaker 1: But last we knew it wasn't secure, right, Well.
Speaker 3: So actually it's interesting the MCP guys are trying as
Speaker 3: hard as possible to offload that's a terrible word the
Speaker 3: security to the underlying environment. Like so for example, ACT
Speaker 3: authentication shouldn't really be an MCP thing really really should be.
Speaker 3: You know, if you use two user or two for authorization,
Speaker 3: you want to use open idconnect for authentication, use you
Speaker 3: use Windows Authentication for authentication, so beet.
Speaker 1: And then your MCP is is whatever is there correct?
Speaker 3: Correct? Which is which I agree with. There there is
Speaker 3: some work going on with authorization. They recognize that, but
Speaker 3: I would not throw out the terms MCP is insecure.
Speaker 3: I would think MCP doesn't do some things on purpose.
Speaker 3: So it's not locked into a WS it's not locked
Speaker 3: into Azure, it's not locked into Windows or Linux or
Speaker 3: whatever they talk about.
Speaker 1: Can it be exploited though?
Speaker 3: Well, I actually funny should say that I sort of
Speaker 3: the thing came came across in my inbox, but a
Speaker 3: vulnerability in some MCP client because it wasn't authenticating the server.
Speaker 1: Well okay, okay, not MCP's fault.
Speaker 3: That's not an mc exactly exactly right, it's not an
Speaker 3: MCP fault. But you know this, this bug is being
Speaker 3: built as an MCP vulnerability, but it's not, you know,
Speaker 3: so I I understand your you know how you're arriving
Speaker 3: at that, but by the same token, you gotta understand
Speaker 3: where the MCP guys draw the line, right, Okay, I
Speaker 3: think that's fair.
Speaker 1: That's fair, that's fair. I mean I think it was
Speaker 1: when we were talking to Scott Hunter and he had
Speaker 1: some inkling about that, right, that might be where I
Speaker 1: picked that up. Yeah, but it's good to know that
Speaker 1: it's that it's evolving and all.
Speaker 3: That apparently, Yeah, grain their authorization is that next thing m.
Speaker 1: Mm hmm okay, well you'll have to google that, folks,
Speaker 1: because we're out of time. So Michael Howard, thank you
Speaker 1: very much. It's been a pleasure talking to you and
Speaker 1: a little bit scary, but in a good way.
Speaker 3: Oh I'm not scary, that's all.
Speaker 1: No, No, you're not scary.
Speaker 2: Life is, but the world is very scary. You just
Speaker 2: reminded us.
Speaker 1: All right, Thanks a lot, and we'll talk to you
Speaker 1: next time on dot net rocks. Dot net Rocks is
Speaker 1: brought to you by Franklin's Net and produced by Pop Studios,
Speaker 1: a full service audio, video and post production facility located
Speaker 1: physically in New London, Connecticut, and of course in the
Speaker 1: cloud online at pwop dot com. Visit our website at
Speaker 1: d O T N E t R O c k
Speaker 1: S dot com for RSS feeds, downloads, mobile apps, comments,
Speaker 1: and access to the full archives going back to show
Speaker 1: number one, recorded in September two.
Speaker 2: Thousand and two.
Speaker 1: And make sure you check out our sponsors. They keep
Speaker 1: us in business. Now go write some code, see you
Speaker 1: next time.
Speaker 3: You got Javans
Speaker 2: And