-: Attacking AAA protocols and Systems.
So we've talked about how important AAA is to our networks
and we talked about some different protocols
like TACACS and RADIUS and Kerberos,
so now let's talk about how we can attack those things
or how attackers will attack those things
and how we should be defending them.
Directory, authentication and SSO systems
are great targets for attackers to go after, why?
Because they're the keys to the kingdom,
it's what gives them access to our system.
So attackers are gonna use specific vulnerabilities
and misconfigurations to target our protocols
or the way the servers implement those protocols
This is gonna allow system compromises to occur,
especially of domain controllers and other AAA systems.
We have to be able to be looking for these
and we have to be able to stop them
as cybersecurity analysts.
Now, the first one I want to talk about is attacking LDAP.
We talked about how important LDAP was and how it's used
in so many different configurations.
Well, there's a couple of key things we want to look at.
One, is attackers are gonna target unencrypted LDAP traffic.
They're gonna try and capture it
and use it in replay attacks.
How do you stop that?
Well, you secure binding or encryption to prevent it, right?
That makes sense.
The next thing we want to look at is
how they target improper access controls
to harvest directory information
and modify directory accesses.
So, how do we stop that?
We setup proper access controls.
The next one we want to talk about
is they can perform LDAP injections
against your vulnerable web applications trying
to put things into your directory that shouldn't be there.
How do you prevent that?
Well, input validation is a great way to check that
and using least privilege
so the web apps can't create admin accounts, for example.
They can only create user accounts.
And finally, they can conduct denial
of service attacks against you.
They can try to cause services to fail.
How do we overcome this?
Redundancy.
Anytime there's an attack on availability we want
to look to redundancy.
So designing scalable LDAP infrastructure for redundancy
in additional servers is going to help us survive
that attack.
Now, the next one we want to look at is the RADIUS protocol.
We mentioned that Radius was an upgrade to attack us
but it was still pretty old and secure.
Some of the things that they can go for
on this is session replay because
of that unencrypted connection by default.
How are we going to overcome that?
We're gonna use IPsec tunnels and add encryption.
They can compromise your shared secret key
from client machines.
That's a real vulnerability that we have
to be concerned at with RADIUS.
Again, trying to use a longer,
better hashed key will work well.
But again, radius will only support so much.
Again, you want to use encryption and end-point protection.
Brute forcing your shared secret key from a stolen password
and trying to reverse engineer that secret key
is another thing they can do.
And so, again, changing your passwords often; every 90 days
or every year.
At least every year but hopefully every 90 days
will help secure those endpoints.
And then denial of service.
They can try a temp denial of service against you.
Again, redundancy is what's gonna help you here.
Now, the next one we want to talk about is Kerberos.
Like we said Kerberos is very, very popular.
So a lot of people focus on going after Kerberos.
Kerberos relies on central key distribution center,
or KDC's.
Now, the compromise of the KDC can allow impersonation
to occur and they can pretend to be any user that they want.
There's things like "pass the hash" and other attacks
that can be used.
Some of the common attacks you're going to see
is stealing admin account credentials
and then passing those around
using what's called "pass the hash".
Other things they can use is doing ticket reuse.
We talked briefly about how Kerberos uses tickets
to authenticate the services.
Well, if they can get a ticket they can pass the ticket
and allow them to impersonate that user
for the lifespan of that ticket,
which normally is only a couple of days.
Now, the other one they can do is passing the key.
Passing the key is going to allow reusing the secret key
to get new ticks and extend their access.
One of the biggest threats we have against Kerberos is going
after ticket granting ticket
because these are the "golden tickets" as they're known.
If they have a golden ticket it allows them
to create new tickets and even extended duration tickets
that allows them to do account changes,
escalate privileges,
create new accounts,
delete old accounts,
change new services,
all sorts of bad stuff.
If they can get a "golden ticket" on your system
then they pretty much own your domain at this point.
The next one we'll talk about is active directory
which, again, is really central to our Windows domain.
It is the core identity store and AAA service
for Microsoft Windows domains.
Therefore, there are ton of exploits
that have been built for it:
Going after the clients,
going after the servers,
and going after the AD service itself.
Many Windows domain controllers also have older systems
still connected to them
so they have to use backwards compatibility
for things like NTLM
and some of these older authentication schemes
which makes them very, very vulnerable to attack.
The best thing you can do
upgrade those older systems or get them off the network
and put them onto an isolated network
because they are dragging down your security.
This is a very common attack vector for attackers.
Now when we talk about active directory
there is many different ways to attack it.
One is going and using malware to try to steal credentials.
Another, is using social engineering or phishing
to get the account credentials from a user.
The other ones you can do is malware
that's focused on exploiting the server
instead of exploiting the client.
The other thing you can do is focus
on attacking older services like
NTLM, netBIOS, LANMAN, unsigned LDAP,
and SMB, service-message block protocols.
If you can go after these older services
you can then get a foothold into active directory
and really cause some havoc.
You can also look out for things like privilege creep
of service accounts.
Should a service account have admin rights on the domain
or be a domain admin user?
Probably not. Right?
So look at what groups these service accounts
are being placed in.
The other thing you want to look at is overuse
of domain admin credentials.
Are your system administrators using their domain admin
credentials every time they log in the box?
They shouldn't be.
They should only be using those credentials when they need
to do domain admin functions,
which should be a very small portion of the time.
The other thing you want
to look at is privilege escalation attacks.
So look at your accounts and see
"is Normal User in an admin group?"
One of the common ways to keep this separate
is use some sort of naming convention.
For example, you might have
admin.jason
admin.scott
That means those people are admins.
Jason would have his own account
and Scott would have his own account.
So we have an admin account and a user account.
So if I see a normal user in my admin groups
that doesn't have admin. in his name
that can tell me that that person doesn't belong.
So, again, looking for those privilege escalations
and try to maintain them is going to help you prevent
some of these attacks.
The next one we want to talk about is
Oauth, OpenID, and OpenID Connect.
These OpenID and Oauth are used and implemented
by each service provider.
So if I have a website like jasondion.com
and I choose to use google authentication using OAuth,
well, then I'm the one that has to configure it
and I can configure that incorrectly.
This happens all the time.
This is where most of the insecurities lie is
in misconfigurations.
They can allow for things like open redirects to happen.
That is one of the most common attacks
you're gonna see out there.
The redirects and forwards aren't validated
so instead, when I tell you to go to my website
and login using Google it will take the credentials
and the authorization from Google and forward that
on to a malicious website, for example.
That would be bad.
So, again, you have to make sure these configurations
are done properly.
This allows untrusted user input to be sent to web apps
and then those users can be redirected
into untrusted websites.
This gives you a potential
for phishing, pharming, and bypassing web security.
So make sure the configuration is done properly
if you're going to be using third party authentication
using things like OAuth, Open Connect, and Open ID.
Your original account information
the Google ID you had is not going to be what's compromised,
but your web application,
i.e. me the service provider,
may be allowing in untrusted users.
So that's what you really got to worry about is
if you are that service provider,
if you are the website,
the training site,
the e-commerce site,
that's allowing Google logins,
make sure they're not coming from redirects
and make sure they're coming directly from Google
by using proper configuration.
The next thing you need to worry about
with Oauth and OpenID and OpenID connect is a couple
of these other vulnerabilities from the early iterations
to those protocols.
OpenID, for instance, in its early days
there were attacks against the protocol itself.
These attackers were able to forge request
to gain arbitrary logins.
When I started researching this, it really comes down
to things back in 2012.
Those things have been fixed in the latest version of OpenID
but it's still something to think about
if you're using older protocol.
OAuth2, for example, was vulnerable
to cross site request forgery attacks
and OAuth2 is still the latest version.
So these attempts allow a user to click on a link
so that their browser will perform an action as a user.
And, again, this is if you go to a malicious website
they try to pretend they're a real website
and they try to do a cross site request forgery
to get your Google ID credentials
to authorize you to a third site.
OpenID Connects provides an additional encryption layer
and signing to prevent many of these exploits.
Oauth2 has been replaced by OpenID.
It's kind of like version 3, if you will.
You need to be using the latest versions
and the latest configurations to protect your services.
Again, if you're going
to be using third party authentication
you have to think of some of these risks
and determine risk vs reward:
"Is this worth it?"
We'll talk a little bit more about that later.