Brilliant Hire Exposure No Bounty
- Adam Baldwin
- Application , Data
- October 30, 2016
During security research a few years back, I discovered an exposure on SAP’s BrilliantHire API - an exposed Node.js debugger instance that provided full remote code execution capabilities and access to sensitive AWS credentials, database encryption keys, and production source code. The finding highlights how a simple misconfiguration can lead to complete system compromise.
The Issue
Node.js debuggers left exposed to the internet require no authentication and essentially provide “remote code execution as a service”. An attacker can simply:
- Navigate to chrome://inspect
- Click “Configure”
- Add the IP:port of the exposed debugger
- Get full access to the running process
In this case, the debugger was accessible at http://35.166.232.40:9229/
The Impact
Through the exposed debugger, I had access to:
2 Production AWS credentials including access keys:
- AKIAJREDACTEDERICWXQ
- AKIAREDACTEDZMMLZGV5
These credentials had access to multiple S3 buckets including:
- brillianthire-test
- brillianthire.fileuploads
- brillianthire.io
- brillianthire.logs
- dashboard.brillianthire.io
- transcript-backups
- And several others
Database encryption keys (potentially dev environment):
- Database IV
- Database encryption key
- Database salt
Full source code access
Internal hostnames and infrastructure details
The Takeaway
This type of exposure is particularly dangerous because:
- Node.js debuggers provide full RCE capabilities with no authentication
- The process runs with the same permissions as the application
- Environment variables containing sensitive credentials are exposed
- Source code can be extracted
When running Node.js applications in production, always ensure debugger ports are not exposed to the internet. If debugging is needed, use SSH tunneling or VPN access rather than exposing the port directly.
Note: All credentials shown have been rotated and are no longer valid. The debugger has since been taken offline.