Story Time:
This scenario reminded me of a customer story from a few years ago when an organization's security and admin team hadn't recognized what they'd unintentionally done.
I'm hoping that it's an educational (and maybe even fun) sharing of something that can happen when we are unable to practice Defense-In-Depth or don't practice what Ted Lasso so wisely teaches us about when he says, "Be Curious."
In any case, I was working with an organization on the 2nd day of an engagement, and I was working with the staff, monitoring traffic, reviewing alerts, tuning the config, etc. (ie.. the normal stuff) When I happened upon a SQL Injection violation. It's not necessarily uncommon to see one, but this one was from an RFC1918 address (eg.. 10.10.3.4), it was with an account I recognized to be a default and highly privileged system account for the database, and it was a non-obfuscated, and rather long SQL query. I spent a little time researching it, reviewing the other related violations on the same alert, and making sure I had my facts straight.
Then, I called over my technical contact at the organization, asking them to take a look at the SQL Injection I had up on the screen, calling their attention to the IP and related violations, etc. After possibly as long as 10-seconds, their response was, "That's a false positive. Just allow it."
** Now, don't get ahead of me in this story. just stick with me here... **
I told them that I disagreed with them because of the: a) system user, b) the internal IP, c) the complexity of the SQL Command itself (it was at least 1000 characters long), and d) the query was successful in returning a significant volume of sensitive (ie.. "Private") data. So, I asked my contact if they could clarify why they considered it a false positive. I mean, they certainly know their environment better than I did, but this was triggering multiple red flags for me...
The engineer spent a few more seconds reviewing the alert data, and then yelled across the cube farm to a network engineer and asked "Who is 10.10.3.4?" The response yelled back was that it was "Customer X." My contact again said, "Oh yeah, that's OK, you can allowlist that. We told them how to do that."
Well now, my curiosity was really piqued, and so I said, "That's interesting. Could you explain that to me a little bit more?"
I believe at that point, the engineer thought I was a bit dense, but they indulged me and shared the following details. And as I continued to dig deeper and ask "Oh, tell me more about that." or "Can you expand on that a little more?" they shared the following salient data points with me:
- Their organization provided a SaaS solution to a niche market segment that was COTS Software (or OEM perhaps) that they then made available as a service to a specific vertical.
- Since the SaaS solution they provided was really COTS or OEM software; they could not modify the software/code
- The customers of this business organization were presumed to be "trusted" because they were all connected to this business over MPLS, VPN, or Dedicated Connections.
- Customer X was a very important customer to this organization.
- Customer X wanted a custom report created for them to comply with some audit or routine processing, etc.
- The COTS software provided no capability to create custom reports.
- The organization's leadership told their Lead DBA to solve the problem for their "VIP customer."
- The DBA being a brilliant developer/engineer created a custom SQL query that would deliver the custom dataset/report that Customer X wanted using their existing client application.
- The COTS client had the system account embedded (hardcoded) in it.
- The organization and its flagship product in question organized all of its customer's data in a centralized and shared datastore.
- Customer X is the only customer (organization) that was given this SQL query.
** <Please Pause here for a moment> **
Now, if you're tracking along with this, I would love for you to please put yourself in my position, understanding the Risk involved in this situation/environment, and reply to this post with the first response that would come to your mind for you in that situation. Please Reply first; then, <scroll down to continue>
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Okay, back to the customer story... I explained to the engineer, and eventually to their DBA as well, that with that embedded system account, and the fact that they had "admin" level permission to their organization's shared datastore, they could actually change a few variables, or send a different query entirely, and retrieve additional data for their organization's data or another organization in the shared datastore, or dump the database, etc...
I suggested that we could the following, and then implemented it:
- Create a signature for that single query they provided to their VIP customer, to match against,
- Then, create an exception to the general SQL Injection rule for "Customer X and that signature specifically." So that we'd eliminate the SQLi alerts we were receiving, yet were expected.
- Create a custom security policy to match on the use of that specific signature and customer-specific IPs, as "alert only", so that they could monitor the usage of that signature/query if they wanted to. We used this policy during initial testing.
- And then, create another custom security policy to block SQL injection attacks from Customer X that did not match that specific signature/query. We implemented this as an alert only during the first few weeks initially.
- Impress upon their leadership the need to have the custom report capability implemented as a feature in a future version of the COTS software they used, and to have the embedded admin account model in that software changed ASAP.
- They needed an additional way to protect their data. eg.. find a way to segment their customer data, or tokenize it, or implement customer-specific encryption, etc...
So, a few of the lessons learned that day were:
- Implicitly trusting a customer (or Business Partner) organization to either not be malicious, compromised, or just "curious", they'd have unfettered access to all of their SaaS provider's customers' data (if they chose to exercise that ability.)
- In my opinion, the concept of Zero Trust was not widely known at the time. If it had been, I like to think that multiple tenants, and multiple steps in the process/framework of zero trust would have exposed the multiple problems above. Looking at it as a tabletop exercise, it seems like a comedy of errors, but I know that when different people are involved in just their piece of it, over time, it's easy to miss the warning signs that jump out at us in review.
- By not having any solutions in place to provide visibility, protection, or control, they'd never have known if someone was accessing more data than they were "supposed to", and their organization was put at significant risk.
- The Separation of Duties provision in NIST and SOX and other industry regulations is really important and makes a lot of sense in terms of Risk and Cybersecurity.
- This organization could have benefited from Data Risk Analytics and it's zero false positives.
.
This story is about a specific organization being instructed on how to successfully initiate a SQL Injection attack against their own data, but that same capability was available to the 300+ other organizations that were customers of the organization I was working with. And any compromised, malicious, bored, or curious users (ie.. the "Insider Threat") at any of those 300+ customer organizations could have just as easily leveraged their existing access to do the same thing, that the business specifically instructed one of their customers how to do themselves.
It's really pretty scary to think about, but I'd love to hear your feedback
------------------------------
John Thompson
Director, Channel Presales
Imperva
San Diego CA
------------------------------
Original Message:
Sent: 02-02-2024 01:15
From: Angfe Landagan
Subject: [Cloud WAF] cross site scripting whitelisting for specific url (/abc) with geolocation ip - alert only
Hello practitioners,
What is the effective way to mitigate a cross site scripting attack on a SPECIFIC URL (/abc) where geolocation is activated- allow ip address within a country and log mode is Alert Only?
Im hesitant in having this WHITELISTING logic setting since users around the country are accessing this url.
May tips on how we can investigate or gather information
#Whitelist
#GeoBlocking
#GeoLocation
#XSS
More power,
A
#CloudWAF(formerlyIncapsula)
------------------------------
[Leangf]
------------------------------