Wait… Who Are You Again?
A couple weeks ago, when logged into a website provider’s admin panel, I found a strange user in my account with admin rights that I did not recognize! As you can imagine, this triggered all my alarms. I took a screenshot, removed their access, looked them up on LinkedIN, and contacted the provider’s support right away. They were a CEO of boutique consultancy! Who was this person and why would they have access to my account?? Very odd and disturbing at the same time. Could this be a bug with the SaaS provider’s IAM system?
Well, of course 1st tier support couldn’t get me the logs or answer my question, so I asked for the security team. They kindly forwarded my request and said they would get back to me in a few days. Frankly I didn’t expect my request to be forwarded or to hear back at all… but lo and behold they responded! (Actually a Product Manager, not Security) After some authentication of my identity, they provided me the details of what transpired.
Could this be a bug with the SaaS provider’s IAM system?
Turns out, when I invited my developer to the account, they were signed in as someone else! When they clicked the link, access was given to the account they were logged in to, not their actual account. Those pesky cookies!!
Turns out, when I invited my developer to the account, they were signed in as someone else!
Two things went wrong here:
First, the developer was logged in as someone else. Tsk, tsk. #1 rule about identity management, no shared accounts! Every login id should be tied to a human (if your dog or cat has their own email, please leave a comment below).
Second, the SaaS website provider does not tie the actual account access to the user. Instead, they send the user a public link, which anyone can access! This is somewhat old school and they should know better. I have since filed a bug report, let’s see what they say.
Moral Of The Story: Trust… But Verify
People are great at what they do, but they sometimes make mistakes. Cloud providers provide awesome platforms and software to conduct our work, but they’re not infallible either. Bugs happen or tools may not work exactly as expected. We need to bake in security at various levels in case anything else fails.
5 Steps You Can Take Right Now To Prevent This
- Ensure all user accounts are tied to an individual. No shared user accounts. Use 2FA on all accounts, or at least on higher privilege or high risk accounts*.
- Add notifications/tracking/audit trail whenever access is granted/removed
- Verify your access and permission work as desired. (AWS IAM rules for example can be tricky.)
- Review access controls often (at least quarterly), especially for access creep
- Have a clean and documented onboarding and offboarding process. Standardize your roles; document and expire any exceptions. (Former employees and contractors can often have access for months and sometimes years!)
*Shared accounts = high risk accounts.
Ayman Elsawah – AWS Security Strategist
This article first appeared on LinkedIN on May 22, 2018.