Web Attack Investigation Part 3

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

17 hours 41 minutes
Video Transcription
Hey, welcome back to the course. So the last video we stopped about our first part of the last top 10. So we talked about injection, broken authentication, sensitive data exposure, XML, external entities or *** E broken access control, security, Miss Configuration and cross site scripting attacks.
In this video, we're gonna talk about insecurity, serialization, using components with known vulnerabilities and finally, insufficient logging in monitoring.
So insecurity serialization. So this often leads to remote code execution. Eso Even if the even. If this doesn't lead to remote oh, code execution. Generally, this could still be used for attacks. So things like replay attacks, injection attacks, privilege escalation, attacks, etcetera, etcetera.
So what is to prevent against this? You know, implementing integrity checks. So things like your digital signature on excuse me digital signatures on any serialized objects to prevent hostile hostile object creation or things like data tampering.
Koda's isolation. So we don't want to isolate a run code that DC realizes in low privilege environment. So again, we wanna make sure we're not running at the admin or root level on that,
and then logging you no exception and failure attempts of di sale. Excuse me d serialization. So things were the account is things like, you know, where the incoming type eyes not the expected type, right? You know, or that the dis serialization actually just throws like an error.
So using components with known vulnerabilities so things you know, if we know that, like, certain libraries or frameworks, you know, or other software models are running, you know, with the same privileges. Applications, you know, are we want to avoid those, right?
Because I can lead to, you know, things like data loss, you know, or even like server takeover by the attacker.
So ways we could prevent against this Obviously patching. You know, as we see throughout also, all sorts of, you know, tax for vulnerabilities. We see that patching is one of the one of the main things that, you know we used to try to prevent against this type of stuff
I'm taking, you know, Ah, the components from official sources. Right? So, you know, instead of going to like 1/3 party web site to, you know, get the software package, we're actually going to the actual vendor on getting it from them. You know, that does reduce the chance it doesn't mean entirely. There's no risk involved.
But it does help reduce the opera the chance. That is something nefarious,
I'm taking, you know, continuous inventory of the the frameworks that we're using on the client and the service side, as well as the libraries that we're using.
So next up, insufficient logging of monetary. You know, we can couple this with the missing or ineffective integration with incident response. So basically, this allows Attackers to further attack systems, you know, maintain persistence, pivot to additional systems, you know, do you?
you know, if you think about it, a lot of a lot of the research out there shows that the time to detective breaches, you know, like anywhere from, like, 2 to 300 days. So think about it in that context, right? If we're not logging and monitoring effectively that it might be even longer that we go without actually noticing. We have a breach, right? It's so from there,
maybe we had a breach that if we caught it within the first month would have been too bad, right? They got a little information, but
not too bad at all.
However, we're going, you know 300 days is almost a year,
and then we find out about the breach and Oh, wait. Now it's affecting, you know, 400 million people or something. Oops. You know, there goes our company, so just keep that in mind. That's just one of the main reasons we want to try to prevent against us. So,
you know, some common l common, you know, common sense type of stuff. I guess I'll say a SW far as prevention, you know? So we wanna make sure we log all you no longer access control fairy failures, you know, any type of input, validation, failure. We want to make sure we log that and notify on it. Um, you know, if we notice Ah,
uh, you know, suspicious or malicious looking in accounts.
We want to make sure we, uh,
block those. Or at least, you know, prevent those from doing anything or, you know, accessing anything before we take a look at them.
Make sure we know we're generating locks, and a former that could be easily could consume. Right. So you don't think it like tools like Splunk, where it, you know, takes in all that data agree Aggregate. Sit. And that spits it out. And something that an analyst can actually look at,
you know, establish going along with the 1st 1 there, establishing effective monitoring and alerts. So again, you know, we want to make sure that we're actually detecting, you know, are being notified of suspicious activities. And then, of course, we're that we're responding in a timely fashion. High value transactions have some type of audit trail in place,
uh, with integrity controls that week. That way we could prevent against tampering
or even deletion.
So, you know, using things like in upend Onley database or something like that.
So some other risk, you know, things like information liquid directory to gain, you know, to either gain or corrupt different information.
Former log tampering. So our input there and then cross at risk request forgery
where they're taking over the session.
So after an attack, what are some of the things we're looking for? You know, asked as the forensic investigator. So things we want to grab are gonna be things like the date and time. Of course, that kind of kind of goes without saying I p address information. If we can get it. Http. Method used. So which commands, like guests get or post the http headers and body
as well as a different event Logs from the incident.
We could also use some different commands. So, like net view in the i p. Address net session that use nb t t n b t stat. Excuse me. Ah, and nuts Stat desk Anil, make sure you remember that one for your exam Scheduled task or s ch task dot e x e and then net start as well.
So the deep lock analyzer. This is ah, tool. You'll just want to know for your exam and really just understanding that it's a Web analytics tool and used for smaller medium websites
and also a small, weak medium businesses. So you may you may possibly see it ask either way on the exam,
just a screenshot of what it looks like here
are so different air logs. You just want to kind of memorize these paths. So for red hat or fedora Lennox viral log http de ah and then air underscore log who boon to end debian var log Apache to an air dot log and then freebsd var log http D dash
air dot log So again, you're just gonna want to kind of memorize those
for the exam.
So just a quick post assessment question here we talked about the deep log analyzer tool. So the question here is it's a tool used for Web analytics on small to medium websites. Is that true or false?
All right, so that's true, right? We talk about that. It's used for small 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.
So this video we wrapped up our discussion on the Awash Top 10
and the next video we're gonna start our discussion on database forensics.
Up Next