In the course of performing data leaks investigation on behalf of an UpGuard client, a member of the UpGuard Data Breach Research team discovered publicly accessible information belonging to technology services provider HCL. The public data included personal information and plaintext passwords for new hires, reports on installations of customer infrastructure, and web applications for managing personnel. After notifying HCL, the pages with the sensitive information were made inaccessible, securing the known data exposures.
Because this data exposure involves a different vector than our previous reports, some background on the activity of the research team will help explain how it was discovered. The UpGuard research team continuously monitors for exposures of sensitive information for customers of the Breachsight Data Leaks module. This approach is keyword-based and datacentric; it is agnostic to where or how the data is stored. In some cases that data may be posted on a software-as-a-service application like Trello or hosted on an infrastructure-as-a-service platform like AWS.
In this case, a file containing customer keywords was publicly accessible for download from an HCL domain. That file was discovered on May 1, 2019. Additional searches of that domain led to the discovery of other publicly accessible pages with personal and business data. Due to the nature of the exposure, ascertaining its extent required several days of work. Whereas a typical data exposures involves one collection of data, either in a single storage bucket or database, in this case the data was spread out across multiple subdomains and had to be accessed through a web UI. These constraints expanded the scope of analysis and limited the speed with which the analyst could access the data.
On May 6, after reaching a reasonably complete level of analysis of the public pages and data, the researcher sent notification to HCL’s Data Protection Officer at email@example.com. That notification included links to five subdomains hosting pages with some kind of business information and two URLs for pages as examples of what could be found on those subdomains. On May 7, the analyst confirmed that those two pages could no longer be accessed without authentication but that pages on the other subdomains were still accessible. The analyst sent a followup email linking to other pages with HCL data, and on the next day, May 8, the analyst confirmed that those pages were also no longer accessible to anonymous users.
Several subdomains with different applications were included in the set of resources with information from HCL.
Human Resources Dashboards
One subdomain contained pages for various HR administrative tasks. Not all pages within this subdomain were accessible– the pages that were accessible contained links to many other parts of the application that returned a “session expired” message when visited. But the pages that did allow anonymous access included substantial amounts of personal information, some of it very recent.
A dashboard for new hires included records for 364 personnel. The oldest were from 2013, but over two hundred records were from 2019. In fact, 54 of the records were for people who joined on May 6, 2019. The exposed data included candidate ID, name, mobile number, joining date, joining location, recruiter SAP code, recruiter name, created date, user name, cleartext password, BGV status, offer accepted, and a link to the candidate form. Among those data points, the most obvious risk is that the passwords could be used to access other HCL systems to which these employees would be given access.
Another page related to personnel management listed the names and SAP codes for over 2,800 employees. Another application page presented a field where SAP codes and names could be used to look up and “deactivate” employees, though none of these actions were attempted by the researcher.
Customer Installation Reports
HCL provides a wide range of services and according to their website they have over a hundred thousand employees, making efficient project management crucial to their business. Part of their method for doing so is the “SmartManage” reporting system, according to news coverage of their contract with the State Bank of India to interlink ATMs via VSATs (“Very Small Aperture Terminals”– small satellite dishes that enable connectivity). A reporting interface for the SmartManage system, with data up to the present day, was left open, exposing information about project statuses, sites, incidents, and more.
These reports included sets of dropdowns to configure the search. The options available varied slightly between reports, as fits their varying purposes and datasets. The “Customers” list included a little over two thousand names.
The index of the reporting app listed these reports, all of which were accessible to anonymous users:
Internal Analysis Reports (To be shipped to customer on specific request)
- Top N Incidence Report
- Detailed Incidences Report
- Service Window Uptime Report
Weekly Customer Reports (Shipped out to customers every week - Automated).
- Network Uptime Report
- VSAT Summary Uptime Report
- Reason Analysis Report
- Reason Analysis Report (LHO Wise)
- Project Summary Report
- Project Summary Report (LHO Wise)
- Pending Action Report
- Pending Action and Summary Report
- Pending Action and Summary Report (LHO Wise)
- DOT Report
- Activation Report
- Pending Order Report
- Order Cancelled Report
- Site Problem Report
- Shipment on Hold Report
- Project Customers Dashboard Report
- Short and Dead Shipment Report
- Shipment Detail Report
- Shifting and Dismantling Report
The ASP framework used on this site had a security feature that prevents requests from being submitted if they are not from the UI. This prevents the alteration of requests to go beyond the scope of what the user is authorized to access. Because the UI was fully available to anonymous users, this did not protect the data, but did prevent bulk downloading of all data by calling the APIs directly. Because a complete data set is both inconvenient and unnecessary for our purposes, samples were taken to confirm the types and approximate quantities of data to which an attacker would have had access. None of the data here included credentials, but there were substantial amounts of information about HCL projects.
Internal Analysis Reports
The “detailed incidences report” listed about 5700 incidents with fields labeled: VSAT ID, Location, ATM ID, Start time, End time, Duration, Reason, and Description. The “Service Window Uptime Report” includes VSAT ID, Consignee, City, Accountable Uptime, Comnet Issue, Non HCL Comnet, Customer issue, Uptime. There were 450 records for April of 2019, 450 records for January of 2019, and 521 records for January 2018, matching the regularity one would expect from some kind of standard monthly report.
Weekly Customer Reports
The weekly customer reports included large numbers of records for tracking system performance. Thus far in 2019 (from January to May) there were approximately 18k records, with fields for VSAT ID, Location, City, Accountable Uptime, Comnet Sisue, Non HCL comnet, and Uptime.
There were many report views available in this section that appeared to offer similar data sliced in different ways to map to respective business purposes. In general, these reports tracked the progress of installations, and as a result exposed information about client sites and the internals of their progress. These reports tracked the overall status of projects along with the reason for any delays, the status of shipments needed by those projects, and some additional details about the health of VSATs.
The “Reason Analysis Report” included fields for Consignee, Site Address Received, Site Readiness, Customer Issues Identified, Site Cleared, Pending Processing, Shipment on Hold, Pending Dispatch, Dispatches, Received at Site, Installation, Inst. Pending, Customer Issues Identified, Physical Installation Complete, Bandwidth Not Available, Activation Completed, Remarks. There was no count given in the application, but there were about 200 records for 2018 and about 1200 records for 2017. There were records going back to 2016.
Along with tracking project status, there were assorted reports for following shipments with fields for Po No, Customer Name, Consignee, Site Entered (date), Days Elapsed EnToPR, Pending Reservation, DaysElapsedPRtoPE, Pending Delivery, DaysElapsedPDtoIN, Installation Pending, Days Elapsed INSToSA, and Site Activated. The purpose of the reports was to provide detailed visibility into what was happening at each site– valuable information for a project manager— or a would be attacker.
The “DOT report” had a comparatively smaller number of entries but had detailed information on the installation of the VSATs themselves. The app only allows retrieving one month of data at a time, but in sampling there appeared to be several of these installations each month going back to 2017. The reports documented the id, size, location, and surroundings of the VSAT.
Escalation matrix for transportation service
It’s unknown how recent this information was, but one page included the names, email address, and mobile phone numbers for fifteen cab hubs and seven bus hubs. As part of an escalation matrix, this information had a business context that malicious actors could have used to waste valuable resources and possibly launch highly targeted phishing attacks. This page included a link to a login page, so the developer may have intentionally made it public, but the information on the escalation chain beyond tier one support seemed like it would only be intended for HCL personnel and privileged customers. It is no longer publicly accessible.
Administrative panel for recruiting approval chain
The “Smart Recruit” system appeared to be part of administering the approval process for hiring. The GroupID parameter was in the URL and could be iterated to reach the pages for eight groups. The pages for each group looked fairly similar, though some required two approvers and some required three. It was unclear whether these systems were being used, but if they were, their access by a malicious actor could have caused business disruption.
A large services provider like HCL necessarily manages lots of data, personnel, and projects. That management complexity writ large is the root cause of data leaks in general. In this case, pages that appeared like they should require user authentication instead were accessible to anonymous users. The fact that other pages on those same apps did require user authentication speaks to the challenge that causes data leaks: if every page must be configured correctly, eventually a misstep will result in an exposure.
The data also speaks to the gamut of information generated and consumed by business processes. The most obviously sensitive data were the freshly minted passwords for new hires. But credentials are valuable because they provide access to information, and the detailed and long running project plans are the kind of information an attacker might abuse credentials to access. Furthermore, the pages accessible here show how identifying information like internal IDs can be used to expand the scope of a breach to collect more information.
In addition to taking to heart the risk of data leaks, business leaders should also note the effectiveness of HCL’s response. HCL has a Data Protection Officer, which not all companies do. The existence of that role is clearly advertised, and an email address for contacting them easy to find. Though HCL never responded to UpGuard, they took action immediately on notification. Many exposures remain public long after detection due to a lack of public, correct contact information for the responsible party. In this case, HCL’s data protection function advertised how to report exposures to them and acted promptly toward a remedy. In a world where data loss of some kind is inevitable, effective incident response like this is a vital capability.