Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/118 Thanks!
OK. This is Nate.
He will do
talk about like responsible disclosure
and what to do and what not to do if
you find some kind of security,
vulnerability or something.
So give him a one plus.
The thing is on.
Awesome, thank you.
Thank you for having me.
This is my first time at CCC and I'm very
excited to be here.
So we are at the Electronic Frontier
Foundation.
I will start by say a little bit about
who we are and what we do.
We are a nonprofit digital
civil liberties group based in the United
States in San Francisco, California.
There are about 15 lawyers, and we have
a total of about 50 staff.
We do free speech, privacy
users, rights innovators rights.
We fight for a say in copyright system.
We fight for a sane patent
system.
We do legislative activism in
the United States, in Europe, all around
the world.
We write blog posts and
pertinent to this talk.
We represent coders.
I am part of Jeff's Coders Rights
project.
The other major contributor to the
project is sitting right in the middle of
the of the room.
We work to protect the rights of coders,
security engineers, developers,
everyone building a safer internet.
There are a lot of laws and
regulations and
difficult egos involved in the
pieces that that put together.
They comprise the internet, and we work
to help security
researchers, coders, developers
navigate all of all of those pieces.
This is, as I said, if first
time at CCC.
But this isn't our first time doing
this kind of work.
We f have
been helping coders do what they do
for a very long time.
I've been doing it for not quite as long
as most of the many of the people
at F, including some of the people in
this room.
But this this, as I said, this
is not my first security conference and
I know a very small amount, but I do know
something about about what I'm about to
say. Hopefully, fingers crossed
the theme of this talk is one size does
not fit all. I put it in the abstract,
and I'm going to say it a bunch of times.
What do I mean by that?
This
that this talk is titled
Disclosure Dues Disclosure Don'ts.
I did not title it responsible
disclosure.
I didn't title it.
Vulnerability reporting.
I'm not going to make any moral judgments
about whether you disclose
about how you disclose, if you disclose
publicly, if you disclose privately,
if you participate in a bug bounty
program. All of those choices are
yours to make and not mine to judge.
OK. The biggest disclaimer of the night
I am a lawyer.
I am not your lawyer unless
you already have me as your lawyer,
which I don't see any of my clients in
the room. But it's possible.
But I'm not your lawyer.
I'm not going to give you legal advice
in this talk.
The biggest reason for that is
when I give you legal advice, it has to
be in a confidential situation.
This is not confidential.
This is being streamed.
Hello online.
So it is not
possible for me to give you legal advice
in this environment.
However, feel free to contact if
info if dot org and
my email address will be at the end of
the slides. Nate at f f dot
org. It's pretty difficult for
help finding a lawyer if
it is possible that we could be
your lawyer, but we have a very long list
of very good lawyers who do this kind of
work, sometimes even
for free.
If does all of its work for free
and some of our cooperating attorneys
do that work for free as well.
So if you need a lawyer, you're not
going to get one right now, but
I can I can try to help you get one.
As I said, this talk is not going to be
me judging you.
What what you do is your business,
and it's my job to help
you do what you do
better, more efficiently and not get in
trouble for it. Hopefully,
also with this talk isn't I'm
not going to give you a formulaic
approach to disclosure.
As I said, the theme is one size does
not fit all.
They're for each
security vulnerability, and
there's going to be a different approach
to reporting it. And there's all sorts of
reasons why that's true.
And of course, this talk will not be
legal advice.
I am going to try as hard
as I can to not give any legal advice.
I am going to let you ask questions.
My voice, I've been sick for a while
and my voice is not going to hold out for
an hour, so there's no way that I can
talk for a full hour.
So I will let you ask questions.
If you ask a question that calls for
legal advice, I'm very sorry in advance.
I will not be able to answer it, at least
not on stage.
Disclosure, OK.
What is disclosure, you found a
vulnerability in someone else's project?
Now what?
What is the vulnerability you hopefully
all have?
A vague concept of wonderful new ability
is
I'm not going to really get into it, but
they can look like they
can take different forms,
all of all the various types
of vulnerabilities that you might want to
disclose.
It could be a customer data leak.
It could be something as simple as a
buffer overflow. It could be,
you know, DNS poisoning attack.
All of these are vulnerabilities.
You might want to disclose anything
that looks like a vulnerability.
And hopefully these do's and don'ts
will give you some,
some inkling about
how to to to disclose
those.
Anything you find,
however, if you want to sit on the
vulnerability, if you want to keep it
quiet and use it for yourself, if you
want to sell the vulnerability on the
open market, then this talk is not for
you and you don't need my advice.
See the title of this talk, which is
disclosure to use and disclosure does.
This talk will talk.
I will talk about disclosure.
I will not talk about sitting
on a vulnerability or selling a zero day.
The first question to ask yourself,
what's your goal in disclosing the
vulnerability?
The the first goal, which
many people have, is they want to fix all
the things. If you found a vulnerability,
your goal in disclosing it might
be to patch that vulnerability.
This is the probably the biggest,
the biggest reason that people
disclose vulnerabilities.
Probably the second biggest reason is
because you want to publish it or present
it. You want to publish your paper
or give a talk saying, Holy crap,
GSM encryption is broken, and
I proved it. And here's how.
And that leads to number four, and you
might get famous doing it.
People have gotten famous doing it,
and that's great.
You might get paid.
Some people actually have gotten paid,
and I will talk a little bit more about
that.
But there's a question mark at the end of
that one.
All of these schools are great.
I'm not here to tell you which one is
better than any of the rest for the rest
of the talk. However, I will try
and focus my various points of advice
or various do's or don'ts on the
various schools. Some of them obviously
will have broader application than just
one.
But some of them will really be focused
on just one of those goals or another.
OK. Number one, and this is the most
important disclosure to remember
that developers are people to
computers and machines and software runs
on computers, and so you can think of
software as a machine.
But the people who design the computers
and the software that runs on them are
people and they are like you
more or less.
And they have all of the faults
and flaws and egos that
people have specifically that hackers
have. Because if someone developed
a DNS system and you're a DNS hacker,
the person who did all the DNS system is
also a DNS hacker, and she
might be more like you than you think.
What does that mean?
Many of the problems that the security
researchers that we've counseled at ECF
have run into might have
been avoided if they had taken
the title of this slide to developers
or people. To what do I
mean by that?
As I said, developers have egos.
Developers often are corporations
who face
stiff bottom lines.
They have money to win
or to lose based on what
you're going to tell the world, or maybe
what you're going to tell their biggest
customer, or maybe what you're going to
publish at Def Con or at CCC.
How you tell them that
might really pissed
them off.
It might really endear them to you,
and it might do anything in between.
There are ways of telling people
that their product sucks in words
other than your product sucks.
So like, don't see that, at least
not at the beginning.
Disclosure, do do your homework.
One of the things that we've noticed
over the years is that
a lot of people in our business don't
necessarily have a lot of patience if you
discover
an open port on a hospital's
patient database.
You might just email the system
administrator. Let's say you can find
their email address and say, Look,
I was able to get on your database
and download all the Social Security
numbers and all these patient records.
Take a step back before you
send that first email and do your
homework.
OK? Is this an activation or is
this an intel?
What do I mean by that?
Is this a company that has a history
of suing the crap out of people?
Or is this a company who's dealt with
security vulnerability reporting
many times in the past and is well versed
in how to handle it?
Again, is this the first time a
company has received a security
vulnerability report?
You probably won't be able to tell that
offhand, but
you may be able to tell that just from
looking.
Is this Facebook?
Has Facebook received any
security vulnerability reports?
Yes, they've received lots.
They know how to handle this sort of
thing. Is this a very small
medical device manufacturer?
Have they received a security
vulnerability report?
Probably not.
They might not even be thinking along the
lines of security.
They might say, why would anyone other
than a doctor ever try to communicate
with a heart implant?
Google is your friend here.
Before you send that first email
before you click, submit on that first
form.
Google the problem Google to see if this
is a problem that anyone else has
discovered in the past, is
this a known vulnerability
that the company has six
bugs elliptic it's open for?
Is this a company that has a bug
bounty program?
Google is your friend.
OK, now this is related back to the very
first find.
A person to whom to disclose
is the closer you can get
to the very person who developed the
product with the vulnerability, the
better.
Why?
Because you want whoever you're
talking to to be able to understand
what you're talking about.
If you email Verizon Tech support
and say that,
I don't know, they're leaking NC
numbers on their on
some sort of sequel
database that's open and you can get with
a get command.
The tech support person is going to say,
Huh? He talking about.
So you want to find someone as
close as you can
to the engineers on the team that
developed the product that
you're actually looking at?
Why the.
The closer you get to to the product
itself, the more likelihood that a
you'll be taken seriously and b
you'll be taken less seriously
in the way that like, ooh, hackers,
right? You don't want to come across as
an ooh hacker, you want to come across as
a hacker.
Like, as we would understand it here,
the kind of people who put a system of
vacuum tubes to send messages around
conference center and not the kind of
people who break into banks
in the middle of the night to steal
credit card numbers.
Finding a person is more homework.
This is again why you don't just
submit to Verizon Tech support.
If it's an open source project great,
you should be able to find the person's
email address and probably pictures of
their cats online and finding
whoever actually developed the product
should be easy.
If it's a commercial product, this
is weird, but LinkedIn can actually
be helpful in this situation.
You can search on LinkedIn for security
engineer. If it's a big company, maybe
they'll have one.
Maybe someone that you know knows someone
at that company.
That would be awesome.
One of the things that we found is even
if you don't know anyone
at the company, you don't know anyone at
the team. Finding it in
in the company will both get you taken
more seriously and
make it less likely
to scare the crap out of that company.
And scaring the crap out of the company
is never a good thing, even if what you
found is scary.
You don't want to scare them needlessly.
Disclosure Do you make a good first
impression?
The first contact will be the most
important and hopefully will set the tone
for the rest of your interaction with the
developer. This is why you don't send an
email titled Your Project Sucks.
It's leaving all iPhones open
to having their contacts databases
scraped like Snapchat, for
instance.
You want to ease into
it.
Hello, my name is so-and-so.
Or, you know, if you not going
to give your name hello, my contact
information is so-and-so
and I have found a
security vulnerability in your products
that maybe you
would like to help them fix.
How important is the issue that you have
found? How important is the bug?
Is it a mere nuisance or is it a
significant public safety matter?
Your first impression, your first
contact should give whoever's
reading it some hint of
what this is.
You don't necessarily have to include
full proof of contact code or proof
of concept code in your first
interaction with the company.
But you should let them know if this is
like going to bring down
all of IPv4, or
if this is going to let someone copy a
game token,
because both of those are security
vulnerabilities that are worth reporting.
But really, one is more important than
the other. Is this going to kill people?
Is are you going to be able to like, stop
Dick Cheney's heart?
Or are you going to be able to play,
copied games over or
undersell your research if you've found
the game console type?
Don't say that lives are at stake if
lives are at stake.
Don't say you found a minor issue.
And don't threaten.
Don't. It's a terrible idea.
I don't care.
This I'm going to come close to judging
you a couple of times in this talk, and
this is one of them.
It's just bad
if if the first language, if
your first language is not
that of the developer.
Be extra careful.
If your first language is English and the
developers are finished, make sure
that you're not using idioms like I
used in the second slide when I said,
this is not my first time at the rodeo.
If your first language is German and
you're reporting to Microsoft, maybe get
someone to help you with your English.
If your first language is not that of
standard human interaction and you're
mostly a computer person, maybe
get someone who knows
how to do that
there. I mean, you know, if
it's 3:00 in the morning and you're on
your seventh club, mutter, Hey, maybe
wait until 10:00 the next
morning to send the email to make sure
that you're really kind of on the same
page as the suit and tie
or, you know, Polo and
Dockers guy who's there.
Don't make a demand or ultimatum on the
first contact.
That's really bad.
There may be times when you kind of have
an ultimatum, which I'll get
to later,
but don't make it sound like an
ultimatum, at least not on the first
contact.
Do not demand compensation or
a job, at least on the first contact.
If they want to pay you, they will
you demanding it won't make it.
So unless you know
you're a hacker who's stolen
30 million credit card numbers and you
want to blackmail them. And if so, this
is not the talk for you.
Offering your help is fine.
Making your home contingent on
anything could lead to problems.
So do not offer
to keep quiet in exchange for something
or anything, money or otherwise.
Researchers have been accused of
extortion for doing this.
I don't know much about European law, but
in the United States, if you
offer to keep something quiet in exchange
for money, there's at least a cultural
argument that what you just did is a
crime.
And I think that what you just did
maybe may or may not be a crime,
but I'm not going to advise it either
way. It's simply not a good idea.
It's I mean, I do not title this talk
responsible disclosure, but that's really
not responsible at all.
So don't do it.
Don't say too much too soon.
This this don't is contingent,
and there may be times when
the type of vulnerability is such
that you can really just set like,
let's say this is,
I don't know, Tor and you found
an easy bug. And for whatever reason, you
don't want to use a bug submission.
You want to disclose it as a security
vulnerability.
You might want to go ahead and give like
the patch along with the vulnerability
report.
However, if this is,
let's say, a hospital and you found
a way in to look at patient records, you
might want not want to email them the
entire database of patient records that
you downloaded from their site
in your first contact
that could incriminate you later on.
And if you, well, I'll get to it later.
But you know, it's not the best idea to
go about telling people
all of the bad stuff you did
before you know how they're going to
receive it.
OK. And now I'm going to pause for a
second. Bad stuff you did.
You might need a lawyer if
you broke DRM to get to
where you are.
If you violated an NDA and
NDAs can come in all sorts of forms that
you might not even know that you signed.
If you clicked through something that
might have included an NDA and you might
really want to think about getting a
lawyer before you make that vulnerability
report.
If you gained access to a nonpublic
anything, or
if you've got some of your information
from a nonpublic source,
you might want to at least think about
getting a lawyer before you make
your report.
If your employer will be pissed
that you're going to Def Con and
telling people how to get free
subway rides for life,
then maybe you might need a lawyer before
you go to DEFCON and tell people that
no legal issues are not one size
fits all, just like vulnerability
reporting. There are tons
of potential legal issues.
I know some of the legal issues
in American law. I know very few or
maybe no issues in European law.
Some of them might be contracts
that you might be bound to your
employment agreement.
For instance, if you found this
vulnerability as part of your employment
and now you're no longer at the company,
copyright could be a significant problem.
Trade secrets might be a problem.
Patents can be a problem.
Anti circumvention provisions could
be a huge problem, depending.
And then if you did something
that could be construed in one
jurisdiction or another as a crime,
you will want to, as I said
earlier, get a lawyer
if any of that is true.
OK. Disclosure, do this.
One's easy.
If you have discovered
a bug at a company that has a bug
bounty program, go nuts.
Use their bug bounty program and
they're put there for a reason.
Otherwise, if you found the vulnerability
at a company that does not have a bug
bounty problem and chances
are you're not going to get paid for it.
It has happened.
It's very rare.
So don't get your hopes up.
If there is no bug bounty program,
do not demand money for any reason.
Because that could be construed
as extortion or blackmail.
It's not a good idea.
Bug bounty don't who recognizes this?
Raise your hand.
OK, a couple of you recognize this.
Facebook has a bug bounty program.
Carlyle found a bug
in the Facebook API that allowed him to
post to
an arbitrary user IDs
wall, whether or not he had posting
permission to that user ID.
He submitted the bug through Facebook's
bug bounty program.
Not exactly clear on why.
I don't have the wording of his
submission, and this person is not a
client of ours.
Apparently, Edward Snowden is just a user
profile picture, which I kind of like,
but they ignored him.
And so he upped
the game a little bit and posted on
Mark Zuckerberg's wall.
OK, that got attention.
It got the bug fixed.
So he met goal number one.
He did fix the thing
and he did it quite effectively, right?
Because he posted to Mark Zuckerberg's
wall and they were like, Holy shit, you
can post to Mark Zuckerberg's wall.
And so they fixed the bug.
He didn't get paid for the bug bounty
program. Why? Because he didn't follow
the rules. The bug bounty program says
that you can't exploit the bug
as part of the and still claim the
bounty.
Facebook's bug bounty program says that
if you want to claim the bounty, you
have to submit a proof of concept but not
actually exploit it.
Or if you exploit it, you can exploit it
on accounts you own or.
Or something like that.
So if you're going for a bug bounty,
don't do that.
But if you're going for fixing the
thing and
you're reasonably certain that you're not
going to get sued or charged with a
crime, which in this context,
I don't know if you should have been
certain about that. It turned out that he
was not sued and he was not charged with
the crime.
Then go ahead and do this.
But really, it's not the best idea.
If I were him, I would have tried to
resubmit the bug through the bug bounty
program, maybe worded differently.
As you can see, he says, Dear Mark
Zuckerberg, first sorry for breaking
your privacy and post to your wall.
I has no other choice to make.
After all, the reports I sent to Facebook
to him on his first language is probably
not English.
Maybe he could have gotten help
on that part of the
submission.
OK.
What if you've now gone beyond
fixing all the things and
your goal is to publish or present
the vulnerability that you've discovered,
sometimes this goes hand in hand with
fixing all the things.
Often it goes hand in hand with fixing
all the things. If you have found a
vulnerability, for instance, in a
standard rather than a product.
There may be no person
to report it to.
Actually, let me pause for a second.
I was talking with Roger from tour the
other night, and he when I was
outlining a little bit of what I was
going to say in this Typekit, he said, Oh
yeah, people, for when they report
vulnerabilities and horror, they will
often just like post
a vulnerability on their own web page and
say, Holy crap, I wish someone at horror
would pay attention to this.
OK. There are people at tau, right?
You can email somebody at
Tau and they will read your email.
So just because it's a standard doesn't
mean there's not a person.
I mean, tau is also it's not just a
protocol, it's a product.
So there are people.
But even if it's just a standard or a
protocol, there may well be people
that you can email.
OK, so now getting back to
publishing or presenting sometimes
really, the only way of getting this
thing fixed is to make the entire
world know about it.
And in that case, you're going to need
to publish or present.
Sometimes you have for your own
in your own calculus, decided
that publishing or presenting
and disclosing the bug in public
is going to be better for you,
for whatever reason, than disclosing the
bug in private.
But that's a decision that you should
make as early as possible,
whether you're going to disclose this to
the company or to the developer before
you publish your percent, or
if free subway rides for life
is going to be the first thing that they
hear about the vulnerability in
their product.
I'm not going to judge you, and I'm not
going to tell you that you need to do one
or the other, but it's something that you
need to think about and think
about it early. And maybe like before
you submit the talking, it's not like a
week before I've come.
If you disclose first before
your talk or before your paper,
it'll give the developer an opportunity
to fix the bug.
Maybe, maybe not.
Maybe the way it is is, you know, these
are Samsung smart TVs that are in three
million living rooms all across the
world.
And unless people update their
firmware, there's no
way of pushing updates.
So maybe there really is no opportunity
to fix it in deployed devices.
Maybe there is.
So that's something that you need to
think about.
However, if you disclose
the vulnerability prior to publication,
you're going to run into
a possible problem.
You're going to give them an opportunity.
You're going to give Volkswagen an
opportunity to prevent you
from disclosing a serious vulnerability
in the keyless entry system of
Porsche's nowadays right
that happened this year at U-6.
They are,
you know, I don't know if they disclosed
privately, but they published the
abstract and use X because that's what
you use next does.
And Volkswagen was able
to go to a court in the UK and get an
injunction preventing them from giving
their talk. Their talk didn't happen.
Their side issues here and
about timing. How long to give
a developer before publishing
again, there's no one size fits all might
be a week. Maybe six months might
be a year.
I cannot give you
the answer to this question without a
whole lot more information, which we're
not going to or it's going to do here
tonight.
Jurisdiction is another one.
Hypothetically, if the Volkswagen talk
had happened in the United States,
the court would not have been able
to enjoin it the way that it did.
But that's only hypothetically if a judge
wanted to ignore the law.
Maybe that could have happened in the
United States.
OK. I've alluded to this,
but now I'm just going to say it when I
was writing these slides, I couldn't
decide whether the next one was a do or a
don't
who here knows what I'm talking about on
this slide. Cindy does.
Kurt does the first
all raise their hands because they were
there, OK?
There were a group of MIT students
a few years ago who submitted a talk to
Def Con with this title,
but they didn't actually mean free subway
rides for life.
What they meant was they had discovered
a vulnerability in the Boston Smart Card
or the Boston fare
card system that allowed you to add
an arbitrary value to
the cart.
They titled their talk free subway rides
for life, and this got headlines, and
this pissed the hell out of the Boston
and the Boston MTA was not
an organization
familiar with security vulnerability
reporting.
They're not.
You know, this isn't Cisco.
This isn't Intel.
And this isn't Facebook.
This is a transportation agency.
They don't necessarily think about these
things in the way that you security
researchers do.
And when they saw a free subway rides for
life, one of the things which
they might have thought from this title
was, Oh my God, these kids are going
to give people a step by step on how to
get free subway rides for life.
So why did I say that?
I didn't know whether this was a do or a
don't.
How much attention is too much attention?
What type of attention is the right
attention? This is an important decision
for you to make, and you need to make it
the you need to actually make the
decision. You can't let the decision be
made for you.
You need to think about whether
free subway rides for life is going to
piss off the people
who you're disclosing to more
than it will get you people to come to
your talk.
If you're a bee and
you submit a talk that says DGB has
something to say, people are going to
come to it.
If you're a random MIT student and you
submit a talk that says random MIT
student has something to say.
No one's going to come to it. So you need
to hear that
there's a line to walk and it's and
everybody is in between those two things.
So think about what you're going to put
in your abstract.
Think about what you're going to put in
your talk title to get
just enough attention of the right kind
and try maybe not to think,
maybe not to make the company think that
you're going to teach people how to steal
their shit.
Think about how the title will read to
all of your audiences, the press,
law enforcement, the company,
potential employers, current employers,
conference goers, paper readers,
you know, whatever.
Are you really going to give step by
step instructions on how to get free
subway rides for life?
Or are you going to disclose a pretty bad
vulnerability in the fare card?
I mean, those are two
ways of saying the same thing.
So think about it.
Disclosure do. OK, now
this when I when I was talking at the
front about about goals this
comes down to you've
decided to publish your present.
Maybe you've already disclosed the
vulnerability to the company, maybe not
disclosure to release a proof of concept.
If you want to. You know, if you've
decided to release a proof of concept
release, one that is
enough for someone of your level of
technical ability to understand
the vulnerability you
want to release enough so that they know
what the fuck you're talking about
and not so much the script kiddies can
run with it.
If you have discovered a vulnerability
in Pandora that allows you to save
full copies of MP 3s, of all the
songs that they do, maybe your proof
of concept is not going to be a browser
plug in,
you know, maybe
consider dual uses.
Consider whether the proof of concept
is doing something to advance the
state of the art in security,
or whether it's something that's just
going to let people get free shit.
So the free software life for its kids
weren't actually going to tell people how
to get free shit. They were going to
advance the state of fear card security
for proof of concept.
Think more about releasing your proof of
concept for academics and not for the
kiddies. The kids don't
need your help, and I don't.
This is another thing where I'm going to
be judging you a little bit.
Don't help them because
they don't need it.
OK?
That's what I just said.
There are better ways of advancing the
state of the art and security than
releasing a
browser plug in that will let you scrape
a visa card transactions, and because
that doesn't really advance the state of
the art and security, in fact, it does
the exact opposite, even though it is a
perfect working proof of concept.
It doesn't help.
OK.
And that's all I have.
My voice is amazingly held up and
I'm ready to go for questions.
Here are some resources that we have at
the ESF website.
This is our coders rights page.
If Tawargha issues
slash coders and we have that
wonderful picture of a cat
on the page because
that's the kind of people we are.
You can always email info
at Forberg, and I promise
that someone will read the email
that does not go to Dev null.
It goes to
our intake coordinator, who is
awesome and knows
what he's talking about and Will will
flag the issue appropriately.
You can also email me and there's my
email address and there's my Twitter.
OK.
OK, first of all, thank you, Nate.
So now we have time for Q&A.
So if you have any questions, you can
line up at your microphones and we will
start with a question from the internet.
When looking over the past few years,
are researchers getting better or worse
at disclosing effectively and our
company is getting better or worse at
responding to disclosures?
It's a mixed bag.
You know, security researchers are often,
you know, I see a lot of young faces in
this room, so people may not have been
around for a few years.
Those of you who have been around for a
few years have gotten better.
Companies who have been around for a few
years have gotten better.
That said, with
the Internet of Things, we are
discovering more and more security
vulnerabilities and more and more things
that the designers of
which may not have ever thought like a
television a TV
engineer would never five years ago
have thought about security ever.
It's not something they would have
thought about. And now there are TVs
that are internet enabled that have a
camera on them that
are running a Real-Time Operating System
in your living room at all times.
And that's a huge attack vector.
So they may.
I mean, Samsung is good
for Samsung TV people.
I don't know.
Like, I'm sorry, I can't answer
that question, but the Internet of Things
has really thrown a monkey wrench into
all of this.
OK, now from a guy in the back,
I I
am not allowed to
talk about the specific
vulnerability, so I need to keep it
as weak as possible
if hunt and vulnerability
seems content management system
and
the window is not that helpful
in disabling the in the fixing
of vulnerability
that this seems is
very many firms big firms
in Germany use it.
What would be the best way to
to keep them safe?
So they all
got those. This one, it's
even a backdoor in there and
stuff.
So I can't answer your question
in a specific, but let me answer in a
more general way.
This is a that's the most common
problem that security researchers have.
They submit the vulnerability.
The manufacturer understands
the vulnerability, but they just don't
patch it.
The market isn't there.
There are lots of ways to deal with this.
One of them is
publishing
that will bring market pressure to bear
to get this thing fixed.
It might also expose
the vulnerability in a way that will make
people unsafe.
So that's a it's a fine line to walk
and, you know, maybe come
up after or email me tomorrow
and we can talk more about it.
But that's that
again, there is no one size fits all
in that the line between getting them to
take you seriously and fixing it
and publishing
in a way that might give people
script kiddies or black hats
ammunition, it's tough.
But one of the ways you can get them to
take you seriously is to publish.
I don't know. That might not be the right
solution for you. So let's talk.
OK?
Thank you.
OK, number one, please.
So if you submit a
report, a vulnerability report and
the company does not react,
how soon do you follow up?
When are you going to start
like setting deadlines
somewhere along the lines of if you do
not answer within, like one month, I'm
going to make this public and
stuff like that.
Again, it depends on how serious this
thing is.
If you found like a serious vulnerability
in a skater product that's in
traffic lights and power stations all
around the world, and people might die,
then maybe don't give them
very much time.
But if this isn't skater, it might
be really hard to patch, then maybe you
should give them time. So it's extremely
dependent on the exact circumstances of
the bug, and I couldn't
tell you what the answer is.
Sometimes it's a week, sometimes at six
months, sometimes it's a year.
Don't know.
Do we have more questions from the
Internet?
Oh, Internet.
Yes, there is kind of a one week
question.
Do you see any difference
in the way you're reporting
responsibly to say
if it's a buck in a natural product
or if it's the application
or the usage of a product,
if someone's using something wrong, is
there any difference in the way you
report bugs?
I mean, every bug is reported
differently, but generally speaking, no,
I don't see a difference in.
There's no difference in type, at least
in in my mind,
a vulnerability is a vulnerability
in reporting it to the
people, the person or people who have the
ability to fix it,
whether it's in an application or
of, you know, a protocol or a stack
or whatever it is is
the best way to go.
Two. OK, number two, please.
Hi, I'm one of the founders of
Hek Militant Fentanyl, which is
a possibility for Dutch people to
anonymously disclose.
OK, you've briefly touched the subject
of being anonymous, but
what would you recommend in which
circumstances do you
report something anonymously and when do
you not do it anonymously?
Is there any, uh,
uh, rule of thumb for you?
There's no.
No rule of thumb.
No, it it totally depends.
You know, if you're Jake Appelbaum
and you find a vulnerability disclosure,
there's probably no reason to do it
anonymously.
Or if you find a vulnerability, there's
probably no reason to disclose
anonymously.
If you're someone with a checkered past
and maybe there is, if you're someone
who just wants to be anonymous
for whatever reason, if you live in
an area where being
a hacker is not OK, if your employer
is not great with you doing what you do
and then disclose anonymously.
But no, there's no rule of thumb.
OK, thanks. Mm hmm.
OK, number one piece
isn't hunting down a project manager
on LinkedIn was that isn't
hunting down a project manager on
LinkedIn and then confronting him with
the bug that he probably should have not
let public in first place?
Isn't that more likely to scare the crap
out of it?
Again, it depends on how that first
interaction goes. If you say,
Hey, I'm a friendly hacker
on the internet and I found this thing
which you probably weren't expecting a
bizarre and strange use
of the product that will
allow someone to do something that you
didn't intend.
And I would like to help you
fix it then.
Probably not.
But it depends if this is someone who
with a particularly big or thorny ego,
then maybe it will.
But we have found that the closer
the people are to
being developers like you, like people
who know security engineering, they know
you're not likely to piss them off.
If you
have you seen numbers that
I don't have numbers.
I only have an anecdote anecdote.
But again, like the your product sucks
vs., hey, I'd like to help
you make your product better.
That can really set the tone for the
communication going forward.
It.
What would you recommend to product
managers of companies or organizations
that are not experienced with dealing
with security vulnerabilities that are
contracted for the first time?
That's a great
question. Yeah,
we think about that for a second.
I guess I take it seriously and
treat any.
I'm just talking off the cuff on this
one. But you know, there's no reason
to treat a bug report off the internet.
Any difference, any different than a bug
report in your internal reporting system.
You know, any any developer is going to
have a
reporting system, a bug tracking
system. I mean, maybe if
this is the first time, just open a
ticket on it. I don't know that
that would be my best advice if
this is not a software company.
If this is, you know, if this is an
insulin pump manufacturer, then maybe
you have to think about it a little
differently, but they
probably have a bug reporting system
also.
So treat it like you would any other bug
treat it like you would an internal
report? I guess that would be my advice.
OK, thanks.
OK. Are there any more questions?
OK.
OK, well, then thank you, Nate,
and everybody have a good time.