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/598 Thanks!
Hi, thank you.
So as I said today, we'll learn
about those, but not about
what it is, because that's something that
you all should know about.
But we actually do this from
the defenders side. Mostly we hear
about it on the news or the media
or whatever some Apte
guys did indeed, or some
viruses, some botnet.
But we always hear just one side
of the of the border, the defenders.
Now, we learned today
about mitigation of the dose
or more specifically, how not to mitigate
those.
First of all, we
doesn't walk.
OK, excuse me.
So first of all, we got some intro
into details, what is this?
What it is all about, something boring,
just one slide about it, methodology
of work, of our method of delivering
this kind of service.
We are actually we've been attacking
now for three years.
We added services to our customers
that want to test our systems for
this as mitigation or correctives
mitigation. And guess what?
Not all of them were so correct, as
we figured out before
afterwards, we talked about some ideas
in the wild, what is exactly going
on in the world, just some statistics
against something boring.
And then we've come to the ten most
common from the book strategies that we
figure that you should hear about
at the end.
Will will have some kind, of course.
So myself.
Etzioni I do security stuff.
I know I'm managing
a team of security researchers at Verint.
We do something cool
with defense,
but except that mainly I'm experienced
with penetration testing and
ethical hacking.
And for, as I said, from the from
three years of hard work about details,
we are attacking and providing
our customers a service
of those attacks.
That's the end of the shameless promotion
slide. I will never you will never hear
about it again.
So everyone gets visas, not
in the correct sense of the word, because
everyone meaning you,
if you are an attacker, you will then
maybe I hope that you will learn one
or two tactics that you didn't
know before.
If you're a defender, you know what not
to do or what is what are the most top
10 top top ten common
strategies not not to do or to avoid
from.
And if you are neither an attacker
or defender, you just kick back, relax
and hear some good laughs
over someone else.
So the method, the method of
delivery is somewhat complex
because we want to have control over our
botnet. We have a legitimate botnet.
Of course, everything that I will
mention here is legitimate and we are
doing it as as legit
as we can.
We are we have our own botnet, a pretty
vast botnet all over the world, all over
the globe.
And the living this kind of controlled
mechanisms for those for us, for our
customers have some extra edges
like we view exactly
what is happening. We log all the stuff.
This is pretty hard to do actually, when
we are talking about botnet with
thousands of computers that we want
to control each one of them
and know what exactly we are missing.
And on top of that, we have something,
something more like a red team and a blue
team. So the blue team is
is incorrectly named blue,
but you can see spoke with a blue
T-shirt.
So the blue team is is
on site with the customer and
viewing all the logs, not for
mitigation, not for telling him what to
do, just for taking notes for
the red team. And the red team
is is on the other side of the line
attacking the customer with the
with the botnet and together
with the two spox.
We have a complete image of what exactly
is happening on the network or
maybe in the computers of the
of the customer.
And through that, we can we can have
a good recommendation, logistical
recommendation.
We know the site.
We know exactly what happened.
We can pinpoint it.
We can we can analyze it.
We can analyze our own botnet
in terms of improvement if you want to
improve it for the next time.
So together, we have this visualization
of the analysis and we can progress with
the attack.
Moreover, some in
the world leaders use mainly
maybe it's a shock for most of you, but
mainly by science, most of
the attacks are less than two
gigabit per second.
I mentioning that just to acknowledge
that Deeds does not have to
be so large as the media claims
it claims to be.
Of course, there are times that network
bandwidth is the main main type of
things. But if
we hear about some details in the media,
it doesn't mean that automatically
it leaders by bandwidth by the network.
We'll get to it later.
Other than that, we have reflection
amplification.
This are two wars that we hear a lot.
Reflection is the actual act
of benefiting from
a third party that we want
to we want to communicate with.
And the third party is communicating and
reflecting the so to say
to the actual site that we want to attack
amplification is using some
kind of asymmetric protocol
or asymmetric behavior between the
attackers and the defenders of the
service. So the servers will have
to work much harder in order to
accomplish something.
And that's amplification.
Last most attacks that we hear about
on the Internet and on the media does not
require brains.
You can leave your brain out and then
just attack with some some kind of a
tool. And because of that, most
of them rely heavily on bandwidth
consumption.
My point here is that you don't have to
be that lame.
You can't you don't you don't require
most of the like 90 percent
of your brain, but you need a small
fraction of it in order to to
designate and amplify your attack
without actually using so much
bandwidth as proposed.
So.
Just just some headlines,
headlines, as I mentioned, there
is more than a front end will come
together. We come to it at least once
in the examples.
But everyone is thinking of websites
that's going down by diddles, by
some kind of log into a bank or maybe
the double double W's site for the bank.
But it's not exactly if you can
attack the back end and we will get it.
Other than that, you have
you have the the back
end walk for you. The back end is
actually doing something, not just
presenting a cached page or something so
you can actually amplify your attack
by the back end.
Keep it stealthy.
They might be listening.
The magic of sniffing.
We all have heard about it.
The sock team, the sock manager is online
and checking his site all the time.
He's there with the magic of sniffing
and think
of amplification in a general way.
When I'm when I'm saying stealthy, I
mean that use your own tools.
Most of the attacks that you hear about
and read or maybe even
even if you have the source code for it,
you can read the source code and then
analyze by yourself what the attack does.
And attacks are mainly these attacks are
mainly very simple to comprehend because,
you know, the small fraction in the
distribution of the attack in order to
complete it.
So if you know what you're doing, you can
easily believe me very easily write
your own scripts.
And by that you eliminate 90 percent
of the signatures that are residing on
idiocies and antidotes machines.
So amplification on the general term,
we refer to it as four pillars.
We have the network attack that the usual
suspect. We have the C.P.U, which is
very limited in some some
cases.
And C.P.U was actually attacked
by someone on 2083
three, which
I forgot his name because it's not my
native language.
But some very professional guys
devise a effective attack over
C.P.U, presenting a
single aget or post request to
an HTP server and then evaluating
the CPU up onto
ninety nine percent of the system
by using hashes.
So C.P.U is again a very prominent
attack that we choose to attack in
the process. The other thing that we
choose to attack mainly is the memory,
memory, volatile memory.
Everyone use it, everything uses
volatile memory and we can use it to
our advantage.
Think of it everything that is done on
the website. If you have, let's say, a
form and the form is undergoing some
kind of a multi-stage, you can actually
do maybe part of the stages, maybe all
the stages. And in memory,
residents will be very effective indeed
of.
And last is the story itself,
you have a
some amount of storage
on disk storage and even the IO buffer
of the drives that are working very hard
to complete the mission.
OK, so last
this is a true story.
At the request of the survivors, the
names have been changed, will never
do shaming to any of our customers.
You know what comes next out of respect
for the dead, the rest
of the rest have been left unchanged.
OK, so
very.
Set the actual
result as facepalm, so every one of
these of the these
stories will be presented by a
facepalm ratio, will have a scale
facepalm. You'll see it.
And did I mention at the end
and the number one, we go ten to one.
Number one, I can promise you that
all of you will do an epic
facepalm.
That's a promise.
OK.
Very.
Number 10, number 10
was common.
Actually, it's it's less
common nowadays because everyone
knows that mainly everyone
network guys knows that that's rubbish.
Limit the rate of incoming Puckett's.
That's something that is meant magic
for network people to say, yeah, yeah,
yeah. We have Adidas like two gigabits of
men with oh, no problem.
We have one megabit megabit of bandwidth.
So let's use only one megabit
of bandwidth to upload.
Then this way we can't even
choke the bend the rest
of the ninety nine megabits per second.
So of course you
are nodding all of you.
I see the heads if you
have an incoming package coming at
you and this doesn't
work and that's why the
customer had to do this actually.
And that's why he asked the ISP
to ISP, told him please,
please rate the limiting,
limit the incoming packets into your
service.
That was the ISP talking.
And so we did.
And he believed that he is
sufficiently
mitigating the attack if we test
him. And he requested the test.
So we delivered
and it was pretty simple liver,
because if you have
the knowledge of how the Internet
works, so
you have a get request or you have let's
say I get requests, I get requests,
something pretty easy in size,
like, let's say level one killer
bit or maybe one kilobyte,
let's say. And you request a file from
the server. If the file is sufficiently
large, you have, let's say, one megabyte
of a file. You can go with the list, by
the way. You can go with two hundred
kilobytes. It will be an amplification
factor of 200 times more.
Think about it. So now we can
use the minimum amount of data
that we want. We want to upload in terms
of and then get it from the download
itself, meaning that
effectively the servers are choking
themselves.
So the beauty of this, this tactic
is that will work always,
not only when someone will try to
mitigate you. So the mitigation is,
of course, Fagel, but
say that the consumption by reflexion.
But it's an implied facepalm, something
that you all should know and say,
OK, that's something stupid to begin
with. So maybe it shouldn't be on
this scale at all.
So does Tommy Lee Jones.
Number nine.
That's that's a beauty.
We have a vendor that monitoring the
sites all the time, or maybe not the
vendors itself, maybe the SOC in this
case, in this story, as I said through
a story, the monitoring was done by
a third party.
That was the only job was
to monitor the site.
Now, when you monitor anything you
you come to after 20 minutes
of an attention, your attention drifts
away. And the thing about puppies or
about your babies or about your friends
or about I know what
you ate for lunch
and then you forget about monitoring
because monitoring tends to be something
very, very,
very boring to do.
So you look at a graph and if everything
is OK, you live it as as
this is it.
But in this case, we didn't live it as
as as I presented it.
We actually we attacked the site and
the site was down.
Now, when was when the site was down,
it was a surprise attack, meaning that
the the the men
that started the test was the
was the
security officer for this customer, for
this organization.
And he didn't let let know of the idea
and the third party that is doing this
kind of test.
So when the site was down and you see
this site is down, you don't have to be
an expert to see that.
And and then you
just waited and waited
and waited some more.
Now you will ask yourself, wait a second,
maybe an email, maybe a
phone, maybe someone will
pick up the line and say to I.T.
or say to the stock, listen, guys, we
have a problem, but no one did.
Why? So?
So because
two things. It was
pretty, pretty quiet.
No one called it in.
And we'll figure out why in a second.
No one call it no one got an email
about it.
And the monitoring vendor
wasn't aware of anything going wrong on
the network.
So what what what what went wrong
exactly. So first of all, the
vendor saw, as I said, the logging
system and the logging system.
And the logging system was looking a
bit like that, you have a pic,
you have something like a bot, the
the I don't know about the colors, but
the most of it are are
susceptible as botnet.
And it's it's in
a relaxation somewhere.
So first of all, that's the screenshots
that when the security
officer called the vendor and ask say,
guys, do you see this site is everything
is OK, so it's safe to him and send him
the screenshot.
That's the actual screenshot from the
vendor. So everything looks, I don't
know, suspicious. But let's say it's
relaxed after this.
Let's say that the
problem is that,
A, they didn't check the site actively.
They all they needed to do is
just click on the on their
browser, apparently Internet Explorer,
and then go to the site.
And if you go to the site, you see the
site is down. You don't have to be an
expert or a soccer team to see
the site is down.
So they didn't do exactly that.
Now, for this for the second question,
why doesn't the IOC got any calls
or emails?
Because and that's in addition to this
epic fail, the actual the bandwidth
that's used for the banks servers.
This customer service was used
for the HQ traffic
inside the corporate.
So everyone that wanted to serve at the
time, I'm talking about hours of
of of no surfing and
of no email for the corporate sites.
No one could email and no one can can use
the VoIP phones on the.
So that'll be the fun
and this kind of facepalm is
having a face bomb is another rather
that's easy and it's cute,
right?
Ah, OK.
Going and going to number eight.
OK, so I've mentioned it before back and
servers are not important to be protected
against leaders.
Again, a very safe assumption we
have to consider the heavily
backend servers are not important,
eh, eh, that's bullshit.
And servers are always important.
If you think that any servers are not
important and don't use those servers,
that's backup.
So
if.
So if those servers are not
are not needed to be protected against
those, so they are
somewhere and this notion of thinking
was coming from the media, I
guess. So everyone is reading about this
kind of let's say, for example,
supposedly Bank of America was attacked
by Dido's. And the first thing
that you hear about is everyone is
tweeting about the login site for this
bank. Why is not responding?
So the media is responding accordingly.
She's right.
Login site for the site is down.
Oh, man.
But actually, what can happen is,
is something much more vast than
that. But you won't know it unless
you are seeking the stock and know
exactly what what went wrong.
And maybe it is maybe most of the attacks
do actually hit the front end.
But it doesn't mean by that that the
backend not unimportant.
So in this case, we try to
map the site, we as
attackers want to tackle the back because
of this notion, we want to attack it
and want to know what to do,
how to designate some kind of a backend
server. So actually, that's easy because
I don't know about easy that actually,
but it's very common for us
to do when when you check a black box
site, you just go to a site and try
to assume what is going on under
under the covers and see what exactly is
happening. But you can't really see
because you're not a developer, you're
just testing the site as a as a hacker,
a penetration test.
Now, when you decide to try to figure
out where is the database, what is going
on, and that's that's pretty easy.
If you get a query for somewhere,
some search supposedly is and ask
you out and ask your server or anything
like that, maybe a file even, but it is
a data set. You can query it.
You can you can do some work on it.
And that's why this notion is
pretty bad.
So the conservers oh, excuse
me.
Some problems there, maybe someone is
using me now.
OK, so
in this case, we have
like to guess something and that's
a pretty easy guess. If you have delays,
if you have inappropriate delays between
searches or between forms, you
can assume that something is going on at
the back and not in the front.
And the front end doesn't think hard
about something.
That's the whole point.
So if the site is thinking hard about
something, that's the back end.
So you hit gold and you profit from
it when you do need us.
And this facepalm.
Is a kitten because you have to be a
kitten to do that.
That's so nice of you.
OK,
number seven, we had
actually a pretty good customer in terms
of relationships.
And he really respected our work
that we did with one of our leaders, and
then he called us again, but
this time he bought a shiny new
box and this shiny
new box cost a fortune, of course, but
any any box does.
And when you buy
a very, very pricey box,
you may be connected to
all of your service.
We said before that the backend servers
are as important as
the front end.
So protect other domains, connect all
your sites to it, connect to your
corporate machines, your ionno, maybe
your bank. I don't know everything that
that he could figure out how you
connected to this box.
Now you can say to yourself, so what's
the problem? So we get some
extra stuff on
that.
What is really getting is protection from
us against all of those
domains.
And when we did it, when we did
the actual test, we tried to
figure out what is the box is supposed to
do. Now, we didn't have some issues
of this new box that we didn't know
before.
It's name has to be, to be honest.
And so the mitigation is
pretty, pretty unique.
They have like the strategy of of
the the strategy of it is like
thinking about what is going wrong.
The box is just sitting there for 20
seconds when it suspects
something and after 20 seconds after
we suppose it's building some
kind of a model for the attack
and then it tries automatically
to figure out how to deflect the attack.
This this mechanism is usually
preceded by something called draining of
the lines.
When you have all the lines that are
susceptible, you just drain all the
lines. You just drop it all and then wait
for new lines. And then by the model that
you built, the box can decide
what is going what is going in and what
is not going on.
So when we try to
attack it, we were we were very scary
because always before the
attack, before attacking the site, we
we gather information about something.
We try to assess what exactly is
happening in mostly the customer does not
need to respond to anything.
We do not intrusively and try
to figure out the technological
benefits and technological traps that we
want to overcome.
So in this case, we just read the
brochures and try to figure out some
strategic spasticity the
defenders could do and try to
circumvent it.
So we didn't have something really
good, let's say, to be honest,
when we started to attack.
But exactly twenty seconds, twenty
one seconds later, all
the site went down
from all of the old.
Not only that, six minutes
later, the guys from the blue team gets
a call.
Listen, guys, you have to stop the
attack.
Right now someone is very angry.
Why? What is happening?
You knew that this stuff is going on.
We just.
We just shut it off.
It's OK.
We take about two minutes to shut off and
attack and started if we want to.
So two minutes.
Let's let's let's wait a bit.
It took about one and a half minutes and
then the attack attack was gone,
but none of the servers was responsive.
So
so apparently they were very,
very stressed about it,
I guess.
Not only that,
you said you thought that at the end of
the line, not only that,
is that not only
the mean that we we thought
that we are attacking was down.
All the corporate network was down, of
course, because all the main was was
covered by the box and
because of the behavior of
this kind of shutdown, the complete
shutdown of most of the computers that
they are involved with, the Internet
traffic, some back very back
and let's say second to back end of the
corporate side, it was trying to
communicate to something very crucial to
them without explaining exactly
what. But let's say some something
went very wrong on the corporate side
and they lost
some some hefty
money about it when they were
dealing with transactions.
So that
was pretty embarrassing.
And you can figure out exactly what
happened when the box was seeing all
of it. By the way, I didn't mention
monitoring. The monitoring itself was
shut down because it was connected
to the box.
So everything went dark in a second
and everyone was stressed, the phones
were orange voice over IP,
so they they were PSTN
or dials and then they
each other and said, OK, guys, let's stop
it. And we stopped.
And then I think it took like seven
hours of actual mitigation, actual
try to bring back the service
to normal operation.
This facepalm
is like that.
OK, No.6,
that's a good one.
I love it. It happens all the time, by
the way. It's not. It's pretty
common to encounter nowadays when you
have many vendors that provide
some kind of a cloud based dust
mitigation.
We don't trust the vendor.
And that's what they are saying all the
time. We don't give them certificates
shamefully.
That's what happens when when you
rely on third parties that you don't
really know. It's not nothing like the
big five ional providers
that provide some kind of a box or maybe
cloud based mitigation.
But you go with something, maybe a
startup, maybe something in in
its youth when you want to support them.
And maybe it gives you for for free.
Doesn't matter what, but it gives you
some kind of another layer
of security when talking about.
So this kind of defense is is
pretty awesome for us because if we know
that this kind of operation is going on
or we can assume because of the nature of
the relationship with a vendor,
we can say, OK, so https
is not covert.
So you go with steps and when
we go it steps it it becomes
even even better because
you see, the hackers choice did
a terrific research on renegotiation
for SSL and renegotiation.
SSL was approved by them to
be so effective like 15 times more
for the c.p.u of the server,
harder that are harder than your own
walk when you when you try to push
your computer to the most.
And it can be actually
pretty, pretty simple to employ
you with only two computers.
But if we're talking about a very large
you to do computers will not be enough.
You need like 100.
So if renegotiation is
is present, we'll talk.
We'll we'll attack with renegotiation
and it will be done.
It's really hard to counter this kind of
thing unless you have https
and you know what exactly is going on on
the line and you can read it.
And the second thing that not only the
vendor can protect you, you can't see
anything because you are not actually
processing the data.
Now, you can say and
you will be right that you don't want
to anyone else to see your data.
Right.
But the thing is my point is,
if you are not trusting a security
vendor, don't work with him.
That's a that's a pretty simple
advice.
And that's fixable.
They the first one
is the walking with a security window
that you don't trust,
the second one
is the visibility that you don't give
yourself if https is not actually
terminated by anyone.
OK.
We need big data.
Collectors'.
It wasn't just rank of some order.
So we need big data.
That's a big world, I don't know if you
heard about it before.
But big data is going to be a trend, I
tell you.
So we need the big data.
Let's collected all like documents.
We have big data.
We have this we have this netballer
device. We have this network divisiÃ³n.
And we want to collect it all.
So that's great for you.
But when you collect it all, you have one
big problem. That's storage
space.
And let's be honest, some protocols
like PCI tells you to
save all the data.
That's something that you have to do.
So maybe it's not it's not only
that you are wrong with their assumption
of just collect the data, don't do
anything with it, just collect it
responsibly.
And when it doesn't happen responsively,
you have logs and overcoming
some storage boom and Silow
needed.
The result in a complete lockdown.
You don't have to do what you can do
anything on the servers, it's very
hard to operate without, let's say,
Fourcade, for minimum, if
you need something from the from the disk
and maybe the IO itself is breaking
down. But the most susceptible
to those attacks are not servers
themselves because servers can be
cycled through their logs and
most of the network guys knows how to do
that. And infrastructure guys.
But something that is overlooked
many times is the networks and
network switches and ideas, IP
as firewall as well, and maybe the
A.D.s mitigation machine that you have,
or maybe the VPN.
And in this case that I want to mention,
it was the ISPs,
the ISPs. I live the vendor,
of course, alone.
But the ISPs wasn't cycling through
its logs and it over
it, it got the storage boom
and then it just disconnected the
whole site.
So even when they wanted to
mitigate the attack, they couldn't
because the ISPs was down and because the
IP was down. No network can
be reached to the site itself and
they couldn't connect to the ISPs
because there was no storage room on
the IP. So
they couldn't fix the problem and they
needed to get to some
bunker and press the button.
I think the correct button.
And that's a facepalm that
is done by a third party.
Number four.
We are under attack
and forced the OnDemand scrubbing
service, first of all, there is no such
thing. I don't know if you heard about
it, but OnDemand scrubbing service,
scrubbing service is something they need
to learn about your traffic.
You need to know what exactly to scrub
unless you want to teach them.
And that's pretty much impossible
if you are talking about a dynamic
changing site.
But let's leave it.
Let's say there is such a thing like
OnDemand scribing service.
In this case,
we have learning mode, learning mode,
something very beautiful that lets you
just switch switch off
this kind of responsibility or this kind
of mitigation and just switch it on
when when you want to mitigation
to be actually occurring.
Now, in this case, we had it
was in Australia and
it was an Australian customer and
it's not his fault.
And he used some kind of a
OnDemand scribing service, such as say,
and the attack was legitimate
traffic. If you actually know how
legitimate traffic looks like, you can
mimic it pretty easily.
If you use your own tools with other
more robust tools, you can do that
in a good way.
And last, you have to read the manual.
Please do. And they read the manual and
and discovered that the manual itself of
the vendor said that's no, no problem.
We can learn on demand.
I don't I don't really familiar I'm not
familiar with with this notion, but let's
say it's possible and
we'll live it four minutes from
now when the response was
epic.
Now, the story went like this.
We had the the side
of the customer. We actually attacked it.
And then it was pretty OK,
the we try to to
make wrap up
a ramp up of the attack so we can analyze
what exactly is going on.
So we wrapped up them, wrapped up to
remember that.
And then when we reach some kind of a
limit, we said, OK, it looks
fine. Do you want us to continue with
the ramp up? And he said, no, I want to
test the On-Demand streaming service.
And in the second that he switched
on the on demand
service, I was all was
shot and nothing can be accessed.
And it was pretty impressive because
not only that, it does like that he
didn't have any kind of control over
it. He can switch it off.
You can you can maybe try to
DNS the incident.
He tried to call the vendor and now
usually we do it overnight because we
want we don't want to hurt customers
that are actually using the site.
True.
This is harmful to us because we want
to actually mimic a true and
not off-peak, but but on
peak hours when we want to actually
attack during Christmastime,
I say
but in this case, of course, it was a
large customer that didn't want to
actually hurt the customers.
So that's negligible.
So he picked up the phone
and called the vendor.
The vendor has a twenty four seven hour
someone that is picking up the phone,
that someone picked up the phone and
looked and and heard about.
He he was
going on like someone that actually woke
up from sleep.
We would imagine that you were if you
didn't have any kind of communication
with him except his voice.
So he said to the vendor, listen,
I have I have to have your help.
My site is down.
We are six hours to, uh, to, uh,
to actually the mall.
We six hours for morning.
And when the morning comes, the customer
will try to to exercise and no one can
currently. No one can.
But it's again, it's it's
controlled. So the vendor says, wait a
second, I have to consult with someone.
He consulted with someone and
in half an hour passed.
And then he called back to him
and said, OK, OK, we'll we'll try to
figure it out another hour.
And then the unstrapping service was
down.
But the aptness about this is the
answer, the complete answer of the
vendor. The vendor said when when
they were asked, why didn't you
actually told us that we want
we need to calibrate the, uh,
the I know describing service that that
was the the thing that he said.
He said another thing next time by our
service of calibrating
your site.
That's a good friend.
And that's.
A triple facepalm,
why a triple, because Fehling had
protection working with a vendor
and the pool vendors answer.
We are approaching number one, number
three, so what Sydney's is not
dynamic, let's enable its citizens
is the distribution network is
pretty popular nowadays in protecting
against those.
And that's pretty cool because it
actually works if you have a spread out a
city and you can actually mitigate
network based, maybe
even other other based attacks
to your system. That's cool, right?
But Sydney, as a culture, it's called
static and dynamic and it's usually
marketing, but most of the citizens
are static.
Static means that it can pull off
some requests for your site from static
data, not something like searchable
queries and stuff.
And then you can you can cache
those data, those data, this
data on the CDN and
via that other customers can benefit from
the no lag at all
from the sit in.
Now, when a citizen tells you that it's
not dynamic's, which is good, which you
should know about, and you use your site,
which is dynamic on this CDN,
it can be very, very devastating.
Now why?
Because the thing is that it works like
that. If you have a citizen
and a citizen is is getting
a request from an attacker or just
just a regular user, it asks for
some kind of a landing page.
Let's say if the landing page is on
is was visited by someone
else in the vicinity of the and it will
know how to respond and then respond from
its own cache.
If it's not was if it wasn't
asked by someone at that
a given time, it will ask itself.
It was a request for the origin.
The origin is the actual domain that no
one should access except the city.
And it will ask the
origin about this request.
Get it back and then get back.
Get back to the to the customer, to the
user. And attack tracker will do the
same. But that does not know.
We'll get to it in a second.
Does not know where the origin is and
how to ask it directly.
You need to ask the citizen about
something in the DNS that the NSA
is issuing is giving him
the closer to the end that
he can need to think about when he's
talking about the site.
So in this case, we have
an origin
that is getting so many requests.
So that's wrong if you're using
dynamic.
The thing is that dynamic is pretty
easy to deduce because if
it's not dynamic, say the end, meaning
that he will need to issue each and every
one of the requests if it's a
different parameter or value for those
for those parameters, it will need to
issue each and every one of that.
All we need to do is just requesting
from the see the end data with parameters
that didn't know the same page,
other parameters, sometimes even
parameters that doesn't exist in the
site. But it doesn't matter.
He will issue a command and issue a
request for the site because it doesn't
know the correct you URL for that
and it doesn't have it on cache.
So one of our customers did exactly
that user sedan on a
dynamic site and we easily
they just deduces machine.
And other thing about citizens, which
is not exclusively for dynamic but for
dynamics, is much more devastating, is
that if you monitor your origin,
many of the citizens does not give you
actual uses for monitoring
like traffic, like did you have your
own machine and you monitor that as
good as you can and maybe some some
kind of tools that you get from the
vendor of the sedan.
And actually, when you try to
mitigate it on your sites,
you actually many times can't
because you can see the actual attacker
and you can't blacklist the attacker or
something. You just see request from the
citizen. And if you block the city in
itself, that's good for us.
OK, and that's deserve
a distributed collage
of facepalm.
Number two, again, city
is pretty exciting for me because
no one knows how to protect students.
And when someone searches the Web
in this case, some obscure site name,
Google will use it for
finding how to protect protected
in origin.
That's the best phrasing that we can.
We could walk out and the
the first one after the
one, which is advertisement,
you have the how to protect your city in
origin. So let's click on that what you
say.
OK, we clicked on that and that's magic.
And then we have several
recommendations how to mitigate and how
to protect your city and your citizens
origin.
And just magnified for you, this
is a simple trick and it is also the
best solution, create some random
long set of alphabetic characters
and use that as a subdomain
even more. So can it be guessed?
Yes, but highly unlikely.
Can it be linked?
Yes, but again, highly unlikely.
There was much rejoicing reading those
lines.
Why so?
Let's talk about it.
So the tactic is like
that find other subdomains
dance that translated to Ipis scared
the hell out of it.
It's a serious sless, 20 for
16.
Good, good chances, but it's not
bulletproof. You can you can actually
miss a lot of of those origins
from the actual name.
But something that is much more probable
to find out is the who is this?
Who is Elvis never forgets means
it is forgetting because who is this
dynamic? But you have who is history's
online and you can check
who is history or history
domains. And then when you check it, you
figure out and we figure it out in this
case that the if we
want to solve some of our customers
actually but this kind of service
and try to protect against it and we
figure out how we can know what is the
origin, who wanted to attack the
original. Everything is static.
It's pretty hard to to attack static
sites unless
we have a subdomain or unless we have
another origin that we know that
will will be hurt by that by
our attack. And we can just attack some
some obscure subdomain.
We need to know what we are attacking to
some extent. Of course,
because of the backend that doesn't
really determinists isn't really
deterministic all the time, so
we never forget. So we look online.
In this case, I'm just giving an example
for a malicious infected site
named Big Dot Com.
And this site is
covered with who is history that you
can pull off from View DNS in this case.
But there are many other services for who
is Esrey. And then we actually thought
about it when you bastardy and you don't
actually change at the last IP
of your site, you just giving it out to
the actual content provider.
And then if you look up the who is
history the last one or maybe one or one
before that, you actually hit the jackpot
because this is the IP
of the origin.
And that's exactly what we did.
And that's exactly what happened when the
site went down and the customer said to
us that he doesn't see anything
on the Syrian.
That's around.
No one.
OK, that's something personal
because in this case,
the again, the the
actual the actual person that
bought the service from us was the
security officer of the organization, a
big organization in Israel in this case.
And this organization
was very, let's say,
politically savvy.
So it was very
vicious in their attempts to block the
attack.
So as I said during
this week of research before the attack,
which is nonintrusive, we try to figure
out how the mitigation works from low,
low impact attacks and stuff without
actually impacting anything.
We try to figure out what is going on.
And we saw that the mitigation that they
they invented was amazing.
Like we have one server and we are
taken from this server.
And that's and from this on,
the blacklist is not following just
on on our servers, but all of our servers
worldwide or just a branch of our service
in some place in for
instance, in this example in the United
States. And we try to figure out why.
Why is that? If you are taking from one
source, how come you can mitigate
all the sources from this area and
the the susceptible answer?
And in this case, the correct answer was
that the mitigation walked like that.
If you see an IP, if the sea
rises up and alert and then an IP
is raised, then it doesn't block
only the IP.
Remember, he wants to block us, not an
attacker. And he knows that we are
limited with our with our resources
because because, as I said, we are
legitimate as possible.
So when he tried
to mitigate us, he said to himself,
OK, you have some botnet that released or
bought somewhere and that this will be
some kind of a cluster of vipers, which
was correct in this case.
Most of our servers do like
that. So it didn't just
block us. He blocked the whole 16
site.
I'm hoping that you are not cheering for
him because.
So, for example, in Germany, you
have like one hundred sixteen million
IDPs in Israel.
It's much, much smaller, but you can
extrapolate.
So if you
have 160 million
IDPs, you have about
roughly, of course, one hundred thousand
eight hundred class
ranges. Right.
So if
we have only hundred
IDPs that we need to hit
and we can, let's say,
spoof the scene,
we can actually block all of the
customers nation if the
nation is deplorable, customer in this
case, insurance is Proval to
to come from customers from this
nation.
And in this case, Israel, as I said, is
very small. And so
we told them a bit so.
So think of a monkey just typing high
fees like crazy, and then it just blocks
on the nation by itself and he
can do anything about it because
50 minutes after after the
the actual attacks have started, it's
inflicted by all the nation.
And before the 15 minutes of light,
like half the time of that,
he blocked himself so he couldn't see
the.
And now you can see why it's my favorite.
Now, remember what I told you about the
mega fund that will give me remember?
So that's the one.
But I don't see you face palming,
so I brought my own picture.
And actually, I think it's kind of a
tradition, so if you may find
yourself for a second.
That's OK, right?
Right, let's say it's OK.
OK, so
I thought about it,
maybe the most important one is test.
Don't be afraid to test.
Many of our customers didn't know that
such services is is in
existence. And we are not the only one
that providing this kind of service.
We know.
So
there is no magic pill.
You have to be an architect to understand
that. It implies not only the front
end of the place, all your network, all
your computers, maybe even more than
that, maybe your phones and emails.
But test it and and you
have all the money and all the toys.
If you just deploy it without thinking,
it will fail you.
So please be
responsible about it.
And one less promise.
If you wanna do that, you can be
evaluated to this presentation in
the future.
Thank you.
We now have about 10 minutes for Q&A.
So, as always, police line
up at the microphones or
use the Internet to ask an ISP
or Twitter.
We have a person reading out your
questions here.
And if you leave, as always, please be
very, very quiet because
the talk is not over. It's going to go on
for ten more minutes. So please be
very quiet.
Microphone.
No, no, no.
You're not hearing is not hearing.
Any questions?
OK, the Internet.
You need to switch on the microphone.
Should I ask my ISP before it
does or not?
Oh, that's so if they
wanted us is included in the.
So that's partly a
legal question and partly a
tactical question, let's say, for your
sake of evaluating your security.
I won't touch the legal sections because
I'm not a lawyer.
And for the legal section, you
have to consult your law department if
you have so if you have such a department
department. For the other part,
it depends on what is your focus
on the testing. If you if you are
focusing on testing the system as
a whole, if you are looking at the army
to get all the mitigation factors that
you put into place, in my opinion,
it's important not to notify the ISP if
possible, but if it's not
possible, of course.
Notified.
Microphone number three, please.
Hey, so there
are techniques that, for example,
CloudFlare has this project called
Railgun, where they def the
websites and
sort of not request the full website.
I don't know really how they do it, but
does this have any impact?
Can you see this when you did?
Does this help at all or is this just.
Yeah, OK.
This, um, usually
we test with blackbox.
It means like testing.
We don't really know what exactly
is happening on the other side except
what what the blue team is being fed
also or seeing by the customer.
Such examples as CloudFlare and others
are examples of of
partly participating factors into
the attacks and the testing, because
they they didn't provide us with much
of the explanation that we want to.
Actually, I'm not talking about and not
talking about CloudFlare, because
actually we're not going to figure that
we've never tested something with with
CloudFlare in mind.
Not not that I know of.
It wasn't effective, actually.
And let's say other
vendors similar to CloudFlare has
approached us and and usually
put up some difficulties.
I'm not talking about technical
difficulties, more political
difficulties.
Let let me know when you are doing it
with the legal stuff is not correct.
You can do it and you have only
ten minutes of time and something like
that. So something like well done and
similar is not employed
by it. Haven't been employed in our
testing yet.
I hope it, uh, it answers your
question.
Microphone number two, please.
How often do you find your customers were
protected when you get there the
first time?
Let me let me put it that
way.
We are when we conducted tests.
It is important to say that I'm not I'm
not continuing these tests anymore.
Like two months from now, I'm
I'm off.
When we conducted these tests,
we actually did we
took a length spend
four to six hours from the customer.
And through these four to six hours, we
actually provided usually
one one attack per hour.
We tested some some kind of attack that
we have in Stasch that we actually
prepared before according to our research
and evaluating by overnight.
If we have whatever a number
of attacks that we have a night like a
real attacker will do.
But on an on a very lengthy,
a lengthy span,
we have more than 95
percent of success.
So most of the attacks, unfortunately,
are not well protected.
That that answers your question, yes, OK.
And now the Internet plays.
You said you just scanned the whole 20
for 16, even word
IPV six, make it better.
Think of a whole 56 and random
IPS. That's quite something to scan.
Yeah,
this is good. This is great.
But I am I'm not familiar
with any bank that is working with us
or any bank at all that is moving
to IPV six as a whole is
just using IP before and the IP is
on top of that.
Number three, please.
So given that a lot of things
are on shared infrastructure with Amazon
and CloudFlare and stuff like that, how
do you make sure that whatever you're
detoxing doesn't cause any
collateral damage with people who
are just innocent bystanders?
It does. It does.
And it's probably
if you're referring to to to
not not customers of the
front to to actually customers or clients
of the customer.
So, yeah, give it like someone on Amazon
dossing like them for something
and like something on Amazon
GhostTown.
OK, so should infrastructure as a whole
is a whole different ballgame.
We have to consult legal
and the SLA with Amazon
and Azure and others are
pretty different from one another Azure
that we do stuff if you
let let them know in advance.
Amazon, as far as I as I know of,
doesn't let you do anything.
It's pretty strict in terms of testing.
Think about it. It's pretty massive not
to test your own site, but again, it's
considerable when you're thinking about
the shared infrastructure, when you have
Amazon or so others.
So it depends on the on
the host.
And what what are the SLA with?
Number one, please, so
thank you for the nice talk, but can we
change the rules?
So I would like to
to hear you a bit elaborating
about what you would do if you
have to run mission critical
infrastructure and how you would
protect it.
I'm not a genius.
So for starters, I
won't presume that everything that I will
say will be holy.
It will be holy in another term.
But I know that everything I
will do, I will try to architect not just
design and mitigation, architecture and
mitigation and redundancy, as
much as others know nowadays
how to back up and how to help something,
it's pretty much the same when you are
talking about redundancy and things
that need to be standing by and how much
like the time that you can you have
because this can occur.
It doesn't. It isn't.
There is no magic pill.
As I said, nothing that I will provide
you with, with a complete architecture
will not be failsafe, but it
will be epic, fail safe.
And and and on top of that,
test your systems any time
you want, you can be the greatest
developer. You will actually test your
obligations.
Right. So that's the same thing.
If you architect something tested it
to test.
Thank you. OK.
And once again, the Internet, please.
Are there any particular solutions
or products recommended or that are
particularly bad?
No.
Number four,
I'm home.
So, first of all, the photo was
not really appreciated.
I mean, we're not here for
your amusement or anything.
It's it's kind of bad, Norm.
And now moving on to the question,
have you given any thought to
to saturate the link without sending
any package to the
target?
First of all, how to, like, legally do
that and if you've ever had to do it or
it was never necessary because the sites
are done for other reasons.
Let me put it again.
If I if I understand correctly
what your question is, how
can you actually do
some damage without
going on and on and on with
the traffic?
Yeah. So you can be sending
traffic to sites
ipis actually that Syria
link with your target so that your target
does not observe any traffic and so
that you do not actually
do with any of them.
But so I mean
they do not get tons of traffic
individually, but the whole link that
they share will be saturated,
which would be nice to have because then
you could see how
your path actually how resilient your
path is to those attacks.
I mean, it's been described in academia,
but I don't know if you use it in
practice.
OK, we didn't we didn't
do something like that before.
Personally, I it's
hard to think about something that we can
deliver such an attack with
without anything unless we have an
exploit for that.
Like like a like I said, 2083.
There was an exploit exploiting many
Web application servers through
the hacking mechanism.
But unless we have an exploit, a
designated exploit and we talked about
generalized stuff, not exploits a pair
of Web application servers, I don't think
that's possible.
But maybe it is in some
in some situations when you have a
database that is working very hard and
crunching something and you can do pretty
much the same, which is the equivalent of
XPoint as an expert as I see it.
Not exactly.
So you're sending traffic to piece
that they're not related to your target,
except that they're being hosted in the
same data center, say, oh, that you
saturate the link, but your target
doesn't seem to traffic.
Oh, you mean so excuse me.
You mean that another subdomain
and through that is is impacting the
actual one that I wouldn't call another
IP. Yeah. It doesn't have to be related
at all to your target. Yeah.
That happened a lot and that happened a
lot when we, when we got confirmation
from the from the customer of course, to
attack other domains just for a second
to test if the infrastructure was shared
for any means, you have to have some kind
of a shared infrastructure, of course,
maybe the same host, maybe,
maybe it's networking on some sites.
And the one example that I said about the
shiny box, it was in the U.K.,
that's exactly exactly what what
happened on the tier two back and
the tier two was attacked.
It wasn't our target, but it was
attacked.
So it is possible through other
subdomains, by by definition in the.
And unfortunately, we are out of time, so
please, once again, thank Delmar's.