Oracle NetSuite Flaw Exposes Sensitive Data to Hackers

Misconfigured access controls on NetSuite Custom Record Types (CRTs) within SuiteCommerce environments expose sensitive customer data, including PII, where attackers can exploit these misconfigurations to access public-facing sites and steal data. 

Thousands of live SuiteCommerce instances are currently vulnerable due to improperly configured default websites or insufficient access control settings on CRTs. 

Oracle has acknowledged the issue and introduced additional security measures, but administrators must still implement stringent access controls and carefully review CRT configurations to mitigate the risk of data exposure. 

NetSuite employs a client-server architecture where UI Suitelets, comprising forms and client scripts, interact with server-side components via web-accessible APIs. 

Client scripts trigger these API calls to perform server-side operations, such as database interactions. While both SuiteScript 1.0 and >2.0 utilize this pattern, the latter imposes stricter access controls on server-side modules from client-side scripts.

By employing a robust access control mechanism for unauthenticated users, it primarily focused on Custom Record Types (CRTs), which, akin to database tables, offer table-level access control options: Require Custom Record Entries Permission, Use Permission List, and No Permission Required. 

The latter, while granting open access, is generally avoided due to security implications. Field-level controls further refine access within CRTs, using Role/Department/Subsidiary Lists, Default Access Levels, and Default Levels for Search/Reporting to determine visibility and permissions based on user roles and other criteria. 

The N/record module’s loadRecord function retrieves data from NetSuite custom records, which requires the record type, internal ID, and optional default values. Successful execution returns accessible field values and all field names, regardless of authorization. 

For unauthenticated users, data access depends on the custom record’s “No Permissions Required” access type and individual field default access levels. The N/search module in SuiteScript 2.0 offers a flexible way to query NetSuite data by specifying desired columns and filters. 

While it provides more control than the record API, it relies on the ‘Default Level for Search/Reporting’ field setting to determine data accessibility, potentially exposing sensitive information if not configured correctly, which contrasts with the record API’s stricter access controls based on field-level permissions. 

Appomni describes a three-step Proof-of-Concept (PoC) for exfiltrating data from NetSuite as an unauthenticated user by leveraging a custom record type (CRT) with specific access controls. 

First, the attacker enumerates record IDs using a searchRecord call targeting the vulnerable CRT, then they use the loadRecord call to retrieve specific fields with “View” access. 

Finally, using field names discovered in the loadRecord response, the attacker performs a searchRecord call again, targeting a field with “None” access for search or reporting, effectively bypassing the intended restriction. 

To prevent data exposure, enforce granular access controls by changing record type access settings to ‘Require Custom Record Entries Permission’ or ‘Use Permission List’, then refine permissions at the field level, restricting default access and search/reporting levels. 

For critical situations, temporarily take all websites offline to halt data exfiltration, understanding that this will disrupt service for all users. 

Also Read:

Hackers Exploit URL Rewriting to Sneak Phishing Links into Emails

See more