Thousands of ecommerce sites are inadvertently leaking customer data via Oracle NetSuite SuiteCommerce (NetSuite Site Builder) access control misconfiguration.
“NetSuite is one of the world’s leading enterprise resource planning [ERP] systems and handles business-critical data for thousands of organizations,” explained Aaron Costello, chief of SaaS security research at security firm AppOmni, the cybersecurity firm that discovered the security flaw.
Costello says the vulnerability allows unauthenticated users to query sensitive customer information via API endpoints by chaining a CRUD (create/update/delete) and reporting function.
However, AppOmni has clarified that the security faux pas was not the result of a NetSuite security vulnerability but site administrators’ oversight. Nonetheless, the victim count could be significant based on the number and profile of affected stores.
Thousands of SuiteCommerce ecommerce sites leak customer data
According to AppOmni, the vulnerability stems from how clientside scripts interact with the API and access custom record types (CRTs), which include sensitive customer data. It exposes personally identifiable information (PII) of registered customers, including full addresses and mobile phone numbers.
This information is invaluable for crafting phishing attacks that could further expose significant personal data, leading to fraud and account takeovers. AppOmni says thousands of SuiteCommerce ecommerce sites are inadvertently leaking customer data, exposing them to unacceptable risks.
“Based on my initial investigations, several thousand live public SuiteCommerce websites are already affected,” said Costello.
However, the San Francisco, California-based firm did could not estimate the number of customers impacted. Nevertheless, thousands of established ecommerce sites with thousands of customers use NetSuite SiteBuilder, leaving a significant number at risk.
Even worse, many NetSuite customers were unaware that public-facing ecommerce sites deployed on their tenant by default were hemorrhaging customer data. This unawareness could leave customer information exposed longer, increasing the chances of unauthorized access.
“In many such cases, organizations using NetSuite that had no intention of deploying a commercial store were entirely unaware that a default stock website had been deployed publicly upon purchase of their instance,” the report said.
In addition, many vulnerable ecommerce sites had problems determining if unauthorized actors had accessed customer data, as NetSuite’s logs are difficult to access. Subsequently, AppOmni ecommerce sites suspecting unauthorized customer data access to contact NetSuite and request raw log data.
Meanwhile, NetSuite insists that the impacted components were working as intended, shifting the blame squarely on site administrators.
However, NetSuite is working on fix to solve the security misconfiguration, while AppOmni has developed a solution to detect misconfigured instances and notify site owners.
How NetSuite access control misconfiguration leaks customer data
Compared to Standard Record Types (SRTs) which are tables provided by default, CRTs are tables “created by the customer that were not provided with the NetSuite tenant.”
According to NetSuite’s design, CRTs employ both “table-level” and “field-level” access controls (ACs). Table level AC is defined by “Access Type,” which could be “Require Custom Record Entries Permission,” “Use Permission List,” or “No Permission Required.” Any entity without a role, such as unauthenticated users, defaults to “No Permission Required.”
Similarly, custom fields implement three access levels: the RDS List (Role/Department/Subsidiary), “Default Access Level,” and “Default Level for Search/Reporting.”
However, custom fields of a CRT with “No Permission Requried” defaults “Default Access Level” and “Default Level for Search/Reporting,” since table level users do not fit into the RDS List.
Unfortunately, the two default levels have their permissions set to “Edit,” the most privileged permission, setting the stage for unfettered access.
While administrators modify the “Default Access Level” to either “View” or “None” instead of “Edit” to limit unauthenticated access via the loadRecord function, they usually leave the “Default Level for Search/Reporting” set to “Edit.”
Subsequently, threat actors could leverage the “nlapiSearchRecord” function, whose permissions are determined by the “Default Level for Search/Reporting” rule to read restricted data.
While the nlapiSearchRecord requires knowing the table’s field names, it also returns field IDs, which could be loaded into loadRecord to return restricted fields’ names. The threat actor could then feed the field names into the nlapiSearchRecord to expose data.
