>> Hey. Welcome back to the course.
In the last video, we talked about
our first part of the OWASP Top 10.
We talked about injection,
broken authentication, sensitive data exposure,
XML external entities or XXE,
broken access control, security misconfiguration,
and cross-site scripting attacks.
In this video, we're going to talk
about insecure deserialization using
components with known vulnerabilities and
finally insufficient logging and monitoring.
Insecure deserialization.
This often leads to remote code execution.
Even if this doesn't lead to remote code execution,
generally this could still be used for attacks.
Things like replay attacks, injection attacks,
privilege escalation attacks, etc.
Ways to prevent against this,
>> implementing integrity checks.
>> Things like your digital signatures on any
>> serialized objects to prevent a hostile object creation
>> or things like data tampering.
>> Code isolation.
We don't want to isolate a run code that
deserializes in low-privileged environments.
Again, we want to make sure we're not
running at the admin or root level on that.
Then logging exception and failure
attempts of deserialization,
so things like where the incoming type is not
the expected type or that
the deserialization actually just throws an error.
Using components with known vulnerabilities.
If we know that certain libraries, or frameworks,
or other software models are
running with the same privileges applications,
and we want to avoid those because
that can lead to things like
data loss or even server takeover by the attacker.
Ways we can prevent against this, obviously patching.
As we see throughout
all sorts of attacks or vulnerabilities,
we see that patching is one of the main things that
>> we use to try to prevent against this type of stuff.
>> Obtaining the components from official sources.
Instead of going to a third-party website
to get the software package,
we're actually going to the actual
vendor and getting it from them.
That does reduce its chance.
It doesn't mean entirely there's no risk involved,
but it does help reduce the chance that
there's something nefarious in it and
taking continuous inventory of
the frameworks that we're using on
the client and the server side
as well as the libraries that we're using.
Next up, insufficient logging and monitoring.
We can couple this with a missing or
a ineffective integration with incident response.
Basically, this allows attackers to further
attack systems, maintain persistence,
pivot to additional systems [inaudible].
If you think about it a lot
of the research out there shows
that the time to detect a breach
is anywhere from 2-300 days,
so think about it in that context.
If we're not logging and monitoring effectively,
then it might be even longer
that we go without actually noticing we have a breach.
From there maybe we had a breach that
if we caught it within
the first month it wouldn't have been too bad.
They got a little information,
but not too bad at all.
However we're going 300 days;
so almost a year and then we find out about
the breach and now it's
affecting 400 million people or something.
There goes our company.
Just keep that in mind, that's one of the
>> main reasons we want to try to prevent against this.
>> Some common sense type
or type of stuff I guess I'll say as far as prevention.
We want to make sure we log
all login or access control failures.
Any type of input validation failure,
we want to make sure we log that and notify on it.
If we notice suspicious
or malicious looking at accounts,
we want to make sure we block those or at least
prevent those from doing anything or
accessing anything before we take a look at them.
Make sure we're generating logs in
a format that can be easily consumed.
I'm thinking about tools like Splunk
where it takes in all that data,
aggregates it, and then it spits it out in
something that an analyst can actually look at.
Going along with the first one there,
establishing effective monitoring and alerts.
Again, we want to make sure that we're actually
detecting or being notified of suspicious activities,
and then of course that we're
responding in a timely fashion.
High-value transactions have some type of
audit trail in place with integrity controls,
that way we can prevent
against tampering or even deletion.
So using things like an
append-only database or something like that.
There are some other risks,
things like information leakage,
directory to either gain
or corrupt different information,
form or log tampering;
so our input there,
and then cross-site request
forgery where they're taking over the session.
After an attack, what are
some of the things we're looking
for as the forensic investigator?
Things we want to grab are going to be things
like the date and time of course
that goes without saying
IP address information if we can get it,
HTTP method used,
which commands like GET or POST,
the HTTP headers and body,
as well as the different event logs from the incident.
We could also use some different commands
like net view in the IP address, net session, net use,
>> nbtstat, netstat -ano;
>> make sure you remember that one for your exam,
scheduled task or shtasks.exe,
>> and then net start as well.
>> The Deep Log Analyzer,
this is a tool you'll just want to know for
your exam and really just understanding
>> that it's a web analytics tool and used for
>> small and medium websites
and also a small medium businesses.
You may possibly see it asked either way on the exam.
Just a screenshot of what it looks like here.
Different error logs. You just want to
memorize these paths,
so for Red Hat or Fedora
Linux: var/log/httpd/error_log,
Ubuntu and Debian: var/log/apache2/error.log,
and then FreeBSD: var/log/httpd-error.log.
Again, you're just going to want to memorize
those for the exam.
Just a quick post assessment question here.
We talked about the Deep Log Analyzer tool,
so the question here, it's a tool
used for web analytics on small to medium websites.
Is that true or false?
That's true. We talked about that
it's used for small and medium websites.
You may also possibly see small to medium businesses,
so either way it's for small to medium;
just remember that, and it's for web analytics.
In this video, we wrapped up our discussion on
the OWASP Top 10.
In the next video, we're going to start
our discussion on database forensics.