Greetings!
When searching for a good security auditor, we need to conduct a detailed study and analysis of the service's security.
Black-box. Source code is not provided. Production installation, Bitcoin mainnet.
Brief specifications below. Details after candidate approval.
Carefully review the specifications, provide a budget and deadline.
## 1. What is the
Custodial Exchange service? Three public points:
## 2. What to test
### 2.1. Demo
### 2.2. Admin Panel
### 2.3. Custody App
Install on an isolated virtual machine.
Local key storage. Where and how the key material is stored, file permissions. Encryption algorithm and KDF parameters, salt/IV reuse, integrity checking. Evaluation of offline password brute-force speed on a standard GPU with current parameters.
Leaks. Public key in logs, debug output, crash dumps, swap, hibernate file, temporary files. Search for key patterns in the process dump after entering the password.
IPC. Which commands are exposed between the UI and the native part. Is it possible to call a privileged action bypassing the standard UI scenario. Possibility of injection via a local socket.
Interface integrity. Substitution of visual elements of confirmation dialogs, overlay attacks, clickjacking-like vectors. The semantic correctness of the displayed data during normal operation does not need to be evaluated.
Update mechanism. Pinning to the update server, update signature verification, downgrade and rollback protection, and whether the local update cache can be spoofed.
Installer integrity. Embedded secrets, extra or suspicious binaries included.
### 2.4. Network and TLS
### 2.5. Server Infrastructure and Asset
Search Asset search. Subdomain enumeration (passively via CT logs and actively via DNS brute-force). OSINT sources (Shodan, Censys, ZoomEye, leaks in public repositories). Reverse DNS on found ranges. Linking assets of a single owner via ASN, certificate fingerprints, JARM/JA3.
Port scanning. TCP/UDP by found IPs, service versions and banners, checking against databases of known vulnerabilities.
Open services and incorrect settings. Externally accessible administrative interfaces (Grafana, Prometheus, Kibana, mempool/explorer, queues, Redis, PostgreSQL, etcd, Consul and similar). Open Bitcoin RPC, ZMQ. Default credentials. Accessible without authentication /metrics, /debug, /actuator, /swagger, /graphql. Public .git, .env, DB dumps, backups.
Cloud misconfigurations. Open S3 / GCS / Azure Blob. Public snapshots, disk images. Anonymous IAM recalculation. Cloud metadata leak via detected SSRF.
Mail and DNS. SPF, DKIM, DMARC, BIMI on the operator's domains. DNSSEC. Open recursive resolvers, walkable zones. Mail forgery if there are public addresses.
CDN and edge. Origin IP lookup bypassing CDN (historical DNS records, SAN certificates, error pages with origin headers, sloppy DNS records like direct.<domain>
. WAF and rate-limit bypass via non-standard headers. Cache poisoning via manipulation Vary.
### 2.6. Reverse engineering
Custody App (binary). Unpacking the installer, static analysis of the compiled code. Search for embedded secrets: API keys, tokens, test accounts, hidden debug flags. Additional backend addresses — dev/staging hosts, telemetry, analytics. Third-party libraries and their versions — known vulnerabilities. Anti-debug and anti-tamper protections and their bypassability. Code signature chain: validity, presence of a timestamp counter-signature.
Demo and admin web assemblies. JS bundle analysis: source maps in production, obfuscation and its bypassability, hidden API surface visible through the bundle. Hardcoded addresses, feature flags, debug and admin routes in client code. Third-party SDKs in the bundle (Sentry DSN, analytics, chat widgets — each with its own attack surface). Admin logic leakage into public chunks.
Network formats. Reverse custom exchange formats between the custody app and the backend if non-plain JSON is used. Structure of authentication tokens and signed payloads.
## 3. What's out of scope
**More details after approval.
When searching for a good security auditor, we need to conduct a detailed study and analysis of the service's security.
Black-box. Source code is not provided. Production installation, Bitcoin mainnet.
Brief specifications below. Details after candidate approval.
Carefully review the specifications, provide a budget and deadline.
## 1. What is the
Custodial Exchange service? Three public points:
- Demo is a client site where a mixing request is created.
- Admin Panel — operator panel. Credentials are not provided.
- Custody App is the operator's desktop application that holds part of the cold key.
## 2. What to test
### 2.1. Demo
- IDOR on order reading: is it possible to read someone else's order, iterate over it, or predict its identifier?
- Server-side validation of form fields is the substitution of parameters in circumvention of UI restrictions (without assessing the impact on business operations).
- XSS and HTML injections in all free input fields.
- Injections: SQL, NoSQL, command, header, template.
- SSRF via any URL fields.
- Open redirects.
- Session cookie security: flags Secure/ HttpOnly/ SameSite, session fixation, predictable identifiers.
- CSRF on modifying operations.
- Leaks in responses: traces, versions, internal paths.
- HTTP request smuggling, response splitting.
- File upload and path traversal - if available.
### 2.2. Admin Panel
- Bypassing login without credentials: default passwords, weak JWT, password reset hijacking, predictable sessions.
- Access to admin API without authentication.
- Open service paths: debug routes, preview environments, /.envhealth endpoints.
- Privilege escalation: client → admin, viewer → operator.
- TOTP weaknesses: predictable backup codes, no rate limit on code verification, races to verify.
- Stored XSS on surfaces that the operator sees after logging in (via the demo, user-agent, and IP fields in the admin logs).
- CSRF on operator actions.
- Disclosure before login: open Swagger, /metricssource maps in production build, available .git.
- RCE via any injection, deserialization, file upload, or templating engine.
### 2.3. Custody App
Install on an isolated virtual machine.
Local key storage. Where and how the key material is stored, file permissions. Encryption algorithm and KDF parameters, salt/IV reuse, integrity checking. Evaluation of offline password brute-force speed on a standard GPU with current parameters.
Leaks. Public key in logs, debug output, crash dumps, swap, hibernate file, temporary files. Search for key patterns in the process dump after entering the password.
IPC. Which commands are exposed between the UI and the native part. Is it possible to call a privileged action bypassing the standard UI scenario. Possibility of injection via a local socket.
Interface integrity. Substitution of visual elements of confirmation dialogs, overlay attacks, clickjacking-like vectors. The semantic correctness of the displayed data during normal operation does not need to be evaluated.
Update mechanism. Pinning to the update server, update signature verification, downgrade and rollback protection, and whether the local update cache can be spoofed.
Installer integrity. Embedded secrets, extra or suspicious binaries included.
### 2.4. Network and TLS
- TLS on front-facing domains: versions (excluding 1.0/1.1), cipher suites, HSTS with preload, mixed content, certificate chain, OCSP stapling.
- Custody-app ↔ backend channel: pinning by key or certificate, mismatch behavior (fail-closed or silent fallback), the ability to slip in your own CA via system storage, interception and modification of traffic at the transport layer (without evaluating semantics), interception of authentication material.
- DNS hygiene: no CAA, weak SPF/DMARC.
- Subdomain takeover on demo and admin domains.
- Incorrect CORS on API.
### 2.5. Server Infrastructure and Asset
Search Asset search. Subdomain enumeration (passively via CT logs and actively via DNS brute-force). OSINT sources (Shodan, Censys, ZoomEye, leaks in public repositories). Reverse DNS on found ranges. Linking assets of a single owner via ASN, certificate fingerprints, JARM/JA3.
Port scanning. TCP/UDP by found IPs, service versions and banners, checking against databases of known vulnerabilities.
Open services and incorrect settings. Externally accessible administrative interfaces (Grafana, Prometheus, Kibana, mempool/explorer, queues, Redis, PostgreSQL, etcd, Consul and similar). Open Bitcoin RPC, ZMQ. Default credentials. Accessible without authentication /metrics, /debug, /actuator, /swagger, /graphql. Public .git, .env, DB dumps, backups.
Cloud misconfigurations. Open S3 / GCS / Azure Blob. Public snapshots, disk images. Anonymous IAM recalculation. Cloud metadata leak via detected SSRF.
Mail and DNS. SPF, DKIM, DMARC, BIMI on the operator's domains. DNSSEC. Open recursive resolvers, walkable zones. Mail forgery if there are public addresses.
CDN and edge. Origin IP lookup bypassing CDN (historical DNS records, SAN certificates, error pages with origin headers, sloppy DNS records like direct.<domain>
### 2.6. Reverse engineering
Custody App (binary). Unpacking the installer, static analysis of the compiled code. Search for embedded secrets: API keys, tokens, test accounts, hidden debug flags. Additional backend addresses — dev/staging hosts, telemetry, analytics. Third-party libraries and their versions — known vulnerabilities. Anti-debug and anti-tamper protections and their bypassability. Code signature chain: validity, presence of a timestamp counter-signature.
Demo and admin web assemblies. JS bundle analysis: source maps in production, obfuscation and its bypassability, hidden API surface visible through the bundle. Hardcoded addresses, feature flags, debug and admin routes in client code. Third-party SDKs in the bundle (Sentry DSN, analytics, chat widgets — each with its own attack surface). Admin logic leakage into public chunks.
Network formats. Reverse custom exchange formats between the custody app and the backend if non-plain JSON is used. Structure of authentication tokens and signed payloads.
## 3. What's out of scope
**More details after approval.
