[00:00:00] Jack: And welcome back to security voices,
[00:00:04] Dave: Jacob, thanks for joining
[00:00:05] Jacob: us. Great to be here.
[00:00:08] Dave: All right. So a long, long time ago, which I think was at
least seven, eight years ago, not sure how long it was, but there was a
little south African born company called that did services and a whole
bunch of stuff. And they also did this thing called think scapes where a
round of.
All the things that were going on at the conferences. And it was really
cool, but it was paid for, and a lot of people liked it, but for many people
wasn't accessible. Of course, you know, we've had Haroon on previously
who founded. Thanks. And recently think scapes came back in just in
time because there's a budget Cleon conferences and a bajillion plus a
bajillion different talks.
So Jacob, when we asked to ruin, like who should we talk to about think
scapes, who's the brain behind it. You were attacked. Did you join?
Thanks to do thanks scapes. Or was this part of the package or was it
shoved at you unceremoniously after you joined? How complicit are you
in this ma'am
[00:01:16] Jacob: yeah, this was definitely part of the package.
A large part of my role is to make sure that things scapes is the source
for curated research reviews and. Uh, it's a large part of my role as the
head of the thinks labs. Cool. And
[00:01:30] Dave: you joined from AWS, right?
[00:01:33] Jacob: That's correct. Yeah. AWS security. Cool. Cool, cool.
What were you doing for AWS? Managing a couple of teams.
I had one that was looking at all things security from the hypervisor to
the firmware, to the hardware of AWS offerings. And the other was
looking at the open source supply chain, looking at how to find and fix
vulnerabilities and protect customers who use it directly through AWS or
it's indirectly from upstream.

[00:02:01] Dave: Got it. And how big of a culture shock and just shock to
the system is going through. The Goliath of AWS down to little thinks
[00:02:12] Jacob: it's a big change. It's a big change in many different
ways. I've always worked generally for small companies until I went and
worked at DARPA, which is a fairly large organization within the DOD.
AWS is my first large company that I've worked at going from that to
thinks well, there's a lot fewer meetings, much smaller team and much
smaller infrastructure. But it's nice that you get to know all of your
coworkers, much more intimately. And it's also very nice at AWS. I had
employees on four different continents spanning the majority of the
world's time-zones.
So now it's nice that I only have one other time zone that I need to deal
with in South Africa.
[00:02:53] Dave: And what do people get wrong about AWS? What's
different on the inside that folks on the outside wouldn't suspect.
[00:03:00] Jacob: I think that AWS has figured out that there is not just
the scale in terms of lots of computers and everything that takes to
orchestrate that.
But also how do you scale an organization as well? Which is the softer
part, which is where a lot of organizations really struggle.
[00:03:19] Dave: Hm. So in spite of what you might've heard, they
actually get things like management practices, right? At least some of it
in HR. And so. I
[00:03:29] Jacob: would say that it is maybe not necessarily uniformly
distributed, but there are definitely strong managers out there.
And that there are people that are definitely doing pretty amazing things
on behalf of their customers and the products they're building.
[00:03:45] Dave: Look, how big of an organization are they at this point?
How many people work there?
[00:03:51] Jacob: I wouldn't know. Actually it's uncountable large, uh, at
least without writing a Python script to scrape El dapper.

[00:04:00] Dave: Yeah. Yeah. Which we'd be impressed, but it also feels
unnecessary. I mean, I'd imagine it's just like any huge organization
there's pockets that are awesome. There's pockets that aren't so great. I
can't tell you like our recent experience working with the data protection
team at open Raven, they've been great to us.
They were actually really pretty nimble to work with. We couldn't have
asked for anything more and I think their customer service and. It can be
a little difficult at times. My experience, you can always get to the right
people. So I have nothing but positive things to say at this.
[00:04:33] Jacob: It was very fun to work there because there are kind
of the right people for any question you have that are there.
So I was learning the rust programming language and in the Russ slack
chat are many of the creators of the open source rustic community who
were hired, same thing with another programming language, Daphne,
which is a formally verifiable language. So it's really neat to be able to
have those type of technical resources at your fingertips.
[00:05:00] Dave: Cool. Cool. All right. So. There is a stat in here that it
says in 2019, the year the world fell apart, thinks tracked almost 7,000
talks, 6,940 to be specific across 1700 conferences in 2020. Thanks
tracked 5,313 talks. So. Across slightly more than 500, mostly virtual
conferences. So a huge drop-off in the number of conferences as switch
to the virtual format, but not that big of a drop-off in the number of talks.
And I think the reasons for this are pretty obvious. I don't think there's
anything that's kind of earth shattering about that, but what is 2021
[00:05:44] Jacob: local? 2021 is definitely seeing a resurgence. So I just
came back from besides Kansas city, which was supposed to be in
person last year in 2020, they had pushed to maintain that in-person
format and they just happened in-person in 2021.
So there was a lot of conferences that have pushed to 2021. Some are
still saying virtual, some are doing a hybrid format. And so I think we're
tracking. Just under 300 for this quarter alone in 2021. So it's a
significant bounce back as the world is starting to slowly return to
whatever normal may be.

[00:06:22] Dave: And Jack is how it's looking. I was looking across
besides in general, as you've been watching this.
[00:06:28] Jack: Yeah, absolutely. Last year, there was a feeling I think
that we need to be cautious for a couple of months and then reality set in
and people pushed off and pushed off. People have come to terms with
the fact that, uh, well, we're going to have to figure out what what's right,
what the new normal is.
And so last year there was a lot of confusion this year. A lot of people
were really hoping to be in person and have struggled as depending on
where they are in the planet. As the Delta variant has torn things up, but
people are really trying to get back. People really want to be back in
person. And so there have been a handful of pretty good sized besides
and other conferences.
That have come back and done at least partially in person. The, besides
in Canberra early this year was a 2,400 people, I believe. Wow. Yeah,
that was seventy-five percent of capacity. And it was at a point where
Canberra was pretty clean and they had, uh, you know, protocols in
place. And as far as I know, there were no infection incidents from that.
There were only a handful from Devcon even, which was kind of
surprising. It was really. Unfortunately, one of my friends did get a mild
case, but it, people want to see each other. The technical content is a
critical part of the conferences. The meeting people, the networking, the
social aspect, but also the business networking aspect is critical.
As you know, TAFE in a startup. Sometimes you just got to see
somebody's face to know whether or not the pitch is landing.
[00:07:56] Dave: Yeah. The things that people will tell you over a beer in
the hallway that they won't. And for a young company, you know, I was
told this stat, I think. But about 50% of the usual leads come from
events.
And I think that's been one of the things that has been really hard for
young companies during the pandemic is lead gen just kind of fell off,
you know, with respect. Uh, you, you know, you have to earn every lead
you have by like creating great content and running small events and so
forth. You just can't show up in an event and run into people.

Or attend and get a booth and so forth, which I say is probably always a
bad idea. I don't love booths, but having said that it's made it really hard
for us baby companies to do the things we normally do, but it strikes me
mentioning Canberra. Like that was probably all Australians. It's so hard
to get into Australia now with their quarantine requirement.
And, you know, it strikes me that like I'm betting there. Weren't a lot of
people outside of Kansas city who came in to Kansas city for besides,
and it was noticeable the lack of international presence at black hat. I
mean, I think the one thing that we've really taken a hit on is feeling like
we're an international community from a cyber perspective outside of
Twitter and so forth.
It's like the normal interactions you have with people outside your
country. Other than stuff that happens in the Twitter verse and so forth.
Just, it just isn't there. Do you guys agree with that or do you see it
differently?
[00:09:26] Jack: Yeah, I do. And I, I want to hear from Jacob, but I just
want to plug something of her ruins since you said.
Couple of years ago, Haroon wrote up, uh, his take on having done RSA
with all of the baggage and things that get said about RSA. And he had
a great article from the perspective of a small company going to RSA for
the first time. And if you haven't read that, uh, it may change your mind
about what RSA is or how, who it works for and how it works, because
it's fun to make fun of some of the excess of, of RSA, but that was a very
insightful.
[00:10:00] Dave: Cool. Cool. Cool. So the obvious question is, so you
guys have chunked through all those presentations so far this year. Like
how many presentations have you personally sat through and kind of
ingested Jacob?
[00:10:16] Jacob: Yeah, so we have to triage otherwise. I don't think
there'd be enough time for me to go through them all.
We go through some conferences that are listed as security
conferences, don't have much research content, you know, things like
CIO summits, those we're not going to get the breaking research that
we're looking for. So we can pretty quickly allied those from our, from our
list. Then we go through and I would say the last issue we were looking

at specifically conferences that were there during the virtual format,
which.
I personally found that I zoned out very quickly in virtual conferences. I
think without that personal aspects of it, meeting people and having that
hallway track, even though I was supposed to be session sharing, I kind
of subscribed for the time I was session sharing for one conference and
then I signed off and didn't attend very many other talks.
I think that's, that's a bit unfair to the researchers who just happened to
be publishing at that time. And so I really wanted to go through a lot of.
The top tier conferences and then a little bit further down into some of
the more niche areas. And so I think we went through well over a
thousand talks with the full abstracts and anytime we didn't feel like it
was clear from that we'd read the paper, we'd read the slides, we'd
watch the videos.
So it was a significant amount of content to go through. I think that was a
little bit more content in terms of just sheer numbers, because we were
trying to look. The period of COVID. So it was a little bit longer than our
typical quarterly format. We're going to aim to release our next one later
this year, before the end of the year.
And that will just be covering conferences a little bit more in depth from
this quarter.
[00:11:54] Dave: How many of you think you've been through
personally? A hundred, 200.
[00:11:59] Jacob: At least a thousand, I built little Python scripts to
game-ify it. So I could do it a little bit more quickly. Okay.
[00:12:06] Dave: So first things first, I know a lot of us would love to get
through more reading, more research, more papers, and so forth.
What have you learned? What tips and tricks since you've had to feed
yourself a mountain of stuff, what tips and tricks do you have just for
information processing on this stuff? If someone was to say, Jacob,
Teach me how to ingest massive, more research. What would you tell
them to do? What are your tips and tricks?

[00:12:33] Jacob: Yeah, so I would start with clustering, the projects into
different sub fields and security. So I was on the program committee for
used next security. And so I was able to kind of get a good idea of where
the cutting edge research was. I had a couple different fields. I was
there. So adversarial machine learning, deep low-level, you know,
hypervisor or CPU security, and then general network security, where
the three areas that I was felt pretty confident going into this project.
Kind of knew what was going to be published and what was at the cusp
of those fields. And then for any of those, I could then turn a piece of it
into my mental model and say, what's the Delta from my generic
abstracted having read 50 or 60 papers in very detail and really
understanding that what's the new thing here.
Is this something that's worthwhile calling out or is this something that
we can kind of lump in with what's already happening out there? And so
trying to look for. The dark horse in the running where, Hey, no one has
ever looked at that before. And that's really interesting. Or there are a lot
of people looking at this area, we'll pick one or two exemplars, but you
know, this is something that's kind of a field of research.
That's, it's definitely gaining momentum. And so that was kind of how I
was able to slice it up in my mind. And then again, I had to gamify it
because it can be pretty dull reading through hundreds and hundreds of
abstracts. Right.
[00:13:56] Dave: Before we get into some of the specifics, which piece
of research do you remember the most, which ones stuck with you?
And it can be for whatever reason.
[00:14:05] Jacob: I definitely liked this word. I think it was by trend
micro, where they created an entire company, fake factory with real
SCADA devices, the whole corporate persona, you know, slick about us
board sheet. They actually got themselves geo located on Google maps.
So you could find them and they created this whole company that was
all a honeypot, just to see what would have.
And what I thought was the most entertaining of it is they had
screenshots from various computers and their virtual infrastructure
where attackers had broken in and were insulting these fake people

saying you should fire that guy. He's terrible at it because they had
pulled, you know, the CIO or the CISO's information off of that.
So it was definitely an interesting, and eye-opening piece of research.
The research itself was fascinating to see how. Slowly initial attacks
happened, how they never pivoted to the ICS SCADA, the operational
side of the factory. And no one was ever a kind of attacking that, which
is what you think when you read the news that the nation states are
going to come and break all of our SCADA stuff.
In fact, over I think, six months, no one touched it at all. They were just
going after basic ransomware and malicious, but relatively mundane it
type attacks. Interesting.
[00:15:24] Dave: Interesting. Did they create like fake LinkedIn profiles
for these people and all of that to how far did they go with.
[00:15:31] Jacob: It went pretty far to the point where yeah, you could
search for this company, you could get about them and you could get
customer testimonials.
You could figure out where their office, where they showed up on a
Google maps. I think they had some pictures of their offices from there.
So it was pretty in depth on the corporate persona side, the it side was
lots of virtual machines that looked like a real company. And then on the
SCADA side, they actually built a fully working factory, but with no
actuators, so everything.
Yeah, I'm not going to blow up or catch on fire, but it had all the right
controllers and all the components there.
[00:16:05] Dave: Very cool. In terms of just presentation itself, is there
anybody who, who knocked your socks off, who also equally sticks out in
memory?
[00:16:17] Jacob: I've seen a lot of great presenters, some great
keynotes, which is kind of a rare.
I wasn't included in this edition because it happened prior, but I thought
that Thomas Deleon Saigon talk, which was, you know, a relatively non
necessarily focused InfoSec conference, it's more about kind of like a

NATO nations, strategic security conference talks about complexity and
the externalities of cheap complexity.
And I thought he was able to break down pretty detailed. Interesting.
Security relevance and security problems that come from that complexity
to an audience of a lot of movers and shakers in the geopolitical space.
And I thought that was a, a really compelling talk. It's one of my
favorites. I've read it numerous times and I watch it occasionally to keep
myself refreshed on, on his takeaways.
[00:17:09] Jack: Since you touched on it, let me ask about that. One of
my pet peeves is the non keynotes. They call something a keynote, but I
have maybe it's just cause I'm a cranky old man, but I expect keynotes
to be keynotey make me think, make me change the way I think provide
insights or something that alters my perspective or it goes way deeper.
And I don't expect to keynote to be the same thing that I would see at
the local security meetup on Thursday afternoon at the holiday Inn. And I
see a lot of that kind of recycled stuff. You know, recycling talks is one
thing, but the keynote thing gets to me. Do you have any thoughts on
that?
[00:17:51] Jacob: Yeah, I mean, I think for me, the keynotes need to
strike a very delicate balance between abstracting bigger trends that
encompass much bigger work than they could do alone.
But also not getting away from something that's grounded in facts and
figures and, and actual work that they can speak confidently on. And I
think the ones that I've been the most interested, the ones that stick with
me throughout my conference attending and speaking career have
been. Help you think about technical things from generally an economics
perspective.
So Haroon had a market of lemons and security keynote that I thought
helped me change my mind about how I think about the security product
space. Again, the externalities of complexity in the hardware supply
chain and the notions of shift left and how that changes the supply chain.
That was something that Thomas talked about in his case.
Those types of things I think are what really stick with me. It wasn't a
keynote. It was a presentation at DARPA of new project rate X, looking
at the power grid and securing the power grid and just the economics

behind that is that there's regulation saying these utilities, which are
heavily capitalized.
Very regulated. They can only charge a certain amount. And so they can
charge a little bit extra after some catastrophic event. So they're actually
negatively incentivized to invest in security early because they can buy
all that nice fancy stuff later. And so it's really striking when I see
something that is technical, but then it's flipped into a, you know, a
market or an economics problem.
And.
[00:19:28] Dave: Can I play in it back to you? What do we expect out of
keynotes? You know, we expect something that challenges a
perspective, especially a widely held one, or take something that's
complicated and breaks it down and kind of breathtaking simplicity. The
best example of that. Actually, if either of you read sapiens by Yuval
Noah
Harari,
[00:19:50] Jacob: I've read homo Deus.
[00:19:52] Dave: I listened to it on audible and the first minute or two of
the book, he breaks down all these disciplines and what they are and
explains things like physics and chemistry in ways, real like, oh my God,
that's what everything is and how it fits together. It's kind of near
immediate payoff for the book.
And I think great keynotes do that too. It takes something complicated
and gives you a really, a much better mental model for it or challenges in
existing. And it gives you a new way of framing it. And so on, on that
sound about right. I mean, I don't think a lot of keynotes were kind of
breaking any research.
That's not what they're about.
[00:20:31] Jacob: I just gave a keynote my first ever at, besides Kansas
city. And it was very difficult. I felt like an absolute fraud going into it
because usually I'm used to talking about my specific research and I feel
very comfortable talking about something I've spent months and months
working on.

It's very difficult to go in and talk about. Larger trends. And so, you know,
either you need to have a novel perspective, which I think is very difficult
and a little beyond me or an ax to grind about some bigger problem that
you're seeing, and you're not seeing anyone address, but yeah, it's, it's
very, very difficult.
And I don't know how good my keynote was, but I've seen a lot of bad
keynotes and very few good keynotes. And so that's why it was
memorable to me because there's probably all the conferences and all
the talks I've seen. One handful at most of good keynotes that I think will
stick with me.
[00:21:22] Dave: Um, what was your keynote on it?
Begs the question.
[00:21:26] Jacob: Yeah. So my general thesis was that we've kind of
evolved and we build a lot using the physical constraints of the laws
around us. So gravity and density, et cetera, to build constraints, to
simplify things. So it's very easy to be. Uh, building or a bridge. And as
long as some assumptions holes, you can rebuild that somewhere else.
And the fact that you can generalize that into knowledge, which you can
concisely share with people allows us to build these fields of engineering
and in software development, you can build an MCs you're painting. And
I've seen software that is very much like an MC Escher painting, and we
don't have any.
Laws of physics that ground us, but act as a speed limit for our own
complexity. And so we're very quickly entering a world where between
software and machine learning, we are building machines that for the
first time ever will not be able to ever know. So as a statistic, you use the
largest number you can think of.
So 10 to the 80 is roughly the estimate for the number of observable
particles in the known universe. So it's a pretty big. If you go in and look
at the windows 10 GPO configuration for just a standard, not on a
domain, windows, 10 computer, right out of the box. It's 10 to the 1,260
ways. You can configure that just to the operating system before you
install any software.

So that is a truly intractable number. And so we've built this literal chaos
machine and that's just the operating stuff.
[00:23:01] Dave: Yeah. You know, he knew, look at something like
infrastructure as a service in AWS and how complex it is in general. Can
you add in the number of services and how fast the services are
changing and so forth?
The future is trending towards more complexity, not away from it by any
stretch of imagination.
[00:23:22] Jacob: Yeah. And there's a emergent complexity all over the
place. I mean, yesterday, Facebook went down because of BGP. Some
of the folks from the Lang sec community have found that BGP is a
distributed Turing machine.
So it has the wonderful properties of the halting problem. So you can't
even verify certain routes and certain properties about routes because
it's a touring complete distributed system. So the complexity that we're
going to run into, and I think configuration is. Another externality in terms
of complexity, where 70 ish percent of vulnerabilities that I've found or
found from other sources are configuration inspired or configuration
based.
And it's something that we don't really have the checks for. We can do a
lot of secure development life cycle and, you know, fuzz all the things.
But if you configure the systems wrong or you have multiple vendors that
don't integrate very cleanly, you're still back at square.
[00:24:20] Dave: Let's hop into some of the research itself here.
And there's a comment at the beginning. And I have to say I was
somewhat saddened that in the beginning. I didn't get past this. Some of
the intro before I encountered something, I didn't, I didn't know. And it
looks like it's been five years since think scapes was published. So last
one was in 2016 as I look at my notes here.
And the comment is the rise of speculative execution, vulnerabilities and
attacks. Jack, do you know what a speculative execution vulnerability is?
[00:24:53] Jack: I read something about it and I've now forgotten.

[00:24:57] Dave: I had Jacob break it down for us. What's a speculative
execution
[00:25:01] Jacob: vulnerability. Sure. So these, I think were made most
famous by spectrum meltdown, which has now I think, grown to a class
of 40 different, unique vulnerabilities in this.
So as a way to continue to squeak around Moore's law and make
computers faster and faster. When a CPU is confronted with, say a
branch to go off and do either function a or function B it may take many
hundreds of clock cycles to get whatever the value is that would change
that branch. And so it will run both branches in the time that it takes for it
to figure out which one.
And then. Delete, whichever branch was wrong. So it will essentially run
both of them. And one of they're called specular V because you're not
sure you're making a speculation that either branch a or branch B will be
run, and then you are supposed to roll back and throw away essentially
all of the side effects that happened when you went down the wrong
branch.
And so that way at the end of it, you've left with the correct execution.
And now. The researchers behind this field have found that there are
many side effects that persist or are not necessarily rolled back entirely
correctly or have other impacts like timing. So you can derive a timing
side channel.
And so this has allowed you to essentially find execute and exploit bugs
in code that doesn't exist necessarily. And then look for those side
effects after. So that type of work is a little bit. Blowing my mind as well,
but it's something that we're seeing in a lot of conferences and. I can't
remember the total sum, but it's something like there's the microcode
patches, the operating system patches, or something like 60 to 40%
performance impact if you want to mitigate most of those vulnerabilities.
And so it's a, it's a significant performance costs and stepping back
many, many years, especially in shared environments like the cloud
where you need to be worried about multi-tendency. There's a significant
performance cost there, which with the cloud now means that there's a
cost cost with that as well.

It seems very arcane and out there, and it's, you know, these things that
happen for a few clock cycles, but it's something that drastically impacts
how companies like AWS and Azure and GCP need to deploy and
design their systems.
[00:27:34] Dave: It's an attack that really matters in multi-tenant
environments. And. I'd argue that it's not just infrastructure as a service
providers, but it's probably also a lot of SAS companies too.
When you say
[00:27:46] Jacob: SAS companies, the other concern, the initial concern
was actually JavaScript where you could be running an attacker
workload is leaking memory outside of your browser. So they can kernel
memory over Java script or. Pulling like your password manager, data
out few JavaScript to those. So that was where the early initial attacks,
any time an adversary can kind of drive a workload, it's not necessarily
an exploit in the sense of, you know, a memory corruption.
It's not breaking out of the sandbox, but it's allowing them to reach
beyond where they should be.
[00:28:19] Jack: Wow. Good thing. Hubble doesn't run
[00:28:21] Dave: JavaScript. Yeah. Sorry had to. Yeah. Yeah. Well, you
know, it's kind of funny. I was going to get to this later, but since it came
up, follow on from last episode, is it talks about geo versus Leo based
constellation use and satellite eavesdropping effectively is kind of the
title.
So we might as well jump into it now. And it's talking about basically old
school TCP timing attacks, and if light you care to shed on that, Jake.
[00:28:52] Jacob: Yeah. So at first, I just want to say I I've worked with
Frank, Frank lb. Who is your guest? Last time I transitioned some work
from him when he left DARPA to myself.
So, uh, it's funny that I keep bumping into him. So that was interesting
work in the sense that we make assumptions about typical networks. So
things like VPN is a nice solution to deploy, especially in the work from
home and. But with high latency, very low bandwidth are very expensive

networks. Some of those kinds of turnkey out of the box network layer,
things don't necessarily work.
And so they are generally turned off. So this research essentially found
that research by James PowerVR found that for about $300, you could
intercept communications between critical infrastructure like aircraft in
route ships, IOT, sensors, et cetera. And the majority of it wasn't
necessarily encrypted because the standard link layer encryption would
cause poor performance.
So he proposed looking at more application aware that doesn't
necessarily cause the same increases in latency, but is a little bit more
difficult upfront, but it's a better solution. Now, as we move to Leo, I think
that a lot of these things are going to be. You could have a VPN on
Starlink when you're getting a a hundred megabit per second down.
It's a lot more difficult when you're talking about some began network
that's incredibly, incredibly slow, or you have seconds of roundtrip time.
I'm personally on DSL right now. And I can't wait for something like star
link, which will be a massive improvement, but I've been on the low, the
geo satellite networks before.
And they're pretty pokey. It's an interesting thing to see what happens.
So if as long as companies can move on to those Leo constellations
quickly, I think they should be able to deploy the standard network
protection capabilities. But with all of this stuff, there's a long legacy tail,
especially in these environments where there are sensors distributed out
in places that are very hard to get to deserts.
Antarctica and the Arctic where it's not very easy to go out and just drop
in a Starlink terminal and upgrade your network.
[00:31:05] Dave: Yeah. I mean, we talked about some of the really old
satellites that were up that are up in Frank, you know, stuff from the
1950s and so on. And then we didn't really talk that much about the base
stations and how aged some of them are and so on.
So it's kind of an interesting compliment to that conversation. Okay.
There's another one here. It's kind of interesting. It's around E BPF,
which is mentioned by Zach from Yelp ages ago. It was an EBP F foam.
How bad is it? So it seems like he BPF and I think it's enhanced

Berkeley packet filter. If I remember correctly, incredibly useful for
tracing and so on.
I think it's at pretty heavy adoption is how it seems, how bad was the
volume that was found on this.
[00:31:55] Jacob: Yeah. So it was a local privilege. I think it was limited.
So there are some distributions that allow untrusted, EBP F loading. So
a non route user can load an EDPs function with certain guard rails in
place that is not necessarily the standard.
And again, it comes back to the whole configuration point. That's
something that distribution, I believe Ubuntu was the largest. So the, a
bunch of distribution allowed for these nonprivileged. Users to load EBF
functions and then the vulnerability bypass some of the checks there
that allowed them to execute and essentially get root or Colonel
privileges.
So it was quite bad in the sense that it was, you know, an LPE, but
again, it was only on certain distributions and only when configured in
this environment and only when there's an untrusted user running there.
So there've been other EBP F exploits. There will probably continue to
be some, but it's, it's something that I think needs to be continuing to
focus because there's a lot of adoption and there's a lot of push for it.
And then people need to realize that it's not a magical, secure
environment. They need to consider how they configure it, how they
deploy it and that the assumption of what does happen if there is, and
there likely will be another vulnerable.
[00:33:11] Dave: Let's go onto a less serious one here. This was one of
my favorites, light commands.
Laser-based audio injection on voice controllable systems. And here's
how I understood it. Basically, you can use a laser to trigger somebody
else's Alexa, Google home device, whatever it is, and get it to do things
on your behalf without saying a word, but you can trigger. Basically it
like, as if you said something, but with, you know, the laser that you
would otherwise use the tournament and your cat.
[00:33:45] Jacob: Yeah. So this was very much like mission, impossible,
the microphones that are used in those home assistant devices. And a

lot of these micro electronics have these interesting kind of cross
modality actuation. So you can, you can trigger it with voice, but also it's
so sensitive that you can trigger it through, you know, a photo of.
So you can generate the same amount of current. And so yeah, you can
essentially silently go in modulating that laser to say, Hey, Alexa, unlock
all the doors or at two in the morning, Hey, Alexa set off, you know, as
many alarms as possible. It was very interesting that you had that kind of
physical pivoting from one modality of light spectrum to acoustics, which
are, you know, sound waves.
So I'm sure that there are others as well, but it was a very cute way to
wrap that into something that seemed like a very clever Hollywood stunt.
And I'm sure, you know, in the next 10 years, they will be a movie where
someone does use a laser pointer to MacGyver their way into a smart
building.
[00:34:50] Dave: All right, Hollywood.
You heard it here. First. Here's one that Hollywood won't be taking. And
this was my favorite title, device, agnostic firmware execution as
possible. Normal enough, a concolic execution approach for peripheral
emulation. I have never heard the word concolic before. It's a new one.
[00:35:11] Jacob: Okay. So can call it, I think is a port tamanu, is that
the right term for this of concrete and symbolic execution?
Ooh. So concrete execution is when you're running program, typically
standards that you have the right value. So you know what the variables
are. You've gotten user input, you're running the program, how we run it,
all of our software today, symbolic execution is where you replace. Many
or some of the variables with a symbol, and then you can execute the
program.
If you get to an interesting state, say you're running a program and it
crashed. Then you can use a SMT solver or, you know, uh, satisfiability
modular theorem solver to go in and solve all the symbolic constraint to
generate a concrete input. And so this is used to get very high coverage
or find really interesting parts of programs for vulnerability research, or to
prove that there are no vulnerabilities in certain areas.

And so can call like execution switches between the two to be able to
especially expedite the process. Every symbolic variable you have is a
lot of solving time on the SMT side, right? So we're essentially racing up
an exponential curve there because satisfiability is an NP hard problem.
So very quickly you end up taking 99.7% of your time when you're
running something symbolically in the solve time.
So if we can run it partially concretely and then switch back, now you
can start to get deeper and deeper into the. So what this research did
was looking at. If I had a raw binary say I ripped it out of a printer or
someone's their desk. I don't know necessarily what the hardware
devices are and how that software is trying to reach out and kind of
bootstrap itself.
This was something of, how can we figure out what responses from the
hardware this raw firmware is looking for, and then be able to give it the
right values to keep it to go. So you could essentially boot this up.
Having never seen the hardware. It had no idea what it is, which is a big
deal despite the very long time.
'cause now you can start looking at scaling up your vulnerability
research for all of these devices, which generally have been something
that's a manual one-off, you know, you're soldering on to J tag ports.
You're manually debugging these things. Now you just grab it, throw it in
the cloud and I'm sure you're going to be reigning zero days on these
things.
[00:37:43] Dave: Oh, showed on show. Don's going to be so
[00:37:46] Jacob: delighted. It's an interesting space. I have not done
any real embedded work. It's an interesting space where it's easier to
find bugs than it is for people to tell their customers because there's so
many steps, you know? So you may buy a device from vendor a who
then white labels, the products from vendor B, who then uses IP from
vendor C.
So if you report to vendor C saying, Hey, I found this vulnerable. They
don't even know who the customers are and that can be proprietary or
other types of kind of trade secrets. And so at the end of the day, that
customer is kind of in the dark. They don't even know if they're impacted
and then it's a multi-party problem of trying to get patches or medications
deployed.

So it's an interesting space and I'm, I'm a bit concerned now that you
know, this type of work is making it very easy for us to find it without
necessarily making it easier for us to pay.
[00:38:37] Dave: Oh, there's so many, so many interesting threads to
tug on here. Let's go to, there is a comment in here about transitioning
from attacking clients like Google Chrome, popular, formerly juicy target
to targeting SAS applications themselves.
Office 365 was mentioned golden SAML. And so on. Any more color on
that or things that you would call.
[00:39:02] Jacob: Yeah, I think there's been a lot of investment on the
client side. You know, things like Chrome books and other devices. Your
browser is, I mean, I'm looking at my computer right now. I have two
browser windows open with a whole host of tabs and then.
Essentially a browser app that is running locally for visual code. So
realistically everything is moved into the browser from what I'm doing,
and that has really pushed and helped centralize the focus for teams like
project zero. And those poned own targets are now very much browser-
based focus. So I think, you know, on one hand it's a lot harder to exploit
browsers because there's a lot more resources being focused on it.
We're getting us kind of a monoculture in the sense. Seems to have
somewhat positive outcomes. And you're also getting to a very
complicated world with SAS applications. There was an interesting talk
that came out after this looking at hybrid active directory. So you have
Azure cloud, but you also have your local network.
And so you kind of have two masters for your windows environments
where you have, you know, some servers and resources. The Azure
space, which then tie in very nicely with your office 365 and your, your
SharePoint and your teams. And then you have your local infrastructure
to support, you know, your kind of back office things.
And so I think we're seeing both people realizing that the browser might
not be the best place to go, but you can now go in and break into the
SAS applications and compromise a large part of a supply chain. So
you've seen that with maybe not necessarily SAS, but solar winds. There
was also some CICB pipeline break in.

So Travis CEI I believe was compromised and there was one before. I
can't remember what it was called that did linting and code checks for
you. You know, you break into that and now that's running on code
pipelines around the world. So I think they're seeing these are juicy
attacks that don't necessarily have the budget of project zero to go in
and focus.
[00:41:06] Dave: It strikes me first off browsers are just so picked over at
this point to state it almost in vulgar terms. And you've got SAS
applications at the same time that are growing in complexity. Like look at
all these low-code no-code solutions that are effectively full on
development platforms, whether it's air table or web flow or other things
like that.
There's a ton of attack surface. And there's so many people using. It
stands to reason that they're a logical place to go next.
[00:41:38] Jacob: Yeah. I mean, with the cloud and the kind of SAS
model, is that a company of two or three people who may not have a big
security background or may not have the funding to hire, you know, the
top tier project, zero type researchers for their team can reach in an
audience or, you know, a client base that is significant enough for
attacker to try to compromise them, to get access.
I mean, even if you have. 1520 a hundred customers. If you're in there a
hundred different networks, the attacker can go after, you know, the
team of three people building off of a low code or a very naive
development environment that doesn't have the maturity and then they
can use that to pivot. So it definitely makes sense.
I think we're going to see more of that.
[00:42:20] Dave: Here's one of the fun one. That's entirely different.
There is a concept that came up in, um, hopper modeling and detecting
lateral movement. And it wasn't about technology at all, but it was
conceptually about having an alert budget and just a finite kind of
constraint on how many alerts that one could possibly consider.
And then creating an environment in which you satisfy that budget, but
no more I'm stating it. Probably not in the best way, perhaps clumsily,
but can you talk through it a little bit? It was an interesting concept and it
felt like one that was kind of pretty obvious in hindsight.

[00:42:59] Jacob: Yeah. I think there's definitely, you know, awareness,
especially from people who are ever worked in socks or, you know,
managed socks that there is this decision fatigue and alert fatigue.
Right. If you get. Hundredth alert for the day. You're probably not going
to have the same reserves as maybe your first or second alert for the
day. And so being able to tune that saying, okay, Alex, This many false
positives, but that means I make, you know, I may catch the really juicy,
the real ones as you can tune that saying, okay, my organization, this is
how deep my SOC team is.
This is how mature the practices. I'm going to be able to tune that to a
way that doesn't overwhelm them. Right? So many tools you plug in and
they create value, or they sell themselves by how many alerts they get. I
would say that thinks in our Canary product kind of advertises itself as
the thing you'll forget, you have, until it saves your bacon.
It's not sending you a hundred alerts today reminding you that you've
paid for this very expensive device or this SIM. So I think this is a nice
way to realize. The people who were actioning, these alerts have human
capacities and designing that into the machine learning algorithm to
make sure that they're balancing the possible false positives with the
capabilities of the team, getting them because.
If you will, or on every single thing, you'll get a hundred percent
coverage of all malicious activity, but you've now been kind of worthless
unless everyone is going to look at every single action that happens on
your network. So it's an interesting balance that I've seen and I've seen it
happen before.
And it's a nice metric that I think I'd like to see more often, especially in
the vendor space of how you can tune that for your organization,
because. Uh, local school with one or two, it, people getting a hundred
alerts a day is not the same as someone who's got the same integration,
but with, you know, a 24 7 stock security operation center that has 50
people working in it.
And so this was nice that they were able to make that an explicit metric
and design that in.
[00:45:04] Jack: Yeah, that's cool. I read that book as a kid to SIM that
cried Wolf.

[00:45:14] Dave: Yeah. I mean, the industry has grown up a little bit
when we have concepts of cognitive load and neuroscience making their
way into like a socks, which are newly established and alerting. I mean, I
wouldn't say we're all grown up, but that's kind of cool.
[00:45:31] Jacob: The one that really hit me was. User experience
studies and surveys into how reverse engineers versus vulnerability
researchers use different tools.
The fact that we have university people doing IRB surveys and analysis
of people do. What used to be mostly illegal, you know, cracking
software or finding bugs to figure out the similarities of the process
engineering. I think that's really a Testament to how far we've come in.
The sense that, you know, it's now a very multidisciplinary field.
I
[00:46:04] Jack: go back to some of the, the old timers in the industry,
Willis ware and others have in the sixties and seventies observed. If we
don't factor in the fact paraphrasing people are using this stuff. If we
don't take that into account, it's not going to work well. That's distilling
great wisdom down to a dumb sentence.
But I think as an industry, we're not universally there, but there's more
and more sign of oh yeah. People that matters.
[00:46:32] Dave: Yeah. Yeah. I mean, and Jamie got to some of this
with how she was talking about security at ASU and what she's doing
over there. And how it's incredibly, what they're teaching around security
is incredibly multidisciplinary and all the different folks involved in it.
And so on, it feels like academia is maybe leading this trend and we're,
we're all waking up to it more and more given the pandemic, just all. Toll
on people's lives. I mean, we just have so much less plasticity because
of the load of just the pandemic and everything else that came with it. I
think it catalyzed maybe a more general awareness of perhaps what
academia realized
[00:47:11] Jacob: earlier.
Yeah. I'm kind of shocked at how, you know, baby steps we've been in. I
did a red team and it was an environment where the human's actions

were legally mandated. So if they saw the red light flash, they had to
push the green button and that allowed us to jump air gaps between
separate networks. But I haven't seen a lot of kind of whole system
modeling, even for the very constrained, you know, not trying to enter in
the cognitive world of an actor.
This person legally has to do this thing. Right. And that was, that was the
basis of the movie Sully. Right. Did he follow that checklist? Legally
inaccurate and his whole life was basically based on that. And so it's
fascinating that we're seeing it start to happen in, in the academic sense.
It'll be interesting to see when it starts happening, you know, more
broadly and you know, in the vendor space, the product space, et
cetera.
[00:48:07] Dave: Well, maybe it's the subject for a future.
[00:48:11] Jacob: By someone else by
[00:48:13] Dave: someone else. All right, Jacob, is there anything I
should have asked you about? I had a couple more things, but that feels
like a good part to kind of start to wrap up and maybe edge over into our
speed round at questions here. But is there anything else that was
interesting or just big that we missed that you done?
[00:48:34] Jacob: No, I think you covered it. I mean, every quarter
there's going to be new, interesting things. It doesn't detract from the
work that there wasn't featured or was featured in the past. So, I mean,
we could exhaustively go through this, but the whole point is, is that
we've done a lot of that work. There's a very short audio version about
20 minutes.
If you just want to get the gist and then the document itself isn't terribly
long. So no, I don't have anything that I feel like I'm dying to get out of.
Cool. Cool.
[00:49:01] Dave: Cool. Cool. All right. So we already know, we already
know what you've read that you like. That's usually the first question as
to what someone's digested and you have digested way too much, a 20,
you know, 500 Thanksgiving dinners this year, apparently of security
content.

What do you read for fun or what has made an impression on you
outside of the security field? A book, a poem podcast, an article,
[00:49:28] Jacob: a media. Yeah. So trying to think the last book that
had me kind of laying awake at night thinking was the three body
problem. Part of the dark forest trilogy. It's a fantasy book recently
translated into English.
The second book kind of was a little bit too close to home in terms of not
so much of the fiction and a lot more of the science. So that was a great
read. A bunch of us at the office at DARPA were reading that one before
I left. So that was probably. My most memorable reads lately.
[00:50:02] Dave: Uh, and I'm probably butchering the name, but it's by
shisha and Louis C I X, C I N Liu.
And it is, it's an extraordinary book. It is just, it's so clearly written from
the perspective of another culture in a lot of good ways, like the way that
they explain what happened to in the cultural revolution. And a lot of just
the perspective is so rich. And so does. What a great book. And you
know, it just, it pulls you in, it's a little awkward in the beginning, but it
just sucks you in and becomes a page Turner
[00:50:36] Jacob: getting used to the names.
And the naming scheme is very difficult at first, but then it definitely does
suck you in. Yeah. Yeah. I think,
[00:50:44] Dave: I think, I think it's going to become a movie or at least a
series coming soon. So fingers crossed. We'll see if they can pull off
dune first and then I'll start feeling optimistic. Speaking of optimism of all
the things you're reading, digesting and so on.
What gives you hope? What do you, as someone who's deep in the
bowels of security and has eaten way too much research recently, what
do you look at and say hot damn things are getting.
[00:51:17] Jacob: I think the programming language space is starting to
work to bridge the gap between relatively approachable and very
powerful and safe.

I think the initial languages, C and C plus plus gave you a lot of rope to
hang yourself with, but the knee jerk reaction to that things like cock and
Isabel and some of these formerly verified languages. Basically, we
require a PhD to be able to write hello world in them. And so, you know,
I'm seeing, starting to meet in the middle.
I was looking at a. Today I was programming some kind of cool stuff in
rust, and they've added some new features where you can do a lot of
compile time checks for things. So you can safely write a lot of functions
and you can encode your programmer assumptions into your, your code.
And then that way, you know, if you get hit by a bus and someone else
has to pick it up, they can understand that without necessarily having to
read comments that may or may not be actually.
And some of the very powerful type theories or refinement types have
made their way into TypeScript, which is kind of the new hip JavaScript.
So I feel like generally, no dot JS is a dumpster fire, but if we're moving
that community again, very approachable towards something that has a
little bit more of this, I hope we're going to trick all of these new
developers into not making the mistakes we made because you know,
our tools were, were so dangerous and easy to cut ourselves with.
[00:52:49] Dave: Wow. That's a great answer and a fresh one. We
haven't heard. Awesome.
[00:52:54] Jack: Yeah. I'm continuously amazed that we get so many
different answers. It's becoming hard to be a bitter old man with
optimistic, but I'm trying, don't worry. I'm not, not giving up yet.
[00:53:09] Dave: All right, Jacob. Thanks so much for your time. This
was great.
[00:53:13] Jacob: Yeah. Thank you.
[00:53:15] Jack: Awesome. Thank you so much.

‍