scc: Session save and push from GURU-5070 at 2026-06-05 10:35

glaztech: :3436 backup-job recon + Tom's architectural reply; session log update.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

clients/glaztech/reports/2026-06-05-quo-sql-fix-list.md

@@ -0,0 +1,68 @@
+# Glaztech — `quo()` SQL parameterization fix list (for Tom)
+
+**Date:** 2026-06-05 · **Source:** live tree on `WWW` (`D:\web\glaztech_4`), via GuruRMM read-only `findstr`
+(excludes stale `Old_bin\` / `Old_code\` copies). Addresses assessment finding **C3**.
+
+## What this is
+
+Every place the site builds dynamic SQL with the `quo()` helper (which wraps a value in quotes but does
+**not** escape embedded quotes → SQL injection). The fix is to **parameterize** these statements (use
+`SqlParameter`/`@params` instead of `quo()`-concatenation), then delete the `quo()` helper. No redesign —
+it's a mechanical, repetitive change.
+
+- **80 `quo()` call sites** across **15 live files** (these are the line-level edits).
+- That's roughly the **~59 concatenated SQL statements** the assessment counted — several statements use
+  multiple `quo()` values per statement, so call-sites (80) > statements (~59). Both numbers are right.
+- Priority: the **payment / order / quote pages** (where customer input flows) first; the rest for completeness.
+
+## Count per file
+
+| Sites | File |
+|---:|---|
+| 15 | `ach.aspx.vb` |
+| 14 | `customer-login\online-payment-pnc.aspx.vb` |
+| 14 | `customer-login\online-payment-ach-na.aspx.vb` |
+| 12 | `customer-login\quote-detail.aspx.vb` |
+| 12 | `customer-login\order-detail.aspx.vb` |
+| 2 | `quick-pay-ach.aspx.vb` |
+| 2 | `quick-pay.aspx.vb` |
+| 2 | `quick-pay-pnc.aspx.vb` |
+| 1 | `customer-login\Order-acknowledgements.aspx.vb` |
+| 1 | `customer-login\order-acknowledgements-approval.aspx.vb` |
+| 1 | `customer-login\online-payment-old.aspx.vb` |
+| 1 | `customer-login\settings.aspx.vb` |
+| 1 | `customer-login\CustomExportPdf.aspx.vb` |
+| 1 | `gs\appearance-makeup.aspx.vb` |
+| 1 | `gs\performance-makeup.aspx.vb` |
+
+## Full list (file : line)
+
+```
+ach.aspx.vb:224, 276, 277, 278, 279, 280, 282, 283, 284, 285, 286, 634, 671, 1246, 1248
+customer-login\online-payment-pnc.aspx.vb:1151, 1326, 1383, 1384, 1385, 1386, 1387, 1389, 1390, 1391, 1392, 1394, 1593, 1629
+customer-login\online-payment-ach-na.aspx.vb:1208, 1388, 1444, 1445, 1446, 1447, 1448, 1450, 1451, 1452, 1453, 1454, 1653, 1692
+customer-login\quote-detail.aspx.vb:96, 97, 98, 101, 102, 103, 286, 288, 310, 312, 1625, 1627
+customer-login\order-detail.aspx.vb:113, 114, 115, 118, 119, 120, 299, 301, 321, 323, 1712, 1714
+quick-pay.aspx.vb:880, 882
+quick-pay-ach.aspx.vb:888, 890
+quick-pay-pnc.aspx.vb:656, 658
+customer-login\Order-acknowledgements.aspx.vb:384
+customer-login\order-acknowledgements-approval.aspx.vb:39
+customer-login\online-payment-old.aspx.vb:1152
+customer-login\settings.aspx.vb:167
+customer-login\CustomExportPdf.aspx.vb:564
+gs\appearance-makeup.aspx.vb:211
+gs\performance-makeup.aspx.vb:175
+```
+
+## Notes
+
+- `quo()` is defined **per page** (not one shared helper). Explicit `Function quo` definitions confirmed in
+  `gs\appearance-makeup.aspx.vb:494` and `gs\performance-makeup.aspx.vb:482`; the payment pages carry their
+  own local copies. So "delete `quo()`" means removing each page's local copy after its call sites are fixed.
+- The 12 stale copies under `Old_bin\` / `Old_code\` are **not** in this list (not the live code) — but those
+  duplicate trees should be removed from the production host separately (assessment H1 / item 20).
+- Each page should be **tested after** parameterization (no staging — H1), confirming the queries still return
+  correct results, on a maintenance window with rollback.
+- `online-payment-old.aspx.vb` looks like a legacy page — confirm whether it's still reachable; if dead, remove
+  rather than fix.

clients/glaztech/reports/2026-06-05-tom-message-draft.md

@@ -1,8 +1,7 @@
-# Draft message to Tom (for Mike's review before sending)
+# Draft message to Tom (Mike's final wording, 2026-06-05)
 
-**Channel:** suggest a direct email or Teams/Slack to Tom — NOT buried in the #32378 security ticket
-(that ticket carries the full alarming findings; this message is intentionally light and solution-focused).
-**Tone goal:** lead with relief; one concrete, bounded ask; respect the 20 years; no threat-model dump.
+**Channel:** direct email or Teams/Slack to Tom — NOT buried in the #32378 security ticket.
+**Tone:** partnership / not-a-fire-drill; one concrete bounded ask (the 59-ish SQL queries, with line numbers).
 
 ---
 
@@ -10,45 +9,29 @@
 
 Hi Tom,
 
-We know the last few days have been stressful — the security scan dropped a real bomb in your lap, and
-we don't take that lightly. Believe me when I say we're here to help: to keep Glaztech safe, and to help
-**you** with the security side of the network and the site. You've kept this running for a long time — we're
-not here to second-guess any of that. We're here to take the security weight off your shoulders and work
-it *with* you.
+We know the last few days have been stressful — the security scan dropped a real bomb in your lap, and we don't take that lightly. Believe me when I say we're here to help: to keep Glaztech safe, and to help you with the security side of the network and the site. You've kept this running for a long time — we're not here to second-guess any of that. We're here to take the security weight off your shoulders and work it with you.
 
-Here's the reassuring part, now that we've had time to dig in: **this doesn't have to be a fire drill.**
-What the deeper look showed is that the site, the GTIware tools, and the database all tie together pretty
-tightly — and *because* of that, the right move is a calm, staged plan, not a rushed scramble. We handle
-the urgent, self-contained pieces on our side right away, and work through the rest methodically,
-together, without disrupting your day-to-day or your billing.
+Here's the reassuring part, now that we've had time to dig in: this doesn't have to be a fire drill. What the deeper look showed is that the site, the GTIware tools, and the database all tie together pretty tightly — and because of that, the right move is a calm, staged plan, not a rushed scramble. We handle the urgent, self-contained pieces on our side right away, and work through the rest methodically, together, without disrupting your day-to-day. At least as much I can, I'll try not to be a nuisance.
 
 So here's what we're proposing.
 
 The heavy infrastructure security is squarely our lane, and we'll carry it:
-- Locking down the server and tightening the database permissions
-- Putting a web application firewall in front of the site
-- Tightening the network/firewall around the database server
+•    Locking down the server and tightening the database permissions
+•    Putting a web application firewall in front of the site
+•    Tightening the network/firewall around the database server
 
-And there's one place where your knowledge of the app is exactly what's needed — and where we'd be working
-side by side with you. There's a specific set of **~59 older SQL queries** in the site that build their
-statements by stitching text together; switching those to use parameters is the single highest-value code
-change for hardening the site. It's contained and repetitive — no redesign, no new frameworks. **We'll
-hand you the exact list — files and line numbers — and walk it with you on a call if that's easier**, so
-it's a real collaboration, not a hand-off.
+And there's one place where your knowledge of the app is exactly what's needed — and where we'd be working side by side with you. There's a specific set of ~59 older SQL queries in the site that build their statements by stitching text together; switching those to use parameters is the single highest-value code change for hardening the site. It's contained and repetitive — no redesign, no new frameworks. I'll get you the exact changes I need, down to the line number if that helps, so you can review them and make the changes.
 
-Down the road there's a bigger item — modernizing how saved cards/payments are handled — but that's a
-project we'll plan and scaffold **with** you when there's bandwidth. No rush; we'll carry the legwork.
+Down the road there's a bigger item — modernizing how saved cards/payments are handled — but that's a project we'll plan and scaffold with you when there's bandwidth. No rush; we'll carry the legwork.
 
-Bottom line: you're not on the hook to become a security expert overnight, this isn't a five-alarm
-scramble, and you're not in this alone. We've got the infrastructure side, we'll hand you a clear, bounded
-list for the code piece, and we'll work it together at a sane pace. Let me know a good time to connect.
+Bottom line: you're not on the hook to become a security expert overnight, this isn't a five-alarm scramble, and you're not in this alone. We've got the infrastructure side, we'll hand you a clear, bounded list for the code piece, and we'll work it together at a sane pace. Let me know a good time to connect.
 
 Thanks,
 Mike / Arizona Computer Guru
 
 ---
 
-### Notes for Mike (not part of the message)
-- **Prerequisite before sending:** ACG should run the §2a source grep first so the "exact list of 59 lines/files" is actually in hand when Tom replies — don't promise the list and then make him wait. (Assessment C3 names the files: `ach.aspx.vb`, `quick-pay-ach.aspx.vb`, `quick-pay-pnc.aspx.vb`, `quick-pay.aspx.vb`, `order-detail*` + the `quo()` definition.)
-- **Held back deliberately** (keep the first ask minimal): the customer-vs-employee path-map review and the `/emp/` VPN-gating. Raise those as a separate, lighter touch once the 59-query ask is moving, or have ACG derive the map from logs/source and just confirm a couple of points with him.
-- **Not mentioned:** the full threat model, plaintext passwords, the domain-admin/`msdb`/`xp_cmdshell` chain — all ACG-side, handled without burdening Tom.
+### Notes for Mike
+- Optional tiny grammar fix in para 3: *"At least as much **as** I can, I'll try not to be a nuisance."* — left your wording as-is otherwise.
+- **Prerequisite before sending:** the exact line-number list for the SQL queries — ACG grep in progress (80 live `quo()` call sites found on WWW; producing the per-file:line list now). The message promises "down to the line number," so have it ready when Tom replies.
+- Held back deliberately (minimal first ask): the customer-vs-employee path-map review and the `/emp/` VPN-gating — raise separately/lighter later.

clients/glaztech/reports/2026-06-05-tom-reply-draft.md

@@ -0,0 +1,40 @@
+# Draft reply to Tom (calm/partnership tone, 2026-06-05)
+
+**Channel:** reply to Tom's email/message (the one where he listed what he's already done).
+**Tone:** affirm his direction strongly; ask rather than assert; remind rather than demand.
+**Context:** Tom independently encrypted PAN/CVV/passwords, is building separate web-only DBs on
+0.55 with a dedicated low-priv `web` login, and converting inline SQL to stored procs. This is the
+architectural fix we scoped — ACG's role shifts to validate/align + own the backend infra.
+
+---
+
+**Subject:** Re: Glaztech site — we're in this with you
+
+Hi Tom,
+
+This is great to read — honestly, it's exactly the direction we were hoping for, and you're already further down it than I expected. Splitting the website onto its own databases, getting cc_file off that surface entirely, and giving the site its own limited "web" login instead of your personal one — that's the heart of the whole thing. The stored-proc cleanup and the longer-term move to everything going through the *.dll library layer is the right endgame too. You're solving the hard part at the source, which is better than anything we could bolt on from outside.
+
+A few things I wanted to ask about rather than assume, just so we stay aligned:
+
+- On the card data — the encrypted PAN column is a solid step. Out of curiosity, where does the decryption key live relative to that database? The thing that makes column encryption really pay off is the key sitting somewhere the web login can't reach, so a compromise of the site doesn't hand over both.
+- One heads-up worth flagging on the CVV (cc_code) — this is the one spot where encryption alone doesn't quite get there. The card brands' rules (PCI) treat the CVV as something that can't be retained at all once a payment's authorized, even encrypted. So rather than encrypt it, the usual move is to stop storing it and drop the column once nothing in-flight still needs it. Is that something the new web-DB design could just leave behind?
+- On the website passwords — when you say encrypted, are those one-way hashed (salted), or two-way encrypted? Either is a big improvement over before; just want to make sure I've got it right in my notes. (And if anything in the app ever emails a password back out in plain text, that's a good one to retire while you're in there.)
+- The new web databases landing on 0.55 — since that box also has the accounting data on it, is the new web login scoped so it only sees its own web databases and nothing on the finance side? If it'd help, I'm glad to sit down and work out the exact minimal permission set for that login with you so it's tight from day one.
+- Last one, just to be safe: does the back-office billing engine still point at the main server (8.62) for cc_file? I want to make sure none of the auto-billing gets caught up in the website cutover.
+
+On our side, we'll take the stuff you shouldn't have to think about — locking down the server itself, cleaning up some old backend job credentials, putting a web application firewall in front of the site, and tightening the network around the database servers. That all runs in parallel with what you're doing and doesn't need anything from you.
+
+One thing that might save you some hunting: when we looked through the site we mapped every spot still building SQL the old inline way — I can send you that list as a checklist so the stored-proc conversion doesn't miss a page. Just say the word.
+
+Really glad we're rowing the same direction on this. Let me know a good time to connect if it's easier to talk any of it through.
+
+Thanks,
+Mike / Arizona Computer Guru
+
+---
+
+### Notes for Mike
+- CVV is framed as a "heads-up / usual move" with an ask, not a directive — the one must-fix, softened.
+- Every other technical point is a question, not an assertion (key location, hash-vs-encrypt, web-login isolation on 0.55, billing-engine path).
+- The `quo()` fix-list is offered as a convenience checklist, not a handed-down to-do.
+- Held back for the live conversation: key-management depth, the co-location-on-finance-server risk specifics.

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

@@ -90,3 +90,61 @@ SELECT name,data_source FROM sys.servers WHERE is_linked=1   # the mesh (0.54/0.
 - Ticket: #32378 (id 112111185), Waiting on Customer. Comments 417493519 + 417494988.
 - Coord todos: `aebaf751` (least-priv `tom` migration), `6d15fc88` (E2-E4 containment).
 - GuruRMM: WWW agent `455a1bc7-1c29-42bc-b597-fa1e64f08eec`; GTI-INV-SQL agent `869e56b4-e8ed-4808-8c88-782d1577c152`.
+
+## Update: 10:35 PT — :3436 backup-job recon + Tom's architectural reply
+
+### Summary
+Completed the `:3436` SQL Agent job-definition recon (via tom credential, read-only) and
+reconciled two reachability checks. Then Tom replied to the partnership message with a
+substantial list of work he's already doing — which materially shifts ACG's role.
+
+### Recon findings
+- **`192.168.0.55,55181` (mas_gti linked server) is LIVE** = `GTI-FINANCESVR`, SQL Server 2019
+  (15.0.4322.2). The website's accounting connection is current, NOT vestigial. "Old MAS90 dead"
+  refers to the retired app/box, not this data path.
+- **`SAGE2025` enrolled in RMM** (Glaztech / TUS-Tucson) — new payroll server. Distinct from
+  GTI-FINANCESVR. (This is why we asked Tom how qqest/payroll is used rather than assuming.)
+- **Cleartext domain-admin password (`glaztech\administrator`) sits in ~10-12 backup-job copy
+  steps** across 6 jobs on `:3436`. Pattern (redacted): `exec xp_cmdshell 'net use
+  \192.168.8.52\sql_backup\... /user:glaztech\administrator <PW> /persistent:yes'` then
+  `xp_cmdshell 'copy d:\sql_backup\...\*.* \192.168.8.52\... /y'`. Jobs: Glaz PDF Differential
+  (Daily) to 8.62; Glaz PDF Full (weekly) to 8.52 + to 8.62; Glaz Prod Archive Full Monthly;
+  Glaz Prod Differential (Hourly) to 8.62; Glaz Prod Full (Daily) to 8.62. Most also have a
+  `.212` copy step. `Copy EndofWeek Backups` uses xp_cmdshell for a LOCAL copy only (no creds).
+- The `BACKUP DATABASE` steps themselves are clean TSQL → local disk. Only the push-to-share step
+  carries the cleartext credential. Fix = replace each copy step with a CmdExec robocopy under the
+  service account's own share access (no net use), OR BACKUP TO DISK=UNC directly. That removes the
+  cleartext password AND the last xp_cmdshell dependency → unblocks disabling xp_cmdshell.
+- The bulk of `:3436` jobs are GTIware automation (`gt_console_apps.exe` modes + d:\sql_jobs\*.bat)
+  plus `del \192.168.0.147\web\glaztech_4\pdf_output\*.pdf` (confirms 192.168.0.147 = 2nd web host).
+  Any dedicated Agent service account (E4) must retain DB + d:\sql_jobs + \192.168.0.147 +
+  8.52/8.212 backup-share access.
+
+### Tom's reply (strategy shift)
+Tom independently: encrypted cc_number (cc_number_encrypted) + CVV (cc_code_encrypted) + website
+login passwords; is building separate web-only databases on 0.55 (no cc_file), with a new low-priv
+`web` login replacing his personal login; converting inline SQL to stored procs; long-term moving
+all DB access into *.dll library layer. This is the architectural fix we scoped — ACG's role shifts
+from "carry the app work" to validate/align + own backend infra (the :3436 cleartext/xp_cmdshell/sa/
+domain-admin rotation, WAF, network segmentation).
+
+### Caveats raised to Tom (drafted reply, ask/remind tone)
+1. CVV must not be retained at all even encrypted (PCI 3.2) — drop the column. (The one must-fix.)
+2. Confirm PAN decryption key isolation (key out of web login's reach).
+3. Confirm passwords are salted one-way hash vs reversible encrypt; retire any plaintext-password email.
+4. Confirm new `web` login on 0.55 is scoped off the co-resident accounting (mas_gti) data.
+5. Confirm back-office billing engine still points at 8.62 cc_file (cutover safety).
+Offered: the quo() fix-list as a stored-proc conversion checklist; help defining the web login grants.
+
+### Files
+- Committed (fdcf014): clients/glaztech/reports/2026-06-05-tom-message-draft.md (final),
+  2026-06-05-quo-sql-fix-list.md (80 quo() sites / 15 files).
+- New: clients/glaztech/reports/2026-06-05-tom-reply-draft.md + Outlook draft opened.
+
+### Pending
+- Await Tom's answers (CVV drop, key location, hash vs encrypt, web-login isolation, billing path).
+- ACG-owned Tier A still ours: recreate :3436 backup copy steps clean (CmdExec robocopy / dedicated
+  service account on 8.52/8.212) -> disable xp_cmdshell -> disable sa -> rotate glaztech\administrator;
+  WAF + SQL network segmentation. Sequence: E4 service acct -> clean copy steps -> xp_cmdshell off ->
+  domain-admin rotation.
+- Reference 58KB job dump: tool-results/b30gcchnr.txt (this session's transcript dir).