Last month I wrote an article about the way low-code/no-code platforms are offering credential-sharing as a service, why they are doing it, and how this looks from an attacker’s perspective. In this article, I’ll focus on the implications of that compromise and how it affects enterprises today.
Here’s why sharing your enterprise credentials with somebody else is bad practice. Say I want to pass my credentials to a colleague in order to query production logs for some one-off user-behavior analysis. In a typical enterprise, granting someone permissions to query a new data source could mean a long access review process, especially when it comes to production or sensitive data. My colleague could easily get frustrated. “All I wanted is to do this tiny one-off query, and I’ve already been waiting for a month!” they could say. I could just run the query for them, but I’m swamped with my own day-to-day tasks, and one-off queries tend to get complicated.
I am left with one quick solution: I could just share my username/password with my colleague. If they get an MFA challenge, I’ll gladly approve. I don’t have to spend the time running the query, and my colleague gets unblocked. Everybody wins! Right?
Well, you would be right in your analysis, but you are missing the bigger picture. While it’s important for the enterprise that your colleague gets their user behavior analysis done, it is equally, if not more, important that your enterprise remains compliant with a whole host of privacy and security standards and maintains customer trust by upkeeping the company’s commitment to security.
If high-level enterprise goals do not convince you, consider the central management teams in IT or security. Those teams base their operations and security strategies on the fact that each user has their own unique identity. IT teams are setting up networking and access policies that assume each user would be logged in from one corporate IP or corporate laptop at once; security teams are correlating events based on user ID; finance teams could be aggregating cost reports per user and their personal cloud environment. Credential sharing undermines all of those assumptions, among others. It strips away the basic meaning of an online identity.
A Real-World Example
Let’s turn to the world of low-code/no-code and examine a real-world scenario. In a large enterprise, Jane, an inspired employee from the customer care team, realized that when employees across the organization take part in a customer case, they are usually missing key information about the customer, such as their support case history and latest purchases. This degrades the customer’s experience, since they have to explain their issue again and again while the case gets routed to the right employee who can address the issue.
To improve this, Jane created an app that allows company employees to view this key information about customers when those employees are part of the team responsible for addressing the customer’s support case. First, let’s take a moment to acknowledge the power of low-code/no-code, which allows Jane to identify a need and address it on her own, without asking for a budget or waiting for IT resource allocations.
While building the application, Jane had to work around multiple issues, the biggest one being permissions. Employees across the organization don’t have direct access to query the customer database to get the information they need. If they did, then Jane wouldn’t have to build this application. To overcome this issue, Jane logged into the database and embedded her authenticated session directly in the application. When the application receives a request from one user, it will use Jane’s identity to execute that query and then return the results to the user. This credential-embedding feature, as we explored last month, is a key feature of low-code/no-code platforms. Jane made sure to set up role-based access control (RBAC) in the application such that every user can only access customer cases they are assigned to.
The application solved an important business problem, and so it quickly gained user adoption across the enterprise. People were happy that they could provide better service to their customers by having the right context for the conversation. Customers were happy, too. A month after Jane created the application, it was already used by hundreds of users across the organization, with customer satisfaction rates rising.
Meanwhile at the SOC, a high-severity alert showing abnormal activity around the production customer database was triggered and assigned to Amy, an experienced security analyst. Amy’s initial investigation showed an internal user was trying to scrape the entire database, querying information about multiple customers from multiple IP addresses across the organization. The query pattern was very complex; instead of a simple enumeration pattern you would expect to see when a database is being scraped, the same customer’s data was queried multiple times, sometimes through different IP addresses and on different dates. Could this be an attacker trying to confuse the security monitoring systems?
After a quick investigation, Amy uncovered a crucial piece of information: All of those queries across all IP addresses and dates were using a single user identity, someone named Jane from the customer care team.
Amy reached out to Jane to ask her what’s going on. At first, Jane didn’t know. Were her credentials stolen? Did she click on the wrong link or trust the wrong incoming email? But when Jane told Amy about the application she recently built, they both realized there might be a connection. Amy, the SOC analyst, wasn’t familiar with low-code/no-code, so they reached out to the AppSec team. With Jane’s help, the team figured out that Jane’s application had Jane’s credentials embedded within it. From the database’s perspective, there was no application — there was just Jane, executing a whole lot of queries.
Jane, Amy, and the AppSec team decided to shut down the application until a solution was found. Application users across the organization were frustrated since they had come to rely on it, and customers were feeling it, too.
While Amy closed the issue and documented their findings, the VP of customer care was not happy seeing customer satisfaction rate drop, so they asked Jane to look for a permanent solution. With the help of the platform’s documentation and the organization’s Center of Excellence team, Jane removed her embedded identity from the application, changed the app to use each user’s identity to query the database, and ensured users gain permissions only to customer cases they are associated with. In its new and improved version, the application used each user’s identity to query the customer database. Jane and the application users were happy that the application is back online, Amy and the AppSec team were happy that Jane’s identity is no longer shared, and the enterprise saw customer satisfaction rate starting to climb up again. All was well.
Two weeks later, the SOC received another alert on abnormal access to the production customer database. It looked suspiciously similar to the previous alert on that same database. Again, IP addresses from across the organization were using a single user’s identity to query the database. Again, that user was Jane. But this time, the security team and Jane knew that the app uses its user’s identities. What’s going on?
The investigation revealed that the original app had implicitly shared Jane’s authenticated database session with the app’s users. By sharing the app with a user, that user got direct access to the connection, a wrapper around an authenticated database session provided by the low-code/no-code’s platform. Using that connection, users could leverage the authenticated session directly — they no longer had to go through the app. It turns out that several users had found this out and, thinking that this was the intended behavior, were using Jane’s authenticated database session to run their queries. They loved this solution, since using the connection directly gave them full access to the database, not just for customer cases that they are assigned to.
The connection was deleted, and the incident was over. The SOC analyst reached out to users who had used Jane’s connection to ensure they discarded any customer data they have stored.
Addressing the Low-Code/No-Code Security Challenge
The story above is a real-life scenario from a multinational B2C company. Some details were omitted or adjusted to protect privacy. We’ve seen how a well-meaning employee could unwittingly share their identity with other users, causing a whole range of problems across IT, security, and the business. As we explored last month, credential-sharing is a key feature of low-code/no-code. It’s the norm, not the exception.
As low-code/no-code continues to bloom in the enterprise, consciously or not, it is crucial for security and IT teams to join the business development conversation. Low-code/no-code apps come with a unique set of security challenges, and their prolific nature means those challenges become acute faster than ever before.
