azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

sync: auto-sync from GURU-5070 at 2026-06-03 15:55:57

Browse Source 
Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-06-03 15:55:57
This commit is contained in:
Mike Swanson
2026-06-03 15:56:01 -07:00
parent ea0b406259
commit d33951041d
3 changed files with 36 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
clients/glaztech/reports/2026-06-03-website-security-assessment.md
View File

@@ -30,6 +30,20 @@ The site stores cardholder data (PAN + CVV) and **all user passwords in plaintex
---
## Current State Verified — 2026-06-03 (exposure is ACTIVE and ONGOING)
Re-checked the live system after a report that card processing had moved to a different provider ("Payrilla"):
- **The website is still on CyberSource/PNC.** There is **no Payrilla integration** anywhere in the site code or config; the live payment pages remain `online-payment-pnc.aspx` / `quick-pay-pnc.aspx` → CyberSource (`api.cybersource.com`).
- **Card processing is live via PNC today** — `web_payment_header` shows `CC-WebPayment-PNC` approvals/errors on 2026-06-03 (e.g. 14:47 Approved, 15:07 Error) plus E-Check.
- **Plaintext cards are still being written to the local databases every day** — `cc_file` last write: Tucson **2026-06-03 14:15** (8 writes/60d), Phoenix **2026-06-03 10:19** (14 writes/60d). This is ongoing accumulation, not historical data.
- *(Anomaly: `cc_file` returns "Invalid object name" in the `corp` DB though it existed there earlier the same day — needs a second look; the per-office DBs are unaffected and still writing.)*
- **Where is "Payrilla/Paya," then?** Not in the website (CyberSource) and not in Sage 100 — Sage's native CC module is **disabled** (`CreditCardEnable = N`, 0 stored cards). So the new processor is **not visible in either system we can reach**; if it is in use it is a **separate channel** (e.g. a standalone Paya/Payrilla virtual terminal or a different portal) that does **not** cover the website. This is the likely source of the "we moved to Payrilla for everything" belief — it may be true for some manual/standalone processing, but it is **not** true for the customer website, which is the system storing plaintext cards.
**Implication:** any move to Payrilla has **not** been applied to this website. The plaintext PAN + CVV exposure in this report is fully active and **growing daily**; switching processors provides no protection until the website is actually re-pointed to a tokenized store and the stored data is purged. The correct remediation path is to **complete a real migration to the new processor's secure token vault** (store a token, never the PAN), stop writing `cc_file`/`cof_payments_header`, purge the existing plaintext cards + CVV, and then decommission CyberSource. Treat this as a live, present risk.
---
## Critical Findings
### C1 — Plaintext PAN and stored CVV (see companion PCI report)
@@ -83,7 +97,7 @@ Chaining the findings into the realistic worst case, with difficulty ratings.
**Where the full PAN is used.** Only five DB objects reference the full `cc_number`: `save_cc_data`/`save_cc_data1`/`save_cc_data2` (writes) and the `is_cc_active`/`is_cc_on_file` functions. However, **`get_cc_data` is `SELECT *`**, so it also returns the full PAN + CVV whenever a saved card is read for charging — the full number crosses to the app server on every card-on-file charge; the UI only masks the *display*.
**Containment — does NOT spread to other systems.** The Sage 100 ERP DB (`mas_gti`) has **0** procedures referencing `cc_file` or `web_security` — the plaintext cards do **not** propagate into Sage (which uses tokenization). Exposure is **contained to the custom web app's 15 office databases** on SQL `192.168.8.62`. Secondary exposure surfaces: **database backups** (every backup of those DBs contains plaintext PAN + CVV) and **stale on-disk code/data copies** (`Old_bin`, `Old_code`).
**Containment — does NOT spread to other systems.** The Sage 100 ERP DB (`mas_gti`) has **0** procedures referencing `cc_file` or `web_security` — the plaintext cards do **not** propagate into Sage. (Sage's native CC module is in fact **disabled** — `SY_Company.CreditCardEnable = N`, `AR_CustomerCreditCard` = 0 rows — so Sage stores no cards at all and is not a cardholder-data location.) Exposure is **contained to the custom web app's 15 office databases** on SQL `192.168.8.62`. Secondary exposure surfaces: **database backups** (every backup of those DBs contains plaintext PAN + CVV) and **stale on-disk code/data copies** (`Old_bin`, `Old_code`).
**Fix preserves the feature.** Migrating card-on-file to the **CyberSource token vault** (store a token; let CyberSource hold the PAN) lets `gt_auto_process` keep auto-billing by token while removing every stored PAN/CVV — and removes the cardholder-data liability from backups.
@@ -126,7 +140,7 @@ Web app connects with a **single shared SQL login (`tom`)** that has full read o
## What is Acceptable (balanced view)
- **OS patching is current-ish:** Windows Server 2019, build 17763.8755, patched through **May 2026** (supported to 2029) — the OS itself is *not* the weak point.
- **Most data access is parameterized** (948 parameterized calls) — the SQLi exposure is a bounded set of concatenated queries, not pervasive.
- **The Sage 100 ERP DB** (`mas_gti`) uses proper tokenization (`CreditCardGUID`, `Last4Unencrypted`, `EncryptedCreditCardNo`) — materially compliant; the exposure is the **custom web app**, not Sage.
- **The Sage 100 ERP DB** (`mas_gti`) stores **no** cardholder data — its native CC module is **disabled** (`CreditCardEnable = N`, `AR_CustomerCreditCard` = 0 rows; tokenization columns exist in the schema but are unused). The plaintext exposure is **entirely the custom web app**, not Sage.
- TLS 1.2 to CyberSource now works (payment outage fixed 2026-06-03).
---