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

Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-06-03 15:55:57

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

@@ -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).
 
 ---

clients/glaztech/session-logs/2026-06-03-session.md

@@ -104,3 +104,19 @@ Performed a deep security assessment (read-only; no card numbers or passwords re
 - GuruRMM client id `d857708c-5713-4ee5-a314-679f86d2f9f9`; WWW agent `455a1bc7-1c29-42bc-b597-fa1e64f08eec`.
 - TLS fix pattern (legacy .NET → modern gateway): `SchUseStrongCrypto=1` + `SystemDefaultTlsVersions=1` both `.NETFramework\v4.0.30319` hives + app-pool recycle.
 - LE-safe HTTP→HTTPS redirect: URL Rewrite rule with `{REQUEST_URI}` `^/\.well-known/acme-challenge/` negate condition.
+
+---
+
+## Update: 15:52 PT — Payrilla/CyberSource reconciliation + Sage finding
+
+Mike reported Glaztech "no longer uses CyberSource, switched to Payrilla (secure card storage)." Verified the live system rather than take it at face value — and the technical reality contradicts the belief:
+
+- **Website is STILL on CyberSource/PNC.** No `payrilla`/`payrix`/`paya`/`payroc` references anywhere in `D:\web\glaztech_4` code or config. Live payment pages remain `online-payment-pnc.aspx` / `quick-pay-pnc.aspx` → `api.cybersource.com`. `web_payment_header` shows live `CC-WebPayment-PNC` Approved/Error transactions **today** (2026-06-03 14:47 Approved, 15:07 Error) + E-Check.
+- **Plaintext cards STILL being written daily.** `cc_file` last write: Tucson **2026-06-03 14:15** (8/60d), Phoenix **2026-06-03 10:19** (14/60d). Ongoing accumulation, not legacy.
+- **Sage 100 (`mas_gti`) CC module is DISABLED** — `SY_Company` (Company GTI) `CreditCardEnable=N`, `CreditCardVaultOnlyID` empty, `AR_CustomerCreditCard` = **0 rows**. Corrects an earlier in-session assumption that Sage actively tokenizes via Paya: the tokenization columns exist in the Sage schema but are **unused**. Sage stores no cardholder data at all (strengthens the containment finding).
+- **Payrilla/Paya is not visible in either system we can reach.** If in use, it's a separate channel (standalone virtual terminal / different portal / manual) that does NOT cover the website. This is the likely source of the client's "we moved to Payrilla for everything" belief — true at most for some standalone tool, NOT for the website (the system storing plaintext cards).
+- **Anomaly:** `cc_file` now returns "Invalid object name" in the `corp` DB though it existed there this morning (3 rows) — needs a second look; per-office DBs (tuc/phx) unaffected and still writing.
+
+**Actions:** updated `clients/glaztech/reports/2026-06-03-website-security-assessment.md` (added "Current State Verified — 2026-06-03" section; corrected two Sage lines from "uses tokenization / materially compliant" to "CC module disabled, 0 stored cards"). Posted public+emailed client comment on **#32378** (id 417040624) reflecting the live, ongoing risk and that Payrilla is not yet implemented on the site. Drafted a further client clarification (the Sage/Payrilla visibility gap) — **pending Mike's go** before posting (would be the 4th #32378 email today).
+
+**Open:** confirm with Payrilla which flows actually route through them; investigate the corp `cc_file` anomaly; remediation path reframed to "migrate the website's card-on-file to the chosen processor's token vault, stop writing `cc_file`/`cof_payments_header`, purge plaintext + backups, decommission CyberSource."

wiki/clients/glaztech.md

@@ -124,8 +124,9 @@ A full read-only security assessment of the Glaztech e-commerce web application
 
 - **`cc_file` (~780 saved cards):** Full PAN stored in plaintext in every per-office database (`glaz_prod`, `glaz_prod_phx`, `glaz_prod_slc`, `glaz_prod_elp`, `glaz_prod_den`, `glaz_prod_alb`, `glaz_prod_boi`, `glaz_prod_brl`, `glaz_prod_shp`, `glaz_prod_corp`). Zero encrypted rows. `cc_file.cc_code` retains CVV/CID (50/54 rows in tuc; mirrors expected in all offices). **CVV retention is a PCI Req 3.2 violation — indefensible; no exception even if encrypted.**
 - **`cof_payments_header` (historical payments):** Phoenix alone: 14,496 rows, 11,794 plaintext PANs. Tuc: 2,245 rows, ~367 plaintext + ~597 formatted. Years of transaction history with recoverable card numbers.
-- **Why cards are stored:** Card-on-file invoice auto-pay. `i_get_cc_on_file_invoices` joins `invoice` × `cc_file`; `gt_auto_process_2020.dll` reads stored PANs and bills them via CyberSource. Stale copies in `Old_bin`/`Old_code\Bin`. **Feature can be preserved by migrating to CyberSource token vault — store a token reference instead of the raw PAN.**
-- **Containment:** Exposure is limited to the 15 custom web-app databases on 192.168.8.62. The Sage 100 ERP DB (`mas_gti`) uses proper tokenization (`CreditCardGUID`, `Last4Unencrypted`, `EncryptedCreditCardNo`) and is materially compliant. **Database backups also contain plaintext PANs — cleanup must address backups, not just live data.**
+- **Why cards are stored:** Card-on-file invoice auto-pay. `i_get_cc_on_file_invoices` joins `invoice` × `cc_file`; `gt_auto_process_2020.dll` reads stored PANs and bills them via CyberSource. `get_cc_data` is `SELECT * FROM cc_file` (returns full PAN+CVV; IDOR-shaped on `@acctno`). Stale copies in `Old_bin`/`Old_code\Bin`. **Feature can be preserved by migrating to the chosen processor's token vault — store a token reference instead of the raw PAN.**
+- **Containment:** Exposure is limited to the 15 custom web-app databases on 192.168.8.62. The Sage 100 ERP DB (`mas_gti`) stores **no** cardholder data — its native CC module is **disabled** (`SY_Company.CreditCardEnable=N`, `AR_CustomerCreditCard`=0 rows; tokenization columns exist in the schema but are unused). **Database backups also contain plaintext PANs — cleanup must address backups, not just live data.**
+- **Processor reality (verified 2026-06-03):** despite a belief that processing moved to "Payrilla/Paya," the website is **still on CyberSource/PNC** (no Payrilla anywhere in site code/config) and **still writing plaintext cards daily** (`cc_file` last write tuc 2026-06-03 14:15, phx 10:19; live `CC-WebPayment-PNC` txns today). Sage's CC module is off. Payrilla, if used, is a **separate channel not visible in either system and not connected to the website** — the website exposure is unchanged. Anomaly: `cc_file` absent in the `corp` DB though present earlier 2026-06-03 — needs a look.
 
 ### Authentication — Plaintext Passwords
 
@@ -171,7 +172,7 @@ Obtain a customer login (LOW difficulty — no lockout, guessable username = acc
 5. Hash all passwords (PBKDF2/bcrypt/Argon2); replace email-the-password flow with reset-token flow; force global reset
 6. Parameterize all concatenated SQL in payment pages; delete `quo()`
 7. Add Secure+HttpOnly cookies, session regeneration on login, login throttling/lockout
-8. Migrate card-on-file to CyberSource token vault; purge/encrypt historical `cc_number` columns; address backups
+8. Migrate card-on-file to the chosen processor's token vault (CyberSource or the new provider — confirm which flows actually route through "Payrilla"); purge/encrypt historical `cc_number` columns; address backups
 
 **Structural:**
 9. Separate dev from production; deploy precompiled; remove SDKs/IDE/source from prod host