BSidesRDU 2019 : Main Theater

small groups of people smoke

Good morning. How's the audio? Good? Awesome. Good morning. Welcome. Oh, yeah, I can't walk away from that. Never mind. Welcome to B-Sides RDU 2019. Super happy to have you here. Thanks for coming out. This is our dumpster fire edition, if you haven't heard. So, if you will, please, dumpster fire. Domster. All right, there you had the opportunity to say fire in a theater. So a little bit about B-Sides. Wall of text, I'm not going to read that. B-Sides started 10 years ago. It's a community movement primarily focused on education and community. If you know something, share it. If you don't know something, find somebody and learn from them. And a little feedback. Meet with fellow people. Do some

networking. B-Sides is a great, great platform to advance your knowledge and the community and the people you know and the things they can do for you. A little bit of interesting history. Ten years. Yeah. This happens to be number 562. In ten years, this is the 562nd B-Sides event, which I think that's an impressive number in and of itself.

We're now up to 167 cities and 48 countries. So it's not just a US thing, it's all over the globe. Started with two events back in 2009, there's 114 events like this scheduled this year. I think it's incredible how the community has grown and come together to help. So thank you for being a part of it. We definitely can always use your help. So if you have any interest, find me, find one of the staff. Let us know. We will be happy to get you involved to help everybody else out. Obviously, this is the opening. We have a keynote coming up. Mr. Chris Weisopel, super happy to have him here. Thank you. One of the changes from, actually, before that, by show of hands, who's this is first

time at a B-Sides event? Wow. Continues to impress us every time we do that, the number of new hands. So welcome. Thank you for coming and being a part of it. For those of you returning, a couple changes from last year. This year we actually have two tracks instead of just the one. So one track will be in here. The other track is in Cinema 1. So if you go out in the lobby, go to the end of the lobby, go up the stairs, follow the signs there. But there are two tracks this year, so if something doesn't interest you, you might find something interesting in the other one. So please check them out. For

lunch, there will be a bunch of food trucks out front. Give you some choices. Please enjoy. Talks will start up again at 1:00. And then we have a keynote this afternoon from Mr. Bruce Potter, which also should be entertaining. 5:00 we'll do a closing. And then we're having an after party over at High Wire at 6:30. So please join us in some libations and some more communication and discussion afterwards. SecureWorks is doing a wireless CTF, and Eversex doing their normal CTF. It's up on the third floor. OCL has Lockheed Village up on the second floor. Yay, Patrick! And the Mobile Museum is also up on the second floor. So those of you gray-beard types out

there, go relieve some history because they have some really great stuff. And another addition this year, we actually added two workshops. They were pre-reg and they sold out, so if you have a ticket, great. If you don't, sorry. We're hoping next year to expand that some more. Those workshops are over in the Durham Convention Center, so if you go out the front of the theater here, up the stairs and into the right, you'll pass the main office and then there's the two meeting rooms on the right where those workshops are. Super happy to have those added to the list this year, so... Glad those of you that could get in there did. Next year hopefully I can find more space so we can

get a few more. A few other oddball things. We were able to do free parking. Anybody happy about free parking? Good. It was just a whole lot simpler. So if you haven't done it already, take your validation, your ticket from the parking thing, go get it validated. Unfortunately they would only give us 400, so there are a couple people that may miss out, but I can only do what I can do, so I'm sorry about that, but hopefully most of you get to take advantage of that. All of the staff and the volunteers are in the charcoal edition of the shirt. If you need anything, you have any questions, find somebody with a charcoal shirt, flag them down, you know, ask them your question, whatever, we'll get you

situated. And raffle! Slight change from how we've done the raffle in the last few years. This year it's the normal two-part tickets. We'll get it all set up at the registration table a little bit later this morning once that's cleared out. In your bag there should be a ticket. Split it in half. One half goes in the box for the item you're interested in. There's about 20 items out there. And at closing ceremony we'll pull out the corresponding other half the ticket and read the number and if you have the matching ticket, it's yours. It must be here to win, so please hang around for closing and enjoy that. And last but not least, certainly not least, this is not possible without all the help of

the sponsors that put this on. Their tables are out there, please go visit them. They make it possible, so go up, please thank them for their support, you know. see what they have to say. I'm sure there's some use cases that might be useful for you, but absolutely, this doesn't happen without them. So please make them feel welcome and appreciative for their efforts. And with that said, we will be doing a keynote here in about 10 minutes. Still waiting for some people to finish through registration and get that on. So feel free to chat amongst yourself for a little bit, and we'll get Chris up here with the keynote in a few minutes. Thank you.

Should I check to see if they can see it back there? We can go out and check.

And my message is yes, my drug died. And so each step, and pick the crowd up, and pick the crowd up. I promised to reach up, and pick the crowd up, and pick the crowd up, and pick the crowd up. Get it back in my head. Good morning! Oh come on you can do better than that. Thank you. Pleased to introduce this morning Chris Weisopel, CTO and co-founder of Veracode. Chris is one of the original vulnerability researchers and an early member of Loft Heavy Industries. Give me a round for that thank you. which he joined in 1992. He's the author of Netcat for Windows and one of the authors of Loftcrack. He's testified on Capitol

Hill in the US on subjects of government security and how vulnerabilities are discovered in software. He published his first advisory in 1996 on parameter tampering in Lotus Domino and has been trying to help people not repeat this type of mistake for 15 years. He's also the author of The Art of Software Security Testing. Please give a warm welcome to Chris Weisopel.

As is a tradition that some of them are aware, all of our speakers get a little present. The glory and the dream. Open it. Oh, nice. Thank you. Thank you very much. So I'm very happy to be here. When Patrick McNeil asked me to come and speak, I was like, I don't know. And he said, the theme is dumpster fire. And I said, "I think I can work with that. I can work with that." So the title of my talk is "Security is Already Here, It's Just Unevenly Distributed." And I get asked a lot about, you know, "Are we getting better? Are we getting better at security? You've been doing this for 20 years. Are we getting better?" And I'm like, "Yes

and no." Right? There are some places where it's better, and there's a lot of places where it's not better than it was in the '90s. So it's both, right? It's better and worse. There are places that you can build something securely or rely on something, and there's a lot of places where you can't rely on whatever the vendors or the companies you're dealing with are. So that's how I started to think about it. It's unevenly distributed, and the quote is kind of a takeoff of, if anyone's a William Gibson fan, I read Neuromancer in my early 20s, and it was kind of a seminal book for me. He was the seminal cyberpunk writer, and I

follow him on Twitter, and one of his famous quotes is, the future is already here, it's just unevenly distributed, which, you know, that's pretty deep, right, when you think about that. It has to start somewhere and spread, and I thought, well, you know, if security is somewhere, maybe we can... Hopefully get the spread so that's what I'm gonna talk about today just gonna start off with This picture because I think it's so it's so fun And if you don't know which one is in that Senate hearing room, that's me right there With the long hair if you notice they let us testify with our with our hacker names. He says well pond there and space

rogue and much pink pin and Brian Oblivion and Senator Thompson, who I think was from Tennessee, was the chairman of the committee at the time. And he told a story in the press the next day where his son asked him, you know, did you do anything interesting today, Dad? And he said, yeah, I had a hearing and I was questioning a guy called Space Rogue. So I think the senators kind of enjoyed it too. But the fact that they let us testify with our hacker handles was sort of like... Giving us some respect for for what we were doing they basically said we know you guys have day jobs and you know poking holes at companies like Microsoft could put your job at

risk right it's crazy that sometimes that even happens today but back in the 90s that that happened all the time right vendors would would pressure companies say hey we're not going to do business with you if you you know are making us look look bad because that's what disclosure was back before today where it's much more accepted. But the thing that really we did at the Loft in the 90s was the concept of adversarial testing, which vendors didn't understand, companies didn't understand. They put their technology out there and they thought it was secure because they had authentication and authorization and logging and all the things that all the compliance people said that they had to

do to have a secure piece of software. But of course it was riddled with buffer overflows and just stupid logic errors, right? I found I found a vulnerability in in in Windows in the late 90s where I don't know if you remember back then but you could if you weren't connected to a domain You could have local user accounts on your machine and you could you know have file shares like that and there was actually a different authentication path it went through and the way that they checked to your your see if your password was correct to connect to the share was to do a string compare and when they did the string compare they

use the the length of the string that you sent them so all you had to do to it to if it was an alphanumeric password all you had to do is cycle through single letters, A, B, C, D, and it would just compare the first letter that you sent to the first letter in the password that was the password stored on the system. So stupid, stupid stuff like that. I think that qualifies as a dumpster fire, right? We should have something that happens when someone says dumpster fire. But this was sort of we were figuring out this way of using hacker techniques of reverse engineering, fuzzing, and just trying to do things to break the assumptions that the programmers had to find vulnerabilities. They're beginning sort

of the vulnerability research. And that got noticed by Microsoft, and they actually Wanted to have a meeting with us and said you know how are you doing this stuff like breaking our SMB protocol like how do you how do you do that and we're like hey we set up you know two machines and we sniff the network and we look at the packets and we try to figure out how it's working and then we you know we we we set up like a Linux machine to to send you know. The right with the right request that we think is going to log us in or let us take over connection and they're like what's this Linux thing you know like they did all their testing on Windows boxes

where the stack the network stack always like took control and wouldn't let them actually really test their software. So, they're like, "Huh, that's interesting. You actually look at the packets on the wire with another operating system." So, we kind of started to teach them to do that and this article here in EE Times where I'm back in the left there with the sunglasses. See, I cut my hair. Where is this? See, I cut my hair. My didn't cut his hair, but that came later. This guy Larry Lange like wanted to hear about you know Microsoft's meeting with you Why is Microsoft meeting with hackers and we're just kind of opening their eyes to like you're

in a rep You're not really doing any security testing. You're just you're just not you think you are and then a few years later The Loft, which I have bittersweet thoughts about, joined at stake, and we helped start this security consulting company with the whole concept of using good hackers to battle bad hackers. And the idea was, You know, we would sell our services, and we would do code reviews, we would fuzz, we would do manual pen testing on applications so that vendors could ship secure applications. And I worked on several applications for Microsoft at the time. And so there was this period where people were not doing security at all, and people actually started to do things sort of in

the early 2000s. And I did that for about four years. And it was all manual. There were no tools to do this. And then in 2006, me and Dildog, Christian Ryu, founded Veracode, and the idea there was there's just not enough security experts to go around. There's just too many developers writing too many applications. There weren't enough people. Let's just try to automate all the things that we could automate. So that's where we came up with binary static analysis to basically automate code review. We came up with... you know, web scanning to scan applications and other tools that would just really help developers secure the software that they were building. So now I want to talk about,

you know, where we are now. Like, what are the problems? When we testified before the Senate in '98, we famously said, and this was the sound bite that everyone latched onto, we didn't really know about sound bites back then, but we got a lesson, was we can take down the internet in 30 minutes, is what we said. And everyone was like, whoa, you can take down the internet in 30 minutes? And we didn't really want to say exactly how to do it. But we said, you know, we're gonna tell, like, the people that could potentially fix this how to do it. And what we were talking about was the BGP protocol. So the Border Gateway Protocol is how different networks route traffic between each other, right?

And this is how the different routers talk to each other between different network systems, and that's actually what kind of makes an internetwork, right? And it's totally unauthenticated. Some people would have filters that said, "I'm only going to take BGP protocol over this port from these IP addresses." But a lot of places didn't have those filters because they had to manage that and it slowed things down. And it was just sort of wide open. So you could just spoof BGP packets and tell a router that, "Hey, route your traffic through there." Well, what if you tell all the routers to route all their traffic through one place? That's not gonna work, right? And those were the things that we were talking about. So that was back in '98.

Guess what? They didn't fix it. They came up with Secure BGP. Actually, it was fixed by IETF, there's a secure BGP protocol, but no one implemented it. Everyone would sort of have to implement it. And no one implemented it. Because if you're backwards compatible, what's the point? So everyone would have to go to secure BGP, and 20 years later, no one has done it. So even though the solution exists, no one has done that. And if you look up here, this is a tweet. I follow this BGP stream because you know I'm into the BGP protocol and what they do is they whenever this sort of an anomaly in BGP in new routes that are published they Tweet about it and you can see here that

it's a US Department of Energy's network is being routed through China Telecom That's probably not the best route Right? That's probably not the best route. So this still happens today. And there was an interesting attack. It's not common that people use it for attacks. This is probably just the sniff traffic, right? But there was an attack using this in 2018 on MyEtherWallet. So MyEtherWallet is a place where you can store your Ethereum, right? And you can go to their website and you can do transactions with your account. Well, someone--they were using Route 53, which is a DNS service by Amazon. Someone did a BGP attack on Route 53. So this is a BGP attack on Amazon, right? You think they would know what they're doing, but you can't--

it's really hard to control this. They routed all the Route 53 DNS traffic through their DNS server, where they were publishing a new IP address for MyEtherWallet, so all the traffic went to a different website. They even registered a certificate for that website because once they had control of the traffic they're like hey This is my email. This is my domain. I want to register a certificate So it even showed up with a with the lock right and so this is a problem with like these foundational problems that never get fixed and They stole These attacks, I should say, are usually short-lived. There's groups like the NAG and BGP Stream that are publishing and noticing

these things. And someone will contact Route 53 and say, this doesn't look right. Maybe you want to fix that. But it takes a few hours, typically, to get this stuff noticed and fixed. In two hours, they stole $17 million in ether. So if you can compromise something within an hour or two and get away with your heist, this is a perfectly fine attack. There's other things that are still broken, like DNS. People take over DNS all the time. People DDoS DNS servers to take things down. We have DNSSEC, but that's also not really ever implemented. DNS over HTTP is really a privacy thing for end users. It doesn't really solve the DNS problems. So I saw this stat the other day that the average DNS attack against

a financial services company costs them 1.1 million-- in this case, it was pounds. But these problems have been around forever, and it doesn't seem like there's any motivation to fix them. So clearly, this is part of our dumpster fire. And I think certificate authorities is kind of the same thing with typo squatting. Anyone can get a let's encrypt. Everyone sort of wants to bypass all the UI warnings. For most users, a certificate attack is going to mess them up. And of course we have developers not implementing certificate validation properly too, right? Like in all those mobile apps. I think when we last looked at this, like 70% of mobile apps don't validate that certificates are valid. So you can just, you know, man in the middle

their TLS connections with, you know, self-signed certificates and it just thinks it's fine, right? The other thing that I see is a problem is security vendors. Of course, not all the security vendors out there are my company. But, you know, in general, security vendors like to say, we make you secure, right? Like every firewall vendor on the planet is like, you need to secure your network, right? I put in the firewall, now my network is secure. You know, that language to the average person is just completely wrong. It didn't secure the network. It does some stuff. There's some level of security. Maybe you can say it's a little more secure. You know, buy our product,

it makes your network a little more secure. It's not that exciting to the marketing folks. But that's the truth, right? Oracle's unbreakable? I don't think so. Right? So the marketing people like to use these superlatives, but superlatives are misleading, and they lead people to think that they're secure. Like, I got my firewall. The company said it makes my network secure. I got my endpoint security. The company said it makes my endpoint secure. And my, you know... My files got breached. What happened? And we blame the user for doing something stupid. Right? Oh, it's the user's fault. The user screwed up. They didn't do something right. You know, that's sort of the dumpster fire we have

with the way we talk about security to people buying security technology or services. I don't know what the solution to that one is, but it's just an ongoing problem that we never seem to be dealing with. The other problem I see all the time is people think everything is secure by default. What? No, it's insecure by default. Like the first time I saw like, you know, like remember, they don't really do this that much anymore, but remember when you first like installed Windows NT somewhere and it had like lockdown instructions, right? It's wide open and then you have to do all these different things. I remember one of the first NSA guys to locking down

like NT4. It was like 353 pages. Like, no one is going to do this. No one is going to do this, so it's inherently insecure because you shipped it wide open, right? So I think that it's the same thing we see with, you know, IoT devices, with any kind of software people install. You know, it's the same thing with privacy. You know, I'm not going to talk about privacy today, but it's the same thing. Oh, you signed up for an account. You know, you're completely exposed. It's not private at all. Oh, do all these steps to make it private, right? Like that's bullshit, right? Like that's just crap, right? And that's what we live with.

And the thing that I deal with a lot is developers. And developers think they're writing secure code by default, right? They're like, I've been doing this for 20 years. I write high quality code. It's performing code, it does the functionality, it's done on time, I'm a good developer. They think because of all those things, it's also secure. Talk to a developer. That's what they really think. They don't think they need to do anything else to make their product secure. But we all know security is a completely separate domain than quality and performance, functional quality and performance. I went to, back in 2002, I went to Java 1 with AtStake, and we actually had a boot there because we were working on a tool, and we had

a service that we would sell to people writing Java applications, and we told them, We can help you make sure that your Java application is secure. You work at a financial services company, you're making an online banking portal or whatever, hire us, we have tools, and we'll make your application secure. And the developers basically came up and they were like chuckling and laughing, like who are these goofy dudes? Like what are they talking about? I know Java is secure. That's why we chose to write in Java. It's secure. Right, because that was the marketing for Java, right? Sun marketed Java as a secure alternative to C and C++, which was the languages people were using before that. And because it was a secure language, not more secure,

or eliminates some security vulnerabilities, which, you know, no one wants to say that. They said Java was secure. So all the developers thought Java was secure. And that's why we had a decade of really crappy web apps before people started to say, oh, maybe I should have some security process here before I put my application into production. And it was just such a mind change for them. We actually showed them, like, this is how SQL injection works. And they were just in complete disbelief because their mind was already set. that they chose Java because Java was secure. So now I'll pick on the vendors a little bit. I don't know, has anyone heard the saying, you know, the cobbler's children have no shoes? And the idea is, you know,

the cobbler is so busy, you know, working, you know, dusk to dawn to put food on the table, and just barely scraping by making shoes that he doesn't have time to make shoes for his own children. So his own children don't have shoes because he's focused on making money. He's got to support his family. Well, guess what? Security vendors are exactly the same. They're trying to make their products as quickly as possible and get them to market and you know having extra security processes are having to hire security people to help them actually secure their own stuff cost money and time and I have the data to show that actually security products security vendors have

the most insecure software. So this is applications we looked at a few years ago. And the orange bar here is whether it failed our testing, which is if it had a critical or high vulnerabilities when we did testing. And you can see the financial services apps are actually pretty good. Only 37% failed out of all the ones we did. I was like, they're doing actually pretty good. The financial services people are thinking, hey, if our app gets breached and our customers lose a lot of money in some transaction or something, we're going to lose business, right? Like, it was a business requirement, a business imperative for the financial services software makers to do that. Maybe PCI and PADSS had something to do with that, but

there's also other non-regulated software that are doing doing better Even learning and growth and customer support are doing better than security products 74% failed right how does that make you feel the security companies are the ones who care the least about making secure software and It's completely ridiculous, right? But it's there in the data in our testing. And let me tell you there's another data point here. Just don't listen to me. Mudge tweeted this last year. He says the percentage of security software, 3.8% in DoD and U.S. government. So 3.8% of the software that's deployed at the DoD and the U.S. government is security software. It makes up 28% of the security vulnerabilities that they find on their network. More

than a quarter of the vulnerabilities are coming from less than 4% of software, right? So think of all the work that people are doing to maintain and configure and patch all their security solutions, right? Because the security vendors don't make secure software. Pretty crazy. I think that qualifies as dumpster fire. We should have had, like, drink, if you say that, right? So where are we going, right? So I saw this op-ed in the New York Times, and it was by the general counsel of the NSA. And he basically said, you know, technology is changing so fast, we just can't keep up with it. And that is definitely a huge factor that I see out there,

why we're in this state of insecurity. If we just sort of stopped, no new protocols, you know, you know, no new IoT products, and, like, we took a breath for a year and just sort of made sure everything was secure and got down our security debt and then, you know, worked from there, we'd probably be okay. But that's never gonna happen, right? We're never gonna do that. So we're going to be constantly churning in the state of there's new protocols, there's new ways of deploying software, there's new languages, people are doing new things with software like blockchain and AI that we don't even know how to secure, and people are putting all this money out

there and all this risk. So that's going to continue, so I totally agree. And I also agree with sort of the threat space is going to be all pervasive. So that sounds like we're going to be in a world of hurt for the future. The other thing I see out there is, you know, Marc Andreessen famously said, "Software is eating infrastructure." I'm sorry software is eating the world and so you could look at that as what are the different places software is eating and one of the things is infrastructure right that's the cloud right where everything is becoming software defined and that's one of the things that's giving us this unprecedented speed in deploying applications. is that we can just spin up all

these machines without plugging anything in or screwing things into racks. And we can just build stuff with off-the-shelf components, whether they're services from your cloud provider or they're open-source things. Speed is the name of the game. And then the whole DevOps movement is really encapsulating the concept of, you know, operations now is just software. Right? And developers can do their own ops. The next phase I see of this is DevSecOps, which is developers are gonna be able to do, you know, their own security. And security shifts from, you know, securing physical networks to securing all that software-defined stuff and applications. So we're also in a period of having to change how we do security, and, you know, I think software

is starting to eat security. We're starting to see developers do security without security experts, which is really the only way to do it because we're outnumbered like 100 to one. We can't be everywhere, there's a developer writing code and making mistakes constantly. We just can't do that. So we need automated systems that developers can use. The flip side of that is security people are-- and I'm not talking about product vendors making software that you deploy or appliances running software-- security people in enterprises, in the cloud, security people actually writing code to be security engineers. to have someone whose full-time job is security, and the way that they solve security problems in their organization is to write code. This is kind of something that Dino DiZovi talked

about at the Black Hat keynote. It's just one of the things he does at Stripe is he actually writes software to do his job of making sure the apps that Stripe builds are secure. So that's sort of where we're going. And so now I want to talk a little bit about how do we deal with this, right? Because it seems pretty bad. Like, is there any solution? Is there any way out? So I look on one side of the equation, and we have companies like D-Link, which don't really try to secure their routers, right? They don't patch them when they know that there's vulnerabilities. And they recently, you know, end of lifed a few routers that have a CVSS 10 score vulnerability in them, and they're

not going to fix it because it's that router's end of life. Well, guess what? They're still selling it, right? You can go buy a brand new one You can go buy a brand new one. They're not pulling them from the shelves. It's a forever vulnerable router that they're still selling today. And there's no regulation over this. There's actually this FTC consent decree over D-Link that came out last year. That's what this headline is here. But that was actually not for this. It was just that they weren't patching things that they knew about. was really what it was. Of course, the router's secure. I'm sure it's all over the marketing, right? It's totally secure. You know,

and then we have, you know, the leaky bucket problem, which, you know, is sort of the S3 bucket that, you know, developers are using, and there's no security process at all, right? They're just doing whatever they want with S3 buckets, and, you know, there's no policies, there's no review, there's nothing, and this is how we end up with, you know, 15 million people in Ecuador having their PII exposed on the internet, right? We have these catastrophic failures. You know, the same thing with Elastisearch. There's all kinds of things that developers are like, this is cool. This is really powerful stuff. I can just spin up all this stuff, throw all this data in there, and

it's great and get my job done. And there's no security process or controls. So, you know, that's sort of one thing. potential future that could just keep going, right? We could have insecure cloud technology. We could have insecure IoT devices. But, you know, on the other hand, this is where security is unevenly distributed. There are people and organizations that are actually making, you know, secure software. Like, I look at iOS and Windows 10 and Chrome, right? If you look at how many billions of people are using this technology and how it's not a constant shitshow, right? It's not like--you know, Windows 10 is not like, you know, Windows XP was. It's just not, it's not bad. We don't have like a global worm problem.

They've actually got their act together. And so like how can we do more of that and distribute what they're doing and less of what, you know, D-Link and what everyone is doing with the rest three buckets. How do we distribute the security more widely? So, you know, there's a saying, and this is something, you know, I had heard the saying, and I did some research. It's actually something that JFK said when he was talking about his economic policy. He said, I want an economic policy that's like a rising tide, that will lift all boats, right? My economic policy isn't going to make the overall, you know, GDP go up. Because that could just you know make all the rich companies be more productive and all

the rich people make more money in the middle class and the poor stay exactly where they are he wanted an economic policy that would lift lift all the boats like the tide does whether you're a big boat or a small boat and so I got thinking like we should think about security that way, right? We shouldn't just be saying like, well, let's have big bug bounties for Windows 10 and all the security talent out there is going after making Windows 10 incrementally more secure, right? We could do that and there would be some benefit to that, but then someone's just gonna spin up a leaky bucket or they're going to just plug in some IoT

device and it's not gonna matter that Windows 10 went from a vulnerability density of one vulnerability per million lines of code to one for every two million lines of code. That won't make a difference when you can just plug in something that has no security done to it and your data is owned. So I think we need to, people have talked about sort of getting people above the security poverty line. I think we need to think about things that can do that. So this would be a better, you know, this is nicer, right? We can all drive our boats. So I want to, you know, I think we should think about things that can be applied broadly, not just to security leaders. That's easiest for the sort of the

people that are at the bottom to apply. And I already talked about we're going to help the people that are below the security property line. So let's look at where security is unevenly distributed and think about what are the security leaders doing? What are the things that they're doing? And so one thing that they do is they assume the network is compromised. Security leaders like Google-- use a zero trust network. They famously came out with their BeyondCorp network architecture and they published it. Like, anyone can do this, and there's actually tools out there that are almost like consumer grade that you can build a zero trust network. And I think that's the direction that we need to go in. And we can look

at what Google did. They did this in response to the Aurora attacks, the fact that their Chinese branch office was trusted just because of its location on the network. They said, "Hey, we can't do this. We're a global company. You know, we can't have every network node be trusted in some way. We need to go to a zero-trust model." And I think, you know, every company should probably go to a zero-trust model with their network. If they're building out, you know, software in the cloud, go with the zero-trust model. And... The second thing I think leaders do is they build security in from the very beginning, right? When they start, we're going to build this system, they start thinking about security early,

right? Whether it's a piece of software, whether it's some infrastructure they're doing, and they don't think about security later, right? This is really hard for startups to do, but at some point they have to start thinking this way. They have to start doing this because otherwise you don't build security in until you have that huge breach and that FTC consent decree, like which happened to Twitter, it happened to Snapchat, because they didn't do any security until they were five, six years in as a company and had tens of millions of users. And it actually costs them more money to do security later. So building security in is critical, and that's what all the security leaders

do. You wouldn't get iOS, Chrome, or the security of Windows 10 unless it was built in from the very early stage of the development process. And the other thing security leaders do is they expect They expect their suppliers to do this too. And they ask their suppliers. They don't say, oh, you have a big brand name. I'm sure you wrote secure software. They don't think it's secure by default. They say, prove it to me. Prove to me, if you want me to buy your software or use your service to run my company, you have to prove to me that you're doing all the things that I'm doing when I build my own software. Like, I don't want to have extra risk in my organization just because

I'm using a supplier, right? So that's another thing that security leaders do. If you've ever tried to sell anything to Apple, Microsoft, or Google, you would know that. They scrutinize you. The other thing is they leverage the work of others. So if someone is doing something secure, they use that. They use something that's been open sourced, that they know is secure, that some other group has put out. Microsoft is actually going to be switching over to Chrome as their built-in Windows 10 browser because they said, hey, you know what? Chrome is actually doing a better job than we're doing. And we're just gonna go that way. The other thing I think is important is operate less software. Because software is hard to operate securely. First of

all, it ships insecurely, so you have to do all that extra patching to make extra configuration. You have to do the lockdown guide, and then you have to maintain its patch level, right? Why would you want to do that when you could do SaaS and make the person who's writing the software configure it securely and keep it patched, right? And put all the onus on the SaaS providers instead of receiving software and letting that software vendor shift all their liability to you, right? It's your fault. You didn't follow the lockdown guide. We had the patch out there. You didn't patch it in time. When you operate software, the system we have, I know it's not that great, right, where the vendors disclaim all liability, right? So you are

liable if you operate the software. If you use a SaaS provider, that SaaS provider needs to operate that software securely. They need to keep it patched. But all SaaS providers aren't the same. You want to hold them accountable. You want to look for their architecture. DAI stands for distributed, immutable, and ephemeral. If they're using the cloud, are they using that kind of architecture? What is their crypto? Are they doing good key management? What algorithms are they using? These are things that you have to ask a SaaS provider. Don't assume the SaaS provider is secure. But I don't think that the market can solve all problems. A lot of stuff I'm talking about is like organizations making good decisions with where they're gonna put their money. I

think that there's some problems that really just can't be solved, like the insecure IoT device, because those become sort of environmental problems, where like the Mirai botnet was able to DDoS DNS servers in lots of places. And so a lot of insecure IoT devices become an environmental problem because it allows attackers to leverage this computing power to launch attacks and DDoS anywhere on the network. So it starts to become something like pollution, like each individual person, you know, polluting might not be bad, but everyone polluting makes it so that people get asthma, right? So we need to have some minimum standards around there. I think the UK with their Secure by Design initiative for IOT is heading

in the right direction. Very basic stuff that you're like, oh my god, someone is actually shipping products that aren't doing these things, and they are, and that's why it has to be there. So these minimum standards like no hard-coded passwords in an IoT device, again, that's not secure by default. You know the the the the device needs to be securely updatable yes, people ship devices that you can't update securely like no signs no signed updates right and the third one is that they have to have a. a response capability, a vendor response capability. If someone finds a vulnerability, they actually have a process where they take in that vulnerability and update their software and update their device. I don't think

it's a lot to ask, but it's crazy that we live in a world that people are shipping stuff that doesn't even have those minimums that we have to do that. So I think we do need some government standards around minimums, or at least labeling whether you meet the standard or not. Does it meet the minimum standard or not? Maybe you can still sell the product, but it's like cigarettes. It's like if you use this product, your data is eventually going to get stolen. Like a picture of your data flying away or something on the box. Because we need transparency to understand what's a good product and what's a bad product. Because right now, we just

don't. And so that means that the market can't decide. And there's no incentive for the small people the small vendors to put in security. So I talked about the forever vulnerable routers still for sale, and I said, well, what's the solution to that? Well, there should be an expiry date like milk on a piece of hardware that you buy. If you're buying a TV, a smart TV, and it's going to be end of life after four years where they're not going to ship patches anymore, Shouldn't that be something that you know about at time of purchase and it's clearly available to the consumer? And I think if we start seeing end-of-life dates on software and hardware, people would at least know that they need to

upgrade. Like, maybe the D-Link router was only $100 and you had it for six years and, you know... upgrading to another one for $100. Maybe it's not a big deal, but the thing is people don't even know. They don't even know that their hardware needs to be decommissioned and they need to buy something new. They don't even know. So this is where transparency can make a big difference.

And then this is, I think, I'm talking to the audience here of you. What can you do? What can security people do to talk to business leaders? And we need to communicate some of the things I talked about. We need to communicate that we can't trust internet infrastructure. If we're building something securely that's operating over the internet, we have to put in extra stuff to make sure that we are mitigating the fact that BGP is never gonna get fixed, DNS is never gonna get fixed, certificates are always going to be a problem. You know, that would maybe say, "Hey, maybe we should be pinning our certificates "in our mobile app," or at least be checking

for certificate validity. You know, if people don't know these things, how are they gonna do it? So we still have to constantly be educating. And the other one I think is really around security products where people think if I just get all the right security products that I check all the boxes that I'll be secure. And we all know that's not true, but there are still CISOs out there that don't think this, especially organizations that don't have CISOs, right? They have just a CIO or a head of IT. And they think that they, you know, if they get the right few security products, right set of security products, they'll be secure. And, you know, we have to make sure people know that that's

not true. And lastly, I think this is really one of the most important things is, you know, technology is not secure by default. It takes work. And don't ship me a lockdown guide. Actually make your stuff secure. And think of this as, you know, a supply chain problem where whenever you're buying something, you're inheriting risk unless you do your due diligence. And you, because there's no regulations here, like when you buy a house, you know it passed the inspection, right? It was built to the building code and it passed the inspection. So you don't have to do much due diligence about the safety of the house, right? When you buy it, like the banister isn't just going to fall off, right? Someone checked that. If there's supposed

to be a fire door between the garage and the house, it's there, right? Because someone checked that. With technology, there's no building code. There's no inspector. It's up to you to do that. And I think that most business leaders don't understand this. They don't think this way. They think that there's a big brand there. So, of course, they did it securely. We all know from the data that if it's a security product, it doesn't matter how big the brand name is. So I think that's probably the most important thing that we need to get across to people that have the checkbook and are buying things, that you're buying, you're inheriting a huge amount of risk

unless you do your due diligence and push back on your vendors. So I think I'm about out of time. I don't know if we have time for a couple questions or not. What do you think? Yeah, so if anyone has a question, we'd be happy to try something. Someone in the back there? Yeah, so I think, well, I like the idea of FedRAMP. I don't like the idea that it's like super complicated and no one can get FedRAMPed, right? I can tell you that Veracode has been trying to get FedRAMPed for like three years now. It's just a complete, complete, I don't know, dumpster fire. So, drink. So I like the concept of FedRAMP. I just think that the whole thing is really broken. The

amount of paperwork and consultants and all this stuff is... I like the concept of it where the federal government is saying, hey, you know, if I'm going to buy your SaaS solution, your cloud solution, I need to do my due diligence and make sure you did yours. But we need lower tiers that are simpler... SIMPLER TO MEET. SOC 2 IS BETTER. IT'S NOT AS BAD AS FED RAMP. AND THAT'S DEFINITELY SOMETHING THAT I WOULD LOOK TO MY SAS PROVIDERS TO SAY, YOU KNOW, ESPECIALLY IF I HAD MY CUSTOMER DATA OR MY EMPLOYEES DATA AT THAT SAS PROVIDER, I WOULD WANT TO MAKE SURE THEY WERE SOC 2 COMPLIANT. YEP.

I still think it can be solved with technology, right? You can force people to use two-factor. And if you look at all the ways two-factor bypass, like people hijacking SMS and stuff like that, those are all technical attacks. I think the people problems can all be solved. We're just not willing to do it. And people aren't willing to do something which takes a little bit more time. How much longer does it take to log in with your Duo or whatever? I don't know, five seconds? Right, come on, right? So, yeah, the anxiety. Yeah, that's what I liked about Jua. They made it 60 seconds instead of like whatever it was with RSA security. So I

don't buy it. I think that we can solve the people problems. Want to do it? Friction is not... Any friction. People want to do it. That's the problem.

I agree, I agree. Fallbacks to insecure protocols, like fall back to, once you have two factor in place, falling back to one factor is insecure. And I think that it's very clear to people that we're shipping it secure, you're turning the knob to insecure. And then thinking about it that way, they've decided to take on risk. What we do is we don't do it that way, we say My technology is secure. My system is secure. Use it. Oh, there's this lockdown guide that allows you to do two-factor. That's really what I'm talking about. It's like flip it, flip it around. So I guess we're pretty much out of time. Thank you so much.

Hey, reaction. A simple task of turning. So sure. Much too soon. Isn't something too natural for me? Taken in desperation. Suicide. Hit this zone. Bump to a side. Bump to a side. Make a new power. Explosion. Explosion. Suicide. Are we good? Hey! Hey everybody! So we're moving on to the next talk and this is, I'm happy to be introducing Ray Doyle, the man, the myth, the legend, also known as Doyler Sec. He's the senior staff adversarial engineer at Avalara. He's been there recently and you can visit his blog. Sorry, we had to do some last minute changing on here. Anyways, you can visit his blog at doiler.net where he's been posting for over four years now. When he's not hacking for work, he's well hacking for fun

as well. Ray has attended various security conferences for the past few years now and has even spoken at CarolinaCon, B-Sides Manchester, BurrCon, B-Sides Denver, and B-Sides RDU. He has competed in numerous hacking competitions and CTFs over the years, most recently with Team EverSec and managed to place seventh in the DEF CON Open CTF. First in the Raleigh B-Side CTF, second in the DerbyCon CTF, first in the DEFCON 24, so hopelessly broken CTF, winning a DEFCON Black Badge, and first in the DEFCON 25 Wireless CTF, helping to win another Black Badge. Other than security, you can always hit him up for a game of Overwatch. He's Doyler... pound 1799 in the Diamond Rank Warframe, he's Doyler, or a Super Smash

Bros. Melee money match. So here he is, he's what is HTTPS and why does it matter? Congratulations. - All right, so we're gonna pretend there's slides. Oh, hold on, that's my fault. Computers are hard, guys. No? Thanks to Ashley for introducing me for this wonderful talk. It was there and now it's gone. What happened?

Give back the HDMI. I know, you may have to stand up here the whole time. There you go. All right, computers, back at it. All right, so like Ashley said, my talk is what is HTTPS and why does it matter? So before I get started, does anyone here know nothing about HTTPS? Awesome, at least one person. Hopefully you'll get the most of this talk. Does anyone know a ton about HTTPS? Cool, you want to switch? Because you probably know more than me. Either way, hopefully everyone learned something. If not, if you're waiting for the next speaker, hopefully you can at least be entertained. So Ashley gave a super long introduction. I'm Ray, a doiler at DoylerSec, local to the area, been here for years. You

can find me on Twitter @DoylerSec or my blog. I've been posting weekly for four years now. There's a ton of posts. Senior staff adversarial engineer at Avalara in downtown Durham. Great company, just started. Also part of Team EverSec and EverSec CTF. We're running the CTF upstairs and we also just won DerbyCon this year. Wasn't in the bio. The last DerbyCon ever. Awesome. Come talk to us about our CTF or competing. And yeah, I've got a ton of certs. Ashley asked if she could skip them. If you want to learn about certs or know a cool one I don't have, let me know. That said, a better way to get to know me? Whiskey. This is

a picture of our third annual Bourbon Bonanza. We had 54 whiskeys this year. So buy me a drink, talk about anything computers, I'll probably listen. And crowd involvement. I'm not going to make a drink for those of you who saw my CarolinaCon talk. That went horribly. But I highly recommend you live tweeting during this talk. When I get something wrong, use that hashtag. If you want me to learn something new, use that hashtag. If you take a picture of me looking ridiculous or good, use the hashtag. Have fun with it. It'll be a good time. So before I begin... Some caveats. As I joked about in the beginning, I'm not an expert. My job is

to break stuff. I'm a penetration tester, formerly developer. There's tons I don't know about, and in 40 minutes I can't cover the tip of the iceberg about HTTPS. That said, I'm hopefully going to cover a lot of talks, or sorry, a lot of topics that will at least get you familiar with it and why you should be using it if you're not already. So here's a big verbose slide full of definitions. You can read it. I'll post the slides later. It's not all going to be important right now. That said, HTTP is how your browser and the web server you're connected to communicate. It's the basis of what we know as the internet. Your computer

tells a website you want a web page, it sends it back to you, you can view it. HTTPS is HTTP over SSL. It's how when you go to, you know, PayPal or Ebank's website, you get that cool little like lock icon in the top left. Some things say you're secure. Sometimes you no longer get all those scary warnings. That's basically how your connection is. It's telling you that the connection is secure to a point. And that's hopefully what you'll learn a little about during this topic. What SSL is, is what's actually performing the encryption for HTTPS. In short, it's how the data, so your passwords, all of the information you're getting back from the website, your credit card when you're on Amazon, how it's being transmitted back and

forth so that ideally only you and the server know that information. TLS stands for Transport Layer Security. This is just an updated, more secure version of SSL, basically. Nowadays, when most people say SSL or HTTPS, they're actually referring to TLS. Hopefully most sites aren't using SSL. That's a talk for another topic. HSTS is a very important topic that I'm not going to cover at all. That's what I wanted to include it. The biggest benefit of HSTS is it prevents downgrade attacks. Back when SSL was first implemented, you could have your bank, it could be secure, but an attacker could basically tell your connection, no, you don't want to use SSL, it's fine, use the other one. So it wouldn't actually be encrypted anyway. That said, I'm not

going to have the time for that. If you're interested, look it up, talk to me, talk to people who raised their hand when they said they knew more than me. So, what are the advantages of SSL? Why should I implement it? Why do I want it? Honestly, there's a ton of advantages. Nowadays, Google's going to rank you higher. Customers are going to feel more secure. There'll be privacy. There'll be data integrity. I'll cover a lot of these, but honestly, the biggest issue is just security. You want to have a secure website. You care about security. Implement HTTPS. Implement SSL, TLS. So what are the disadvantages? I've seen plenty of arguments, I've seen plenty of websites, but it's 2019. The only real argument that's a disadvantage is

it is more work. It's not necessarily a ton of work, but the difference between having an HTTP website and having an HTTPS website is a little more work. That's it. So, one of the first advantages I mentioned, or didn't mention, but that was on that slide, is authentication. Authentication is just how you log into a website. When you go to yourbank.com, you type in your username, you type in your password, you hit enter. That's the act of authentication. Credentials are what you're actually passing to the website, username and password. So, when you authenticate to a website, ideally you don't want other people to know your username and password. This is the reason you either, you

know, keep it on a post-it note that you don't show to anyone, or you use a password manager, or you just remember it. We know that our passwords are important and private for the most part, so we try not to share them. Well, if a website's not using HTTPS, you're sharing it with people and you may not even realize it. So, let's see if a video can work. We're not going to do any live demos yet. So to set this up, on the right window, we have our evil attacker in a coffee shop just hanging out, trying to do some bad stuff. And on the left, we have a user who's just trying to log into their banking website. So I apologize if the size is small. Oh,

no. OK, so the hacker's starting up some software on his right window. It's called Wireshark. It just listens to network traffic. So now on the left side, we have our user, and they're just trying to log into their website. It's a very beautifully designed banking website. It looks a lot like some of the CTF challenges. I'm no longer a developer. So they're just logging in, and if you can see, there's no lock icon. It says "not secure," so that's one of the ways we know HTTPS is not being used. So they type in their credentials, and they're logged in. So they get their account number, 8-6-7-5-3-0-9, and they get their account balance, which is $1.3

million. So, you know, they're doing pretty good. They're feeling good about themselves. They're just checking their banking information at Starbucks. So, they're happy. But now, the attacker who's, you know, sitting a few rows away, drinking his latte, he's seen some network traffic, so he's scrolling through it, just to see what he's, you know, captured on this network. And he sees an HTTP request, which, like we said before, is how browsers and web servers communicate. And the video appears to have restarted. So, he sees an HTTP request. So once he remembers how to use his program, he takes a look at it. And this is just a request from the browser to the server saying, "Hey, give me my banking website." There's nothing interesting there, it's just code

for the website. No big deal. He scrolls a little further, keeps just looking, see if he's got anything interesting, and sees another request. Now in this request, if we can see, they're actually going to login.php, so the login page, and we've got their username and password right now for their banking website. Not something you want to give to a random person at Starbucks. Additionally, actually from the response from the server, we've now got their account number as well as their account balance. So this is a clear example of why you want to use HTTPS, why you don't want to be logging into websites that don't use HTTPS. So another example of an advantage of HTTPS is privacy. I'm sure most people

know what privacy is by now. You've heard the term once or twice in your lifetime. You know it. There are things I'm sure that you do or post on the internet that may not be considered sensitive information. They're not a username, they're not a password, they're not your credit card, but they're things you wouldn't just shout out loud. They're things you wouldn't just post on a wall somewhere. They could be, you know, a private conversation between you and someone else. It could be a quiz online that is, you know, more sensitive information. It doesn't matter. There are things that we do on the internet that we have some sort of expectation of privacy. That said, without HTTPS, same as the banking information, people could sniff it, they could

capture it, they could view what you're sending or receiving on the internet. There is another point of this that I'm not going to cover. It's an entire other presentation. So when you go to, say, yourbank.com. Your computer sends a request called DNS saying, "Hey, where's the address of mybank.com?" And it gives you back that address. None of that is encrypted, so people will still know what websites you're going to even if you do use HTTPS. So any website you go to, if someone's listening, they will know it. There is a way to do DNS over HTTPS. It's fairly new, it's very complicated, but that part of the privacy won't be covered by standard HTTPS. So

an example of privacy. Now I just went to Google and was looking for domestic abuse examples. Unfortunately, not unfortunately, I couldn't, thankfully I couldn't find a form that was using HTTP, but I did find the Wake County Network of Care, which lists all the domestic violence shelters on an HTTP website. Now that said, if you can imagine, instead of a search bar, if there was a form here, that you would enter information about, you know, a potential abusive spouse or person you know. So that's something that's not sensitive information, it's not a credit card, but if you were inputting form data about, you know, "Hey, this person is abusing me, I would like to find

a shelter, I'll schedule an appointment," anything like that, someone on your network could sniff it. Instead of a bad guy at Starbucks, it could be the abuser, it could be someone who's trying to find out information about you. So, HTTPS isn't just about, you know, buying stuff on Amazon, checking out PayPal. Privacy is a huge issue if you don't want people to listen to your, you know, your connections. So, we know that we should log in over HTTPS. That's great. Let's see a video of that. So, we go back. So, now we're at our homepage for our bank, which is an even prettier website that, you know, has a button at the top left that

says log in. Again, I'm not the best web developer. And it's a little harder to see, but this page is not secure. That's unfortunate, but if you look, there's no login, there's no sensitive information. We're okay for now. And on the right side, we still have our evil hacker listening to the network. Or he will be in a second. So when we click the login link, we're taken back to... our login page. And now if you see, the little lock icon is back, or it's not back, the little lock icon is there. We're, you know, using HTTPS now. It's in the URL bar. Everything is happy. So let's see what happens when we log in, same as before. We type in our username. We type in our password.

We're logged back into our bank. We still have the same amount of money. Awesome, so if we go back to the evil hackers window, he's seeing you know what he captured He's not good at wireshark filters, so he's scrolling up and down He sees a connection, so if we take a look at that we see you know the original the original page Which was not using HTTPS, okay? That's okay We knew there was just a button there so he clears that and he's still looking for the login as well as the bank account information so he he scrolls up and down and Actually, I think this one may be the... So he scrolls up and

down, and if we see right there, there's some weird new protocol that says TLS. Let's look at... Well, I don't know what that is. I can't read any of that. That doesn't seem helpful at all. But it was TLS v1.2, which I mentioned earlier. So that... He can't read that. That doesn't help us at all yet. So he scrolls a bit more. He's just seeing if he captured anything, and there's no other HTTP like there was before. So the reason for that was, once we clicked on that login page, the browser and the server made a secure connection and everything we sent back and forth was encrypted. So I honestly don't know if that was

the correct packet, but the packet we opened that had all that gibberish and nonsense, that was actually the same as before with the username and password and banking information, but the attacker wasn't able to read it this time. Awesome. Almost awesome. So another huge advantage of HTTPS is Data Integrity. Now, Data Integrity, in short, means that if you go to, you know, yourbank.com, and it has HTTPS, it's got the little lock icon, it's in the URL bar, no errors, everything is happy, then in theory, no one can change anything on that page. If it was HTTP, people can change the stuff on that page. While they're able to intercept the traffic and we saw see what's on it, they could also change it

before it gets back to you and your browser would have no way of knowing that what the server sent is what you received. HTTPS does this in a form of, you know, it's called message digest. Basically they take what the server sends, do some math, get a number, give that number to your browser and say, "Hey, these two things need to match up." This allows you to know that no one tampered with your information as well. Well, why does that matter? I mean, if someone wants to tell me I have less money in my bank account, that's fine. Well, the reason this matters is the video we just showed before, or I just showed before.

So, we're back on the HTTP website that has just a login button. No big deal. We know we're not sending any information to that. Well, if you look, we click the same login button. This isn't a different web page. We're at a page that looks slightly different because my web development skills still aren't great. And it says this is a malicious site. Ideally the hackers won't be doing this but for the demo purposes it will be and if you look in the URL It's actually a different URL. It says the connection is not secure the URL is different That's kind of weird, but we know our bank uses SSL so we log in we're in

our bank the URL is correct We're at you know our banking website our bank account information is fine And we had a right balance, so I don't know what that was about no big deal well this if we take a look at from the hackers perspective you know he looks Oh man, did I? Nope, I just typed the wrong thing. Okay, so he's got a, this zooms in in a second, he's got a file on his web server that actually has our username and password, but he shouldn't have that. We logged in using SSL. We went to our main bank website. What's up with that? So as it turns out, if we take a look

at the source of our main banking page's website, the link for our login page is actually different. It's not the one we expect. It's not, you know, ourbank.com/login. It's the malicious webpage. So what happened there? So a very simple... This is all of the code that I used to steal a banking website login. This is a little confusing if you don't read JavaScript or know what it's doing. But the bolded line at the very bottom basically intercepted the request, so our browser said, you know, I want to go to mybank.com, the server sent back a response, and the attacker's computer said any links on the webpage, replace them with a link to a server that I control. That's it. So since the main page was using

HTTP, the attacker was able to modify it. Now he couldn't change the login page, it was using HTTPS, he couldn't sniff it, so instead, what he did was change the link The user logged into a page that looked exactly like their bank. He sent their login to their bank. They looked like they logged in just fine. But before that happened, he stole their login credentials. And now he's got the username and password for their banking account. Not so great. So, what is the benefits of data integrity? So code injection is a big one. That's what I just showed. So he changed a link on a webpage to a link that he controlled. They could also

do things like put some sort of malicious JavaScript, crypto miners, if you've heard about those, they're in the news a lot, they could make your computer mine Bitcoins for them or whatever else. There's also ad insertion. So imagine if you were at home visiting an HTTP website, Spectrum could actually put their own ads into any website you're viewing or anyone could Because again, there's no there's no data integrity anyone can put any ads they could control You know what ad you're seeing which is annoying but no big deal another huge one is this content modification which seems a little different but the next slide I'll Covered a bit more interestingly It could be something as harmless as changing all of the pictures on a website So, you know you're

trying to you know view a website of whatever houses someone could replace all of them with pictures of cats and you would not know why Because the websites are using HTTP people can modify the data and there's also some big scary attacks based on these above that I'll hopefully show live so content modification And I want to thank Patrick for sending me this. This is really cool. So this little white device is called a news tweak. You plug it in, and it will literally do that attack I just demonstrated about replacing stuff, only it will replace it on news websites. Now can you see the bigger issues? So say CNN.com was an HTTP website. I

could literally change the news that you're getting and make you believe different things, make you have different feelings, because I can change any of the data being sent back to your browser. You don't know that that's actually what's not on CNN.com. So the picture is fairly innocuous. They changed the word ceasefire to custard. What if I changed the word turkey to Israel? There's a lot bigger implications. Any website using HTTP, I could change the entire content of it. I don't have to steal your credentials. I can change what you're thinking, change what you're doing. And it's a really cool device. They sell it, it'll automatically do it. Yeah, I recommend taking a look at it.

So, I mentioned a big, scarier attack. And this is the more advanced part, so hopefully those of you who at least knew a bit about HTTPS will enjoy this part. And the crux of this demo, I'm gonna do an earlier name and shame. So the origin of this talk was Cackalackycon. Cackalackycon's website was using HTTP. No big deal. It was a static website. There was no forms. There was nothing sensitive. And no one was modifying any, you know, the dates or anything like that. That said, there's still some scary stuff that we can do as attackers. So, let's do it live and see what happens. Hopefully, things work well. So, we'll load up some VMs. We'll have our hacker and our innocuous little user.

And these slides will be posted, so if you're worrying about taking pictures or stuff like that, I'll have the videos and demonstration of this. So, we'll log in as our attacker. And since, you know, we're hackers, we'll just... And I'll cover what is happening in a second, but, you know, we're a hacker. We're gonna run some commands, there'll be some cool colors, it's terminal, we'll do stuff. No big deal. Alright. So, we are an internet user. This is high resolution, but we're gonna go read my old roommate's blog. He's just a software developer, just a static blog with a webpage. I'm gonna have to connect to the internet first. Let's see if I got that password right. Should've done that beforehand.

Oh, I got it right. Let's see if it connects. It's more fun if we use a real website on the internet. CTD has not been working on any of them. Steve, what's the password? Eversex CTF. Look at that, providing internet to speakers one talk at a time. And while we try and see if I can connect to the internet, I wanted to thank the-- so I mentioned we won the DerbyCon CTF. Not only did we win their CTF, they actually donated all of their networking gear to us for the Eversex CTF. So all right, so we're connected to the internet. So let's read a blog post. This stuff is hacking on the hacker's computer, we don't really care. Is there internet on the Eversec network? Jeff?

Steve? Alright, cool. So, we see it's HTTP. No lock, but just a blog post about an interview question he had at Microsoft. No big deal, we're not going to send any sensitive information. We don't care if someone modifies his malloc blog post. Whatever. No big deal. So, let's go back to our hacker computer. Some stuff happened with this green one, I'll cover that in a second. But this one is more interesting. So, this line right here, we see an IP address. That's actually the IP address of our user in the coffee shop or user at work, whatever. We've got a username. IE user is actually the user logged into the user browsing the blog website, as

well as some sort of big long hash string. So let's grab that and see what it is. So if we go to our slightly other hacker computer, 'cause I couldn't get it to work on the first one, and we put this in a file, we run a quick command, Some more hacker stuff will happen. So if you see right here, there's a new string at the end of the hash that says "password!" That's actually the password of the user browsing that blog website. What the heck happened? So, if we go back to our first hacker window, there's a bunch of commands happening and a bunch of output. But the first thing that the hacker did in this window was he intercepted all traffic on the network. All

of it went through him, then went on to the router. Okay. Additionally,

He had a script running that any time a web page had a body tag, so basically saying, "Hey, this web page is over," he replaced it with a picture. This picture was to, you know, a file that he was hosting called file.jpg. Well, we don't see a picture here. It's actually right there, but he could have hidden it better. But it's a broken picture. Why do we care? He was also running, and I can gladly speak to you plenty more about this, this attack is really cool, it's hard to demonstrate in a short talk. Over here he's running a program called Responder. So when the blog looked for this picture, which it didn't have, it's not hosted in my roommate's blog, we injected it with that first window.

It said, "Hey, I want this image.ping." It reached out, the hacker's computer was where it was looking, it said, "Hey, do you have image.ping?" And it was like, "Yeah." But also, since you're using Internet Explorer, and I do want to note that this attack will only work against Internet Explorer, it can work against Edge, it's weird, but it will not work against Chrome or Firefox, but since he was using Internet Explorer, Internet Explorer was like, "Hey, I'm on Windows. That file's on the local network. You can have my credentials just in case you need them." And the server was like, "Well, thanks. I don't need them. Here's the image." So since it sent us their

credentials, we were able to receive them, which is what this big long string is. Now this is a big long string, it is very hard to crack it. That said, we saw the user had a pretty weak password of "password with an exclamation mark". So just by visiting an HTTP website, not sending any information, not, you know, being tricked into anything, we now have this user's username and password for their computer. Now we can do whatever we want. So that's the bigger, scarier issue. Just because you're not sending sensitive data doesn't mean you shouldn't be using HTTPS. So, what are the key takeaways? I didn't forget the theme. If you're not using HTTPS, you're contributing to the internet dumpster fire. Now everyone can finally take

your drink. So how do we fix it? The quickest and easiest way is to use something called Let's Encrypt. And Weldpon mentioned this even during his talk. It's free, it's fairly simple, and it's a way for everyone to get an SSL certificate. So there's instructions here, there's a website. If you google "Let's Encrypt", if you just bother me, I'll gladly talk to you about it. So this is--and it's harder to read, I don't want you to set it up right now-- but these are all of the steps. This is all you would need to do if you had a server you controlled and had command line access to. Now that said, Not everyone knows how to use a command line. Not everyone owns their server. This is still

kind of hard. If you're just, you know, a mom and pop running your store, you're just, you know, you have a personal travel blog, whatever. So, even easier option is... Get a hosting provider that just does HTTPS for you. There's a huge list on that same SERPA website I showed before, and I'll provide the link with the slides, that shows you all of these hosting providers that will enable HTTPS for you. You do nothing. You host your site under their server. For somewhere in the middle, there's also the option of something called Cloudflare. Cloudflare is a service that will basically stand between the internet and your website. They'll provide some security, they'll provide some DNS, DOS protections, other things, but the most relevant thing to this talk is they'll

literally set up SSL for you. And if I can find my cursor, there might be a video. It appears to have disappeared though. There we go. So this is just demonstrating how to use their website. So you type in your domain, you click add site, they'll do some stuff. You choose your plan, they have a free plan, so this doesn't cost you anything. You update some things that you would already have in your hosting provider, and it'll be set up. And that's it. You're done. You now have their SSL and their other protections. So if you have your own website, if you work in a company, if you see a website without HTTPS, try and

get someone to implement it. That said, there is a lot of steps. So I'd like to introduce the Tetra algorithm. acronym to help you remember how to implement HTTPS. So T: take ownership of your life. establish boundaries. tell someone that you love them. Remember to stay hydrated. And I: implement HTTPS. That's it. Follow those five steps and you'll have HTTPS on your websites. I understand even five letters is a little more complicated. So I've provided you with a flowchart. Does your website need HTTPS? Yes. We saw why. Implement it. Tell people to implement it. If your bank doesn't use HTTPS, and I know there are some, call them. Yell at them. Obviously that one's terrible, but there's no reason websites shouldn't be using HTTPS. So, time for a

quick shame session. So I called out CackalackyCon, but they are the reason I gave this talk. And they did fix it, like, two days after I yelled at them. So the left one is an exploit writing tutorial website. This is a security website not using HTTPS. The top right one, and I wish Dan was here, he would love this, this is irongeek.com. This is Adrian Crenshaw's website that hosts almost every conference talk. So he could have a link to the DerbyCon opening ceremonies, and I could put a pornographic video there instead, because he doesn't have data integrity. And the bottom right is Baidu. It's a huge search engine, so I can intercept the request and

put my own results into it. This shouldn't happen. We should all be using HTTPS. Like Chris said, security is here, it's just not everywhere. So, a few quick acknowledgements while I wrap up. I want to thank B-Sides RDU. They let me spout my nonsense up here every year. And the second part isn't true this year. There's no hacker jeopardy, but I heard some crazy guy will be shouting out questions in the CTF room and throwing prizes at people. Avalara, my new company, they pay me to hack, they pay me to talk about stuff like this. It's awesome. RTPsecbeers is a great group. It's a bunch of local people and some not so local. They helped me get the inspiration for this talk because people in the channel about CacalackyCon

were asking why they needed HTTPS for a static website. We saw we could have stolen their username and passwords. And EverSecCTF/teameversec. The most recent CTF they've hosted is... we've hosted is Upstairs. Most recent one we've won is DerbyCon. If you want to learn about running CTFs, participating in them, you just want to bring us food and drinks, come on up. And you guys, if one person learned one thing from this talk, I'm happy. So, I don't know how much time we have left, but does anyone have any questions? I can maybe answer some of them. Yes, so the question or comment was, bad guys can also use Let's Encrypt to make malicious sites. And that's exactly true. So... And I meant to cover this a bit more, so

HTTPS doesn't save us from everything, it doesn't secure everything. I can stand up a bad website using Let's Encrypt, and we saw that. The malicious webpage that we stole credentials with, it had a certificate, it seemed fine. So just because something is using HTTPS doesn't mean it is secure. But just because a site is not using HTTPS, we know it's not secure. Yeah, awesome comment, thanks for bringing that up. Anyone else? So that's it. You can find me on Twitter. You can find my blog. You can find me upstairs. Thanks for coming. Baby, slow down. The end is not as fun as the start. Please stay a chat somewhere. Give it what you want. Accept

the thing that you want. You are the first one.

Some people get way too much confidence, baby. ♪ I'll give you everything you want ♪ ♪ Except the thing that you want ♪ ♪ You are the first one ♪ ♪ Yes, dear, I want you so much ♪ ♪ I'm a lot of what you got ♪ ♪ And I want nothing that you're not ♪ ♪ Oh, you're shy, you don't have to be shy ♪ ♪ Yes, I'm a little bit shy ♪

Well... Welcome back. Quick reminder, the raffle tickets. We got the stuff starting to get set up at the registration table. So pull one half. There's a bunch of different items that you can choose to bid on. Must be present at the closing to win it. Also go talk to the sponsors because some of the sponsors have some too. So if you talk nicely to them, you might get a couple of freebies out of it. And up next, we have Jeff Mann. respected information security expert, advisor, evangelist, co-host on Pulse Security Weekly, tribe of hackers, and currently serving in consulting and advisory role for online business system. Jeff has too many titles. Over 37 years of experience working in

all aspects of computer network and information security including cryptography, risk management, vulnerability analysis, compliance assessment, forensic analysis, and penetration testing. If you're playing buzzword bingo, you probably just won. Certified NSA cryptanalyst. What was that? Cryptanalyst, yes. I'm going too fast. previously held security research management and product development roles with the NSA and the DoD private sector enterprises and was part of the first penetration testing red team at the NSA. For the past 20 years he's been a pen tester, security architect, consultant, QSA and PCI SME providing consulting and drink providing consulting and advisory services to many of the nation's best known companies. And even though I know you have one of these, you now have a spare so that

you can carry two of your finest selections with you. My question is, is it full? Later. So without further ado, please give a warm welcome for Mr. Jeff Mann. Thanks, Jeremy. That's pretty much all we have time for, so I guess it's lunchtime. So... The title of the talk is More Tales from the Crypt Analyst. Several years ago, I was at a conference, and I can show you my info while I'm telling you this story. I was at a conference, I met another speaker, and at some point I asked him what he was talking about. He said, oh, I'm going to do a talk on intro to cryptography. I was like, oh, that's kind of cool. Cryptography is kind of a thing I'm into.

So I went to his talk the next day, and... As I'm listening to him do this basic overview of cryptography 101, I thought, wow, I could give a talk like this. I lived this. So a couple years ago at GURCON, I premiered a talk called Tales from the Cryptanalyst, which was basically the story of the first several years of my time at NSA, my tenure at NSA. And I always promised a sequel, which is essentially the essence of this talk today. Real quickly just to get the acknowledgments out of the way. I work for a consultant company called online business systems. We're mostly a consultancy advisory company. We do a lot of the pen testing type of stuff and we do PCI work as well as other compliance. But

before your eyes roll back in your head, what we really try to do is as experts, we come in and try to help companies figure out how to do security, do it right for them, do it the way that gets them to a place where they can be compliant and get the regulators off their backs. But more importantly, just become more secure. My background very briefly, which Jeremy sort of stole my thunder, but that's okay. I'm not bitter or anything. I've been in the business a long time, sort of from the beginning, if you will. I spent my formative years working for the DoD, primarily with NSA, and left the NSA about 23 years ago. Why, you're going to hear today in basically the

crux of this presentation. I've been out in the private sector trying to make the world a better place one company at a time, trying to help them be secure. Somewhere along the line I fell into PCI, but I actually kind of like PCI because when I was first introduced to PCI, the data security standard, it was presented to me as this is a framework or this is a measuring stick for how organizations should be doing security at their companies with an emphasis on a particular type of data. And I read it and I said, "Yeah, this makes sense. "This is kind of what I've learned over the years "from the DoD, let's go do it."

That's another story for another day. So the crux of this story today is I had basically three tours of duty at NSA. And I'll get into the details of that, but the third tour of duty, as Jeremy alluded to, is when I got into pen testing and started doing that for NSA. We didn't call it red teaming back then. And that's sort of the gist of this story today. So sit back, relax. If your stomach's grumbling, lunch is afterwards. But hopefully we will be entertained over the next hour or so. I first want to apologize. As I was first putting this talk together and trying to think about what we did 20-some, 25-some odd years ago in terms of pen testing and what did the internet look

like, what did the world look like, I discovered that trying to find entertaining screenshots for this talk was a little bit daunting. So apologies in advance. I think I did a pretty decent job, but certainly what we had available then and actually trying to find it and bring it forward to the future was a little bit daunting. I also want to make this talk a little bit audience participatory. So there's going to be times through the presentation where dates will pop up, and the challenge to you is to try to answer what is the significance, what is the meaning, what is important about the date. It's a little bit of history. It's a little bit

of putting things in terms of a context and a timeline of what existed and what didn't during the time in particular when I was at NSA starting to do pen testing. So let's start off with an exercise. In fact, I have two. This one is my special Raleigh-Durham edition of this test. Anybody have any idea what this date's about? I'm not going to give you much time to guess because I've got a lot of slides to cover. Give up? This is the original release date of probably arguably the best baseball movie ever made, Bull Durham. And actually a movie that years later still gives us a very important lesson, which I used to use all the time, still do. Don't think,

just pitch. One more date. Anybody else? Anybody? Three, two, one.

Okay, so you get the idea. Actually, I've done this talk for audiences that have no idea what Skynet actually is, which is a little bit disturbing. So I apologize in advance. If I do movie references or things like that, they might be a little bit dated. If you're a younger audience, actually out of curiosity, how many people, raise your hand, are let's say 37 years old or younger? Okay, I've been doing this your entire life. Just to put that in context. And yes, that does make me feel old. Another little wrinkle that I've added to this talk in the last couple months is to try to put an emphasis on mental health hacking. We've had

a lot of issues within our community of people getting burned out and people going to extreme lengths to try to end the pain. So I want to, as I'm telling the story of what I was doing many years ago trying to become a hacker and pen tester and things like that. I want to overlay that with the fact that I had a real life. So I'm going to bore you with a bunch of family photos. But the emphasis is don't forget, whatever your passion is, whatever you're doing for your day job or your interests, don't forget to step away from it and actually have a life, whatever that may be. So I will bore you

with some family photos. So anyway, getting into it. I was at NSA approximately 10 years from 1986 to 1996. During that time I did several different things, but boils down to primarily cryptography and I actually worked at the time there was two sides to NSA what we loosely called offense and defense. The offense is what most people think of when they think of NSA. It's communications intelligence, signals intelligence, intercepting the communications of our adversaries and other countries and nation states. I worked on that side of the house breaking codes, breaking ciphers. I was also on the defensive side, which is what we called InfoSec at the time, actually designing and creating secure codes and ciphers. And then later on,

obviously got into the pen testing thing. I mentioned there's an original version one of this talk, Tales from the Cryptanalysts, where I go into more detail of sort of the early years and things I did. But I do want to highlight a few of the things that I did there as they apply to sort of the formative things, events that occurred in my career at NSA which helped me to realize that I was actually a hacker. I actually believe you're a kind of a hacker from birth because to me hacking is sort of a state of mind. It's a way of viewing things and for better or for worse I view the world differently than

most. So very early experience at NSA. I was working for the manual crypto system shop. We were responsible for putting out all the paper cipher systems, primarily one-time pads, mostly for the armed forces. I had a customer approach me very early on and say, it takes us hours to do the one-time pad decryption, but there's this thing on our desk called a PC. Is there any way we could use that to speed up the process? And I thought, well, yeah, that's something that we could do. That seems reasonable. So to make a long story short, Produce, what I am still to this day, I believe, is the first software-based encryption product that NSA produced. And

all it did was take a one-time pad and on one end it was paper, on the other end it was a floppy disk. And we wrote a program that would run on the computer that would do the encryption and decryption a page at a time, securely delete that page and move forward. I had to go through, and this is where it kind of gets into the methodologies and sort of thinking about pen testing. I had to go through a compliance process, if you will, or an SDLC process. It was called FSRS in those days, Functional Security Requirements Specification. These specifications were written for hardware. Back in those days, there was no such thing as software-based cryptography or online digital or anything like

that. It was all basically radios and things that would attach to radios that would convert Signals voices to Possibly like Morse code and things like that But it was not digital in any way shape or form at least the way we think of it today So I had to take hardware specs and try to follow them but make them applicable to What we were doing which was software-based so I basically had to hack the requirement specifications and This did not go over terribly well. I had to go through a review process and basically sit in front of the board of directors, if you will, you know, the equivalent C-level type of people that were running the entire InfoSec side of the house. And they begrudgingly had to

acknowledge that I met the requirements the way they were written. At least they couldn't talk me out of it or they couldn't find an argument not to go forward. So they granted me the permission to publish, you know, produce this software-based system. But the last thing that the senior head guy said to me was, don't do this again. Another fun thing I did which was for another customer, again using one-time pads, happened to be US Special Forces. They used a particular one-time pad that as their algorithm, if you will, they used something called a visionaire table which is a slide of the alphabet, 26 different offsets, but using a reverse alphabet in the body of the table. This produces 123 unique three-letter combinations,

three-letter tri-gash we call them. So think of it plain text, key, and cipher in any order. You got two letters, there's always a unique third letter. So that enabled the encryption process with a one-time pad. They memorized it, I didn't. As a crux for me, I had just gone through an intro to crypto class, learned about a cipher wheel, and I thought there must be a way to do a cipher wheel with this visionaire table. So I came up with this wheel. They liked it so much they stole it from me every time I made one. So I ended up asking, "Would you like us to make these things?" So we produced like 15,000 of

these wheels. and they were used by special forces, as far as I can tell, well, as long as they used paper one-time pads, but at least 10, 12 years, up to maybe around the 2000s. Earlier this year somebody approached me and said, "Have you ever heard of the Diana cipher wheel?" And they showed me this picture. Some artist somewhere, a craftsman, has produced wooden versions of this cipher wheel and is selling them online. I don't know if you can see the link there, but if you Google Diana crypto system, you should come up with this. This is on Etsy, you can buy these things. I got in touch with the guy that made them because

I said the guy that showed it to me is like not only am I familiar with it, I'm the inventor of it. So I got in touch with the guy that built them, he was very excited. He actually sent me a bunch of his wooden crypto devices. So there's two sizes of the cipher wheel. The thing in the middle is a wooden version of the Enigma machine. And the one on the bottom is, I forget what country it is, but it's like Polish or Italian or something. But it's another really cool cipher wheel. So if you want some cool paraphernalia, check that out. This is actually, I found online, a picture of an actual production

version of the cipher wheel. I've got the two prototypes that we produced, and I have one with me. I always show it off. If you want to see it, find me later. Anyway, I was doing these things and my boss at the time referred to me as a loose cannon and I kind of took that as a badge of honor. I don't know if he meant that in a positive way or not, but I kind of took that as, yeah, I'm a loose cannon. I'm going to try to figure out a way to get things done and do things regardless of what the rules are. Hacker mentality. Very briefly, my second tenure, my second tour

at NSA was I became a cryptanalysis intern and I went over to the operations side of the house. I happened to be there during the first skirmish in the desert, Desert Shield, Desert Storms. I got to work a bunch of midnight hours and I got a certificate for it in like a small cash board, which was really cool when I was newlywed. I was down the road. I had originally started at a satellite location and I went to the main campus. So if you've ever seen the aerial photos of NSA, those mysterious black buildings, I was somewhere in there. And ultimately being an intern enabled me to get a certification as a cryptanalyst. It's really the only certification I hold. It's the only one I really care about. But

again, that's another story. Certifications. So, chapter three, which is the crux of this talk today, is what I did during what started out as my last tour of duty as an intern. I was back on the InfoSec side of the house, and I went to work for what was called the Fielded Systems Evaluation Division. In that division, the reason it existed was somebody within NSA had figured out that the way that we, NSA, very often exploited the communications and crypto of other countries and our adversaries was we took advantage of basically the systems were misused. operators would find shortcuts to bypass the crypto. They would use key that was intended to be used one time and for whatever reason to save paper or

something, they'd use it for a month. When you misuse cryptography and use it in ways other than it was intended to be designed, inevitably, very often you introduce vulnerabilities that become exploitable and that's where the cryptanalysis kicks in. So, Somebody had the idea well gee NSA at the time was the producer of all the crypto for all of the US the military the government the DoD State Department and all that we produce the best crypto in the world we we test everything we get everything certified and approved we do all our certification and testing on the inside and But how do we know that people that are out in the field using it are actually using it the way we intended it? It looks good on

the blackboard or whiteboard, but how do we know we're using it in the field? So we had this whole office that was dedicated to going out into the field and actually meeting our customers and observing and watching how they used it to see if they were doing things that would bypass the crypto or inadvertently introduce vulnerabilities. I thought it was a great idea at the time. I was actually assigned to look at this one particular device. It was called, every crypto device has a code name. This one was called Parkhill. This one was taking an audio analog phone voice signal converting it to digital, encrypting it, the digital portion, taking the digital stream, converting it back to analog so it could be sent over whatever channel,

whatever frequency, and the process was reversed. If you used it and you were able to actually make out what the people were saying on the other end, it sounded a lot like a very choppy Donald Duck. It wasn't perfect, but it was revolutionary at the time. So I was assigned to look at it and evaluate it. But then this happened. Here's a date. Anybody know what happened on this date? This is why we're all here today. Well, more specifically, it was the release date of the first sort of publicly available web browser called Mosaic. Anybody remember Mosaic? It really literally changed the world. It was revolutionary. It's what first made the Internet sort of publicly available to the masses. And

of course, there had been hackers and bad guys and people doing things on the Internet for many years, but it wasn't really open and out there and people weren't aware of it. But thanks to popular movies, the awareness of it became a thing. I was in a branch or a group within this field of systems evaluation division that was focused on what we called at the time network systems. So, you know, we were there, we were looking at mostly mainframes that were connecting to each other with workstations or dumb terminals, I guess in those days. workstations were all Unix based, usually they were Sun or Solaris, and everything was sort of networked, it was all Unix. In fact,

in the early days, it wasn't really cyber security, it had a lot to do with Unix and internet security. Here's one of those sidebars. While I was doing all this, and it was really convenient because working for an organization like NSA, it was literally a nine to five job because we were a classified entity. We couldn't take our work home with them, which made it convenient to leave things at work. But I was getting married, raising a family, having kids. But back at the day job, there was a small group of us that were working in this network systems group, and we started learning about the web, and we were going on to Mosaic and searching and finding out all these cool things, and

we were having this thought. It was a similar time frame to what Chris had talked about during his keynote this morning. This was sort of early to mid-'90s. But we're like, hey, you know, we should try to figure out how to break into things and do it hacker style, do it the way we've seen it in the movies. One of our main inspirations, anybody's heard of this book, The Cuckoo's Egg? I mean, this actually, this is Clifford Stahl that was, is, I believe he's an astronomer by training. works at a university. Back in those days when you were getting on the computer, which was a mainframe to do whatever work you were doing, you had

to pay for your time. He was reviewing the bill, the monthly bill he got one time and noticed a discrepancy and that led to him discovering that the university mainframes, which were doing a lot of government work, had been compromised by East German hackers, you know, Iron Curtain, Soviet Union. All sorts of cool stuff. And they made a movie about it, and it was premiered on a show called Nova. I don't know if anybody remembers Nova. I don't know if it's still on or not, but educational television back in the day. But this kind of stuff was like, wow, we've got to figure out how to do this. We've got to figure out how systems

can be secured by breaking into them. It was kind of cool. It was kind of fun. It was kind of edgy. And more on that later. I actually had the privilege earlier this year of meeting Cliff Stahl, which was kind of cool. And we were at a conference up in Canada. So there's going to be several of these things. I've had a fun year meeting all of my heroes from back in the day. But anyway... What the government likes to do when they come up with an idea of seeing something new and we were kind of doing things sort of at the worker bee ranks but the management was thinking lofty and higher so they

reorganized and they formed this thing called the Systems and Network Attack Center. So the small group of us that had been starting to tinker with learning how to break into primarily UNIX systems, how to hack systems, we got pulled into this group And we actually were put into a division. Everything at NSA is letters and numbers. So we were put into an office called C4, which we thought was kind of cool. This was designed to be a center of excellence. It was one of the first centers of excellence that NSA produced. So there was, it was done by the management, the suits we like to call them. And so it was a very intellectual, very

research oriented type of organization. And we were put in it, but we were trying to be different. We were trying to be edgy. We were trying to be hackers and sort of live and think that mentality and come up with a pen testing methodology. So we sort of formally pulled together and started a team. The deputy director at the time, again, he had this sort of naive vision. He thought, all we need is a bunch of these long-haired, young, you know, weird type of people together, and if we get them together, we'll just rule the world and we'll be the best that there is. And we tried to educate them that there's a few thousand

of these types of people out there and no subgroup would ever be able to compete against the masses that were available out there. But it got us reorganized. They put us into an office. So we were together. And one of the first things we tried to do, now that we sort of had an organization and budget and a mission, was we wanted to learn. So at the time... The organization that was sort of leading, at least within the DoD, was the Air Force. The Air Force, for whatever reason, sort of owned the internet for the military. They were basically the sysadmins for the entire internet presence, networking presence for the DoD. So they set up the first network operations center, which led to shortly thereafter the first security operations

center, and this was all based down in San Antonio, Texas. They had an organization at the time that was called the Air Force Information Warfare Center. So we knew them to be sort of the elite and the premier. They were leading edge and so we took a trip. We wanted to go learn from them. So we took a trip to San Antonio. We met a couple guys there, these two captains. On the left is Captain Zeiss. He unfortunately passed away about two years ago. And on the right, Captain Waddell. These guys, you know, again, leading edge, they and a bunch of their cohorts left the Air Force. They went on to start a company called

Wheel Grip, which was, I believe, more or less credited as being the first commercial security vendor company out there. And like many security companies that were leading edge at that time, they very quickly got snatched up by some larger company. They actually were acquired by Cisco. Whenever I meet somebody from Cisco as an aside, I ask them, why are you here? Cisco is not a security company. They've been trying to be a security company for a very long time. Anyway, not to dig on Cisco. So San Antonio. Has anybody ever been to San Antonio? Wonderful place. At the time, they had an Air Force museum with a lot of planes. Anybody know what plane this

is? Recently declassified when we got down there, so this was the first time we had seen this plane. And this, anyone this one? ATEM Warthog, this was what kind of won that skirmish in the desert. And of course, we had the usual sightseeing stuff, including the river walk and, of course, the 46-ounce margarita. Only have one of them. I was in San Antonio. We were on the Riverwalk. We had just had some big, huge steak dinner and then drinking the 46-ounce margarita, and I called home to talk to my wife, and she's like, you know, how are you doing? And I said, oh, I just had a steak, and I had this margarita. And she's like, great. I'm home with the four kids, and we just

split a can of tuna fish. So it was very important in my off time to make sure I took care of the family and take them on vacation. So we did a lot of vacationing as an aside, hacker mental health. Our biggest takeaway from the Air Force visit was two things. One was these guys were smart, but they weren't any smarter than us. We were sort of on the same page in terms of learning about attack methodologies and what kind of exploits were out there in the wild and sort of the way you did things back then. But what was significant to us was their physical office structure. What do they call that? Feng shui?

Something like that? They had instead of regular old cubicles stacked up, they pushed everything to the corners and they literally had a round table in the middle of their office and the way that they set it up was, you know, everybody's doing their own thing but if anybody had a problem that they wanted to sort of collaborate with, they'd call round table and everybody would turn and come to the middle. And we thought that was really cool. So we emulated that. Of course, we had to have our own space to do that. And we set ourselves up in an office. We had the whole round table scenario. We were trying to live the hacker mentality,

the hacker culture. So we nicknamed our office and we called it the pit. The pit was an office that existed in an NSA facility that was just west of BWI Airport. And the pit was actually in this building here in the corner. I think it was in the second or third floor. The reason I bring this up is because several years ago a book came out called Dark Territory, the Secret History of the Cyber War. In the fourth chapter, which is entitled Eligible Receiver, there's the following paragraph, which I like to do a dramatic reading. I'm going to do it like this because I can't read that small print. In the middle there, during its

most sensitive drills, the red team worked out of a chamber called the pit. Which was so secret that few people at NSA knew it existed and even they couldn't enter without first passing through two combination locked doors. So, our office was the pit. Somehow it got evolved into folklore. We didn't have double locked doors. We were just an office. We were an office with cubicles and a round table in the middle of the room. But somehow that transcended. One of the members of the pit, one of the people I used to work with, bought the book, read this. They took a picture of the paragraph and sent it out to all of us. Like, we're famous, we're famous, we're in a book. So the pit really at the end

of the day was six people. There were six guys that were working together trying to learn how to do hacking, ethical hacking, penetration testing. We actually at the time called it vulnerability and threat assessment. So we tried to develop a methodology. They didn't exist back then. There were no SANS courses. There was no certified ethical hacker, none of it. We were just kind of shooting from the hip trying to come up with things. Of course, we were doing this at NSA and that immediately caused several issues because A, it was something different and NSA at the end of the day and still to this day to my knowledge is a pretty conservative organization. It's also a bureaucracy. It is at the end of the day government and things typically

don't move very quickly within government. You know, Chris mentioned how long he's been trying to get his company through the FedRAMP program. It's not efficient if you're into speed and we were trying to live the hacker culture which moves fairly quickly. So that caused conflict, let's just say. The biggest conflict is we wanted to break into things but to get authorization to do this thing that was kind of different and weird and also by the way was sort of against the charter of NSA which basically if I can sum it up because it's still I think a classified document. NSA is only supposed to do what NSA does to foreign nationals, to other countries, other citizens. NSA is not allowed to do what NSA does to U.S. citizens. and

a whole other talk and discussion that we could have about Snowden and all that kind of stuff. But that's sort of the genesis of it is NSA is not supposed to do that. But we can do it if we follow rules and the rules would take weeks to get done where all we wanted to do was break into something and we knew it could only take a couple seconds.

We came up with a methodology. I think the methodology hasn't changed a whole lot because there's a way that you try to break into things. You first do some sort of recon-essence. We called it recon. These days it's called open source intelligence. But you have to learn about your target. And once you learn about your target, you try to zone in and try to find the weak spots. And you try to find the weak spots in various ways. And once you find the weak spots, you try to exploit them. So on and so forth. To try to help put this in context, because I go to a lot of these conferences and I hear lots

about pen testing and how it's done these days, and I think, again, even Chris referred to the amount of automation that's out there these days, I want to just remind you of what we did not have available to us when we were discovering all this. So this is just, this is not a concise list. This is not a comprehensive list, but this is just to give you some examples. We were doing it manually primarily. There were some rudimentary tools here and there that became available. I'll share some of you. But the stuff that we take for granted as pen testers these days more or less just did not exist. By the way, I tried to

get together with my family on holidays, and we would do fun things like go to the pumpkin patch and all that kind of stuff. I'd dress up as Santa. Now I do Santa very well. Anyway, I told you about what we didn't have. I want to share a little bit about what we did have. And again, it was all manual, and we were sort of making it up as we went along. I want to give you a disclaimer now. The way the rules were at the time, any time we targeted a system, and very often the system was a network, Everything we did had to be classified at the level of the target So if we were going after a top secret network or a top secret server

or top secret system Everything we had to do was top secret and since we were NSA and we're our charter was to take care of and monitor and inspect and secure the classified networks very often everything we were doing was classified with which to my knowledge hasn't been unclassified. So what I will say to you is I'm not saying we were using any of this stuff I'm about to share with you. I'm going to say that this was stuff that was commonly available at the time. Nudge, nudge, wink, wink. I did this at a conference in Baltimore, B-Sides, Charm, and somebody like interrupted me and was like, I work there, you can't do this, stop,

stop. And I'm like, it's a joke, it's a joke. So disclaimer, this is a joke. We had network sniffers. They were hardware. They weighed 20 or 30 pounds and we'd wheel them around on carts and we would plug them into the network devices and we would do what was called sniffing the network. Nowadays you have Wireshark and things like that. We had the rudimentary beginnings of a vulnerability scanning tool. One of the first ones out there that was publicly available as open source was a program called SATAN. You can see what it stands for. Again, I had the pleasure, I think it was last November, since I'm involved with Security Weekly, we were able to arrange to have the developers of Satan on the air

for an interview. A very special moment. We got to talk to Vitsa Venema and Dan Farmer. So, fanboy moment for me. And I'll say this in terms of a fanboy as an aside. These guys are in it for the passion of the craft. They try to help people have more secure networks. They had an opportunity very early on to commercialize and make people pay for their product and they opted to keep it open sourced. Not to make a value judgment, but I've always thought that was kind of cool that they just didn't see the dollar signs and run for it like a certain other person did that came out with a contemporary vulnerability scanning tool.

Which is not to disparage that person, and I won't say who it is, but you make your life choices. I'm just going to suggest that the outcome isn't always money that makes for a satisfying career in however we define success. Sometimes doing the right thing and educating and helping people be a little bit better off can be pretty darn satisfying too. Another day. One, two, three. Nobody's going to get any of these. This is when something called BugTrack came out. Anybody ever hear of BugTrack? Remember BugTrack? Is it still around? I don't do this stuff actively anymore. BugTrack was at the time one of the primary sources of vulnerability information. If you're working on a system or a particular application or operating system and you wanted

to learn about what people knew about it in terms of its operation, particularly vulnerabilities, people would write into this email mailing list and it became an archive and you could respond. It's an old fashioned way of communicating which is only 25 years old. It was a primary resource for us. We used to go to the pool and I used to have hair. So this is an example of what BugTrack looks like. And again, it was an email format. People would write a question and then people would respond to it. And BugTrack had the ability to just sort of thread everything together. So it didn't work perfectly, but if you had a topic, it had the ability to help you find who's

talking about it and what they were saying. One of the other things we had as a primary source of information was advisories that were published by the Computer Emergency Response Team. This was tracking real world hacker activity. Look out, there's bad guys doing something somewhere. If anybody can read the small print on that, check the date and check what the vulnerability is about. This was a real advisory that they put out about alien operating systems being vulnerable to a virus. They had a sense of humor back then. Some samples of OSINT, again we called it more reconnaissance back then. They were basically databases, most of the internet back in them were databases that had some sort of rudimentary search engine built into it. There was

FAQs that were available. There wasn't much to go on. Archie was one of the search engines that could look up mostly university-connected databases to see what information is out there. The Intranet was a way to look up domain registrations, who owned what and what address space. Gopher is another search engine. Before Google, there was this kick-ass search engine called AltaVista. Anybody remember AltaVista? Anybody still think it's better than... Netscape came along as a browser. As more people put more things on the internet, things became more browser-friendly. And then the original browser, Yahoo, not the one that exists today, but the original. Anybody remember the original Yahoo browser? So old. We would try to acquire targets. Back in those days, everything was internet routable. The

private addressing wasn't really a thing. If you wanted to be on the internet, you had an IP address and you had to register your network segment. They were categorized in domains and so on and so forth. But if you found a target, you wanted to do a port scan. The port scanner that we had available to us at the time was something called Stroke. Interesting trivia note about this thing called strobe which I didn't realize until I was putting the talk together because I was trying to look up when things came out anybody have any idea who wrote strobe Julian Assange when I saw that I was like that's why I recognize the guy's name

totally forgotten it I hadn't looked at strobe in 20 20 years brownie points for getting the answer right somebody get him a beer You'd have to look up. You had a target. You'd look up what their registration was, what their domains were, what their addressing space was. You'd use NS Lookup, and you could look up the targeted account, IP addresses or the network segments and you get all sorts of fun information like the name of the administrator that set up the account and you could usually figure out what his user ID was and then you know surprise surprise guessing passwords back in those days were was a thing but that's been solved now so passwords have moved on we had tools that would actually do of the networks

to figure out the topology, and it would actually do a little bit of sort of what we call traffic analysis. Look who's talking to who, and look who's talking to what. And back in those days, there was this concept of client-server, where the server was running the application, and the clients would just attach with sort of an interface. So the server is what you wanted to go after, typically. That's where the perceived crown jewels were, the juicy targets. You could figure that out with network mapping. Another date. Anyone? This is when a password cracking program came out that was cleverly entitled Cracked. uh again back in those days uh to get the passwords you all only had

to go to the password file etsy password this is an actual snapshot of an actual password file not from the nsa days because that would have been classified but this is one that i pulled shortly thereafter so you've got the user id you got a colon you've got this weird string which is the hash of the passwords this used to be world readable by anybody on the system. So you could just go grab it, run crack, pop, and recover password after password after password. Again, passwords have been solved now. So that's not a problem anymore. Back in those days, Basically, the methodology was to get anywhere on any system within the network, and once you had some sort of user access level, because these were all pretty much

Unix systems, the next goal was to get root. If you got root, it was game over. It's the equivalent to getting the domain admin access these days in the Windows world. A very common technique for elevating your privileges to root was finding programs that were running on the system with what was called set UID or set UID zero. What that basically meant was the program was running as if it was running on the root account. And if you could halt the interruption of that thing, very often it would dump out into a shell but retain the characteristics of what it was running as. So very often you would dump out into a root shell. So

find a program running set UID, figure out how to break it or halt its operation, make it choke somehow, and very often it would just dump out into a root shell. You had root and you did the root dance and you were done. So I mentioned... So that's some of the tradecraft back to what we were trying to do I mentioned that We had some growing pains. We had some problems and and one of the key problems was this thing as I sent mentioned earlier the NSA charter Which I can't show to you because it's still classified But again essentially the essence of it is NSA doesn't do what NSA does to US citizens another date anyone

Anybody know about PGP? So, uh, I have a story to tell about this, but in the interest of time, I will skip it. Ask me about my NSA PGP story if you see me somewhere out today or this evening, especially if you put a drink in my hand. I'd be happy to tell you the story. Another fun fan moment for me is I got to meet the actual Phil Zimmerman last fall. He's a real geek. I mean, among geeks, he's a real geek. But it was really cool to meet him. So we had this issue of we weren't supposed to be doing things that, you know, to citizens and we were trying to do this ethical hacking, breaking in first before

the bad guys did. I want to share with you one reveal of one top secret thing that we did. So this doesn't leave the room. You don't really have to pause the video. But here's one of our primary attack tools back in the day. I'm going to let that sing in a minute. It's funny. The ping command. We had our lawyers, our general counsel, rule on the ping command and say their interpretation was because the ping command elicits a response from the target, we have to therefore classify it as an attack tool, therefore it has to be considered classified. So, quite literally, before we could issue a ping command, we would have to go through the weeks-long process of getting 10, 15, 20 signatures from all sorts of various

levels of management, half of which didn't even know who we were or what we were doing. It could take weeks, if not months, to wait to issue a ping command. Now, grant you, we never really waited to issue the ping command. But at some point we had to wait for the paperwork to catch up to us. This wasn't going to work. This wasn't going to work in terms of building any kind of reasonable methodology that we could go out and do this thing, this ethical hacking, this pen testing, what we called a vulnerability threat assessment to any of our customers, which was primarily the DOD, the military, state department, anybody running a classified network. So

we had to engage with the lawyers. For whatever reason, I thought, I can do this. I have a brother that's a lawyer. I felt like I could speak their language, so I sort of volunteered to take on the assignment of trying to educate the lawyers and work with them on figuring out a way to sort of streamline this process because it's ridiculous to have to wait six weeks to issue a ping command. So, the original idea was, the lawyer said, "Well, why don't you just show us all your different attacks and we'll sort of pre-approve them so when you have an assignment or you have a new job, you'll just sort of fill out an

a la carte menu. We're going to do a couple of pings here, we're going to couple this over here." And they'd be like, "Oh yeah, we know what that is. We approve it and we'll streamline the process." And I tried to explain to them, well, that doesn't really work because we don't often know what we're going to encounter until we start doing the reconnaissance or the open source intelligence gathering. We don't know what we're up against. We don't know what the potential weaknesses are that we might want to exploit until we start doing the job. So I tried to emphasize to them that we needed to think more about the methodology and the process and

not so much focus on the tools and the techniques. So we embarked on what I called at the time a weekly meeting with the general counsel to teach them hacking techniques, to teach them the methodology, to just show them how it worked. And I called it tool time because there was this popular show on at the time called Home Improvement where the show within the show was tool time. And again... I also found time to spend time with the family because it was important to take time off so we would go on field trips and go on outings. And I did get to know my kids and I think they mostly liked me even though

they're adults these days. But meanwhile, back at the day job, we started doing this. It was new. It was different. People were connecting to the internet in all sorts of new and different ways. So we became popular. We were doing our thing within our little world, the DoD military classified world. But somehow word got out. And this will be a very abbreviated story. But... Somehow the Department of Justice got wind that NSA had this group of people that were doing this ethical hacking, pen testing type of thing, and they said, we want you to do that to us. Well, at the time, NSA was doing what it did to classified networks. The organization that was responsible for the unclassified networks of the government was an organization called NIST.

You've all heard of NIST. It was also well understood at the time that And I will disavow this if you share with people, but NIST was very generally understood to not have much in the way of capability at the time, so they would often defer to us anyway. So again, there was this bureaucratic, political, red tape process that we had to go through. And so... We were approached by the DOJ, we want you to do this. I had to go to the lawyers and say, how do we make this happen, and launch this months-long process where basically what it boiled down to was it was sort of a handshake, sorry for the sexist language, gentleman's

agreement between cabinet member positions within the government. So the secretary, gosh, what do they call them, the attorney general for the DOJ had to talk to the person in charge of the DOD, which was designated to the deputy director that was responsible for all this internet type stuff. But they had to request, "Hey, can you have NSA do this for us?" So back and forth at this high level, I was responsible for writing a lot of the letters and other people would do that, like the lawyers, get all the language right and then it would go for the signatures. But this letter actually came in signed by the Attorney General at the time, Janet Reno, asking for the help. And the response was eventually published, signed by the Director

of NSA at the time. You can see I'm actually named in it as the point of contact. We were going to do a security assessment of vulnerability and threat assessment of the DOJ. And before this letter could be sent, this happened. This was the first... compromise the first hack of a government website. And back then, it was all website hacking. And so whoever did it, I'd still like to meet them to this day because we never figured out who it was, but I suspect that I've probably met them at some point. But they came in and defaced the NSA website. You could scroll down. You can find this on the Internet Archives, Hacker Archives. Just

Google the DOJ hack. You scroll down and you get into some NSFW stuff. I'm not going to put it up here. To make a long story short, it was hacked. We figured out a way to go down. So I took the first forensics team that NSA had and, of course, We didn't know what we were doing. Nobody did at the time. The DOJ had what most people had in those days, a web server that was running on one of their own servers in their own DMZ. There was no co-hosting or cloud or anything like that. And as soon as they discovered that they'd been hacked, they pulled the plug, wiped the whole system, and rebuilt

it with an operating system, thus wiping out whatever forensic evidence there might have been.

Whole nother topic, but essentially we were doing something that somebody in the political position got wind of, and we were down there for, I had led a team to go down there, we were down there for two, three days when I got a phone call from somebody in the pit saying, the shit's hit the fan, drop what you're doing and come back. We came back, we got... into the conference room for the deputy director of information security. So we were in the big panel building with the big long table. And the lawyer that I'd been working with came in and proceeded to read us the riot act that we had done some gravely illegal thing.

Don't you know about the NSA charter? Don't you know about the church proceedings? I'm not going to go into that. But the second time I ever heard about the church proceedings was Snowden. I I give a talk where I go into detail on this that I have entitled, I Was the First Edward Snowden. Again, put a drink in my hand. I'll tell you the story later. The upshot was we got into a lot of trouble because I was the ringleader. Everything kind of fell on me because somebody's got to be the scapegoat. But in a positive light, because we became familiar with forensics, one of the first publications that SANS did was one on incident

handling, and I was a contributing editor to that. But at the end of the day, after all sorts of bad things happened, the members of the pit were again paraded into the conference room, and we were told by our senior management, look, we really like what you guys are doing here. you know, we want you to do what you guys are doing, but if you're gonna do it here, you kinda have to do it following our rules. And we were hackers, so we left. Most of us. So, there were six of us originally, Two of us are still at NSA doing all sorts of wonderful things that I don't even know what they do anymore. Four of us are out in the private sector. The only

other one that I have public permission to share with is Ron Gula. Ron Gula went on to be the founder of Tenable Network Security, the makers of Nessus, and me and several other people. So that's the pit. Sort of as an aftermath, I mean, you know, this whole DOJ thing happened at the end of '96 in August. I was gone by October. Others followed shortly thereafter. Here's another date. And this is for the benefit of the Loft and Well Pond. And as close as I can get to, I think, was the release of Loft Crack, which was the original Windows password cracking tool. So correct me if I'm wrong, Chris, but I think this is

as close as I've been able to find. Also in '97, after I left, was this thing called Eligible Receiver, which you may recall was the name of Chapter 4 in the book Dark Territory, where we have been memorialized as being the pit. What Eligible Receiver was, was a joint, organized NSA hack of the entire DoD. It was designed to last for something like two weeks. And you may or may not be surprised to know they had to pull the plug on it after like 13 hours because they owned everything. And it revealed for the first time how vulnerable things were and so on and so forth. The picture on the right here is they actually got all the suits

and senior level executives that were so proud of themselves for coming up with this thing. I guess for the 20th anniversary they got them together for a symposium at University of Maryland, which would have been in 2017. That website I think is still active and you can go there and it's weird, you can't Google search But if you go there, you can find a link to, they have a roundtable discussion where they talk about eligible receiver. They also published a redacted version of sort of a promotional video that they did about eligible receiver that they produced back in 1997. It was originally a 20-minute video, and they redacted it down to it's like 11 minutes.

If you're clever, you can go out and find it. There's people that are in that video that I know and I worked with, so it's a little interesting piece of history, but it happened after sort of the time of the pit. Another fun date, just again to put this thing in context, NMAP didn't come out until after I had left NSA. So just everything we did at NSA in the early days was done without NMAP, can you imagine? We still get together less frequently now. We try to do it as often as we can. In a recent gathering of the original members of the PIT, somebody that still works at NSA brought us a whole bunch of tchotchke from NSA. So I got a bottle of NSA secret

sauce. I've never tried it. I'm not going to open it. And then we got this really cool NSA pen that actually emits the NSA seal as sort of a bat signal, which is what's being projected on that coffee mug. So that's not a seal on the coffee mug. That's what the pen produces. You can find this stuff at the gift shop for the NSA Cryptologic Museum, which I encourage you to meet. I encourage you to visit sometime if you're ever in Fort Meade, Maryland. So, that's a real high level, lots of stories. I've taken all this sort of institutional knowledge, tried to turn it into a career, and at this point I try to give back and educate because I still think there's value in learning from the history

of where we've come from. It's been mentioned I'm a co-host on Paul's Security Weekly, and I get to correct Paul all the time and try to provide context. We get along really well. I'm known as the PCI guy on Security Weekly, and I don't know if I've been rewarded or put in a corner yet, but they've given me my own show now, and we've just started recording since October, Security and Compliance Weekly. So I'm the main host of that. We're trying to record several episodes before we drop it on the podcast feed so we have a little bit of, you know, something for people to listen to. But stay tuned if you're at all interested

in sort of how security and compliance works together. And I would assert that they are very, very interrelated and can't be separated. Stay tuned. I'm involved with a group called Hack for Kids. They put out a game last year that's supposed to be educational called Freaker Life. It's sort of the history of hacking and freaking from the 70s and 80s and 90s. I was honored enough to be included as one of the face cards, what they call in hackronisms. And this is a group of most of us together at DEF CON last year. There was a book published earlier this year called Tribe of Hackers, I guess because of my older statesman status they let me be in it, so I have a chapter in Tribe of Hackers. Just

I guess right after, right around the time of DEF CON this year they published the second version, Tribe of Hackers Red Team, and I got to be in that. They're working on a Tribe of Hackers Blue Team. I'm not in that book, not that I have anything against the Blue Team. I'm also known as a Jedi Master. I give a talk on mastering the art of the Jedi mind trick. And I was honored enough, I guess it's been three years ago now, to have been included in what's called the Cabal of the Curmudgeons, which is a group of old-timers that get together at RSA every year and have dinner with Gene Spafford. Gene Spafford is

one of the authors of, way back at the beginning of the slide presentation, Basic Unix and Internet Security. So he wrote, essentially, the Bible that we used in the early days of how to secure networks online. He's at Purdue University. He founded CERIAS, C-E-R-I-A-S. He's a really old timer. To be included in this group, you have to be invited in by one of the members and you have to get voted in. Somebody has to sort of present your case and they vote, you know, thumbs up, thumbs down. So you might recognize some of the faces up there. It's a pretty small, you know, quote-unquote elite group, but we're really... We call ourselves curmudgeons because we're

old and generally bitter and pessimistic, but we haven't completely given up hope. We're still in our own way trying to organize and trying to make a difference. And ironically, the person that I have my arm around, the guy in the red sweater there, is the lawyer that I dealt with back at NSA. So we have buried the hatchet and made amends, and now we're together again. It being time for lunch notwithstanding, I'd be happy to answer any questions that anybody has. Like, what's my favorite craft cocktail? Yes, in the back. Wow, that's a great question. What constitutes a security company? If Cisco isn't, I guess, is really the question. Then I have no comment. Any other questions? Like, what's my

favorite alcoholic beverage? I am partial to old fashions. Thank you. If we're at a beer place, I like browns and darkers, the fall ales are what I prefer. If you want to ply me later on, yes. The one that's free. Oh, man, now we're going deep. I like walnut bitters. I like just about any kind of bitters. But anyway, let's go eat lunch. Thank you very much for your time. Oh, and last thing, I've got stickers. I'll put them out on the table somewhere if anybody wants stickers. More Tales from the Crypt Analyst stickers. Thank you.

On the shore things that you might think of When were all those dreams we shared those many years ago? When were all those plans we made now left beside the road, behind us in the road? More than friends I always pledge cause friends they come and go People change as does everything I wanted to grow I just want to grow Slide on next to me I'm just a human I will take the blame But just don't say this is not You see, nothing else don't leave me so cold I'm buried beneath the stone I just want to Worth your love And I'm such a It's my fault now I've been Caught a sickness in my bone Now it

pains to Look at on your own Just don't let me go Help me see myself Cause I can know

Looking out from the side of the barn where his head I had no more years before I disappeared Whispering, give me something to echo future I see The air comes near, but not much longer Precious mother of rest until

you can fool your friend i think it's just more kiss me just to that feeling don't give me yours to get it's not there to take it out

♪♪ ♪♪ ♪♪

♪♪ ♪♪ ♪♪ All of this can be yours. All of this can be yours. All of this can be yours. Just give me what I want and no one gets hurt. Hello, hello. We're at a place that we go. Let's go down and all that you give me something. I can feel your love teaching me how. Your love is teaching me how.

Yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah, yeah. She goes to art school. Art school. Girl. Got a girlfriend. She got a girlfriend. And she gotta go. She left her home from sweet Alabama. New York City, yeah. She left her home from sweet Alabama. It's time for the Power of the Town. I told you five times I told you

You don't have to. Let me take some of the punches for you tonight Listen to me to let you be fine Sometimes you get with fine all the time That's all with the same soul I don't need to hear you say well and so to me now To let you know

♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪

♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ Again, I'm talking to, I'm standing on the rock. You're not.

♪♪ ♪ And take and take and take ♪ ♪ You're not the ocean ♪ ♪ I'm standing on my toes ♪ ♪ You're not oceans ♪ ♪ You're not the ocean ♪ ♪ You're not too much in ♪ ♪ You're not ocean coming in ♪ ♪ Ocean ♪ ♪ Too much in ♪ ♪ You're not coming in ♪ ♪ Yeah ♪

I'm gonna tell my soul, a soul, yeah I've been told, yeah I'm gonna tell my soul, a soul, yeah Truth be told, I don't need truth be told, no Yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah

yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah

All the thoughts you never see. You are always thinking. Brain is wide. Brain is deep. Oh, are you sinking? See the way. It's on distant shores. Dream or dream no one's right. Distant time, distant space. That's where we're living. Distant time, distant place. So what you give, what you give in. Friends it goes to art school. Art school, girl. Girlfriends, you gotta go. she left her home from sweet alabama We've got a friend that you know from Sweden.

She left her home to sleep. I don't know what time, I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what

time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what

time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't know what time. I don't

I don't want my soul to be normal I'm in a wild run of insecure delusions For a beast to cross me Oh, feel the change coming down I've been hiding in my shadow My shadow Change is coming through my shadow I've been crawling on fear and doubt With insecurity Feel the change consume me Feel the outside me turning me ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪

Please stay a child somewhere in your

you want. Accept the thing that you want. You are the first one. And you feel like no one before you steal. Cause I want you so. The light of what you got. And I want nothing that you're not. You go, you shout. ♪ You don't have to be shy ♪ ♪ Some things you shouldn't get too good at ♪ ♪ Like smiling, crying, and celebrity ♪ ♪ Some people pay too much confidence, baby ♪ ♪ Give everything you want ♪ ♪ Accept the thing that you want ♪ You are the first one. If this be right or not, cause I want you so much. I want the light of what you got. I want nothing that

you're not. Oh, you're shy. You don't have to be shy. Sugar, sugar, sugar. Show yourself. If you keep your back in track. Oh, you're shy. You don't have to be shy.

♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ ♪ Never shed a clothing Yeah, that type of couple for reaching Nelson Can't help but wonder where and who she might meet to go Watch these with hell And I sleep with the light in case she calls And I sleep in case she is Recently as I was waiting on a dream She cut the lips above my head She went out for a month Cause for years I've been hoping Oh yeah, I've been hoping That when she came, she would She came, she'd be And when she came, she'd be Yes I understand that every life must end. As we sit alone, I know someday we must go.

Practice time of sin is never gonna let me win. Under everything, just another human being. Yeah I don't wanna hurt. There's so much in this world to make me believe.

Hey everyone! I know you guys are just back from lunch. And the crowd's up there. announcements before we start. One, go by and see our vendors. A couple reasons why, because one, they're sponsoring us and we can't do a lot of what we're doing without our vendors. Two, they actually have extra raffle tickets that they are giving away for you guys to contribute into the different raffle boxes which you'll find at the registration table. There's a lot of great stuff that we are giving away such as like a Wi-Fi Pi, a Red Team field guide, a Cult of the Dead Cow book that has been signed by our keynote that was earlier today. Also, in your bags you'll see

raffle tickets as well. So if you haven't looked through your bag from this morning, look in there and you'll see a raffle ticket and make sure you put it up in the different boxes at the registration table. So I have the pleasure to introduce and totally butcher our next guest's name. So one, it's going to be on me, and you can laugh at me and not him. So with that said, I apologize in advance. But today we have the honor of having Algis, here he goes, the last name, Kiyaburski, who is an information security consultant. He is the principal security consultant, auditor, and instructor at Ethi Secure. He's a former security architect for Ericsson and Nuance, and he has over

30 years experience in assessments, implementation, design, auditing, strategic planning, and policy development. He brings a generalist and sensible approach to the realm of information security. So with a warm welcome, I would like to introduce Algis.

Swirls and curls of angel hair And ice cream castles in the air And feathered canyons everywhere I've looked at clouds that way They only block the sun They're rain and snow on everyone So many things I would have done Clouds got in my way I've looked at clouds from both sides now All right. Good afternoon, everyone. Welcome back after lunch. Does anyone, by any chance, happen to have recognized the dulcet voice that was behind that song, behind that interpretation of the song? Anyone at all? So, not many Star Trek fans here today. Well, I'm going to start with you. Radar Security Conference, I figured I'd try to get, you know, from the dark side of the geeky realm. It's the gentleman on the left. It's Leonard

Nimoy. In the days of the 70s and the 80s, it became quite popular for a lot of these actors to start dabbling into the musical realm. They thought they were good at something or more or less good at something, that perhaps they could be more or less good at something else. And so I figured that it would be logical to lead with, you know, the original author and the singer of the song, Joni Mitchell, a proud Canadian. And apologies to those illustrious artists who have much, much, much better versions of this song, including the illustrious names that are there, including, of course, Sporty Spice and Courtney Love and the rest of that. And for anyone wondering, again, for those that are

in the Star Trek geeky realm, there is no... William Shatner version. Now, why am I bringing that up? Well, Bill Shatner, all around nice guy, famous Montrealer, I am from Montreal, McGill University alumnus, and even the Student Union building is named after him. best known as an actor, perhaps in Luce's sense of the terms. He's an author, writes about Star Trek producers, produces stuff about Star Trek directs stuff as well. But he is also a recording artist, like you could have seen from, you know, he shared the other half of that CD cover. Eight albums. Now, for those who like Eclectica, Bill Shatner is best known as an actor, but he's second best known as...

what I would say to be a spoken word artist. He's got a certain way of expressing himself and I guess perhaps he sings as well or as badly as I do. So he didn't create the spoken word realm but well just by watching this clip I think that you'll see that he's nailed it. Oh I miss the earth so much. I miss my wife. It's lonely. I'm such a... Timeless. Thanks, Bill. Thanks for going beyond the realm of television. Really appreciate it. Oh, yeah. So, my talk today is on cloud. Oh, no, no, no. None of that music again. So, talk is on cloud. I wasn't a proponent of it or a big fan of it. I work exclusively

in it now and I just wanted to share a few stories or insights. Standard disclaimer, these are my opinions. You may not share them. Please feel free to challenge me. There's a question and answer session at the end. So if we can start with an informal poll for those that are here, just so I can get an idea of the room. Who has sensitive data in the cloud? Talk about nominative data. Personal data, business confidential data, awesome. Who's planning to move sensitive data to the cloud? Some of them have and some of them are putting in more. Who has decided not to move that stuff into the cloud? Awesome, and we'll cover some of these aspects. Who has

critical infrastructure in the cloud? Awesome, networking, databases. Who's planning to move that stuff into there? Who's got management that's forcing them to do this? Awesome. And who doesn't want to even go there? Awesome. I feel like I've got feet on every side of this one. So we've got the cloud and... There you go. So we've got all sorts of just a few definitions to just ramp up people who may be more or less familiar with it. So we've got infrastructure as a cloud. So that would be your material stuff and everything, your foundational type of stuff. You've got software as a service. And that's usually the stuff that you interact with directly, right? Your application level stuff. And then you've got PaaS, which is somewhere in

the middle. And then you've got a whole bunch of Yeah, asses. And then you've got public, which means that you subscribe to something, and you've got private, which means you have it all in-house, and a lot of organizations still do this today. And then you've got hybrid, so you've got, again, a foot on each side. So maybe an organization might decide to, you know, go in and get an account in AWS and do all sorts of big data, cool stuff, but yet they may decide to keep some of their sensitive data or some stuff that doesn't port as well outside. Today's technical focus seems to be more on third-party processing and storage. I saw that

the SANS Institute is a sponsor for this event. SANS used to offer a course that was private cloud, and now they've put that aside, and now their only offerings are dealing with the public cloud. And that's where the market has tended to go these days. Upper management focus seems to be fixated on cost cutting. We'll look at this again a little bit later, but it's a huge one, right? They want to be able to streamline things. This thing is a magic thing, this cloud thing, and we can cut operational costs. We don't have to buy anything. And at the end of the day, we're just going to have a couple trained monkeys, perhaps one to watch the presentations of the other, and that's going to be pretty much it,

and everything just magically runs itself. The obligatory definition, right? Cloud is what? Allows you to, once you have a subscription, to add as much processing power as you want, perhaps on demand, perhaps automagically, and a whole bunch of other capabilities, and managed networks, service storage, application services, you name it, this thing does it. It's a magic all-in-one. So basically, if you've got a computer or a phone, and a logger digital, and you've got a credit card, you've got some of that cloud action going for you. So all is good. It's really great. A lot of benefits here. I put little asterisks next to the ones that attracts upper management attention. Certainly you don't have to

buy anything, right? It's a subscription model when you're going out and, you know, into the cloud. Your AWS is in your Azure's of this world. And it should reduce overall costs. Simplifies accounting because you just got one bill to pay or at least one per instance. You've got on-demand self-service, you've got a perception of having reduced training burden. You know, if this stuff is in the cloud, the security can be handled by those magicians over there, and rightfully so, to a certain degree. And there's a whole bunch of technical improvements, many of which you have certainly seen, and some of this I've mentioned already. Now, just to go again with the Star Trek thing, it's no longer a place... where no man has gone before.

Many people use it, many organizations do it. This is just an example. There are hundreds. There's a new series of Amazon Web Services commercials that are out these days. that basically scroll through all the different kinds of organizations or services or clients that they have. And they're pretty ubiquitous and they're the big player, but there's a few there as well. And they dabble from private to public services. The province of Quebec where I live, they're absolutely huge there and they've decided to go all in in the cloud. But then you have to be careful when you first look at this to see, well, when people say all in, what do they really mean? And in

some organizations, like I mentioned a little bit earlier, they put in some or most or strategic aspects or high availability aspects in the cloud, but some of the components they keep internal. So by going through a subscription-based model like your Azure's and your Google Cloud and your AWS, are we really raising that security bar? They've got experts there. They're competent, they're certified, that's what they say on their websites, that's what I've seen by meeting these people. They really do have competent people there. And their configurations are supposed to be sanitized for our protection, well protected, well configured, reasonably well configured, and so on. But yet these things have to be permissive enough with respect to their configurations that people can actually use them from the get-go. And we

already had a few talks, I believe, this morning, certainly one that I was able to attend, where we addressed that particular issue that things are generally insecure by default, even security software. And this goes as well with respect to the cloud. And we need to go and look through soft wording in SLAs. Now, I took a quick look just before this talk to see what buzzwords are considered to be very popular these days in SLAs. Azure uses, actually explains what they mean, what we consider by being available or highly available. So they use these terms, but then they propose a definition of what it really means to them and maybe not necessarily to us. Whereas AWS likes to use this term that they will do everything that is commercially

reasonable to ensure high availability. So, despite the soft wording, and perhaps there's certainly disclaimers in there as well, there's an issue to see beyond the soft wording and see, okay, so they're doing the CYA exercise, but what are we really getting, and is it better than what we can do at home? So despite the fear, despite the uncertainties, and despite the doubts, the security benefits of going in the cloud are real. You've got an SLA, you've got someone to go after. They are demonstrable. They can have certifications. You've got these SOC 2 things, an ISO 27001, beautiful certificates that they put on their walls. You've got FedRAMs for the organizations that can actually attain those lofty goals. And the benefits are tangible for an

organization. If they're doing some stuff that your organization doesn't need to anymore, then that's awesome. And we have a history of trusting other organizations to protect assets, right? The newborns, money, vaults, our passwords at work. We use usually a corporate password vault these days, and many of us have our own on our smartphones. And we trust them to do the right things. So, tamper-proof ID bracelets for the newborns, locked doors, things like that, video cameras, two keys for opening a safety deposit box. And look, even Wells Fargo in the old days, I understand they've got some challenges these days, but as one of the original ones that went coast to coast in the United States, gee, didn't even go by security through obscurity, man. They were

advertising as they were going through the wild, wild west. And there are strength in numbers, right? So the more people are using a certain service, the more the cost per head go down, so to speak, and you're able to invest perhaps more in protection mechanisms that can serve all. And cloud service providers have many high-profile customers that they can't alienate, or they'll lose that segment, they'll lose trust, and they'll lose that segment of business. But there's always that cost-cutting thing that comes into play. But what if we all end up sharing the same weaknesses? After all, we're all putting our money in the same banks, right? All putting the babies in the same nursery. All going to the same three main, but

there are many smaller players, cloud service providers. What happens? We're all in, and we all end up being vulnerable to the same thing. A thing that we're not even under control of. What if somebody finds that Achilles heel? We've got, everyone's got the same Achilles heel. And we may all be end up being vulnerable to one strategically placed, well-placed, targeted attack. And I apologize again to those Star Trek fans and mixing with Star Wars. Apparently that is forbidden, but I thought the Big Bang Theory took care of that by grouping everything together. And then we can feel comforted in saying, well, okay, well, we might be gone down and we're just one of these little stars here and we've got company and misery loves company.

So there are cloud related business risks and there's a few that are listed there, right? Our reputation could be stained due to something that happens that is outside of our control. It could be a regulatory pressure that say, oh, well, you know, you really have to do your due diligence and if you transfer your due diligence to a third party, well, then you're ultimately responsible. But yet you can't really see through that opaque wall of what's going on there in the Azure world. And you've got multi-tenancy issues, so again, you know, you're subscribing, and how do you ensure that you're, you know, you're Ford, and then your next door neighbor is General Motors, and you're

both in the same search provider. How can you ensure that they can't go peek and see what's going on in your side of the world? And of course, the privacy issues with GDPR and so on. How do you ensure that people are adequately protected with their information? How do you make sure that according to the European law of which you may be subject to either as a business decision or because of legal issues if you happen to have a business direct business relations or a regional office for company based in Europe and all of a sudden you say well you know according to gtpr you have the right to be forgotten right according to the

laws over there you on request you can say I want all traces erased of me how do you really do that effectively in the cloud How do you remove all those traces, not only in the instances that you know of, but those mystery, hidden AWS instances that they don't advertise to ensure their resiliency and their high availability? How do you ensure that it gets erased from all of their backups? And where are those backups? So we'll address a few challenges. There's a short list there.

At the end of the day, trying to avoid, you know, try to perhaps cut our subscription to the Dumpster Fire of the Month Club. I should be hearing a little bell in the back of the room every time we mention Dumpster Fire during the course of these sessions. So, first one, over-reliance on SLAs, Service Level Agreements and Third Party Audit Reports. Third party certificates and audit reports don't paint full pictures. Who's had the luck and privilege and honor to have to look at these kind of reports when doing assessments, right, of these third parties, right? Who enjoys doing this? Who can see through the opaqueness of the way these things are written? You know, you

go on the Azure website, right? And, oh my goodness gracious, there's dozens of these things, right? And Amazon is worse. And they do great things. They allow you to do a lot of wonderful things. But they're very dense and they're very difficult. You know, you've got a certificate that's saying we're ISO 27001 compliance. Right? So they've got an information security management system in place. They have control over their controls. Right? Awesome. They list all of the controls that are in the associated standard ISO 27002. All these different things that they have controls from an administrative perspective and technical perspective, compliance perspective, you name it perspective. But yet the details, what do they check, where do

they check? Now we got a certificate man, trust us. So they don't paint the full picture, so you got to fill in the gaps. How do you fill in the gaps? Oh, we got a security questionnaire. Who has security questionnaires that send out to organizations? Less and less than before, right? Who gets responses back? And for those that get responses back, are those responses even remotely useful for what it is that you're trying to do, right? You're either going to get these vendors that reply and say everything is compliant, one word, responses, or they go on and say, well, applicable to this, but then you don't know applicable to what, and then at the end

of the day, you're playing whack-a-mole and trying to figure what is going on. So you don't really get a full picture either way.

Cloud service providers are increasingly open and tolerant to stress and pentesting. That's good news, right? Nowadays, aside from perhaps the administrative interface to manage your account, and perhaps as long as you get yourself a dedicated IP space, you could pretty much go for gold and try to hammer away and find out the weaknesses. So that's good. The problem is often in these implementations you don't really get the information or the results or the answers back from your tools that you would expect to get. Packets get dropped, connections get reset. It's really tough to find out what's going on even when you do your due diligence by going beyond a questionnaire and actually passing them to the test. And it can be

very difficult to change clauses in agreements. Who's tried to change clauses in CSP agreements? I know I have, many times. Who has been successful? I know I haven't. And that's usually the case when smaller organizations, people that are not at the top tier of this world, the FedExes and the military organisms of our country don't have the power over these vendors. So one of the tactics that are being proposed is, well, find someone your own size. You know, using the old one neck to choke metaphor, you know, finding someone that you've got a handle on, that they are ready to respond to your needs and your whims or your particular aspects that perhaps the biggest vendors just simply declined to

do. And if you don't like it, just go to door number two. Second aspect is loss of hands-on control to your data, right? We're letting Jesus take the wheel. Or in this case, we are letting the Azers and the Googles and the AWSs take control of it, we're buying a subscription, we accept your terms and conditions, we give you money, please do the right thing. The challenge is though, is that even though you know on the contract where your data is going, you may not necessarily know where that shadow instance is in AWS, like I was mentioning, or where those backups are located. You may have limited visibility or absolutely none at all. For those

that are outside of the US, they're impacted by the Cloud Act that was enacted here a few years ago. See, I'm in Canada, and the example that I know in one of my clients that they faced is they had an obligation that all of their data would have to be residing in their country, such as in Canada. Ah, we're covered. That was our requirement, and we checked it off. Then this law comes into place and said, well, okay, well... Where's Google based? Where's AWS based? Where's Microsoft based with Azure? Well, any US resident or citizen that happens to have information outside of the country, all of a sudden now the doors have to be opened

and that data needs to be made accessible to the affected authorities. And then these organizations have to now be able to turn around and pivot and respond to these requests instead of turning around and doing the easy thing, which is just give them everything. If you have encryption as a way, as a magical tool to have control over your data, or at least the read capabilities to your data, where is it implemented? Who has the keys? Is it in the same cloud provider's hands? Are you protecting those keys? Okay, how are those keys protected? If you're storing the keys locally in your organization, this is becoming more and more prevalent. Who's got control over unlocking those keys? and so

on, just because you got encryption is at the end of the day is who's got the keys in hand is really the one that has access to the data. And then it's my biggest pain point, and that's vendor lock-in. Now I worked in the telephony industry before, and vendor lock-in was a very, very real thing. And vendors, especially the bigger vendors, when they saw that technology is evolving from say, in mobility, from 2G to 3G to 4G and now 5G, and there's already work groups set up for 6G. There's an opportunity to dump that vendor that we don't really like so much and go to another one. But you still want to keep those things

like a customer database. in these home location registers, for example, these glorified databases that you've got basically all the client data in. And then you want to port it over and you've got this contractual agreement that says, okay, we have access to our data. It is inside your equipment. We want it out now. And what organizations found out is it ain't so easy. If they would give it to you, it would be in a format that wouldn't be readable or it would be in a format that seems to be readable and then, well, good luck to you. And... In organizations, you can stumble on things as trivial as the character set that you use to be able to run into major, major problems in terms of porting data

from one environment to another. This exists certainly in the cloud as well. Who here, if any, and I'm hoping to see at least one hand, has a plan to be able to back up and restore in another cloud vendor's environment? Awesome, and I hope there's going to be more of you in the future. It ain't that easy, I'm sure. I'm pretty sure a lot of the people that raise their hands, they have the bruise marks to be able to prove it. Can you retrieve your data in a standardized, usable format? Your JSONs, your XMLs. Imagine how big these things are going to be for some instances. Have you generated dumps backups? Have you made them available? And have you actually attempted to do restoration? Nice to

have a backup plan, but a backup plan without a restore plan or a tested restore plan that works, ain't much of a plan. A few other bonus parts. Like I've mentioned before, a lot of organizations look at cloud as a magic way to cut costs. We don't have to buy. Our organization has decided our new five-year plan or our new strategic plan says we are not buying anything anymore. We are going subscription-based. We're going to save money. And look, the cloud is there to save us. And there are other organizations that say, all right, we don't like to have operational costs, right? The day-to-day stuff, all our people doing the hands-on monitoring and management of

these solutions. We want to cut costs there. So we want to buy. Now, I worked recently as a client for, as a subcontractor for an organization that they wanted to cut costs. And they actually did the opposite of the first part. Said, all right, you are a cloud provider. We want to buy three years' worth. Three years, in our opinion, is a capex expense. Who here in this room has seen an organization go from one end to the other end and back again? I think I've got whiplash with many of the contracts that I've been under. What they're trying to do is say, "We want to save on both." How are you able to save on operational expenses and on capital expenses? Again, it's that

magical cloud. And while hands-on technical control is given to the third party in exchange for your money, right? The suggestion would be is you tend to refocus. Not eliminate, say, a security team or an operational team, but allow them to refocus on things that you're supposed to do, that you're bound to do by contract, such as oversight. If an organization outsources to a third party, that organization is still responsible for the execution of those functions that have been outsourced. Well, if you don't do the oversight, then all of a sudden you're doing less than you've done before, and you're exposed to aspects such as negligence. And then you should have some available bandwidth to actually

do the stuff, say from a security perspective, that you've always wanted to do, but you've always been so busy doing with respect to good housekeeping. or basic sanitization, basic encryption or access controls or that kind of thing. That would give you the opportunity to refocus, perhaps with a smaller team, but a team nonetheless. Then you got the elephant in the room, shadow IT. Now you've got these capabilities where everyone has got access to the internet or phone, for those that go by phone. and a credit card to be able to get something in the cloud for yourself if your organization is not quick enough to be able to get that thing for you. I was in an

engagement recently, an audit engagement, where an organization was too slow in providing capability to have a governance platform introduced, a GRC platform, right? Governance, risk management, compliance. But they had to do it for regulatory purposes. And so what they did is they They got their own subscription. They pitched in, three, four people in the team, ponied up 10 bucks or so a month, and they got themselves a SaaS subscription to a solution that provides this GRC capability, including all of their audit report findings, including basically a blueprint to all the weaknesses, a blueprint to the Death Star. And they had not implemented the necessary security configurations. They had a shared password with a shared account, default password, well, you can possibly imagine. So shadow IT is a

big thing that needs to be looked at and considered. And that's basically why it's been flagged out there. Just because you're going cloud, chances are if you're not moving fast enough, others are doing it one step or two steps ahead of you. So is cloud the final frontier? I don't think so. Cloud is relatively new. It's only been around for what, 20 odd years or so? I know that it's become a recently, you know, we're using that word term now. We had other terms for it before. And there'll probably be some other cool stuff that comes up at some point along the way. But right now, this is what we got. And it's very compelling. And so while it will not be the final frontier, it is the current

one. So I would have three suggestions. And one of them is to just do the oh yeah, oh yeah, and drink the Kool-Aid. It's there, people want it, contractual obligations are less and less binding for you to have direct control of some of the information inside your organization. They're more permissive to having it outsourced to a third party. And it is so compelling from a financial perspective and from a security perspective, it really gives organizations a new way to pivot and say, "Okay, can we give up the good housekeeping thing and stop dealing with the trivialities that have been stuck doing for years or decades, and we can move on to application-specific or business-specific risks and deal with the stuff that is really hurting us and not just

doing the basic housekeeping stuff?" Trusting but verifying. Demand transparency from your vendors. Scrutinize those assessments. Ask questions and if they're not answering, maybe pivot and find someone else who may. Heck, for all you know, there might be a reseller of those big boys that might be more responsive to answer the questions you're asking but the big boys aren't answering. And finally, controlling your data. Make sure that you can repatriate when you want. Make sure that you protect it when it's sending somewhere else. And make sure that you're managing and controlling the keys. So that's basically the content. Now if I could oblige, if it's possible, to just dim the lights a little bit, if it's within our control. And if

not, I can still do it in the daylight. I'd like to wrap up with using the inspiration that I got from the very beginning of this session. And share my thoughts and my experiences. Everything has gone well. I thought it earned my silvered hair. Got her lose it and didn't care. Then clouds popped up from everywhere. I feared clouds that way. But now I see I've just begun. Clouds advances I just can't outrun. So many things I could have done. Once clouds

I have looked at clouds from both sides now. From up and down and still somehow. It is clouds. Illusions I recall really do not like clouds at all. I wasn't able to choose the word to... Mind that's why I inserted there Great app Chateau Atria. I'm pushing it best $10. I am invested in my life. Thank you very much for your patience understanding Do we have any questions any questions that I hear a peep I've got to encourage people to ask questions I've got beautiful CDs for those that have CD readers of the space that album to build the spruce they make great coffee mug coasters If there are no questions, thank you very much.

You're more than welcome to pick these up. Have a great rest of the conference. It's a wonderful event. You don't have to always be right Let me take some of the punches For you tonight Don't tell me to lie You don't have to be fine Sometimes you get We fight all the time That's all with the same soul I don't need No need to hear you say I'm sorry Don't tell me

How's everybody doing? You guys enjoying B-side so far? Yeah? All right. So just a quick announcement. Everybody got tickets in their SANS bag when you guys came in. You might have heard this the last time, but I'm going to repeat it again. Those are raffle tickets that you can use for items that are by the registration table. There's also additional ways to get more raffle tickets. One way is you can purchase some and all the proceeds go to charity or you can actually go speak to our vendors and our vendors also have free tickets that they can give out to you. So if you're interested in any of those items or even just giving to charity, feel free to check out the registration table.

Moving on, I have the honor of introducing Paul Burbage. He is the founder at MalBeacon.com. He's a malware researcher for over 15 years of experience with tracking botnets and finding vulnerabilities in malware command and control channels. His passion lies in performing PHP static source code analysis on commodity malware kits. He currently works at CrowdStrike as a senior e-crime researcher where he tracks and analyzes malware being sold in underground communities. His Twitter is @hexlax. And without further ado, here's Paul Burridge with eliminating malware adversaries with Malbeacon. Send my book down there. Thank you. So yeah, my name is Paul Bribbage. Today I'll be giving you a talk on illuminating malware adversaries with Malbeacon. Really excited to show and share with you

today a passion project that I've been working on for over three years. So let's go and dive in. A little bit about myself, I'm a Maurer researcher and as the nice lady that introduced me mentioned, I currently work at CrowdStrike but this particular project is not affiliated with them. This is a personal project that I've been working on myself for over three years. So my passion in the field is looking at those Maurer kits that have some type of lamp stack and finding vulnerabilities within them. I'm a drummer, like music, of course. And I was active duty Marine 2004 to 2008. Any devil dogs in here by chance? Yeah, one back there. Simplify, brother. Yep. Good to go. Feel

free to reach out to me at HexLax on the Twittersphere. All right, so we'll go over our agenda for today. I'll discuss what I foresee as a problem within the malware ecosystem. It's far too easy for people to go out and acquire malware kits and utilize that to breach organizations. To understand how we're able to beacon malware command and control, I need to touch upon stored cross-site scripting just to kind of lay that foundation of how we're able to do it. Then I'll dive into the system itself, so how we're able to inject those beacon payloads into malware C2, and then what that receiver looks like, all the information that we're recording from the adversary

as they log into that malware control panel. touch upon the legality concerns utilizing this type of intelligence collection, and then have some case studies to present to you. Finally wrap that up with some conclusion and Q&A. So what is the problem? It's far too easy for anyone to go out to the internet and whether or not they're purchasing these within cybercrime forms or finding them for free, malware kits that leaked, and they can utilize these to breach organizations. And these, in my opinion, the current attribution for people that are utilizing these to attack companies, it's one-sided. It's typically grouped by shared infrastructure, you know, shared domain registration details or shared IP addresses, or similar tools, techniques, and procedures. as well as malware code. However, with most

commodity malware kits, it's one author that's selling to several different individuals. So to trace that back to an author is one piece of attribution, but who's actually utilizing these kits to attack these companies? So there needs to be better attribution. In order to protect ourselves, we need to understand the attacker and where they're coming from. Is it a target attack or are these attacks occurring across multiple industries and they're just trying to do drive-by download attacks or drive-by attacks to reach as many people as they can. So one way that we can do this to get better attribution is to beacon the adversaries as they utilize their malware C2. So I want to touch upon the stored cross-site scripting. So stored cross-site scripting in general is just

whenever a web app vulnerability allows an attacker, in this case us, the researcher, to execute script. It's the most common vulnerability in web apps today. I was talking to the Veracode guys out there, actually, about some of the different web app vulnerabilities, and they confirmed that cross-site scripting is still very prevalent, and even more so in malware command and control. So these families, these web applications, they're not going to go, hopefully, through the rigorous testing that customers of Veracode would be utilizing their stack for. So this persistent or stored cross-site scripting occurs whenever that payload is persistent across the session, so it's not reflective. This is typically a payload that's stored inside the database, but can also be stored on

the web server file within session information and so on. then it's printed out or echoed to the web application user, in this case a malware actor who's logging in to look at all the infected machines under their control. So it's printed out and it's rendered. And although it's possible within stored cross-site scripting vulnerabilities to insert JavaScript, with this particular system we're solely doing benign image callbacks. And I'll show you why that is when we touch upon the legality concerns here in a little bit.

I wanted to briefly cover what is a malware command and control. So most of these systems, the ones that we're able to insert beacons in, it's essentially just a web application. Most of the underground actors refer to these as a panel, most of them running on a LAMP stack, so your Linux, Apache, MySQL, and PHP. So all of the infected nodes communicate-- you can think of it as an API with the malware C2. This is commonly referred to as the gate. So all the infected nodes, they might check in or exfiltrate data from those infected machines and send that to the C2. The other interface allows the adversary to log in. It's usually a nice, gooey, you know, web front end where they're able to log

in, see all of the infected machines under their control, and issue commands or, you know, download exfiltrated information from those infected nodes. One other, so to give you kind of a higher level overview of what the system is doing here, we're actually pretending to be an infected node. So some of those artifacts that are submitted to a C2 might be like the workstation name. So we write code to mimic that infected node check-in protocol. and we're able to insert beacons inside of that protocol, and then hopefully if the malware C2 is vulnerable to that, the actor then logs into the C2 and it triggers an image callback. Whenever an adversary logs in, they might be greeted with

a screen like this. So this is an administrative interface for Formbook malware. Formbook, one of the families that we are collecting fairly heavy on. And I'll dive a little bit more into the case studies here in a little bit. But as you can see, further down towards the bottom, there's a couple rows. And these indicate two infected machines. And again, some of these fields, like the OS version there or the bot ID to the left, that might be one of the fields that are susceptible to stored cross-site scripting. So we can insert our beacon payload into that. And then as that actor logs in, again, it triggers that image callback and we get all of

the information about them. So I want to dive into the system itself. How are we able to first insert the beacons into malware C2 and then the receiver? So the beacon injection method, there's also two methods how we're actually able to inject this particular beacon. I kind of touched upon it earlier, so we do a manual insertion where we pretend to be a bot to check into the C2, and then we also have an automated hooking function as well within Mauer Sandbox. Show of hands, is anyone familiar with Cuckoo Sandbox? Quite a few? Cool. So yeah, it's just heavily modified Cuckoo. For those not familiar, Cuckoo is an open source project. You can download it

for free on GitHub. It allows you to execute malware samples within a virtualized environment. It's pretty cool if you want to play with it. And then finally, there's the receiver part. So this essentially is just an image request that's coming back and hitting our systems. We're able to log all the information about the actual attacker, you know, utilizing these malware families in the wild. I wanted to go over the injector method, or the manual injection. So this actually requires researchers to analyze the C2 source code. So we have to have a copy of that, right? We have to, you know, some of these kits are leaked out on the internet. We can grab a copy of the kit and take a look at that

PHP web application and find these vulnerabilities and then write you know, reverse engineer that check-in protocol and then create a fake bot to check in and leverage those particular vulnerabilities. So the pros of using the manual injection, it's very high precision, right? You get a nice callback rate as far as people, if the C2 is still up, you know, by the time that you are able to inject that beacon, nine times out of ten, you'll get a very nice beacon response from the actual person behind that particular malware campaign. Cons of this is that it's time-consuming, right? So some malware families, we might find a vulnerable family, but if it's still under active development, that

author might change the check-in protocol. Then we kind of have to go back to the drawing board, reverse-engineer the newer version of that, and rewrite our fake bot to check in just to see if it's still vulnerable for collections. Hopefully we didn't need that. I don't know what that was. So let's talk about the automated. I kind of touched on this earlier. So it's just heavily modified Cuckoo Sandbox. And the way that it works is that we're able to rewrite the monitor for the executable and the DLLs that get injected to monitor the behavior of malware samples as they're being ran within this virtualized environment. So what we do is hook these Windows API functions You know, the malware sample, as soon as

it fires, it might say, "Give me the machine name," or, "Give me the username of the Windows computer that I just infected." So that would be like a Windows API call, like username X. So we hook that function, and on the return, we taint the response to that with our beacon payload. Again, that might be one of the artifacts that are submitted up to the C2, and if it's vulnerable, it would pop and give us telemetry on who's using the actual C2 there. So the pros of this is that it's highly scalable, right? We can scale out cuckoo to run not hundreds but thousands of samples, discover new families in the wild that we might

not have the source code to analyze for vulnerabilities. And then from there, you know, we can... take a look at the ones that we're getting callbacks for and then fine-tune and reverse engineer that particular malware family to develop a little bit better check-in protocol for the manual injection. So it kind of feeds itself. The cons of this though, that it's quite noisy. And the reason why it's noisy is that it's a best-case scenario that a malware family is not susceptible, it's not vulnerable. is that initial gate, or the malware check-in protocol, it just drops that connection. It says, "This is a bad input. I'm not even going to try to process it. Drop it. Goodbye." Worst-case scenario, though, is

that information is still stored into the database, but the particular field is not vulnerable to cross-site scripting attacks. So now we have a URL, our benign image callback, that's not properly rendered as HTML, so they can see those domains, our infrastructure that we're utilizing for callback. So obviously a bit of an offset concern there. Then again, so as that malware C2, you know, person who's conducting these campaigns as they log in to look at all of the infected machines, they're going to trigger these image requests back to our systems. And what we set up is just a, you know, an image, another web application to record those image requests. When I first started looking at this, I was amazed at how much information you can get just from an

image request. really opened my eyes up to the amount of information that advertisers have on each and every one of us. So what the receiver is, is just an Apache with some HD access hacks. So image request comes in, redirect that GIF to a PHP script, and now I'm able to do some stuff programmatically as far as all that information is concerned. Pulling out the source IP address, which of course can be geolocated in the event that it's a true IP address. Questions that I received in the past, are actors utilizing VPNs? The answer is yes. But just knowing what VPN provider your attacker is utilizing, I think that's a pretty unique intelligence aspect in and of itself. What are some of the

other fields? The HTTP referrer field is probably one of the most interesting. The referrer field, this is going to be the actual C2 address of the malware campaign, or where the malware actor is currently logged into. So that's always pretty cool to see. We get the complete like git parameter that they're utilizing as they're browsing around on the malware C2. For some of the manual injection methods, I'm able to submit a unique ID parameter. So this is really interesting, especially in malware families where you might have multiple proxies in between the infected nodes and the C2. So receiving a UID response and that initial gate URL is different than the UID response, HTTP referrer, that indicates that this is a

completely different backend infrastructure that the bad guys are utilizing. Stuff that you wouldn't see from typical running malware samples just in a sandbox to retrieve those indicators of compromise. And some of the crappy, there's like browser add-ons that some people place that, or they utilize like free HTTP or HTTPS proxy list. Some of those proxies actually leak the true IP address of the individual. So they might think that they're utilizing these free proxies to obfuscate their true origin, but within that proxy request, they include headers of that true IP address. So if we see that, we obviously log that particular IP. And then the user agent. Of course, all of these client headers can be forged, but if the user agent

is true, that tells us quite a bit of information about our adversary. Everything from the architecture that they're utilizing, you know, x86, 64, whether or not they're coming from a mobile device, the operating system in use, and their preference in web browser. So the script just records all this, saves it to a database for later review, and then we send back a one by one pixel image. Why do we do this? Because as long as that cross-site scripting field is rendered properly, we just want to send back a one by one pixel image, hopefully to not mess up any of the HTML formatting as that actor's looking through their C2 web application. So hopefully the actors are none the wiser that there's a tiny 1x1 pixel being rendered there

on their C2. And then probably one of the coolest artifacts that I implemented earlier this year, I was discussing with some researchers in the field, and they're like, "Paul, why aren't you placing a persistent cookie in the reply to that image request?" And that's exactly what I implemented. And I'm seeing some really nice clustering from this data. So again, going back to how we're starting to, the old ways of attributing, I had this malware sample. It communicates with this domain, and I found this other domain that was registered with the same email. Yeah, that might be an indication of the same threat actor group, but now we're able to track these browser sessions as they

log in to new C2s. so they can change the domain. We can track the movement of that. We can start clustering C2s together to form this picture here. This data was actually just generated last week. So what I did was map the C2 host and the persistent cookies. And what this indicates is that 562 unique domains or IP addresses can be attributed to one threat actor group. And previously looking at this, you wouldn't be able to draw those conclusions. It would just look like a bunch of commodity malware that's hitting organizations' networks. And we've actually been able to attribute to a lot of this activity to Silver Terrier, so Unit 42 publishes a report usually about once a year. Most of these guys doing business email compromise,

but also dabbling in Loki bot malware, form book malware. But yeah, it was pretty cool to draw that to that one threat actor group, mainly operating out of Western African nations like Nigeria and Cameroon. So let's discuss the legality of utilizing this type of collections apparatus. So I actually went several rounds with the EFF, the Electronic Frontier Foundation, and I wanted to get their opinion. What's... how far can I get away with doing this? And they said, as long as you're not doing code execution, which in this case would be JavaScript, you're good to go. Which was kind of a letdown, because in the event that we were doing JavaScript, we could do some pretty cool things, like, I don't know, request access to the adversary's webcam, take a

picture of it. There's a company just off the top of my head called SessionCam that records video of what's occurring inside the web app. So we could take like an MP4 of everything that they're doing inside the malware C2. But again, that unfortunately utilizes JavaScript and it's a little bit out of bounds for staying legal. So I wanted to keep this system ethical and legal. That way I could talk to you all about it here today. So it's no worse than advertisements. I bet each and every one of us, if we pulled up our phone and take a look at the raw source of the emails on the phone, you'll find these benign image callbacks to tell the advertisement companies whether or not-- or tracking companies-- that you

opened that email. No worse than that. There's no authentication bypass. Again, in the event that we were doing JavaScript, we would be able to grab those authenticated cookies. and then utilize that to authenticate against the other C2. But since we're not doing JavaScript, we're not able to grab those cookies and do that. Wouldn't recommend that. And it is privacy respectful. So again, these are beacons that are solely submitted through a bot check-in protocol. And the only way for them to be tripped is if you're the adversary that's logging into these malware C2s. You wouldn't be tripping these beacons just by ordering blow-up dolls on Amazon. Good to go? So let's dive into some case studies here. I believe

Bluelive called this group Air9. And maybe Talos or maybe it was Unit 42 actually calls them TA545. Again, I've been collecting this data for over three years. Back in January of 2018, some groups of knuckleheads were utilizing the online or spam bot to send email attached with CanadaPost.zip. The zip contained R's VBS loader, which is actually a commodity malware family that was sold in Russian underground forums. Pictured right is the C2 login for that. So it's just a VBS that when that victim clicked on it, reached out to the C2 and asked, you know, what additional malware would you like me to download and execute? And the underground vernacular actors call this a loader. So this particular campaign

was loading Canadian banking trojans. They targeted Canadian financial institutions users as well as deploying Zero Evil Stealer, the same author actually, Zero Evil, the same author behind RSVBS Loader. So received some pretty interesting callbacks on this one from a dedicated server hosted in the UK. friendly nation, right? So reached out to the Canadian cert folks that were pretty interested in getting that piece of intelligence. Taking a look at the IP address at the time across Shodan indicated that it was a Windows 10 box and the same thing with the user agent there as far as the callback. So that was pretty good attribution for this particular case. So they were actually utilizing this dedicated host in the

UK as a bounce box to conduct their malware campaigns.

Second case study back in September of 2018. This is actually ongoing threat. I see it probably at least two or three times a month where guys will go out, bad guys will go out, they'll take a look at popular crypto coin wallet software. They'll copy that website, stand up a fake one, and by tricking users via SEO or advertising that link in crypto forms, they'll trick people to visiting these websites to grab the new edition of this software. In this particular case, it was downloading K-Pot Info Stealer. K-Pot is actually an Infostealer sold in Russian underground forms. K-Pot actually pronounced "krot" in Russian means "mole." This particular campaign tracing back to a VPS provider in Russia.

So this not only works with commodity malware. The system has also recorded advanced persistent threat groups, APT activity. Back in January of this year, a piece of Mullrat's malware came across my desk. And this was one of the families that we obviously didn't have the C2 source code for, but I tossed the malware sample into the hooked sandbox, the modified sandbox, and received some pretty nice attribution callbacks from this particular campaign. IP address tracing back to Gaza cyber gang, I'm sorry, geo-trace back to the Gaza strip and of course, mole rats has been attributed to the Gaza cyber gang. One pretty cool artifact in this particular campaign is that in order to render the the backend C2 panel there down

at the bottom, you had to set that particular user agent of twos. So I thought that was a pretty unique string, and sure enough, searching that string across social media profiles may or may not have found a couple people attributed to this particular cyber game. Just wanted to briefly touch upon the current statistics. Over three years, unique IP addresses that I've collected, over 28,000. Beacons received, so this is each like page refresh that's sending an image request, over 355,000. These stats were pulled yesterday morning. And I've identified over 32,000 C2s. Wanted to give a shout out here to this slick front end graphics that you see. Here's one of my good friends, Chris Court, who programmed that, so

he'll probably watch this later. Can everyone say thanks, Quark? - Quark! - Awesome, thanks. He'll get a kick out of that. I appreciate it. So in conclusion, some of my future work that I want to take a look at is really scaling out that automated sandbox. Cuckoo itself supports like a distributed mode. So I'm looking to, you know, get past the, you know, just doing like hundreds of samples today and take that up to thousands. Run several samples through, see what kind of callbacks we get, and then we can go back and reverse engineer those particular check-in protocols and fine-tune the beacon responses for that. The clustering of beacons, so if anyone in here has a data science background, I'd really like to understand how we could

apply some machine learning models, start clustering these threat actor groups into actionable intelligence to hand off not only to LE but also cyber threat intel teams. So that being said, I'm currently working on an API as well as like a MIS feed. So if you're into threat intelligence, the front end, the website snippet that I showed you earlier, you can request access to it. Right now it's just, you can log in and search for the data, but eventually we'll have like a malware submission where you can upload samples and we'll attempt to run it in our malware sandbox so you can hopefully try to get beacons back on that. So the short URL there, it doesn't go to a Rick

Roll or anything. You can hit up that short URL to a Google form. Just request some information to verify who you are or where you might work just to verify I'm not giving access to any bad guys at all. That's about it. Thanks for having me. Got through that pretty quick. Did anyone have any questions or concerns? Yeah, I would like to. So the question was, have I considered any other type of beacons beyond image callbacks? Yeah, that was one thing I was hoping to do with JavaScript. So with JavaScript, especially utilizing like WebRTC. So WebRTC is notoriously known to sometimes circumvent VPNs. So by issuing a WebRTC request from a victim's machine, if they have

a pretty crappy VPN provider, they don't filter those properly and you can get a true IP address back from that. But unfortunately, again, that's utilizing JavaScript, so it's kind of out of bounds. Yes, sir? I'm sorry, could