When Infosec and Weed Collide: Handling Administrative Actions Safely

BB King//*

The state of Ohio recently validated a webapp pentest finding that sometimes goes overlooked. It relates to the details of administrative functions, how they can be abused, and how just the potential for abuse can call all of your data into question.

Here’s what they found:

COLUMBUS, Ohio — A “critical flaw” in Ohio’s process for grading medical marijuana grow applications could have allowed a state employee to change scores or manipulate other documents, the state auditor’s office found.

Two Ohio Department of Commerce employees had unlimited access to the online accounts of more than 20 application reviewers and associated documents, according to Auditor Dave Yost’s office. The employees also created and managed passwords for the application reviewers, who were only granted access to certain parts of the application.

In a Feb. 6 letter to Commerce Director Jacqueline Williams, Yost wrote that the weakness could have allowed an employee to log in as a reviewer and change scores. The “weakness,” as Yost refers to it, means auditors can’t tell whether a record was revised by an application reviewer or someone else logging in as the reviewer.

Source: http://www.cleveland.com/metro/index.ssf/2018/02/ohio_auditor_finds_flaw_in_med.html

Administrators need to be able to create user accounts. In some situations, they also need to be able to reset passwords. In still other cases, they may need the ability to impersonate another user in order to diagnose a problem, to provide training, or help resolve problems in real-time. All of these things are legitimate needs, but each of them, if done poorly, can poison your audit trails, making it impossible to determine who did what in the application, and making your application’s data completely unreliable.

Any time an administrator does anything “on behalf of” another user, it’s important that the event is logged as such. Investigators must be able to tell that a second user was involved, who that second user was, what that user did, and when it was done.

Without such logging, it becomes impossible to know for sure who took any given action. How serious a problem is that? It depends on what you want to be able to do with your data, and what responsibilities your users may have to ensure that they’re doing things “correctly” (whatever that means for your situation).

The Auditor for the State of Ohio summarized the problem:

This control weakness could allow an administrator access to manipulate documents … while logged in … as an account holder rather than their own administrative account. Because of this critical flaw in the procedure’s design, neither this office nor the public, can rely upon the … results.

Source: https://assets.documentcloud.org/documents/4377305/2-6-18-Commerce-Letter-Director-Williams-2.pdf

When an administrator has access to user credentials, the administrator can untraceably impersonate that user. Credentials are not just username and password, but anything that gives access to an account. In a webapp, the session cookie is a credential.

If you’re storing user passwords in cleartext, or any other way that allows them to be used as-is from the database, the problem goes far beyond the auditing issue. Even showing a password hash, though (as some admin panels do), can approximate the same problem. Hashes can be cracked. For audit purposes, a hash revealed may have to be treated as a password revealed.

There are more resilient ways to handle the need for administrative access to accounts.

• Password self-service, where a user can change or reset their own password by proving their identity to the application through use of a shared secret. Where an administrator must be involved in password resets, the user should be forced to change that password before doing anything else in the application.
• Use of “ride-along” functionality for technical support. When an administrator needs to see exactly what a user is seeing, the application can be built such that the user must invite the administrator into their session, and actively allow them to control it. This grant of permission would be recorded, and all events while the administrator is alongside would be flagged as such, clearly identifying both people involved in the session.
• Use of “on behalf of” signons. In the rare cases where there is a need for an administrator to use another person’s account, that must not mean the administrator gets access to the user’s credentials. An impersonation system that clearly records which person was at the keyboard during the events of that session is required. In sensitive cases, this notation should be displayed alongside the relevant data in the UI so that it cannot be missed.

*Full disclosure: BHIS was not involved with this action by the State of Ohio in any way. We just noticed it in the news.