By
Viewed
490
Please choose the correct answer for each question below:
Questions: 0/117
Correct: 0
Translate:
Hi, I'm Craig Rowland, founder of Sandfly Security.
Today I'm going to tell you about a very
little known way to access SSH with authorized keys.
And this is called the authorized_keys2 file.
Now, many of you are aware that if you edit the authorized_keys
file for SSH for a user, you can add your public
key to it and that allows you access to the host.
But what many people don't know about is
there is a deprecated file called authorized_keys2, just
the number 2 on the end of it.
And if you put your key in there, many
older versions of SSH will allow you to log
into that host and authenticate with that key.
And this way you avoid putting
it into the authorized_keys file.
Now why would you do this?
Basically because most people look for
authorized_keys, very few people know
about the authorized_keys2 file.
So this is a way to hide backdoor access onto
a system that might evade standard detection search mechanisms.
So let me show you what I
mean by that in the Sandfly system.
In Sandfly, it's an agentless endpoint
detection and response product for Linux.
We can monitor Linux without deploying endpoint agents.
We also track SSH keys, password
auditing, drift detection, a lot more.
But for today, what I did is I scanned a
system here and on this system we identified one alert.
And the alert here that we identify for today's
demonstration is that we flag the user admin and
we set the user admin has an SSH authorized_keys2 file
present in their SSH directory.
The authorized_keys2 file name is an alternate name
for SSH to use for authorized keys and if enabled,
can allow users to access the host without listing keys
in the standard authorized_keys file.
Basically what this means is that there's two ways
to get a public key to get recognized by
SSH daemon on a lot of systems, a lot
of especially older versions of Linux.
And when we look here at our raw result data,
I see the information about that user and I could
see the file here in question and I can see
the full path of where we found that SSH key.
So let's switch to the terminal so we can explore
this a little bit more. On the terminal itself,
I'm now in the main directory here. I'm going to go
to the admin directory and I'm going to go to .ssh
and I do an "ls -al" and notice something here:
authorized_keys2
Right, so what does this mean is
basically you're expected to see authorized_keys.
If I cat out this file it has an identical layout to it.
That's a standard authorized_keys.
In fact, I could run the authorized_keys
file and this file at the same time.
So that way you can have two
places to have a key in there.
But the thing to understand here is that if I
log in to that system, I'm going to SSH in,
I'm going to use a private key here.
I'm going to add log into that box as admin.
And you see here that I dropped in to a shell.
There is no authorized_key file here.
See that it's authorized_keys2.
This is what actually activated it.
Now there's a couple more
things here that are interesting.
Let me clear this out here.
If I do a look at the config file
for SSH and I scroll down here a bit.
Let's see here it is here it says expect SSH authorized_keys2
to be disregarded by default in the future.
And in fact later versions OpenSSH over the past
couple of years do in fact ignore this file.
But the default here is not to ignore it.
And you see here this is actually commented out,
but it still will view that file as legitimate.
So this is actually something that's a very sneaky
way again to keep a key lying around.
Now if we go back over here to the
Sandfly, I'll show you something else that's interesting
on this. Is that we actually did identify this
through our SSH hunter as well.
Probably too much to get into this video here, but
we'll get into it in other videos in the future.
You can see on our channel.
But we marked this as an internal SSH security zone
and we did get a violation showing that this system
here has a user on it that's added a key.
And again I can see who that user
is over here I can see it's admin.
I can see here they added a key and again that
key is present in the authorized_keys2 file here.
And again I could see everything about who's using that
key, what host they have access to, and so on.
But the main thing here to
understand authorized_keys2 file.
Basically, if I were to see a user using this
file, I would assume they're up to no good.
And I strongly advise you to do the same thing.
There's no reason why people should be
using it today except to avoid detection.
And if they're trying to avoid detection,
if they're friendly, you should find out
why they've decided to do it.
But odds are very high if they're using that
file that they're not going to be friendly and
you should be asking some serious questions.
So I'm Craig Rowland from Sandfly Security.
Thanks so much for watching this video.
Check out our other videos as well for
more Linux forensics, intrusion detection and analysis tips.
I appreciate your time.
Thanks again and goodbye.
Related Songs