Hey everybody welcome to the next video.
We're gonna be talking about broken authentication in session management logic.
Now the vulnerabilities listed under this particular topic there's quite a lot of them.
But we're gonna be going over just just a few just to kind of get you more familiar with the topic in
and of itself.
There is a large field that you can go into when you start looking at the logic of a management application
or the logic and application in general and then the authentication each of them can go a mile two miles
20 miles deep.
So we're just gonna scratch the surface on just giving you guys a little bit more familiarity with some
of the stuff that we're gonna be working with.
So some of the bones that are present such as no automatic log outs no session I.D. rotation session
I.D. and tokens in New York.
And then we can default passwords so no automatic log outs.
This is when the users just never logged out by the application.
Okay.
There's no timeout set for the application.
Now this is particularly an issue once with session hijacking so once a user has.
Or an attacker has gained access to that BHP session IP or whatever it happens to be called for that
application.
Then the session is gonna be valid for indefinitely until the user actually hits the logout button.
The reason the reason this this happens is because a session I.D. is stored locally on the server.
So the web server itself.
So if a user does not or the web application does not delete that file then the same session I.D. long
as it's presented will allow you to log in as that user anywhere as long as that session is available
and an issue with that is when they don't actually delete it.
Now anyone with physical or remote access to the machine can view it and logged in as the user.
Now this is a particular issue when you walk away from your desktop even for a second somebody can just
open up a browser go to your bank and if you're break if your bank is vulnerable to this and does not
have no on no automatic log outs set up then it's going to just let them log in right as you.
There's got to be no authentication needed or if they have remote access to the machine itself such
as through a malware or anything else like that they can then proceed to pull the session I.D. from
there even though it might be an older one it's still valid because there's no actual log out occurring.
So there's no session I.D. rotation you kind of fall under the same the same principle here because
the session I.D. should be rotated every time the user logs in and out.
Now if the if the session ideas built bar upon a set set of variables that are always the same every
time they log in there's no random seed or it's not.
It's not being randomly used or randomly generated then this can cause a problem.
So once an attacker has access to the session or this token then they're going to have permanent access
to the account because the session I do will always be the same regardless of whether logged the user
logs out or in.
So this is a very very bad thing to do and can be used anywhere in the world.
And it does and it's not related to a single system such as the climatic log that's where you need to
be accessing that single system first.
So session I.D. and tokens in the URL.
Now this is a very tricky topic but if you're over DDP and not HDP s so nothing so it's not secure.
I'm clear over the wire.
If you have a session I.D. in the U R L or a token for permissions or anything like that any user on
the network can read that token or that session I.D. and grab it now sniffing on a network such as your
local Starbucks or your local Wi-Fi that's free if you're if you're not using G.P.S. everything is going
to be over the wire and anybody can view what you're viewing and in some cases there's a man in the
middle type attacks which we haven't gone over specifically yet we'll go over that in the post exploitation
module.
However just understand that man in the middle essentially allows somebody to make your computer think
that it's a router so they you send all your traffic to them and Nate's and it's the router which in
turn you're making connection to them and they can see everything whether it's encrypted or not.
And this is very bad for session ideas especially if it's present in New York.
It makes it very easy for them to grab out these the session I.D. and log in as your current user.
Same thing goes for tokens tokens are mainly used for web applications for permissions or doing something
specific and you don't want these passed and you are all unless there is an absolutely necessary need
for it.
So the last one here is default or weak passwords.
Default passwords for for anything is the number one killer for anybody in the enterprise world.
And it's also the quick wins for a red team.
It's I can't tell you how many times I've ran into issues where somebody has a web application loaded
or anything loaded really.
And it's running on the default passwords.
So when you first installed it it happens all the time.
Doesn't matter how big your enterprise is you are in it you're going to find these some way shape or
form.
There are a few tools out there that you can use to kind of mitigate this but a lot of software is starting
to force you to change the password.
Wouldn't you go through the install process so again never allow default credentials for any application
on the network.
So weak passwords are ones that are also default.
Those are considered weak as well.
But anything located in word list or uses a common phrase is never a good idea.
So stuff like there's plenty of wordless on your Cally machine if you go to the slash user slash share
slash word list you'll see quite a few and there's one in there called Rock You which is a very common
word list to use.
So if you search there and you find your password on that list change it.
It's a it's a very bad thing to have your password in a word list.
So it's it's it's just always a good idea.
12 characters minimum and don't make it something that is fairly obvious that would be easy to replicate
week hashes in a database or a particular issue.
So when databases should be using salts sometimes they're not sometimes the straight empty five the
password and there's a lot of empty five engines out there that are quick on cracking empty five or
it might have already been cracked.
There's a lot of options out there when it comes to this but when there's salts it makes it a little
bit more difficult to reverse the or not reverse the hash but try to break the hash and find out what
the plaintext value was.
But it's also a good idea for developers that store their web applicator or their passwords in a database
to not use publicly known or obvious salts.
So when they salt a hash is what they do is they take a random value or should be random into the user's
password either appending it or pre spending it and then they go ahead empty five that instead of the
straight password.
So the password for password for example would not be the same as if it had a salt appended to the end
or at the beginning of it.
So this has just been a quick recap on common things that you're going to want to look for things that
you can look for just just by experience it's just going to come in time where you're going to remember
you're going to see something that's going to look obvious.
You're going to remember there's some issue along with that and then you can look into it a little bit
more and in turn you'll learn more.
So it's just a red teaming and ethical hacking whatever you want to call it.
It's all going to be a learning process.
Everything changes new things come out old things go away.
But it tends tends to be the fact that old stuff always seems to crop back up again in some way shape
or form.
But the new stuff is always good to see you prepare to always be learning.
So this has just been a quick quick overview on how this sort of stuff works.