User-Specific Secrets: Console Access

ACM.93 Testing that the user we granted AWS Console access can see their user-specific secret in Secrets Manager

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Part of my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: AWS Security | Application Security | IAM

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the last post I had to take a timeout to write some automation code to speed up redeploying stacks in a failed state.

Now we’re back to our main thread — creating a user-specific secret that a user can access in the AWS console.

You can find the other posts related to user-specific secrets here:

Providing AWS Console access to our user-specific secret

Alright, we now have a user that can log into the AWS console. I wanted to the secret in Secrets Manager. Login and make sure you are in the correct region. As it turns out, our policies do not allow the user for whom we created the secret to access the secret:

I’m going to guess that error is due to basic listing of services in the AWS console because now we are not just accessing a single secret, but let’s find out. Head on over to CloudTrail.

As I suspected. ListSecrets. Access Denied. We need to add that, even though the user should only have access to one secret.

I updated the user secret policy to add that permission.

Now, I mentioned in a prior post that my User template was creating a secret with a console password even for users that were not supposed to get console access and they didn’t. It is at this point I remember that I added an untested condition to the secret to only deploy it if the ConsoleAllowed condition is true:

Unfortunately AWS CloudFormation doesn’t work when you do that the way I have my template set up. I have a dependency on the Passwrd in my User resource:

So the user cannot be created unless the Password exists. As it turned out I don’t think the dependency was the problem. Let’s try to remove it.

I also removed the Password output at the bottom of the template that we added to confirm the incorrect password showing up when we referenced the password in the user Resource (an issue I still hope to resolve but am ignoring at the moment). This documentation doesn’t seem to be working as explained in the last post:

Aha. I think I figured it out. I’m not sure if I am delusional but I think the documentation just changed or I was looking at a different page that said you could reference an object you created in CloudFormation but it wasn’t working no matter how I tried to do it. Then, as mentioned, I found a post referencing the full ARN of the secret on stack exchange — and now that appears in the above documentation. Maybe I was looking at a different page.

At any rate this deploys with no dependency and I think I was using this format last night and it wasn’t working but now it is.

Since we re-deployed the user I presume the password changed and all our extraneous secrets should be gone. Let’s check.

Well, one thing is interesting. If the password is different, it didn’t affect my active logged in session. That’s something to be aware of if you are trying to terminate user access to your cloud accounts.

Here’s some information about revoking roles. But our user is not using a role.

Hmm, I am not immediately finding a way to terminate an individual user’s IAM access. This is a good case for why you might not want to give any permission to a user but rather make them assume a role since you can terminate role sessions.

Anyway, let’s logout and log back in with the new password — an explanation of all that was in the last post.

So, this is intersting…

If the above is true then how was I able to set the password for this user last night? Let me close out and return to this page in an incognito window like I did last night. Odd. Somehow I could reset the password last night but not today. My developers need permission to change their own password. Thankfully there’s a policy for that:

Another version, slightly different:

I added that to my user specific secret policy because right now the only users that need access to the console are those with a secret. That may change later, in which case I might want to create a separate policy for password changes. Anyway, let’s test it out.

Well, I can now change the password and thankfully it did not remove MFA from before the change of password with CloudFormation.

I’ll also make one more note here that for console access, I would prefer to use a Yubikey, but I can only set one MFA device with AWS IAM. I did recently notice that you can set two in AWS SSO which is much better. That way you can have a backup. The other way around this would be to give users a two separate IAM accounts — one for console access and one for programmatic access.

But it still says I can’t list secrets. I know what the problem is…

This is something I always found odd with AWS policies. I have to give the user access to list ALL secrets even though they are only supposed to use one secret. The same is true for other policies like S3 bucket policies. I think it makes the policies more confusing than they need to be and I don’t *want* to allow my user to list all secrets. But that’s what we have to do.

So this:

Becomes this:

Ick. But let’s see if it works.

Refresh the page with the secret and yes, now I can see *ALL* the secrets unfortunately. I don’t want users to see all the secrets or all the buckets in my account if they are only supposed to access one. Same for application roles. I really wish AWS would fix that. #awswishlist.

However, when I click on a secret, I can’t see it. It’s not real pretty but it works:

I can open up the secret the Developer is supposed to be able to access, but can’t view the Secret value in the console. Is it just malformed or a permission issue?

Let’s check CloudTrail. Looks like we have a few issues:

And in case you can’t read that (I can’t) our developer needs these permissions;

Another permission I wish we did not have to add for this purpose:

Why does this user need to see every encryption Key alias to view a secret?

I don’t think we need to allow the developer to get the resource policy.

We have already granted KMS decrypt to the developer key in the IAM policy. Let’s check out our KMS policy. And yes:

Once again AWS has changed the KMS policy without warning to what I think is some sort of user ID. This is really problematic. If a user or role is ever deleted and recreated you need to redeploy your key policy. And make sure you don’t delete the user that administers the key!

Also just a reminder, the policy key won’t update with a CloudFormation stack that hasn’t changed, so I added a timestamp parameter to the policy to force the change in this case. I’m redeploying the key now…

And…I just remembered that I forgot to add back MFA for my KMS admin.

The fix is definitely to restore the user ARN above. The problems I had restoring the KMS admin warrants a blog post unto itself.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2022

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab