As always, commands below, but what we're taking a look at here is the login.def
s commands below. And the reason I'm pointing this out is because of a couple of things. For instance,
we can't exactly do pseudo elevated things unless this our connection is ran as pseudo as we saw
earlier. Inside of Windows, we're able to take a little bit more of an exploitive approach whenever
we have our initial connection through meterpreter like this. But inside of Ubuntu and other
POSIX-based operating systems, we fall just a wee bit short until we start doing post-exploitation.
It's coming, don't you worry. And this, it can be a hurdle. However, we can look at policies
on the actual system itself. In Windows, we have local security policies if they're a local
workstation, a group policies if they're on the domain. But in Ubuntu and POSIX-based systems,
we have policies on the actual system itself defined by certain files and knowing their
file locations. And the logon.def s gives us an idea and scope of what's actually required on
the system concerning logins and actual configurations for the system overall.
Specifically, as I zoom in here for us, oops, let me get that out of the way real quick.
What we're taking a look at here is one password policy example of password maximum days being
basically infinite and the minimum days being zero in a warning age. If these are configured,
you know that you have a method of being able to trick somebody to change their password,
potentially. And right below that is a way for some system administrator like myself to be a
little bit janky. Generally, inside of POSIX-based systems, the lower the UID number, the more
permissions. The higher the UID number, the less permissions. Generally, okay? It's rule of thumb.
Not always, it's not a law. But inside of here, you can actually change the defaults of where UIDs
and SIDs, system UIDs and all that stuff, group IDs and et cetera, are where their range is. So
you could say, start off a new user ID at 10. You wouldn't want to do that, but I'm just saying
you could. You'd have to make sure it doesn't conflict with anything else on the system.
But these are set by default, and you could definitely go in as an administrator and change
them. But your access to the actual POSIX-based system through MetaCreator allows us to be able
to go in and start taking notes on what to expect on the overall system. And that's not the only
thing that we can do. We can actually go in and take a look at what the password requirements are
and how the system deals with them. We can do that by typing in cat slash etsy slash
pam.d slash common password. And inside of here, and I'm going to highlight a specific line for
us to take a look at, that first one right there, the YesScript option enables blah, blah, blah.
That means that YesScript is enabled on this specific system. And that tells us, along with
the rest of this file, what the prerequisites are for the actual password itself. Again, there's a
little bit of research involved in this and basically taking notes out of this and getting
an understanding of how the system interacts with users is good for you and me to know later on
what our left or right limits are when it concerns being able to take advantage of users on the
system. Now you may be wondering what that common passwords, what else it holds for us. And like we
mentioned with the YesScript being a possibility inside of Ubuntu, that kind of starts the narrowing
of our criteria for programs like John the Ripper. We covered password attacks in depth in a few
skills prior to this one. And the reason we did so is because tools like John the Ripper allow us
to be able to brute force based on a certain understanding of what hash it is. It will brute
force overall, but I mean, if you can identify the hash, it makes it even better. Now, yes,
I know that Ubuntu and other POSIX-based systems identify the hash with the first couple of dollar
signs in their actual hash output, but it's always good to know because that way you can
narrow the field down of possibilities to save yourself time if you have to find yourself
running John the Ripper from a hash dump. You don't want to play the guessing game. You want
to try to rule out as many of the options there are out there as possible to narrow it down so
you spend less time wasting resources or spending resources on something that could have been done
a whole lot sooner. And that way you can actually spend more time
on attacking the actual network and searching for those vulnerabilities.